I’m trying something new: if you’re in The Netherlands on June 28th, you can alpha test my new course! It’s about how to contribute to Bitcoin Core, with a focus on the process around making and reviewing pull requests.
You can sign up here. I’m looking for up to ten participants, but as long as at least two people sign up it will happen (i.e. I break even on the venue).
Today continues chapter 7 from the book Bitcoin: A Work in Progress.
You might think this would do the trick, but here’s where the paper comes into play. The authors ran a simulation to see how difficult it was to actually overflow all these buckets, and it found that, within a matter of days, it can be successful.
How did they do this? By using a botnet — not a real one of course, as that would probably be unethical for university researchers, not to mention potentially illegal. But they simulated one. A botnet is a group of random computers in the world that have been hacked and can be remote controlled. Because they’re not all in the same data center as our example above, their IP addresses have many different starting digits, so they end up in different buckets.
The paper estimated that a botnet with less than 5,000 computers can successfully pull off an eclipse attack. That might sound like a big botnet, but you can rent that from various nefarious “companies” for less than $100.
In addition to attacking your node from many different directions, thereby defeating the bucket system, the hypothetical attacker in the paper also exploited other weaknesses.
First, they would flood your node with IP addresses that are known to be fake. This would flush all buckets with fake nodes. Remember that when your node needs a new peer, it’ll toss a coin to either connect to familiar node or try a new one. Well, there wouldn’t be any new ones to try. We’ll revisit the problem of fake nodes in the next chapter.
For the other side of the coin flip — connecting to a familiar node — the attackers exploited another weakness. It turns out your node considers any node it ever connected to “familiar.” That includes botnet nodes that connected to it, even if only briefly. Fixed in 2016. There’s a separate 64-bucket system for these familiar nodes, and over time, they get filled up by botnet IPs.
At this point, your node still has long-lived connections to the real world from before the attack began, so the attacker still needs to get rid of those. The trick is to either wait for your node to restart, or to try and crash it.
Whenever your node restarts, it starts out with zero connections. Firstly, this creates an opportunity to very quickly fill up all 117 inbound slots. And secondly, it’s going to look at that file of peers it knows, and it’s going to try and connect to them. If an attacker succeeded at dominating these buckets, your node is exclusively going to connect to attacker IP addresses. That’s all that’s needed for the eclipse attack to be in play.
So although crashing a Bitcoin node isn’t a very useful attack on its own, it can help when performing an eclipse attack. This is one reason why it’s important for developers to ensure they don’t write code that can make a node crash.