Copyright (c) 2004,2005 Philippe Sultan, INRIA.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".
Dynamic VPN connections are useful to get into your private network. Todays
VPN solutions aim to provide remote users the ability to work outside their
network as if they were physically located in the private network.
In order to achieve this objective, IETF's IKE/ISAKMP/IPSEC standards describe a full system that permits data transfer between a remote user and his private network resources relying on three security points : data integrity, data confidentiality and end participants authentication.
The latter point will be discussed in these pages, and we'll show how some ISAKMP Client implementations can be misleaded to talk to a wrongly authenticated VPN server, which can lead to a security hazard.
In particular, when ISAKMP Aggressive Mode + Pre Shared Key authentication + Xauth is used, we will describe how to get the Xauth credentials (username / password) sent by the VPN user in a LAN environment when you already know the Pre Shared Key, sometimes refered to as Group Password.
Phase I of IKE/ISAKMP system can be set up in two different modes : Main
and Aggressive Modes. While the latter needs less round trips messages to
build up Phase I Security Associations, it is far more insecure as ISAKMP
ID payloads for both ends remain visible.
Therefore, using pre-shared keys under Aggressive mode to authenticate both ends is certainly the least secure way of setting up ISAKMP SAs.
We used a Cisco VPN Client (v 4.0.4) on a Windows 2000 platform to perform our tests, locked to work in Aggressive Mode + pre-shared keys. In order to provide a more secure and flexible authentication mecanism, the VPN server asks users for credentials (username / password) which are tested against a RADIUS database. Both VPN client and server implement the non-standard XAUTH technology to achieve user authentication.
Note : we tested Cisco VPN client v 4.6, as well as opensource vpnc client. Both of them are vulnerable as they still use ISAKMP/Xauth with PSK. This has been done with Frederic Giquel : thank you!
The VPN client had full Internet connectivity through the gateway to the
VPN server, the standard ISAKMP UDP port 500 was used for both client and
server in our tests.
All the tests have been performed on a switched LAN and a network traffic diversion tool was used to redirect ISAKMP packet initially sent by the VPN client to the insider attacker.
arp-sk is a very good 'ARP cache poisoning' tool, and it was intensively used during our testing period : http://www.arp-sk.org
Figure one shows the general setup, including IP addresses assigned to the different elements.
: general setup
Under normal conditions (ie no traffic diversion from the VPN client to
the attacker), the client initiates a VPN connection to the VPN server, and
an ISAKMP Phase I dialog under Aggressive Mode between these ends starts.
The first IP datagram sent to the VPN server goes through the gateway, as the IP destination (192.168.1.2) matches the default gateway entry in the client's routing table. Moreover, destination MAC address of the Ethernet frame encapsulating the IP datagram corresponds to the gateway.
: correct traffic circulation
The following test implies the VPN client and server as well as the attacker.
Traffic from the VPN client to the VPN server will be intercepted by the attacker
who will reply to ICMP requests instead of the VPN server. We only need to
divert the IP stream going from the VPN client to the VPN server, in fact
the attacker will echo the expected replies to the VPN client by setting the
VPN server's IP address as the source IP address of each ICMP echo reply.
A continuous 'ping' command from 192.168.0.2 to 192.168.1.2 is executed on the VPN client and ICMP requests and replies follow the expected path, ie through le local LAN gateway.
: ICMP echo exchange between VPN client and server
The attacking computer's OS is Linux (kernel 2.4.25 - debian distribution).
Its network configuration is simple :
Let's now use 'arp-sk' to divert the traffic from the VPN client to the VPN
server. We'll update the ARP cache of the VPN client and replace the MAC address
corresponding to the gateway's IP address with ours. As a result, all the
Ethernet frames that were previously going from the VPN client to the gateway
are now processed by the attacker. This includes the Ethernet frames that
encapsulate the IP datagrams from the VPN client to the VPN server.
The following command does it :
root@attacker#arp-sk -s <Attacker's MAC> -d <VPN client's MAC>
-S 192.168.0.1:<Attacker's MAC> -D 192.168.0.2:<VPN client's MAC>
This ARP cache poisoning command is repeated every 30 ms, as we experienced
unwanted updates of the ARP cache with lower values.
Now, all the ICMP echo request from the VPN client to the VPN server go
through the attacker, and are forwarded to the gateway according to the attacker's
Note that the ICMP echo reply from the VPN server to the VPN client follows a 'normal' path, as we did not modify the ARP cache on the gateway.
4 : ARP cache poisoning => one way traffic diversion and packet
We can also stop forwarding the ICMP echo requests so that they won't reach
the VPN server.
To stop forwarding packets on the attacker :
root@attacker#echo 0 > /proc/sys/net/ipv4/ip_forwarding
5 : ARP cache poisoning => one way traffic diversion without packet
Once packet forwarding capability on the attacker has been stopped, we'll
borrow the VPN server's IP address in order to send ICMP replies back to the
VPN client. A new logical network interface is created for this purpose 'on
top' of the existing interface :
root@attacker#/sbin/ipconfig eth0:0 192.168.1.2
The VPN client receives ICMP echo replies from 192.168.1.2, but these replies
are sent back by the attacker. The network configuration on the attacking
computer becomes :
6 : ARP cache poisoning => one way traffic diversion, replies sent
back by attacker
Now, instead of playing with ICMP, what would happen if we had an actual ISAKMP stack on the attacker?
The main characteristics of the VPN client are :
Mutual authentication through pre-shared keys, although widespread, is known
not be secure and keeping the pre-shared secret is the problem.
See these documents for more information :
http://www.ima.umn.edu/~pliam/xauth/ : Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets, by John Pliam
http://ikecrack.sourceforge.net/ : A tool to break Aggressive Mode + PSK authentication, by Anton T. Rager
In order to spoof the VPN server, you need to know the pre-shared key used
by both VPN client and server. Moreover, the previously detailed traffic diversion
technique will be used, following these steps :
ot@attacker#arp-sk -s <Attacker's MAC> -d <VPN client's MAC> -S 192.168.0.1:<Attacker's MAC> -D 192.168.0.2:<VPN client's MAC> -t u30000
root@attacker#/sbin/ifconfig eth0:0 192.168.1.2
root@attacker#echo 0 > /proc/sys/net/ipv4/ip_forwarding
Openswan offers a complete and free VPN IPSEC based solution. The ISAKMP
part of this solution is called 'pluto' and is used as the ISAKMP server component
in the attacking computer.
The Cisco VPN client is locked to work with Cisco devices, so a few adjustments had to be made to the original pluto. See the instructions to install and configure an ISAKMP server able to talk to your Cisco VPN client ( v 4.0.4 ) : Configuring openswan for the attack
You must edit the
/etc/ipsec.secrets file on the attacking computer
to enter the preshared key :
: PSK "<your PSK>"See the openswan documentation for more onfo on editing
The following parameters were used to launch pluto, mainly to get as much
debugging information as possible :
root@attacker#./pluto --debug-all --noklips --stderrlog --nofork
pluto comes with 'whack', which sends commands to pluto, another terminal
must be used to launch whack. We set up pluto as an ISAKMP Aggressive
Mode + PSK + Xauth server by giving these parameters :
root@attacker#./whack --name silly --host %any --to --host 192.168.1.2 --nexthop 192.168.1.2 --psk --aggrmode --xauth
Any attempt to connect to the VPN server from the VPN clien will be intercepted by the attacker, and after mutual authentication through the pre-shared key, the user will be prompted for his username and password. Once entered, the credentials are encrypted with the keying material mainly deriving from the PSK and transmitted to the fake VPN server.
As a result, the user will get a kind of 'unable to connect' message as we
don't proxy the connection, and you just have to stop the arp-sk attack to
disappear...with his username and password.
Here is a part of the debug output you get in the pluto terminal, the interesting part starts with "->", it gives the username and password as entered by the user :
"silly" 192.168.0.2 #1: transition from state STATE_AGGR_R1 to state STATE_AGGR_R2
| inserting event EVENT_RETRANSMIT, timeout in 3330 seconds for #1
"silly" 192.168.0.2 #1: ISAKMP SA established
"silly" 192.168.0.2 #1: XAUTH: Sending XAUTH Login/Password Request
"silly" 192.168.0.2 #1: XAUTH: Sending Username/Password request (XAUTH_R0)
"silly" 192.168.0.2 #1: XAUTH: User sultan attempting login with password -> mypassword
"silly" 192.168.0.2 #1: XAUTH: User sultan: Incorrect Password
The last line indicates that user authentication failed, you expect that
if you don't have any user authentication database running on your fake ISAKMP
A copy of the GNU FDL is available here :
GNU Free Documentation License
Created: 2004/07/24 21:05:31
Updated: $Revision: 1.6 $ $Date: 2005/07/19 22:54:49 $ $Author: sultan $