Honeypot Attack

Defining Honeypot Attack

A Honeypot is a smart contract that pretends to leak its funds to an arbitrary user, who is the victim, provided that the user deposits some sort of fund into the contract. Once the fund is sent the attacker will be able to trap the user and retrieve all of the funds. Usually, the honeypot attack is carried out in three phases:

1. The attacker creates and deploys a contract with the appearance of vulnerability via the form of a baiting of funds

2. The victim tries to exploit the contract by transferring the required amount of funds, failing in the process

3. The attacker will withdrawal the bait contract with the funds that the victim had sent, thus keeping the funds.

There are no special capabilities to execute a honeypot attack, the only requirement in the starting funds to deploy the smart contract and place the bait.

Taxonomy of Honeypot Attacks:

Ethereum Virtual Machine

Balance Disorder: Every smart contract in Ethereum has some sort of balance implemented within it. A function call is sent to any arbitrary user with the assumption that all the user needs to do is call the function with a value equal or higher than the current balance. However, the condition in which the balance is transferred to the user is no longer accessible as the function already increments.

Solidity Compiler

Inheritance Disorder: Inheritance creates a single contract on the blockchain that can take code from multiple base contracts. What can occur is an overwrite of variables to where when declaring the user as the owner the task is successful, but when attempting to withdraw the balance the task is failed. This is because whatever owner variable is being used is duplicated and separate to where the user is not given the owner variable that accepts inheritance from the base classes.

Skip Empty String Literal: These contract usually allows some sort of misinterpretation to give the impression that the smart contract can be exploited by some user. After the user invests funds, they will often attempt to abuse whatever feature is vulnerable. A well placed empty string as a conditional will appear in the code giving access of diverting funds only to the contract owner.

Type Deduction Overflow: In Solidity declaring a variable as a type var will make the compiler attempt to infer the data type using the first expression assigned. This deduced variable type often can lead to some type of infinite loop that will eventually max out via an integer overflow, leaving the balance being somewhere lower than the initial balance that the user had funded.

Uninitialized Struct: Solidity provides structs to define new data types by combining various data types into one. Some contract may require the use random number or betting to receive the funds. This source of randomness is often given publicly and can be called seemingly as a mistake. Once a user provides the number, a new struct is created that is not initialized with the correct keyword resulting in the location of the user mapping to the random number. This makes the checking condition fail to receive the funds.

Etherscan Blockchain Explorer

Hidden State Update: Etherscan can display both normal transactions as well as internal messages, which are transactions from other contracts and not users themselves. A user will be prompted to guess some value or compete with other users and once completed will assume that the functions are set to be false as the internal messages does not appear. This function can then be called outside of the current smart contract by another contract using an empty transaction value (empty transaction values do not show internal messages).

Hidden Transfer: The HTML that comes with the provided Etherscan web interface displays the code of a smart contract. The textarea element can be abused via spacing to remove certain hidden amounts of code. The code would still be viewable, but only after an long time scrolling horizontally. This can cause any user that does not pay attention to be unaware of any additional transfers that are presented off the original screen.

Straw Man Contract: The smart contract will provide a message to the user for them to deposit the minimum fund into the contract. Eventually the user will attempt to claim the fund in which the creator of the contract will have not initialized the contract to the correct address, but rather one that implements the same appearance while failing to deliver unless the contract owner is calling the function.

Demonstration of Attack:

This is the Bank contract, one of the two visible contracts within the file. The bank contract works as a simple lure for an attacker to exploit. First there is a logger made that will log all of the events that occur. Next is a function that allows deposits into the bank to be created, htis will be used to push funds into the smart contract as bait. Then the withdraw function, which is crafted to seem exploitable via a reentrancy attack where a single withdraw command will be repeatedly called after only one payment of ether until the entire back is dry of funds. The Logger Contract is what monitors the callers actions, and amounts.

This is the ReEnterAttack contract, which simulate a reentrancy attack on the bank contract in order to take all of the funds out of the bank. The way it works is by taking in the address of the bank and plugging it into the contract when deploying. adding in the initial value of one Ether to interact with the bank contract the attack function can be called. What occurs is that the attack is supposed to repeatedly call the withdraw function until there are no more funds within the back. What happens in reality is that this is a honeypot contract that steals that initial payment and holds it within the bank contract and never allowing the attacker to withdraw their funds.

This is the HoneyPot contract, which is what executes the honeypot attack. This code would be hidden on a separated file but still deployed with the bank contract to where no one could see that there is this extra code anywhere with the bank contract. The honeypot executes whenever there is a withdraw being executed and if it is not the owner account then the money is not transferred.

Solution:

The Solution to honeypot attacks is undesirable in its current state due to many significant reasons. Firstly, honeypot attacks are among the easiest contracts to create including the developing, hiding, and initial funds set up leaving anyone able to create a honeypot attack. Secondly, they are viewed as a form of cyber security within themselves on the blockchain network as it removes many of the attackers attempting to exploit legitimate contracts. Lastly, once there is any form of interaction within a honeypot contract, which will require funds to be spent, there is as of currently no solution to being able to withdraw any funds back from the contract.

So what are ways to avoid honeypot attacks?

Check for an audit: If there is a verified company that has audited the contracts, tokens, or currency then it is much less likely for there the be any type of criminal or fraudulent contracts that will scam a user out of their funds.
Check for a website/ Check the Website: If there is no website available then it is likely to be a very new, or armature project that could show signs of a scam, additionally if there is a website check for its domain to see how long it has been active, or if the development seems to be poor.
Use internet tools that can give some insight into the legitimacy of these contracts and if there are attacks: certain tools such as honeypot token checkers, and token sniffers can be used to determine if a certain contract is fraudulent or show unclear signs. It should be noted that these tools are not 100% accurate and can easily make mistakes, therefore it should not be taken as completely solving the honeypot attacks

Tools to help with determining if a contract is a honeypot attack:

Honeypot checker tool - https://rugdoc.io/honeypot/
Token Sniffer - https://tokensniffer.com/

Theoretical Solution:

Over the course of this research and coding there has been much need for currency to deploy contracts on the blockchain. This currency is for testing purposes only and cannot be used for legitimate smart contracts that will be deployed. One approach that could be using these testing funds to create a separate contract that allowed for these test funds to run independently of actual funds and attempt to go through a transaction in a contract. If the transaction succeeds then there is no honeypot attack and if it fails then the contract is a honeypot attack. In this solution only the test currency would be funded and not have any real crypto value. This could be done through creation of a unique type of token that can be used to convert the actual contract to accepting itself instead of whatever the contract currency is such as ether.

How to Run Attack:

HPAc.mp4

What Deploying Contracts Should Look Like:

This is the order in which to deploy the contracts and see how it looks for information on how to set up and run the code please watch the video above. The first picture is to the left and below this text the order of pictures is from left to right.

First, deploy the HoneyPot contract on the ganache test network with the first account. Do not place any either into the HoneyPot contract when deploying.

Second, deploy the Bank contract by first copying the address of the HoneyPot contract and pasting it into the address box. This can be done by pressing the symbol on the HoneyPot contract that is a file overlapping another file.

Next, after deploying the Bank contract add at least one Ether into the Bank using the deposit function.

After adding the funds into the bank, switch to a second account and deploy the Attack contract on this account passing through the address of the Bank contract.

Lastly, Put tha value selection to 1 Ether and activate the attack method. This will fail as the contract was a honeypot trap that will refuse to have an injection unless the owner verifies it.

Take a Look at The Code:

https://github.com/EricWeese/Cyber-Security-in-Blockchain/tree/main/Honeypot%20Attack

References:

1.Torres, C. F., & Steichen, M. (n.d.). The art of the scam: Demystifying honeypots in Ethereum Smart ... - usenix. usenix. Retrieved October 10, 2022, from https://www.usenix.org/system/files/sec19-torres.pdf

2.Solidity by Example. (2022). Honeypot. Solidity by example. Retrieved from https://solidity-by-example.org/hacks/honeypot/

3. Merre, R. (2022, June 30). Honeypots - how the Community Fights Back Against Hackers. Medium. Retrieved from https://medium.com/ngrave/honeypots-how-the-community-fights-back-against-hackers-729770f5ad47

4.rugdoc. (2021, November 7). So you got honeypotted - rugdoc. https://wiki.rugdoc.io/. Retrieved from https://wiki.rugdoc.io/docs/so-you-got-honeypotted/

5. Singh, J. (2021, December 26). What is a honeypot crypto scam and how to spot it? Cointelegraph. Retrieved from https://cointelegraph.com/news/what-is-a-honeypot-crypto-scam-and-how-to-spot-it

Page updated

Google Sites

Report abuse