Telefoncek.si

Rootkits - how deep the rabbit hole is?

Thu, 11 Dec 2025 01:00:00 +0100

Rootkits are malicious software designed to gain unauthorized access to a computer system and hide their presence. Therefore attackers can use rootkits to conceal their presence on a compromised system and make it possible to return undetected at some later date.

A rootkit usually hides by intercepting and altering communications at the interfaces between various system components, so rootkits are a form of man in the middle attack.

Rootkits allow an attacker to maintain command and control over a system without the owner’s knowledge. Typically they enable remote file execution, system configuration changes, can log keystrokes or network activity and other forms of spying on user activities. If they are hidden in device or file system drivers, they can hide files, they can hide processes, disable security policies, etc.

First generation rootkits just modified system files on the target system. Typical example was modified UNIX login program, that stole login credentials of a victim. Later rootkits started to modify static OS components and dynamic OS objects loaded in memory.

Bootkit

Bootkit is a malware and specific type of rootkit, designed to infect a computer and to load their malicious code into memory before the operating system initializes. Bootkits usually target the system's bootloader, kernel boot files, Master Boot Record (MBR), or Basic Input/Output System (BIOS)/Unified Extensible Firmware Interface (UEFI). By targeting the pre-boot environment, bootkits can bypass standard security measures and remain hidden. They often have the ability to survive reinstallation of an operating system, so they are hard to remove.

Bootkits were popular in 1980s and 1990s, but the technology of bootkits is also implemented in various governmental and commercial remote surveillance tools (“Nice Boots!” - A Large-Scale Analysis of Bootkits and New Ways to Stop Them).

CIH - Chernobyl virus

The first bootkit was CIH (Chernobyl virus), which appeared in 1998. It was developed by a Taiwanese student Chen Ing-hau (hence the name CIH) and targeted Windows 9x systems. The malware corrupted the MBR and overwrote parts of the BIOS, rendering the system unbootable.

Another known bootkit/computer virus was Stoned. It was created in 1987 and infected computers by booting from an infected floppy disks (that was also the vector of its spreading).

Around 2007 security researchers identified more advanced Alureon bootkit (also known as TDSS or TDL-4), that infected MBR of the computer and was used to intercept network traffic and to steal banking and other sensitive user data.

In 2007 appeared IceLord (also known as ICLord Bioskit), which was the first BIOS based proof-of-concept bootkit. In 2011 the first BIOS bootkit appeared in the wild. It was called Mebromi and targeted Chinese computers. The first UEFI bootkit that was sold on cybercrime forums (BlackLotus) was discovered in 2022.

As mentioned, the technology of bootkits is often implemented in various governmental and commercial remote surveillance tools. One of the reasons is, that bootkits can be used to bypass encryption, typicaly by intercepting passwords or encryption keys entered during boot.

This was shown by security researcher Joanna Rutkowska in her Evil Maid proof-of-concept tool (developed in 2009), that targeted systems using TrueCrypt (version 6.x) full disk encryption software. The tool replaced the original bootloader with a malicious version, which logged the user's encryption passphrase when it was entered during the next legitimate boot.

Evil Maid attack is a name of physical attack scenario where an attacker with physical access to a device (for instance laptop) manipulates it to compromise security, usually while the legitimate owner is absent. The name comes from the hypothetical scenario of a "maid" in a hotel tampering with a guest's computer. The mentioned application Evil Maid, developed by Joanna Rutkowska, is a bootkit, that was developed to perform an Evil Maid attack against TrueCrypt. The malware intercepted TrueCrypt's password that was typed in by the user, and stored it in a particular location on the disk and then passed it on to TrueCrypt. The attacker could later extract the stored password the next time they have physical access to the computer, thus bypassing encryption protection.

According to some media reports, this is how the Israeli secret service obtained the access to the data on a computer of a Syrian diplomat who had left his computer unattended in a hotel room in London in 2006. The data obtained that way had proved that Syria was building the secret Al-Kibar nuclear facility in the desert (in IAEA documents it is also referred as Dair Alzour). The nuclear facility was subsequently bombed in Operation Orchard (also known as Operation Outside the Box) on September 6th 2007.

Al Kibar facility - before and after bombing

From this we can clearly see how bootkits (and rootkits) could be utilized for cyberattacks and spying.

How deep the rootkit can go?

Rootkits can hide at different parts of the system, or, to be more specific, in different so called protection rings.

Protection rings, also called hierarchical protection domains, are mechanisms to protect data and functionality from faults (by improving fault tolerance) and malicious behaviour.

Rings in computer systems are arranged in a hierarchy from most privileged (most trusted, usually numbered zero) to least privileged (least trusted, usually with the highest ring number). On most operating systems, Ring 0 is the level with the most privileges and interacts most directly with the physical hardware.

Computer operating systems provide different levels of access to resources, and correctly gating access between rings can improve security by preventing programs from one ring or privilege level from misusing resources intended for programs in another.

Example, spyware running as a user program in Ring 3 should be prevented from turning on a web camera without informing the user, since hardware access is reserved for Ring 0 (kernel mode).

Modern operating systems are using only Ring 0 (kernel mode) and Ring 3 (user mode). However, there are even lower rings, that - if attacked - could compromise the entire systems (operating system and user applications). So let's take a look into the different levels of rootkits to see how stealthy they could get.

Ring 3 rootkits

Ring 3 rootkits, also called user mode rootkits are running at the user-space level. They run with the lowest level of privileges within the operating system and can perform a damage at the user space of the infected user.

Ring 3 rootkits mitigation

Since Ring 3 rootkits do not have kernel-level access they are easier to detect and remove. Good strategy against this malicious software is application sandboxing (in order to minimize damage within the infected user space) and regular backuping/snapshoting of the complete user space in order to prevent complete data loss.

Also, good strategy of a user could be to use different isolated environments for different tasks. For instance, for web browsing user should use one isolated environment, for banking another, and so on. So in case web browsing environment gets compromised, infection is limited to this environment only and would not affect environment used for online banking.

Ring 0 rootkits

Ring 0 rootkits, known also as kernel mode rootkits reside in the core of the operating system (so called kernel space). They have the highest level of privileges within the operating system. They are usually hard to remove, since they operate at the highest privilege level (Ring 0) and could be deeply integrated into the operating system.

They can hide files, processes, or network activity and modify system calls. Often the removal requires specialized tools or reinstalling the complete operating system.

Ring 0 rootkits mitigation

However, good strategy against this malicious software is running the operating system in virtual compartment and to use different isolated environments for different tasks. Additionally, if system enables virtual machine level snapshots, that can assure that the whole system could be easily returned to a last known good state.

In that case virtualisation technology provides the isolation of different virtual machines. One example of solution against that type of threats is provided by QubesOS. QubesOS is a security focused desktop operating system that provide security and segmentation of applications through isolation with virtualization services.

QubesOS architecture

In QubesOS, the user has several isolated environments, which are used for different tasks. If one of the virtual compartments gets compromised, the malicious software would get access to only the data and applications inside that environment. Isolation is provided by hardware controllers (some virtual compartments can have limited access to the hardware, for instance to microphone or camera), and with virtualisation, where the user's digital life is divided into security domains with different levels of trust. Unfortunately, QubesOS is quite complex and is less suitable for regular users, because it has quite steep learning curve.

QubesOS

Ring -1 rootkits

Ring -1 rootkits, also known as hypervisor rootkits operate at the hypervisor level, below the operating system. Hypervisor is a software code used to run and manage one or more virtual machines on a computer. Because they run at a privilege level higher than the operating system's kernel, they are called Ring -1.

Those rootkits exploit virtualization features in modern CPUs to run the rootkit as a hypervisor beneath the operating system. Usually they can intercept and manipulate hardware-level instructions and can virtualize the operating system to control it entirely. Basically they create virtual environment and confine operating system into it, while the compromised operating system believes it is running directly on the hardware. They are extremely challenging to detect (and remove), because they can manipulate the operating system from outside its own context.

In 2006, a Polish security researcher Joanna Rutkowska conceptualized Ring-1 malware, called Blue Pill. It exploited virtualization extension AMD-V to act as a hypervisor, and was able to place the operating system in a virtualized environment without the operating system being aware of it. While operating system thinks it is operating on bare-metal hardware, in reality, it's running in a hypervisor and is being being monitored and manipulated by the Blue Pill rootkit.

While Blue Pill initially used AMD-V virtualisation extension, other researchers (for instance, Dino Dai Zovi, also in 2006) has shown, that Intel VT-x virtualisation extension could also be exploited. Similarly, researchers from Microsoft and the University of Michigan in 2006 developed a proof-of-concept malware designed as a virtualization-based rootkit, called SubVirt.

Ring -1 rootkits mitigation

One solution against Ring-1 rootkits is to disable hardware virtualization in BIOS/UEFI, however in that case user will be limited running virtual environments on their system.

Another solution is to use trusted boot mechanisms. Those mechanisms perform hypervisor integrity checks (by verifying its cryptographic signature) and can help to ensure that unauthorized hypervisors cannot load during the boot process. Those mechanisms are provided by the open source BIOS/UEFI project called Dasharo (with Heads payload), however more about that will be explained later.

Ring -2 rootkits

Ring -2 rootkits are a mix of so called SMM rootkits and BIOS/UEFI bootkits (also called UEFI implants). Usually Ring-2 rootkits utilize SMM and UEFI compromise. While SMM rootkits operate dynamically within the CPU’s SMM environment they usually use UEFI rootkit technology to embedd malicious code in the firmware layer to achieve persistence.

It also needs to be noted, that SMM and UEFI contain security vulnerabilities (for instance some SMM's contained complete USB stack), which is briefly explained by Ron Minnich in his talk Replace Your Exploit-Ridden Firmware with Linux.

SMM rootkits

SMM rootkits run at the System Management Mode (SMM). SMM operates in a protected memory space called SMRAM (System Management RAM), which is inaccessible to the operating system and most security tools. SMM is the most privileged mode in the modern x86_64 processors. It gives an execution environment with full access to every (physical) resource of the computer. In addition, SMM is a non-pre-emptive mode meaning that it cannot be interrupted by normal hardware/software interrupts. This allows completely stealth code execution from the execution context of the operating system.

SMM has its own private memory space and execution environment which is generally invisible to the outside environment (operating system) and is immune to memory protection mechanisms. Since SMM can directly interact with hardware, it is bypassing the operating system and hypervisors. Therefore SMM rootkits can remain persistent across reboots because they are embedded in firmware or manipulate SMRAM configurations, which are reloaded during system startup. SMM rootkits are often not persistent on its own and usually utilize UEFI compromise to gain persistance.

In 2005 Sherri Sparks and Jamie Butler presented a proof of concept SMM rootkit Shadow Walker, which demonstrated that it was possible to control the view of memory regions seen by the operating system and other processes. Shadow Walker was capable of hiding both its own code and changes to operating system's components and was able to fool both signature and heuristic based scans.

In 2008 Shawn Embleton, Sherri Sparks and Cliff Zou presented their development of a proof-of-concept SMM rootkit (see: SMM rootkits: a new breed of OS independent malware. They implemented a chipset level keylogger and a network backdoor capable of directly interacting with the network card to send logged keystrokes to a remote machine via UDP. The rootkit was able to hide its memory footprint and requires no changes to the existing operating system (i. e. was OS independent).

There is also an interesting proof-of-concept demonstration by Jussi Hietanen how injecting shellcode to a Ring0/Ring3 context that can be achieved from the SMM (described in the article System Management Mode (SMM) rootkit. The rootkit's capability was to infect a Windows usermode process, access the full memory space and persist between OS reinstalls.

BIOS/UEFI rootkits

Another class of Ring -2 rootkits is called BIOS/UEFI rootkits, because they specifically target the BIOS (Basic Input/Output System) or its modern equivalent, UEFI (Unified Extensible Firmware Interface).

As mentioned on the beginning, the first rootkit/bootkit targeting BIOS was CIH (Chernobyl virus) in 1998, and in 2007 a Chinese researcher know under nickname icelord developed proof-of-concept bootkit ICLord Bioskit that has demonstrated that BIOS rootkits were feasible and powerful. Another interesting proof-of-concept firmware rootkit was developed in 2012 by security researcher Jonathan Brossard, which presented Rakshasa, that was able to persist in UEFI/BIOS firmware.

Probably the first known Ring -2 rootkit used in the wild was Mebromi, discovered in 2011, that targeted mostly the computers in China.

Notable research on UEFI rootkits has also been done by Andrea Allievi in 2012, who developed one of the first UEFI bootkit concepts (for Windows 8). Also, in 2013, Sebastien Kaczmarek from Quakerslabs presented Dreamboot), which was also Windows 8 x64 experimental bootkit (however Andrea Allievi later accused Quakerslabs that they stolen the project in the year 2013 without mentioning him.

Rootkit/bootkit technology is often used by government spying tools. One of the fist known examples of that thype of rootkit was used by the Hacking Team group, which infected UEFI/BIOS to keep their malware tool called Remote Control System persistently installed in their targets’ systems. It was first discovered in 2015. (Just a sidenote - Hacking Team Group was trying to sell their malware to the Slovenian police and secret service). Similar tool, FinSpy (also known as FinFisher or Wingbird), is also used for cybersepionage. It is being used at least from 2011, but in 2021 thy employed UEFI bootkit technology to preserve

In 2021 security researcher by Kaspersky discovered MoonBounce rootkit, that injected its malicious code into the SPI flash chip on computer motherboard, targeting UEFI firmware. This means that the rootkit does not leave any traces on a hard drive, and is capable of persisting in the system even if disk is formatted or even replaced. It is linked to Chinese APT41 hacker group and is used for cyberespionage.

Probably the most known Ring -2 rootkit used for cyberespionage in the wild is LoJax. It was discovered by security researchers from ESET in 2018. LoJax embedded itself into UEFI firmware to execute at system startup and was operating in SMM, bypassing OS-level detection. LoJax can persist in the UEFI even if the operating system is reinstalled or its hard drives are replaced. When infection is successful, attackers can use LoJax to track the system's location, remotely access the system and install additional malware on it. The researchers found out, that LoJax was - similar to Hacking Team's malware - used for cyberespionage.

Researchers found out that LoJax targeted organizations in the Balkans and countries in Central and Eastern Europe.

Mac EFI Rootkit

UEFI bootkit concept that could be applied to various operating systems, but those rootkits in the past mostly targeted Windows systems. Not exclusively, because in 2012 a security researcher Loukas K., "snare", presented Mac EFI rootkit (DE MYSTERIIS DOM JOBSIVS:\ MAC EFI ROOTKITS). And in 2017 Wikileaks published information about CIA's Vault 7 hacking tools, containing Mac OS X EFI implant, QuarkMatter (QuarkMatter used an EFI driver stored on the EFI system partition to provide persistence to an arbitrary kernel implant.).

However in 2024 the first UEFI bootkit designed for Linux systems appeared, named Bootkitty. It was a proof of concept tool that disables the kernel’s signature verification feature to load unsigned boot code. But it has to be noted, that Bootkitty was not the first rootkit capable of bypassing UEFI Secure Boot mechanism. The first one was BlackLotus, discovered in 2022, which integrated Secure Boot bypass and is probably the first UEFI rootkit that was "commercially" sold on cybercrime forums. It also implemented several detection evasion features, for instance code obfuscation, anti-virtualization, disabling Windows Defender antivirus software, bypassing User Account Control (UAC), etc.

SecureBoot bypassing - CVE 2024-7344

Ring -2 rootkits mitigation

Ring -2 rootkits are very difficult to detect, because they are firmware-level and they operate independently of the OS. Usually they require firmware reflashing or even physical replacement of the hardware.

However, there are some more practical mitigation techniques, and that is to enable hardware protections like BIOS lock (a security feature designed to prevent unauthorized access when the computer is booting) and SMM lock (hardware protection to prevent unauthorized access to SMRAM). Using Secure Boot to prevent unauthorized firmware or bootloader modifications is also an option, however some rootkits (for instance BlackLotus and Bootkitty) can bypass Secure Boot protection. Another option is also to prevent physical access to the system, because BIOS/UEFI rootkits could also be installed via direct hardware access (this requires special hardware device called BIOS firmware programmer).

Unfortunately, security researchers found several vulnerabilities in closed source BIOS firmware code. One of the main problems is, that Secure Boot and Intel Trusted Boot in traditional BIOS'es are vulnerable to rollback attack. While updating BIOS requires that firmware code is digitally signed with a valid signature, an attacker can install one of the previous official versions of the BIOS firmware (with valid digital signature), but this old version contain security vulnerabilities that could be exploited. There are also known UEFI vulnerabilities that could be exploited (for instance LogoFAIL attack). And in 2024 security researchers found out, that Secure Boot was completely compromised on more than 200 device models sold by Acer, Dell, Gigabyte, Intel, and Supermicro, because someone mistakenly published the cryptographic key that forms the root-of-trust anchor between the hardware device and the firmware that runs on it (so called platform key). This was another warning that BIOS/UEFI code is not under the control of the user, and that the users must trust the vendor in order to trust their systems.

Fortunately there is a solution for that. The open source BIOS/UEFI project Dasharo with so called Heads payload, incorporates several measures to protect against SMM rootkits.

Dasharo ensures that System Management RAM (SMRAM), where SMM code executes, is locked down during the boot process. It has an option to enable SMM BIOS write protection. When this is enabled, it allows only SMM code (the privileged code installed by the firmware in the system memory) to write to BIOS flash. It has implemented BIOS/UEFI lock to lock down the firmware after boot, preventing modifications by unauthorized software and has implemented Secure Boot and Measured Boot to detect unauthorized changes to firmware and SMM code (and also operating system's boot scripts!) and with the help of external hardware security module.

Dasharo with TOTP

Dasharo with Heads payload boot firmware and software suite uses a combination of the Trusted Platform Module (TPM), Time-based One-Time Passwords (TOTP), and HMAC-based One-Time Passwords (HOTP) to provide enhanced system integrity verification and secure authentication. Verification of the system could be done with external hardware security module (small USB device), which verifies system's firmware, kernel, and bootloader, and provides a visual confirmation of the verification status.

Ring -3 rootkits

Ring -3 rootkits operate in the Management Engine (ME) or Platform Controller Hub (PCH) firmware, such as Intel's Management Engine (ME) or AMD's Platform Security Processor (PSP). These are embedded microcontrollers within the CPU chipset, designed for out-of-band system management and security features. Since those rootkits reside in firmware, they are also called firmware rootkits.

While Ring -2 rootkits exploit SMRAM and SMI (System Management Interrupts) vulnerabilities, Ring -3 rootkits relies on firmware in chipset microcontrollers (for instance Management Engine). They can access host memory via DMA (direct memory access), they can directly access network interface, can boot the system from the emulated CDROM and are active even in so called S3 sleep (System Power State S3).

Ring -3 rootkit concept was first presented in 2009 by Alexander Tereshkin and Rafal Wojtczuk in a presentation Introducing Ring -3 Rootkits.

The presented that many Intel vPro chipsets have an independent CPU, access to dedicated DRAM memory, special interface to the network card and execution environment called Management Engine (ME). Also, they found that the Intel Q35 chipset has also a standalone web server. So this chipset is a little computer, that can execute programs independently from the main CPU.

Researchers have shown, that Intel ME and similar technologies could be exploited. Intel Active Management Technology (AMT) is a technology for remote management of computers and is running on the Intel Management Engine.

One of the first research on the security of Intel's AMT was published in Vassilios Ververis' master thesis titled Security Evaluation of Intel’s Active Management Technology in 2010. Ververis described several fundamental security weaknesses in Intel's AMT that allow the attacker to remotely control the target machine (over the Internet or a mesh networking) and enables the installation and control of a botnet on the hardware level.

in 2017 Mark Ermolov and Maxim Goryachy presented a talk titled How to Hack a Turned-Off Computer, or Running Unsigned Code in Intel Management Engine, where they have shown how to execute unsigned code even on a powered-down system by exploiting Intel ME.

The critical vulnerabiliy in Intel ME, CVE 2017-5689 - Manually Exploiting Intel AMT Vulnerability (also see Intel-SA-00086 advisory) from 2017 allowed an attacker to gain system privileges remotely (through the Internet). This vulnerability was also known under nickname "Silent Bob is Silent" and was present in Intel CPUs from 2008 (9 years).

In June 2017, the cybercrime group PLATINUM started to exploit Intel's AMT Serial-over-LAN functionality, which allows them to remotely access computers, bypassing the host operating system and its firewalls. The cybercrime group exploited AMT to perform data exfiltration of stolen documents.

Also, in June 2022, the Wizard Spider ransomware group, who was developing Conti ransomware developed proof-of-concept code targeting Intel firmware to carry out persistent, hard-to-detect attacks.. This should be a serious warning, that the danger is not just the theoretical one, but could be (and probably it is) already exploited in the wild.

Ring -3 rootkits mitigation

Ring -3 rootkits enables attackers to maintain deep, persistent, and stealthy control over a system, beyond the reach of traditional security mechanisms. However, there is a possible mitigation, that is to disable ME functionality (at least partially, because completely disabling destroys the CPU), which can be achieved with the special tool ME Cleaner, developed by Nicholas Corna. However, this is possible only for specific Intel CPUs only and might not work in the future anymore.

There are two methods to disable Intel ME on a computer. The first on is so called HECI (soft-disabling; Host Embedded Controller Interface) method, but it is not fully trusted by the security community and it also only partially disables Intel ME. Another option is HAP disabling method, which sets a special HAP bit that acts like a kill-switch. This method completely turns off Intel ME that can be disabled.

Ring -4 rootkits

Ring -4 rootkits are more theoretical, however there are some proofs that they can be successfully deployed. The term Ring -4 is used to describe emerging threats in the privilege hierarchy below known Ring -3 systems.

Those rootkits would target components even deeper within the system, such as the System on Chip (SoC) or physical hardware devices themselves. So let's take a look to some of the exploits that have already happened.

Exploits on baseband processors

Baseband processor is a special processor inside a mobile device or a computer, that manages all the radio functions. Researcher have shown, that firmware code on baseband processors is vulnerable, and some vulnerabilities are known to be already exploited, usually for cyberespionage.

In 2011, security researcher Ralf-Philipp Weinmann from University of Luxembourg had a presentation titled The Baseband Apocalypse, where he has shown how to set up fake base station, attract nearby phones to join the fake network, where he was then able to inject a malicious firmware update into the baseband processor. His malicious firmware would then switched on the phones’ auto-answer feature, which would have let the researcher to silently dial into the phone and remotely listen to nearby conversations.

In 2019 Android security patches included a fix for two dangerous vulnerabilities called QualPwn (CVE-2019-10538 and CVE-2019-10540), that impacted devices with Qualcomm chips. The attack allows to send a specially-crafted packets to a device's WLAN interface, which would create the so called buffer overflow, that allows the attacker to run code with kernel privileges and code execution on the device.

Also in 2019, the security researchers from AdaptiveMobile Security discovered a Simjacker vulnerability, which allows the attacker to send a special crafted SMS to the victim's device, which instructed the SIM card within the phone to take over the mobile phone and perform sensitive commands. The Simjacker attack was exploited by surveillance companies for cyberespionage operations.

Exploits on network interface cards

Malware could also be run on a processor on a network interface card. This has been shown in 2008 by a security researcher Arrigo Triulzi, who presented Project Maux Mk.II. He developed proof-of-concept hardware rootkit that he stored on a network card, called NIC SSH. The tool allows him to connect directly to compromised network, completely bypassing the operating system (and the firewall) to access the computer. More about the tool can be read in my interview with Triulzi from 2009 (Slovenian version is also available).

NIC SSH tool

Exploits on storage controllers

Storage controllers (especially for hard disks and SDD's) are desirable location for malware attack, because the can directly access or modify the content of the files on a target systems.

In 2013 security researcher Jeroen Domburg published a blog post describing how he developed malware that could be installed on a hard disk controller (article in Slovenian language is also available). That malware was able to modify data when reading from the hard disk. In his case, he demonstrated how to "inject" replacement password to a target system.

The malware activity could be triggered with a certain magic string the modified firmware would look for to the disk. The magic string in that case is a sequence of characters prepared in advance by the attacker, and can be hidden in any file, e-mail message or (in case the compromised server is web server) - URL. When the magic string is received on a target computer, it will be written on a disk, and that means it would be passed through hard disk controller, which would activate the malware.

When the malware is activated, it would modify the replacement password hash in /etc/shadow file (in Linux systems this file stores login passwords of users in hashed format). When the attacker would then try to log into the system with his own (replacement) password, the machine would check this password against the now-modified /etc/shadow and the attacker would be able to login. In that example the target system remains vulnerable even if the operating system is completely reinstalled.

Another research was presented in 2015 by security researcher Marcus Hutchins, who created a firmware rootkit that could be stored on hard drive’s memory chip, and can intercept and modify data being sent back to the host computer. This allows the rootkit to trick the host system into executing arbitrary code (more technical description is also available).

What is interesting is, that the leaked Snowden files revealed, that NSA has also developed a tool called IRATEMONK, that provided software application persistence on desktop and laptop computers by implanting the malware (rootkit) in the hard drive firmware to gain execution through Master Boot Record (MBR) substitution. So this attack is not just theoretical, but has been actively used for cyberespionage.

Other exploits on hardware components

The possibilities for attacks of course does not end here. In the past we have seen various attacks through Firewire interface, installing malware on a Apple Aluminium Keyboard, on a PCI card, etc.

Ring -4 rootkits mitigation

While Ring -4 rootkits are not easy mitigated, there are some effective defences against them - but it depends on a type of a component that rootkit resides on. However, in general the main mitigation approach would be firmware validation (unfortunately most of the firmware for computer components is not open source), and secure supply chain practices.

Exploits on baseband processors could be mitigated by baseband isolation (this is for instance approach used by GrapheneOS mobile operating system), while some other providers provide so called blob-free network cards for computers. That means that the network card’s firmware is considered to be non-modifiable pre-installed firmware that is part of the hardware.

Malware on storage controllers could be defeated by software level full disk encryption, because the rootkit is only effective if the data written or read from the storage disk is in the clear (however full disk encryption should have data integrity algorithm in place, which would detect if malware is corrupting data).

For other hardware components the threat level is different. For instance malware on a keyboard controller could be less problematic if it can not communicate with device's operating system. So keeping the operating system secure, can also help defending against firmware attacks. Physical security is also important. If the attacker does not have physical access to the infected firmware device, they can not exfiltrate data, even they are being recorded. Using hardware components with open source and verified firmware also helps.

As a sidenote, Row hammer attack could be prevented by using ECC RAM, TTR (Target Row Refresh) enabled DDR4 or DDR5 RAM and by use of operating systems or hypervisors that implement memory partitioning or access throttling to complement hardware defences. Incorporating robust mitigation strategies like strict memory isolation and minimal privileges for different components on the operating system level can also help to reduce the impact of any memory-related vulnerabilities, including Row hammer attacks.

Can we go even deeper?

Now, the question remains, can rootkits go even deeper? And what could be possible defence? The answer to the first questios is - unfortunately - yes. (But fortunately, yes, there is possible defence).

Processors with malicious design

One of the early public research on this topic was published in 2008 by Samuel T. King, Joseph Tucek, Anthony Cozzie, Chris Grier, Weihang Jiang and Yuanyuan Zhou in a paper titled Designing and implementing malicious hardware.

They presented so called Illinois Malicious Processor (IMP), that was a proof-of-concept research project demonstrating how malicious functionality can be embedded directly into a processor's design.

The authors have shown, that an attacker can design a hardware to support general purpose attacks. Their proof-of-concept has shown that malicious hardware design can bypass traditional software-based security mechanisms. Illinois Malicious Processor included a hidden operational mode, that was designed to be undetectable by traditional hardware and software monitoring tools. This mode allows the malicious processor to execute hidden instructions and access reserved parts of the cache memory for storing attack payloads.

Processors with malicious manufacturing

Another vector of attack could be malicious manufacturing of the processors. We will show, that these attacks are not just theoretical, since researchers have already proven that they can be carried out in practice.

But first we must understand how the processors are manufactured. The main raw material for processors is silicon, which needs to be first purified to a high degree (99.9999%) then sliced into thin wafers. Silicon is a semiconductor that can switch between conducting and insulating electricity.

In the next step photolithographic and chemical processes are used to create the actual circuit on the silicon wafer. First the layer of photoresist (light-sensitive material) is applied to the silicon wafer, then the circuit is illuminated with UV light through a photomask with a picture of a circuit. During that procedure photoresist that is illuminated through photomask is hardened, while other parts of photoresist could be removed. This creates image of a circuit on the silicon wafer. Exposed silicon is then etched away (chemically or with plasma).

Next step is important, and it is called doping. Doping refers to the process of intentionally introducing impurities into a semiconductor to modify its electrical properties. In that step impurities like phosphorus or boron are added to the silicon to alter its electrical properties and create areas that can conduct or block electricity.

If elements of chemical group V (such as phosphorus), which have more electrons than silicon, are added to the silicon, the result is weakly bound and very mobile electrons. We get an n-type semiconductor. However, if we dope silicon with elements chemical of group III (such as boron), we create a deficit of electrons, so we get p-type semiconductors.

Finally, thin layers of materials like copper, aluminium, or insulating oxides are deposited on the wafer in order to get the multi-layered structure of the chip.

Theoretically doping could be used to introduce hardware vulnerabilities or even inject malware-like behaviour into a chip. For instance, malicious actor could create regions in the chip with altered electrical properties. This might cause the chip to malfunction, leak data, or execute unintended instructions under specific conditions.

Typically the attacker would try to target security-critical features, like random number generators or handling of encryption keys. In that case the attacker would make the generation of cryptographic keys predictable, which would facilitate attacks on encryption.

Another feasible attack is to create subtle data leakage channels, enabling side-channel attacks. Slightly varying power consumption or electromagnetic emissions could then enable the attacker to reconstruct encryption keys or other sensitive data.

Doping could also be used to create hidden circuits that are not part of the original design. That would in fact create hardware Trojan on a chip.

So, is it only theoretical or could be carried out in practice?

Researchers Georg T. Becker, Francesco Regazzoni, Christof Paar, and Wayne P. Burleson have shown that hardware Trojans can be implemented completely undetectably on consumer grade processors (their research is from 2013 and they used Intel's Ivy Bridge processors). With appropriate doping, researchers were able to create malicious changes to the logic gates of transistors on an integrated circuit.

They also pointed out that a similar process is already commercially used to obfuscate the operation of integrated circuits (see the article A Survey on Chip to System Reverse Engineering from 2016 by Mdshahed Enamulquadir, Junlin Chen, Domenic Forte, and Navid Asadizanjani), which suggests that performing this type of attack in practice is not as impossible as it might seem at first glance.

In an article titled Stealthy Dopant-Level Hardware Trojans they demonstrated the creation of two hardware Trojans. First was malformed random number generator implemented in Ivy Bridge processors, and the second one was malicious hardware implementation of the AES encryption functions, so that they were not resistant to a side channel attack any more.

As already mentioned, in the first case, they modified the random number generator (so-called hardware RNG) on Intel's Ivy Bridge processor.

Intel's hardware RNG generates 128-bit random numbers by default. This means that there are 2\^128 possible combinations of a single random number (340282366920938463463374607431768211456 possible combinations).

However, by modifying the processor, the researchers were able to arbitrarily reduce the range of random numbers. For example, from 2\^128 to 2\^32, which returns only 4294967296 possible combinations. These are much easier to guess and subsequently encryption keys generated with that random number generator are much easier to break.

Interestingly, the random number generator modified in this way passed the test of the American National Institute of Standards and Technology (NIST) to determine the randomness of the generated numbers.

In the second case, the researchers implemented the attack on a hardware implementation of an AES encryption chip that is supposed to be resistant to the side channel attacks. It is a special purpose integrated circuit, called iMDPL (Improved Masked Dual-Rail Logic), which they modified so that it changed its power consumption depending on the input data (but only in a way known to the attacker).

The researchers then shown how this could be used to implement leaking of the AES encryption key, while the integrated circuit still performs its task - protecting against the all other side channel attacks. In this case, too, no functional testing can detect a hardware Trojan horse.

Those malicious hardware modifications could not be detected neither by optical inspection (the metal and polysilicon wiring of the modified chip is unchanged), or by performing a BIST test (build-in-self-test, a hardware self-testing process), or by checking with a reference chip, so called gold chip.

What about mitigation?

While malicious design of the processors could be detected at least by third-party verification, doping-based attacks are nearly impossible to identify without highly advanced equipment and specialized knowledge. Again, general mitigation strategies here are to ensure secure supply chains and third-party verification. Unfortunately, those strategies are not really feasible for ordinary users.

On the other hand, ordinary users can use external random number generators for generating unbiased random numbers, and hardware security modules for handling encryption keys, which enables them to mitigate at least some of the risks.

Conclusion

As we have shown, rootkits can hide pretty deep in our systems. The most advanced attacks can usually be performed by very advanced, usually state actors. But we have also shown, that the bar is lowering and advanced rootkits are becoming more easily accessible to non-state actors, like ransomware group Wizard Spider who was developing their own SMM rootkit and PLATINUM cybercrime group who exploited Intel Management Engine on Intel CPU's.

On the other hand, there are several mitigation techniques available, that can help to secure our systems, even though no system could be 100% secure.

Good mitigation strategies are using sandboxing and different isolated virtual environments for different tasks. In case of malware attack, malware would be limited to an isolated environment, and infection would not be able to spread (at least not easily). And if we implement virtual machine level snapshots, compromised environments can be easily returned to a last known good state.

Another line of defence is BIOS/UEFI, that has safeguards against compromising SMM, and has implemented secure boot and measured boot with external hardware security module. This not only reduces the attack surface, but also provides enhanced system integrity verification and secure authentication.

Disabling Management Engine functionality helps to disable Ring -3 rootkit attacks. Malware on storage controllers could be defeated by software level full disk encryption, and for other critical components using hardware with open source and verified firmware (or at least without firmware blobs) also helps. Several attacks could also be prevented by using external random number generators and hardware security modules for handling of secure cryptographic materials.

Also, we should not forget on general mitigation strategies, which are to ensure secure supply chains, third-party verification of hardware components and software and firmware validation.

* * *

Info: you can also download my presentation on this topic.

Also, I developed a working prototype of security enhanced laptop that has implemented most of the rootkit mitigation strategies presented in this article, which means that advanced rootkit protection is possible and accessible to ordinary users.

Varnost sončnih elektrarn in geopolitika

Mon, 26 May 2025 02:00:00 +0200

V sredini maja 2025 so nekateri ameriški mediji objavili novico, da naj bi varnostni strokovnjaki v nekaterih kitajskih razsmernikih in baterijah, ki se uporabljajo v sončnih elektrarnah, našli sumljive naprave, ki bi lahko omogočale prikrito komunikacijo.

Raziskovalci naj bi namreč našli nedokumentirane komunikacijske naprave, vključno z radijskimi sprejemniki in oddajniki, preko katerih bi bilo mogoče na daljavo dostopati do razsmernikov in baterij oz. do sončne elektrarne. Seveda se je takoj pojavil strah, da so proizvajalci, ali pa nekdo drug v dobavni verigi, v ključne komponente sončnih elektrarn vgradili tim. stranka vrata (angl. backdoor), preko katerih bi bilo mogoče izvajati kibernetske napade.

Težava je v tem, da bi tak kibernetski napad na sončno elektrarno v skrajnem primeru lahko povzročil ne samo izpad napajanja ali dvig napetosti, pač pa tudi požar. Zato je take grožnje vsekakor treba jemati resno. Mimogrede, saj se še spomnimo kibernetskih napadov na ukrajinsko energetsko infrastrukturo, kajne?

Žal zaenkrat kaj bolj konkretnih informacij o tem ni, tudi viri, ki so spregovorili za medije so anonimni niti niso želeli izpostaviti konkretnih naprav, zato je neodvisno preverjanje teh informacij oteženo. Kar pa seveda ne pomeni, da grožnje ni potrebno jemati resno.

Izraelski SolarEdge

Kako pa je s tem v Sloveniji?

Podatkov ni veliko, je pa iz letnega poročila Slovenskega portala za fotovoltaiko mogoče razbrati, da je bilo v letu 2022 v Sloveniji 17.278 sončnih elektrarn. Podatka o tržnih deležih posameznih proizvajalcev ni mogoče dobiti, a kot kaže ima v Sloveniji dokaj velik delež sončnih elektrarn proizvajalec SolarEdge. Gre za podjetje, ki je iz Izraela, njihovo opremo pa v Sloveniji prodajajo in vzdržujejo različna slovenska podjetja.

Reklamni letak podjetja navaja: “Podjetje SolarEdge ponuja sisteme porazdeljenega pridobivanja sončne energije in spremljanje delovanja sončne elektrarne. … Ponudba proizvodov SolarEdge vključuje optimizatorje moči, zelo zanesljive fotovoltaične pretvornike ter spletni portal za nadzor sistema in odkrivanje napak na ravni modulov.”

SolarEdge oprema torej o sončnih elektrarnah svojih strank zbira številne podatke, seveda zlasti podatke o proizvedeni in porabljeni električni energiji (podatki o porabi so zanimivi tudi iz stališča varstva osebnih podatkov, sj je z njihovo pomočjo mogoče ugotoviti kdaj so stanivalci na dopustu, koliko oseb živi v objektu, kakšne so njihove dnevne navade, itd.), pa tudi nekaj drugih, bolj tehničnih podatkov.

Dostop do podatkov je mogoč preko aplikacije, kar pomeni, da se podatki pošiljajo v oblak. Oblačna storitev se nahaja na strežniku monitoring.solaredge.com, IP naslov tega strežnika pa se nahaja v Izraelu.

Za dostop do podatkov sicer obstaja še druga možnost, in sicer je dostop do podatkov mogoč tudi lokalno, preko API vmesnika na razsmerniku (tega sicer ne omogočajo vsi SolarEdgovi razsmerniki). A večina običajnih uporabnikov bo najverjetneje uporabila kar aplikacijo oziroma oblačno storitev, saj je to najbolj enostavno, poleg tega pa kaže, da podjetje SolarEdge lokalne dostope skuša omejevati in s tem uporabnike pripraviti do tega, da uporabljajo oblačno storitev.

Kako to vemo? Ker so razvijalci sistema za avtomatizacijo doma HomeAssistant za SolarEdge razvili integracijo SolarEdge Local, ki podatke zbira neposredno na razsmerniku. In v dokumentaciji te integracije piše da lokalen API vmesnik podpirajo samo specifični modeli razsmernikov, podjetje pa je z eno izmed posodobitev strojne programske opreme lokalne API vmesnike preko WiFi povezave na teh razsmernikih tudi začelo onemogočati in je zato integracija nehala delovati oziroma je bilo potrebno razsmernik povezati s kablom.

Skratka. Izraelsko podjetje SolarEdge iz sončnih elektrarn, ki so jih prodali zbirajo številne podatke, ti podatki pa se zbirajo v Izraelu. Hkrati pa podjetje lahko na daljavo, preko interneta, posodobi tudi strojno programsko opremo v sončni elektrarni kar seveda pomeni, da lahko tudi spreminjajo nastavitve.

Bi bilo torej teoretično mogoče na sončne elektrarne na daljavo namestiti zlonamerno programsko kodo, ki bi npr. povzročila dvig izhodne napetosti, vse elektrarne sinhronizirano izključila iz omrežja (in s tem povzročila kolaps elektroenergetskega omrežja, kot se je na primer pred kratkim zgodil v Španiji) ali pa na primer povzročila požar? Ne vemo. A to bi vsekakor morali vedeti.

Seveda ne trdim, da bi takšno zlonamerno kodo želel namestiti proizvajalec. Se pa zastavlja povsem legitimno vprašanje varnosti dobavnih verig, torej ali obstaja možnost, da bi nekdo vdrl v oblačno storitev SolarEdgea in od tam dostopal do podatkov oziroma pripravil zlonamerne posodobitve? Ali pa da to naredi kdo od znotraj? Tudi tega ne vemo, vemo pa, da je solarEdge v preteklosti že imel varnostne ranljivosti, konkretno, aplikacija SolarEdge za Android ni pravilno preverjala digitalnih potrdil, ta varnostna ranljivost pa je omogočala napad s posrednikom (tim. machine-in-the-middle attack). (Opomba: SolarEdge je ranljivost že odpravil.)

Na pomen varnosti dobavnih verig pa vsekakor kaže tudi primer eksplozije pozivnikov Hezbollaha v Libanonu septembra 2024, ko je Izrael članom Hezbollaha podtaknil pozivnike in ročne radijske postaje (angl. walkie-talkie) z eksplozivom, ki so ga potem sprožili na daljavo (kasneje so se pojavila tudi poročila o eksplozijah sončnih elektrarn v Libanonu, čeprav ni neposrednih dokazov, da bi bile povezane z napadom s pozivniki). Kasnejše analize so pokazale, da proizvajalec pozivnikov v napad sploh ni bil vpleten, pač pa je bila kompromitirana dobavna veriga.

Zaključek

Varnost naprav, ki so del kritične infrastrukture je vsekakor pomembna tema. Glede na trenutno geopolitično situacijo pa bi bilo morda potrebno nekoliko bolj poglobljeno raziskati tudi nacionalno-varnostne vidike sončnih elektrarn v Sloveniji.

How I discovered a hidden microphone on a Chinese NanoKVM

Mon, 10 Feb 2025 01:00:00 +0100

NanoKVM is a hardware KVM switch developed by the Chinese company Sipeed. Released last year, it enables remote control of a computer or server using a virtual keyboard, mouse, and monitor. Thanks to its compact size and low price, it quickly gained attention online, especially when the company promised to release its code as open-source. However, as we’ll see, the device has some serious security issues. But first, let’s start with the basics.

How Does the Device Work?

As mentioned, NanoKVM is a KVM switch designed for remotely controlling and managing computers or servers. It features an HDMI port, three USB-C ports, an Ethernet port for network connectivity, and a special serial interface. The package also includes a small accessory for managing the power of an external computer.

Using it is quite simple. First, you connect the device to the internet via an Ethernet cable. Once online, you can access it through a standard web browser (though JavaScript JIT must be enabled). The device supports Tailscale VPN, but with some effort (read: hacking), it can also be configured to work with your own VPN, such as WireGuard or OpenVPN server. Once set up, you can control it from anywhere in the world via your browser.

NanoKVM

The device could be connected to the target computer using an HDMI cable, capturing the video output that would normally be displayed on a monitor. This allows you to view the computer’s screen directly in your browser, essentially acting as a virtual monitor.

Through the USB connection, NanoKVM can also emulate a keyboard, mouse, CD-ROM, USB drive, and even a USB network adapter. This means you can remotely control the computer as if you were physically sitting in front of it - but all through a web interface.

While it functions similarly to remote management tools like RDP or VNC, it has one key difference: there’s no need to install any software on the target computer. Simply plug in the device, and you’re ready to manage it remotely. NanoKVM even allows you to enter the BIOS, and with the additional accessory for power management, you can remotely turn the computer on, off, or reset it.

This makes it incredibly useful - you can power on a machine, access the BIOS, change settings, mount a virtual bootable CD, and install an operating system from scratch, just as if you were physically there. Even if the computer is on the other side of the world.

NanoKVM is also quite affordable. The fully-featured version, which includes all ports, a built-in mini screen, and a case, costs just over €60, while the stripped-down version is around €30. By comparison, a similar RaspberryPi-based device, PiKVM, costs around €400. However, PiKVM is significantly more powerful and reliable and, with a KVM splitter, can manage multiple devices simultaneously.

As mentioned earlier, the announcement of the device caused quite a stir online - not just because of its low price, but also due to its compact size and minimal power consumption. In fact, it can be powered directly from the target computer via a USB cable, which it also uses to simulate a keyboard, mouse, and other USB devices. So you have only one USB cable - in one direction it powers NanoKVM, on the other it helps it to simulate keyboard mouse and other devices on a computer you want to manage.

The device is built on the open-source RISC-V processor architecture, and the manufacturer eventually did release the device’s software under an open-source license at the end of last year. (To be fair, one part of the code remains closed, but the community has already found a suitable open-source replacement, and the manufacturer has promised to open this portion soon.)

However, the real issue is security.

Understandably, the company was eager to release the device as soon as possible. In fact, an early version had a minor hardware design flaw - due to an incorrect circuit cable, the device sometimes failed to detect incoming HDMI signals. As a result, the company recalled and replaced all affected units free of charge. Software development also progressed rapidly, but in such cases, the primary focus is typically on getting basic functionality working, with security taking a backseat.

So, it’s not surprising that the developers made some serious missteps - rushed development often leads to stupid mistakes. But some of the security flaws I discovered in my quick (and by no means exhaustive) review are genuinely concerning.

One of the first security analysis revealed numerous vulnerabilities - and some rather bizarre discoveries. For instance, a security researcher even found an image of a cat embedded in the firmware. While the Sipeed developers acknowledged these issues and relatively quickly fixed at least some of them, many remain unresolved.

NanoKVM

After purchasing the device myself, I ran a quick security audit and found several alarming flaws. The device initially came with a default password, and SSH access was enabled using this preset password. I reported this to the manufacturer, and to their credit, they fixed it relatively quickly. However, many other issues persist.

The user interface is riddled with security flaws - there’s no CSRF protection, no way to invalidate sessions, and more. Worse yet, the encryption key used for password protection (when logging in via a browser) is hardcoded and identical across all devices. This is a major security oversight, as it allows an attacker to easily decrypt passwords. More problematic, this needed to be explained to the developers. Multiple times.

Another concern is the device’s reliance on Chinese DNS servers. And configuring your own (custom) DNS settings is quite complicated. Additionally, the device communicates with Sipeed’s servers in China - downloading not only updates but also the closed-source component mentioned earlier. For this closed source component it needs to verify an identification key, which is stored on the device in plain text. Alarmingly, the device does not verify the integrity of software updates, includes a strange version of the WireGuard VPN application (which does not work on some networks), and runs a heavily stripped-down version of Linux that lacks systemd and apt. And these are just a few of the issues.

Were these problems simply oversights? Possibly. But what additionally raised red flags was the presence of tcpdump and aircrack - tools commonly used for network packet analysis and wireless security testing. While these are useful for debugging and development, they are also hacking tools that can be dangerously exploited. I can understand why developers might use them during testing, but they have absolutely no place on a production version of the device.

A Hidden Microphone

And then I discovered something even more alarming - a tiny built-in microphone that isn’t clearly mentioned in the official documentation. It’s a miniature SMD component, measuring just 2 x 1 mm, yet capable of recording surprisingly high-quality audio.

What’s even more concerning is that all the necessary recording tools are already installed on the device! By simply connecting via SSH (remember, the device initially used default passwords!), I was able to start recording audio using the amixer and arecord tools. Once recorded, the audio file could be easily copied to another computer. With a little extra effort, it would even be possible to stream the audio over a network, allowing an attacker to eavesdrop in real time.

Hidden Microphone in NanoKVM

Physically removing the microphone is possible, but it’s not exactly straightforward. As seen in the image, disassembling the device is tricky, and due to the microphone’s tiny size, you’d need a microscope or magnifying glass to properly desolder it.

To summarize: the device is riddled with security flaws, originally shipped with default passwords, communicates with servers in China, comes preinstalled with hacking tools, and even includes a built-in microphone - fully equipped for recording audio - without clear mention of it in the documentation. Could it get any worse?

I am pretty sure these issues stem from extreme negligence and rushed development rather than malicious intent. However, that doesn’t make them any less concerning.

That said, these findings don’t mean the device is entirely unusable.

Since the device is open-source, it’s entirely possible to install custom software on it. In fact, one user has already begun porting his own Linux distribution - starting with Debian and later switching to Ubuntu. With a bit of luck, this work could soon lead to official Ubuntu Linux support for the device.

This custom Linux version already runs the manufacturer’s modified KVM code, and within a few months, we’ll likely have a fully independent and significantly more secure software alternative. The only minor inconvenience is that installing it requires physically opening the device, removing the built-in SD card, and flashing the new software onto it. However, in reality, this process isn’t too complicated.

And while you’re at it, you might also want to remove the microphone… or, if you prefer, connect a speaker. In my test, I used an 8-ohm, 0.5W speaker, which produced surprisingly good sound - essentially turning the NanoKVM into a tiny music player. Actually, the idea is not so bad, because PiKVM also included 2-way audio support for their devices end of last year.

Basic board with speaker

Final Thoughts

All this of course raises an interesting question: How many similar devices with hidden functionalities might be lurking in your home, just waiting to be discovered? And not just those of Chinese origin. Are you absolutely sure none of them have built-in miniature microphones or cameras?

You can start with your iPhone - last year Apple has agreed to pay $95 million to settle a lawsuit alleging that its voice assistant Siri recorded private conversations. They shared the data with third parties and used them for targeted ads. “Unintentionally”, of course! Yes, that Apple, that cares about your privacy so much.

And Google is doing the same. They are facing a similar lawsuit over their voice assistant, but the litigation likely won’t be settled until this fall. So no, small Chinese startup companies are not the only problem. And if you are worried about Chinese companies obligations towards Chinese government, let’s not forget that U.S. companies also have obligations to cooperate with U.S. government. While Apple is publicly claiming they do not cooperate with FBI and other U. S. agencies (because thy care about your privacy so much), some media revealed that Apple was holding a series secretive Global Police Summit at its Cupertino headquarters where they taught police how to use their products for surveillance and policing work. And as one of the police officers pointed out - he has “never been part of an engagement that was so collaborative.”. Yep.

P.S. How to Record Audio on NanoKVM

If you want to test the built-in microphone yourself, simply connect to the device via SSH and run the following two commands:

amixer -Dhw:0 cset name='ADC Capture Volume 20' (this sets microphone sensitivity to high)
arecord -Dhw:0,0 -d 3 -r 48000 -f S16_LE -t wav test.wav & > /dev/null & (this will capture the sound to a file named test.wav)

Now, speak or sing (perhaps the Chinese national anthem?) near the device, then press Ctrl + C, copy the test.wav file to your computer, and listen to the recording.

Kako sem na mini kitajski napravi odkril skriti mikrofon

Fri, 07 Feb 2025 01:00:00 +0100

Lansko leto je kitajsko podjetje Sipeed izdalo zanimivo napravico za oddaljeno upravljanje računalnikov in strežnikov, ki sliši na ime NanoKVM. Gre za tim. KVM stikalo (angl. KVM switch), torej fizično napravo, ki omogoča oddaljeno upravljanje računalnika oz. strežnika preko virtualne tipkovnice, miške in monitorja.

Kako deluje?

Napravica ima en HDMI, tri USB-C priključke, Ethernet priključek za omrežni kabel in posebno “letvico”, kamor priključimo dodaten priložen vmesnik za upravljanje napajanja zunanjega računalnika. Kako zadeva deluje? Zelo preprosto. Napravico preko omrežnega Ethernet kabla povežemo na internet in se potem lahko nanjo s pomočjo navadnega spletnega brskalnika povežemo od koderkoli (je pa v brskalniku potrebno omogočiti JavaScript JIT). Vgrajena je sicer že tudi podpora za Tailscale VPN, a z malo truda oz. hekanja jo lahko povežemo tudi na svoj VPN (Wireguard ali OpenVPN). Torej lahko do nje preprosto dostopamo preko interneta od kjerkoli na svetu.

NanoKVM

Napravico nato na računalnik, ki ga želimo upravljati povežemo preko HDMI kabla, naprava pa nato zajema sliko (ki bi se sicer prikazovala na monitorju) in to sliko lahko potem vidimo v brskalniku. Povezava preko USB na ciljnem računalniku simulira tipkovnico, miško, CD-ROM/USB ključek ter celo USB omrežno kartico. S tem naprava omogoča oddaljeno upravljanje računalnika kot bi sedeli za njim, v resnici pa računalnik upravljamo kar preko brskalnika preko interneta. Za razliko od aplikacij za oddaljeno upravljanje računalnika tukaj na ciljni računalnik ni potrebno nameščati ničesar, dovolj je, da nanj priključimo to napravico. Seveda pa s pomočjo te naprave lahko vstopimo tudi v BIOS ciljnega računalnika, z dodatnim vmesnikom, ki ga priključimo na prej omenjeno “letvico” pa oddaljeni računalnik lahko tudi ugasnemo, prižgemo ali resetiramo.

Uporabno, saj na ta način lahko računalnik prižgemo, gremo v BIOS in tam spreminjamo nastavitve, nato pa vanj virtualno vstavimo zagonski CD in celo namestimo operacijski sistem. Pa čeprav se računalnik nahaja na drugem koncu sveta.

Napravica je precej poceni - razširjena različica, ki ima vse priključke, vgrajen mini zaslonček in prikupno ohišje stane nekaj čez 60 EUR, oskubljena različica pa okrog 30 EUR. Za primerjavo, podobna naprava ki temelji na RaspberryPi in se imenuje PiKVM, stane okrog 400 EUR, je pa res, da je tista naprava precej bolj zmogljiva in zanesljiva, preko KVM razdelillca pa omogoča tudi upravljanje več naprav hkrati.

Kaj pa varnost?

Najava naprave je na spletu povzročila precej navdušenja, ne samo zaradi nizke cene, pač pa tudi zato, ker je res majhna in porabi minimalno energije (napaja se lahko kar iz ciljnega računalnika preko USB kabla s katerim v drugo smer simulira tipkovnico, miško in ostale USB naprave). Zgrajena je na odprtokodni RISC-V procesorski arhitekturi, proizvajalec pa je obljubil, da bo programsko kodo naprave odprl oziroma jo izdal pod odprtokodno licenco, kar se je konec lanskega leta tudi res zgodilo. No, en del sicer še ni povsem odprt, a je skupnost že našla ustrezno odprtokodno nadomestilo, pa tudi proizvajalec je obljubil, da bodo odprli tudi ta del kode.

Težava pa je varnost.

Proizvajalec je seveda imel interes napravico čim prej dati na trg in ena izmed prvih različic je celo imela manjšo napako v strojni zasnovi (zaradi uporabe napačnega kabla na vezju naprava včasih ni zaznala vhodnega HDMI signala) zato so vse napravice odpoklicali in jih brezplačno zamenjali. Tudi razvoj programske opreme je bil precej intenziven in jasno je, da je podjetju v takem primeru v fokusu predvsem razvoj osnovne funkcionalnosti, varnost pa je na drugem mestu.

Zato ne preseneča, da so bili razvijalci pri razvoju precej malomarni, kar je seveda posledica hitenja. A nekatere ugotovitve mojega hitrega (in vsekakor ne celovitega) varnostnega pregleda so resnično zaskrbljujoče.

Že eden prvih hitrih varnostnih pregledov je odkril številne pomanjkljivosti in celo prav bizarne zadeve - med drugim je varnostni raziskovalec na strojni programski opremi naprave našel celo sliko mačke. Razvijalci podjetja Sipeed so te napake priznali in jih - vsaj nekatere - tudi relativno hitro odpravili. A še zdaleč ne vseh.

Odprt NanoKVM

Napravico sem pred kratkim kupil tudi sam in tudi moj hitri pregled je odkril številne pomanjkljivosti. Naprava je na začetku imela nastavljeno privzeto geslo, z enakim geslom so bile omogočene tudi ssh povezave na napravo. Proizvajalca sem o tem obvestil in so zadevo relativno hitro popravili. A številne napake so ostale.

Tako ima uporabniški vmesnik še vedno cel kup pomanjkljivosti - ni CSFR zaščite, ni mogoče invalidirati seje, in tako dalje. Šifrirni ključ za zaščito gesel (ko se preko brskalnika prijavimo na napravo) je kar vgrajen (angl. hardcoded) in za vse naprave enak. Kar absolutno nima smisla, saj napadalec s pomočjo tega ključa geslo lahko povsem preprosto dešifrira. Težava je, da je bilo to potrebno razvijalcem posebej razložiti. In to večkrat.

Osebno me je zmotilo, da naprava uporablja neke kitajske DNS strežnike - nastavitev lastnih DNS strežnikov pa je precej zapletena. Prav tako naprava prenaša podatke iz kitajskih strežnikov podjetja (v bistvu iz teh strežnikov prenaša zaenkrat še edino zaprtokodno komponento, pri čemer pa preverja identifikacijski ključ naprave, ki je sicer na napravi shranjen v nešifrirani obliki). Naprava ne preverja integritete posodobitev, ima nameščeno neko čudno različico Wireguard VPN aplikacije, na njej teče precej oskubljena različica Linuxa brez systemd in apt komponente, najde pa se še precej podobnih cvetk. Porodne težave?

Morda. A na napravi sta nameščeni orodji tcpdump in aircrack, ki se sicer uporabljata za razhroščevanje in pomoč pri razvoju, vseeno pa gre za hekerski orodji, ki ju je mogoče nevarno zlorabiti. Sicer povsem razumem zakaj razvijalci ti dve orodji uporabljajo, a v produkcijski različici naprave resnično nimata kaj iskati.

Skriti mikrofon

Potem pa sem na napravici odkril še mini mikrofon, ki ga dokumentacija ne omenja jasno. Gre za miniaturno SMD komponento, velikosti 2 x 1 mm, ki pa dejansko omogoča snemanje precej kakovostnega zvoka. In kar je dodatno zaskrbljujoče je to, da so na napravi že nameščena vsa orodja za snemanje! To omogoča, da se na napravico povežemo preko ssh (saj se spomnite, da sem na začetku omenil, da je naprava uporabljala privzeta gesla!), nato pa s pomočjo orodij amixer in arecord preprosto zaženemo snemanje zvoka. Datoteko s posnetkom nato preprosto skopiramo na svoj računalnik. Z malo truda pa bi bilo seveda mogoče implementirati tudi oddajanje zvoka preko omrežja, kar bi napadalcu seveda omogočalo prisluškovanje v realnem času.

Skriti mikrofon v NanoKVM

Mikrofon bi bilo sicer mogoče odstraniti, a je za to napravico potrebno fizično razdreti in mikrofon nato odlotati iz nje. Kot je razvidno iz slike to ni povsem enostavno, poleg tega si je treba pri lotanju pomagati z mikroskopom oz. povečevalnim steklom.

Skratka, če povzamemo. Naprava ima kup varnostnih pomanjkljivosti, vsaj na začetku je uporabljala privzeta gesla, komunicira s strežniki na Kitajskem, ima nameščena hekerska orodja in vgrajen mikrofon z vso programsko podporo za snemanje zvoka, ki ga pa dokumentacija ne omenja jasno! Je lahko še slabše?

Sicer sem prepričan, da je to posledica predvsem skrajne malomarnosti in hitenja pri razvoju in ne zlonamernosti, a vseeno vse skupaj pušča precej slab priokus.

Po drugi strani pa te ugotovitve nikakor ne pomenijo, da naprava ni uporabna.

Ker je zasnova naprave odprta je seveda nanjo mogoče namestiti svojo programsko opremo. Eden izmed uporabnikov je tako začel na napravo prenašati svojo različico Linuxa (najprej Debian, zdaj je preklopil na Ubuntu), in z malo sreče bo ta koda kmalu postala osnova za to, da bo Ubuntu Linux tudi uradno podprt na teh napravah. Na tej različici Linuxa že teče modificirana KVM koda proizvajalca in verjetno bomo v nekaj mesecih že dobili popolnoma neodvisno programsko opremo, ki bo tudi bistveno bolj varna. Manjša težava je, da bo za namestitev te programske opreme napravo treba fizično odpreti, ven vzeti vgrajeno SD kartico in nanjo zapisati to alternativno programsko kodo. A v resnici to ni preveč zapleteno. Lahko pa ob tem še odlotamo mikrofon… ali pa gor priključimo zvočnik. Sam sem za test uporabil 8 Ohmski, 0.5 W zvočnik, ki zmore predvajati kar kvaliteten zvok in tako dobil mini predvajalnik glasbe. :)

Osnovna plošča z zvočnikom

Za konec pa se je dobro vprašati koliko podobnih napravic s skritimi funkcionalnostmi bi se s podobnim pregledom še našlo v vaših domovih? In to ne nujno samo kitajskega izvora. Ste prepričani, da nobena od njih nima vgrajenih miniaturnih mikrofonov ali kamer?

P. S. Za snemanje se je treba na napravico povezati preko ssh in zagnati naslednja dva ukaza:

amixer -Dhw:0 cset name='ADC Capture Volume 20' (s tem nastavimo visoko občutljivost mikrofona)
arecord -Dhw:0,0 -d 3 -r 48000 -f S16_LE -t wav test.wav & > /dev/null &

Zdaj lahko poleg napravice govorite ali prepevate (na primer kitajsko himno), nato pa pritisnete ctrl-c in datoteko test.wav skopirate na svoj računalnik kjer jo lahko poslušate.

Signal kontejner

Sun, 10 Nov 2024 01:00:00 +0100

Signal je aplikacija za varno in zasebno sporočanje, ki je brezplačna, odprtokodna in enostavna za uporabo. Uporablja močno šifriranje od začetne do končne točke (anlg. end-to-end), uporabljajo pa jo številni aktivisti, novinarji, žvižgači, pa tudi državni uradniki in poslovneži. Skratka vsi, ki cenijo svojo zasebnost. Signal teče na mobilnih telefonih z operacijskim sistemom Android in iOS, pa tudi na namiznih računalnikih (Linux, Windows, MacOS) - pri čemer je namizna različica narejena tako, da jo povežemo s svojo mobilno različico Signala. To nam omogoča, da lahko vse funkcije Signala uporabljamo tako na telefonu kot na namiznem računalniku, prav tako se vsa sporočila, kontakti, itd. sinhronizirajo med obema napravama. Vse lepo in prav, a Signal je (žal) vezan na telefonsko številko in praviloma lahko na enem telefonu poganjate samo eno kopijo Signala, enako pa velja tudi za namizni računalnik. Bi se dalo to omejitev zaobiti? Vsekakor, a za to je potreben manjši “hack”. Kakšen, preberite v nadaljevanju.

Poganjanje več različic Signala na telefonu

Poganjanje več različic Signala na telefonu je zelo enostavno - a samo, če uporabljate GrapheneOS. GrapheneOS je operacijski sistem za mobilne telefone, ki ima vgrajene številne varnostne mehanizme, poleg tega pa je zasnovan na način, da kar najbolje skrbi za zasebnost uporabnika. Je odprtokoden, visoko kompatibilen z Androidom, vendar s številnimi izboljšavami, ki izredno otežujejo oz. kar onemogočajo tako forenzični zaseg podatkov, kot tudi napade z vohunsko programsko opremo tipa Pegasus in Predator.

GrapheneOS omogoča uporabo več profilov (do 31 + uporabniški profil tim. gosta), ki so med seboj popolnoma ločeni. To pomeni, da lahko v različnih profilih nameščate različne aplikacije, imate povsem različen seznam stikov, na enem profilu uporabljate en VPN, na drugem drugega ali pa sploh nobenega, itd.

Rešitev je torej preprosta. V mobilnem telefonu z GrapheneOS si odpremo nov profil, tam namestimo novo kopijo Signala, v telefon vstavimo drugo SIM kartico in Signal povežemo z novo številko.

Ko je telefonska številka registrirana, lahko SIM kartico odstranimo in v telefon vstavimo staro. Signal namreč za komunikacijo uporablja samo prenos podatkov (seveda lahko telefon uporabljamo tudi brez SIM kartice, samo na WiFi-ju). Na telefonu imamo sedaj nameščeni dve različici Signala, vezani na dve različni telefonski številki, in iz obeh različic lahko pošiljamo sporočila (tudi med njima dvema!) ali kličemo.

Čeprav so profili ločeni, pa lahko nastavimo, da obvestila iz aplikacije Signal na drugem profilu, dobivamo tudi ko smo prijavljeni v prvi profil. Le za pisanje sporočil ali vzpostavljanje klicev, bo treba preklopiti v pravi profil na telefonu.

Preprosto, kajne?

Poganjanje več različic Signala na računalniku

Zdaj bi si seveda nekaj podobnega želeli tudi na računalniku. Skratka, želeli bi si možnosti, da na računalniku, pod enim uporabnikom poganjamo dve različni instanci Signala (vsaka vezana na svojo telefonsko številko).

No, tukaj je zadeva na prvi pogled malenkost bolj zapletena, a se s pomočjo virtualizacije da težavo elegantno rešiti. Seveda na računalniku samo za Signal ne bomo poganjali kar celega novega virtualnega stroja, lahko pa uporabimo tim. kontejner.

V operacijskem sistemu Linux najprej namestimo aplikacijo systemd-container (v sistemih Ubuntu je sicer že privzeto nameščena).

Na gostiteljskem računalniku omogočimo tim neprivilegirane uporabniške imenske prostore (angl. unprivileged user namespaces), in sicer z ukazom sudo nano /etc/sysctl.d/nspawn.conf, nato pa v datoteko vpišemo:

kernel.unprivileged_userns_clone=1

Zdaj je SistemD storitev treba ponovno zagnati:

sudo systemctl daemon-reload
sudo systemctl restart systemd-sysctl.service
sudo systemctl status systemd-sysctl.service

…nato pa lahko namestimo Debootstrap: sudo apt install debootstrap.

Zdaj ustvarimo nov kontejner, v katerega bomo namestili operacijski sistem Debian (in sicer različico stable) - v resnici bo nameščena le minimalno zahtevana koda operacijskega sistema:

sudo debootstrap --include=systemd,dbus stable

Dobimo približno takle izpis:

/var/lib/machines/debian
I: Keyring file not available at /usr/share/keyrings/debian-archive-keyring.gpg; switching to https mirror https://deb.debian.org/debian
I: Retrieving InRelease 
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on https://deb.debian.org/debian...
I: Retrieving adduser 3.134
I: Validating adduser 3.134
...
...
...
I: Configuring tasksel-data...
I: Configuring libc-bin...
I: Configuring ca-certificates...
I: Base system installed successfully.

Zdaj je kontejner z operacijskim sistemom Debian nameščen. Zato ga zaženemo in nastavimo geslo korenskega uporabnika :

sudo systemd-nspawn -D /var/lib/machines/debian -U --machine debian

Dobimo izpis:

Spawning container debian on /var/lib/machines/debian.
Press Ctrl-] three times within 1s to kill container.
Selected user namespace base 1766326272 and range 65536.
root@debian:~#

Zdaj se preko navideznega terminala povežemo v operacijski sistem in vpišemo naslednja dva ukaza:

passwd
printf 'pts/0\npts/1\n' >> /etc/securetty 

S prvim ukazom nastavimo geslo, drugi pa omogoči povezavo preko tim. lokalnega terminala (TTY). Na koncu vpišemo ukaz logout in se odjavimo nazaj na gostiteljski računalnik.

Zdaj je treba nastaviti omrežje, ki ga bo uporabljal kontejner. Najbolj enostavno je, če uporabimo kar omrežje gostiteljskega računalnika. Vpišemo naslednja dva ukaza:

sudo mkdir /etc/systemd/nspawn
sudo nano /etc/systemd/nspawn/debian.nspawn

V datoteko vnesemo:

[Network]
VirtualEthernet=no

Zdaj kontejner ponovno zaženemo z ukazom sudo systemctl start systemd-nspawn@debian ali pa še enostavneje - machinectl start debian.

Seznam zagnanih kontejnerjev si lahko tudi ogledamo:

machinectl list
MACHINE CLASS     SERVICE        OS     VERSION ADDRESSES
debian  container systemd-nspawn debian 12      -        

1 machines listed.

Oziroma se povežemo v ta virtualni kontejner: machinectl login debian. Dobimo izpis:

Connected to machine debian. Press ^] three times within 1s to exit session.

Debian GNU/Linux 12 cryptopia pts/1

cryptopia login: root
Password: 

Na izpisu se vidi, da smo se povezali z uporabnikom root in geslom, ki smo ga prej nastavili.

Zdaj v tem kontejnerju namestimo Signal Desktop.

apt update
apt install wget gpg

wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg

echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main' | tee /etc/apt/sources.list.d/signal-xenial.list

apt update
apt install --no-install-recommends signal-desktop
halt

Z zadnjim ukazom kontejner zaustavimo. Zdaj je v njem nameščena sveža različica aplikacije Signal Desktop.

Mimogrede, če želimo, lahko kontejner preimenujemo v bolj prijazno ime, npr. sudo machinectl rename debian debian-signal. Seveda pa bomo potem isto ime morali uporabljati tudi za zagon kontejnerja (torej, machinectl login debian-signal).

Zdaj naredimo skripto, s katero bomo kontejner pognali in v njem zagnali Signal Desktop na način, da bomo njegovo okno videli na namizju gostiteljskega računalnika:

Ustvarimo datoteko nano /opt/runContainerSignal.sh (ki jo shranimo npr. v mapo /opt), vsebina datoteke pa je naslednja:

#!/bin/sh
xhost +local:
pkexec systemd-nspawn --setenv=DISPLAY=:0 \
                      --bind-ro=/tmp/.X11-unix/  \
                      --private-users=pick \
                      --private-users-chown \
                      -D /var/lib/machines/debian-signal/ \
                      --as-pid2 signal-desktop --no-sandbox
xhost -local:

S prvim xhost ukazom omogočimo povezovanje na naš zaslon, vendar samo iz lokalnega računalnika, drugi xhost ukaz pa bo te povezave (na zaslon) spet blokiral). Nastavimo, da je skripta izvršljiva (chmod +x runContainerSignal.sh), in to je to.

Dve ikoni aplikacije Signal Desktop

No, ne še čisto, saj bi skripto morali zaganjati v terminalu, veliko bolj udoben pa je zagon s klikom na ikono.

Naredimo torej .desktop datoteko: nano ~/.local/share/applications/runContainerSignal.desktop. Vanjo zapišemo naslednjo vsebino:

[Desktop Entry]
Type=Application
Name=Signal Container
Exec=/opt/runContainerSignal.sh
Icon=security-high
Terminal=false
Comment=Run Signal Container

…namesto ikone security-high, lahko uporabimo kakšno drugo, na primer:

Icon=/usr/share/icons/Yaru/scalable/status/security-high-symbolic.svg

Pojasnilo: skripta je shranjena v ~/.local/share/applications/, torej je dostopa samo specifičnemu uporabniku in ne vsem uporabnikom na računalniku.

Zdaj nastavimo, da je .desktop datoteka izvršljiva: chmod +x ~/.local/share/applications/runContainerSignal.desktop

Osvežimo tim. namizne vnose (angl. Desktop Entries): update-desktop-database ~/.local/share/applications/, in to je to!

Dve instanci aplikacije Signal Desktop

Ko bomo v iskalnik aplikacij vpisali “Signal Container”, se bo prikazala ikona aplikacije, sklikom na njo pa bomo zagnali Signal v kontejnerju (bo pa za zagon potrebno vpisati geslo).

Zdaj ta Signal Desktop samo še povežemo s kopijo Signala na telefonu in že lahko na računalniku uporabljamo dve kopiji aplikacije Signal Desktop.

Kaj pa…?

Žal pa v opisanem primeru ne deluje dostop do kamere in zvoka. Klice bomo torej še vedno morali opravljati iz telefona.

Izkaže se namreč, da je povezava kontejnerja z zvočnim sistemom PipeWire in kamero gostiteljskega računalnika neverjetno zapletena (vsaj v moji postavitvi sistema). Če imate namig kako zadevo rešiti, pa mi seveda lahko sporočite. :)

Varnost in zanesljivost aplikacije Telegram

Sun, 25 Aug 2024 02:00:00 +0200

Včeraj zvečer je odjeknila novica, da so v Franciji aretirali ustanovitelja in izvršnega direktorja Telegrama Pavla Durova. Francoske oblasti mu očitajo, da ni sprejel zadostnih ukrepov za omejevanje kriminalnega delovanja na platformi, zaradi česar so kriminalci Telegram uporabljali za pranje denarja, trgovino z drogami in deljenje pedofilskih vsebin.

Ob tem se je pojavilo precej špekulacij, da je ustanovitelj Telegrama tarča zato, ker je Telegram “preveč” varen. Zanimivo je, da Durov že dlje časa vodi kampanjo proti Signalu, kjer Signal skuša predstaviti kot ne-varen, Telegram pa kot edino pravo aplikacijo za varno komuniciranje.

Precej intenzivno kampanjo proti Signalu je Durov nazadnje zagnal maja letos, na kar je v svojem zapisu na Twitterju opozoril tudi Matthew Green, ki sicer velja za enega najbolj znanih kriptografov in varnostnih strokovnjakov. Durov je takrat skušal aplikacijo Signal prikazati kot varnostno nezanesljivo, pri širjenju teh dezinformacij pa je pomagal tudi Elon Musk.

Matthew Green je Twitterju lepo razložil, da je Signalov kriptografski protokol superioren in dejansko eden najboljših na svetu. Aplikacija Signal je odprtokodna, uporabniško zelo prijazna, kriptografsko varna, poleg tega pa še zelo ščiti zasebnost. Po novem pa tudi povečuje anonimnost svojih uporabnikov, saj omogoča anonimne identitete.

Telegram pa je po drugi strani varnostno precej šibak, privzeto ne omogoča šifriranja, več varnostnih raziskovalcev pa je odkrilo, da je bilo uporabnike Telegrama mogoče dokaj preprosto geolocirati. Varnostni raziskovalci so v Telegramovem šifrirnem protokolu odkrili tudi zanimivo napako, ki je varnost šifriranja močno zmanjšala. Napaka je zanimiva predvsem zato, ker se zdi, da je precej verjetno namerna. Napaka je bila sicer kasneje odpravljena, slab priokus pa ostaja.

Durov je v javnih nastopih večkrat poudarjal, da naj bi bil Telegram trn v peti ruskim tajnim službam (Durov je namreč državljan Rusije in Telegram so najprej razvijali v Rusiji).

Pa vendar - aplikacija Signal je v Rusiji blokirana, Telegram pa ne. Še več, Oleg Matveychev, znan tudi kot “kremeljski propagandist”, sicer pa član ruske Dume in namestnik predsednika parlamentarnega odbora za informacijsko politiko, informacijsko tehnologijo in komunikacije, je marca 2022 izrecno izjavil, da v Rusiji Telegrama ne bodo blokirali, saj da je “politično nevtralen”. Le zakaj?

Za strokovnjake iz področja varnosti so trditve Durova (in Muska) popolnoma absurdne. Žal pa take kampanje širjenja dezinformacij običajne uporabnike lahko zmedejo. Zakaj se torej znova in znova pojavljajo?

Najverjetneje je cilj teh kampanj prepričati aktiviste, da prenehajo uporabljati varen Signal in začnejo uporabljati ne-varen Telegram. Zakaj, si seveda lahko le mislimo.

In ravno zato je pomembno, da se zavajanja Telegrama javno izpostavi.

Povezava Mikrotik usmerjevalnika v Wireguard omrežje

Wed, 21 Aug 2024 02:00:00 +0200

WireGuard je sodoben in hiter VPN, ki je bil tudi formalno verificiran, kar pomeni, da za Wireguard protokol obstaja matematični dokaz, da je varen. V tokratnem prispevku si bomo ogledali kako Mikrotik usmerjevalnik povežemo v Wireguard omrežje, a ne kot strežnik, pač pa kot tim. vrstnika (angl. peer).

Mikrotik je blagovna znamka zmogljivih in cenovno dostopnih omrežnih naprav, na katerih teče poseben operacijski sistem RouterOS. Mikrotik omrežna oprema je na voljo tako za domača omrežja (domači usmerjevalniki, WiFi dostopne točke,…), kot tudi za omrežja manjših ali večjih podjetij, na voljo pa so tudi zelo zmogljivi izdelki, ki jih uporabljajo tudi nekateri ponudniki dostopa do interneta.

A najprej vprašanje, zakaj bi Mikrotik usmerjevalnik sploh želeli povezati v Wireguard (VPN) omrežje kot vrstnika? En scenarij uporabe je, da želimo oddaljeno dostopati do njegovega administrativnega vmesnika. To bi sicer lahko naredili tudi preko njegovega javnega IP naslova, a težava je, če ta ni stalen (no, to je sicer rešljivo), predvsem pa, če je usmerjevalnik “skrit” za NAT-om, torej ni neposredno dostopen iz interneta. Rešitev je torej na dlani - usmerjevalnik nastavimo tako, da se bo sam povezal na VPN strežnik, nato pa bomo do njega dostopali preko njegovega VPN naslova.

Na Mikrotik se lahko povežemo preko spletnega vmesnika, preko aplikacije Winbox ali preko SSH povezave. A najprej nekaj predpriprave.

Če želimo na Mikrotik napravah uporabljati Wireguard, moramo imeti nameščen RouterOS v7 ali novejši. Ker bomo Mikrotik povezali v Wireguard omrežje, potrebujemo Wireguard strežnik - predpostavljamo, da ga že imate postavljenega. Iz njega bomo potrebovali:

zunanji IP naslov in vrata kamor se bodo tim. vrstniki povezovali;
njegov javni ključ;
PSK ključ Mikrotik odjemalca (ki ga ustvarimo kar na Wireguard strežniku);
razmislimo pa tudi kateri VPN IP naslov bomo dodelili Mikrotiku.

Zdaj pa se vrnimo na Mikrotik. V spletnem vmesniku ali Winboxu odpremo konzolo (če se povežemo preko SSH samodejno vstopimo vanjo) in najprej ustvarimo nov omrežni vmesnik z menom wireguard1, ki posluša na nekih vratih (nastavimo lahko katerakoli, ki niso zasedena, v našem primeru 51821):

/interface/wireguard/add listen-port=51821 name=wireguard1

Če želimo videti seznam Wireguard omrežnih vmesnikov, vpišemo ukaz:

/interface/wireguard/print

Dobimo izpis, kjer vidimo tudi zasebni in javni ključ Mikrotik vrstnika:

Flags: X - disabled; R - running 
 0  R name="wireguard1" mtu=1420 listen-port=51820 private-key="zasebni-kljuc-Mikrotik-vrstnika" public-key="javni-kljuc-Mikrotik-vrstnika"

Opomba, če bi želeli Wireguard vmesnik z imenom wireguard1 odstraniti, to storimo z ukazom: /interface/wireguard/remove wireguard1.

Zdaj dodamo povezavo do Wireguard strežnika:

/interface/wireguard/peers add allowed-address=10.10.7.0/24 endpoint-address=xx.xx.xx.xx endpoint-port=51194 interface=wireguard1 persistent-keepalive=5s public-key="javni-kljuc-wg-streznika" preshared-key="PSK-kljuc-Mikrotik-vrstnika

Razlaga:

allowed-address: tukaj vpišemo Wireguard podomrežje (iz Wireguard strežnika), v našem primeru je to 10.10.7.0/24;
endpoint-address: javni IP naslov Wireguard strežnika;
endpoint-port: vrata, kamor se povezujejo Wireguard vrstniki (privzeto so 51194);
interface: Wireguard vmensik za katerega veljano nastavitve (v našem primeru wireguard1);
persistent-keepalive: določimo, da bo odjemalec do strežnika ohranjal aktivno povezavo tako, da bo vsakih 5 sekund (5s) na strežnik poslal ping;
public-key: javni ključ Wireguard strežnika;
preshared-key: PSK ključ Mikrotik vrstnika.

Seznam vrstnikov lahko tudi pogledamo (v našem primeru imamo seveda samo enega):

/interface/wireguard/peers print

Columns: INTERFACE, PUBLIC-KEY, ENDPOINT-ADDRESS, ENDPOINT-PORT, ALLOWED-ADDRESS, PRESHARED-KEY, PERSISTENT-KEEPALIVE      
# INTERFACE   PUBLIC-KEY                                    ENDPOINT-ADDRESS  ENDPOINT-PORT  ALLOWED-ADDRESS  PRESHARED-KEY                                 PE
0 wireguard1  javni-kljuc-Mikrotik-vrstnika                 xx.xx.xx.xx               51194  10.10.7.0/24     PSK-kljuc-Mikrotik-vrstnika                   5s

Kratka opomba, če bi želeli ta vnos (z zaporedno številko 0, označeno na začetku) odstraniti, uporabimo ukaz: /interface/wireguard/peers> /interface/wireguard/peers/remove numbers=0.

Zdaj je na Wireguard strežniku potrebno v nastavitveno datoteko wg0.conf dodati:

javni ključ Wireguard strežnika
PSK ključ Mikrotik vrstnika
IP naslov Mikrotik vrstnika (v našem primeru smo uporabili 10.10.7.155)

Primer (nastavitvena datoteka /etc/wireguard/wg0.conf):

[Peer]
# MojMikrotik
PublicKey = javni-kljuc-Mikrotik-vrstnika
PresharedKey = PSK-kljuc-Mikrotik-vrstnika
AllowedIPs = 10.10.7.155/32

Na tej točki na Wireguard strežniku ponovno naložimo nastavitve:

systemctl reload wg-quick@wg0.service

Vrnemo se na Mikrotik. Zdaj je na Mikrotiku na Wireguard omrežni vmesnik potrebno dodati IP naslov, ki smo ga določili na strežniku:

/ip address add address=10.10.7.155/32 interface=wireguard1

Nato pa še tim. omrežno pot (angl route):

/ip route add dst-address=10.10.7.0/24 gateway=wireguard1

S tem je Mikrotik povezan v Wireguard omrežje. A verjetno boste opazili, da povezava iz Wireguard omrežja do Mikrotika ne deluje, saj jo onemogoča požarni zid. Treba je torej dodati pravilo, da Mikrotik dovoli povezave iz Wireguard omrežja:

/ip firewall filter add action=accept chain=input comment="Access from Wireguard network" in-interface=wireguard1 src-address=10.10.7.0/24

Vendar pa verjetno povezava kljub temu ne bo delala, saj se vsako novo pravilo samodejno doda na konec seznama pravil. Pravilo je potrebno prestaviti nekoliko višje navzgor, točneje, takoj pred pravilo, ki zavrže vse paketke, ki ne prihajajo iz LAN omrežja. Najprej izpišemo seznam pravil:

/ip firewall filter print

Nato pa to zadnje pravilo premaknemo na višje mesto:

/ip firewall filter move N destination=D

Razlaga:

N je trenutna zaporedna številka pravila
D je na katero mesto naj se prestavi to pravilo

Primer trenutnih pravil, s katerimi blokiramo vse zunanje povezave (razen iz Wireguard omrežja), dovolimo pa povezave znotraj LAN omrežja in povezave navzven:

/ip firewall filter print

Izpis seznama pravil:

Flags: X - disabled, I - invalid; D - dynamic 
 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 

 1    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked 

 2    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid 

 3    ;;; defconf: accept ICMP
      chain=input action=accept protocol=icmp 

 4    ;;; defconf: accept to local loopback (for CAPsMAN)
      chain=input action=accept dst-address=127.0.0.1 

 5    ;;; Block new connections from outside
      chain=input action=drop connection-state=new in-interface-list=WAN 

 6    ;;; Access from Wireguard network
      chain=input action=accept src-address=10.10.7.0/24 in-interface=wireguard1 

 7    ;;; defconf: drop all not coming from LAN
      chain=input action=drop in-interface-list=!LAN 

 8    ;;; defconf: accept in ipsec policy
      chain=forward action=accept ipsec-policy=in,ipsec 

 9    ;;; defconf: accept out ipsec policy
      chain=forward action=accept ipsec-policy=out,ipsec 

10    ;;; defconf: fasttrack
      chain=forward action=fasttrack-connection hw-offload=yes connection-state=established,related 

11    ;;; defconf: accept established,related, untracked
      chain=forward action=accept connection-state=established,related,untracked 

12    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid 

13    ;;; defconf: drop all from WAN not DSTNATed
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN 

S tem je Mikrotik postal povezan v Wireguard omrežje. Do njega lahko dostopamo preko IP naslova 10.10.7.155.

Vsekakor se iz nekega zunanjega strežnika in iz Wireguard omrežja splača preveriti ali požarni zid deluje. Najprej preverimo odprta vrata na Mikrotiku iz Wireguard omrežja: nmap 10.10.7.155. Izpis:

Starting Nmap 7.93 ( https://nmap.org ) at 2024-08-20 13:33 UTC
Nmap scan report for 10.10.7.155
Host is up (0.057s latency).
Not shown: 993 closed tcp ports (reset)
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
23/tcp   open  telnet
53/tcp   open  domain
80/tcp   open  http
2000/tcp open  cisco-sccp
8291/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 1.15 seconds

Nato pa še preko zunanjega IP naslova Mikrotika (nmap xx.xx.xx.xx):

Starting Nmap 7.93 ( https://nmap.org ) at 2024-08-20 13:33 UTC
Nmap scan report for xx.xx.xx.xx
Host is up (0.052s latency).
All 1000 scanned ports on xx.xx.xx.xx are in ignored states.
Not shown: 1000 filtered tcp ports (no-response)

Nmap done: 1 IP address (1 host up) scanned in 53.08 seconds

Iz nmap izpisa je razvidno, da administrativni in drugi vmeniki Mikrotika iz njegovega javnega IP naslova niso dosegljivi, iz Wireguard omrežja pa je vse dosegljivo.

Z opisanim postopkom smo torej Mikrotik napravo nastavili, da se ob zagonu samodejno poveže v VPN omrežje in nam je potem iz VPN omrežja tudi vedno dosegljiva.

GrapheneOS - zaščita pred zasegom podatkov iz telefona

Thu, 18 Jul 2024 02:00:00 +0200

Večina posameznikov na mobilnih telefonih hrani številne zelo osebne podatke, od fotografij, elektronske pošte, do sporočil, ki si jih izmenjujejo s svojimi bližnjimi. Nekateri, npr. preiskovalni novinarji in politični aktivisti, pa imajo na svojih mobilnih telefonih tudi druge občutljive podatke, ki jih ne bi želeli razkriti, saj bi njihovo razkritje lahko ogrozilo njihove vire ali aktivnosti. Enako velja tudi za odločevalce, uslužbence v podjetjih, itd.

Uporabniki zato svoje mobilne telefone zaklepajo, za odklep telefona (in s tem dostop do podatkov) pa so na voljo različne metode: odklep z geslom, s PIN kodo, z vzorcem za odklepanje, s pomočjo prstnega odtisa ali s pomočjo prepoznave obraza.

Slednji dve metodi sta biometrični in za uporabnike zelo priročni, a s stališča varnosti precej problematični. S stališča varnosti je namreč pomembno, da identiteta (“Kdo si?”) in avtentikacija (“Kako lahko to dokažeš?”) ostaneta ločeni vprašanji. Pri uporabi biometrije temu ni tako, saj se biometrični parametri smatrajo kot dokaz identitete. To je še posebej problematično v primeru, da biometrične parametre nekdo ponaredi oz. ukrade, saj jih v takem primeru - za razliko od gesel ali šifrirnih ključev - ni mogoče spremeniti ali preklicati. Poleg tega so biometrični podatki praviloma sami po sebi javni.

Sodobni telefoni za prvi odklep po zagonu (tim. BFU - Before First Unlock) večinoma zahtevajo eno izmed ne-biometričnih metod. Ko pa je telefon po zagonu prvič uspešno uspešno odklenjen, se za odklep zaslona lahko uporablja ena izmed biometričnih metod.

To lahko predstavlja težavo. Znani so namreč primeri, ko je naključni mimoidoči posnel nezakonito ravnanje policije, policist pa je nato posamezniku vzel mobilni telefon, ga prisilno odklenil s pomočjo prepoznave obraza in potem zanj sporne fotografije ali posnetke izbrisal.

Dodaten izziv za zasebnost predstavlja tudi tim. forenzični zaseg podatkov. Gre za skupek tehnik, ki se uporabljajo v digitalni forenziki, s katerimi je mogoče s pomočjo različnih orodij in (hekerskih) tehnik mobilni telefon odkleniti in potem dostopati do datotek na njem. Žal teh tehnik ne uporabljajo samo “uradni” digitalni forenziki in policija v demokratičnih državah, pač pa tudi hekerji, kiberkriminalci in različni avtoritarni režimi.

Večino mobilnih telefonov, tako z operacijskim sistemom Android, kot tudi iOS, je mogoče odkleniti s pomočjo različnih hekerskih tehnik (s tim. vdorom) ali z ugibanjem PIN kode/gesla. Večina telefonov ima sicer omejeno število poskusov za ugibanje gesla, vendar orodja kot na primer GrayKey podjetja Magnet Forensics ali Universal Forensic Extraction Device podjetja Cellebrite te omejitve pri večini telefonov odstranijo in potem z metodo grobe sile gesla ugibajo brez omejitev.

GrapheneOS ima zato implementirane številne tehnike in izboljšave s katerimi otežuje tako vdore v telefon (tim. “hekanje”), kot tudi neomejeno ugibanje PIN kode/gesla. Posledično je v mobilne telefone z nameščenim GrapheneOS izjemno težko vdreti, kar priznavajo tudi vodilni ponudniki opreme za digitalno forenziko mobilnih telefonov. Pobegli dokumenti podjetja Cellebrite (pa tudi dokumenti podjetja Magnet Forensics) razkrivajo, da za forenzični zaseg podatkov iz telefonov z nameščenim GrapheneOS ta podjetja nimajo rešitev (razen v primeru soglasja uporabnika oz. tim. prostovoljnega odklepa telefona s strani uporabnika).

V takih primerih torej napadalcu ne preostane nič drugega kot to, da telefon skuša odkleniti prisilno. Kar je pravzaprav v primeru biometrije relativno enostavno in vsaj v ZDA tudi povsem zakonito.

Prisilno odklepanje mobilnih naprav

Prvi dokumentirani primer prisilnega odklepa telefona s pomočjo biometrije sega v leto 2018, ko je policija 28-letnega Američana Granta Michalskega osumila razširjanja otroške pornografije. Policija mu je telefon zasegla, sodišče pa je v odredbi dovolilo, da telefon (šlo je za iPhone X) tudi prisilno odklenejo s pomočjo Face ID tehnologije.

Sicer v večini demokratičnih držav velja privilegij zoper samoobtožbo, v skladu s katerim se nihče ni dolžan izpovedati zoper sebe ali svoje bližnje. To pomeni, da osumljenec preiskovalnim organom ni dolžan povedati svojega gesla. V ZDA je ta pravica opredeljena v tim. Petem amandmaju, v EU v Charter of Fundamental Rights and Freedoms v 37. členu, v Sloveniji pa je opedeljen v četrti alineji 29. člena Ustave Republike Slovenije.

Vendar pa so ameriška (in tudi druga) sodišča že večkrat presodila, da privilegij zoper samoobtožbo ne velja v primeru biometričnih podatkov (in tudi DNK vzorcev), saj v tem primeru ne gre za pričanje (primer United States v. Jeremy Travis Payne).

Drugačna pravila veljajo tudi ob prehodu meje. V ZDA ima recimo US Customs and Border Protection pravico pregledovati potnike brez suma za kakršnokoli kaznivo dejanje. Res je sicer, da je ameriško Vrhovno sodišče leta 2014 presodilo, da sta preiskava mobilnega telefona in zaseg digitalnih podatkov na njem brez sodne odredbe nezakonita (primer Riley v. California, 573 U.S. 373 (2014)), vendar trenutno te odločitve ni še nihče testiral v primeru tim. izjeme pri preiskovanju ob prehodu meje (angl. border search exception).

V praksi se sicer najbolj pogosto dogaja, da mejni organi uporabnika skušajo prepričati, da telefon odklene prostovoljno, to prepričevanje pa lahko vključuje tudi krajše pridržanje, zavajanje, da je uporabnik dolžan odkleniti mobilno napravo (kar ne drži), daljšo (a na trajno) zaplembo telefona, predvsem pa lahko potniku v takem primeru zavrnejo vstop v državo. Prav tako lahko mejni organi sami skušajo forenzično zlomiti tak telefon in tako priti do podatkov, v primeru da je naprava zaklenjena z biometrijo, pa jo lahko tudi prisilno odklenejo. Podobna pravila ob prehodu meje sicer veljajo pri večini držav.

Nekatere države pa so celo sprejele zakonodajo, ki bi od osumljencev zahtevala obveznost posredovanja šifrinih gesel. Tak primer sta npr. britanski Regulation of Investigatory Powers Act ter francoski tim. ““decryption orders”, ki pa so trenutno v presoji na Evropskem sodišču za človekove pravice (primer Minteh v. France)). Vendar pa ostaja dejstvo, da osumljenca ne more nihče prisiliti, da pove geslo, če ga je (npr. zaradi stresa) preprosto pozabil.

Obstaja pa še druga možnost. Na forumih GrapheneOS opisujejo vsaj en primer nekoga na Švedskem, ki je imel na svojem mobilnem telefonu nameščen GrapheneOS. Policija je vedela, da telefona s forenzičnimi orodji ne bodo mogli odkleniti, zato so ga tajno opazovali in počakali, da je telefon odklenil, v tistem trenutku pa so ga zagrabili in mu telefon zasegli.

Zaščita pred odklepanjem telefonov z GrapheneOS

GrapheneOS ima sicer implementiranih kar nekaj zaščitnih mehanizmov, ki otežujejo tovrstne napade.

Kot omenjeno, ima GrapheneOS implementirane številne mehanizme, ki blokirajo forenzična in hekerska orodja. Eden izmed njih (obstajajo pa tudi številni drugi) je možnost, ki onemogoča nove USB povezave ko je telefon zaklenjen. Če torej napadalec zaklenjen telefon preko USB vmesnika poveže z računalnikom (oz. forenzično napravo), taka USB povezava sploh ne bo mogoča in forenzična naprava sploh ne bo zaznala povezave do telefona.

Naslednji zanimiv mehanizem je tim. PIN scrambling oz. “premešanje” PIN številke. Če omogočimo to možnost, bodo številke za vnos PIN kode naključno razporejene. Ugotavljanje PIN-a s pomočjo opazovanja uporabnika (tim. shoulder surfing napad) je torej v tem primeru oteženo, še posebej, če uporabnik uporablja zaščitno polarizacijsko folijo.

PIN scrambling (premešanje PIN številke).

Še en zanimiv mehanizem je samodejni ponovni zagon telefona (angl. auto reboot feature).

Za kaj gre? Ko se operacijski sistem na telefonu zažene, je telefon v stanju imenovanem BFU (Before First Unlock) - torej “stanje pred prvim odklepom”. V tem stanju je v telefon praktično nemogoče vdreti in iz njega s forenzičnimi ali hekerskimi orodji izvleči podatke. Ko pa uporabnik prvič vnese PIN kodo ali geslo, pa gre telefon v stanje imenovano AFU (After First Unlock) - stanje po prvem odklepu. Ob tem se podatki na notranjem pomnilniku telefona dešifrirajo, šifrirni ključi pa so nato shranjeni v notranjem pomnilniku telefona.

GrapheneOS ima sicer implementirane številne mehanizme, ki forenzičnim in hekerskim orodjem onemogočajo, da bi uspešno izvlekla šifrirne ključe iz notranjega pomnilnika. Vendar pa je - vsaj v teoriji - uspešen napad na telefon v AFU stanju bolj verjeten, kot če je telefon v tim. BFU stanju.

GrapheneOS ima nastavitev, ki omogoča, da se telefon, ki je v AFU stanju, a po določenem času ni bil odklenjen - samodejno ponovno zažene. S tem se telefon vrne v BFU stanje, in ekstrakcija podatkov iz njega je praktično nemogoča.

Privzeto je ta čas 18 ur (če zaslon telefona v tem času ne bo odklenjen, se bo telefon samodejno ponovno zagnal), vendar pa je ta interval mogoče poljubno spremeniti - celo na samo 10 minut.

Praviloma namreč traja nekaj časa, da preiskovalci začnejo forenzično preiskavo naprav, ki so jih zasegli. Tipično je to lahko nekaj dni. Če bo torej od samega zasega (ali pa kraje oz. izgube) telefona, pa do začetka postopka forenzičnega zasega preteklo dovolj časa, se bo telefon samodejno ponovno zagnal, se s tem vrnil v BFU način, zaseg podatkov iz njega pa bo praktično nemogoč.

Še en zanimiv varnostni mehanizem pa so pri GrapheneOs uvedli pred kratkim. Gre za tim. “prisilna gesla/PIN šteilke” (angl. duress password/PIN).

Prisilno geslo oz PIN koda je posebno geslo (oz. PIN koda), ki si ga nastavimo v nastavitvah. S tem geslom oz. PIN kodo pa se telefona ne odklene, pač pa se ob vnosu nepovratno pobriše (vključno z eSIM karticami).

Prisilna gesla lahko pridejo zelo prav v primeru, ko napadalec mobilni telefon uporabniku nasilno (nezakonito) vzame in od njega zahteva, da ga odklene. V primeru, da mobilni telefon zaseže policija z odredbo, pa bi vnos prisilnega gesla lahko predstavljal tim. uničevanje dokazov (angl. tampering with evidence) oz. tim. oviranje pravice (angl. obstruction of justice).

Vendar pa kot rečeno, osumljencu gesla za odklep ni potrebno povedati. Lahko pa ima uporabnik prisilno geslo oz. PIN kodo zapisano na kakšnem listku, zataknjenem za ovitek telefona. In če bo napadalec listek našel in PIN kodo vnesel sam, bo s tem tudi sam pobrisal telefon.

Zaščita v primeru uporabe biometrije

Kot smo torej videli, v primeru, da za zaklep telefona uporabljamo PIN kodo ali geslo, obstaja kar nekaj zaščit, ki otežijo uspešen zaseg podatkov iz telefona. Težava pa je, če za odklep zaslona uporabljamo biometrijo - torej prstni odtis.

Vendar obstaja rešitev tudi za to. Najdemo jo v obliki posebne aplikacije Private Lock (dostopna je na tržnici F-Droid).

Aplikacija PrivateLock.

Aplikacija zahteva res minimalno dovoljenj (ne zahteva niti dostopa do omrežja), deluje pa tako, da ko telefon zaklene takoj, ko ga dovolj močno stresemo. Stopnjo občutljivosti tresenja lahko nastavimo med nastavitvami. Telefona, ki je zaklenjen na ta načina, pa naslednjič ni več mogoče odkleniti z biometrijo (prstnim odtisom) oz. vzorcem za odklepanje (vlečenjem), pač pa je potrebno vnesti geslo. (Po uspešnem vnosu gesla je biometrično odklepanje oz. vzorec za odklepanje spet normalno aktiven.)

Nastavitve PrivateLock.

Aplikacija torej omogoča naslednji scenarij uporabe: če skuša napadalec uporabniku telefon na silo vzeti iz rok, ali pa nanj na silo pritisniti prst, uporabnik telefon samo dovolj močno zatrese (ali ga spusti na tla) - in telefon se bo samodejno zaklenil.

Odklep sedaj ne bo več mogoč z biometrijo, pač pa samo s PIN kodo ali geslom. Tega pa uporabniku ni treba povedati, oziroma lahko vpiše prisilno geslo ali zavede napadalca, da prisilno geslo vnese sam - in telefon se bo pobrisal.

In če odklep ne bo izveden v času do naslednjega samodejnega zagona, se bo telefon samodejno vrnil v tim. BFU način, zaseg podatkov s forenzičnimi in hekerskimi orodji iz njega pa bo praktično nemogoč.

Vse opisani mehanizmi seveda ne nudijo absolutne zaščite pred dostopom do podatkov na mobilnem telefonu. Vseeno pa v kombinaciji pokrijejo številne scenarije napadov in s tem precej izboljšajo zaščito zasebnosti uporabnika mobilnega telefona.

Reševanje ZFS

Tue, 16 Jul 2024 02:00:00 +0200

Prejšnji teden sem se odločil posodobiti operacijski sistem Debian na enem izmed svojih strežnikov. Posodobitev je načeloma preprosta - v datoteko sources.list je treba vpisati nova skladišča programskih paketov, nato pa se požene apt-get -y update, apt-get -y upgrade ter apt-get -y full-upgrade (pa še kakšno malenkost). Vse to sem lepo naredil in na koncu je preostal le še ukaz reboot, ki ponovno zažene sistem. Minuta ali dve čakanja - in strežnik bi se moral zbuditi s posodobljenim operacijskim sistemom. Le da se to ni zgodilo. Niti po petih, niti po desetih minutah. Kar je… znak za alarm. Še posebej, če se strežnik nahaja na drugem koncu… Slovenije (ali pa Evrope, saj je vseeno).

PiKVM

No, na srečo je bil na strežnik priključen PiKVM. Gre za napravico, ki omogoča oddaljen dostop in oddaljeno upravljanje računalnikov. PiKVM je v osnovi dodatek (tim. “klobuk” oz. angl. hat), ki ga priklopimo na RaspberryPi. Nato pa PiKVM priključimo na računalnik namesto monitorja in tipkovnice/miške - v tem primeru nam PiKVM predstavlja virtualni monitor, virtualno tipkovnico, miško, CD, USB ključek, itd. Preko tega nato lahko računalnik ali strežnik oddaljeno upravljamo (vstopimo lahko tudi v BIOS, virtualno pritisnemo gumb za izklop ali gumb za reset) - in to kar preko spletnega brskalnika. Programska oprema je popolnoma odprtokodna, zadeva pa podpira tudi priklop na KVM razdelilec, kar nam omogoča oddaljeno upravljanje več računalnikov - to je recimo idealno za montažo v podatkovni center.

PiKVM ob nakupu.

Skratka, ko se strežnik nekaj časa ni več odzival, sem se povezal na PiKVM in šel pogledat kaj se je dejansko zgodilo. In zgodila se je… katastrofa.

Težava

Strežnik je namreč po ponovnem zagonu obstal v initramfs. Aaaaaa! Na dnu zaslona pa se je svetilo še zadnje opozorilo preden je sistem dokončno izdihnil - ALERT! ZFS=rpool/ROOT/debian does not exists. Dropping to a shell!. V obupu sem spregledal tisti “s” in prebral “hell”…

V tistem trenutku sem se spomnil, da je bil na korenskem razdelku strežnika seveda nameščen ZFS datotečni sistem - in to šifriran - ob nadgradnji pa sem seveda pozabil ročno omogočiti tim. jedrne module (angl. kernel modules), ki bi omogočili, da operacijski sistem ob zagonu prepozna ZFS. In da bi bila stvar še hujša - na strežniku je teklo (no, zdaj pač ne več) več virtualnih strežnikov. Ki so bili sedaj seveda vsi nedosegljivi.

Opomba. ZFS (Zettabyte File System) je napreden datotečni sistem, ki je znan po svoji zanesljivosti, razširljivosti, uporabi naprednih tehnik za preverjanje in popravljanje napak (kar zagotavlja, da so podatki vedno dosledni in brez poškodb), uporabi kompresije in deduplikacije, itd. Skratka, idelaen za strežniška okolja.

Dobro, zdaj vemo kaj je problem, ampak kako ga rešiti?

Načrt za njeno rešitev

Da si vsaj malo opomorem od pretresa, sem si najprej pripravil močno kavo. Odločitev se je izkazala za strateško, saj se je reševanje sistema zavleklo pozno v noč (in še v naslednje dopoldne).

Po krajšem razmisleku se mi je v glavi zarisal naslednji načrt. Najprej sistem zaženem iz “Live Debian CD-ja”, na ta začasni sistem namestim podporo za ZFS, priklopim ZFS diskovje, se “chroot-am” v stari sistem, tam popravim nastalo škodo in vse skupaj ponovno zaženem. In to je to!

Na tej točki bi se v kakšnem starem filmu samo še vsedel na konja in odjahal v sončni zahod, ampak kot se je izkazalo, je bila pot do konja (in njegovega sedla)… še precej trnova. Pa pojdimo po vrsti.

PiKVM v akciji.

Najprej sem na PiKVM prenesel datoteko debian-live-12.6.0-amd64-standard.iso, jo priklopil kot navidezni CD, ter zagnal strežnik. To je bilo resnično enostavno in PiKVM se je ponovno izkazal za vreden svojega denarja.

Se je pa že kar na začetku izkazalo, da strežnik prepoznava samo ameriško tipkovnico. In ker imam jaz slovensko, je bilo treba najprej ugotoviti katero tipko moram pritisniti, da dobim točno tisti poseben znak, ki ga potrebujem. No, tule je nekaj v mojem primeru najpogosteje uporabljenih znakov na slovenski tipkovnici in njihovi “prevodi” na ameriško tipkovnico:

- /
? - 
Ž |
+ =
/ &

Luč na koncu tunela

Naslednji korak je bil, da v /etc/apt/sources.list tim. “živega sistema” dodam še skladišče contrib. Nato pa sem že lahko namestil podporo za ZFS: sudo apt update && sudo apt install linux-headers-amd64 zfsutils-linux zfs-dkms zfs-zed.

Po minuti ali dveh, pa sem že lahko naložil ZFS jedrne module: sudo modprobe zfs. Ukaz zfs version je pokazal, da podpora za ZFS zdaj deluje:

zfs-2.1.11-1
zfs-kmod-2.1.11-1

No, prvi korak je uspel, sedaj pa je bilo v sistem potrebno “samo še” priključiti obstoječe diskovje. Najprej sem naredil ustrezno mapo, kamor bom priklopil diskovje: sudo mkdir /sysroot.

Nato pa sem skušal nanjo priključil svoj “rpool” ZFS. Spodnji ukazi so zgolj približni (verjetno je treba narediti še kaj, recimo nastaviti tim. mountpoint), so pa lahko vodilo komu, ki bo imel podobne težave. Naj seveda dodam, da ni šlo povsem enostavno in je bilo potrebno kar nekaj telovadbe, da sem uspel priti do končnega cilja.

sudo zpool import -N -R /sysroot rpool -f

sudo zpool status
sudo zpool list
sudo zfs get mountpoint

Na tej točki sem vnesel šifrirno geslo: sudo zfs load-key rpool… in preveril, da je ZFS odklenjen: sudo zfs get encryption,keystatus.

Sedaj pa priklop: sudo zfs mount rpool/ROOT/debian. In evo, podatki so bili vidni in kot je kazalo ni bilo nič izgubljenega!

Oživljanje “pacienta”…

Končno je sledil chroot v stari sistem:

sudo mkdir /sysroot/mnt
sudo mkdir /sysroot/mnt/dev
sudo mkdir /sysroot/mnt/proc
sudo mkdir /sysroot/mnt/sys
sudo mkdir /sysroot/mnt/run
sudo mount -t tmpfs tmpfs /sysroot/mnt/run
sudo mkdir /sysroot/mnt/run/lock

sudo mount --make-private --rbind /dev /sysroot/mnt/dev
sudo mount --make-private --rbind /proc /sysroot/mnt/proc
sudo mount --make-private --rbind /sys /sysroot/mnt/sys

sudo chroot /sysroot/mnt /usr/bin/env DISK=$DISK bash --login

Zdaj sem bil torej uspešno povezan v stari (“okvarjeni”) sistem. Najprej je bilo vanj potrebno namestiti ZFS podporo:

apt install --yes dpkg-dev linux-headers-generic linux-image-generic
apt install --yes zfs-initramfs
echo REMAKE_INITRD=yes > /etc/dkms/zfs.conf

…z manjšimi težavami

Seveda se je vmes pojavila še ena napaka, in sicer nameščanje programske opreme ni bilo možno zaradi okvarjenega systemd paketa. To sem rešil z:

sudo rm /var/lib/dpkg/info/systemd*
sudo dpkg --configure -D 777 systemd
sudo apt -f install

Potem so se seveda pojavile še nerešene odvisnosti… kako točno sem to uspel rešiti se niti ne spomnim več, pomagali pa so naslednji ukazi (ne nujno v tem vrstnem redu):

dpkg --force-all --configure -a
apt --fix-broken install
apt-get -f install

Zdaj je bilo potrebno priklopiti še efi razdelek (za katerega je bilo potrebno najprej ugotoviti kje točno se sploh nahaja):

cp -r /boot /tmp
zpool import -a
lsblk
mount /dev/nvme0n1p2 /boot/efi
cd /tmp
cp * /boot/

Zdaj pa zares!

Končno sem lahko pognal ukaze s katerimi sem dodal ZFS jedrne module v jedro operacijskega sistema:

update-initramfs -c -k all
dkms autoinstall
dkms-status
update-grub
grub-install

No, in končno je sledil ponovni zagon sistema, po njem pa je bilo treba popraviti še mesto priklopa ZFS sistema (zfs set mountpoint=/ rpool/ROOT/debian)… še en ponovni zagon - in stari sistem je vstal od mrtvih.

Postfestum sanacija nastale škode

Zaradi silnega čaranja in ne povsem dokončane nadgradnje, je bilo potrebno namestiti manjkajoče programske pakete, ponovno namestiti nekaj systemd paketov in odstraniti stara jedra operacijskega sistema. Vse seveda ročno.

Aja, pa iz nekega razloga je ob posodobitvi izginil SSH strežnik. Ampak to rešiti je bila sedaj mala malica.

Sledil je reboot in nato še enkrat reboot, da vidim, če res vse deluje.

Konec dober, vse dobro

In zdaj deluje. O, kako lepo deluje! ZFS je kriptiran, sistem se po vnosu gesla za odklep lepo zažene, prav tako se samodejno zaženejo virtualni strežniki. PiKVM pa je dobil prav posebno mesto v mojem srcu.

Pa do naslednjič, ali kako že rečejo! :)

P. S. Hvala tudi Juretu za pomoč. Brez njegovih nasvetov bi vse skupaj trajalo precej dlje.

GrapheneOS and forensic extraction of data

Wed, 29 May 2024 02:00:00 +0200

GrapheneOS is an Android-based, open source, privacy and security-focused mobile operating system for mobile phones. It is one of the most secure and privacy protecting operating systems (and yes, it does this task comparable and in some scenarios - especially regarding privacy - even better than iOS, but we will come to that later).

However, in the beginning of May, someone started an attack on GrapheneOS across social media platforms. The perpetrators were misrepresenting consent-based data extraction as GrapheneOS being compromised. Which would be funny if it wasn’t so stupid. So let’s see what happened and what actually consent-based data extraction means.

Digital forensics

Digital forensics is the process of uncovering and analysing electronic data in order to gather evidence for legal proceedings. It involves the use of various techniques and tools to examine digital devices such as computers, smartphones, and storage media to identify, preserve, analyse, and present digital evidence.

Digital evidence refers to any data or information that is stored or transmitted in digital form and can be used as evidence in a legal investigation or trial. Digital evidence is often used in criminal investigations to help establish a suspect’s guilt or innocence, and can also be used in civil litigation, regulatory investigations, and other legal proceedings.

Unfortunately, sometimes digital forensics can be abused. It can be used against investigative journalists or political activists, it can be used for privacy violation, to intimidate or harass someone, to tamper with evidence, etc. That is why GrapheneOS developers are working hard to protect mobile phones from tampering and try to make data extraction without user’s consent as hard as possible.

Cellebrite

Cellebrite is a leading Israeli company in the digital intelligence and digital forensics field. Their main digital forensics tool is called Universal Forensic Extraction Device (UFED), and is used to extract and analyze data from mobile devices for investigations.

They are selling their equipment to governments all around the world, and their tools are mostly used for legitimate purposes. Unfortunately they are selling their tools to authoritarian regimes too. Cellebrite’s customer list has included authoritarian regimes in Belarus, Russia, Venezuela, and China, death squads in Bangladesh, military juntas in Myanmar and those seeking to abuse and oppress in Turkey, UAE, and elsewhere.

Data extraction

As mentioned, digital forensics tools first try to extract data from mobile device. This is the initial step in a digital forensics investigation.

The problem for digital forensics is, what if mobile phone is locked? How to extract data from a locked device?

There are several options, but basically three approaches exist.

First option is so called consent-based data extraction. This simply means that user voluntary unlocks their device (or provides PIN code or password), and forensic tool then extracts data from unlocked device.

Why would someone voluntary unlock their device? Well, maybe the owner of the device wants to cooperate with the investigators. Maybe he is a victim of criminal activity and wants to provide evidence against the perpetrators. Maybe he knows that data will prove his innocence. Or something else.

The question is of course, what if user do not want to provide PIN code or password or to unlock their phone?

In that case, there are two general approaches of digital forensic examination. The first option is to try to hack a mobile device so it gets unlocked (and then extract the data). And the other is to try to guess PIN code or password in order to unlock the device and the extract the data.

Companies like Cellebrite are offering various tools, that can try to hack into the locked mobile phone and then extract the data. And their tools also offer a possibility to “guess” PIN code or password, in order to unlock the device.

But first we need to understand that from the digital forensics point of view, mobile phone can basically be in two states.

First is called BFU (Before First Unlock), and it simply means a device that has been turned off or rebooted and never subsequently unlocked by entering the correct PIN or passcode. The second is called AFU (After First Unlock), and it means that device has been unlocked after reboot (meaning that encryption keys are stored in internal memory of the device).

Technically, there is important difference between the two. BFU devices (that hasn’t been unlocked with a PIN or passcode) mostly contains encrypted data. Since the first unlock of the device also decrypts the device (technically: unlocks the decryption key, so device can access the data stored in internal storage), most data on the device in that case is inaccessible for forensic analysis. Technically that means that data are encrypted at rest.

AFU devices (that has been unlocked with the correct passcode after powering on, or restarting) contains decryption key in it’s internal memory, and that key is used to decrypt files in internal storage. In that case most data on the device becomes accessible for forensic analysis, because data in that state are decrypted for normal use. However, in that case screen lock could still been activated, meaning, that forensic investigator needs to unlock the screen first, and then can extract the data.

From the user’s point of view this simply means that a locked device in BFU state presents significant challenges for data extraction, while an unlocked device (in AFU state) offers greater access to extract the data.

Data extraction approaches

As already mentioned, AFU devices are easily approached for extraction. General approach here is to hack into the locked mobile phone (by exploiting some software vulnerability) in order to disable or bypass a screen lock, and then extract the data.

In case of BFU devices, where data in internal storage are still encrypted, the forensic examinator needs to “guess” PIN code or password, in order to unlock the device. Usually this is done by so called brute forcing. This simply means that a forensic tool tries to guess the correct PIN or password by going through all possible combination, until the correct one is found.

Cellebrite’s capabilities

In April 2024 Cellebrite published a list of their capabilities provided to customers. The list shows that they can successfully exploit every non-GrapheneOS Android device brand. They can do this for devices in AFU and BFU states. This means, that Cellebrite’s tools can unlock (and then extract data) every Android device on the market.

Android capabilities.

According to Cellebrite’s documents, they have similar capabilities for iOS devices too. Not all, but for many of them. In fact, it is only the latest device generation and OS versions which are not fully supported yet (however, it is fair to mention, that most iPhone users are getting iOS updates automatically). Will they be able to develop exploits for the later iOS devices too? We do not know that, but we know, that NSO (an Israeli company developing Pegasus spyware) already did that, right after iOS 17 has been released in September 2023.

iOS capabilities.

Which is interesting, because Apple is advertising iOS as “the world’s most personal and secure mobile operating system”.

What about GrapheneOS? According to the documents, Cellebrite admits they can not hack GrapheneOS if users had installed updates since late 2022. This is important, because GrapheneOS is releasing security updates and improvements quite frequently - sometimes even several times a month. And GrapheneOS is designed in such a way, that updates are automatically enabled, and if users want to disable them, they need to do that manually. This means that very likely vast majority of users have GrapheneOS updated to the last version automatically and their phones can not be hacked by Cellebrite’s tools.

GrapheneOS capabilities.

On the other side, Cellebrite claims that they can do so called consent-based full filesystem extraction with iOS, Android and GrapheneOS. As already mentioned, this simply means they can extract data from the device once the user voluntary unlocks their device. For GrapheneOS that means, that when they get unlocked phone, they just enable developer options and use standard ADB tool (ADB lets you communicate with Android devices through a computer) to extract the data.

So, according to Cellebrite documents, they can not unlock fully patched GrapheneOS phone, unless user voluntary unlocks the phone. In fact, analysis of Cellebrite’s documents shows, that they even can not brute force a random 6-digit PIN on Pixel 6 and later phones (which are the phones supported by GrapheneOS). Cellebrite’s documents reveal, that Pixel 6 phones and later with GrapheneOS (and the latest iPhones also), are the only devices where a random 6 digit PIN can not be brute forced.

As we mentioned at the beginning, in the beginning of May, someone started an attack on GrapheneOS across social media platforms. The perpetrators claimed that GrapheneOS has been compromised, and the “proof” has been, that data extraction from GrapheneOS is successful when it is consent-based.

It is unclear who has been behind this social media attack, but in December 2020 something similar happened. At that time, various media (including BBC) reported, that Cellebrite claimed to have cracked Signal’s encryption. Signal is a free, encrypted messaging application, which is widely considered one of the most secure messaging apps due to its strong encryption and focus on privacy.

However, at that time it turned out, that the claims were completely false - Cellebrite has been able to extract Signal messages only if user unlocked the phone and Signal app and hand it to the forensic examinator. Which is by definition consent-based extraction and does not really require some specific technical excellence from the forensic acquisition tool.

Short notice: Signal’s local database on a phone is encrypted. So you need to need to extract the Signal database from the filesystem first, and then to you need to obtain three values to decrypt the database. The first is stored in so called Keystore system, and the other two values are stored in the XML file on the phone’s file system. It is important to know that cryptographic keys stored in a Keystore system are more difficult to extract from the device, because once keys are in the Keystore, you can use them for cryptographic operations, with the key material remaining non-exportable.

Defense against forensic hacking tools in GrapheneOS

Now let’s dive into GrapheneOS security countermeasures against described attacks.

Protection against hacking into the phone

GrapheneOS has implemented many security features. You can get a glimpse of them from my presentation on GrapheneOS security.

However, regarding various forensic tools, it is important to mention, that GrapheneOS has a special feature that disallows new USB connections in AFU mode (After First Unlock) after the device is locked, and fully disables USB data at a hardware level once there aren’t active USB connections. This means that if an attacker would connect GrapheneOS device to the computer through USB, GrapheneOS device will not allow any connection at all.

Users can set it to do this in BFU (Before First Unlock) mode or even when the phone is fully unlocked. And users with a high threat model can even fully disable USB, including USB-PD/charging, while the OS is booted. So they can decide to only allow charging while powered off or booted into the fastboot/fastbootd/recovery/charging modes. This is the feature no other phone has, and can be completely customized by the user.

GrapheneOS is constantly improving security, and since beginning of 2024 they massively improved security against various possible exploits. In April 2024 they also helped to implement several firmware improvements for Pixel phones.

Protection against brute force attacks

As we mentioned, in case of BFU devices, where data in internal storage are still encrypted, the forensic examinator needs to “guess” PIN code or password, in order to unlock the device. This is done by so called brute force attack (guessing every possible combination of PIN code or password).

However, Pixel 6 and later phones contain a dedicated security chip Titan M2, also called hardware security module, which is storing the decryption keys. This chip will unlock the internal phone storage only if user will enter the correct PIN or password.

But here is the catch. If an attacker try to perform brute force attack (i. e. try to go through all possible PIN/password combinations), the chip will limit the number of attempts. After 5 failed attempts, chip will add 30 second delay before next guessing attempt is allowed. Then delay gets increased (after 30 failed attempts the delay doubles after every 10 attempts), and after 140 failed attempts, GrapheneOS and its secure element will limit brute force to 1 attempt per day. This is called secure element throttling.

So if an attacker would like to test all different combinations to guess a 6-digit PIN, there are one million possible combinations, so brute forcing would take a long, long time. Unless, the attacker is extremely lucky and guesses the correct PIN at the few first attempts.

Of course, the question is, is it possible to somehow hack this secure element or unlock the limited number of attempts? The answer is - very unlikely. Why? Because this secure element has been developed specifically to protect against those types of attacks. And it has passed the highest hardware vulnerability assessment (AVA_VAN.5) by an independent and accredited evaluation lab.

In fact, GrapheneOS is so successful in this area, because it is doing far more hardening than iOS against these attacks. iPhones also have security element, but the companies developing attacks, had successfully bypassed secure element throttling from Apple for years (and are doing the same with Samsung and Qualcomm implementation of secure element). These companies were successfully bypassing the secure element throttling on 2nd through 5th generation Pixels. Pixel 2 used NXP secure element and Pixel 3 moved to a custom ARM secure element. But Pixel 6 and later phones are using a custom RISC-V secure element. It seems that moving away from the standard ARM Cortex secure element cores was the correct decision, because it blocked these companies from successfully exploiting the secure element for several years.

Auto reboot feature

GrapheneOS also has an auto-reboot feature, meaning that after some time, phone gets automatically rebooted. Default auto reboot time is 18 hours (if phone is not unlocked in that time, it will reboot), but user can set it to a different interval, even as low as 10 minutes.

This technically means that the data after this period are put back to rest, or, to put it differently, phone gets from AFU to BFU state. And as we already explained, a locked device in BFU state presents significant challenges for data extraction, much more than unlocked device in AFU state.

After reboot, it is almost impossible to extract decrypted data from the phone. So the focus of GrapheneOS’s team is defending against exploitation long enough for auto-reboot to work, and after that your data are even safer than before. That means that if an attacker develops a successful exploit, their window of opportunity to use it to get data from user profiles is until next reboot from when the phone was locked.

Conclusion

In the last year, GrapheneOS started to put much more effort into defending your phone against these attacks. Users who need their data secure, should definitely use a strong passphrase. To make that more convenient, GrapheneOS is developing 2-factor fingerprint unlock feature, which will allow people to combine a strong passphrase with convenient fingerprint and PIN unlock. They are also planning to offer an UI for generating random passphrases automatically. This will vastly improve security and make access to the user’s data on a phone much more difficult.

The actors that want to hack into GrapheneOS are rightfully desperate. So it is no surprise, that they try to play dirty, by spreading misinformation. But knowledge is power and misinformation could be successfully fought with facts.

Telefoncek.si

Rootkits - how deep the rabbit hole is?

Bootkit

How deep the rootkit can go?

Ring 3 rootkits

Ring 3 rootkits mitigation

Ring 0 rootkits

Ring 0 rootkits mitigation

Ring -1 rootkits

Ring -1 rootkits mitigation

Ring -2 rootkits

SMM rootkits

BIOS/UEFI rootkits

Ring -2 rootkits mitigation

Ring -3 rootkits

Ring -3 rootkits mitigation

Ring -4 rootkits

Exploits on baseband processors

Exploits on network interface cards

Exploits on storage controllers

Other exploits on hardware components

Ring -4 rootkits mitigation

Can we go even deeper?

Processors with malicious design

Processors with malicious manufacturing

What about mitigation?

Conclusion

Varnost sončnih elektrarn in geopolitika

Izraelski SolarEdge

Zaključek

How I discovered a hidden microphone on a Chinese NanoKVM

How Does the Device Work?

Final Thoughts

P.S. How to Record Audio on NanoKVM

Kako sem na mini kitajski napravi odkril skriti mikrofon

Kako deluje?

Kaj pa varnost?

Skriti mikrofon

Signal kontejner

Poganjanje več različic Signala na telefonu

Poganjanje več različic Signala na računalniku

Kaj pa…?

Varnost in zanesljivost aplikacije Telegram

Povezava Mikrotik usmerjevalnika v Wireguard omrežje

GrapheneOS - zaščita pred zasegom podatkov iz telefona

Prisilno odklepanje mobilnih naprav

Zaščita pred odklepanjem telefonov z GrapheneOS

Zaščita v primeru uporabe biometrije

Reševanje ZFS

PiKVM

Težava

Načrt za njeno rešitev

Luč na koncu tunela

Oživljanje “pacienta”…

…z manjšimi težavami

Zdaj pa zares!

Postfestum sanacija nastale škode

Konec dober, vse dobro

GrapheneOS and forensic extraction of data

Digital forensics

Cellebrite

Data extraction

Data extraction approaches

Cellebrite’s capabilities

The attack on GrapheneOS on social media?

Defense against forensic hacking tools in GrapheneOS

Protection against hacking into the phone

Protection against brute force attacks

Auto reboot feature

Conclusion