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!

How does a crypto exchange know when you sent it funds? Well, there is an address associated with the exchange. In particular, this is unique per user. A transfer is made to this address, which tells the exchange that you sent funds to them. The exchange needs to see this transfer happen via scanning for blocks. Finally, a specific amount of confirmations happen, validating that no reorg will occur. At this point, your exchange account will be credited with funds.

Recently, Kraken feel victim to a false top off attack. This articles goes into several ways that this can be exploited, from their own experience. In the case of CertiK on Kraken, it was pretty simple! Kraken was looking for a deposit made to this address within a successful transaction via logs. However, the attackers sent over the funds in a contract then reverted this function call, only to be handled (and ignored) by an upper level call. All Kraken was looking for was a transfer within the transaction that on a successful call.

Normally, I would guess that an event would be emitted for this to work. However, since it was transferring ETH directly, there is no event emitted. So, some weird and custom shenanigans has to be done for this. Apparently, the parsing being done was this didn't consider the case that CeritK tried. According to the Tweet, they tried this as several exchanges but only one of them worked.

The first two are simple issues with blockchain confirmations. If a fork happens after only a single confirmation or it simply looks in the mempool, then you're super duper F'ed since the transfer could have already reverted. Certain quirks of systems that are unique to it can cause issues as well.

The next set of issues deal with failures. If the transaction reverts, then the deposit shouldn't be counted, because the funds were never sent there in the first place. Type confusion can be an issue as well; getting one event to be processed as another type, such as in Felix's Polygon bug. Missing checks on the emitter of the smart contract are common as well.

There is also double spending issues, where you can provide the same transaction twice or something like that. In the case of Bitcoin, where ownership is confusing, it may be possible to make a transfer accessible to an account but YOU actually have control over the funds still.

They have a few other mentions of previous issues in other blockchains. The specific case study they reveal is about the TON blockchain integration issue, made by telegram. On the TON blockchain, is a cross contract call fails then it can bounce back. When this happens, a callback is made to the calling contract to fix whatever just happened. In the logs of the message, the field in_msg is used to determine the information. However, out_msgs will be the bounceback if it fails. If you only look at the in_msg and it bounces back, then leads to a false transfer.

How do we prevent this? Rigorous transaction matching needs to be done in order for this to be secure. It must be a perfect match and nothing else. Second, checking balances before and after a TX is a good source of truth. Finally, having detection's in place is helpful; this sounds easy, but is non-trivial given that there exist a failure in the system that allowed this to happen in the first place.

Overall, it's a good article on tricking off-chain infrastructure, which I really enjoyed. I also found a partial payments issue with integration with XRP wallets that was interesting while researching more into this.