Intern Breakdown #5: Crypto Hacks
Crypto hacks explained at 3 levels of depth (👶, 🐸, 🧠)
The first documented Viking attack occurred in 793 AD when Scandinavian raiders pillaged a monastery in Northern England. The local Christians, unable to comprehend that anyone could be so profane as to attack a holy site, were utterly unprepared. Who could have imagined that pacifist monks sitting on piles of gold and silver would make enticing targets for pagan warriors?
I imagine hackers look at the current crypto landscape in much the same way as Vikings looked at monasteries in the 8th century — with a glint in their eye, thinking “this is almost too easy.” Rich people who are new to crypto and don’t understand private keys and seed phrases are Web3’s defenseless monks; young DeFi projects with poor security practices are Web3’s monasteries; Bored Apes, protocol treasuries, and funds sitting in bridges are the Web3’s piles of gold, silver, and precious metals.
Coming off an especially bad string of recent exploits (in particular, the back-to-back Nomad Bridge hack on August 1st and the Slope Wallet hack on August 2nd), now seems like a good time to break down crypto hacks. Let’s answer the relevant questions for all levels of crypto users:
Normies: At a high level, what are the different types of attacks? Who’s vulnerable?
Degens: How can I minimize risks as a crypto user? What are the most important security best practices?
Gigabrains: How do various attacks actually work, so that I can do them myself design the most resilient, secure systems possible?
Level 1: Normie
Taxonomy of Hacks (Haxonomy?)
Hackers have come up with such a diverse assortment of ways to steal crypto-assets that it’s challenging to classify them all. Two useful dimensions Chainalysis uses to categorize hacks in its crime reports are victim type and general attack type.
Looking at victim type, we can see that attacks on cryptocurrency exchanges used to be in vogue, but DeFi protocol hacks are now all the rage. Exchanges used to be sketchy operations with lots of funds and lots of vulnerabilities. It was in their DNA, tracing all the way back to Mt. Gox — the porous OG Bitcoin exchange that started as a way to trade “Magic: The Gathering Online” cards. But as exchanges matured and went from this:
…to this:
…they became more resilient and hackers found easier pickings elsewhere.
Chainalysis also examined hacks based on the attack type — that is, the method hackers used to steal funds:
These categories are worth exploring in greater depth. Note that the definitions below are my own and probably don’t perfectly correspond to how Chainalysis classified these hacks. In fact, I’ll probably use a lot of terms slightly incorrectly — I care more about understanding the fundamentals of these attacks and how to avoid them rather than precisely defining the difference between “spoofing exploits” and “phishing attacks.”
Security Breaches
Hacks caused by security breaches are not unique to crypto, and several of the strategies used in these types of exploits come from the Web2 playbook.
Some of them use social engineering to take advantage of us weak, fragile humans instead of trying to attack code directly. Examples include…
🎣 Phishing: when an attacker pretends to be a reputable source, usually in an email or other message, to trick users.
Some phishing attempts are more respectable than others. You can (sort of) understand how users were conned back in February by fake OpenSea emails that (a.) were sent at the same time that OpenSea was sending out real notifications about a migration, (b.) looked identical to the actual OpenSea emails, and (c.) came from domains like “opensea.xyz” and “opeansae.io.”
Other phishing attacks have become so common as to be cliché:
You should beware of phishing attempts by fraudsters who find ways to hack Discord servers (e.g. this Monkey Kingdom hack), Instagram accounts (e.g. this Bored Ape hack), Twitter accounts (e.g. NFT influencer Zeneca’s account hack)… basically assume everyone on every app is trying to snatch your magic Internet money.
🐳 Whaling: phishing, but targeted at the important people in an organization.
The $540M Axie Infinity hack back in March is a prime example of whaling. Lazarus, a North Korean hacking group, duped a senior engineer at Axie into going through multiple rounds of interviews for a fake job with a hefty compensation package. They sent a malicious file disguised as a job offer and, when the engineer downloaded it, were almost able to take control of Axie’s Ronin network. After one final step — compromising a key held by Axie’s DAO — the hackers had everything they needed to steal the chain’s funds.🪝Baiting: phishing, but the attacker entices users into interacting with them by promising a reward.
If something seems too good to be true, it is. I hate to break it to you, but the only thing Elon Musk is giving out for free is memes and children. So maybe approach his crypto giveaway YouTube livestreams with a bit of skepticism.
🥸 Fake NFTs: when hackers convince a victim to buy NFTs from a fraudulent collection.
AKA when you buy a JPEG from someone but it turns out the JPEG you bought isn’t worth as much as you thought because it’s just a JPEG that happens to look the exact same as the JPEG you wanted.
Jokes aside, counterfeit products are a problem in lots of markets — even in the physical world. It’s easy to mock the notion of one JPEG being worth thousands of dollars while another one that looks the exact same is worthless (it’s basically the 'ol right click, save argument), but the same principle applies to Fake Yeezys and synthetic diamonds. The point is, make sure the NFTs you’re buying are legit, and the only way to be 100% sure is by confirming the collection’s on-chain address.
Other security breaches involve more technical sophistication but are still fundamentally a type of social engineering since they fool users into voluntarily signing fraudulent transactions rather than straight up grabbing their assets.
🖥 Front-end hacks: when the user interface (UI) of a protocol gets hijacked, fooling you into signing malicious transactions.
This happened recently to the popular DeFi protocol Curve, which suffered what’s called a DNS spoofing attack. Basically, a hacker was able to manipulate the protocol’s website so that the URL “curve.fi” redirected users to the hacker’s IP address instead of the correct IP address.
BadgerDAO suffered an even larger attack ($120M) in 2021 when its front end was compromised.📄 Token approval exploits: more on these in the Degen section.
Tl;dr: many apps require you to give them permission to transfer your tokens, and if you forget that you granted them these rights, they could nab your assets.
Are there other types of security breaches? You bet.
✂️ Clipper malware: This type of malicious software can hijack your clipboard so that when you copy and paste a crypto address to transfer funds, the destination address is replaced with a hacker’s address. While this type of hack is frightening, it’s also one of the easiest to avoid. Send test transactions before making major transfers, and double check the destination address every time you send crypto. Better yet, use a human-readable address if you’re sending coins to someone who uses ENS/Unstoppable Domains/a similar service.
🔑 Private key leaks and theft: Why bother fooling users into signing malicious transactions when you can just snatch their private keys or seed phrases? Attackers can either hack into a physical device, or they can engage in a cyber attack like the recent exploit that exposed the private keys generated by the Slope wallet. Slope used a service called Sentry (which helps with error logging), but the team neglected to obscure sensitive details. As a result, users’ unencrypted private keys were visible to an attacker who managed to hack into Sentry.
👤 Inside job: A project might have the best security in the world to protect against external attackers, but this doesn’t do much good if they can’t trust their own team members. A pretty depressing example of this comes from Velodrome Finance, which recently saw $350,000 drained from a wallet holding the protocol’s operating funds. It turned out a trusted team member known as Gabagool had taken the funds and, by his own account, had done so out of desperation to try to recoup his losses from the recent crash.
📁 Malicious file downloads: Not every file that looks like a PDF is actually a PDF. Be very careful about downloading and opening files from randos, and always double the file type — .scr and .exe files can run dangerous programs on your computer, and they can be disguised as innocuous PDFs.
🔧 $5 Wrench attack: If a hacker can link a public address holding a lot of crypto to a real-world identity, then it doesn’t matter how great that person’s online security is. A $5 wrench attack, also known as “rubber-hose cryptanalysis,” involves taking someone’s private key using physical coercion.
There have been many documented cases of these types of attacks. Is there any way to protect against these attacks? Yes — you can hold large amounts of crypto in more advanced wallets that require multiple parties to approve transactions, you can prioritize privacy to avoid having your identity leaked, and you can learn Krav Maga to fight off the attackers.
Code Exploits
Bugs in code can be just as catastrophic as security breaches. I’ll cover these in more depth later because there’s a wide range of technical screw-ups that can leave projects and protocols open to attacks.
Flash Loan Attacks
Flash loans are a powerful tool offered by DeFi protocols. Aave, probably the most in(famous) flash loan provider, describes them at a high level:
Flash Loans allow you to borrow any available amount of assets without putting up any collateral, as long as the liquidity is returned to the protocol within one block transaction.
Since the borrowed funds must be returned within a single atomic transaction — atomic means it’s “all or nothing,” so the loan is only made if the lender is certain it will be repaid — protocols face virtually no risk when providing flash loans.
Being able to borrow any available amount of funds without collateral makes flash loans a major asset to hackers. Having control of this much capital opens the door for novel strategies they wouldn’t otherwise be able to perform (e.g. price manipulation, hijacking governance votes) and also gives them the leverage needed to turn a small bug into an attack that can drain a project’s entire treasury. More details on the mechanics of these hacks can be found in the Gigabrain section.
Honorable Mention
There’s one notable type of malicious activity that I’m choosing not to cover in this post: rug pulls. A rug pull is when a team promotes its project’s token, convinces investors to put their money into it, and then runs away with the funds. There are a few different ways to complete the rug pull — yanking liquidity, restricting investors’ ability to sell, or simply dumping tokens.
Without getting into the semantics of what’s a hack versus a scam versus fraud versus a Ponzi, I’ll just say that rug pulls feel like a fundamentally different sub-category of “ways to lose your money in crypto” than the hacks mentioned above. Many rug pulls aren’t even illegal, just unethical. And the victims never lose possession of the tokens they bought — the tokens just turn out to be worthless. Still, reminiscing over the biggest rug pulls in crypto history can be an interesting walk down memory lane.
Normie Additional Resources:
Level 2: Degen
How to Minimize Risk
Crypto’s risky enough without having to worry about hacks. “Minimizing risk” isn’t something a 150x leveraged degen usually thinks about, but trust me — it’s much more fun to lose your hard-earned money yourself than to have it stolen by someone else. Let’s cover some tips and best practices.
1️⃣ Seed phrases versus private keys
A seed phrase (also called a “recovery phrase” or “mnemonic”) is a list of 12 to 24 random words that are generated whenever you set up a non-custodial wallet, like MetaMask, Phantom, Coinbase Wallet, or a hardware wallet. Most of these wallets are “deterministic wallets,” meaning they follow a standard that allows many private keys to be generated from a single seed phrase.
You can think of private keys as passwords that unlock the crypto held by individual addresses — there’s one private key to access the Bitcoin owned at address bc1qxy2…, another private key for the ETH owned at address 0xb794f…, and so on for other alt coins. But if these private keys were all generated from the same wallet provider — maybe they were all stored on the same Ledger wallet, for example — then they are all derived from the same seed phrase. This makes a seed phrase a bit like a master password to a password manager — if it gets lost or exposed, you could lose your crypto across lots of different accounts and chains.
Understanding the distinction between private keys and seed phrases can help you avoid making dumb mistakes. As a recent Solana hack unfolded and it became apparent that the attacker likely had access to leaked seed phrases, some people mistakenly thought they could protect their funds by creating a new “wallet” within the same browser extension. But creating a new address/private key when an attacker has access to the master seed phrase is useless. It’s like finding out your computer has a virus and thinking you’ll be safe by switching from one browser tab to a new one.
2️⃣ How cold is your cold wallet?
Quick reminder of Wallets 101:
🔥 Hot wallets are connected to the Internet; you should use them for frequent transactions, but don’t store lots of funds in them unless you want to get rekt.
🧊 Cold wallets store your keys offline (usually in a hardware wallet); they’re mainly used to buy and hold assets for longer durations.
Even your cold wallet will likely interact with the Internet sometimes — you usually have to connect to a computer with a cable or Bluetooth in order to buy and transfer coins. But when this happens, your private keys don’t leave the cold wallet. They’re used inside the wallet to sign transactions, and these transactions are what get passed to the computer.
All this to say… if you own a hardware wallet, then you spent ~$100-200 for the ability to hold your keys securely offline. Which means if you then do something like copying your seed phrase into Google Drive, or using your MetaMask seed phrase to seed your hardware wallet, or anything else that might expose your seed phrase or keys to the Internet, you’ve wasted your money (until you reset your wallet with a new seed).
3️⃣ Token approvals
Web3 apps that involve transferring tokens to and from smart contracts require users to grant the application permission to spend tokens on their behalf. This is necessary for using these apps, but what gets people into trouble is when they approve unlimited token allowances, which is often the default amount. More details on why allowances are necessary here.
You can grant applications transfer rights over both ERC-20 tokens and NFTs. The more applications you’ve approved, the larger the surface area you’ve created for being exposed to exploits. That’s why it’s important to carefully monitor your approvals (you can do so here) and revoke them when necessary. When should you revoke? Revoke.cash explains it well:
Choosing which allowances to revoke is always a trade-off between safety and convenience. For certain well-known protocols (e.g. Uniswap) it is most likely fine to leave allowances active, but for newer and unknown smart contracts, it is more prudent to revoke allowances. Also keep in mind that some use cases require you to keep your allowances active. For example, if you have active listings on OpenSea you need to keep the allowances in order for the listings to remain active.
…buuuut before you go on a revoking spree, remember that even revoking websites themselves can be malicious, so double check what you’re using. Only the paranoid survive:
For an example of a token approval gone wrong, consider the story of this user who put some UNI tokens into an obscure farming protocol, thought he was no longer at risk after he withdrew his tokens from the pool, and then had his tokens drained.
Or consider a somewhat different, but still related, issue that affected users who forgot they’d approved NFTs listings on OpenSea and later found that their treasured JPEGs had sold for waaaay below market value. (OpenSea has since implemented updates to help prevent this from happening.)
4️⃣ The MetaMask (Dis)Connection Myth
If you open your MetaMask browser extension, you can view all the websites you’re currently “connected” to. Connecting to a dapp allows the site to see things like your public address, wallet contents, and transaction history, and it also lets the dapp initiate transactions — that is, it can prompt MetaMask to give you a pop-up asking you to sign a transaction. It does not give the dapp permission to execute transactions on your behalf, and it is not the same as granting control over your assets like the token allowances I just mentioned.
Disconnecting MetaMask from sketchy sites you’re no longer using can’t hurt (MetaMask says it’s “good for your privacy,” but your data is stored publicly on-chain anyway so I’m not sure what the real benefit is…), but don’t fall into the trap of thinking it makes your tokens more secure.
5️⃣ SIM Swaps: Why Not All 2FAs Are Created Equal
Did you think your funds were safe just because you used 2FA, anon? Think again.
There are a few ways to set up two-factor authentication (2FA), which is a way for apps to verify your identity with an extra piece of information beyond your username and password. One of the most common methods is SMS-based 2FA. You know the flow:
Sign into a site ➡️ get sent a text with a numeric code ➡️ type it in ➡️ ??? ➡️ profit
The problem is, hackers have become adept at tricking phone companies into performing “SIM swaps.” They convince the company to associate your phone number with the attacker’s SIM card, giving them access to all the texts and calls that are meant for you. If they also find your username and password, your account has been compromised. Game over.
The solution? Use another 2FA method, such as Google Authenticator or a similar app-based strategy. It’s the exact same amount of effort, but more secure. No-brainer.
6️⃣ Beware of Bridges
This wouldn’t be a post on crypto hacks if I didn’t mention bridges.
To transfer funds from one chain to another, say from Ethereum to Solana, you need to use a bridge. It works like this: you connect your Ethereum and Solana wallets to an app, send ETH to a smart contract, wait some amount of time (it depends on the bridge), and then you’re given “wrapped” assets in your Solana wallet. These wrapped assets are pegged to the value of the underlying asset on the source chain because you should be able to redeem them when you bridge back.
Sounds simple, right? You can now start tossing assets back and forth across chains like it’s nothing!
…that is, until something goes horribly wrong.
If alarm bells started going off in your head when you heard “pegged to the value of…” and “…should be able to redeem,” then congrats — you’re learning how crypto works. Because if a bridge gets hacked and its funds get drained on Ethereum, then the wrapped assets you’re holding on Solana are now worthless.
What’s the lesson here? Be careful when bridging, and when you do, consider swapping wrapped assets for native assets on the destination chain to reduce your risk.
Note: the lock/mint process I just described is used by “trustless” bridges, which allow users to always retain control over their assets. There are also “trusted” bridges, which are operated by centralized entities and come with a different set of trade-offs. For example, trusted bridges might be more secure against smart contract vulnerabilities, but they introduce the risk of the centralized company’s private keys being compromised.
Degen Additional Resources:
Level 3: Gigabrain
Let’s explore some of these exploits in greater technical detail. Plz use this information for good and not for evil.
Hacks at the L1 Level
Some hacks take advantage of specific features of blockchains themselves. Here are a few of my favorites:
Replay attacks
A replay attack is when a hacker sends you an mp3 file containing the song Replay by Iyaz, but it’s actually malware.
Lol it’s actually when a hacker takes a transaction that a user meant to send in a particular context, and then re-uses that transaction in another context.
For example, if you use your private key to sign a transaction that says “Send 1 ETH from my address to Vitalik,” what’s stopping Vitalik from broadcasting the same transaction over and over again, taking 1 ETH from you each time? Ethereum solves this by including an “account nonce” — a counter of sorts — in every transaction you send so that any attempts to replay old transactions will be identified as duplicates and thrown out.
Replay attacks can also occur across chains that have hard forked, which is why transactions usually include some sort of chain ID. That way, when you send a transaction on Ethereum, the recipient can’t use the same transaction on Ethereum Classic to claim that you sent them ETC, too.
Assorted L1 Bugs
Not even the core code behind a blockchain is immune to bugs. Consider this list of historical Bitcoin vulnerabilities, and the fact that 184 billion bitcoins were once created out of thin air in a single block — slightly more than the intended 21 million cap.
Of course, other chains have had vulnerabilities, too, including a bug in Ethereum’s popular Geth client that affected over half the network, or the bug that put $24 billion (yes, BILLION) of Polygon’s MATIC token at risk.
There’s not much more to say about these types of bugs. They’re nightmare fuel, and there isn’t a whole lot individual users can do about them unless you’re an experienced white hat hacker.
Distinct L1 Features
Some L1s have unique features that create opportunities for hackers. Consider Tron’s set of Multi-Sig features, which allow accounts to delegate their signing permission to other addresses. This is not possible on Ethereum. A clever Tron dev realized you could take advantage of this with a few simple steps…
Set up Account A and transfer its signing permission to Account B, which you control.
Load up Account A with some funds — make sure they’re TRC-20 tokens, not the native TRX that’s used for gas on Tron.
Send out thousands of DMs on Twitter saying you’re a student who needs help transferring those funds. Include the private key for Account A.
When someone tries to log in to the wallet using the private key, they’ll see the TRC-20 tokens sitting there and will attempt to claim them by transferring them to another account. They just need some TRX for gas…
When the user sends TRX to Account A to pay for gas, they’ll find that they can’t make transactions from the wallet because it doesn’t actually control its own signing permission. Meanwhile, you use Account B to help yourself to the TRX they transferred into the wallet.
Hacks at the App/Project Level
Most of the time, L1s themselves run perfectly fine, and it’s the apps built on top of them that introduce bugs. Rekt maintains a leaderboard of the top DeFi protocol hacks if you want a nearly exhaustive list.
One notable hack missing from Rekt’s list, and perhaps the most famous exploit in crypto history, was The DAO hack in 2016. There have literally been entire books written on this, so my brief explanation will not do the hack full justice, but the hacker used what’s called a “re-entrancy attack.” This is when a hacker uses a custom smart contract to exploit another smart contract by repeatedly running code before the target contract has time to update itself. The DAO hacker, for example, kept withdrawing funds before The DAO’s smart contract had time to update its token balances. (Fun fact: the bug was introduced on line 666 of the smart contract code. You can’t make this stuff up.)
Flash loans, which I quickly defined earlier, can also be used to attack protocols. Cream Finance has been drained multiple times by flash loan attacks that manipulated the system it used to price the tokens in its vaults. The ~$130 million October 2021 hack occurred when a hacker noticed a vulnerability in Cream’s internal PriceOracleProxy. The bug allowed the attacker to use flash loans to manipulate Cream’s vault into effectively thinking $1 of collateral was actually worth $2. The hacker then drained Cream’s funds by taking out a massive loan against this inflated collateral, defaulting, and keeping the excess coins.
Beanstalk, a stablecoin protocol, was hacked in April 2022 using a different, novel flash loan strategy. The attacker used a flash loan to temporarily acquire enough voting power to execute a malicious emergency governance proposal that stole all of the project’s funds. Check out a post mortem of this attack for more details — it’s an intriguing one that highlights the weaknesses of untested governance mechanisms.
Hacks We Haven’t Seen (Yet)
There are a few types of attacks and vulnerabilities that we know exist, but which have not yet actually occurred.
Widespread key generation exploits
When we initiate a new crypto wallet, we take it for granted that the private keys were generated in a safe, random manner. But that’s not always the case. Consider this bug in 2017 which, although unrelated to blockchain, affected many devices that used RSA key pairs. A particular chipset had a vulnerability that made it possible for certain private keys to be derived from public keys if an attacker had enough compute power. At the time, researchers estimated it would cost an attacker “about $76 to do the factorization for a 1024-bit key … and roughly $40,000 to do the same with a 2048-bit key,” and reported that “at least 760,000 keys generated by the chipset” were at risk. If a bug of this magnitude occurred in, say, a popular crypto hardware wallet…. well, it would be bad.
Quantum attacks
The current state of quantum security <> crypto is a nuanced, fascinating topic that most people don’t fully understand.
Each L1 will approach the quantum issue slightly differently, so I’ll focus on the two big guys: ETH and BTC.
Ethereum’s top-notch group of core devs have already started looking into alternatives to ECDSA, and my guess is they’ll take after the standards released by the National Institute of Standards and Technology (NIST) — a group that’s been working on evaluating quantum-resistant public-key cryptographic algorithms. The Ethereum ecosystem is constantly improving and iterating, so implementing these new schemes should be challenging but extremely feasible. Even the Ethereum L2 roadmap acknowledges the long-term superiority of STARKs (a quantum-secure ZK rollup) over SNARKs (which are not quantum-safe).
Bitcoin, on the other hand, is not known for being receptive to change. If push comes to shove and the community has to choose between making a major upgrade or risking systemic vulnerabilities, something tells me they’ll rally and make the needed updates. But the Bitcoin core devs certainly won’t be pioneers relative to other L1s.
What might a quantum attack look like? Around 25% of BTC (including most of Satoshi’s bags) is currently stored using “pay to public key” (p2pk) transactions, which are at risk of being stolen by anyone with a sufficiently powerful quantum computer. When quantum computers will actually become “sufficiently powerful” to derive the private key for a given public key is uncertain, but it’s not unthinkable that it could be as soon as 10-20 years from now.
The entire Bitcoin network will be at risk once quantum computers become advanced enough to derive a private key from its public key in 10 minutes or less since every transaction (even those that aren’t p2pk) would be at risk of being hacked while they’re being mined. Check out this article for a deep dive.
Major 51% attack
Gigabrains ought to know what a 51% attack is, so I won’t bother giving a detailed explanation. All major blockchains use consensus mechanisms that makes attacks of this sort prohibitively expensive, with the possible exception of attacks by major nation-states. And even if an attack were to occur, it’s possible that the social layer of the exploited blockchain would kick in, with the community agreeing to hard fork to revert to a pre-attack state.
Interestingly, smaller chains have experienced exploits that could be considered 51% attacks. Check out this story of a user making $200K through a chain re-org that scammed Gate.io out of ETC in 2019.
Gigabrain Additional Resources:
That’s it for this breakdown — hope you learned a thing or two. It’d be great if this info helped protect someone out there from getting hacked, but something tells me it will probably just be used by people on Twitter to anon-splain to victims of the next hack what they did wrong. ¯\_(ツ)_/¯
As always, sharing this Breakdown post (or ones from prior weeks) would be greatly appreciated, and please hmu on Twitter @MarkMBissell with feedback, criticism, or ideas for future topics. 🫡