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!

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.

XMPP is a messaging protocol based on XML. This is based upon short snippets of XML called stanzas. These messages are sent over the same stream connection as control messages to the server. XMPP allows the client to have full control of data within the <body> tag, including their false XML snippets.

If a user could escape this XML, to get into the control section of the message, they could add arbitrary stanzas into the data. The author dubbed this attack XMPP Stanza Smuggling. Since there are two points of parsing: server and client, the difference between these could cause problems. This is where the author searched for vulnerabilities at.

Between the server-side (Expat) and client-side (Gloox), there are two XML parsers: gloox and fast_xml (Expat). Both of these support UTF-8 but handle it differently. Expat is fully UTF-8 aware and handles errors appropriately. Gloox has only a minor effort to detect invalid characters, since it does the parsing character by character.

One the server-side, it will send aa\xeb><aa;. The \xeb designates a unicode character is being used, since this denotes the 3-byte prefix for UTF-8. Once Expat receives this, it does not check that the next two characters in the sequence at valid - it adds them to the XML tag as is by creating <aa\xeb><aa/> from our input.

Once Gloox receives the data, it will NOT see 0eB as the start of the 3-byte sequence. Instead, it is just another character in the tag name. It will read the data as two tags: <aa\xeb> and <aa/>. Neat! We have smuggled in a closing tag to the client.

As a result, the author believes it is possible to escape the <message> tag. To exploit this, they used a quirk within Gloox: smuggle in the tag <?xml ?> in order to completely reset the state of the parser, making our node the new root node. This is only possible because of the UTF-8 encoding bug talked about before. As, otherwise, it would remove the <?xml ?> data.

With the smuggling bug in the XML stanzas, how do we actually exploit this? Of course, we can know spoof users and control things that we normally cannot control. However, we can do better! Using the <stream:error> tag, we can specify all of the servers that the device be using, since we can control the endpoint this goes to. This effectively man in the middles the entire connection!

With the man in the middle position, we can exploit the update process to get code execution. This was done by first downgrading the Zoom client to an older version (that is still signed) then exploiting an unverified .cab file, which contains installation data. The replaced .cab file will NOT call Zoom as it should. Instead, it can call an arbitrary file, such as cmd.exe.

After posting this, the author found an additional smuggling bug unrelated to the previous finding. When the server uses Expat, it creates a parser with a newline as the delimiter between the namespace URI and the local part of the name. Since we can add arbitrary data into this (including newlines), we can confuse the two modes.

Since the parser believes we have added a delimiter (when we really haven't), we can smuggle in arbitrary XML tags. This leads to the same XML stanza smuggling bug as before. This was simply done by adding a newline!

Overall, I love this report because of the parsing differences between two XML parsers. Even without memory corruption, Zoom can still be compromised. I also enjoyed the downgrade attack, proving that cryptographic signatures are not enough (no wonder Apple limits versions on iOS).

OGNL (Object Graph Navigation Library) is an expression language used for getting and setting properties of Java Objects. This is used by a plethora of big products, such as Apache Struts.

OGNL evaluations are exploitable when OGNL code is evaluated twice. According to the author, this is often done when the findString() or findValue() function is called consecutively inside an object with nested calls. While reading on previous work, the author noticed that special Apache strut files called ftl (FreeMarker) files can also have OGNL expressions.

ftl (FreeMarker) files are used to define how an element will present itself in the final HTML code. Within a ftl file there was a call to findString() on a user controlled parameter. Then, later on, the function getText() is called, which has a nested call to findValue().

The code for the call is stack.findValue("getText('" + text + "')");, where text is user controllable data. getText() appears to have limited functionality for getting code execution. But, because we have a string concatenation on a dynamic query language, we can escape the original call and make our own call. This is similar to SQL injection in that way.

The payload text = a') + #application + getText('b will result in us escaping the getText() function to allow arbitrary queries to be ran. Using this, a payload to achieve code execution can be made but is too long to put into this resource. The article has a good example of this though.

The author found a minor XSS issue on the onChange event. This required user interaction in order to exploit though. Overall, I really enjoyed the double OGNL bug leading to code execution in Struts. It is interesting to see a query language that I'm unfamiliar with get exploited in a way similar to SQL injection.