BuildBear
A Practical Guide on Honeypot Attacks in Smart Contracts

A Practical Guide on Honeypot Attacks in Smart Contracts

BuildBear's photo
BuildBear
·

5 min read

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:

carbon (3).png

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.

carbon (4).png

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:

one.png

  • 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:

two.png

Select the Bank contract and deposit some tokens by calling the deposit function. After a successful transaction, it will show like this:

three.png

Now from the attack contract call the attack function and see if it can utilise the vulnerability.

four.png

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's withdraw() 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 the log() function of the Honeypot contract.

  • Trap Activation: The Honeypots log() function detects the string "Withdraw" passed from the Bank contract and executes revert("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

Web3smartcontractSecuritySolidity#SmartContractsSecurityBlockchainTestingTutorialDeveloper Tools