From 7f2edeeb117211419cd2e6b12aa02b050b9294f4 Mon Sep 17 00:00:00 2001 From: Brian Warner Date: Sun, 1 Jan 2017 14:29:48 -0500 Subject: [PATCH] document some attacks closes #107 --- docs/attacks.md | 89 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 docs/attacks.md diff --git a/docs/attacks.md b/docs/attacks.md new file mode 100644 index 0000000..702fd45 --- /dev/null +++ b/docs/attacks.md @@ -0,0 +1,89 @@ +# Known Vulnerabilities + +## Low-probability Man-In-The-Middle Attacks + +By default, wormhole codes contain 16 bits of entropy. If an attacker +can intercept your network connection (either by owning your network, or +owning the rendezvous server), they can attempt an attack. They will +have a one-in-65536 chance of successfully guessing your code, allowing +them to pose as your intended partner. If they succeed, they can turn +around and immediately start a new wormhole (using the same code), +allowing your partner to connect to them instead of you. By passing, +observing, and possibly modifying messages between these two +connections, they could perform an MitM (Man In The Middle) attack. + +If the server refused to re-use the same channel id (aka "nameplate") +right away (issue #31), a network attacker would be unable to set up the +second connection, cutting this attack in half. An attacker who controls +the server would not be affected. + +Basic probability tells us that peers will see a large number of +WrongPasswordErrors before the attacker has a useful chance of +successfully guessing any wormhole code. You should expect to see about +32000 failures before they have a 50% chance of being successful. If you +see many failures, and think someone is trying to guess your codes, you +can use e.g. `wormhole send --code-length=4` to make a longer code +(reducing their chances significantly). + +Of course, an attacker who learns your secret wormhole code directly +(because you delivered it over an insecure channel) can perform this +attack with 100% reliability. + + +## DoS Attack on the Rendezvous Server + +Wormhole codes can be so short because they implicitly contain a common +rendezvous server URL (any two applications that use magic-wormhole +should be configured to use the same server). As a result, successful +operation depends upon both clients being able to contact that server, +making it a SPOF (single point of failure). + +In particular, grumpy people could disrupt service for everyone by +writing a program that just keeps connecting to the rendezvous server, +pretending to be real clients, and claiming messages meant for +legitimate users. + +I do not have any good mitigations for this attack, and functionality +may depend upon the continued goodwill of potential vandals. The weak +ones that I've considered (but haven't implemented yet) include: + +* 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 tool (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, 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 channel-id 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. + +See #107 for more discussion.