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 Nginx DNS resolver is used to resolve hostnames via DNS for multiple parts of the popular reverse proxy. When validating the DNS address, there is an off by one heap overflow that could potentially lead to code execution. How is this done?

ngx_resolver_copy() function is used to validate and decompress each DNS domain in a DNS response. This is done in two steps:

1. The uncompressed domain name size is calculated. Once this occurs, the input packet is validated, discarding names containing more than 128 pointers.
2. An output buffer is allocated from the size calculated in the previous step. Then, the uncompressed name is copied into it.

In order to separate the resolved domains, a dot is used. The decompression step only believes that a dot can occur between labels. However, if the pointer for the domain is a pointer to NULL, then the dot is written past the end of the heap buffer.

If the size of the buffer happens to align with the heap size, this can be used to overwrite the metadata of the size of the heap chunk. 0x2E will clear the PREV_INUSE bit and set the IS_MMAPPED flag on the heap chunk. Because of the IS_MMAPPED, I would be surprised if this was possible to exploit by itself.

The end of the article mentions that this vulnerable function can be hit several times in the normal processing of a response, triggering multiple off-by-one writes. Additionally, with a poisoned CNAME, this could be used to cause an additional OOB write and OBO reads within the CNAME functionality.

Interesting finding in a high impact target. This was a simple logic assumption that was made about how the information was going to get sent back, even though the attacker does not have to conform to this.

The Apple M1 is an apple computer (no iPhone) that runs on ARM. This was recently released and has been a hot topic for people.

This vulnerability is described as a covert channel between different processes running on the system. Instead of using the memory, sockets or files, an attacker could use this to remain under the radar.

The ARM system register s3_5_c15_c10_1 is directly accessible from EL0. This register contains two bits that can be read or written to (0 and 1). This is a per cluster register that can be accessed by all cores in a cluster. This creates a two bits convert challenge that can be used to send data across processes.

This vulnerability has little impact on the system. However, it is super interesting! This can only be fixed at a hardware level and only affects Apple M1 users.

Instead of having only a password, lots of sites have the option to use an additional way to validate the users identity. This is called multi-factor authentication. Being able to bypass an MFA is part of the process to account compromise. This small article has a list of MFA test cases.

The first (obvious) issue is is lack of rate limiting. A few interesting attacks here:

• Brute forcing the OTP with an unlimited amount of requests.
• Creating an unlimited amount of OTP codes where the previous ones do not expire.
• Bypassing the rate limiting, depending on the restriction.

Besides the obvious attacks, there can be issues with the logic.

• The OTP's can be reused. Reused from different actions, or reused from other users.
• Old OTP tokens
• Client side validation only.
• OTP is leaked in headers or error messages.

There are some other interesting session management handling issues as well.

• 2FA does not need to be used to disable 2FA. Interesting attack!
• No 2FA on sensitive actions such as password resets, resetting a password or something else.
• Different APIs on web and mobile.

Overall, there are some interesting test cases in here to consider. Coming up with ideas for this is complicated to do!

eInk price tags are ESL (Electronic Shelving Labels) that allow for stores to dynamically change the prices as they see fit without placing a new paper on the shelf. Most ESLs are updated wirelessly and use a custom protocol to communicate.

When tearing open the device, Dmitry found a Marvell chip that angered him because of the lack of documentation. The only thing that he could find was that this used an Cortex-M3 processor 512K of Flash, 160K of RAM and it speaks Zigbee (an IoT protocol).

Cortex-M chips are debugged using an interface called SWD (single wire debugging). SWD only has two pins: one for data and one for the clock. After trying a large combination of pins, his CortexProg tool came up with a connection on pins 22 and 23! Sometimes, blind guessing works out for ya.

For whatever reason, the Marvell chip does NOT have any protections against reading out the ROM off of the chip. So, using the tool mentioned above, it was trivial to read 128K of ROM, set breakpoints and do anything a developer would want to do! The Flash was divided into a Bootloader, binary data, peripheral drivers and a Zigbee stack.

The REAL firmware was not in the ROM though: it was coming from RAM! The bootloader was using commands to directly interface with an internal QSPI bus. By writing a program to talk to the bootloader directly, it was possible to dump out the real firmware of the program. Even though they attempted to password protect this, they failed miserably with a default going to 0xFFFFFFFFF.

The protocol works over the 2.4GHz band using QPSK moduation at 250Kbps with a 5MHz channel spacing. After struggling to find a tool that supported QPSK modulation, he found a tool to speak raw 802.15.4 to interact with the device. Finally, to run custom code on the device, they took the bootloader and patched on his own code with linker magic.

A large portion of this article is about the display of the reader, which is not something I cared to take notes for. Dmitry creates his own firmware for the device with a bunch of interesting twists though. Dmitry picks up another one of these devices for fun though: the Chroma 74.

When the device turned on, virtually nothing happened. However, when connecting to the chip it had not been code locked! This allowed for reprogramming and firmware downloading in an easy fashion.

Overall, another interesting reverse engineering article from Dmitry.

In Part 1 of this, the author discusses a vulnerability to turn on Debug mode. In Part 2, they exploit a real device. The Logitech G Pro is a computer mouse that uses the nRF52 chip, which is what they choose a target.

The computer mouse had JTag and SWD modes disabled. This was dynamically tested on the chip. So, this was a perfect item to target!

Decoupling capacitors C5 and C15 are removed and the glitch output is connected to VDD_CPU (DEC1). Then, a The CPU is connected to a glitcher, which attempts the voltage glitching attack.

The fault injection is a Python script that is connected to an oscilloscope. After a specific time delay, a fault is injected (lower or raise the voltage) in order to skip over an instruction. This will HOPEFULLY cause the debug mode to never be turned off, resulting in a debug shell!

Once the debug mode is set up, Opencd via Telnet is used in order to dump the firmware of the computer mouse. With the firmware in hand, we can reflash the firmware with any modifications that we want! In particular, we can turn on the debug mode once again.

Overall, this is an incredibly bad vulnerability to find. This can be used to dump the firmware on all devices that use these chips. Unlike software, hardware mistakes are usually impossible to fix.

IIS for Windows server is a web server for hosting web content in both static and dynamic forms. This web server has a HTTP listener as part of the networking subsystem that is implemented in HTTP.sys. Finding a vulnerability in a web server allows millions of sites to be compromised in one go.

The Accept-Encoding headers dictates which content-coding can be sent back to the client such as gzip, * or deflate. This can be in the form of a list as well. An example with a list looks like Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5.

While parsing the string above, there are three states: supported, unknown and invalid. “gzip” is a supported content-coding string, “aaaa” is an unknown content-coding string, and finally “bbbb;” is an invalid content-coding string because it is improperly formatted.

The maintaining of this bookkeeping is done using a circular doubly linked list for all unknown content-codings. The vulnerability exists in the handling of the doubly linked list.

Initially, a root node is created for handling the unknown content-codings. After sending this information off in the response, there is a routine that unlinks and frees the nodes from the linked list. It starts with the first non-root node and does a multitude of sanity checks.

Once all of the content-codings have been parsed, if the list contains any unknown types, then they are unlinked from the root node that resides in the functions stack memory and relinked to a root node structure.

Here is where the vulnerability occurs at: the next and previous links of the original root node are STILL connected to the migrated nodes. By crafting a special HTTP Accept-Encoding header with a comma (,) a path can be taken that will migrate some but not all of the nodes.

With the root node being incorrect on one of the locations, it can still be used to access the migrated nodes! This can be used to free these pointers, even though they are the wrong ones to be freed. This results in a use after free (UAF) that is exploitable by a remote attacker.

This is an interesting bug! Like lots of heap vulnerabilities, it is just bad bookkeeping of pointers. By simply having the wrong pointers in one place, it creates an exploitable scenario.

Mobile Station Modem (MSM) is a series of different SoCs made by Qualcomm. This is the part of the phone that decoders SMS and radio messages, making it an interesting target for attackers. Besides the remote interface, there is an interface on the device that can talk to the chip as well: the Qualcomm MSM Interface (QMI).

The MSM is managed by a Qualcomm real-time OS (QuRT) that is not possible to dump, even on a rooted device. QuRT is managed by TrustZone as well. In order to have access to the OS, a vulnerability needs to be found in the QTEE or the Linux kernel. The purpose of this paper is attacking the MSM data service to patch QuRT on newer SoCs.

QMI communication is a client-server model in the QMI wire format. QMI ports are exposed to the Linux-running application CPU core inside the chip. QMI offers support for a multitude of services, such as the wireless data service (WDS), Device Management Service (DMS) and about 40 more. OEMs also add their own services to the chip as well.

To know where to fuzz, they found the IPC handlers and reversed the structures to know HOW to call them. They used QEMU in order to emulate the modem to find the vulnerability. This feedback based fuzzing (very little instrumentation).

After throwing random inputs to the service for a while, AFL found a heap overflow in the voice service. This vulnerability is simply a lack of bounds checking on the amount of fields are allowed to be used, which results in the linear heap overflow.

Overall, the vulnerability hunting of this interface was not the hard part: the setup was. By creating a realistic way to test this interface, it become much easier to find the vulnerability in the blackbox setting. The authors believe this vulnerability could have been used to dynamically patch the application processor and the modem itself.

IBM Spectrum Protect is a backup solution that provides data protection. It has a client-server architecture style with different types of nodes involved. The authentication protocol has a vulnerability in it though.

Here are the steps for the protocol:

1. The client generates session and validation tokens. This information is encrypted using the hardcoded AES key and sent to the server.
2. The server selects the password of the connecting user from the database and encrypts it using the same hardcoded key. In this step, the clients information is also decrypted using the encrypted password as the key.
3. The sever generates its own validation token. The server encrypts the clients validation token and its own token suing the decrypted session token.
4. The information above is sent back to the client where the client decrypts the validation tokens using the session token.
5. Once the token is known (from the decryption process), the validation token is sent back to the server.
6. The server validates the two tokens are the same. This is done in order to verify that the client actually knows the session token.

The authentication method above uses a challenge-response format in order to verify if the user has the proper secret. If they have the proper secret, then they can access the server. So, what if we could brute force the secret somehow?

Prior to the server sending back the the challenge, it encrypts the data using the session token. Because we know part of the ciphertext (validation token from client), we have a known ciphertext problem!

With the known ciphertext, the session token from the server side can be brute forced offline until we get the expected plaintext! This allows us to authenticate, even though we never knew the secrets.

Although this requires the brute forcing of a key, it can be used to find the password on the server. Considering this is JUST a password (and not an AES key), this seems doable after a fair amount of tries.

Besides the vulnerability itself, the situation for this is interesting. This is the old protocol, which has been deprecated for security reasons. However, this legacy authentication method is still enabled by default on newly created administrators. So, even though this is deprecated, it is still possible to use!

Overall, this is a fun vulnerability in the authentication flow of an application. The sending back of user data does not feel like a big deal until you realize that the password used to encrypt this data can be learned with offline brute forcing. Great find!

The CSRF attack vector is starting to disappear with the addition of the Same-Site cookie flag. However, there are still many situations that assumed to be secure endpoints can be manipulated to do something malicious. GraphQL is an up-in-coming technology for querying information meant to replace REST endpoints.

GraphQL uses JSON based endpoints. JSON requires a pre-flight request, which means that it is NOT vulnerable to CSRF unless something weird is happening on the back-end. So, the first trick is changing the content-type to be a form-urlencoded encoded in order to bypass this protection.

Secondly, if the endpoint has any mutations via GET requests, this is an automatic vulnerability. Most frameworks will not validate CSRF tokens on GET requests. So, this now becomes a really easy target to hit. These are standard CSRF test cases but it interesting to hear them be called out on GraphQL in particular.

The final thing to look out for is Cross-Site Search (XSSearch). The idea is that a malicious user does not have access to some piece of information BUT the victim user does. By launching GET requests to search for some information, a timing difference can used in order to figure out if the data is valid or not. It should be noted that the return of the request gets blocked because of the same-site policy.

Overall, these are good callouts and I finally have a better understanding of a realistic scenario for XSSearch.

This blog post is a bug in the Mesas llvmpipe Gallium3D graphics driver which was accessible via Chromium's WebGL. This driver is used to simulate GPU processing when the hardware is not available.

LLVMPipe is a software rasterizer that uses LLVM to compile the shader code to run on a CPU. The vulnerability is in the compilation process of shader code.

The vulnerability is in that the size of arrays is not validated within the shader code. When this is created, it is added to the stack as a variable length array (VLA).

Because there is no length check on the length of the array, the VLA can be mapped outside of the current stack mapping. This causes a crash because a guard page is hit within Chromium though. Can we do anything else with this?

Chromium has an additional exploit mitigation: all of the allocations are zeroed out before being used in order to prevent uninitialized memory leaks. Although, this causes issues because we don't want to write over the top of unmapped memory.

In order to prevent the initialization of zeros from happening, an always failing if statement can be used. In order to hop over the Guard Pages, we need to allocate a significant amount of memory in other locations.

By carefully fine-tuning the offsets for the VLAs, partial control over the RIP on the stack can be controlled. Eventually, with a few tricks for handling AVX instructions, the full RIP could be controlled!

To pop a full shell, this vulnerability would need to be chained with a memory leak. Additionally, the GPU runs in a sandbox which would require an additional vulnerability to break out.

This is an interesting vulnerability! This is the second VLA issue that I have seen in the last while; bounds checking on the high end needs to be taken seriously on stack memory in order to avoid these subtle issues.