Slashdot Mirror
Flaw Found in VPN Crypto Security
peeon writes "CNET reports the British National Infrastructure Security Coordination Centre has discovered a flaw in IPSEC protocol. From the article: 'The flaw, which the NISCC rates as "high" risk, makes it possible for an attacker to intercept IP packets traveling between two IPsec devices. They could then modify the encapsulation security payload--a subprotocol that encrypts the data being transported.'"
It's important to realize that you're only vulnerable to this issue if you're *not* doing integrity checking via IPSEC. Most major VPN infrastructures I run across use ESP with both confidentiality *and* integrity functionality enabled (some use AH as well). If that's the case for network x, then network x has nothing to fear from this.
Always read vulnerability details; people love to sensationalize stuff like this to the extreme.
dmiessler.com -- grep understanding knowledge
http://openvpn.net/
I was worried there for a second.
Ok, no I wasn't.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
This is a misleading writeup. The problem only shows up in certain configurations and is easily worked around. From TFA: Solution - - -------- Any of the following methods can be used to rectify this issue: 1. Configure ESP to use both confidentiality and integrity protection. This is the recommended solution. 2. Use the AH protocol alongside ESP to provide integrity protection. However, this must be done carefully: for example, the configuration where AH in transport mode is applied end-to-end and tunnelled inside ESP is still vulnerable. 3. Remove the error reporting by restricting the generation of ICMP messages or by filtering these messages at a firewall or security gateway.
"None are more hopelessly enslaved than those who falsely believe they are free." -- Goethe
Why wouldn't the payload data be encrypted in the first place?
After all, we are talking about sending packets over public lines.
Am I missing something here?
The problem with socialism is that they always run out of other people's money. - Margaret Thatcher
"old news for nerds"
Slashdot is only as up-to-date as you make it. AFAIK the editorial team don't go looking for articles, they wait for YOU the reader to submit them.
If you want current news, you should participate in providing it.
After reading the ultra mysterious unknown exploit in hyperthreading to be announced at that bsd conference + BSD is usually security paranoid == they have tickets to sell for that conference and are brewing up some hype...
I could be wrong, TFA is very sparse on details...
This space is intentionally staring blankly at you
Ipsec it self isn't vulnerable. It is the session setup that can be misconfigured causing the Exploitable problem.
Well, I guess it stands for Virtual Public Network now. ;)
No, the one hole was in openssh. There have been many (well at least one) holes in their apache, but apache is not enabled by default so it is not counted. Openssh is enabled by default, so it counts.
As far as I know, there is a way to crack Aggressive mode Pre-shared keys when used on IP-Sec. It's been done and proven.
READY.
PRINT ""+-0
More info here.
From the article it states clearly that it is a mode of ESP in tunnel mode that causes the problem NOT IKE (Internet Key Exchange) that is used for session setup.
Now the solution might be in IKE as in don't let IKE configure ESP without authentication - but this boys and girls is why you NEVER do encryption without authentication
I have mod points and I am not afraid to use them
Taken from the NISC website.
Solution
- - --------
Any of the following methods can be used to rectify this issue:
1. Configure ESP to use both confidentiality and integrity protection. This is the recommended solution.
2. Use the AH protocol alongside ESP to provide integrity protection. However, this must be done carefully: for example, the configuration where AH in transport mode is applied end-to-end and tunnelled inside ESP is still vulnerable.
3. Remove the error reporting by restricting the generation of ICMP messages or by filtering these messages at a firewall or security gateway.
My lame blog.
So let's see, first there was the Intel Hyperthreading Vulnerability, then there was a patch to an Apple security flaw and now this....
;)
So who came out a winner betting on this trifecta?
"What do you think?" "I think 'What, do you think?!'"
Would this even matter over an SSL connection?
And here I thought my wireless link using WPA-TKIP (WPA2 not out for access point yet) and an L2TP/IPSEC VPN using ESP 3DES would be secure enough for daily use. Guess I'll have to add yet another layer of encryption. Must I now install an english to pig-latin service for both ends? ;)
This method is known as "giving all your sales guys the same key". Once, I was kidnapped, held at gunpoint in a basement dungeon, and beaten until I agreed to so this.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
This only affects a relatively odd combination of features, so it's probably not a big deal for actual users. On the other hand, it is a flaw in the standard to claim that you can get confidentiality without integrity, when, in fact, that means that your data can be replaced with a request to decrypt your earlier packets, and you'll do so. Of course, integrity would only be disabled in a specialized application (where you expect to be able to deal with mangled data), and IPSec is generally deployed in cases where a variety of applications will use the channel.
It's extremely difficult to design a cryptosystem with optional features, because the security of various techniques tends to depend on properties provided by other techniques, and it's difficult to determine, especially in a committee, whether these properties are provided for the proper function of the system or because the end user is likely to want them.
If you hand your credit card to the first person who walks past you when you're done eating, it may not be your waiter!
From now on we should expect every IE or Firefox vulnerabilitiy to be reported as "Flaw found in Internet security"? Very dramatic!
You can disable encryption in SSL. Next article "Critical Flaw found in SSL."
Erm...I did.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
The ESP-without-Authentication issues have been known for a while. ICMP leakage of the otherwise-secure packets are an interesting new wrinkle on it, though.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
That's fine if you don't care about the security of your data. Current cryptanalysis indicates that at a minimum you want 16 rounds of ROT-13. And since I'm rather paranoid, as a rule I tend to double the recommendations of cryptographic primitives, so I use 32 rounds of ROT-13. With current CPUs as fast as they are, there's very little reason to use less than 16 rounds. And 2 rounds is just insanity.
I dare you to crack my data.
Jason.
In bizarro slashdot-land, there's no doubt a peer-reviewed, wiki-ish news system and their critics are arguing that all the trouble with old news, inanity and dupes could be solved if they allowed advertising and used the profit to hire editors to professionally manage the news flow.
Hey, I just use ROT26 and so far no one has cracked my code... of course it might help to be intelligible in my writings.
I support the 2nd Amendment, the right to keep and arm bears!
They must be using ICMP type 12 (from RFC792) which shows the original header + first 64 bits (8 bytes) of data from each packet. Interesting leak, but very small amount of data. http://rfc.net/rfc792.html
You would have been safer if you used Double ROT-13 encryption instead.
That's fine if you don't care about the security of your data. Current cryptanalysis indicates that at a minimum you want 16 rounds of ROT-13. And since I'm rather paranoid, as a rule I tend to double the recommendations of cryptographic primitives, so I use 32 rounds of ROT-13. With current CPUs as fast as they are, there's very little reason to use less than 16 rounds. And 2 rounds is just insanity.
I dare you to crack my data.
Jason.
Basically, this tells us "don't switch off authentication in IPSec" (if your IPSec allows this, many don't allow you to run without authentication).
t ml#encnoauth )
But, the creators of IPSec told us this a LONG time ago.. Security wizard Steve Bellovin analyzed this as part of his IPSec reviews and said that encryption without authentication is a very bad idea. See the FreeS/WAN FAQ pages for more info ( http://www.manualy.sk/freeswan-1.3/doc/overview.h
Mr. Bellovin presented a paper on this in the Usenet Security Symposium of July 1996.
NAT traversal just adds another level of encapsulation and this 'vulnerability' applies to ESP itself.
3.243F6A8885A308D313
Not having integrity protection enabled automatically opens ESP to the replay attacks, which are easier to mount and far more practical than the one described in TFA.
3.243F6A8885A308D313
Response from the Openswan team: Not vulnerable
The NISCC includes a number of solutions to this issue in its advisory.
Solutions:
come on fhqwhgads
This is a known issue. Some colleagues and I published on a very similar attack where unauthenticated IPSec packets can be redirected, bounced, and possibly decrypted by outsiders back in 2000. See "Initialization vector attacks on the IPsec protocol suite" in the proceedings of WET ICE 2000. Basically you can mess with the first encrypted chunk of the plaintext, i.e. the TCP and IP headers, by bitflipping the initialization vector (IV) in the encrypted packet stream. An IV is used in several block encryption schemes, notably cipher block chaining.
This even works with TCP even though the plaintext header is checksummed. We showed that it was easy to get an identical checksum by modifying an unused part of the TCP header along with a more important part, like destination port.
Using authentication defeats this attack. Just don't forget to authenticate and everything is peachy.
2) Look a the openssh.org homepage. Notice the quote 'OpenSSH is primarily developed by the OpenBSD Project, and its first inclusion into an operating system was in OpenBSD 2.6. '
I'm siding with bluGill on this point, the AC is the dumbass on this trhread.
Think global, act loco
Big noise, nothing behind it.
To call this issue well-known would be an understatement. It is even mentioned in the RFC2406 in the Introduction. RFC2406 happens to be to RFC that defines ESP mode in IPsec.
It must be a slow news day in Great Britain.
I thought you were supposed to use SSH tunneling to connect the remote sites.. That isn't necessary? shoot i've been doing this all wrong.
Can you be Even More Awesome?!
I prefer to use 52 rounds of ROT-1.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
3328 rot-13's work for me...
plus as an added bonus, you can preview the encrypted message for spelling errors before you post it!
shine,
Time flies like an arrow -- Fruit flies like a banana
Erm, yes?
What do you think "the conquest of the west" was?
America was built by invading lands occupied by others and driving them out and/or killing them. That's not how we ought to behave now, but was not too far from a mainstream attitude then.
All countries were created and re-created the same way, many times, over millennia. Look at Britain, created by successive waves of invasion and colonisation. Before America, the indigines did the same thing to each other. Prior to the invention of the modern state and modern democracy, it wasn't even widely considered especially morally wrong, just something you didn't want to be on the wrong end of.
NO ID: BEING FREE MEANS NOT HAVING TO PROVE IT