The blockchain is not perfect. Though security is integrated throughout all blockchain technology and it continues to improve over time, the strongest blockchains can still be susceptible to attacks by modern cybercriminals. Blockchains can resist traditional cyber attacks quite well, but cybercriminals are coming up with new approaches specifically for hacking blockchain technology.
In this article, we will describe what timejacking is, how does the attack work, and how it can be avoided.
Defining Timejacking
Timejacking exploits a theoretical vulnerability in Bitcoin timestamp handling. During a timejacking attack, a hacker alters the network time counter of the node and forces the node to accept an alternative blockchain. This can be achieved when a malicious user adds multiple fake peers to the network with inaccurate timestamps. However, a timejacking attack can be prevented by restricting acceptance time ranges or using the node’s system time.
How does a Timejacking Attack work?
In a timejacking attack, the hacker manipulates one of the timers of the victim node and creates a “poisoned” block. The victim will reject this block, and the rest of the network will successfully accept, and provoke a fork. The entire network then uses a blockchain built for the “poisoned,” and the victim considers the alternative chain with a token reuse (or double-spending) valid, in which the “poisoned” block does not appear.
The attack is carried out in two stages; Fork & Isolate and Double-spend.
1. Fork & Isolate
The attacker needs to generate a new block, the same “poisoned” block that the victim ignores. In the same way, the victim will reject other blocks that will be added sequentially after the “poisoned” one.
An attacker can manipulate the time value of the victim’s network by connecting to it a sufficient number of neighbors announcing a lagging system time. The time value of the victim’s network decreases; the upper limit of the range of valid values of the timestamp of the verified block decreases. But if the deviation of the neighbor’s time exceeds 70 minutes , then its time will not be taken into account when calculating the network time. Therefore, the maximum value by which the time of the victim’s network can be reduced is 70 minutes.
Accordingly, the “poisoned” block is a block whose timestamp must fall into the time window of all network nodes, except the victim. Only then the whole network will successfully accept it, and the victim, whose network time has been modified, will be no less successful.
This results in the victim being isolated from the main network and considers the main block chain, which will be built by the remaining nodes from the “poisoned” block, incorrect. In this case, the other blocks, helpfully generated by the attacker for an alternative chain, the victim will confidently accept.
2. Double-spending
At this stage, the attacker starts generating an alternative chain, in which he adds a transaction that transfers tokens to the victim’s wallet. Blocks of an alternative chain are sent to the victim. The victim will then accept this chain, since the value of the timestamps is chosen by the intruder from his or her own time window, and the remaining nodes will be rightfully ignored — after all, they are already building their chain from a “poisoned” block that is longer than the alternative one.
As a result, the victim believes that he or she received tokens, and sends the goods. And the main network is sure that the tokens did not leave the intruder’s wallet, and he gets the goods for “thank you” — because the majority cannot be mistaken. After performing all of these tasks, the attacker is deemed successful with his or her illicit act.
How to avoid Timejacking attacks?
There are ways to mitigate or prevent timejacking attacks from happening. Here are some preventive measures to keep in mind.
- Use the node’s system time
It is best to use the node’s system time instead of the network time to determine the upper limit of block timestamps and when creating blocks.Using a hardware time source rather than a network time source would require additional calibration and maintenance. Even with reasonably good timekeeping, a disagreement among nodes for only a tenth of a second (something that will happen as nodes gradually calibrate their clocks) could allow an attacker to split the network or isolate a node. - Strengthen acceptable time ranges
The node’s network time could be restricted to a value within 30 minutes. This changes the maximum initial attack window to between 30 and 60 minutes instead of 70 and 140, but would not prevent splits entirely. Nodes with incorrect daylight savings handling might be left behind though. - More confirmations
It is recommended to require more confirmations before accepting a transaction. But there should be a balance between expediency and the probability of reversal. A significant financial attack could still be successful if other miners have their clocks moved forward or if the target is taken offline, even when the required number of confirmations is increased. - Only trusted peers
Requiring secure nodes to use only trusted peers could make those nodes less secure since a small number of trusted peers may be subverted. A fully decentralized system doesn’t require placing trust in a select group of peers. Requiring operators to maintain their own networks or have geographically distributed servers would also be additional maintenance and syncing issues. Using trusted peers or your own distributed network wouldn’t by itself resolve the global time agreement problem. - Validate blocks through median blockchain time
Use the median block chain time exclusively when validating blocks and transactions. This would ensure no timestamp splits are possible and would be a complete solution. This is already done on the timestamp’s lower bound and could be applied similarly to the upper bound. This method also ensures that no two peers could disagree on whether a block was valid or not since they are no longer using their own variable time clocks but are using the timestamps embedded in the chain itself. - Consider delayed timestamp validation
Nodes can retain blocks with excessive timestamps in memory and re-check them later (possibly by setting an alarm). At most a certain number of blocks would be retained in a queue sorted by timestamp and descending difficulty. Nodes would then rejoin the main chain as soon as their system clocks catch up. This has the advantage that significant block timestamp inflation isn’t possible, but it’s more complex, and timestamp-based splits would still be possible. The delay required to synchronize however would be minimized compared to an approach that only relied on the system time.
Final Thoughts
While this attack only affects the Bitcoin chain, we should not disregard the fact that attackers continue to develop methods to intrude other chains and perform their illicit intentions or acts. A timejacking attack is more rigorous and time consuming to perform, so once someone tries to pull off an attack, security can easily identify it, considering the drastic improvements of blockchain over the years.
