This year again we were a sponsor of Hexacon, the hot new offensive security conference based in Paris. This time four security researchers from the team attended awesome trainings and after that seven consultants from RandoriSec went to the second edition of Hexacon conference. As usual, you can find a quick review of our favorite talks.
A Comprehensive Review on the Less-Traveled Road: 9 Years of Overlooked MikroTik Pre-Auth RCE (Ting-Yu Chen)
Mikrotik is a supplier of network infrastructure components. Their equipment runs a system called RouterOS. Ting-Yu Chen, aka NiNi, started by a detailed state of the art, enumerating previous research and vulnerability found on these devices. RouterOS is a Linux based OS, but it does not offer a system-level access. Everything is done through their own configuration interface (e.g.: WinBox GUI). This explains why most researchers published on jailbreak, in order to obtains a proper lab environment. RouterOS internal heavily rely on their own IPC, most of the business logic is scattered around various daemons, exchanging Nova message. This IPC layer is built upon Unix socket, using the binary loader for routing the messages from the various processes.
Later on, he dug on the blind spot of this previous research. He presented a nice pre-auth vulnerability, lying around for many years. The bug resided in the RADVD binary, responsible for link-local advertisements of ipv6. The bug comes from the parsing of the Recursive DNS Server Option RDNSS. The vulnerable binary create a tree from the RDNSS list options, if the RDNSS list is large enough, it will overflow a statically allocated stack buffer. Nini presented how he exploited it, and described their attempt to use it during the Pown2Own 2017 at Toronto. A major problem arose, when trying to use the exploit from an Ubuntu system, it never worked. Debugging this issue led him to find a race condition due to the non-blocking method.
This was a really nice talk, the author plan to release its tools to ease the reversing of this vendor at https://github.com/terrynini/routeros-tools.
Bypassing the Secure Kernel/Core Isolation (HVCI) memory protection (Viviane Zwanger and Henning Braun)
This presentation is about the Hyper-V Core Isolation (HCVI) introduced in Windows 10. This protection is based on Hyper-V virtualization and is designed to forbid malicious kernel memory pages.
On systems where HCVI is activated, the OS components run on two levels:
- VTL0: the normal world, basically the operating system;
- VTL1: secure world, which is a minimal kernel running secure applications called “trustlets”.
There is no way to deactivate or patch security checks on memory pages, as they run in VTL0, but they can be fooled because they are based only on the page security attributes.
In other words, if the PFN of a page is patched with another PFN of another memory page, the checks will be done on the latter. This is the principle used behind Fabius tool the authors developed.
Here is the general idea to patch a read-only page:
- Create a copy of legit memory page to modify (R–) inside a new rogue memory page (R-W).
- Modify the content of the rogue memory page as wanted.
- Patch the PTE to change the PFN from the original legit memory page to the modified rogue memory page.
The only requirement is to be able to have an arbitrary R/W primitive in kernel land. This can be achieved using a vulnerable driver, like the ones referenced in https://www.loldrivers.io/. The shown example allowed reading the memory of a driver containing sensitive data on a computer with HCVI enforced.
Here is the FKIE department’s GitHub repository: https://github.com/fkie-cad.
Note: At the time of writing, the tool was not published.
Back to the Future with Platform Security (Krzysztof Okupski)
Intel hardware vulnerabilities are very popular and well documented. The well-known CHIPSEC tool allows users to monitor their Intel-based hardware easily, and the research done on this makes it less vulnerable nowadays. On the other side, there’s no tool for AMD hardware, and there’s also less research, so the IOActive team developed a tool named Platbox based on their research. They managed to find powerful vulnerabilities using only reverse engineering and black box testing without access to restricted documentation. The bug found was due to a wrong AMD’s SMM configuration.
The SMM, also known as Ring -2, can only be triggered using a System Management Interrupt, those can be triggered from software SMI generated by SMICmdPort. There are ASEG and TSEG, which are two physical memory ranges protected for SMM code. The segment protections could be disabled because the MSRC001_0015[SmmLock] register wasn’t set.
They also looked at the SPI flash configuration on some laptops, where they found there was no restricted SPI command, so they could from the OS read and write to the SPI flash. Using SPI, they managed to write to the SPI flash thanks to the Insyde SMI handler from FwBlockServiceSmm, which exposed SPI read/write/erase features. They just needed to satisfy a check done before the vulnerable code by proxyfing through XxxRuntimeDxe.
On modern systems, AMD’s Platform Security Processor has a protection called RomArmor which allows writing to only specific SPI regions from the host. They also implemented a Platform Secure Boot as an implementation of a hardware root-of-trust that ensures the initial phases of the UEFI BIOS firmware haven’t been tampered and is the main line of defense against persistent firmware implants. Sadly, the Acer Swift 3 doesn’t properly configure the PSB fuses, thus enabling a persistent firmware implant.
Their tool, Platbox, can be found here. Using it, the user can get details about the configuration of an AMD based machine.
A 3-Years Tale of Hacking a Pwn2Own Target (Orange Tsai)
Orange Tsai presented his 3-year journey with Sonos as a Pwn2Own target.
The saga began at Pwn2Own Tokyo 2020, where Orange managed to discover a buffer overflow vulnerability in the firmware parser of the Sonos device. Unfortunately, the developed exploit for this vulnerability only worked on an old firmware (2018 version) and failed with the latest one, resulting in an unsuccessful attempt to take over the target for the Pwn2Own 2020 edition.
As someone who doesn’t like the feeling of defeat, Orange returned to Pwn2Own Austin 2021, targeting the Sonos device once again. This time, despite the initial setback of discovering a fake buffer overflow vulnerability due to the fault of IDA Pro, he successfully took over the target by achieving code execution on the Sonos One speaker device, exploiting an Integer Underflow vulnerability found in the parser of ID3v2 tags, which earned him a substantial $60,000 prize.
In the third year, Orange returned to Pwn2Own Toronto 2022, once again targeting Sonos. His decision to continue focusing on Sonos for the past two years, which had proven to be a low-cost investment in terms of time but yielded a high return in the form of discovering numerous bugs, made it a rewarding choice. This year, he had a full three months to work exhaustively on this target, further increasing the potential for success.
The research for this year presented a significant challenge, as Sonos had already implemented all binary protections on the device. Despite these obstacles, Orange managed to discover a Stack Clash vulnerability and an OOB-Write vulnerability, for which working exploit PoCs were developed on 9/19 and 10/8, respectively. Surprisingly, the vulnerabilities were silently patched by Sonos on 9/20 and 18/8. There were doubts about Sonos reviewing the crash dumps uploaded by the device every 5 minutes, which may have led to the silent fixes. Orange continued the hunt for another bug anyway, and just before 2 weeks of the deadline, he found out that the fake buffer overflow discovered in 2021 turned out to be a real bug after the October 2022 patch. This time, he didn’t forget to disconnect the device before exploiting the bug to avoid the crash dump report and thus successfully took over the target for Pwn2Own Toronto 2022 edition. The lessons learned from this talk emphasize that persistence and choosing the right paths are the keys to success in bug-hunting journeys.
Bug Tales: Life and Death in the Sahara (Seamus Burke && Aaron Willey)
This conference has been presented by Seamus Burke and Aaron Willey and talked about the vulnerability discovered in the Qualcomm’s Sahara protocol.
The Sahara protocol is used to communicate with the Qualcomm bootrom over USB when the phone is in Emergency Download Mode (EDL). This mode can be reached by several ways like triggering test points or using the command adb reboot edl.
The vulnerability has been found in the command handler function of the Sahara protocol and leads to an unbounded recursion bug which causes a stack overflow. Seamus and Aaron used this memory corruption vulnerability to overwrite a function pointer in EL3 in order to control PC and execute a shellcode which gives persistence by breaking the secure boot chain. The exploitation ended up to give a root shell with a custom magisked ramdisk on a bootloader-locked Pixel phone.
XORtigate: zero-effort, zero-expense, 0-day on Fortinet SSL VPN by cfreal (Charles Fol)
In a recent red team assessment, Lexfo delves into the Fortigate SSL VPN, revealing a critical pre-authentication vulnerability (CVE-2023-27997). This flaw, existing on the VPN’s internet-facing interface, allows remote code execution without authentication, earning a CVSS score of 9.2 (though deemed a 10). Apparently, this vulnerability has persisted for an extended period, affecting versions on both 7.x and 6.x branches.
The vulnerability lies in the web interface designed for VPN authentication. By interacting with the URL path, particularly /remote/hostcheck_validate, an HTTP parameter named enc can be injected. This parameter, an older Fortigate feature, triggers a heap overflow bug.
The enc parameter, structured with seed, size, and data, undergo decryption using a XOR keystream. Lexfo outlines the decryption process and exposes a bug where size miscalculations enable the overflow to extend beyond its intended boundaries.
A clever exploitation theory is explained, involving XORing bytes in memory using a controllable keystream. cfreal narrates the journey from identifying the bug to developing a robust primitive for memory manipulation. It involves considerations of MD5 hashes, heap allocations, and insights into the underlying allocator, jemalloc.
The exploit details a practical approach, targeting the SSL structure, specifically its callback handler handshake_func. The non-PIE binary allows modification of function pointers, providing a route for a stack pivot leading to code execution. The exploit covers both 64-bit and 32-bit architectures, presenting a nuanced exploration of the exploit’s adaptability.
Fortinet promptly patched the vulnerability on June 8, 2023, with versions 7.2.5, 7.0.12, 6.4.13, and 6.2.15. Lexfo acknowledges the swift response but questions the depth of Fortinet’s previous security assessments, given the number and severity of vulnerabilities discovered over the years.
For further details, please refer to their Blog post: https://blog.lexfo.fr/cve-2023-27997.html Also, a PoC is available at https://github.com/lexfo/xortigate-cve-2023-27997/tree/main