Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
server DOS attack? #107
I notice that the channel number seems to be between 1 and 99, at least under current server load. So, what if I run this loop:
while true; do wormhole receive 1-bwaa-hahaha; done
That will give a false guess for all connections attempts on channel 1, so as long as that keeps talking to the server, 1% of all wormhole connections will fail. And it's easily scalable by an attacker.
I have not tried running that script. Does the server have protections against this kind of DOS attack? It could start blacklisting IPs if they make repeated password guesses close together. For all I know you've thought this all out and have protections in place (although a quick pass through the server code didn't find them). If so, it would be good to document the DOS attack scenarios and preventions somewhere.
One idea, I don't know if it's any good, is to derive a longer channel number from the code words (eg, use their sha2 as the channel number), so the user does not need to enter the long channel number, but only the code words. Then a channel collision, either accidential or intentionally as above could be made much less likely.
Yup, this service is quite vulnerable to this attack.. so far we've depended upon the goodwill of the vandals :). I've thought about a few (weak) mitigations, but haven't implemented anything yet:
Using the secret words as part of the "channel id" isn't safe, alas, since it would allow a network attacker, or the rendezvous server, to deduce what the secret words are: since they only have 16 bits of entropy, the attacker just makes a table of
The core problem is that, because things are so easy for the legitimate participants, they're really easy for the attacker too. Short wormhole codes are the easiest to use, but they make it for a trivially predictable target.
I don't have a good answer for this one. I'm hoping that it isn't sufficiently interesting to attack that it'll be an issue, but I can't think of any simple answers. If the API is sufficiently compelling for other applications to incorporate Wormhole "technology" into their apps, I'm expecting that they'll run their own rendezvous server, and of course those apps can incorporate whatever sort of DoS protection seems appropriate. For the built-in/upstream send-text/file/directory tools, using the public relay that I run, it may just have to be a best-effort service, and if someone decides to kill it, it fails.
Good, now it's documented. :)
Of all those options, I like the hashcash one. You can combine proofs of work with token buckets, so that at a low level of activity little or no PoW is needed and when under attack it ramps up to needing progressively larger PoW. https://joeyh.name/blog/entry/PoW_bucket_bloom/ describes such a system in some detail.