The Ethereum Alarm Clock tool was hacked, and we will examine this today. But let’s first recall the general purpose of this tool in order to get to the heart of the matter. Why was it used? By whom? What actually happened? From beginning to end, we will give you a thorough analysis in this article.
In the beginning, we would like to express our heartfelt gratitude to our in-team auditors who have assisted us by providing much-needed information and breaking the veil of secrecy! We are also grateful to the MetaSleuth, BlockSec, and Intell_On_Chain teams for their assistance with the analysis of stolen money paths. Give them a like!
In this article, we will only cover aspects that are relevant to auditing and bug bounty hacking but are not covered elsewhere! We tend to believe that there is no one who doubts that the basis of any secure implementation is a special approach to writing code. Consequently, this article will be focused only on those aspects that can be really useful for making your code safe and secure!
Make sure to read the rest of the series:
Therefore, below you will see not a typical article but a systematization of knowledge (SoK), in which I will rely on authors that I myself trust in this matter and, of course, our pessimistic.io auditors. You will also find a list of tools and research for self-study, and we strongly recommend that you read it separately for better understanding!
Please follow us right now, check out our recent article about Slither, and let’s get started! By the way, there are some vacant slots now so if your project needs an audit — feel free to write to us, visit our public reports page here!
OpSec: Timing Attack
Before we get into the exploit itself, let’s see who used the Ethereum Alarm Clock tool and, more importantly, why. To see how this works, let’s look at crypto-origin OpSec tactics!
Well, it’s no secret that representative sampling attacks (Timing Attacks or Statistics Attacks) are the most popular and efficient way to deanonymize users. But how does it actually work? Before reading my response to this question, please carefully read this article:
It’s so easy: just imagine that you go to a physical location to exchange (selling or buying) your cryptocurrency and performing business using your primary blockchain address. I won’t even go into the potential consequences — research this and this resource and always keep OpSec in your mind!
If some bad people, let’s say, find out that you will be in a specific location and that a transaction has been made, these two facts can be easily matched with one another and used to link your blockchain address to you…
For example, with using the following tool:
The Ethereum Alarm Clock tool was developed specifically to address this issue. It can also be used in a combination with multisig like Safe or an escrow contract! You can imagine that many wealthy people used this tool because it allowed users to ensure their own security through postponed transactions…
As stated above in my OpSec guide:
Randomization, mimicry and entropy must accompany your every step and manifest itself in literally everything: as you can imagine, the law enforcers of different countries have long ago learned to analyze packets via DPI (to counter this you may use something like this or this or VPN), to match them with the post or message time and perform timing attacks and then go to the ISP provider or telecommunications company.
Be smarter. Most likely in the future we will all have to face AI and Neural Network which were made specifically for finding people and information based on OSINT and similar (up to Big Data) methodologies, so the only thing that will save us is what separates humans from machines — our imagination and our capacity for illogical unpredictable actions.
Whatever you do, do it with some element of randomness. If you find it hard to comprehend, then put it in the hands of playing cards or random.org. Do you transfer an amount? Send not an even (1000, 100, 50, etc.) or similar value, and so on. I think you get my point. Once again, be smarter, for example: there is a tool like Ethereum alarm clock (2), but you have to remember to use it with caution.
Perhaps a hacker decided to examine (audit) this tool internally before using it themselves…
We don’t know this for sure. In any case, let’s investigate the causes of this exact hack case and determine how it might have been avoided. The Pessimistic.io auditing team will assist us in doing this!
Ethereum-alarm-clock Attack Flow
In short, Ethereum Alarm Clock is a service that allows you to schedule transactions to be executed at a later time in the Ethereum blockchain.
This is achieved by specifying all the details of the transaction you want to send, as well as providing an upfront payment for gas costs, allowing your transaction to be executed for you later.
The service operates as smart contracts on the Ethereum blockchain, with no privileged access to either party.
The following is a description of events, which took place on Oct. 19th, according to CoinTeleraph Media & journalist Brian Quarmby; here is a direct quote:
According to an Oct. 19 Twitter post from blockchain security and data analytics firm PeckShield, hackers managed to exploit a loophole in the scheduled transaction process, which allows them to make a profit on returned gas fees from canceled transactions.
In simple terms, the attackers essentially called cancel functions on their Ethereum Alarm Clock contracts with inflated transaction fees. As the protocol dishes out a gas fee refund for canceled transactions, a bug in the smart contract has been refunding the hackers a greater value of gas fees than they initially paid, allowing them to pocket the difference.
“We’ve confirmed an active exploit that makes use of huge gas price to game the TransactionRequestCore contract for reward at the cost of the original owner. In fact, the exploit pays 51% of the profit to the miner, hence this huge MEV-Boost reward,” the firm wrote.
For more information, see the following article:
Web3 security firm Supremacy Inc also provided an update a few hours later, pointing to Ethersan transaction history that showed the hacker(s) were so far able to swipe 204 ETH, worth roughly $259,800 at the time of writing.
“Interesting attack event, TransactionRequestCore contract is four years old, it belongs to ethereum-alarm-clock project, this project is seven years old, hackers actually found such old code to attack,” the firm noted.
How are transactions executed?
When a transaction is scheduled, a new smart contract is created that contains all the information needed to execute the transaction.
When called at the specified execution time, this contract will send the transaction as specified and then pay the invoice that initiated the execution.
Links & Resources:
-
etherscan.io/tx/0x4a84d0872887f91546cd5400cf99763b654975efb3376ee55e4463bcfbca4e97
-
etherscan.io/address/0x09e0c54ed4cffca45d691d5eb7b976d650f5904c#code
-
etherscan.io/tx/0xa1bca7d2effa1fba1e993da50cad13ea54b79b2a338c84cee15b9abf97958eb6
These contracts are called TransactionRequest contracts and are written to provide reliable performance guarantees for both parties.
In general, the attack flow is as follows:
-
An alarm is created;
-
Next, attacker calls the cancel method, but with a huge gas cost;
-
When cancel is executed, the amount of ether to return is incorrectly calculated;
-
Making a profit — by the attacker.
In simple terms, the attackers essentially called cancel functions on their Ethereum Alarm Clock contracts with inflated transaction fees. As the protocol dishes out a gas fee refund for canceled transactions, a bug in the smart contract has been refunding the hackers a greater value of gas fees than they initially paid, allowing them to pocket the difference.
A detailed vulnerability analysis of the smart contract is presented below:
-
On line 501 is the sending of ether from the contract balance to the user’s address;
-
The value of the rewardOwed variable is directly proportional to the value of the variable tx.gasprice that is set by the user;
-
On line 489 we can see that the value of the measuredGasConsumption variable will be is always greater than 0.
We want to note that to avoid such a vulnerability, when working with the variable tx.gasprice, keep in mind that its value is set by the user at the time of the transaction!
Stolen Funds Flow
The following is an analysis of stolen money paths that we conducted with the assistance of the MetaSleuth, BlockSec, and Intell_On_Chain teams, to whom we are extremely grateful. Give them a follow!
In total, 204 ETH were stolen. With it, 206 ETH flows to FTX, but the exploiter funded his wallet with funds from Binance and OKX. The 2 ETH difference is because of the funds received from these two CEXs, here is a detailed report:
Analysis through impersonator.xyz, smart contract approvals (revoke.cash) and RPC provider is not possible, the use of OSINT methodology is also not possible due to the lack of representative data, so on this our conclusions are final.
Separately, we advise you to study the following dune.xyz table that bhagi.eth made especially for this article:
Because the attacker did not use a mixer, tools like tutela.xyz will not be of help; however, data can be obtained through CEX by filing a formal request with the appropriate law enforcement authorities!
Resources & Tools
Ethereum-alarm-clock Hack:
-
etherscan.io/tx/0x4a84d0872887f91546cd5400cf99763b654975efb3376ee55e4463bcfbca4e97
-
etherscan.io/address/0x09e0c54ed4cffca45d691d5eb7b976d650f5904c#code
-
etherscan.io/tx/0xa1bca7d2effa1fba1e993da50cad13ea54b79b2a338c84cee15b9abf97958eb6
MEV / Sandwich / Front-run & Back-run:
Front-running — Making trades based on insider information that the rest of the market doesn’t have access to or before it can respond. In crypto, front-running is part of MEV.
Bonus Tip for our Readers:
We recently discovered an excellent tool and would like you to use it in combination with our Slitherin detectors for bug bounty hunting and audits!
Clone any project, then upload extension into vscode (2nd link) -> add key from sourcegraph, select the contract and the AI analyzes the structure of your project for you! Check out this example!
Also check out:
We hope that this article was informative and useful for you! Thank you for reading! What instruments should we review? What would you be interested in reading about?
In recent months we have been actively developing our own Slither detectors to help with code review and audit process. More recently, we have released our own detectors and we encourage you to use them for your initial internal audit, particularly the read-only Reentrancy detector, please join the process:
We also promise you that we’ll be posting a lot of interesting stuff soon!
By the way, there are some vacant slots now so if your project needs an audit — feel free to write to us, visit our public reports page here!
- Let’s get in touch: gm@pessimistic.io!