5

If I am not mistaken the mainline bitcoind will accept unsolicited addr messages, and upon receiving this message - the struct is deserialized, and then verify each address from the unsolicited sender. The addr struct allows for up to 1,000 arbitrary addresses:port tuples and there isn't a port restriction... so what exactly is preventing an attacker from flooding the 100k or so Bitciond nodes with the address to some target web servers on 80 and 443?

...To make things more abusable, the client knowingly accepts information drafted in the future, and will retry three times regardless of the error - even on a protocol mismatch. This means that flooding a control-plane service like sshd or a vpn or even an entire IP range of services could cause a lot of problems for a target entity with a large network footprint.

A similar issue to this was exploited on the DC++ network.

Siggi
  • 7
  • 2
Rook
  • 333
  • 2
  • 8

2 Answers2

7

For a long time, there was a restriction to strongly prefer connecting to addresses with port 8333. This restriction was recently removed in PR 23542 and PR 23306, although a list of "bad ports" was introduced that bitcoin core nodes would still avoid to connect to.

If you send an address to a node, it will often save it in the new table of the AddrMan database (if there is no collision with an existing one), but it won't automatically connect to it. That might happen at some later point when they have less than the default 10 outbound connections and therefore need more, or when they make a periodic feeler connection. But since addresses are gossiped over the bitcoin network all the time, they will know about thousands of potential peers, so they would connect to a specific address of the victim only with a low probability.

So even if you send a victim's address to all bitcoin nodes, that doesn't mean that they would receive so many connections that it would qualify as a DoS attack. There has been a rough calculation in this post by vasild, which comes to the conclusion that even in the unrealistic scenario where nodes made new connections all the time, the number of connection attempts the victim would receive would be ~2 per second. In reality, it should be much less because nodes don't make connections all the time - the victim might get the occasional connection attempt from a bitcoin node, but nothing that would qualify as a DDoS attack.

Also note that your verification link from the OP is part of the AddrMan::Unserialize() function, only used to load saved addresses from the peers.dat file at startup, the function in AddrMan that is executed when receiving addresses from peers is AddrMan::Add().

Lightlike
  • 581
  • 1
  • 12
  • ah thanks for the details, I am new to the codebase. Wait... So does the client forward unvalidated addrs? Also, seeing as i don't see a test case for this I don't see how anyone could know it is "10 connections." Every nasty bug in prod has an excuse. – Rook Jul 27 '22 at 22:34
  • Yes, it does forward them (otherwise it would be very hard for nodes new the network to find incoming peers), although with some anti-spam restrictions. There actually was an addr spam attack last year, see this paper by Grundmann et al.: https://arxiv.org/abs/2108.00815v2 The fact that a bitcoin node makes 10 outgoing connections per default (8 full outbound + 2 block-relay-only) is documented in many places, see e.g. https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md – Lightlike Jul 27 '22 at 23:37
  • Oh cool, my concern was that it was never tested because the design team thought it wasn't exploitable. Forwarding dead nodes and connecting to 80/443 and not rejecting cross-protocol is a bug, this can and should be fixed. If it is known to be an HTTPD - then don't forward it. – Rook Jul 29 '22 at 17:14
1

This specific DDoS vulnerability was exploited in 2021, which lead to an emergency patch. PR #22387 is how Bitcoin prevents DDoS, clients running a version older than v22 may still be used to amplify attacks.

Rook
  • 333
  • 2
  • 8
  • The causal relationship was more complicated than that: It wasn't an emergency fix against an ongoing attack. The spam only started several days after #22387 was opened, so the patch might have provoked the attack, or maybe it was just coincidence. Also note that AddrMan is designed to be able to cope with spam, even without rate limiting, so it didn't really cause much chaos - most node operators didn't notice the spam at all. – Lightlike Jul 30 '22 at 18:02
  • @Lightlike The operator was never the victim, and of course, the operator should not be concerned with such attacks. Suggesting that the node is the victim means that you are missing the point entirely. – Rook Aug 01 '22 at 12:08
  • @Lightlike also, really?? Bitcoin knowingly propagates known HTTPD's that make their way into an ADDR message? This is underpants on head level crazy. – Rook Aug 01 '22 at 12:10
  • I was refererring to the spam from 2021 where unknown people spammed the network with randomly distributed IP addresses, presumably with the goal of atttacking the bitcoin network. I was not talking about the scenario you describe in your OP. And of course node operators need to be concerned with such attacks, either because it might affect their ability to find peers, or because they run out of memory, which happened to an alternative implementation. (https://bitcointalk.org/index.php?topic=5348856.msg57469495). – Lightlike Aug 01 '22 at 19:20