Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security Networking IT

Flaw Found in VPN Crypto Security 106

Posted by Zonk from the dire-straights dept.
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.'"
This discussion has been archived. No new comments can be posted.

Flaw Found in VPN Crypto Security More

Flaw Found in VPN Crypto Security

Comments Filter:

  • Hype Warning (Score:5, Informative)

    by danielrm26 ( 567852 ) * on Friday May 13, 2005 @11:29AM (#12520163) Homepage
    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 (Score:4, Interesting)

      by whoever57 ( 658626 ) on Friday May 13, 2005 @11:39AM (#12520281) Journal
      Does this mean that it DOES apply to IPSEC VPNs that are configured with NAT Traversal?

      • Re:Hype Warning (Score:3, Informative)

        by God! Awful 2 ( 631283 )
        Does this mean that it DOES apply to IPSEC VPNs that are configured with NAT Traversal?
        Sure, if you disable authentication. But there's nothing specifically related to NAT traversal.

        -a

      • Re:Hype Warning (Score:5, Informative)

        by m0rningstar ( 301842 ) <cpw&silvertyne,com> on Friday May 13, 2005 @12:49PM (#12521104) Homepage
        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.
        • 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.
          No, it is not a flaw in IPsec. It is simply a misconfiguration. IPsec is a very flexible protocol, and it has been both praised and criticized for that fact. The upside is that you can choose to use whatever crypto algorithms you want. The downside is that you may choose a dumb combination.

          -a
      • NAT traversal just adds another level of encapsulation and this 'vulnerability' applies to ESP itself.
    • Good one danielson...

      Quick, all you psuedo-pro's get out your VPN cheat sheet and study up!

      oh yeah, and RTFA!!!
    • Is your vulnerability reduced or eliminated by encapsulating your IPSEC tunnels in GRE tunnels?
      • Is your vulnerability reduced or eliminated by encapsulating your IPSEC tunnels in GRE tunnels?

        First, why would you want to encaps IPSec into GRE? And no. It is a flaw in ESP.
    • 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.
      What you say is true.

      Another thing that hasn't been mentioned is that most VPN boxes would use SPD checking to verify that the IPs of packets coming out of the tunnel matc

    • Moreover (Score:3, Interesting)

      by apankrat ( 314147 )
      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.

  • Whew... (Score:5, Informative)

    by grasshoppa ( 657393 ) on Friday May 13, 2005 @11:31AM (#12520181) Homepage
    http://openvpn.net/ [openvpn.net]

    I was worried there for a second.

    Ok, no I wasn't.

    • Re:Whew... (Score:3, Informative)

      by Linker3000 ( 626634 )
      Good call - OpenVPN is a good package.

    • Re:Whew... (Score:3, Insightful)

      by Tack ( 4642 )
      I'm going to chime in with a definite "me too" here. I've been using OpenVPN for over a year, and this is absolutely solid software. It easily falls into the Just Works category. I have it started on boot, and I simply forget that it's there. If there are network issues, it recovers gracefully.

      I can't quite speak to its security, but there's nothing I've seen that makes me the least bit concerned. Although Peter Gutmann didn't do a real audit of openvpn, he did have this to say [auckland.ac.nz] about it: "... but a q

    • OpenVPN:
      Easier to configure than most if not all IPSec-based solutions.
      Provides pretty much the same functionality, except for obscure bells and whistles.
      Has similar, if not better, security.
      Runs on pretty much all important platforms.
      Has a GUI for Windows, so that even dummies can use it.
      It Simply Works (TM).

      I will never go back to IPSec.
    • Yet another to add to those singing praises for OpenVPN. I had a setup with a friend between a linux box and a sparc running solaris. The linux box was setup to initiate the connection and the solaris box had openvpn startup via inetd. The linux box had a cronjob to do a pgrep for openvpn every few minutes and start it up if it weren't running. If there were ever any connection issues on my side or his, the tunnel would be initiated again as soon as the connectivity was restored. It was so much easier than

  • Nonsense (Score:5, Informative)

    by Cally ( 10873 ) on Friday May 13, 2005 @11:32AM (#12520196) Homepage
    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.
    • I agree.

      Not only that, but this is as designed. If you want to guarantee the integrity of the ESP payload, you've got to turn on integrity guarantees. That's why the option is there. Encryption != guaranteed integrity!

      Shame on any vendor which doesn't enable integrity checks on ESP payloads by default. If they make it easy enough to use IPSec without understanding it, they've got a responsibility to use secure defaults or warn the user (loudly) when insecure defaults are used.

  • 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?
    • Why wouldn't the payload data be encrypted in the first place?

      How would you communicate how this is encrypted? You'd need another payload data, which would probably be vulnerable to the same attack.
    • This vulnerability doesn't cause the payload to not be encrypted, it's a means of figuring out how to decrypt them without knowing the key.

      Of course, the whole thing relies on you having message authentication (hmac-md5 or hmac-sha1) off. Something which was already known to be a bad idea.

      With authentication off, someone can twiddle bits in the packet (without knowing their original state, but they can predictably flip a specific bit). From that, you look at the reply. If you do this enough times to field
  • 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...
  • Ipsec it self isn't vulnerable. It is the session setup that can be misconfigured causing the Exploitable problem.

  • VPN (Score:5, Funny)

    by OverflowingBitBucket ( 464177 ) on Friday May 13, 2005 @11:48AM (#12520361) Homepage Journal
    Well, I guess it stands for Virtual Public Network now. ;)
  • Comment removed based on user account deletion
    • 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.
    • 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.
      Yeah... it's called brute force.

      A lot of boxes on the net use relatively weak passwords, so it shouldn't take too long, actually... although you might set off the IDP.

      -a

  • Misleading hype (Score:4, Informative)

    by Anonymous Coward on Friday May 13, 2005 @12:00PM (#12520497)
    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 [cert.org].

  • Solution (Score:4, Informative)

    by SenFo ( 761716 ) on Friday May 13, 2005 @12:02PM (#12520521) Homepage
    Taken from the NISC website [niscc.gov.uk].

    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! (Score:4, Funny)

    by Mad_Rain ( 674268 ) on Friday May 13, 2005 @12:07PM (#12520575) Journal
    So let's see, first there was the Intel Hyperthreading Vulnerability [slashdot.org], then there was a patch to an Apple security flaw [slashdot.org] and now this....

    So who came out a winner betting on this trifecta? ;)
  • 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? ;)

    • Re:Grrr... (Score:1, Funny)

      by Anonymous Coward
      Better throw in some Double ROT-13 encryption as well. Just to be sure ;)
    • > Must I now install an english to pig-latin service for both ends? ;)

      No, here's what you do: Set up Dvorak->Qwerty transliterative fonts on all your workstations at both ends, and set the keyboard layouts to Dvorak. Your users will still type as if the layout were QWERTY, and due to the transliterative fonts the letters will appear correct. For instance, the user will type the key that they think is "S", but on a Dvorak layout that key is really "O", so the character they typed is "O". However,
    • ROT13 twice, for extra security.

  • Only relevant to the standard (Score:4, Insightful)

    by iabervon ( 1971 ) on Friday May 13, 2005 @12:24PM (#12520749) Homepage Journal
    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.
    • On the other hand, it is a flaw in the standard to claim that you can get confidentiality without integrity.
      IIRC, the standard doesn't say that. I believe it says the opposite.

      Disabling authentication is just something vendors like do to increase their published performance numbers. No one should actually deploy that configuration.

      -a

  • Slashdot provides critical security advisory! (Score:5, Funny)

    by ramam ( 882415 ) on Friday May 13, 2005 @12:26PM (#12520762)
    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."

  • More Info... (Score:2, Informative)

    by Jeffb05 ( 883807 )
    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 [rfc.net]

  • Old News.. This is a non-issue (Score:4, Informative)

    by tji ( 74570 ) on Friday May 13, 2005 @01:54PM (#12521901)
    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 [manualy.sk] )

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

  • No sane IPsec implementation id vulnerable (Score:3, Informative)

    by leto ( 8058 ) on Friday May 13, 2005 @02:39PM (#12522448) Homepage
    Response from the Openswan team: Not vulnerable [openswan.org]

  • The NISCC includes a number of solutions to this issue in its advisory.

    Solutions:

    • (1) ignore this hyped warning
    • (2) use all possible security layers of IPSec
    • (3) don't use IPSec at all, if you are worried from this message your obviously not very secure to begin with

  • This is a known issue (Score:3, Informative)

    by lyrix ( 216616 ) on Friday May 13, 2005 @03:11PM (#12522813)
    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.
  • Big noise, nothing behind it.

    To call this issue well-known would be an understatement. It is even mentioned in the RFC2406 [rfc-editor.org] 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.

Slashdot Top Deals

The rule on staying alive as a program manager is to give 'em a number or give 'em a date, but never give 'em both at once.

Close