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!

Parallels Desktop allows for virtual desktops and applications to any device. It acts as a virtual machine that is isolated from the host. This article targets the Hypervisor of Parallel Desktop. Because the hypervisor is accessible by any user, this looked like a juicy target.

This research took a bunch of reversing in order to get the actual image for the hypervisor. The content was a zlib-compressed binary that skips the first 12 bytes. Additionally, only some symbols were left in the code.

The vulnerabilities exist in the hypercall functionality. This interface is for Read Performance-Monitoring Counter (RDPMC) for communication between guest and host. The first vulnerability is a heap overflow because of a user provided size in a statically heap buffer. The overflow occurs in the UEFI name variable.

The other bug is a time of time vs. time of use (TOCTOU) bug that resulted in an out of bounds read. The data size of a UEFI request is written to shared memory before validation. After writing, the size is validated but then refetched after this validation. By allowing for the validation to happen this editing this value, an OOB read occurs.

In order to exploit the race condition the author used a flipping strategy. On one thread, set the variable to be a larger size than what should be allowed for the request. In the other, set the status to 0 by making a call to some function. Eventually, this flipping strategy will trigger the OOB read.

Interesting bugs in a lesser known interface. Bugs tend to be in the obscure places.

Composer is a package manager that is used for PHP. In Python, a reasonable comparison is pip. Finding vulnerabilities in package managers can compromise users at scale.

When downloading a package Composer makes a query to Packagist in order to get the metadata for the package. In order to do this, Composer uses several system commands by using ProcessExecutor so that they do not need to redo the logic for different version control software, such as git.

The URL for this request is escaped properly to prevent straight command injection. So, what's the problem? The command itself can have parameter or arguments injection into it! Using this argument injection, arbitrary parameters can be added to bash calls.

Using this argument injection, it was possible to specify another configuration for the hg version control code. This configuration can have bash aliases defined in it (lolz). With this, we can create an alias to pop a shell :)

Argument injection is difficult to exploit but is super interesting to look at! It is commonly overlooked but can have dangerous consequences.

This bug is a combination of a few issues within the Windows Desktop Manager (DWM). Neither of these issues is a vulnerability by itself. But, by causing a desync in the understanding of a structure, it becomes a vulnerability.

The DirectComposition API is used for Windows bitmap composition with transformations, effects and animations. This component is known to be buggy and has many reported CVEs already. To send batch commands, a special LPC format is used.

When adding a property with this API, there is an issue with input validation. This adds a new property to the resource but only validates the propertyId and storageOffset after it has already been added! Anytime validation is done after an action occurs, that's a sign of something bad to come.

The same code path for the Update functionality does zero validation on this though. Because of the complete lack of validation the attacker can use this as an out of bounds write on the propertiesData buffer if a few checks succeed on the data. However, this version only existed in userland and not the kernel (unlike the first bug).

By using the first bug to increase the number of properties, an error to occur without fixing the counter; this resulted in a desync for the amount of properties and the count for the amount of properties. Because the length had been changed, the update could now be used for an OOB write.

Finding validation after some action has already occurred is a wonderful source for bugs that cause desyncs. Awesome bug and a straight forward write up.

XML External Entity Injection (XXE) is a common attack against XML parsers. When a full XML file or user input being inserted into pre-formatted XML file, a user can include entities. These entities allow for reading files on the local machine, SSRF and sometimes, even RCE. This attack is devastating when it is found.

In Wordpress, there is a Media Library that allows users to upload media files for their blog post. To extract meta information from these files, WordPress uses the getID3 library where some of this information is parsed an XML data.

In previous versions of the XML parser, Wordpress explicitly turned off entity loading for simplexml_load_string. This was because a vulnerability was discovered in this component back in 2014. So, they patched it but what is the issue?

With PHP8, the function libxml_disable_entity_loader was deprecated because the library by default does not parse entities. So, in versions of PHP 8+ the code is not ran.

However, the flags for the function specify LIBXML_NOENT which ENABLES the entity substitution! Damn, one would think that by using the default off version of the library that this bug would be fixed. It simply reintroduced the bug into the ecosystem.

This vulnerability is exploitable in several locations but all comes up to the bug above. This just goes to show that patching is just as hard as writing secure code in the first place. If I were participating in ZDI, I would just look at patches of old bugs and see if they were sufficient.

This router handles a lot of its functionality through a CGI interface. Because we fully control the HTTP request being made to the server and this is a C binary, it's time for memory corruption!

The vulnerability is in a memcpy based upon the Content-Length and the size of the file being uploaded. Because the size of the copy and the size of the buffer are controlled by the attacker, this creates a buffer overflow. This was the original bug here but it had a terrible patch.

The patch simply checks to see if the character before the Content-Length is a newline or not. By conforming to this, the original bug still exists but it makes exploitation a lot harder.

The exploit uses a fd overwrite (or fastbin dupping) in order to control the next location of the chunk from the heap of this requested size. However, malloc_consolidate is called with a later LARGE allocation (which destroys our bin). So, a way around this needed to be discovered.

On older versions of Malloc there is a negative indexing bug with chunks being freed. If a size of 0x8 is used, then the fastbinsY array index is set to -1 and overwrites another value in the malloc_state. What's this value? max_fast! This controls the consolidation is done at. Hurray!

So, the attack looks like this:

1. Trigger heap overflow to create a fake heap chunk with a size of 0x8.
2. When the fake chunk is freed, it will overwrite the max_fastvariable.
3. Overwrite 'fd' pointer of a heap chunk.
4. Allocate our fake chunk (with our controlled data) overwrite the a GOT entry with the PLT of system.
5. Trigger the function with the overwritten GOT to pop a shell.

The article has a nice POC at the end of it as well! It is fun seeing real world heap exploitation of older versions of GLibC malloc.

The days of a single password being used are gone because of the single point of failure. With 2FA, TWO authentication points need to be compromised. Duo is a provider of the second factor of authentication. So, a bypass for this is quite impactful.

With Duo 2FA, a code must be requested by the application. When this request to the server is made is where the vulnerability lies at. By simply copying the content of the hacker request, as opposed to the user request, the payload was sent directly to hacker instead of the main user!

This first bypass allowed for the location of the data being sent to be changed! However, this required the attacker to have access to this Duo portal in order to work.

A second variant was found AFTER requesting the code. When the code had been requested, a transaction id was constantly pulled to see if this had gone through. By sending the transaction id with the other device, the backend could be tricked into accepting the attackers verification code.

This bugs were quite simple and just about anybody could have found these. It is amazing that these bugs stayed in the Duo ecosystem for so long without anybody realizing. According to the authors of the article, Duo was incredibly swift about fixing the vulns and was pleasant to work with.

The authors of this article recently took a course on Windows Exploitation at NULLCon and were out to prove they got something from it. The final challenge was a poorly built driver to exploit.

The driver takes a kernel pointer and writes a value to that location. This was found through dumb fuzzing within seconds. Clearly, pointers should not be passed directly to the kernel and write to.

The interesting thing is that the location is controllable but the value is not, making this a WRITE-WHERE primitive. By abusing this WRITE-WHERE primitive on the credential information (Present & Enabled) this gives the process complete privileges.

The author of this code attempting to review a binary in Hopper (the free version) but was unable to. Why is this?

Hopper attempts to detect itself, as if you could remove the license check then it would be super easy to run the binary for free. One of the ways the detection occurs is by looking for a particular string that denotes the owner of the company.

By adding this string into the binary, Hopper thought it was reversing itself! Haha, fun and silly trick to prevent some reverse engineering.

MacOS seriously attempts to validate that all applications are legitimate. This is done via checking for cryptographic signatures on the binaries, notarization (scan the application for potential issues), Gatekeeper (are you sure you want to launch this app?) and File Quarantining.

MacOS applications are bundled in a weird way. Each .app file actually has many sub-directories that have libraries, the binary and other assets. What is bare-bones application? All you need is a binary that matches the main folder in app_name/MacOS/app_name.

For some reason, this does not trigger any of the security checks above though!? The author stumbled upon this bug by simply trying to get a bare-bones app to work. The bulk of the article is about reversing this functionality on MacOS.

The bug is fairly simple: only bundled applications are validated. What makes up a bundled application? It must have an info.plist. Because of how simple this bug was, it was being exploited in the wild. Yikes!

Sometimes, bugs just fall out of thin air... Reformatting something in a way that violates the developer constraints but still works is where lots of bugs live at.

The CI/CD pipeline for Bitbucket must be user isolated. If it's not, data can trivially be stolen or altered during the build process. This bug was an escape of the CI/CD pipelines.

First, a user must escape the Docker service. This was done using known techniques with CGroups release agent functionality. So, step one is complete.

The second step is the new/unique part of this article: escaping the kata VM. The kata VM is essentially Docker but with a few slight variations in functionality, such as guarantees of container isolation.

With Kata containers, the author started looking at the mounted file systems. An important thing to note is that the hostPath functionality was used in order to mount paths from the container host directly into the container. In order to make the lives of devs easier, one of the mounts was /user/bin/docker.

The mounting process for Kata was quite complicated with a bunch of nesting and other steps taken in between. Although the permissions from within the Kata VM appeared to be ReadOnly, the HOST disagreed with this! The HOST believed that the docker mount was rw.

Because the mount was actually writable, the Docker binary itself could be altered! Damn, that's code execution as soon as the binary is ran.

The author found an additional mounting issue on the Kubernetes pods version of this. The bug was in an improperly mounted log directory. By writing to this directory with a symbolic link, it was possible to redirect the location of the write in order to overwrite arbitrary files.

Overall, awesome bugs with interesting impacts! Containers are awesome in practice but are still complex beasts with bugs in them.