Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The Windows Printer Spooler system has been riddled with bugs since the beginning. Because of this, the authors decided to tackle this attack surface on Windows.

MS-RPRN (Print System Remote Protocol) can add or update a printer driver. Because it would be annoying to install a printer driver from an online website, the printer itself provides a driver for the service. Obviously, this is code execution by design! So, in order to prevent this, the service needs to be authenticated or approved by the user.

If an attacker can bypass the authentication, this would be game over, as the driver would be added. Normally, this would require the client to have the SeLoadDriverPrivilege permission to call the RPC function. However, there is a bug in this logic!

The function ValidateObjectAccess is what should validate access. One of the fields that checks for authentication is user controllable that controls some of the configuration. This field allows for the bypassing of the security protection to add the driver! This is all the article reads; they do not say what the field is actually used for.

They had to bypass an additional annoyances inside of the function RpcAddPrinterDriver as well. Spooler checks to ensure that UNC paths are not used, but it misses one of the paths being used. Secondly, the other file shenanigans needed to be done in order to get the proper DLL to be loaded.

Overall, this is a horribly impactful bug that allows for the taking over of Domain Controllers. The bug is fairly simple but requires a little finesse to get working.

Kernel Based Virtual Machine (KVM) is the standard Linux-based cloud hypervisor platform. Besides Microsoft Azure, every other Cloud provider uses KVM. This vulnerability is in KVM AMD specific code that allows for a full virtual machine escape.

KVM is an open source type-2 hypervisor (runs on top of OS so it's not bare-metal). KVM is implemented with a handful of kernel modules that expose low-level IOCTL APIs to interact with user space processes so that the Virtual Machine Manager (VMM) can manage the environment. For VMM's, popular choices are QEMU, LKVM, Crosvm and FireCracker.

The design of KVM was quite smart: all of the complex low-level code for providing virtual disk, network or GPU access can be implemented in userspace besides a few performance sensitive operations. Because of this, the attack surface is quite limited! A KVM vulnerability would result in compromise of the entire host, but it would be hard to find.

Nested virtualization is about layers of virtualization. Recently, this has became more popular has Virtualization-Based Security has became more prevalent. AMD's virtualization extension is called SVM (Secure Virtual Machine). When making SVM instructions in a nested env, the host needs to intercept these calls from the guest and emulate the behavior.

The virtualization works by adding six new instructions to x86_64 that are enabled when the SVME bit is set on the EFER MSR. The VMRUN command is responsible for running a guest VM, which is done by accepting a page-aligned physical address which describes the state and configuration of the VM called the Virtual Machine Control Block (VMCB).

Inside of the VMCB, there are two main parts. The State Save Area stores the values of all the guest registers including segment and control registers. The Control area describes the configuration of the VM, such as the features enabled for the VM and describes the intercepted actions such as page table addresses. For nested virtualization to work, KVM intercepts execution of the VMRUN instruction and creates its own VMCB based on the VMCB the L1 guest prepared.

Where do bugs live at? Complex and difficult to understand code! Nesting virtualization environments seems like the definition of complex to me. Because of this, the author of the article took to manual code review in the SVM to try to find logic bugs.

When switching between contexts, the KVM cannot trust the guest provided ENV and needs to be validated. When this validation is being done there is a classic problem: double fetch. The validation is done on the first fetch then the data is asked for again.

By passing the data once while it's valid the second configuration can be invalid; this is known as a time of check vs. time of use (TOCTOU). So, what can be done with a weird VMCB configuration?

The SVM VMCB configuration contains a bit that enables or disables interception of the VMRUN command. When this bit is raced, crazy things can happen! Normally, when the function nested_svm_exit_handled is called an exit should occur for the layer 2 virtualized machine which results in the function NESTED_EXIT_DONE being ran from L2 to L1 that lets L1 handle this.

However, when the svm->nested.ctl bit is set to 0, the VM will be handled by the KVM itself for the L2 VM. This results in a second call to nested_svm_vmrun which the code was NOT written to handle. As a result, the L1 context is overwritten by the L2 guest data. This becomes a security issue because the Model Specific Register (MSR) is controllable, which holds many permissions bits.

Eventually, this edge case becomes exploitable because the SVME bit of the MSR_EFER register does dynamic allocations. When the disable SVME call is made in L3, the memory for this in L1 is lost is freed. Eventually, this can be overwritten particular 0s and 1s to give guest access to the host MSRs.

What does having access to the MSRs actually do? The VM_HSAVE_PA value stores the physical address of the host save area. If the MSR points to a memory location under the attackers control, a fake malicious host can be used to execute our own code. Although, this attack was not as straight forward as it sounds.

With the ability to control the flow of execution, the author still needed a information leak in order to proceed (ASLR strikes again). From a BUNCH of reading, they came to the Instruction Based Sampling (IBS) as the perfect way to get an infoleak. It samples a bunch of instructions and collects a wide amount of information. This information is logged in the MSRs, making it perfect for the memory leak.

Finally, the author created a kernel ROP chain. This payload disables the write protection on the kernel memory addresses then allows for the CPU to copy a larger piece of shellcode to some where in the kernel. At this point, with code execution in the kernel, it's a matter of fixing things up and you have won!

This VM escape was from a fairly simple TOCTOU bug. Even though the impact was not easily apparent, by fiddling with the settings on this the author eventually compromised the machine. This was a bug first then what can be done with it second. This goes to show that any bugs can be used in the right hands!

Dell SupportAssist is an overarching solution on all Windows systems that can help/monitor hardware and software problems. BIOSConnect is a feature of SupportAssist that allows remote OS recovery or firmware updating. If there are a vulnerability in this, it would be quite bad!

The BIOSConnect feature to accept any valid wildcard certificate when it connects to the Dell server. Because anybody can create a valid certificate, this breaks the security of DNS. Now, an active interceptor can spoof the endpoint!

With UEFI Secure Boot is disabled, this allows for a malicious image to be loaded via the BIOSConnect. Eventually, this allows for code execution within the pre-boot environment.

With Secure Boot enabled, it is not simple enough to load the malicious image. This is because of signage and other things that occur when loading the image. This means we need more vulnerabilities in order to exploit this!

Because vulnerability #1 allowed for MitM attacks, we can abuse that. The data being sent back has parsing issues that lead to buffer overflow vulnerabilities in the OS recovery process and the other in the firmware update process.

From a real world perspective, I doubt many people would be seriously effected. First, you need an MitM position, which is not trivial to get. Second, the bugs are only possible to exploit when this service is in use. I personally have never used this service before, meaning this would take a long time to exploit.

I'm not a huge fan about how this post was marketed. Although I love the research, they do few things that are frustrating. First, the actual researchers are never credited in the article (besides the person doing the webinar, maybe). Secondly, they do not include all of the details; instead, they are waiting until DEF CON to expose. And finally, because the service needs to be used for this exploit to work and the MitM requirements, I think this is overhyped.

When trying to authenticate to Cisco Hyperflex requests are sent to the /auth in the Nginx configuration. This is then sent to a localhost server that parses the authentication request.

The authorization handling function parses /etc/passwd in order to get the hash and salt of the password for the provided username. In order to check the hash, the following code snippet is used: python -c 'import crypt; print crypt.crypt("", "")'.

Because the password is completely controllable in the command, this is vulnerable to command injection! By escaping the double quote ("), it is possible to add unlimited commands to this request. Now, an attacker can execute arbitrary commands on the server from an authenticated user.

While reversing the application, they noticed traffic being forwarded to port 80. After finding what Java call this was being used for, they found code that was taking a command string into and putting into directly into a /bin/bash request. Since this was not being filtered and was executed in a shell, command injection was trivial to do.

The final vulnerability was an unauthenticated endpoint that allowed for file uploads in the Nginx configuration file. Of course, this was vulnerable to directory traversal, leading to a file write primitive to achieve code execution later.

These vulnerabilities are fairly simple command injections. However, the reverse engineering to find these vulnerabilities is the interesting part. Additionally, Java normally fixes command injection. Somehow, this product was able to disable all of the protections.

In part 3 of a 4 part series, they decide to takes things to another level! While glitching Secure Boot to control the instruction pointer, this required control over a value being written. Because there is Flash encryption, which prevents the bootloader overwrite, they decided to bypass the Flash Encryption protection.

The Flash Encryption protection is used to assure the confidentiality of the code and data stored in external flash. Decryption of the data is done transparently to the processor by the flash controller. Because of the encryption, it is next to impossible to alter the code on the flash chip properly.

There is a main decryption key. From this one key, each 32 byte block has its own decryption key. But, the ciphertext is in 16 byte blocks.

The boot process has multiple sections. With these each of these sections, the some small information is printed out to the console. In particular, this is the length and the load address. This is printed out after decryption but before signature validation.

If one of the sections of the bootloader was aligned to 16 bytes instead of 32 bytes, the memory could be swapped with a section with the same to print the output. This creates somewhat of a decryption oracle! By swapping the last 16 bytes of slot E with F, we can brute force a value that comes up to the address that we want. This would take 10+ years though.

The idea is to use the glitch PC attack in part 2 but while only controlling a single value on the Flash. The goal was to find a location at the end of slot E (which we could partially control with the above vuln) that when glitched used this value as the PC.

After 300K glitching or 12 hours of experiments, the authors were able to cause two successful glitches that used the value at the end of E. This attack demonstrates it is possible to control PC with glitching attacks when only a single value is controlled on boot. Additionally, the flaw in the cryptography was the in for this attack.

In a previous post Raelize demonstrated that it was possible to glitch the ESP32 chip via electromagnetic fault injection. In this, they combine this known issue with the idea of altering a copy operation to set the PC register.

All of this sounds nice in theory: you control the data being copied but not the location of the data. So, you use the glitching in order to affect the address this is getting written to. But, how practical is this!? Apparently, this is legit!

During the boot operation, devices copy data from external NVRAM (flash) into volatile memory. With physical access, NVRAM can normally be altered, the value of these variables can be edited in order to control the value during the execution.

The goal of the attack is to load an arbitrary value into the PC register while is copying data. In order to control the data, they overwrite the bootloader with arbitrary data. The processor will copy the data over prior to the signature check occurring.

The bootloader is overwritten to a ROM function pointer that prints data to the serial interface multiple times. Overwriting with this data does with the continuous pointer does two things: removes the window for writing the proper data and makes it easy to observe with the glitch has succeeded.

Since the bootloader is copied at the end of the flash activity, the glitch is added during the copying process. Hopefully, when this copy occurs, the glitch will cause a different address to be written to, causing the output to appear over the serial console.

The first attempt failed when using the same glitch location on the chip as before. After this, they changed the location of the EMFI and found a place to cause the glitch.

After two more runs, they found the perfect place and timing for the glitch. They got a successful call to the serial output about 0.43% percent of the time! If this was a cryptocurrency wallet, it only takes one successful attack.

Why does this attack work? There is a copy loop that is a large wrapper around memcopy. On the Xtensa architecture, the return address is stored within the register a0. By corrupting an instruction, the glitch could move the ROM function address into a0.

In order to make it impossible to alter the bootloader, EspressIf recommends that customers use Flash Encrypt. This does not mitigate the vulnerability, but does make it significantly harder to exploit.

Physical device security is important but often forgot about. With physical access to a device, the ability to alter the device is now in play! Clock and power glitching are common and well developed. However, this article discusses Electromagnetic glitches, referred to as EMFI. EMFI is non-invasive, making it a much more practical attack.

For doing the attacks, they use the Riscure FI tool. But, there are a plethora of other tools that could be used, such as the Chip Shouter. These tools allow for automatic triggering, changing the type of glitch and controlling the timing of the glitches even!

When performing EMFI glitches, there are three important parts to a glitch: position, power and timing. Tuning these parameters, because of the incredibly large space, is difficult to do. In order to narrow down on this space, they run a test run themselves to see where the chip is vulnerable to attacks.

The test code is a simple counter that runs over and over again. If the EM effects the chip in some way, then the counter will be different. By automating this process, they were able to get a 30 by 30 grid of experiments on positioning and timing on the chip. Only a single location effected the counter. But, now, we know that the chip is vulnerable to attacks.

To time the attack on secure boot, the authors used the flash chip activity in order to time the attack. By randomizing the EM power and timing, they found three successful glitches that bypassed secure boot. This took about 35,000 experiments in about an hour of testing in order to achieve this.

Although this attack is fairly amazing, the amount of equipment used in this setup is unreal. They used an insane of amount of Riscure specific hardware in order to fine-tune and automate the parameters. Although this can be built by someone else, it helps to have the off-the-shelf tools.

For marketing and other reasons, detecting the device is common practice. From bots to difference UI experiences, changing this can be a good option. At first, the User-Agent string was used in order to determine a device. However, as the internet has gotten older, this has became more and more complicated.

At this point, it has became an arms trace for detection and prevention: this article is about spoofing devices and how to protect against it. There are so many tricks that go into figuring this out.

On mobile devices, there are a plethora of tricks for this. If its not touch capable, then the device is clearly not a mobile phone. Or, what about checking the screen resolution depending on the type of device it claims to be? This works too!

Another way to determine the device is system defaults. On different devices, emojis are represented in different ways. For instance, Apple and Android have a completely different unicode encoding for the smiley face. Additionally, default fonts are different on MacOS vs. Linux vs. Windows. By using the fonts, it can be determined what device is being used.

To top this off, a tool called Google Picasso fights device spoofing attempts in the Google Play store. It works by doing some rendering operations that are dependent on the browser OS and graphic hardware. Since the release in 2006, Cloudflare uses this tool in order ot prevent spoofing.

Overall, interesting article that calls the never ending race between device spoofing and device detection.

There are a plethora of third party usable protocols to gain access to information. OAuth is used to get access to information, such as Facebook friends. SAML and OpenID are used as a central management location for authentication (SSO). OpenID is built on top of the OAuth specification, which is the focus of this article.

The attack of this article is against an OpenID two factor authentication (2FA) implementation. While going through the basic test cases for 2FA issues (wrong OTP, brute forcing, etc.), they found nothing interesting. So, they decided to read the AMR specification.

One thing caught the authors eye: "...taking a dependence upon particular authentication methods may result in brittle systems since the authentication methods that may be appropriate for a given authentication will vary over time." This means that different authentication methods for 2FA may be allowed.

Once the author realized this, they used the AMR sms+password in the browser. Instead of the normal Google Authenticator window, a new window that was requesting a phone number appeared! Sure enough, adding the phone number to the account and responding bypassed the otp+password 2FA.

This simple trick of changing the authentication method to SMS instead of OTP caused a complete bypass of 2FA. Obviously, this is a serious security bug and they got paid out as such. In the future, reading specifications while testing implementations out things will be on my radar to find hidden attack vectors.

UEFI is the successor of the BIOS. Part of the UEFI specification includes Secure Boot, which is extremely complicated. This document is a wiki page from Intel that discusses Secure Boot and Intel's Boot Guard. My notes mostly refer to the book Rootkits and Bootkits but this is an additional good link that I wanted to include.

Secure Boot guarantees that only valid 3rd party firmware code can run in the Original Equipment Manufacturer (OEM) firmware environment. It should be noted that the UEFI Secure Boot assumes the system firmware is a trusted entity. Any 3rd party firmware is considered untrusted, but can be manually enrolled by the user.

Secure Boot is made up of two main parts: Verification of the boot image and Verification of updates to the image security database. Essentially, everything has to be cryptographically signed with part of the PKI. This is important because without Secure Boot the UEFI OS bootloader can be swapped out, breaking the rest of the process.

With a large key infrastructure, it is complicated to keep track of everything. Because of this, there are NVRAM variables that store an allowlist of accepted public keys and a denylist of public keys and firmware images. This article has amazing documentation on how the PKI works for Secure Boot, which is why this was included here.

Even with all of these protections in place, the root of trust is set into the initial bootloader. What if an attacker manually overwrites the SPI flash with this? Well, that is a valid attack that breaks the chain! An additional attack is to overwrite the NVRAM variables too.

In order to fix the SPI flash writing problem, Verified and Measured Boot are used. Verified Boot is ran as soon as the machine is powered on via hardware logic. Verified Boot has a public key in the hardware to ensure that the initial bootloader of UEFI is signed. Because the initial bootloader is validated to be secure, the rest of the system can now be known to be secure.

Measured boot stores cryptographic hashes of the OS loader and the platform initialization (PI) firmware. These hashes are stored in TPMs. Because the hashes are stored, the hash only tells us if the firmware has been modified, but nothing else.

Intel's Boot Guard runs directly after the ROM bootloader runs. This is cryptographically signed by Intel and cannot be modified. Boot Guard itself is an implementation of Verified and Measured Boot, but a lot of specific quirks to it. Once it is done with the system initialization steps, it validates then calls the UEFI firmware.