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 Apple Security Engineering and Architecture Research (SEAR) team made everyone aware of a vulnerability in the WebP image library that was being used actively in the wild by NSO Group discovered by Citizen Labs. Since this is in a core library, the impact ranges from iOS to Google Chrome.

Within iOS 14, Apple added a BlastDoor service. This is a tight sandbox that processes untrusted data within iMessages. This exploit bypassed the sandbox by sending this within a PassKit attachment instead of a regular image. Bypass the sandbox by not using it! Fascinating.

Huffman tables are used as a mapping from bit patterns to bytes that is in the image. Going from the table within the image to an internal representation is where the vulnerability is located.

Simply put: the vulnerability is a heap overflow from a statically sized buffer. To hit this, is fairly complicated. Each of the 5 tables is validated individually. The first 4 tables must be full to the brim. Then, the 5th table can have too many nodes, leading to a 400 byte buffer overflow.

The interesting part: the validation is done after the memory corruption occurs. So, the overflow occurs, then the node limit is validation is hit. You don't see the corruption then validation very often! It's fascinating to see this occur here.

The author of this post did not try to exploit this. Exploitation would have been difficult, since the program exits with the bad table. However, NSO group found a way to exploit this it appears.

The webp library did not have a fuzzer setup for it from Google. However, the author does not believe this could have been caught with the complexity of the Huffman tables. A single wrong bit would have caused an early exit. Code review and fuzzing tend to find different bugs.

Telsa uses auth.tesla.com as an SSO provider for external customers. For internal employees, they uses sso.telsa.com as an iDP.

Using auth.tesla.com, they user realized it is possible to create emails for both @tesla.com and @teslamotors.com. Trying to create already created emails, like ones from internal employees, was not allowed. So, what can we do with this?

So, what about accounts that have been removed? Could we recreate these? So, the author looked on LinkedIn for employees at Tesla that may have had permissions in the past on various websites. Interesting idea!

The author had used The Tesla Retail Tool for IT and business data for the dealerships. So, they tried this. After many tries, they found accounts with permissions on this site!

The website did not care which iDP was being used; the external vs the internal one. Using this issue, they were able to login as the other employee. If there was a JWT, then the iss field is what was important here. A super interesting bug!

Price oracles are providing the price of a specific asset; this can either be on-chain or off-chain data powering this. AMMs, loan providers and more use this to provide proper prices. Integrating with price oracles properly is incredibly important for the security of the protocol.

The author posts some code and has a bunch of questions about the oracle. A few of these are listed below:

• What if the price is zero or very large?
• What about the unit (decimals) of the price? Or what if the price is inverted.
• How is the oracle updated? How often? delays? Can it be shut down?

The goal is to build robust oracles that handle anything that comes to it. From large price swings to broke oracles. The first, and most popular, price feed is Chainlink. This is queried through the AggregatorProxy, which interacts with the trading price contract directly. Within this, the latestRoundData() is called.

It is reccomended that this is wrapped in a try/catch block that then has a fallback oracle in case of failure. On top of this, the decimals and ordering of assets should be considered when programming with this.

Uniswap Time Weighted Average Prices. Simply querying from Uniswap pools is dangerous, due to the ability to manipulate the pool beforehand. As a result, by using a time weighted average, the price cannot be manipulated as easily.

UniswapV2 has an oracle library for doing this for you. When using this there is a trade off length. Although it's more protected against price manipulation, large jumps or drops in price would be less accurate. Another consideration is that TWAP of A in B is not the reciprocal of TWAP of B in A.

For Uniswap v3, the TWAP is built into the pool themselves instead of having developers keep track of this information themselves. When using this, tick information is returned; not the price. The price needs to be calculated from the tick.

The Open Price Feed is used by many protocols but is operated by Compound. UniswapAnchoredView contract manages the price for multiple assets. This has two price feeds: a trusted source (chainlink) and an anchor price (uniswap). If the posted price deviates too much from the anchor price, then the program will revert.

The final mentioned price feed is the maker oracles. These oracles have privileged accounts called relayers that aggregate data off-chain in a p2p network. The price data being added calculates the median price from various observations to get a price.

Overall, an interesting article on oracles in the DeFi space as well as their trade offs. I enjoyed the article, even though it is over 2 years old now.

In .NET, the ViewState parameter contains information about the state of a users session. This is serialized in the __VIEWSTATE parameter, which is sent on every request the user sends.

People running .NET sites ran into the problem of the ViewState being too large. So, developers added another variable called __VSTATE and compressed it.

Why does this matter? The handler is serialized data, giving potential RCE if unchecked. Later, the data was encrypted so that it couldn't be tampered with. However, the changes were no backfilled to __VSTATE.

Knowing about this issue, they decided to do a wide search on this. While searching on the code search platform, they saw that Higher Logic used this technique and may be vulnerable.

They set up a interactsh (personal Burp Collaborator), setup a ysoserial payload and attempted the modification of the variable. Boom! It worked. A DNS interact was spotted, indicating that this was successful.

The reporting process was extremely hairy. HigherLogic did not care at all. So, they reported to IBM and 8x8's bug bounty programs directly, who asked HigherLogic about it. Finally, the bug was fixed but they refused to make a security release about it; only the customers who knew about it could ask for the patch.

They wrote up a nuclei template for scanning. They found 1.7K websites that were vulnerable to the HigherLogic issues RCE bug. They sent another email informing them about a public disclosure and blog post. This time, they silently patched all of the devices without telling anyone of the issues.

A lot of the articles on this blog are inspired by other issues. I enjoy seeing where the ideas came from and how they helped the author track down the issues. Overall, fun article that's explained like a veteran of the industry.

phpPgAdmin is a PHP plugin for interacting Postgres databases via PHP.

When a user logs in, there is verification that the beginning and end of the string have a single quote. Or, if it doesn't then the program does the quoting for you. There is no verification done on the input for this though.

The verification allows for more than one field to be added, allowing for directive injection. For instance, 'testinguser' host='1.3.3.7' would change the host.

Using this technique, we can change the host of the server. Why does this matter? We can trick the application to use our database for the login process! Since we know our password, this allows for a complete authentication bypass.

A fun authentication bypass with the directive injection changing the location to authenticate to.

MyBB is a bulletin board application. It has a special template functionality that allows for simple PHP eval execution. However, it has a regex to ensure that anything besides variable access is removed. A good description on what is going on can be found on the DayZeroSec blog.

Regex is amazing for finding patterns. However, it comes at a cost - ReDoS. If the regex is too computationally expensive, then it can eat up all of the memory of a program. This is because of the backtracking on the pattern matching that occurs, resulting in these commonly having limits on the recursive nature of it. To test for ReDoS bugs, there is a tool they used.

In PHP, the Perl based Regex functions (preg_match, preg_replace, etc.) do not throw an exception when they reach their backtrack limit. Instead, it will return null.

The calls to preg_match are wrapped in an if statement. If anything malicious is found, then return. Otherwise, continue on. Since null is being returned instead of a value, the verification for the malicious input can be bypassed.

How do we trigger this? A super nested payload that requires a bunch of backtracking. They went with a eval injection with a lot of [0] inside of it.

Overall, love the post! A seemingly good check on the verification was bypassed by a ReDoS attack. Super slick stuff!

An 0-day in the HTTP/2 specification was discovered that leads to Denial of Service (DoS) attacks. Cloudflare, being a CDN with a major DDoS prevention system, was on the forefront of this. They saw attacks of 201 million requests per second, which were 3x bigger than the largest attack they had seen. So, what's the issue?

HTTP/2 is a major improvement on HTTP/1. It includes all of the data from before but allows for concurrency and multiplexing. The basic location where users send data from in a single connection is called a stream. There is a hard limit on the amount of streams that can be open on a given server at a time within a connection, in order to prevent DoS bugs.

HTTP/2 supports in-flight cancellation for a given stream by sending the RST_STREAM byte sequence. Canceled streams do not get counted in the limit of open streams.

By rapidly abusing the rapid reset of the RST_STREAM, a DoS can be triggered. The opening of a new stream slot and the computational resources to clean up cause a problem. With Cloudclare, they copy the socket into a buffer and process the buffer. Once the cancellation happens, this processing stops but still has eaten up a lot of resources.

The bug reminds me of the SlowHTTP attacks on HTTP/1.1 from years ago. Eat up too many resources to cause a crash on the server. Besides the technical side, it's fascinating to see how Cloudflare mitigates these types of problems. They take security of uptime seriously, which I really appreciate.

Arm TrustZone is a Trusted Execution Environment (TEE) which runs two operating systems: a secure world and a non-secure world. For instance, a cryptographic service could be on the secure world. Then, a user could make a request to sign the data, without directly having access to the key. The Qualcomm secure world is called Qualcomm Secure Execution Environment (QSEE) but has not seen much use.

Android runs the non-secure code and the QSEE contains user mode programs called trustlets. An Android user program sends a special ioctl that the kernel will handle and send to the secure world. This process is performed using shared memory. Write to some place, send the ioctl and then the secure world will do the processing and write back to the specified location.

The simple protocol is not always enough. In these cases, some truslets need read/write access to memory, requiring the use of pointers. There's potential for abuse though: writing of arbitrary addresses to physical memory is bad and giving the trustlet access to the buffers directly is scary.

To prevent these attacks, Qualcomm adds ION file descriptors, each represents an offset into the input buffer. Upon receiving the write request, the ION buffer is translated back to its original form. There is an allowlist for what descriptor can access what memory with a given offset.

This offset causes major problems. By using the offset into the middle of these tables, we can get it to pull addresses part way in between. Although we can't write to arbitrary addresses, we can write to these corrupted addresses. The images in the article explain this super well.

The difference between physical and virtual memory is important here. The virtual memory may be contiguous but not the physical. As a result, the buffer must contain information about both the address and the size of it. So, this allows us to control both the address and the size of the data being copied in.

By using the primitive, the author was able to corrupt the allowlist table itself. Now, the buffers physical memory is mapped to the entire Android kernel. The author needed a primitive where they could write to arbitrary locations using the allowlist bypass they found. The widevine DRM has a bunch of complicated pointer functionality that was perfect for this. Using the encrypt/decrypt functionality made this easy to get a R/W primitive.

Overall, an interesting post on using TrustZone to attack the Android kernel. The fundamental design flaw of the system was surprising. I didn't fully understand the entire exploit mechanism but enjoyed it regardless.

Sui is a layer 1 blockchain is famous for its speed and concurrency. By being architected in this way and using Rust under the hood, it hits incredible speeds. The tldr; of the vulnerability is a out of memory denial of service bug that's not particularly interesting. However, the explanation of the eco-system is interesting and I'll post that for myself here.

Sui uses Narwhal as a mempool (pending transaction list) implementation and Bullshark for the consensus engine (synchronize network between validators). This is done by Narwhal parallel orders of transactions into batches where Bullshark figures out a DAG to form these from. Under the hood, Bullshark uses the BFT consensus algorithm.

Sui network transactions happen with the following steps:

1. Send transaction to a full node, which will send to all of the other validators, which perform checks on these.
2. A quorum of 2/3 (after weights on the voters) is collected. Once this is true, the information about the vote is broadcasted across the network with a combined certificate.
3. Each validator checks the certificate. If it's valid, it will execute the transaction locally.
4. Optionally, the quorum driver can collect an effects certificate based on the previous step and return it to the sender as proof of finality.

When processing the incoming certificate, the logic for this does not consider a malicious user. A user can put an infinite amount of digests within the certificate then grabs the corresponding certificates for these digests. By providing a large amount of digests and large certificates, this turns into a denial of service vulnerability.

Sending a 37MB payload with 1.2M digests triggers an out of memory exception, crashing the blockchain. Honestly, I wish the report was smaller. Most of the information wasn't required to understand the bug... but, DoS to take down blockchains is interesting none-the-less.

Baseboard Management Controllers (BMC) are used for the remote monitoring of systems. Typically, this is a specialized chip on a server on a different wired connection than the server. It can be used to change/update level items like UEFI or give console access to the server.

Since this can be accessed remotely, ensuring that the BMC device is secure is incredibly important. One way of accessing this is via the IPMI protocol. This device has a web interface for interacting with this. The first vulnerability is a command injection within the email notification functionality. This does require administrative login to setup though.

The next three vulnerabilities are all reflected XSS bugs. Using this, an attacker can trick a user to visit their maliciously crafted link to create a user account or perform other bad actions.

Paired together, these vulnerabilities allow for a one-click RCE. By chaining the XSS to create an account into the command injection, RCE is gained. Overall, the bugs are pretty standard and nothing special. The interesting part to me is the impact and the target that is being hit.