A Practical Guide on Honeypot Attacks in Smart Contracts
A honeypot is a trap set to detect hackers. Reentrancy attack is one of the vulnerabilities that affects decentralised systems badly. To combat such threats, developers employ techniques like honeypots. It functions by luring potential attackers into revealing their tactics so that developers get valuable insights for improving security measures.
Common Techniques Used in Honeypot
Reentrancy Attacks: Tricking a contract into calling malicious external contracts repeatedly. Learn more about this attack from this article.
Misleading Logic: Using complex logic structures to confuse and indirectly adding malicious code enabling anomalous behaviour during execution.
Hidden Control Structures: Using hidden control structures to manipulate fund flow causes unexpected behaviour.
How to protect from Smart Contract Exploitation?
Code Review: Continued code review and security audits are essential before deploying any contracts.
Monitoring Transactions: Analyse contract interactions and notice if there are irregularities, repetitive transactions, and unexpected behaviour.
Verify External contracts: Review external contracts if you are using them and make sure they are valid and free from vulnerabilities.
Research: Before interacting with any contracts conduct research, code reviews, and community feedback.
Use reliable sources: Use libraries like Open zeppelin that are verified over time. Such libraries reduce code and logic errors and provide verified best practices.
Audit contracts: Performing basic security audits will help to identify potential honeypots.
Sample Smart Contract for Demonstration of Attack
By combining two exploits, reentrancy and hiding malicious code, we can build a contract that will catch attackers. Here we will deploy three contracts: a Bank, a Logger, and a Honeypot contract. This Bank contract contains a function to deposit and withdraw Ethers. Logger contracts act as event loggers, recording information about events.
Complete smart contract code:
The attacker notices these contracts except Honeypot because it is stored in a separate file, code is not visible externally. As the attacker notes the Bank contract is vulnerable to liquidity drainage lacking reentrancy measure in its withdrawal function, and deploys an attack contract that triggers recursive calls to the Bank contract's withdraw function via the Attack contract's fallback function upon receiving ether.
Let us build on Scaffold-Eth 2 x Buildbear that lets you create your own private Sandbox, forked for various EVM and EVM-compatible blockchain networks, with your own Token faucet and blockchain explorer. Find the complete project here. Follow the instructions given below:
- Clone the repository and install dependencies:
git clone https://github.com/BuildBearLabs/honeypots.git
cd honeypots
yarn install
- Create your private sandbox
yarn fork-bb
- Copy and paste the smart contracts provided above to the contracts folder inside Hardhat. Also, modify the deployment script. Now deploy smart contracts using the command:
yarn deploy
It will deploy all your contracts and you will get a similar output as given below:
- On a second terminal, start your NextJS app:
yarn start
Visit your app on: http://localhost:3000
. You can interact with your smart contract using the Debug Contracts
page. You will get a screen like this:
Select the Bank contract and deposit some tokens by calling the deposit function. After a successful transaction, it will show like this:
Now from the attack contract call the attack function and see if it can utilise the vulnerability.
Tada!! Attackers attempt to exploit the vulnerability fails and all the deposits remain locked in Bank contracts. Honeypot neutralises the attack and turns into a trap for the hacker.
Summarise the process step by step with Alice and Eve:
Initial Deposit: Alice deposits 10 Ether into the Bank contract.
Attack Initiation: Eve, the attacker, calls the
Attack.attack()
function, intending to exploit a reentrancy vulnerability in the Bank contract.Deposit and Withdraw: Within the
attack()
function, Eve first deposits 1 Ether into the Bank contract and then immediately calls the Bank'swithdraw()
function to retrieve the just-deposited 1 Ether.Reentrancy Exploitation: When the Bank contract sends 1 Ether back to the Attack contract without a receive function, it triggers the fallback function in the Attack contract. This fallback function recursively calls the Bank contract's
withdraw()
function until all of Alice's 10 Ethers are drained to the Attack contract.Logger Object Manipulation: When Alice deployed the Bank contract, the
_logger
parameter in the constructor was set to the address of the Honeypot contract instead of the real Logger contract. Despite the identical interfaces of the Logger and Honeypot contracts, the Bank contract interacts with the Honeypot contract.Log Function Execution: The Bank contract executes
logger.log(msg.sender, _amount, "Withdraw");
, which is actually invoking thelog()
function of the Honeypot contract.Trap Activation: The Honeypots
log()
function detects the string "Withdraw" passed from the Bank contract and executesrevert("It's a trap");
, effectively reverting all transactions.Transaction Rollback: Due to the revert, all transactions within the Bank's
withdraw()
function call are rolled back. This means neither Alice's deposited Ether nor Eve's deposited Ether is accessible.Outcome: Eve's attempt to exploit the reentrancy vulnerability fails, and both Alice's and Eve's Ether remain locked in the Bank contract, effectively neutralising the attack and turning it into a trap for the attacker.
About BuildBear:
BuildBear is a platform tailored for DApp development and testing. Developers gain the freedom to construct a personalised Private Testnet sandbox across various blockchain networks. The liberty to mint unlimited Native and ERC20 tokens and rapid transaction times on BuildBear (under 3 seconds!) enhances the DApp development life cycle manifold. The platform comes equipped with tools designed for real-time testing and debugging, ensuring developers can keep tabs on intricate blockchain transactions with unparalleled ease.
Connect with us onTwitter | LinkedIn | Telegram | GitHub
Author: Sana
Subscribe to my newsletter
Read articles from BuildBear directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
BuildBear
BuildBear
BuildBear is a platform for testing dApps at scale, for teams. It provides users with their own private Testnet to test their smart contracts and dApps, which can be forked from any EVM chain. It also provides a Faucet, Explorer, and RPC for testing purposes.