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!

Synology DiskStation Manager is the Linux-based operating system for every Synology NAS. AppArmor is a Linux kernel security module that allows the system to restrict the capabilities on a per-profile basis.

The vulnerability is a simple misconfiguration of AppArmor. The profile for the synosearchagent profile did not restrict access to loading kernel modules. Now, by using the insmod command it is trivial to run code inside of the kernel.

Dell is a brand of computer used across the world. The author audited the Dell firmware update driver ( dbutil_2_3.sys) and found several vulnerabilities in it.

The first (and most obvious) issue is that the driver accepts IOCTL (input/output control) requests without any ACL requirements. This means that the driver can be hit by any user on the system to call the functionality of the driver. By calling a driver that takes in pointers for a call to memmove an arbitrary read/write vulnerability has been given to the user. Damn!

An additional vulnerability is direct access to IN/OUT calls in kernel mode. Using these instructions, it is possible to interact with the HDD and GPU with DMA operations. Direct Memory Access (DMA) operations from userspace is 100% game over, as it can be used to bypasses all security mechanisms the OS has put in place.

The main issue is that the driver does not require any permissions to run, allows any user to kernel instantly. However, these other issues could be exploited by an administrator to get kernel access, which is still a valid concern.

These bugs sat around for 12+ years without anybody discovering them. Sometimes, the best research is just finding the right target. Good research here!

The Nintendo 3DS is a handheld gaming platform several generations after the GameBoy. Streetpass is a functionality that allows passive communication between Nintendo 3DS systems held by users in close proximity, commonly used to share information such as Miis.

When a Streetpass sends a level of Super Mario Maker, the data is compressed. The buffer size is 0x18000 bytes (which is the maximum that is will receive). Because of this, the developers did not consider a bounds check for the size to be necessary. They thought wrong!

The decompressed section sits directly AFTER the compressed section. The parser will continue parsing until it finds no more data to be parsed! Because of this, the parser will attempt to decompress already decompressed data, causing a buffer overflow on the heap.

The 3DS does not have ASLR enabled and there appear to be function pointers on the heap. So, it is trivial to take this buffer overflow to code execution via a specially crafted packet.

This can be done in a drive-by fashion, sort of like Bluetooth level attacks. Although, what is there to gain from compromising a kids 3Ds!? Interesting find that reminded me of the Pokewalker hack as well.

Homebrew is a package manager for MacOS that is ran from the terminal. I personally use Homebrew all of the time. So, hearing about vulnerabilities is quite interesting.

The vulnerability exists in a Homebrew Github actions automation. A Github Action is something that is performed when something happens to the repository, such as a pull request. One of the actions is that if a pull request is simple enough, then it auto merges the PR.

The author could not find a vulnerability in the logic directly. So, instead, they went to the git_diff repository to see how the merge functionality worked.

The diff functionality is quite complex and has many interesting primitives for remote attackers. In particular, the git_diff added file information for where to write the file to directly into the file! With this in mind, it was possible to make a 0 line change PR that could overwrite a Ruby file in Homebrew itself.

The root cause was not in a vulnerability in the parsing library for git_diff. Instead, it was using the code in an unattended way; the authors of git_diff never expected an attacker to be able to control the file information when writing the tool. Overall, interesting finding where the issue is with the integration of technology.

Cognito is an SSO solution from Amazon. Somebody can log into the site and this has password reset functionality. This is implemented by sending a 6 digit code to the users email.

While testing the rate limiting, the researchers realized that something was off. Although the documentation said 5-20 failed attempts will result in a limit exceeded error, this limit could be bypassed using concurrent request via Burp Turbo.

An additional issue was found that the code had a cool down time. Once the limit exceeded had been introduced, some time later attempts could be made again because the counter would be reset.

The maximum they got to work was 1587 which is 0.16% of the space. This means that 1/625 times. With the cool down bug, the odds went down to 1/312. Because this attack could be repeated by requesting a new password reset token and this could be performed on multiple users at a time, this could eventually lead to user compromise.

Reset token functionality is incredibly hard to implement! Even with rate limiting, the limitations may not be enough. On engagements, I will make sure to validate that the rate limiting works with concurrent requests.

Unity package registries, referred to as UPM, work using the same protocol as the Node package manager (NPM). Unity allows for private registries to be used in this environment.

So, what would happen if a outside user created a Unity package with the same name as a private repo? Whatever has the higher version will be used during the installation process. This means that a malicious attacker who knows the name of an internal repo can hijack it.

The ability to hijack repositories has been a vulnerability as of recent. It may be worth taking the time to look at other packages managers to see if the public takes precedent over the private in some way. Overall, great find though!

Oxide is designing a computer from the ground up. With this in mind, nothing goes undocumented. While reverse engineering the NXP LPC55S69 ROM they found an interesting piece of undocumented functionality that allowed them to update the ROM. Sadly (or good for attackers), this code is accessible by non-secure, unprivileged user code thus allowing attackers to make runtime modifications to purportedly trusted APIs.

The purpose of a secure boot process rooted in a hardware root of trust is to provide some level of assurance that the firmware and software booted on a server is unmodified and was produced by a trusted supplier. By using a hardware root of trust, we can 100% know if the firmware has been modified or not.

The chip has a set of privileged APIs for directly accessing Flash, putting the chip into programming mode and so on. The issue is that the undocumented API is not considered 'privileged' which allows for the altering of the ROM itself. Luckily, although the ROM can be modified, it does not persistent across boots. So, this does not corrupt the root of trust.

With access to this API that allows for the editing of this ROM, we can give ourselves access to patch part of the privileged APIs. Then, when a secure-mode application calls this API, we control the execution from this point onward. This issue could be pre-mitigated if the memory protection unit (MPU) is turne, which restricts access to specified address ranges.

The rest of the article talks about how to call this API, the reversing process and so on. All of this is interesting but not ground-breaking. The one thing of note is that only 32 bytes can be written via this API, restricting the impact of the bug.

To fully mitigate this issue, new chips without this feature have to be designed. According to the manufactures current chips do not have this functionality. Besides this, choosing to use the MPU fixes this problem from a user standpoint as well.

A DEFCON talk that dives into the details of TrustZone-M can be seen here as well.

Originally, there were two types of users in Linux: privileged and non-privileged. However, this binary change was not enough for handing out permissions. So, Linux released capabilities, which allows for fine-grained control of the administrative permissions.

When creating a namespace and mounting to a file system, having all of the permissions is totally fine. During the execution on these files though, the capabilities permissions are not checked! This was because a wrapper function with permissions check was not used.

Because of the lack of permission checks on the capabilities on the outer namespaces, the author writes over the user process information to become root. So, they just win at this point with an LPE on Ubuntu.

The remediate of the bug was done in a better than expected way. Instead of waiting for more OSes to make the mistake of not calling the wrapper function, the permission checks were made inside of the regular function. Centralizing security always helps.

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.