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!

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.