Home Next: Configuring openswan for the attack

An example of VPN server spoofing


thanks to Abdelkader Allam for his great contribution!
  1. Copyright and license
  2. Introduction
  3. Authentication in IKE/ISAKMP
  4. Software used and testing conditions
  5. Diverting traffic with arp-sk - ARP cache poisoning technique
  6. Spoofing the VPN server
  7. GNU Free Documentation License

  1. Copyright and license
  2. 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".

  3. Introduction
  4. 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.

  5. Authentication in IKE/ISAKMP
  6. 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.

  7. Software used and testing conditions
  8. VPN client configuration

    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!

    Attacker configuration

    Network environment

    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.

    Fig 1 : general setup

    Fig. 1 : 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.

    Fig 1 : correct traffic circulation

    Fig. 2 : correct traffic circulation

  9. Diverting traffic with arp-sk - ARP cache poisoning technique
  10. 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.

    Fig 3 : ICMP echo exchange between VPN client and server

    Fig. 3 : ICMP echo exchange between VPN client and server

    Setting up 'arp-sk'

    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> -t u30000

    This ARP cache poisoning command is repeated every 30 ms, as we experienced unwanted updates of the ARP cache with lower values.

    Forwarding packets for the VPN client

    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 routing table.
    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.

    Fig 4 : ARP cache poisoning => ICMP one way traffic diversion

    Fig.  4 : ARP cache poisoning => one way traffic diversion and packet forwarding

    Stop forwarding packets

    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

    Fig 5 : ARP cache poisoning => ICMP one way traffic diversion

    Fig.  5 : ARP cache poisoning => one way traffic diversion without packet forwarding

    Taking the VPN server's IP address

    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 :

    Fig 6 : ARP cache poisoning => ICMP one way traffic diversion, replies sent back by attacker

    Fig.  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?

  11. Spoofing the VPN server
  12. 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 :

    ISAKMP software on the attacker : openswan's pluto v1.0.6

    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 /etc/ipsec.secrets

    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
    root@attacker#./whack --listen

    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"[2] 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"[2] 192.168.0.2 #1: ISAKMP SA established
    "silly"[2] 192.168.0.2 #1: XAUTH: Sending XAUTH Login/Password Request
    "silly"[2] 192.168.0.2 #1: XAUTH: Sending Username/Password request (XAUTH_R0)
    "silly"[2] 192.168.0.2 #1: XAUTH: User sultan attempting login with password -> mypassword
    "silly"[2] 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 server.

  13. GNU Free Documentation License
  14. A copy of the GNU FDL is available here :
    GNU Free Documentation License


author :Philippe Sultan
Created: 2004/07/24 21:05:31
Updated: $Revision: 1.6 $ $Date: 2005/07/19 22:54:49 $ $Author: sultan $