Description of problem: The default IPSec ifup script (/etc/sysconfig/network-scripts/ifup-ipsec) initializes the racoon configuration to use aggressive IKE mode, then fallback to main IKE mode if that fails: ... remote $DST { exchange_mode aggressive, main; ... Due to widely known attacks, the aggressive mode should be only used when public key authentication is in use. In practice, most administrators use IPSec with PSK authentication, which combined with aggressive mode leads to aforementioned vulnerability. See this whitepaper for more information: http://www.netsc.ch/IMG/pdf/TargetingIKE_en.pdf The exchange_mode should be changed to "main" only or, for a low-security fallback, to "main, aggressive" (in the opposite order than currently).
Hi Aleksander, Can you elaborate on this paper? I'm having a bit of a rough time understanding exactly what the problem is here. My understanding from reading the paper is that the attack described could allow a remote attacker to determine information about the VPN gateway. I don't think I'm understanding the problem properly, can you help explain this in a manner I can grasp? Thanks.
Sorry, the paper I've linked to may not be as readable as the original paper by Michael Thumann and Enno Rey which you can read over here: http://www.ernw.de/download/pskattack.pdf In short, the PSK hash in Aggressive mode is sent unencrypted over the network, and this condition greatly eases cracking (brute force/dictionary) attacks on the PSK. Quoting the Thumann/Rey paper: "In IKE Aggressive mode the authentication hash based on a preshared key (PSK) is transmitted as response to the initial packet of a vpn client that wants to establish an IPSec Tunnel (Hash_R). This hash is not encrypted. It's possible to capture these packets using a sniffer, for example tcpdump and start dictionary or brute force attack against this hash to recover the PSK. With IKECrack (http://ikecrack.sourceforge.net) is a tool available to do this job. This attack only works in IKE aggressive mode because in IKE Main Mode the hash is already encrypted. Based on this facts IKE aggressive mode is not very secure." That's the theory, in practice you can try the attack yourself using IKECrack. Apart from security problems, this default configuration also causes interoperability problems (which in fact have led me to this investigation). When you try to setup an IPSec transport mode association between Red Hat (tested on RHEL4) and Windows XP, the associations cannot be successfully initiated from the Red Hat side. When Windows initiates the association, it's set up properly. When analyzing network traffic dump one can clearly see that Red Hat offers key exchange using ISAKMP Aggressive mode. Windows simply ignores this request and negotiation eventually times out on Red Hat side. This is both combination of improper behaviour on Windows side (it rightfully doesn't accept the Aggressive mode because it's insecure, but it should reply indicating that the proposed mode of key exchange isn't acceptable - instead it remains silent) and on Red Hat side (it should offer the more secure "main" mode first).
I concur with the reporter. Agressive mode has vulnerabilities and should not be the default. This shouldn't impact any administrators, (at least not in homogeneous Red Hat networks) and if it does, they will be the ones who are knowledgable enough to set up their own configurations anyway. It's possible that this will cause other interoperability problems with other vendors, but I have no way of predicting what those may be. I think the risk is low.
Given that this flaw is the result of a bad configuration option, I'm going to request a CVE id for this issue and we shall see about getting it fixed in a future security update.
Steve, Does this only affect Red Hat Enterprise Linux 5, or are others affected as well?
It's the same in 3 and 4.
I'm moving this bug to the Security Response product for proper tracking as a security issue.
Acknowledgements: Red Hat would like to thank Aleksander Adamowski for reporting this issue.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2012:0312 https://rhn.redhat.com/errata/RHSA-2012-0312.html