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 article dives into the different proxy patterns and the security issues that can arise from this. First, there is the simple proxy. This makes a delegateCall to the implementation code. The delegateCall is used in order for the proxy to have the storage of the contract be decoupled from the code. The original proxy did not have the ability to upgrade though.

Obviously, we want to be able to upgrade the implementation address. This is done by storing the implementation address within the proxy contract and have an admin function to update it. An Initializeable Proxy is a proxy that can be initialized. This is necessary because the constructor will only run on deployment. So, if we set a new implementation, we need a way to initialize or update the state of new variables.

The patterns above have a few problems though. The proxy has an issue with storage collisions if a user is not careful. To account for this, EIP-1967 was created for unstructured storage. This stores the implementation address at a nearly random slot within the contract to ensure that collisions don't occur.

The second problem is function clashing when the proxy and implementation share a function selector. In the Transparent Proxy pattern, the admin of the contract hits a special section of code only meant for admins while the rest of the users hit the normal fallback code.

In all of the cases before, the upgrading was happening within the proxy contract. The Universal Upgradeable Proxy Standard (UUPS) flips this on its head. The upgrading functionality is in the implementation contract instead. This allows for editing the upgrade functionality, which can be a good thing.

The Beacon Proxy pattern is useful when there are a large amount of proxy contracts are needed. If the implementation address changed, then all of the proxies would need to change as well. Instead of the proxy->implementation flow, this pattern adds in a third contract. The flow is now proxy->beacon->implementation.

Diamond Proxy has a list of implementation contracts that point to different contracts depending on the function being called. This allows for smart contracts larger than the official size. However, this does have the limitation of storage being quite weird across the different contracts.

The Metamorphic contract is weird in that it doesn't have a proxy for updating. Instead, it calls selfdestruct then redeploys the contract to the same address. Honestly, this pattern makes the most sense to me for user engagement.

This is a really good article on the types of proxy contracts. I felt like they explained the pros, cons and gave example implementations on the way.

Yearn Finance is a suite of products to yearn yield on digital assets. This includes staking tokens to earn interest and selling/buying votes. For the yield-bearing assets, users can put positions into Aave, Compound, DYDX and BzX's Fulcrum.

The bad contract was the legacy iEarn USDT token contract. What was wrong with it? There is no inherit security issue with the code; it was a misconfiguration of the pools being used. In particular, the contract used the Fulcrum USDC address instead of the USDT address.

Why is this bad? This leads to manipulation on the pool being possible. From my basic understanding, the attacker needed to hit the code path for this misconfiguration. This was done by rebalancing the protocol to use Fulcrum instead of AAVE and Compound. To make the hack as financially profitable as possible, they forced all of the funds to be sent back to the contract instead of be in the pools.

Finally, to exploit the misconfiguration, they sent a single USDT token to the pool. Since it didn't have any USDT, the USDT amount (which was really USDC amount) was divided by the real amount of yUSDT, which is 1 from our donation. This leads to 1.2 quadrillion of yUSDT being minted when it shouldn't have been. Yikes!

The attacker trades these funds to other locations in the Yearn Finance ecosystem in order to profit heavily from the issue. This dumb copy-and-paste issue had a complex manipulation occur in order to exploit this, which is pretty wild. Overall, good read but hard to follow without understanding the codebase.

Automated Market Makers are great! Well, until you manipulate the algorithmic part of it. It was audited by WhitehatDAO who cleared missed some things.

In Hundred Finance, hTokens are liquidity provider tokens. These are interest bearing tokenized representations of user deposits. This is denoted with an h in front of the token name, such as hBTC.

The exchange rate formula for the contract was based upon the amount wrapped Bitcoin (WBTC) that the hBTC the contract has inside of it. Using this knowledge and the lack of protection, this can be abused. First, the attacker donated 200 hWBTC from 200 WBTC.

By donating a large amount of hWBTC to the contract, the exchange rate went up dramatically. Using the inflated exchange rate, they took out large loans from other platforms. Why is this bad?

If we borrow 1M of assets at but provide something worth 1.5M, that's fine. However, the liquidation point is where the collateral becomes worth less than the borrowed funds. The attacker used the high exchange rate to trick protocols in accepting way less collateral than they should. Once they put the exchange rate back by redeeming the hWBTC, they kept the loan and left the useless collateral.

Algorithms are hard when using have access to infinite money with flash loans. Overall, another DeFi hack on Hundred Finance. It should be mentioned that this a fork of Compound... the flaw is partially in the design of Compound.

VM2 is a sandbox for NodeJs. The idea is that untrusted code can be executed within this context without anything sensitive being stolen or important items altered. Being able to escape the sandbox would be terrible for the system.

Host exceptions may leak host objects in the sandbox. In order to prevent this from happening, code is preprocessed to instrument sanitizer for function calls. The identifier of the name catch clause has post processing in order to replace $tmpname with the actual value in a catch clause.

This post processing allows a user to bypass the handleException() processing as a result of this. Now, an attacker can use any method to raise a host exception. Then, using the context of the host, access objects higher in the hierarchy to get code execution outside the sandbox.

Overall, a straight forward sandbox escape by getting access to higher level objects. It's interesting how similar this is to Oxides sandbox escape 3 months ago.

Osmosis Zone is a decentralized exchange built in the Cosmos ecosystem.

A reddit user made a comment that a bug in the liquidity pool allowed a gain of 50% for simply adding and removing liquidity from the pool. Naturally, people did not take the person seriously... until they tried it. This was taken advantage of to still money instantly.

Eventually, this led to a stoppage of the blockchain to allow for a fix before it was too late. How easy was this exploit? Put money in, take it out... do it again. Eventually, the various hackers stole 5M from the dex, prior to the stoppage. It's pretty clear looking at transactions that money is simply being duplicated.

Overall, a really simple vulnerability that is unreal it wasn't found during testing. To me, taking out when you put in seems like a pretty sane thing to test.

Escaping input is very important when trying to prevent XSS, code injection and many other classes of vulnerabilities. However, the escaping is context dependent. In some situations, a single quote would break the system while, for other times, it may be another character. Knowing when to escape what really matters.

In this report, a user is providing a URL that will be navigated to. For some reason, there is a multiline comment that is necessary for escape some input. /*{ url: 'https://example.com' }*/ is used within the parameters. In order to prevent code injection, they call quote to escape single and double quotes.

The quote is not the only thing to worry about though. What about the comment? By ending the comment, an attacker can add their own code. For instance, the input https://example.com?q=*/.../* would escape the comment to add arbitrary content to the JavaScript. In particular, this appears to be a NodeJs environment.

The final payload to escape the function call and execute JavaScript is as follows:

Injection point: 
page.waitForNavigation(/*{ url: '
https://example.com'}*/),

Payload: 
https://example.com?q=*/require(child_process)
.exec(touch$IFS/tmp/haxx)/*

Executed code: 
page.waitForNavigation(/*{ url: '
https://example.com?q=*/require(`child_process`)
.exec(`touch$IFS/tmp/dee-see`)/*' }*/),

A pretty interesting case of not escaping inputs properly. True code injection doesn't happen very often but it's sure interesting when it does. Good report!

The author of this post noted a weird issue on Twitter: thieves were wrecking a mans cars to eventually steal it. Why and how? They wanted direct access to the Controller Area Network (CAN) bus. The Toyota has telemetry on it which is conveniently logs all errors on the CAN bus. On the RAV4, the headlights connect to the CAN bus directly, which is why the attackers removed the headlights.

The telemetry showed that the headlights had a communication failure. Not just for the lights though... many other things as well. Ian, the car owner, went on the dark web to find devices used to steal all sorts of cars. Eventually, he decided to buy one of these devices in order to reverse engineer it. This is where the author of the post comes into the situation: he's an expert on CAN buses.

When most people think about stealing cars, they think about issues with the smart key or key fob, from relay attacks to replay attacks. Since these issues are getting fixed, the attackers discussed a new technique: CAN bus injection. By sending data directly on the CAN bus, we can force it to perform actions. This is possible because the CAN bus is considered a trusted environment; there is no validation on who sends it.

The device is a JBL music speaker with CAN transceiver attached to it. The device gets connected to the CAN bus (commonly through the headlight) to impersonate a smart key Electronic Control Unit (ECU). In particular, it connects and sends back the "Smart Key is valid" signal to the car 20 times per second. This isn't enough though! Since the bus already has other devices on it, it disables other devices from writing to the bus with the dominant-override wire. By doing this over and over again, we can trick the car to turn on.

The author dives into the anatomy of the CAN bus protocol more throughout the article. From this, we can really understand how the injector works. To fix this problem, the author suggests using cryptographic primitives to prevent random devices from jumping onto the bus. Additionally, a more brittle fix would be to program the smart key CAN frame to only be accepted if no bit errors were found on the bus recently.

Overall, interesting article into the dark web and how people are actually stealing cars.

Solidity only has integers and there is a lot of money going around. So, precision is very important when dealing with money. Sometimes, this benefits the protocol. Other times, funds disappear entirely. But worst of all, funds may be stolen. What are all the ways this can go wrong? This article dives into it.

Division Before Multiplication. All division in Solidity will round down by default. So, if we do division then multiplication, there is a chance of lost value along the way. The example shows a multiplication, division and two multiplications afterwards that result in precision loss.

Rounding Down To Zero. Since division rounds down to zero, small values may cause problems. In a loan application, an attacker could repay their funds. However, they could subtract a small amount. The result was that the loanCollateral was being subtracted when it was zero and the loanAmount could still be subtracted from.

The solution to the precision problem is to have a check to ensure that values do not round down to zero.

No Precision Scaling. Tokens have different decimal places, such as USDC with 6 and ETH with 18. In the example, two tokens are used to calculate the value of an LP token. A loss in precision can occur if computation is done by combining the amounts of two tokens with different precision without scaling the the secondary token to the primary tokens precision.

When combining amounts of tokens with different precision, convert the amounts to the primary token's precision before any computation. Otherwise, value could be added or removed from the contract.