This summer, Least Authority was hired to audit the Ethereum 2.0 node discovery protocol. We enjoyed diving into the protocol, and found some issues that were really interesting to model and test. Read the full report here.
Proof of Identity
The audit went smoothly and we were able to quickly grok the protocol the Ethereum team was proposing, though the documentation was admittedly sparse in some areas. The highest priority issue we discovered was that the node discovery protocol presented to us had no sufficient mitigation against node identity threats such as Sybil and Eclipse attacks. We consider it system-critical to the future success of the protocol because without it, the network is vulnerable to several different large attack areas that involve identity.
The specification laid out a system of IP-based node limiting, but this approach has a few issues. For one, IP addresses are not sufficiently scarce enough to enforce the kind of challenge necessary to inhibit an identity attack. The nodes in the network need a provable and unique identity. Without this proof of identity, it’s possible for a malicious actor to fill up another node’s table pretending to be a node they’re not, eventually making them the only “source of truth” without the targeted node ever knowing it.
We modelled a test to determine the difficulty of this variety of attack against their IP limiting based solution presented in the spec, and the results were quite clear. Within the first half hour of our test, we were able to take over 19 buckets of a target node’s routing table. We ran our test for 7 hours total, and we were able to take over another 5 buckets, coming to a grand total of 384 fake node addresses in the target node’s routing table. With this kind of attack, we could feed the node fake information, deny them service, or any number of other malicious network actions.
More concerning yet, we were able to carry out this attack on a free Amazon t2.micro instance. If we threw even a little bit of money at this type of attack, it could be quickly scaled.
As you can see, the ease of bucket takeover is substantially reduced once a proof of identity scheme is turned on. The beauty of a solution like this is that it simultaneously and efficiently inhibits several different flavors of identity attacks.
The Ethereum team acknowledged this is an active area of discussion, and that they have yet to make some difficult decisions needed in this area. We encouraged the use of a memory-hardened proof of work algorithm such as Equihash to include a cost to joining the network.
Lookup Algorithm
The repo was sparse on code for us to audit the specifics of the lookup algorithm, but in combination with the identity issue, we decided it was necessary to explicitly recommend extra precautions with identity in the network.
In addition to the identity schemes, we concluded that the team should implement a multiple disjoint path lookup. This allows the requesting node to validate from several other nodes that they all independently reached the same conclusion in a lookup, making it much harder for a node to fake their identity in the network.
The Ethereum team agreed that this was a simple yet effective mitigation and have added it to the spec.
Node Handshakes
We did discover an issue in the handshake used to validate node to node communication, but it was a quick fix and they’ve updated their handshake spec to match the mitigation we recommended. Overall, it was a tiny issue but with handshakes, there’s a lot of moving parts and they’re crucial to the rest of the platform’s security.
Thanks!
We thoroughly enjoyed this audit and we look forward to working with the Ethereum Foundation in the future. The team was great to collaborate with and we had fun modelling the tests to performed.
Learn more about our security consulting work >> https://leastauthority.com/security-consulting/
Want to work together? Book a chat with us.