New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

server DOS attack? #107

Closed
joeyh opened this Issue Dec 16, 2016 · 3 comments

Comments

Projects
None yet
2 participants
@joeyh
Copy link
Contributor

joeyh commented Dec 16, 2016

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.

@warner

This comment has been minimized.

Copy link
Owner

warner commented Dec 16, 2016

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:

  • hashcash challenges when the server is under attack
  • per-IP rate-limiting (although I'd want to be careful about protecting the privacy of the IP addresses, so it'd need a rotating hash seed)
  • require users to go through some external service (maybe ReCAPTCHA?) and get a rate-limiting ticket before claiming a channel
  • shipping an attack like you described, flooding the first million channels, as part of the distribution, in a subcommand named wormhole break-this-useful-service-for-everybody-because-i-am-a-horrible-person, in the hopes that pointing out how easy it is might dissuade a few would-be vandals from feeling a sense of accomplishment at writing their own :). Not sure it would help much, but I vaguely remember hearing about something similar in the early multi-user unix systems (a publically-executable /bin/crash or something, which new users tended to only run once before learning some responsibility).

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 hash(words) -> channel-id, then reverses it. To make that safer we'd need to increase the codes to maybe 80 bits (ten words), plus do some significant key-stretching (like 5-10 seconds of scrypt or argon2), which would increase latency and CPU demands, and still be less secure overall.

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.

@joeyh

This comment has been minimized.

Copy link
Contributor

joeyh commented Dec 16, 2016

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.

@warner

This comment has been minimized.

Copy link
Owner

warner commented Dec 16, 2016

Nice, thanks for the link! I'll eventually copy the text above into the docs/ directory, and then I'll close this ticket, leaving the PoW approach for a different one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment