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.'"

Comments

Hype Warning

[danielrm26]

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.

Re:Hype Warning

[whoever57]

Does this mean that it DOES apply to IPSEC VPNs that are configured with NAT Traversal?

Re:Hype Warning

[m0rningstar]

No ... all NAT traversal does is to wrap the ESP packet in a UDP packet (to the best of my understanding, at any rate).

So if you have the integrity trailer turned on -- which, as the original poster said, is good practice -- it should make no difference if it's a raw ESP packet or an ESP packet in the payload of a UDP packet.

There also look to be some fairly large technical difficulties with implementing the attack, not the least of which is that you have to bit flip arbitrarily to recover the data and depending on your SA lifetime that might not be terribly productive.

Yes, it's a flaw in IPSec and that's bad, but I think it's technically a very difficult attack AND relatively easy to work around.

Whew...

[grasshoppa]

http://openvpn.net/

I was worried there for a second.

Ok, no I wasn't.

Nonsense

[Cally]

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.

Re:Old news

[norfolkboy]

"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.

VPN

[OverflowingBitBucket]

Well, I guess it stands for Virtual Public Network now. ;)

Misleading hype

[Anonymous Coward]

This only applies to certain configurations using CBC encryption for confidential guarantees without proper integrity protection. These configurations are rare these days and are not even allowed by major vendors.

More info here.

Wrong Answer - Please ignore parent

[MerlynEmrys67]

Uh - NO - (why is this insiteful)

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

Solution

[SenFo]

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.

Sweet Friday the 13th!

[Mad_Rain]

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? ;)

Only relevant to the standard

[iabervon]

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.

Slashdot provides critical security advisory!

[ramam]

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!

Re:Yea.

[Tack]

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.

Old News.. This is a non-issue

[tji]

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).

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.ht ml#encnoauth )

Mr. Bellovin presented a paper on this in the Usenet Security Symposium of July 1996.

This is a known issue

[lyrix]

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.