Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Flaw Found in VPN Crypto Security

Posted by Zonk on Fri May 13, 2005 10:28 AM
from the dire-straights dept.
Security Networking IT
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.'"
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Flaw Found in VPN Crypto Security 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Hype Warning (Score:5, Informative)

    by danielrm26 (567852) * on Friday May 13 2005, @10: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, @10:39AM (#12520281) Journal
      Does this mean that it DOES apply to IPSEC VPNs that are configured with NAT Traversal?
      • 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, @11:49AM (#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.
    • Is your vulnerability reduced or eliminated by encapsulating your IPSEC tunnels in GRE tunnels?
    • 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) <skennedy@tp[ ]co.org ['no-' in gap]> on Friday May 13 2005, @10:31AM (#12520181) Homepage
    http://openvpn.net/ [openvpn.net]

    I was worried there for a second.

    Ok, no I wasn't.
    • 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.
      • Erm...I did.

      • Re:Yea. (Score:5, Funny)

        by Tack (4642) on Friday May 13 2005, @11:48AM (#12521095) Homepage
        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.

        • 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.
        • I prefer to use 52 rounds of ROT-1.

          -
      • IPSec, on the other hand, was designed and reviewed by a large number of experts in security. It continues to go through a lot of review, and constant attempts to break it.

        I can't argue with this. But IPsec's biggest enemy is its own complexity. I've read enough about IPsec and it scares the shit out of me. Sure, I can set it up and see that it works (and have done so). But to really understand what's going on would take a me a solid week (probably more) of research, and even then there's no guarantee

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

        by cduffy (652)
        Spin it however you like -- but read this [gmane.org].

        OpenVPN's security model [openvpn.net] is quite strong -- as documented in the FAQ [openvpn.net], it borrows heavily from preexisting (time-tested, heavily reviewed) protocols (not just SSL but ESP as well), and supports multiple layers of security (ie. "tls-auth", a pre-shared key authenticating all traffic; support for running unprivileged and within a chroot jail to prevent OS-level security breaches; etc). Further, the (limited region of) code which handles pre-authentication network traf
        • No offence intended, but I'll stick to security systems designed by experts. "Borrowing" techniques from experts is great, but its a far cry from being one.

          Consider that the average person rewiring their own home often doesn't know of the dangers of having polarity reversed on outlets despite knowing how to use a screwdriver and knowing that grounding is important.

          Consider that those who do know about polarity issues might not know about the heat dissipation limitations of various sizes of box for the wi
          • There are a *lot* more mistakes to be made in large number cryptography and security software than there are in wiring a house.

            True.

            Notably, while OpenVPN's core is documented well enough to allow peer review of its design, and the code is clean enough to allow for easy desk checking, I haven't seen a single 3rd-party patch to the crypto portions submitted or accepted. As such, it's not such an amateur effort as you perhaps make it out to be -- there's a single author of the core, and to the best of my l
            • While I have no evidence to suggest that OpenVPN actually has any such bugs, many crypto software bugs have been highly obscure even in well-designed packages. Consider the with/without compression issues for PGP/SSH in the past, or initialization vector selection issues, or how memory is handled (protection, swapping, etc.)

              Getting crypto right requires a lot of thought, that's all. I'm sure OpenVPN works well for you, but I'll stick to ipsec for now.

  • Nonsense (Score:5, Informative)

    by Cally (10873) on Friday May 13 2005, @10: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?
  • 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, @10:48AM (#12520361) Homepage Journal
    Well, I guess it stands for Virtual Public Network now. ;)
  • 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.
    • 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, @11:00AM (#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, @11:02AM (#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, @11:07AM (#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? ;)

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

    by iabervon (1971) on Friday May 13 2005, @11:24AM (#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, @11:26AM (#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!
  • 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, @12: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, @01: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, @02: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.

    • Re:Old news (Score:5, Insightful)

      by norfolkboy (235999) * on Friday May 13 2005, @10:34AM (#12520213) Homepage
      "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.

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

        Yeah, like readers are even remotely in control here...

        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

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

          • 1) Look at the security report from the OpenBSD folks at http://openbsd.org/errata31.html#sshd [openbsd.org], the OpenBSD hole was indeed in OpenSSH.
            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.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.