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 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!

Wintermute is an Automated Market Maker (AMM).

The hack wasn't anything that Wintermute actually did wrong. This time, it was a Vanity wallet generator called Profanity. Using this, it can generate a string of characters into the wallet that is easy to remember and identify. This is somewhat of a problem because everything is supposed to be random!

Profanity’s algorithm had a weakness in how it was generating random numbers. Profanity used a 32 bit integer (4.3 billion numbers) to seed the making of the address. As a result, this was brute forcable and came to the public eye.

The belief is that keys are used for Wintermute were generating using Profanity and this is how they were compromised. Please only used trusted and audited tools!

The solution Aurora has built as an EVM implementation on NEAR is called the Aurora Engine, and it is implemented as a smart contract on the NEAR blockchain. This allows for EVM compatible languages to be put on the chain, such as Solidity. It is just a layer 2 blockchain.

ERC20 is a standard for fungible tokens on the Ethereum blockchain. NEP-141 is an equivalent proposal to the ERC20 protocol. Since the NEAR is built on the EVM, ETH is the base currency. NEP-141 tokens are transferred to the EVM are converted into the equivalent ERC tokens then transferred back to the user.

The function responsible for doing this is receive_erc20_tokens takes a structure for &args. From the args, it parses takes out a msg field and validates the length. After this, the function parsers the recipients address out of the message to ensure its valid. It also checks if a fee that should be paid to the message relayer was also supplied in the message or not.

Finally, the function fetches the ERC20 that corresponds to the NEP-141 token. Once the function transfers the token, it checks to see if the receiver the needs to pay a fee.

So, what's the bug here? The flaw is within the logic of the application not considering permission boundaries.

1. Create a NEP-141 to ERC20 mapping. This is allowed by all users and doesn't pose any issues.
2. Transfer the NEP-141 token to the victim. When making this request, specify the maximum possible fee within the args field. This gets send to the owner of the bridge, which we created ourselves.
3. Receive the funds from the recipient to their NEAR account.

In step 2, the transferring of the token to a user with a fee forces them to pay. This results in 18.4 ETH being transferred per exploit. The fix was simply removing this functionality entirely.

Overall, a fairly complex piece of functionality and a misunderstanding of permissions could have destroyed the platform. A million dollar bounty!