Honeypots — How the Community Fights Back Against Hackers
Read Honeypots — How the Community Fights Back Against Hackers in the new NGRAVE Blog.
A war is being waged on blockchain. On one side of the war are cryptocurrency thieves who aggressively seek out weak smart contracts to exploit and steal from. On the other are cunning and sneaky smart contract developers, who create seemingly vulnerable smart contracts as traps for the thieves; baiting their hooks with delicious cryptocurrency rewards.
For the would-be thief there is a problem: to exploit the weakness in the code and unlock their tasty reward, the attacker must send a little crypto of their own to the smart contract. For example, to hack a ‘vulnerable’ contract and grab the 20 ETH lying inside it, they must first send 1 ETH of their own. In that moment the trap is sprung, snaring the ETH and paying out absolutely nothing.
It’s a Honeypot!
The trick, or some might say artistry, in creating a honeypot, is making the contract appear to have a flaw which, in fact, it does not. This bamboozles the thief, while at the same time relying on their greed to trump good sense. The need for speed is another factor which assists the crafty smart contract developers in the con.
Every hacker scouring the blockchain for weak smart contracts to steal from knows they have company. They are not the only thief seeking contracts to exploit, and there is only limited time to act. For that reason they may not be as thorough with their examination of the code as they should be. Adding to the difficulty for hackers is the fact there are a great number of differing methods that smart contract developers can use to trick would-be attackers.
In a 2019 paper from USENIX (the advanced computing systems association), researchers identified 8 different types of honeypot smart contracts, taking advantage of issues which can arise in 3 different areas of implementation. These 3 levels are:
1. The Ethereum Virtual Machine
Although the behaviour of the EVM follows a known set of practices and rules, there are ways that smart contract developers can present their code which is misleading or confusing at first glance. For the unwary hacker these tricks can be costly.
2. The Solidity Compiler
The second area smart contract developers can take advantage of, lies within the compiler. While some issues at compiler level are known, others may not be as well documented. Without testing the contract under real-world conditions these honeypots can be very difficult to spot.
3. The Etherscan Blockchain Explorer
The third type of honeypot relies on the incomplete nature of the data displayed on blockchain explorers. While many implicitly trust the data delivered by Etherscan, it doesn’t always display the full picture. There are intricacies of the explorer which wily smart contract developers can take advantage of.
Case Study
Twitter user Robert Miller shared a smart contract honeypot valued at 30 ETH which took advantage of the third level of misdirection in Etherscan Blockchain Explorer. This use case is worth further examination. As Miller points out, the contract does look vulnerable. In the contract there is a call to a string called ‘_response’. So, if the hacker can find the admin’s original transaction, surely they can find the value of _response in Etherscan.
A quick search on Etherscan reveals that the _question string contains a riddle which reads, ‘Name three days consecutively where none of the seven days of the week appear.’
It also reveals the ‘correct’ input for the _response string directly below it in black and white. The correct answer is, ‘yesterday — today — tomorroW’. That’s not a typo, it’s tomorroW with a capital W at the end.
Once the string value is found the solution is clear. All the thief needs to do is process a transaction with an ETH value greater than 1, say 1.1 or 1.00001, enter the string value in the _response field as ‘yesterday — today — tomorroW’, and collect the 30 ETH in the honeypot.
Not so fast. Hidden away within the contract is an internal call that updates the _response string to something other than the answer shown by Etherscan. A quick check on the ‘Internal Txns’ tab shows it clearly. Anyone who attempts to complete the contract with the supplied answer of ‘yesterday — today — tomorroW’ will lose their ETH.
In this particular example the sneaky contract creator walked away with 3 ETH of other people’s money. This same contract (albeit with a different riddle) was discussed by Scott Bigelow on YouTube in July of 2020. Either the honeypot creator has been running this same honeypot for a long time, or there are multiple people running the same con game.
The Morality of Honeypots
There are few in crypto who will shed a tear for the hackers who lose ETH in a honeypot. They were greedy and lost their money while trying to perpetrate a crime. On the other hand, those stealing from hackers are also committing a theft.
It is, however, the sort of underhand activity that most users can probably live with. Even in their sneakiness, honeypot creators are seen to be scoring a few points back for the ‘good guys’. For that reason, most of us can look away, and perhaps even feel some sort of smug satisfaction that hackers don’t always have it their own way.
Read the latest articles in the new NGRAVE Blog.
About the author: Ruben Merre is a tech entrepreneur, polyglot, life-long learner and founder and CEO of NGRAVE, the digital asset security company behind “ZERO”, the most secure cryptocurrency wallet in the world. Since 2018, Ruben and his team have partnered up with the top tier in nanotechnology, cryptography and hardware security, as well as thought leaders such as Jean-Jacques Quisquater, famous cryptography professor and second reference of the bitcoin paper. The result: a true end-to-end solution for managing digital assets, at maximum security (EAL7, highest security certification in the world), and an intuitive user interaction.
Other articles by Ruben Merre:
