Slashdot Mirror

← Back to Stories (view on slashdot.org)

Flaw Found in VPN Crypto Security

Posted by Zonk on 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.'"

16 of 106 comments (clear)

  1. Hype Warning by danielrm26 · · Score: 5, Informative

    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
    1. Re:Hype Warning by God!+Awful+2 · · Score: 2, Informative

      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

      --
      /. users can't
    2. Re:Hype Warning by m0rningstar · · Score: 4, Informative

      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.

  2. Whew... by grasshoppa · · Score: 4, Informative

    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!
    1. Re:Whew... by Linker3000 · · Score: 2, Informative

      Good call - OpenVPN is a good package.

      --
      AT&ROFLMAO
  3. Nonsense by Cally · · Score: 5, Informative

    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
  4. Don't go replacing anything just yet. by PacketScan · · Score: 2, Informative

    Ipsec it self isn't vulnerable. It is the session setup that can be misconfigured causing the Exploitable problem.

  5. Re:OpenBSD is clear by bluGill · · Score: 2, Informative

    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.

  6. Misleading hype by Anonymous Coward · · Score: 4, Informative
    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.

  7. Wrong Answer - Please ignore parent by MerlynEmrys67 · · Score: 4, Informative
    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

    --
    I have mod points and I am not afraid to use them
  8. Solution by SenFo · · Score: 4, Informative

    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.
  9. More Info... by Jeffb05 · · Score: 2, Informative

    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

  10. Old News.. This is a non-issue by tji · · Score: 3, Informative

    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.

  11. No sane IPsec implementation id vulnerable by leto · · Score: 2, Informative

    Response from the Openswan team: Not vulnerable

  12. This is a known issue by lyrix · · Score: 3, Informative

    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.

  13. This is the Paris Hilton of Security Advisories by Fefe · · Score: 2, Informative

    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.