Red Hat Bugzilla – Bug 435274
CVE-2008-1198 initscripts: IPSec ifup script allows for aggressive IKE mode
Last modified: 2012-02-21 03:18:35 EST
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:
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
See this whitepaper for more information:
The exchange_mode should be changed to "main" only or, for a low-security
fallback, to "main, aggressive" (in the opposite order than currently).
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?
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:
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
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
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
against this hash to recover the PSK. With IKECrack
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
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.
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
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