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!

Aave is a very common loan protocol in the web3 space. Liquidation is the process of getting back the tokens of a loan in exchange for a discounted rate on the users collateral.

For instance, imagine I took out a loan for 1 ETH for 2000 USDC with a threshold of 10% (USDC to ETH is probably around 1800). If I wasn't repaying my interest or the cost of USDC dropped,another user could come in to supply the 1ETH and get 1850 USDC back for this. This keeps the protocol solvant.

e-mode (efficiency mode) is an asset that is consistent in price with a pegged value, like USDC. When getting the price of user assets, the program will check to see if the price should be gotten from the default location or the e-mode location. This is done by passing in the collateralPriceSource and debtPriceSource variables.

The assumption is that the debtPriceSource should be the price source for the e-mode category. This is imposed by the restriction that if a user is in e-mode, they should only be able to borrow assets that belong to this users e-mode. Can this be violated?

If the following situation occurs, this can be violated:

• E-mode is using a custom oracle.
• The debt asset that is liquidated has been removed from e-mode.

What's the consequence of this? The calculations get messed up on the liquidation process. Because the user being in an e-mode state is checked while adding the tokens, the logic explained above takes a weird turn. It will get the wrong price as a result. The e-mode price returns a nice pegged value, which is much cheaper than using an oracle like chainlink.

If USDC was depegged from $1 to $2, then the liquidator would only get half of what they deserve. If it depegged from $1 to $0.5, they would get double they deserve. This is a pretty drastic consequence, especially with large loans.

To fix this issue, the e-mode price should only be used if the e-mode flag on both the user and the oracle is set. This felt like a reasonable optimization but the complicated system led to this issue.

To me, a single thing stands out: this is a completely crazy situation that the author of this conjured up. However, this is a legit scenario that could happen with an admin acting in a sane manner. Did they see the separation between the user e-mode flag and the oracle e-mode flag and come up with this?

Aave is a very common laon protocol in the web3 space. A flashloan is a loan that occurs within a single transaction. By doing this, a user can get access to a large amount of money without the owner risking anything. Usually, there is a fee associated with providing the flash loan.

On Aave, this fee is called a premium. The user asks for a specific amount, then a percentage is added on top of this for what they are required to pay back. Aave calls a callback function in the users smart contract for this.

Once a user goes to repay the flashloan, the function validates that the original funds were paid back. On the premium, it checks to see if this was paid back OR opens a position on the amount that needs to be repaid.

When specifying the position that needs to be taken, there is a miscalculation on the approval price. Some of the funds will not be sent in this case, resulting in leftover funds that Aave could spend. If a hack occurred of Aave, this would be a bad avenue for exploitation. Additionally, this logs a wrong event.

USDT does not follow the ERC20 standard for both returning a bool on successful execution or approvals with a value greater than zero. Both of these can lead to reverts, sadly. This issue is present in the standard template for flashloans on Aave, which makes it more interesting of an issue.

Overall, this is a defense-in-depth issue that was fairly complicated to encounter and understand. Not a very big problem in Aave.

Different types of bot actions with frontrunning/backrunning with various markets:

• Sandwiching: Increase the price of the asset, let the trade happen, then trade back to make a profit.
• Sniping: Buy coins or assets as soon as they are listed.
• Backrunning: Arbitrage price inefficienies within an AMM. Usually the result of large trades.
• Just in time liquidity: Provide assets for a very short period of time for a single trade. Then, remove the assets after the trade to get the fees for providing liquidity. Only valuable for large trades.

This talk is about creating a backrunning bot that are mathematically optimal, which was prior to flashbots. The goal is to arbitrage (go from market A to market B to make a profit from the spread of the price) the differences between various pools. The author treats this as a graph theory problem where each token is a node and each AMM is a line to a different node. Using this, we can find a list of tokens to AMMs that could make a profit.

The first step is getting all of the data. These are pairs with tokens that have value (not meme coins) and the ratio (price) of these in the pool. From there, the author does an initial pass of these tokens from WETH to another token to see if the value went up or down in a breadth-first search pattern to see if the trading situation is good. If not, these tokens/pools are simply dropped.

Next, a depth first search is performed to find the best cycle possible. With the removal of meme coins and bad pools, this makes the search space tenable. To find the most optimal amount to trade on Uniswap is fairly easy. With Balancer, this is a much more complicated problem with the amount of tokens at place. So, this required using Newton's Method to find the profitability of various operations.

To execute this, the transaction is put on the network; but the work isn't done. Now, we need to check to see if there's any competition. If there's a collision in the tx.data, we need to see if our transaction will go through first or not. If it won't then will "fold" our previous transaction sent to minimize the loss, which is done by checking profitability at run time. We could also raise our gas price to see to try to get the transaction executed first.

Folds are important because only a single person can win the arbitrage. Additionally, there is some game theory here. The goal isn't to win a single opportunity; it's to win the most over time. So, sometimes, losing money by raising is more optimal than letting your opponent win. Over time, if you have a deeper pocket, you'll knock competitors out of the market. Obfuscating the code that is running to prevent people from doing this as well.

To make this more efficient, there are many things that you can do. First, caching is crucial. The paths can be cached and only updated on changes. This also goes for network requests for the pair information as well.

How is slippage dealt with on these calls? I'm not 100% sure. However, I've got some thoughts. Putting a transaction in the mempool will result in one of the pools being arbitraged or changed from a simple trade. If we can use the right amount of gas to ensure we're at the beginning of a block, this doesn't matter though. Additionally, there is a time of check vs. time of use (TOCTOU) issue, since the blockchain is always being updated. From my understanding, there's a gap (since transactions happen in blocks) so this isn't as much of a problem though.

At the end, the speaker gives advice on how to get into this: find a niche. JaredFromSubway will kill you if you try to start in his territory. So, finding a weird protocol on some sidechain with little competition works well for starting off. Then, you can work your way up to bigger and bigger things as you learn and build out infrastructure.

Overall, a good trip into the dark forest of MEV. It's fascinating seeing the optimization that goes into all of this.

Terminals are the most common way for developers to interact with computers. The control codes of this is conveyed in-band to the users. Escape sequences like \x1b[32m are a good example of this. The author decided to look into the iTerm2 emulator.

Similar to phone phreaking back in the day, the goal of the attack is to use arbitrary characters printed to the terminal to change the control flow of the terminal itself.

The idea behind the attack is sticking characters into stdin via terminal escape codes. By doing this, we can force a command to be executed. The payload is a complete mess to look at. But, the concept is simply this with various twists.

For instance, the \x1b[5n code is a Device Status Report (DSR). This will end up pushes the character n to stdin. By using this, and various other things, we craft arbitrary commands.

Then, we push the command arg1|m4 using various schengians of pushing data to stdin. The m4 command is a C/C++ macro engine, allowing for code execution via the previous input of syscmd(open -a Calculator).

The line \x1bP1000p%session-changed $9 s\n acts a tmux (terminal multiplexor) command that will press enter for us, executing our command now in stdin.

I don't fully understand the payload. There's a lot of juggling between things and the actual reason for searching through history isn't very well explained. Regardless, I loved the attack method and hope to see many more of these in the future.

Cross-site frame counting is a technique for counting the amount of window references (iFrames) from external websites. This is not a vulnerability by itself but can be used to leak private information. For instance, if there's an iFrame for a user logged into a site and no iFrame if not, then this leaks that the user is logged in.

- While testing VS-Codespaces integration with Github, the author noticed a quirk about the iFrames:

• 2 iFrames2 iFrames: The private repository exists but the file does not.
• 1 iFrame: The private repository exists and the file both exist.
• 0 iFrames: The private repository does not exist.

So, we can determine the state of a user based upon the number of frames. Neat! The exploit is a loop of opening a location in the browser by setting the win.location and checking how many frames were loaded.

How do you fix this? You load a consistent number of iFrames no matter the state. Overall, interesting bug with pretty significant impact.

URL parsing is super hard to do properly. There is a standard that has been updated and changed over the years. Additionally, if there is a difference in verification vs. use at any point, this can lead to massive security issues. In this article, they were looking at an SVG parser.

Previous research has showed that the Inkscape CLI parser is vulnerable to path traversal within rendered SVGs. Within this parser, the XInclude format is also supported, a method of merging XML documents (SVGs are just XML). The underlying library for Inkscape is librsvg, which Canva uses.

Within librsvg, every URL goes through validation to ensure it is not malicious. For instance, being able to include arbitrary local files would be a big no-no. The rules are VERY strict, making it relatively safe to use.

The parser for validation is done with one parser but the loading of the SVG is done using the parser Gio. Anytime there are two parsers operating on the same data, there is likely many bugs lurking. A slight misunderstanding on one end could lead to the break you need.

The authors of the post setup a fuzzer to test the differences in the file resolve process. While doing this, they noticed that current.svg?../../../../../../../etc/passwd passes the validation but can resolve files. How is this? From my understanding, the ? gets stripped from the resolver and is unhandled by the validator.

The Gio parser will happily traverse files and traverse further up. A canonicalization process is done on the link. As it turns out, it starts in the directory in which the program is at. So, placing a . at the beginning can be used to force the program to traverse further up.

The full SVG link is .?../../../../../../../etc/passwd. To me, this really shows the power of differential fuzzing. Who would have thought about a question mark in the path? Not me, only the fuzzer.