Offensive Conference day one
I’ve attend the Offensive Conference 2019 in Berlin. A in-depth technical security conference. What does in-depth imply? Exploit and technical talks with working exploits.
You’re getting some stuff at entering
On the following page I keep track of some notes:
I attend the first half of the presentations. One pattern I saw across was the heavy usage of fuzzer.
First talk was from a Alex Ionescu about reversing without reversing. Tl;DR look at all possible sets of information that are there. Funny because he could reference source from Windows and used into ReactOS. It was inspiriting and frighten at the same time.
Talking about the usage different approache to fuzz. He use of a Stream based Fuzzer approach. It’s a parser before the API call that will be consumed He think fuzzing like a water flow. He extend his concept with the idea of a Protobuf-based Fuzzing. I leak understanding of the Fuzzing nature in deep. However, this seems like a nice solution with a different approach to the classic fuzzing.
With his strategy he found a bug in the AppCache from Google Chrome. It was used for a exploit chain that lead to a RCE. New project is to moving the xnu kernel into a libary. libxnu will be fuzzed with his way. Issue with binaries because it’s hard time to patch.
This presentation is related to the previous one. It presents a exploit on the bug found before. Attacking the IPC in Chrome allows to exploit without ALsR. Defining the Cache of the image can be exploited. Each cache has a reversion. The important is that there is a pointer to the newest object. Creating a free-after-use bug with released cached. Allowing by exploiting the de-counter.
It is not possible to high-jack the vtable. Solution: Create a fake object.
Heap going upwards: Spray the Heap (with 200 MB) Creating blobs that are pushed on the Heap. They need a information leak and get any address from the heap.
There are using a ‘canonical cookie’ to get there. Another idea was to corrupt the size of
std::vec. Because of time constrain they had to throw away many ideas.
Exploitation of the 3D extension implemented for VirtualBox using chrome (not the browser). chrom is abstracion layer to translate Opcode to calls for the GPU. This is done by allowing the client to made special ops calls to the OS. He uses a Fuzzer. Key is that the uses the OpCodes for the virtualisation. It will take the opscode the right handler. There are some issues with debugging the VM. So he created a standard interface for VirtualBox.
The vulnerabilities, we can define buffer with arbitrary size and can read from. (ouch…) The vulnerabilities was boring for him, so instead of pushing shell code, he was redirecting stuff to execute instead.
Bugs so Nice they Patched them Twice! A (Continuing)? Story About Failed Patches by Jasiel Spelman, Brian Gorenc, Abdul-Aziz Hariri
The focus of this talk was to look at adobe software with JS API and how adobe does fix reported vulnerabilities. Most of the time, exploits were bypasses the fixes of a bug. For example they fixed a bug that was a buffer overflow. The overflow was located in a if-else statement. Adobe was fixinig only the if case, but left the same overflow in the else cause unpatched.
Have a classic heap overflow in the function. The fix after some months was to have a check for the value that was used in the exploit. Another sample of this is the xml parser. Note when you want to filter, you want to filter only a several nodes.
Bug: Defining a Marco that will work on debug with dynamic cast but a static cast in production… allows type confusion… Their fix is to replace all to a dynamic cast with null pointer fix. Can be crashed with a comment
Fast searching in pdf: Laxtek -> was not audited. Creating a index file, it can be corrupted and causing issues. It has not been fixed properly.
Possible to bypass bootguard. TPM is broken -> Can be MitM. Bootguard is no part of UEFI Lenovo has a .SMI over WMI function to disable BootGuard. Was found during a Windows update. Question: Could that affect a linux system?
There is a UEFI module that provide access to the SMM from lenovo. With the WMI you don’t need a kernel module to make SMI calls. Most vendors try to reduce the SMI calls to minimal attack surface. Question: using the legecy mode would help (older laptops)? Q: Affected laptops? List will be provided. Q: Possible to reset the state with a re-flash of the UEFI? Yes it will be. But only when then entry chip is begin re-flashed. Q: Could we use this to install coreboot on any Lenovo device.? Sure with no TB you can place what ever you want on it.
Stores value in the nvram .Embedded Controller is not a security boundary. EC has DMA access and can attack other components. There is a separate flow for update an EC, in theory it. But in reality, they don’t have one. EC vendor has an issue with their update process. A not name vendor does not check the hash for updates correctly. Site note: IBG is not used by intel itself. It seems to be even possible to enable CPU debugging from OS! (WTF!). You need to flip a single bit to disable the BG feature. After three reboots it did work. Alex statement is that BG is a Marketing feature. He wonders why lenovo does not consider RE in their Threat Model.
I’ve skipped some talks. But this one seemed to be a good one about skycaller. The classic syscall fuzzing is called Trinity. It’s a basic fuzzer with calling
random() on a syscalls.
Linux kernel devs do not care about CVEs, they rather care for fixing bug.
For the skycaller is a language to describe syscalls. Andrey is not a kernel expert. Skycaller works like any other fuzzer. It try to do handle all these manual work. For example create ways to reproduce found crashes. Skycaller is quite small with 2k LoC. There have quite a lot of todos, for example ToDo for the project: Replacing different corpuses
Showing a demo for syzkaller.appspot.com
USB provides an ID to the client, depending on id the will access the driver. USB can be seen with Wirehark. Skycaller will fuzz some of the usb stuff
The diagramm can be read better from bottom to the top.
- Using a Hypervisor to inject USB - vUSBf
The kernel implements usb in a background threat. Using something like the Tun/tap infrastructure with USB to inject USB messages. (It’s not essay to do this with the kernel) They implement this with Gadget and the usb dummy function. Gadget is limited, instead a own kernel module was programmed. He found 80 bugs, half of them fixed the other was ignored.
The gadget does not support every option of an USB device. For improvement he uses a dwc2 driver, that is used for creating driver using the Rpi Zero. The same bug for the smsusb was not working. The module was missing. A issues when testing the fuzzing on a real device, it might have not been connected correctly. Question: Why only half of the bug where fixed? A: Bugs might be lost on the ML. Maintainer not anymore active one the problem