MIT Researchers Defend Against Wireless Attacks 65
alphadogg writes "MIT researchers have devised a protocol to flummox man-in-the-middle attacks against wireless networks. The all-software solution lets wireless radios automatically pair without the use of passwords and without relying on out-of-band techniques such as infrared or video channels. Dubbed Tamper-evident pairing, or TEP, the technique is based on understanding how man-in-the-middle attacks tamper with wireless messages, and then detects and in some cases blocks the tampering. The researchers suggest that TEP could have detected the reported but still unconfirmed cellular man-in-the-middle attack that unfolded at the Defcon conference earlier this month in Las Vegas."
Nope (Score:3, Insightful)
Anything a legit user can do a MITM can do better.
This "all-software" solution is either bullshit, or relies on pre-shared keys (be they specific keys or hardware-derived).
Without keys / hardware, there is absolutely nothing a legit user can send out that a MITM can't.
Tamper Evident (Score:1)
Maybe on a wired connection you'd be right. I'm inclined to think that wireless, doing something to detect tampering could be possible. You probably wouldn't be able to guarantee that you can create a connection at all, but it might be an improvement for some to be able to connect only if tampering can be ruled out with some probability.
Re:Tamper Evident (Score:4, Informative)
If you RTFA you'd know their scheme works like this: .... BEEP BOOP BOOP BEEP .... BEEP BEEP!".
Client says "Hey, let's connect and be secure.".
Router says "Hey, let's connect and be secure using this key.".
Router yells "BEEP
Client says "That pointless noise lined up exactly with the 1s in the message about the key. And the little pauses of silence lined up with the 0s. I should trust it.".
This does nothing.
A MITM will be able to construct his own lie message about using his key instead, as well as be able to construct his own noise pattern.
All a client can see is "Hey, there are TWO packets telling me which keys to use!".
Exactly the same as current implementations that don't rely on pre-shared keys or out-of-band authentication.
you miss the point (Score:5, Insightful)
The client sees the "lie", and doesn't trust either of the offers because it isn't sure which is real.
Based on this, it's possible to DOS a router by sending out connection offers, but you can't do a MITM attack.
Re: (Score:2)
Re: (Score:1)
Interesting. And it doesn't matter that it doesn't protect against DOS because all wireless communication is subject to DOS anyway.
But is it subject to Windows as well? :-)
CTS (Score:2)
all wireless communication is subject to DOS anyway.
But is it subject to Windows as well? :-)
Yes, in fact. The second page of the article describes CTS (Clear To Send), a way of reserving windows of time for communication.
Re: (Score:1)
The client sees the "lie", and doesn't trust either of the offers because it isn't sure which is real.
Based on this, it's possible to DOS a router by sending out connection offers, but you can't do a MITM attack.
You can do a MITM attack just as you could with any other wireless system.
Sit at the edge of the AP and pose as it, targeting people outside of the AP's range.
If you used a preshared key, the attacker would have to know the key to do a MITM attack - be it a password or other authentication system.
This idea is all about tossing out preshared keys. That's fundamentally not viable in terms of authentication.
Re:Tamper Evident (Score:4, Funny)
Yes, well, everyone knows TEP is insecure and hackable. Im waiting until TPA2 comes out, thats where the real security is.
Re: (Score:2)
Well, don't you have the solution there?
Client sees two packets telling which keys to use = "error, someone's attempting to MITM me!, and either retry or give up.
Re: (Score:1)
Bending over and a taking a DoS up the ass is no solution.
Using a preshared key (either a password or whatever other shit) works far better.
Re: (Score:1)
The point is that you can't make a second overlapping noise pattern without changing the first. You can't yell anything that turns an existing yell into silence.
You're bitwise-anding all the yelling together, and only if that validates the key you got, do you trust it.
So MITM can't yell while the router's yelling unless its hash starts the way the router's ends (and it knows this in time and starts yelling at the right time) or the client will see a bad hash, tear down and try again.
And if the MITM yells _a
Re: (Score:1)
And on page one of thinking for 5 seconds, you'd know that such a MITM is a perfect DoS attack.
Beyond that, a MITM can sit at the edge of an AP's range, pose as the AP, and target people within his own range, but outside of the AP's range.
Re: (Score:1)
So you're saying that their "detect tampering" protocol fails to protect against a "just dumping noise into the air" DoS?
I do grant you that if you can't hear the AP, you could be fooled into connecting to the MITM posing as the AP. But that's kind-of outside the scope of the protocol. This protocol is ensuring that the key you get from the AP comes from the AP you requested it from. If you can't hear the original AP, then you haven't really requested a key from it, but from the repeater.
That's more of an i
Re:Tamper Evident (Score:4, Interesting)
A proper and real diversity system can detect the angle of the radio to the receiver. A properly designed setup with 4 antennas can give a 0-360 degree direction of the radio it is contacting and a crude distance. this added information and watching radio traffic in the spectrum. I.E see a packet transmitted from radio 3 to radio 4 and then the same packet is transmitted to the base, flag it as mitm and contact radio 3 directly.
It would make a $299 AP cost about $3400 but it could be effective.
Re: (Score:1)
...and after reading... yup.
All they've done is create a shouting match that is still vulnerable to race conditions, which, in the wireless world, is all MITM is about once you're authenticated with the other host or the AP.
Prior to authentication, any MITM can cause a denial of service by just blarting out their own bullshit in the same fashion, so the victim won't know which one to trust.
The only protection comes from tight timing windows, and who's louder. And in the wireless world, you can be a MITM wi
Re:Nope (Score:4, Informative)
The only protection comes from tight timing windows, and who's louder.
... and that's where TEP kicks in: it depends on the ability to use periods of silence to communicate. The MITM cannot drown out the router's "energy" packets by silence.
Re: (Score:1)
Destructive interference?
Re: (Score:2)
Not possible. Even for sound they can only get destructive interference to reduce apparent volume, not create silence. And that's with waves travelling a fraction of the speed of light (i.e. the waves travel pretty slowly compared to the time it takes to process the sound, calculate the inverse and send impulses to the speaker). You could interfere with a radio signal enough to make it unintelligible. Impossible to make it disappear altogether.
Re: (Score:1)
You will never have absolute silence on any frequency. Any device which relied on absolute silence would inevitably fail. Therefore the question is not whether you can completely remove the signal, but only whether you can reduce it enough that it will be considered noise by the receiving device.
It's obvious that a digital circuit won't be fast enough to significantly reduce the signal stren
Re: (Score:1)
Victim --- MITM --- AP
The MITM just sits at the edge of the AP's range and poses as the AP. Any victims in range of the MITM and NOT in the range of the AP will get fucked because they won't hear the AP screaming it's noise pattern, and they will trust the fact that they hear only ONE noise pattern as an indication that the scheme is working.
Furthermore, a MITM can:
- Use a triangulation scheme to only attack when the user is estimated to be outside of the AP's range (thus going unnoticed).
Re: (Score:2)
- Scream (DoS) all over the frequencies the real AP is talking, so that the victim will choose another channel.
Re: (Score:2)
Anything a legit user can do a MITM can do better.
This "all-software" solution is either bullshit, or relies on pre-shared keys (be they specific keys or hardware-derived). Without keys / hardware, there is absolutely nothing a legit user can send out that a MITM can't.
Connecting to multiple networks in the same time, launching the same request and comparing the content of the received answers?
In the context of WiFI, unless you are surrounded by the MITM (in which case the appropriate term should be "Man All Over You"), you are bound to detect some tampering.
Re: (Score:1)
(in which case the appropriate term should be "Man All Over You")
Also known as a DSK attack...
Re: (Score:1)
The MITM doesn't have to surround you, he just has to prevent you from hearing the legit AP, the easiest way is to sit at the edge of the AP's range and then pose as the AP. People in the MITM's range, but outside the AP's range, will never hear the AP or it's tamper-evident screaming.
People in range of both will see both and will be DoSd hard.
Re: (Score:2)
Right, but you can make it so that the client can see two messages that it should only see once and teach it not to trust them in that case. As mentioned in the summary, it says it can detect MItM and possibly prevent it. In most cases it would simply detect and not use. Personally, I'd be curious to see what asymetric cryptography could do to protect against MItM.
Re: (Score:1)
All MITM attacks then become DoS attacks.
The user will just disable the extra security to get it to work.
Alternatively, users will feel more secure when they hear only one (pair) of messages. But if it's a situation where a MITM is in range of the AP, and the victim is not, the victim is feeling more secure only because they don't hear the AP shouting, and they walk right into the MITM's trap.
Preshared keys are the only way.
Re: (Score:2)
Saying that a user disabling security makes it ineffective isn't really a fair critique of a technology as the same is true of any security.
As for the range issue, it is possible to overcome this outside of an extremely powerful attacker AP by encoding the response in such a way that it will be able to ecc at a substantially longer range than most wifi data transmissions. I'm not saying that this technique necessarily does it, but it could be done to greatly increase the additional range that a MiTM would
Re: (Score:2)
Assymetric cryptography not only can prevent a MITM, it is the normally preferred and accepted way.
wrong assumptions (Score:1)
They write "TEP begins by analyzing how an attacker mounts a man-in-the-middle exploit: In every case, the researchers say, the attack involves tampering with wireless messages.". But this is wrong - the man in the middle may simply be listening.
Re: (Score:1)
Sure. Everyone knows that country music is the best weapon against attackers.
Re: (Score:1)
Re: (Score:3)
It's OK if the man-in-the-middle is only listening, because the Diffie-Hellman key exchange algorithm is designed so that the two legitimate parties can exchange encryption keys without a listener being able to determine the key, even if the listener records the whole transmission.
Re: (Score:2)
But this is wrong - the man in the middle may simply be listening.
Yeah right, and the purpose of an SSL certificate is to prove that you are a honorable person or business.
Re: (Score:1)
If he's only listening, he's not a man in the middle but an eavesdropper. And the existing protocols already protect against eavesdropping.
Very poor summary (Score:5, Insightful)
"Lucifer" should be "Mallory" in that article. (Score:2)
From the article you linked to:
They need to stick to established naming conventions to make their work easier to understand.
The malicious cracker is named "Mallory". Not "Lucifer".
Re: (Score:2)
What has happened to Eve? I havent heard anything from her in for a long time.
Re: (Score:2)
I don't think that this can be invulnerable and I think it opens up some DoS opportunities, but it looks pretty robust to me. I'll be interested in what Bruce Schneir has to say.
Re: (Score:2)
Re: (Score:2)
Huh, by encoding some information in silences, you can tell if anyone is trying to drown out your signal. So if you hear a TEA transmission and respond to it, you can establish a secure link back to the sender. That seems reasonably achievable and could provide better link layer security than WEP or WPA for unicast traffic. Though it does require custom code to be implemented in each wifi driver, or in some cases perhaps in firmware.
But this approach doesn't directly give you a way to authenticate the pers
Re: (Score:2)
An attacker can tamper with a wireless message in three ways: by altering a message sent by one party to match his own Diffie-Hellman key; by hiding the fact that Party A has sent a message at all; and by blocking a message from being sent. TEP is designed to defang each of these tampering techniques.
It does this by compelling Party A to follow its message transmission with another: a pattern of energy "pulses" and "silences." Party A's wireless radio computes a hash of the original message, creating a sequence of ones and zeros. For each one, the radio sends a random packet; for each zero, it sends nothing -- it's silent. This combined pattern is unique to the original message.
If the attacker alters the contents of Party A's message, he, too, has to follow up with a new "silence pattern" that corresponds to the altered contents. But the two silence patterns will be different: The attacker "cannot generate silence" from Party A's "one bits." Party B can detect that difference and in effect refuse the connection offered by the attacker.
Aha, using the fact that all this comm is occurring in the same collision domain to your advantage against MITM attacks, I wonder if this would actually stand up to scrutiny?
The client can't refuse the connection by the attacker.
The client can only refuse ALL connections when it suspect foul pay (by hearing two shits).
Just as before, it's a race/range condition. Sit at the edge of an AP's range with two radios and people connecting to yours will never even hear the router shouting shit at them as sit in the middle.
AP ---- You ---- Victim
Victim and AP can't hear eachother, and thus have no indication that what you're saying isn't coming from you.
Re: (Score:2)
But in that case, you are simply connecting to a compromised router. The fact that that router then connects to *another* router can be ignored.
That problem should be dealt with differently.
Re: (Score:1)
But in that case, you are simply connecting to a compromised router. The fact that that router then connects to *another* router can be ignored.
That problem should be dealt with differently.
But shouldn't any solution to that problem also solve the other problem?
Paper looks interesting. (Score:2)
Reading the paper, it seems the proposed protocol for key exchange forces a wait time of 17ms, and then hashes the packet to ensure it doesn't get modified (forcing the use of slots and keeping the air open during attack).
The only problem I see is that you could easily use this mechanism to effectively DoS the network by making it wait for the CTS packets constantly while the protocol rejects the bad check-summed packets.
But I guess that's a minor flaw since it's already trivial to DoS wireless networks in
This is specific to pairing (Score:2)
The paper is about wireless pairing, which is a special case.
MITM attacks in general are not entirely invisible. Because the MITM is decrypting and reencrypting the message with a different key, the crypt bits received are different than those which were sent. If you ask "what were the crypto bits you received from bit N to M?", the MITM has to be prepared to intercept that query and formulate a lie. This can be made difficult for the MITM. The early STU-3 encrypted phone sets had a little 2-digit display
Re: (Score:2)
Faking that would require splicing words into a verbal conversation in real time.
Even more, in what language?
Re: (Score:1)
Is it really important that this data is unpredictable, or is "random" here used in the meaning of "arbitrary", i.e. it doesn't matter what that data is?
RTFA: Silence is golden (Score:1)
I read the article, and part of the idea is that noise (radio activity) may contain falsehoods, but that silence (radio silence) is genuine and cannot be spoofed. So you first send out a hash, and then try to establish a series of radio silence periods which, when decoded, match your hash. If anything messes with this authentication, it is obvious, and the connection is refused.