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!

bDollar is a algorithmic stablecoin on the Binance Smartchain. It is pegged to multiply assets.

The contract attempts to do some asset rebalancing depending on what assets are in or out of the contract. When using CAKE tokens for conversion, it will try to judge the amount of WBNB exchanged. From this, it will exchange half of the WBNB for BDO tokens and use to this add liquidity to the pool.

If the value of the BDO token is raised during that process, the project will use more WBNB to add liquidity to the pool. To raise the price of BDO, they exchanged a large amount of BDO tokens in several other pools to create a price raise with flash loaned funds.

The key problem is that the contract will automatically replenish the liquidity for the pool without considering if the token price is out of balance. So, the project will supplement the liquidity at a high price to over the order at a higher price. The exploit happens when performing a swap call.

Feminist Metaverse (FM) is a DAO for women's rights. The contract had its own token - FM.

The smart contracts _transfer function had code for figuring out the dividends for the stakers of the token. This is done with two lines of code:

_balances[uniswapV2Pair] = \
     _balanceOf[uniswapV2Pair].add(contractTokenBalance);

_balances[address(this)] = \
     _balanceOf[uniswapV2Pair].sub(contractTokenBalance);

The key thing to note is that the amount of funds going to the uniswapV2Pair is done via setting the balance manually and not by an actual transfer. Why is this a problem? The normal logic and considerations for money does not apply to this!

The if statement to trigger this functionality is trivial to trigger every time. So, an attacker can send very little FM to increase the amount owned by the uniswapV2Pair contract. This is NOT the intended functionality.

The skim function is for making the balances match the reserves. Without the bug above, this wouldn't matter. But, since we can desync these trivially, an attacker can call this function to get the difference between the contracts.

The bug seems like something that should have been caught in testing. Additionally, the skim function being callable by anyone is very strange. Overall, an interesting exploit.

Float is a currency that tracks digit assets instead of pegging to the dollar. The pool for FLOAT was using Uniswap V3.

The price of a pool is calculated based upon the proportional amount of tokens within the pool. For instance, if there are 50 of token A and 10 of token B, then the trading of token A for B would 5:1.

In Uniswap V3, there is a TWAP (Time Waited Average Price) for the pricing. This means it's not trivial to manipulate the pool, since the time is a factor.

In the previous week, 1M in assets had been taken, leaving 550K total left. Additionally, the price of FLOAT had gone up considerably.

The attacker bought 77.5k float using 47ETH. The pool now contains 250K USDC and 5 FLOAT. After waiting a few minutes, the TWAP caught up and the price had drastically changed.

The attacker then deposited their overvalued FLOAT to get other assets. Since the FLOAT was overvalued, they were able to make a profit off of this.

Deus Finance is a derivatives trading platform. Calculating the price of a token is complicated in a decentralized system. If it is done via an off-chain oracle, like chainlink, then a deep amount of trust is being put into them. If it's being done by an algorithm, the algorithm can be manipulated to make the price too high or too low.

In this case, the price oracle is generated with some simple math from the Solidex pool:

(dei balance * usdc balance) / total supply

What would happen if one of these parameters was manipulated? By taking out a large flash loan, the price is drastically changed. In particular, taking out a large amount of DEI cuts the pool amount by a lot.

Once a users collateral is worse less than what they are trading on, their assets become insolvent. These accounts can be liquidated, giving the user the LP tokens from the liquidated users.

Since the attacker has their hands on a large amount of LP tokens, they can burn this to recoup the original value. Finally, they repay the flash loan and make a profit from other users derivatives.

What's the lesson here? Use a Time Waited Average Price (TWAP). The weighting the average price over time, like a large order, or flash loan, doesn't affect the price very much. A few extra links: Peckshield analysis and Rekt.news.

Miner/Maximal Extractable Value (MEV) is the capability of gaining profit by reordering or adding transactions in a block. This leads to arbitrage, frontrunning and sandwich attacks.

There is a MEV bot (0xbaDc0dE) that gained a large profit from an arbitrage opportunity. The bot is written in Solidity (starts with 0x60806040) but there is no verified contract code. So, the author uses the Dedaub decompiler to see the contract byte code back to Solidity.

The contract is using a delegateCall to call other implementation contracts. Its public functions are flash loan callbacks, which makes sense since it will use these for arbitrage opportunities. The callback for dYdX is interesting to look at.

Validating whether a function can be called is complicated to do within this context. The flashloan callback is being called from dYdX, but who initiated it? This is the vulnerability in the MEV bot.

The callback function has a bunch of logic. Sadly, the decompilation tools cannot decompile everything. So, the author of the post, trying to reproduce the exploit, used the error messages to help them figure out what was going on.

The MEV bot has a mechanism to approve the caller of the contract for spending the functions if the allowance if currently 0. Since we (the attacker) just called it, the code will give our contract now has the ability to transfer funds on behalf of the contract.

It's interesting to see a MEV bot get hacked. It is complicated to see how things works, since the decompilation tools for Solidity are not perfect yet. I wonder if we will see more attacks like this in the future!

Starstream is suite of products for revenue aggregation, generation and smart contract deployments. It exists on the Metis L2 rollup.

The DistributorTreasury contract had a low-level call that took in arbitrary input. This allows an attacker to perform arbitrary function calls as the contract. To exploit this, they called withdrawTokens in the StarstreamTreasury to send to 532,571,155.859 $STARS to themselves. The treasury's owner was this contract, which gave it complete control to do whatever it wants.

Arbitrary calls via a low-level call is very bad practice. Make sure to restrict this otherwise this type of attack will be possible.

Prototype Pollution is a vulnerability in JavaScript that allows for the overwriting of the __prototype__ object. By doing this, an attacker can overwrite the default properties of an object to cause all sorts of havoc. This is normally caused by blindly merging objects together. Does this similar vulnerability affect other languages?

The author of this post dove into how this could be utilized in Python. Instead of prototype pollution the author coined this class pollution. There are dunder (double underscore) methods such as __str__() and attributes such as __class__. In Python, it is possible to overwrite these properties at run time.

The functions __get/setattr__ and __get/setitem__ are used to set attributes about an object. If an attacker is able to set properties of a class arbitrarily using these functions, then we have class pollution. Similar to Prototype Pollution, this may happen when creating a Python class object from a JSON blob on the fly.

This is where the fun begins! What else can be overwrite besides attributes of a class? It turns out, that the functions mentioned above are much more generalized than you would expect. Using the .__base__, an attacker can traverse up the hierarchy of objects indefinitely, with some limitations. The main limitation is that the field we want to overwrite must be in the same hierarchy in the inheritance chain. Or, the __globals can be traversed and overwritten with this as well!

The author notes that this merging is more common than one would expect. The python version of lodash (pydash) had this exact problem in it. In an exploit demonstration with subprocess.Popen the author of the post overwrites the COMPSEC variable by traversing the globals to gain trivial command injection. There are an unlimited amount of primitives to view but many of them are going to be specific to the application in use.

Overall, a super nifty vulnerability that you may come across some day! Love this post and vuln class.

The function handleDeductFee() has no fee for incoming checks for who calls it and the amount. There were some other values that were controllable on this as well.

The attacker transferred almost all of the DDC tokens into the victim fees pool. This effectively turns into an infinite burn security problem from the pool as a result.

The trading value is pinned to the other token. For instance, if USDC is $1 and ETH is 15K, then the pool should have a 15K:1 ratio. So, when $DDC is mostly removed from the pool, the other token (USD) is significantly raised. The attacker can then swap very few DDC to get a large amount of USD.

Overall, an interesting bug that have devastating consequences. These finance manipulation vulnerabilities are complicated and subtle.

The article begins with a blurb on how to and how NOT to run a good bug bounty program. The first issue is NOT following up with emails from whitehats. Second is paying less than the advertised bounty or it being too small in the first place.

The second point is a major issue. If the bounty is 1K and the funds at risk is 1B, the incentive to steal far outweighs the reward; this makes it more likely that a vulnerability found will be exploited. Apparently, Balancer had advertised 2M but only paid of 25% on a previous bug.

Balancer is an AMM in the DeFi space. It allows a pool containing two or more tokens to swap between them, while the people providers liquidity get some proceed of the fees for performing the swaps. This is all very standard functionality for an AMM though.

MerkleRedeem's purpose is to distribute rewards. The original way this was architected only allowed for a single token per contract. This led the way for the Merkle Orchard contract, which allows for multiple tokens being claimable in a single contract. All rewards were in this contract.

The code for submitting a reward claim took in an array of ids. The program would iterate on these ids and send the user all of the tokens they deserved. At the end of the loop, it would mark the id as used, meaning it couldn't be claimed more than once.

The vulnerability is that the continue iterating through the list and ONLY at the end mark the id as used. This allowed for the same claim to be made several times, effectively creating an infinite claiming glitch. In total, between several chains, 3.2M of tokens could have been stolen. It should be noted that this was reported by the author of this post. They made 50ETH on an out of scope target, which is pretty cool. This code had made it past four security audits, which is pretty crazy.

Immunefi created an article with this as well.

HypeBears is a collectable set of NFT bears. mint is used to create new bears within this ecosystem.

When minting the NFTs, the code uses _safeMint from the OZ reference implementation. There is a map that checks to see whether or not a given address has minted an NFT. The safe is in regards to a check for the onERC721Received hook if it's a contract and has nothing to do with security.

The addressMinted is added at the end of the function. This violates the check-effects-use pattern. As a result, an attacker can mint the NFT and implement the hook within the _safeMint() function. Since the variable was not set, we can reenter the mintNFT function to create another one. Of course, this can be done as long as we can enough gas.

Overall, a fairly standard reentrancy vulnerability but fun to read about in 2022 none-the-less.