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 Content Security Policy (CSP) is used to restrict what can be done on a web page. This is useful for defense-in-depth on issues, like XSS, as well as framing. The origin of resources and the types can be restricted as well. In this case, the author had an arbitrary file upload bug but couldn't exploit it because of the CSP not allowing unsafe-inline.

Modern browsers will display accessed data as HTML, as long as the Content-Type lines up. This includes images, CSS files and more. If we can load data into an iFrame, then we can trick the page into loading the page for us. A lot of the time, the CSP is conditional; by loading it into an iFrame with a weird page, we can bypass the CSP. This works with weird looking images or JS files.

The solution? Put the CSP on all requests. This will gunk things up, which is annoying though.

The final payload is confusing to me though; it's using JavaScript to create an iFrame on the page to bypass the CSP. If you can execute JS already then why do you need to bypass the CSP? Regardless, interesting CSP bypass technique; put stuff in iFrames that is not meant to be in iFrames.

Trail of Bits was performing a security audit of the Cosmos IBC Go implementation. While doing this audit, they used Go Fuzz, a coverage guided fuzzer for Go. Seems like a pretty rad tool for fuzzing; just build a quick harass and you're ready to go.

JS8 is a protocol for communicating over vast differences using radio. It's a text based protocol for chat.

The protocol is operates at 7MHz-14MHz, which is extremely low. At these frequencies, the E and F layers of the ionosphere reflect the radio signals. This means that line-of-sight is not important for us! Point to point can go from one spot on earth to another, which is truly amazing.

Jesse was looking at a website that parsed all JS8 traffic and displayed it. The message can literally contain anything after the callsign. So, they decided to add an HTML injection payload to their JS8 payload and it caused modification of the page! Since the page has no authentication, what could we do that would be useful?

Cosmetic change are interesting... logging requests and where the users are located... Even with this, the stored HTML injection has some impact. Overall, a classic vulnerability found in a very bizarre place.

Zunami is a yield aggregator protocol for stablecoin staking. They lost 2.1M dollars in two transactions. How did this happen?

The function calcTokenPrice() is used to determine the price of the tokens of the project. This is done by diving the total holdings of the pool by the number of existing tokens.

The price of a token calculated this way can increased in price by adding tokens or decreased in price by somehow removing tokens. By donating funds to the pool, the value of LP token can be manipulated.

Chainlink provides off-chain data to smart contracts in order for users to query them. Integrating with chainlink creates its own set of challenges.

The oracles are updated periodically but must be updated by Chainlink. However, the values may be stale or out of date when calling latestRoundData(). As a result, a user could contain money from the out of date oracle. Not checking if an L2 Sequencer is down falls into the same category.

When checking if a price feed has been updated, different feeds can have different heartbeats. So, the time for more value may be another. Additionally, simply checking whether the price oracles get updated enough is important. What if a price feed is never updated but we are using it? Real bad!

Besides these, it's common to use wrong hardcoded values. For instance, the precision of various feeds may be assumed throughout the contract. Additionally, hardcoding the wrong address for the price is a common problem as well. This may be in a configuration file instead of the contract though.

A classic blockchain problem is frontrunning. If updates are too slow and the price deviates too much, then they can be sandwiched. To solve this, adding small fees or delays on withdrawals.

Another interesting case is a denial of service (DoS) via bad price feeds. The recommendation is to add functionality to update the price in case something breaks.

The final cases are extreme price changes. If an asset is depegged (WBTC to BTC), then we want to ensure that malicious actors cannot benefit from this. The solution is looking at the price of BTC to WBTC. A similar thing can be done to prevent flash crash attacks on the protocol as well.

Overall, integrating with Chainlink has it's problems just like everything else. Most of these feel like defense-in-depth, but is super important in the case of failure.

Mocor OS is a proprietary OS from UNISOC. This OS is used in various phone vendros such as Nokia, TCL and others.

During the initial boot up process, there is a user-lock password on the phone. Without knowledge of this, it should not be possible to access data on the phone.

The author found a weird (and not very well explained) loophole in the code. When a software reboot is triggered on the SoC via a crash, certain permission checks are not done compared to the regular boot.

By glitching the chip, this can be done. In fact, it does not require fancy equipment. Simply connect GND to the CLK for 50-100 ms during the password check and it will bypass the check.

This article was confusing to me. But, it seems that the soft reboot during the password prompt assumes that the system booted securely. So, it takes a shortcut if a soft reboot occurs after this point. To be honest, not sure if this is true but with the large timing window, this almost appears to be a software bug than a hardware bug.

On the web, the go to method for maintaining state in the stateless HTTP protocol is cookies. The .NET framework included a way of putting cookies into the URL for clients who couldn't support cookies. This had the view of S(aaaaaaaaaaaaaaaaaaaaaaaa) in part of the path of the URL.

Historically, this has been real bad for WAFs and session related issues such as session fixation, session hijacking and more. The author includes a link to various posts about previous issues. Due to these security concerns, the feature was removed from the .NET core in newer versions.

From the WAF bypasses the author posted on Twitter, it's clear that putting sessions into the middle of a URL causes weird problems. While testing new WAF bypass techniques, they noticed two weird anomalies.

The cookieless feature could circumvent the protected directories and URL filters in IIS. Normally, paths in these locations would be blocked. However, by including two sessions in the URL, the validation was bypassed. Why does this occur?

In the rewrite portion of the cookieless paths in the .NET framework, it appears to only perform the removal once for verification. Then, during the resolution process, it will remove the second session and allow the user to access the path. At least, this is what it seems like but it's not explained very well.

In IIS, there are application pools. Some paths could use one pool while others would use another. By using the double session path from above, it is possible to create pool confusion. This can lead to a privilege escalation, given the right scenario.

Interesting bug! It turns out that string parsing is very hard to do correctly. Double adding a value is something I'll be testing for in the future.

The original XBox was pwned hard very soon after its release through various methods. One method that was thrown out early on was the idea of using JTAG. This was a gold mine if possible though; this would give amazing debugging that has never been possible on it.

There were two reasons for this. First, the TRST# line was holding the chain in reset under the chip, making it difficult to remove. Second, reverse engineering the JTAG interface would have been non-trivial as well. But, it's 2023! So, the authors gave it a try.

Instead of modifying the hardware to get JTAG working, the author decided to remove the chip entirely. By creating a breakout PCB, they could isolate the JTAG signals from the CPU signals. This would drastically help out in the reverse engineering process. This costed them $20 USD, which is super cheap.

What's an interposer board? Great question! For the BGA chip, the idea is to add the CPU on the top part of the chip. Then, solder the interposer board onto the original CPU location. This would allow for the CPU to function normally, with the ability to see and interact with the JTAG signals from breakout pads.

There are not one but TWO reflows here. This is incredibly complex to do correctly. From there, they purchased a Pentium III JTAG debugger to attempt to connect.

This did not work straight away because the System Management Controller (MCU) on the original XBox expects the CPU to pass a set of integrity tests at the beginning of boot. the debugger continuing upon attaching was not fast enough to pass these checks. So, the author setup a Arduino sketch on the I2C bus to fulfill these actions.

With that, they had a JTAG debuggable system. Extracting the secret ROM was now a trivial feat. Overall, an interesting feat in its own right. I enjoyed the interposer board setup and guide to performing this. Awesome post!

VPNs are used in order to prevent snooping or internet tracking. In this article, the authors go over widespread issues they found with VPN apps.

When a user joins a network, the subnet is set. However, there is no validation on whether this IP address is proper. If the IP address of a domain is 1.2.3.4, then setting the subnet to 1.2.3.0/24 will allow for the

This happens because the VPN app allows direct access to the local network while using the VPN. What happens? We can force the VPN to send traffic outside of the tunnel by sending it to a local IP. This effected all iOS apps, many on MacOS, Windows and Linux.

The second attack abuses the fact that most VPNs do not encrypt traffic towards the IP of the VPN server. The traffic should already be encrypted, so this shouldn't matter. This is vulnerable to a classic DNS issue of spoofing the response for a domain to be a different IP.

LeetSwap is a decentralized token exchange. It's a fork of Solidly.

In Solidity, private and internal functions are started with an _ (underscore) by convention. In practice, the visibility is the important part. In the case of this protocol, the function _transferFeesSupportingTaxToken() was set to public, even though it had an underscore at the beginning.

Although the name says taxTokens, the functionality takes in a token address and amount then sends it to the fees contract owner. So, what's the big deal? The attacker does not get sent the money.

How do we exploit this? Since this is an automated market maker (AMM), the prices are dedicated by the amount of the assets in the protocol. Since we can arbitrarily move assets out of the protocol, we can manipulate the trading rates. Here's a step by step for hitting a single pool if we were attacking a WETH-SOMETOKEN pool:

1. Swap WETH for SOMETOKEN at the market rate.
2. Call _transferFeesSupportingTokenTax() to transfer out the SOMETOKEN from the protocol. This will make the exchange rate for trading SOMETOKEN to WETH favorable.
3. Call the sync() function to fix the pool amounts used for calculations.
4. Swap back SOMETOKEN for WETH at the favorable rate to drain the protocol of most of its WETH.

Get audits people! Security is hard. A junior auditor would have trivial caught this bug.