Safety at a low level
Safety at a low level
Good afternoon my beloved Alice, today I want to give you a collection of articles and tools about low level security, like "UEFI"🎀📺
Tools 🔧
Fwhunt-scan
Tools for parsing UEFI firmware and checking UEFI modules using FwHunt rules.
This project, available at FwHunt.run, is a free service that helps security professionals quickly scan UEFI firmware images for vulnerabilities and weaknesses in a complex firmware ecosystem.
The FwHunt.run tool uses dependencies from the public github repository of Binarly, which in turn has ensured that the necessary FwHunt rules are matched in its public guidelines, which allows you to detect specific vulnerabilities.
FwHunt is integrated into LVFS and recommended by CERT/CC for detecting known firmware vulnerabilities.
Brick
Brick is a static vulnerability scanner used to identify potentially vulnerable SMMs in a UEFI firmware image.
The scanner consists of a set of modules (implemented as IDAPython scripts), each of which is responsible for identifying a particular vulnerability/anti-pattern in the SMM code.
Brick has combined the following detection modules:
efiXplorer
In addition to being the main analysis engine on which Brick is built, the module has its own set of heuristics that allow it to detect a large number of vulnerabilities:
- SMM calls.
- Buffer overflow, etc.
Unsanitized nested pointers (so-called dirty pointers):
If the CommBuffer for handler contains nested pointers, they must be cleared using functions such as SmmIsBufferOutsideSmmValid to ensure that user-managed arguments do not overlap with SMRAM. Ignoring the requirement can lead to a so-called "obfuscated proxy attack" in which a higher-privileged SMI handler is tricked into using lower-privileged code to overwrite or leak the contents of SMRAM.
Low SMRAM damage
Some SMI handlers write to a CommBuffer file without first checking its size. Attackers can take advantage of this by placing the CommBuffer in memory just below the SMRAM, and when a handler tries to write to the CommBuffer, it will unknowingly corrupt the bottom of the SMRAM.
TOCTOU
The CommBuffer resides outside of SMRAM, so DMA attacks can change its contents while the SMI handler is running. Because of this, double samples of the CommBuffer are dangerous because they optionally produce the same value.
CSEG Only Handlers
Some SMI handlers only check caller-provided pointers against the address range of the Compatibility SMRAM segment (0xA0000-0xBFFFF). Because other areas of SMRAM that might be active are not protected by these SMI handlers, they are not marked as potentially vulnerable by Bricko.
UEFI_boot_script_expl
CHIPSEC module exploiting the UEFI Boot Script Table Vulnerability.
The UEFI Boot Script Table is a data structure that is used to save platform state during ACPI S3 sleep when most platform components are turned off.
Usually this structure is located in the memory area of a special non-volatile storage.
The UEFI code creates the boot script table during normal boot and interprets its entries during S3 resume when the platform wakes up.
An attacker who can modify the current contents of the kernel-mode boot script table and initiate an S3 suspend-resume cycle could gain arbitrary code execution early in platform initialization when some security features are not yet initialized or disabled
The exploit was tested on the following hardware:
Intel DQ77KB motherboard (Q77 chipset)
Apple MacBook Pro 10,2
Lenovo ThinkPad laptops (tested on x220, x230, etc.)
An interesting article on exlating this vulnerability
Fwexpl
Tool and library for exploiting PC firmware
Detailed article about the described vulnerabilities
Despite the fact that the vulnerabilities are far from new, this does not prevent them from remaining very curious and interesting both for exploitation and for research.
The project includes the following components:
* src/libfwexpl - Hardware abstraction library for Windows (see include/libfwexpl.h).
* src/libdsebypass is a Windows x64 DSE bypass exploit based on the Secret Net 7.4 0day privilege escalation vulnerability (see include/libdsebypass.h).
* src/driver is part of the libfwexpl kernel mode.
* src/application - Application that implements the System Management Mode code execution exploit for the 1day vulnerability in the SystemSmmAhciAspiLegacyRt UEFI SMM driver in Lenovo firmware.
An exploit for the SystemSmmAhciAspiLegacyRt driver that targets models:
*Lenovo ThinkPad T450s with firmware 1.11.
*Lenovo ThinkPad X230 with firmware 2.61.
Note that the affected UEFI SMM driver is present in all modern ThinkPad firmware, possibly in some other Lenovo computers. You can protect yourself and contact Lenovo security consultants.
Secretnet_expl
A standalone version of the local privilege escalation exploit for Secret Net 7.4 and Secret Net Studio 8.0 0day, which is available as a separate project:
The 0day vulnerabilities in the sncc0.sys kernel driver of the Secrity Code products allow an attacker to perform local privilege escalation from a guest to the local system.
Additionally, an attacker with access to any Windows system could manually install sncc0.sys (which has a valid digital signature from the security code) and use its vulnerability to bypass DSE and subsequently load unsigned kernel-mode drivers on Windows x64 platforms.
ThinkPwn
This code exploits the 0day privilege escalation vulnerability in the SystemSmmRuntimeRt UEFI driver (GUID - 7C79AC8C-5E6C-4E3D-BA6F-C260EE7C172E) in Lenovo firmware.
The vulnerability is present in all ThinkPad series laptops, the oldest I tested is the X220 and the newest is the T450s (with the latest firmware available at the time of writing).
Running arbitrary system control mode code allows an attacker to disable flash write protection and infect the platform firmware, then disable secure boot, bypass virtual secure mode (Credential Guard, etc.) in Windows 10 Enterprise, and perform other illegal actions.
The vulnerable SystemSmmRuntimeRt UEFI driver code was copied by Lenovo from Intel's reference code for 8-series chipsets.
The code is not found in the public domain, but it is possible to find open source firmware in the public domain for some Intel boards that also use the Intel code. For example, the SmmRuntimeManagementCallback() function from the Intel Quark BSP is exactly the same vulnerable code.
The EDK2 source code from the public repository never had this vulnerability - its version of QuarkSocPkg was heavily modified compared to the vulnerable
The exploit to test the concept of this vulnerability is designed as a UEFI application that runs from a UEFI shell. It is possible to use it from a running operating system, but you must implement your own EFI_BASE_PROTOCOL function. communicate().
This exact PoC was developed exclusively for Lenovo computers, and it's lucky that it works everywhere.
If the PoC fails to exploit a vulnerability on any machine from another manufacturer, then this does not mean that the machine is not vulnerable, it only says that it is not supported by the exploit.
To build an exploit from source on Windows using the Visual Studio compiler, you need to follow these steps:
1. Copy the ThinkPwn project directory to the EDK2 source code directory.
2. Launch a Visual Studio 2008 command prompt and navigate to the EDK2 directory.
3. Run Edk2Setup.bat --pull to set up the build environment and download the necessary binaries.
4. Edit the AppPkg/AppPkg.dsc file and add the path to ThinkPwn/ThinkPwn.dsc to the end of the [Components] section.
5. Change to the ThinkPwn project directory and run the build command.
6. After compilation, the resulting PE image file will be created at Build/AppPkg/DEBUG_VS2008x86/X64/ThinkPwn/ThinkPwn/OUTPUT/ThinkPwn.efi.
To test the exploit on your own hardware:
1. Prepare a FAT32 formatted USB stick with ThinkPwn.efi and UEFI Shell binaries (https://github.com/tianocore/tianocore.github.io/wiki/Efi-shell).
2. Boot into a UEFI shell and run the ThinkPwn.efi application.
Sweetlemonade
SWEETLEMONADE is an OS independent bootkit for UEFI firmware. This repository was created in connection with the publication of an article in the MISC magazine.
Bootkit-samples
Repository with basic information about boutiques and their samples
Let's see what we're talking about, shall we?
Bootkits are malware that infects the boot process of a PC allowing access to the system.
Also in the repository there are examples of bootkits from the "wilderness", such as FinSpy or ESPecter, and as a bonus, a bootkit threat model is described.
Typical malware might check to see if protections are installed and inject bootkits into flash memory if protections are installed incorrectly.
Bootkits used to mostly target MBR or ESP, but now they are more focused on DXE or PEI
An article about the sensational BlackLotus bootkit
There are many vulnerabilities to bypass secure boot.
Their CVSS scores are not so high only because vulnerabilities often require local access to the device, however, despite the complexity of this kind of vulnerability, knowledge about it should not be neglected.
BlackLitus
In general, BlackLitus itself is a successful combination of old techniques, there was a general opinion that this bootkit was based on umap (this is another bootkit that loads the universal driver converter manually without using the UEFI driver), since the ideas are very similar (for example, in the logic of installing hooks).
In general, if you combine public exploits for cve-2022-1894, this can lead to the creation of a detailed BlackLitus bootkit.
Aptiocalypsis
This code exploits a vulnerability in the UEFI SMM drivers of AMI Aptio-based firmware to execute arbitrary SMM code.
Running arbitrary system control mode code allows an attacker to disable flash write protection and infect platform firmware with a persistent backdoor that is active even after OS reinstallation, disable secure boot, bypass virtual safe mode, in Windows 10 Enterprise, and do other evil things .
In addition, the Aptiocalypsis exploit is the first publicly demonstrated successful attempt to break the SMM_Code_Chk_En exploit protection feature that has been introduced on Intel processors since the Haswell microarchitecture.
The vulnerability was discovered during a firmware reversal of the 6th generation Intel NUC platform.
In total, three 0day vulnerabilities were found in the NvmeSmm, SdioSmm and UsbRt drivers from AMI and one in the ItkSmmVars driver from Intel. The vulnerabilities were reported to Intel on 07/15/2016, and within a few business days, Intel and AMI confirmed all security issues.
Intel has decided to issue a single INTEL-SA-00057 newsletter to cover all four vulnerabilities
Fixed NUC firmware version SYSKLi35.86A.0051
Vulnerable UEFI SMM drivers are also present in computers running AMI-based firmware from other manufacturers.
For example, the Asus Q170M-C motherboard firmware contains two of the four vulnerable drivers described above.
So far, Intel is the only OEM that has released advisories and patches for these vulnerabilities. Perhaps in the future we will see information about vulnerable products from other manufacturers.
Articles📚
Hardware-and-Firmware-Security-Guidance
Guidance on Specter, Meltdown, Speculative Store Bypass, Rogue System Register Read, Lazy FP State Restore, Bounds Check Bypass Store, TLBleed and L1TF/Foreshadow vulnerabilities, as well as general hardware and firmware security recommendations.
This repository contains the following:
- Side-channel attacks that include mitigation measures. For example: firmware patches, software fixes, configuration changes, disable Intel Hyper-Threading.
- This also includes resources affected by these attacks, hardware resources, software resources, consulting resources.
- Collected information about the equipment for providence attacks.
- The repository addresses firmware and microcode vulnerabilities: LoJax, Ryzenfall, Chimera, Fallout and Masterkey and bypassing Microsoft Secure Boot.
- It also talks about boot configuration aimed at enhancing security, such as enhancing UEFI security or configuring UEFI secure boot.
- And as a bonus, there is a manual for updating equipment
SmmExploit
Report and exploit CVE-2021-26943, local kernel-to-SMM privilege escalation vulnerability in ASUS UX360CA BIOS version 303.
Vulnerable modules and corresponding SMIs: UsbRt (0x31), SdioSmm (0x40) and NvmeSmm (0x42).
These SMI handlers read the physical memory address 0x40E to get an address to work with, and subsequently write one byte to the address in case of an error, even if it is SMRAM.
This issue is identical to INTEL-SA-00057, which is often described as Aptiocalypsis, however BIOS version 303 for UX360CA does not contain fixes for them, allowing an attacker with write access to physical memory and an OUT instruction to overwrite the contents of SMRAM.
By doing the following:
-Check that physical address 0x40e is zero.
-Write SMRAM address, say 0x88400000, to physical address 0x104.
-Issue SMI 0x400x88400000+2 update to 0x7.
This can be used to execute arbitrary code in SMM like this:
-Find the address of the SMST table in SMRAM by doing the following:
-Get the physical address range for the UEFI runtime code from the contents of value.raw in HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader Reserved
-Find the SMM_CORE_PRIVATE_DATA address by scanning the "smmc" signature from the address range.
-Overwrite the pointer to the SmmLocateProtocol function at offset d0h SMST using the write primitive above. The value is updated to 0x07070707.
-Write shellcode to physical memory 0x07070707
-Start another SMI that calls Smst->SmmLocateProtocol, eg SMI 0xdf. The shellcode at 0x07070707 is executed in SMM.
Arbitrary code execution in SMM would allow you or an attacker to bypass kernel and hypervisor security measures such as HVCI, as shown in another SMM vulnerability report, as well as provide persistence by updating the contents of the SPI Flash (BIOS).
Bios_uefi
Here, I would like to talk about the project as a whole:
The goal of the project is a free, stand-alone resource for anyone who wants to learn more about information security.
The repository has a comprehensive list of tricks, tools and tactics where you can learn a lot and refer to the results in the future.
And the most delicious, one of the main goals is the fact that everyone could use the software as a training ground, where there is an answer to any question regarding the topic of interest. reference/revocable method for the material.
small disclaimer
This project is intended for educational purposes only and does not target you to carry out illegal activities.
Html version can be found here
There are materials about low-level attacks (firmware / BIOS / UEFI).
It contains articles, blogs, notes, documents, general attack materials, which will tell what it is and what it is eaten with. For example, Intel controls, about AMD PSP and UEFI, and for understanding, illustrative examples will be given, of course, disadvantages will also be mentioned.
And finally, a small article about MoonBounce
Attack
The UEFI implant, discovered back in the spring of 2021, was introduced into the firmware component CORE_DXE (also known as the DXE Foundation), which is called at the beginning of the DXE (Driver Execution Environment) phase when booting UEFI.
Among other things, this component is responsible for initializing the necessary data structures and function interfaces, in particular the EFI Boot Services table.
This table contains a set of pointers to procedures included in the CORE_DXE image and called by other DXE drivers in the boot chain.
The malware starts by using a set of hooks that intercept several functions in the EFI boot services table: AllocatePool, CreateEventEx, and ExitBootServices.
The hooks redirect the execution of these functions to a malicious shellcode appended to the end of the CORE_DXE image. The shellcode, in turn, creates additional hooks in the subsequent components of the boot chain, specifically in the Windows bootloader.
This chain of hooks allows the malicious code from the CORE_DXE image to be propagated to other boot components at system startup, and to inject a malicious driver into the address space of the Windows kernel.
The driver, which runs during the initial phases of kernel execution, deploys the malware in user mode by injecting it into the svchost.exe process after system startup.
And the user-mode malware accesses the hard-coded C&C URL (hxxp://mb.glbaitech[.]com/mboard.dll) where it requests the next stage payload to run in memory, but failed to retrieve it
The user-mode MoonBounce loader and multiple instances of ScrambleCross accessed domains with the same second-level domain name, which at some point knocked on the same IP address.
Another important match is the unique self-signed SSL certificate.
It was found on some servers in this campaign (and only a few dozen non-campaign servers). This is an important fact that indicates the actions of a certain attacking group in the network.
Goals
The purpose of the software was to exfiltrate information from individual computers.
This behavior is consistent with some of the past operations of the APT41 group, which in most cases carried out attacks that interfered with the supply chains of targeted companies or theft of confidential information, intellectual property and personal data.
Conclusion
On such a fine note, we end our conversations about exploits, thanks for reading, I hope this collection of materials will be useful to you. 📚
You can read more about bootkits at the links:
By attacks
Protection and detection
More details but less practice
About system boot
Base and a little about attacks
Thanks for reading❤️
And remember:
Even if you can meet the Queen of Spades in the flower garden (by talking to the guards about the flowers growing in this garden), the guards of the Queen of Spades will shamelessly cut off your head. So be careful, unless of course you are a Cheshire cat 🐈⬛🌹