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!

Randomness on the blockchain is a known problem. Regardless, people are still trying to make random functions for themselves, only to fail. This article dives into HOW this is done.

Many of them try to use block variables in order to provide randomness. block.coinbase is the miner of the block, block.number is the height of the current block and so on. An attacker can manipulate these if they have enough resources.

Or, even worse, they could write a smart contract that executes code within the same block used in the PRNG contract. Then, they have all of this information and have completely broken the randomness. The author shows examples using SHA3 of timestamp, block.number and a combination of many others.

blockhash is the verification hash of the block being mined. Why is this bad? blockhash.number will always yield 0, since the data is not known until after execution. blockhash.number - 1. For this one, an attacker can execute code within the same block of the smart contract.

Wait, there is more! block.blockhash() seems great. However, Ethereum only keeps track of the most recent 256 block hashes. After this, 0 is return. As a result, the random number could be predicted, if the new code was executed 256 blocks later. This happened within a SmartBillions lottery.

Want to use private modifier for a seed? That will not work either! Although this is private to the smart contracts, it is trivial to get this information off-chain then make the transaction with this information inside of it.

In Ethereum, the miners choose transactions to create a new block based upon the gas used by the transaction. Hence, the ordering can be manipulated by adding more gas to transaction that you wrote. This can be abused when the execution flow depends on its position in a block; the attack is called Frontrunning.

The article has a great example of this being abused. A lottery could use an external oracle to get a random number. An attacker could observe the pool of pending transactions and wait for the oracle to put data in. The attacker could see this random data, use it to break the randomness and put their data in with a higher gas price to go sooner.

How to fix this problem? Oraclize is a service for distributed applications to go between the blockchain and internet. Here, the random data could be grabbed, then used for verification of previously gathered data. A few other math-y ways were mentioned as well, such as signidice and a commit-reveal approach.

Parity had wallets for cryptocurrency These had to be deployed by users, where their money was inside of it.

The wallet had two contracts: Wallet and WalletLibrary. If the withdraw() function was not called, then the call was sent to the WalletLibrary code. What's the problem here?

Any function within WalletLibrary can be called within the context of the Wallet. In particular, the function initWallet() could be called to change the owner of a contract through this arbitrary delegated call. Yikes!

Since the attacker is the owner of the wallet, they can drain all of the funds from the wallet. Wow, that's pretty horrible. Why did this happen?

All functions are default external and public. If the contract would checked for double initialization or put this function as internal, then this would not have been possible. It is believed that the authors thought that since the function had NO modifiers for the outside visibility, they were safe.

A white-hat hacker identified and drained all remaining wallets to give back to the rightful others. Blockchain is great because it's permanent. But, humans make mistakes, which lead to these issues.

All Parity Multisig wallets use a single library.The wallet had a fallback function that called the walletLibrary with the users data. This is great for modularity, making the cost of a wallet much cheaper.

Here is the problem though: the WalletLibrary is a contract itself with its own state instead of a library. This means we can make calls to the WalletLibrary smart contract itself.

An "non-malicious" attacker called initWallet() of the library, which gave them ownership of the contract. Now, the user got scared of what had just happened and called kill(). This library was now completely nuked, making the funds impossible to gather.

Overall, the person who performed this felt real bad but a bugs a bug!

Reentrancy. Several pieces of functionality in Solidity can have fallback functions or hooks on specific actions. When these hooks are triggered (mid-smart contact), an attacker can run their own code. If the state of the contract was not updated already but money sent, then this can be called recursively to bypass the validations in place.

Integer Over/underflows: There is a limit to how large a number in Ethereum can be. For instance, a uint8 has a max value of 256 and a minimum size of 0. If the arithmetic goes too positive or too negative, then this can wrap back around.

Unexpected Ether: Money can be force-sent to a contract by using either the self-destruct or suicide functions. While doing validation on the data, this could be used to manipulate the service or turn on unexpected functionality.

Delegatecall: Call and DELEGATECALL are used for making function calls to an external function. The only difference is that DELEGATECALL is called within the context of the smart contract itself. When dealing with libraries, ownership and state variables need to be considered.

Bad RNG. Randomness is hard to generate in the blockchain. Some people try but things can be predicted in a variety of ways.

Frontrunning. Manipulating the chain of events by looking into the pool of available transactions and putting yours in at the right time. Or, taking an answer then submitting yourself with a higher gas price to KNOW yours will be used.

The post has a few other interesting bugs of Ethereum that are not as common now-a-days, such as Bad Constructors and unchecked return values. Additionally, some quirks are mentioned about one time addresses and other things. Overall, amazing post with great examples.

Somebody built a Ponzi scheme on Ethereum from 4chan (go figure). The ERC-20 allowed for an approved user to transfer token upon their behalf. Since this is a ponzi scheme, this makes total sense.

When this transfer functionality was happening, an integer underflow occurs. Since the value is unsigned, the should be negative value turns into an extremely large positive number.

This appears to be an edge case where some money is being taken by the contract for simply performing the services. This attack is only possible when an empty second account makes the transfer with only a single coin in the other account. Neat!

Once an attacker has the maximum amount of coin, they can easily exchange this for Ethereum. This attack ended up being 800K in a single attack.

The DAO (Decentralized Autonomous Organization) is an entity without any leadership. This was a concept implemented on the Ethereum blockchain with a substantial amount of money.

The DAO has a piece of functionality called splitDao to ensure that the minority could create their own DAO if the majority was being unfair to them.

This functionality works by somebody splitting the DAO into two different ones. The person who does the split puts their token (from the DAO) into this contract. Afterwards, the funds of the splitter are updated to reflect this.

The vulnerable code is shown below for a reentrancy attack:

...
Transfer(msg.sender, 0, balances[msg.sender]);
withdrawRewardFor(msg.sender);
 
...

totalSupply -= balances[msg.sender];  
balances[msg.sender] = 0;
paidOut[msg.sender] = 0;

The problem has to do with hooks when sending money and other functionality. Once Transfer is called, the initiator of the call can be recalled at this point with the hook. Then, the attacker can recall this function in a nested fashion.

This is a problem because of the Transfer call being triggered multiple times. By doing this, an attacker could get their funds transfers several times!

To fix this type of problem, the state update for the balances of the user in the contract MUST be updated prior to sending the money. Otherwise, this attack is possible. Of course, some other manipulations had to be done in order to exploit this though.

The DAO was the first major application on Ethereum. This hack was a big deal at the time and led to a general suspicion in blockchain technology as actually being secure.

Loans using different assets to know how to equate apples and oranges. This is done by using a Pricing Oracle, such as ChainLink, that provides the market cost of each token.

Terraform Labs’ UST and LUNA tokens feel dramatically in May of 2022. So, what happens when the token is drastically fluctuates? A freeze can be put onto it by the Pricing Oracle.

Is there a problem with this? Once the freeze occurred, the PriceOrcale price of the LUNA token was much higher than the market value. As a result, an attacker could perform flash loan attacks with this HIGHER value of the tokens to steal money from other locations.

This attack was not a single location, since it was Chainlink that made the mistake. Hence, both Venus Protocol and Blizz Finance lost 20 million in total.

Both of these companies did exactly what they were supposed to do with the Price Oracle as a service. However, they still got pwned. Maybe using TWO PriceOracles would have prevented this from occurring?

Fei Protocol is a direct incentive stable coin which is undercollateralized and fully decentralized.

A recent update to their code fixed a reentrancy. This occurs when the check-effect-interaction pattern is not used. In other words, doing some action then updating the state of the contract later.

Why is this a bad flow? When sending money, or performing actions against a smart contract, a hook can be set on that interaction. Then, within the hook, the code can be called once again, putting the contract into a very weird state.

In this case, not all of the reentrancy bugs were fixed. The attacker abused two functions in this case: exitMarket and borrow. exitMarket verifies that a deposit is no longer being used as collateral, then withdraws it. borrow lets a user take out a loan.

The reentrancy attack was performed by calling borrow using a smart contact. When the function sends the loaned amount of money, it has NOT updated the internal state of that the asset is being used as collateral. As a result, a nested call can to exitMarket extracts the collateral for the loan.

This leads to the ability to extract the deposit used as collateral for the loan. This effectively allows infinite money to be borrowed, since nothing is used as collateral. $80 million was stolen using this technique.

CosmWasm is a supposed to be a safe way to build smart contracts. In particular, it's a smart contract platform for the Cosmos ecosystem that is not vulnerable to re-entrancy and other common attacks for blockchain applications.

Bech32 is a format for Segregated Witness (SegWit) addresses. These are composed of 32 letters and numbers, where the letters all either all uppercase or lowercase. The issue is that the address has an inherit assumption on how it is used. Developers believe that either the addr_validate function will normalize it or they MUST be all lowercase.

Why is this bad? Validity checks and many other things can be bypassed. For instance, a blocklist of addresses could use this trick to reuse the contract. Additionally, a single user can create multiple of a resource, which would give them an unfair advantage in the group. Finally, tokens can be locked. In the case of CW20 tokens, an uppercase address can be used for sending but transferring only allows for lowercase.

Overall, the difference between case sensitive and case insensitive bugs has been plaguing developers for years. This is just another case of that occurring.

Rikkei Finance ("RiFi") is a decentralized finance protocol that handles transactions on public ledgers. This allows for cross-chain integration to receive digital assets from different blockchain networks. This renders assets at an identical rate, making it a real time exchange currency.

RiFi uses a PriceOracle to determine the trading cost of each token. The hacker found an access control bug within the token oracle smart contact for RiFi.

There is a public/external function called setOracleData. Since this is public and external without any access control, anybody is able to set the prices of tokens. Yikes!

The attacker provided the service with a small amount of collateral in some coin. Normally, this is to ensure that a loan will be paid back. Since the PriceOracle is manipulated, an attacker can make the exchange rate extremely beneficial for them!

At this point, the attacker used the money taken from the manipulated token to get an insane amount of other money from the contract. By the end, they stole an estimated $1 Million dollar in DAI, BUSD and several other currencies.

This is a very simple access control bug that should have been caught during testing. It is fascinating to see these obvious bugs provide millions in losses.