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!

MediaWiki, which is a PHP, claimed to have a deprecated dependency that was an HTTP web server called got. How does this effect MediaWiki? Some submodules were using this.

The got library added support for making requests via Unix domain sockets. This was to allow for requests to be made to a local server, similar to localhost. Unix sockets are extremely powerful so filtering should be done by the end user. This support added the unix:/ and http://unix:/ scheme. The latter scheme was borrowed from the npm request library for implementation.

The got library was not considering that redirects could occur to Unix sockets. By using a 30X redirect to our own server then sending it to a Unix socket, it would be possible to hit a Unix socket from the request; this is a real bad SSRF vulnerability. Filtering wouldn't work in this case, since the request would redirect anyway. This issue was present in the request framework as well.

How would somebody exploit this? Hitting a locally running unix socket. A common unix socket would be the Docker socket. This can be used for creating and kill containers, getting logs and much more.

Overall, interesting dive down the dependency rabbit hole and a trip down how hard URL are to handle in the modern web.

Each file is encrypted individually, with the name being enc_{OriginalName}. There is a configuration file with the file name and the SHA224 hash. The hash of the configuration file is signed. Finally, everything is put into an encrypted zip file for the firmware.

Knowing all of the information about method for creating the image is vastly important. Since we have the encryption key and the signing key, we can create valid firmware with a backdoor in it.

To backdoor the device, they changed a few scripts. The device has Python on it. So, a backdoor shell was added. Additionally, if a USB drive was plugged in, it would search for a special file that would execute. With the backdoor setup, the device needs to be put into engineering mode.

But, the password doesn't work for the mode!? With the newest firmware update, they had came from the website, the password had changed. The hash of the pin (parts of the pin) was put into the logs. By brute forcing these individually they part of the new pin to be 02. Additionally, a hardcoded hash was in the binary and found to be 38. Putting these together is our code for engineering mode.

A good post on reverse engineering and setting up the process for further security research. A large amount of the time this is in posts, even if it is just as important.

The author simply wants to pwn his car! They bought a 2021 Hyundai Ioniq SEL to drive and play with. The author wanted to target In-Vehicle Infotainment (IVI) system. Additionally, there is a mode called Engineering Mode which requires a special code that can be fond in online manuals.

While reviewing the debug diagnostics, they learned they could get some logs by plugging in a USB drive. Another option was ADB over TCP, which would be awesome. The ADB appeared to be off during a network scan so they turned to the logs. The logs had information about running processes and other things.

One thing that stood out from the logs was D-Audio2V IVI for Hydunai. They downloaded the source code for this project to check it out. While on the update website for hyundai, they found firmware files for this, but it was in an encrypted zip file. Yikes!

Zip encryption is vulnerable to plaintext attacks. So, if we know a set of bytes, then we can use the magic tool to recover the key. The known plaintext is a high ask though... one solution is to find similar updates they include some files that are the same. They found a set of files that had the same CRC, indicating they were the same.

Using the tool doesn't work though. How come? Improper settings. While reading the issues page, they learned that the plaintext needs to be the original compressed version. We don't know the settings for the compressed file though! The author brute forced all of the zip settings until it FINALLY worked.

With the file system unencrypted, they started reverse engineering the image. They noticed that the ADB TCP setting in the Engineering Mode set the IP address of eth0 to 192.168.7.110. To make it even harder, the MAC address had to be F4:50:EB:2E:58:00. After many attempts, including the use of ethtool and RtPGtoolUI from Realtek, they were able to burn the MAC address of the adapter. Sadly, the adapter always goes to eth1 instead of eth0.

With this dead end being hit, they went after the firmware update process. The regular image didn't have this update though; instead, it was in an encrypted image file. From reverse engineering the file system, they found a bash script that was decrypting the image - it was the key listed in SP800-38A. The same thing was done for firmware signing as well - they searched for the public key and found the private key.

The reversing process is not always easy! This is an awesome example of defeating the encryption put onto boot images and other things.

DomPDF is an HTML to PDF converter for PHP. In the past, a vulnerability was found that allowed for code execution in PHP. CSS font can be remotely loaded with any extension, leading to code execution if a user can access that specific file.

From the previous research, the author noted that the fix was to force font extensions to have .ttf. Additionally, it doesn't address the fact that arbitrary contents can be present in a font file or the arbitrary file upload issue. The author decided to look for a work around for the original patch.

In another previous vulnerability (CVE-2021-3838), the author noted that the phar:// URI could be put into any HTML elements. To fix this vulnerability, an allowlist of URIs was put into DomPDF.

Reviewing previous vulnerabilities in applications can be extremely beneficial. First, vulnerabilities tend to come in pairs. Second, only 75% of patches are sufficient, according to Natalie from Project Zero. This can be free vulnerabilities and help teach people where to look.

The code from the phar deserailization vulnerability was not sufficient. Even when the protocol is not in the allowlist, the code flow does NOT return. This means that the file content will still be gathered.

In the actual code for getting the file (getFileContent) still parses phar:// and file:// URIs. Because of the issue mentioned above, we can use the phar:// URI to trigger a deserialization vulnerability for code execution.

In the previous exploit, the isRemoteEnabled option has to be enabled in order to trigger the vulnerability. However, by caching the data:// URI in the CSS file, we can store this as a file. Then, in a second request, we can request the data file path as a phar file. This removes the need for the special flag to be enabled.

A polyglot tiff and phar (serialized PHP) had to be created for this. Lucky for us, PHP is really lenient with parsing. Since we can execute arbitrary PHP code, we now have remote code execution!

Overall, great blog post on real world vulnerability hunting. It was cool to see the improvement on previous exploits on DomPDF as well.

While fuzzing a web application, the authors of the post noticed something weird. When putting one single quote (') in a field for time, a 400 error occurred. However, when putting two single quotes ('') into the field, the request returned a valid response!

The functionality indicated a SQL injection vulnerability. While trying to exploit the vulnerability, they kept getting 403's from the proxy.

Instead of attacking the live production server for the client, they installed a clean version of the software. While crafting the payload they could see error messaging on the running application, which made exploit development much easier.

To bypass the filtering, they simple sprinkled in /**/ comments within the attack query. Can we take this further?

The authors noticed that the running user in Postgres was root. Additionally, stacked queries was enabled, making exploitation much easier. By using the stacked query functionality to call COPY command (known technique)to run shell commands.

Overall, good find! I do find it strange this started from a pentest... it's cool they found the bugs but it seems like a weird use of time.

Unisoc is a semiconductor company that is commonly put on Android smart phones. The authors decided to review the Boot process of these chips.

The first step is extracting the BootROM in order to look at the code. Since this is etched into the hardware, there is no reason for this to be public, making it much harder to get. They choose to look at a Teclast phone and a Motorola phone.

Secure boot was not burned into the fuses and the private key is reused from the Unisoc Github repo. By booting this into recovery mode, the BootROM, this could be easily dumped. For the Motorola device, they had to reverse engineer the SDL (secondary boot loader) to try to find an issue, since the previous trick didn't work.

FDL1 is in the recovery process that is normally loaded from the BootROM. Once FDL1 initializes the system memory, it goes into FDL2 using a USB protocol. While parsing this data, there is no limit on the amount of data that can be sent but it is in a static buffer. This results in a buffer overflow that can be used to get code execution to dump out the BootROM.

The recovery mode on the Unisoc chip exposes 5 commands via UART and USB to start FDL1. The command cmd_start took in a user controlled target address and wrote user controllable writable data. This feels like a vulnerability by design!

The USB command dispatcher takes in an index used to execute a function from a list of pointers. However, it does not validate the index. This means that a section of code could be jumped to in an unexpected way. However, this is in the ReadOnly section of memory, making it not trivial to exploit.

The USB data transfer reads in data byte by byte. When doing this, it writes to a static buffer on the stack without validating the size, leading to an out of bounds write issue. A similar exists in the USB command dispatcher as well.

Boot loaders are supposed to verify the next stage is allowed to execute, which is doing using cryptography. While reviewing the verification check on the secondary boot loader, they noticed there were two types of certs: contentcert and keycert. For whatever reason, the contentcert performed 0 validation and return correctly.

The RSA function had a buffer overflow when using a key greater than 2048 bits. Since the overflow occurs in global buffers (unlike the bugs from before), this can be used to smash the stack and get code execution on the chip.

Overall, the vulnerabilities were fairly straight forward buffer overflows or design decisions that led to issues. The article really shines in showing the difficultly of auditing BootROMs from an access perspective and sharing the boot process in general. Great article!

Crow is an HTTP server written in a C++. While triaging a different vulnerability, they stumbled across an issue that required nothing special!

If a file was smaller than 16KB, then the request would be padded with information from the uninitialized stack buffer it was copied from. It is amazing that this information disclosure was never caught beforehand, since it was easy to trigger. Good bug find!

Crow is an async C++ HTTP/WebSocket library for creating flash web services.

The framework implemented pipelining, which is async HTTP. This allows for different workers to get multiple HTTP requests at once, speeding up the service.

However, the server was not built to handle this. All of the variables were global and were meant to handle one request at a time down a connection. Changes were made to fix this but not everything was found.

The function check_destroy is used to delete the connection object once both the read and write flags are cleared. These flags are modified regardless of how many open requests there are. As a result, after the first write occurs, the connection will be destroyed, even though there is another call in the queue.

Interesting cause of a vulnerability and difficult to simply stumble across. A good fuzzer which truly hit all functionality probably would have found this though.

Timestamps (block.timestamp) are used for logic. Actions such as sending ETH and entropy are common uses for timestamps because they create some randomness.

Block timestamps are quite flexible, commonly within a 15 minute time window. A bad miner can exploit this in order to create exploitable conditions for themselves. More recently, the standard has been 15 seconds in order to prevent attacks against manipulation of the timestamp.

To prevent issues with timestamps, use a more robust algorithm, or do something off chain. Functions should be able to maintain integrity with a 15 second variance in the timestamp.

New Free DAO is a DeFi project hosted by the Binance Smart Chain (BSC). The New Free DAO contracts are not open source, making them hard to audit but a determined attacker could hit it still.

The New Free DAO contract reward calculation is based solely on the balance of the user in the contract.A user earns rewards based on the amount of time that value has been deposited and based on the size of the deposit. In both cases, the deposited amount is multiplied by a set value to determine the reward amount.

An attacker can make a massive deposit using a flash loan. From there, they can extract the rewards from the balance and withdraw the deposit. Doing this process over and over again leads to a ton of money being taken out.

To remediate flash loan attacks, mechanisms need to be timed out. You shouldn't be able to quickly put in and take out money. Standard flash loan attack!