Chapter 12. Assessing IP VPN Services
This chapter tackles assessment of VPN services found running on network boundaries. Increasingly, VPN services provide access for both branch offices and home users, using IPsec, Microsoft PPTP, and SSL. These VPN service endpoints are under threat from information leak, buffer overflow, DoS, and offline password-grinding attacks, which are detailed in the following sections.
IPsec VPNs
VPN technologies and their underlying protocols fill entire books already. One book I used to research IPsec key exchange and authentication protocols is IPSec: Securing VPNs by Carlton R. Davis (McGraw-Hill). If you require detailed low-level information about IPsec and its various modes and protocols, you should read a book dedicated to the subject. Here I tackle the key IPsec protocols and mechanisms at a high level and discuss known remotely exploitable weaknesses and attacks.
Standard Internet Protocol (IP) packets are inherently insecure. IPsec was designed to provide security options and enhancements to IP, and to negate the following security weaknesses:
IP spoofing and packet-source forgery issues
Modification of data within IP packets
Replay attacks
Sniffing attacks
Most IPsec implementations use the Internet Key Exchange (IKE) service to provide authentication and key exchange when establishing and maintaining an IPsec connection. Some older IPsec implementations use manual keying, but this is now considered obsolete. After authenticating and negotiating keying material through IKE, a Security Association (SA) is established between the client and IPsec server. The SA defines the IPsec protocol to be used, as well as cryptographic algorithms, keys, and their lifetime. Figure 12-1 outlines the relationship between IPsec protocols.
The IPsec Authentication Header (AH) mechanism provides data origin authentication for IP datagrams within IPsec traffic by performing cryptographic hashing. AH provides protection from data modification and replay attacks. The Encapsulating Security Payload (ESP) is a second mechanism, one that encapsulates and encrypts IP datagrams to protect them from sniffing attacks.
ISAKMP and IKE
Internet Security Association and Key Management Protocol (ISAKMP) is accessible through UDP port 500 and provides IKE support for IPsec VPN tunnels. IKE is used as the authentication mechanism when establishing an IPsec connection; it supports three classes of authentication methods: pre-shared keys (PSKs), public key encryption, and digital signatures.
IKE uses a two-phase process to establish the IPsec SA: the first phase authenticates the peers and establishes an ISAKMP SA (used during phase two), and the second phase establishes an IPsec SA. Some implementations have additional phases between the two to provide additional authentication or send information to the client. Examples of these are XAUTH, hybrid mode, and mode config; however, none of these extensions are formal standards (XAUTH is an IETF draft published in 1997 and is used by Cisco, Nortel, and others; hybrid mode is an IETF draft first published in 1998 that is used by Check Point; and mode config is a 2001 draft that is used by Cisco, Check Point, and others).
IKE phase one can run in one of two modes: main mode or aggressive mode. IKE phase two has only a single mode, called quick mode. When testing IPsec VPN systems, you will be dealing primarily with IKE phase one, as phase two is only accessible upon successful authentication. For the remainder of this section, we will only be considering IKE phase one testing.
Main mode
Main mode is a phase one key-exchange mechanism that protects the identity of the client and authentication data by using a Diffie-Hellman (DH) exchange to generate a mutual secret key. All VPN servers should support main mode, as mandated in RFC 2409. Figure 12-2 shows the main mode IKE messages sent between the initiator and responder.
In total, six messages are transmitted between the two parties. Here is a breakdown of the messages and their purpose:
- Message 1
An IKE SA (not to be confused with an IPsec SA) proposal is sent to initiate the key exchange mechanism.
- Message 2
The IKE SA is accepted.
- Messages 3 and 4
DH public values (
KE) are exchanged, along with a random data nonce payload for each party (NiandNr). From this exchange, a mutual secret key is computed. After this point, the shared keys computed from the DH exchange are used to encrypt IKE payloads.- Messages 5 and 6
Authentication data (
AUTH) is sent, protected by the DH shared secret generated previously. The identification of the parties (IDiiandIDir) is also protected.There are two points worth noting:
The expensive DH computation is not performed until after the first packet exchange.
The peer IDs are passed encrypted, not in the clear.
Aggressive mode
An alternative to main mode is aggressive mode, in which identity protection isn’t required. Support for aggressive mode is optional, so not all VPN servers support it. A total of three messages are transmitted during a successful aggressive mode IKE exchange (compared with six for main mode), which reduces the time required to complete the phase one exchange, but also impacts security and integrity because the peer ID is passed in the clear (not encrypted).
This mode is generally used within remote access VPN solutions. Because of the way the keying material is calculated, it is not possible to use main mode with pre-shared key authentication unless the IP address of the initiator is known beforehand (which is usually dynamic in a remote access situation).
Aggressive mode is also susceptible to a resource exhaustion attack, resulting in DoS because the expensive DH computation must be performed immediately after receiving the first packet. A hostile peer could saturate the VPN server’s CPU by sending a large number of aggressive mode IKE requests with spoofed source addresses.
Figure 12-3 shows the three aggressive mode messages sent between the initiator and responder.
Here is a breakdown of the aggressive mode messages and their content:
- Message 1
An IKE SA proposal is sent, along with a DH public value (
KE), random nonce data (Ni), and identity information (IDii). Because the identity is passed in the first packet, before the DH exchange has completed, it cannot be encrypted.- Message 2
The IKE SA is accepted, and the responder’s DH public value is sent, along with a nonce (
Nr), identity information (IDir), and an authentication payload (AUTH).- Message 3
Authentication information is sent back, protected by the DH secret key derived previously.
Attacking IPsec VPNs
To assess the security of an IPsec VPN, as with any target network or system, you need to perform enumeration, initial testing, investigation, and qualification of vulnerabilities. Here I discuss how to assess IPsec VPN services accessible over IP. If you have access to the wire, there are a number of complex man-in-the-middle (MITM) and sniffing attacks that can be launched to compromise IPsec VPN tunnels; however, these attacks lie outside of the scope of this book.
I make extensive use of Roy Hills’ ike-scan (http://www.nta-monitor.com/tools/ike-scan/) to test IPsec servers through the ISAKMP service (through UDP port 500). ike-scan is a command-line open source tool that can be run from Windows, MacOS, Linux, and most Unix flavors. Detailed and current ike-scan documentation can be found in the NTA Monitor Wiki athttp://www.nta-monitor.com/wiki/.
IPsec Service Endpoint Enumeration
The first step is to find all the IPsec service endpoints on the
target network. This is best done by sending IKE phase one requests
and observing which systems respond to them. Example 12-1 shows ike-scan enumerating IPsec servers on the
10.0.0.0/24 network. In this
example, I specify the --quiet
option to omit the details of the returned packets from the output,
because I am only interested in finding the VPN servers at this
stage.
$ ike-scan --quiet 10.0.0.0/24
Starting ike-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/ike-scan/>
10.0.0.1 Notify message 14 (NO-PROPOSAL-CHOSEN)
10.0.0.4 Main Mode Handshake returned
10.0.0.11 Main Mode Handshake returned
10.0.0.20 Notify message 14 (NO-PROPOSAL-CHOSEN)
10.0.0.47 Main Mode Handshake returned
10.0.0.50 Main Mode Handshake returned
10.0.0.254 Main Mode Handshake returned
Ending ike-scan 1.9: 256 hosts scanned in 41.126 seconds (6.22 hosts/sec). 5
returned handshake; 2 returned notifyHere I have located a total of seven VPN services, five of which return a main mode handshake, and the remaining two return notify messages. This technique will pick up most VPN servers, but it may not pick up all of them because some may only be configured to respond to IKE requests from specific addresses (such as site-to-site VPN gateways).
Upon identifying accessible IPsec service endpoints, I probe them further using ike-scan. Through such testing I can usually obtain details of usernames, hostnames, supported transports, and other useful information.
IPsec Service Endpoint Fingerprinting
The ike-scan tool can be used to fingerprint accessible IPsec service endpoints. The two techniques used for fingerprinting at this level are as follows:
Analysis of the IKE backoff pattern
Analysis of the Vendor ID (VID)
Example 12-2 shows
ike-scan running against the five
IP addresses that returned a handshake in Example 12-1. I specify the
--showbackoff option to display the
backoff patterns and the --multiline option to split the packet
decode across multiple lines, so they are easy to read.
$ ike-scan --showbackoff --multiline 10.0.0.4 10.0.0.11 10.0.0.47 10.0.0.50
10.0.0.254
Starting ike-scan 1.9 with 5 hosts (http://www.nta-monitor.com/tools/ike-scan/>)
10.0.0.4 Main Mode Handshake returned
HDR=(CKY-R=16b5cca0fcf43a29)
SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds
LifeDuration(4)=0x00007080)
VID=1e2b516905991c7d7c96fcbfb587e46100000004 (Windows-2003-or-XP-SP2)
VID=4048b7d56ebce88525e7de7f00d6c2d3 (IKE Fragmentation)
VID=90cb80913ebb696e086381b5ec427b1f (draft-ietf-ipsec-nat-t-ike-02
)
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.50 Main Mode Handshake returned
HDR=(CKY-R=0af98bad8d200783)
SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=1:modp768 LifeType=Seconds
LifeDuration(4)=0x00007080)
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.4 1 1171708960.343478 0.000000
10.0.0.4 2 1171708961.008901 0.665423
10.0.0.4 3 1171708963.021053 2.012152
10.0.0.4 4 1171708966.976238 3.955185
10.0.0.4 5 1171708974.987006 8.010768
10.0.0.4 6 1171708991.013191 16.026185
10.0.0.4 7 1171709023.016652 32.003461
10.0.0.4 Implementation guess: Windows 2000, 2003 or XP
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.50 1 1171799005.325513 0.000000
10.0.0.50 2 1171799021.346876 16.021363
10.0.0.50 3 1171799037.380750 16.033874
10.0.0.50 4 1171799053.414670 16.033920
10.0.0.50 Implementation guess: Nortel Contivity
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
Ending ike-scan 1.9: 5 hosts scanned in 2.692 seconds (1.86 hosts/sec). 0 returned
handshake; 0 returned notifyThe backoff patterns have identified the systems as Windows, Cisco PIX, Linux, Nortel, and NetScreen. This UDP backoff identification technique is detailed in a white paper by Roy Hills at http://www.nta-monitor.com/posts/2003/01/udp-backoff-whitepaper.pdf.
The other two systems that were discovered in Example 12-1 responded to
ike-scan’s default transform set
with a notify message rather than a handshake, and so they require
specific authentication and transform settings to achieve a handshake.
In Example 12-3 I specify
custom authentication and transform combinations. For the first
system, I use RSA signature authentication (--auth=3), and for the second I use a
custom transform combination of 3DES,MD5,PSK,DH-5 (--trans=5,1,1,5). For further details
regarding alternative transforms to obtain a handshake, see the
ike-scan Wiki (http://www.nta-monitor.com/wiki/).
$ike-scan --auth=3 --showbackoff --multiline 10.0.0.1Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 10.0.0.1 Main Mode Handshake returned HDR=(CKY-R=a0bd270627f4267d) SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080) VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d456da1a80000000018000000 (Firewall-1 NGX) IKE Backoff Patterns: IP Address No. Recv time Delta Time 10.0.0.1 1 1164806997.393873 0.000000 10.0.0.1 2 1164806999.402661 2.008788 10.0.0.1 3 1164807001.402768 2.000107 10.0.0.1 4 1164807003.402999 2.000231 10.0.0.1 5 1164807005.403191 2.000192 10.0.0.1 6 1164807007.412215 2.009024 10.0.0.1 7 1164807009.412454 2.000239 10.0.0.1 8 1164807013.412537 4.000083 10.0.0.1 9 1164807017.412650 4.000113 10.0.0.1 10 1164807021.421858 4.009208 10.0.0.1 11 1164807025.422004 4.000146 10.0.0.1 12 1164807029.422159 4.000155 10.0.0.1 Implementation guess: Firewall-1 4.1/NG/NGX $ike-scan --multiline --trans=5,1,1,5 --showbackoff 10.0.0.20Starting 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
Upon returning a main mode handshake, the backoff patterns identify these systems as Check Point and Solaris. The VID payload for the Check Point system identifies it as Check Point NGX firewall.
Supported Transform Enumeration
You can use ike-scan to enumerate the transform attributes for encryption algorithm, hash algorithm, authentication method, and DH group that are supported by the IPsec server. This allows you to determine if the server supports weak algorithms or methods.
To do this, we use the --trans option to specify a custom
transform. ike-scan allows
multiple --trans options to put
more than one transform in the SA proposal, but when enumerating
acceptable attributes you should specify a single transform. In the
simple form that we will discuss here, the --trans option should specify four numbers
separated by commas, which represent the encryption algorithm, hash
algorithm, authentication method, and (DH) group, respectively. The
values are defined in Appendix A of RFC
2409.
Some common values for these four fields are as follows:
Example 12-4 shows
ike-scan being used against a VPN
server that supports 3DES encryption, SHA1 hashing, PSK
authentication, and DH group 2. The second ike-scan command shows that the server does
not support weaker DES encryption and MD5 hashing with the same
authentication and DH group.
$ike-scan -M --trans=5,2,1,2 10.0.0.254Starting 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 ) VID=4485152d18b6bbcd0be8a8469579ddcc (draft-ietf-ipsec-nat-t-ike-00) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0) VID=4865617274426561745f4e6f74696679386b0100 (Heartbeat Notify) Ending ike-scan 1.9: 1 hosts scanned in 0.048 seconds (20.80 hosts/sec). 1 returned handshake; 0 returned notify $ike-scan -M --trans=1,1,1,2 10.0.0.254Starting 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)
Transform enumeration is a complex topic, and this section has only scratched the surface. For further details regarding this technique, see the ike-scan Wiki (http://www.nta-monitor.com/wiki/.
Investigating Known Weaknesses
Once you have determined the IPsec implementation, you can look up known vulnerabilities using public databases. Table 12-1 shows a number of serious remotely exploitable ISAMKP and IKE issues, as listed in the MITRE CVE list (http://cve.mitre.org).
Date | Notes | |
CVE-2005-2640 | 01/08/2005 | Juniper NetScreen VPN user enumeration |
CVE-2005-2025 | 08/06/2005 | Cisco VPN Concentrator group enumeration |
CVE-2005-1058 | 06/04/2005 | Cisco IOS unauthorized SA establishment vulnerability |
CVE-2005-1057 | 06/04/2005 | Cisco IOS XAUTH authentication bypass vulnerability |
CVE-2004-0369 | 25/08/2004 | Symantec LibKMP ISAKMP buffer overflow |
CVE-2004-0699 | 28/07/2004 | Check Point aggressive mode IKE ASN.1 heap overflow |
CVE-2004-2679 | 16/06/2004 | Check Point NG AI R55 and prior VID fingerprinting bug |
CVE-2004-0469 | 04/05/2004 | Check Point ISAKMP remote buffer overflow |
CVE-2004-0040 | 04/02/2004 | Check Point large certificate request buffer overflow |
CVE-2004-2678 | 04/03/2004 | HP Tru64 UNIX 5.1A and 5.1B IKE digital certificate overflow |
CVE-2003-1320 | 02/09/2004 | SonicWALL 6.4 malformed IKE response handling overflows |
CVE-2002-1623 | 03/09/2002 | Check Point aggressive mode IKE user enumeration |
CVE-2002-2225 | 12/08/2002 | SafeNet VPN client malformed IKE response handling overflows |
CVE-2002-2224 | 12/08/2002 | PGP Freeware 7 malformed IKE response handling overflows |
CVE-2002-2223 | 12/08/2002 | Juniper NetScreen Remote 8.0 malformed IKE response handling overflows |
CVE-2002-0852 | 12/08/2002 | Cisco VPN client IKE payload and long SPI buffer overflows |
Roy Hills has also written a paper detailing some of the common IPsec VPN flaws observed during three years of testing, available from http://www.nta-monitor.com/posts/2005/01/vpn-flaws-whitepaper.pdf.
Denial-of-Service Vulnerabilities
DoS attacks can be launched against VPN servers by sending either malformed IKE packets or exhausting the IKE negotiation slots by sending a high rate of valid IKE requests. These attacks cause in-memory corruption or resource exhaustion, resulting in a DoS condition.
Malformed IKE packet DoS
IKE is a complex protocol, and some implementations cannot cope with malformed IKE packets. ike-scan can create many types of malformed packets and has been used to find at least one exploitable DoS attack as a result (CVE-2005-1802).
Some malformed packet DoS attacks result in memory corruption, which can be very serious because they may allow an attacker to run arbitrary code on the VPN device. If the vulnerable VPN device is also the organization’s firewall, this could give the attacker control of the firewall, which would likely lead to a compromise of the protected network.
The PROTOS test suite (http://www.ee.oulu.fi/research/ouspg/protos/) was used in 2005 to perform comprehensive ISAKMP fuzzing of IKE implementations, uncovering a large number of DoS vulnerabilities in many IKE implementations. For a detailed list of the findings, please see http://www.ee.oulu.fi/research/ouspg/protos/testing/c09/isakmp/.
Negotiation slots exhaustion attack
Most VPN servers have a fixed number of IKE negotiation slots. When a client starts negotiation by sending the first IKE packet, the server will keep the slot open for a considerable time before timing it out. Many VPN servers are vulnerable to a resource exhaustion DoS, which uses up all the available negotiation slots, thus preventing legitimate clients from connecting or rekeying. Also, because IKE runs over UDP, an attacker can forge his source address to make detection and blocking of such attacks difficult.
An example of this issue is CVE-2006-3906. Although this concerns Cisco devices, the underlying issue affects many other vendor implementations. ike-scan can be used to test for negotiation slot resource exhaustion, but as with any DoS testing, it is vital to obtain the permission of the network owner first.
Aggressive Mode IKE PSK User Enumeration
Many remote access VPNs support aggressive mode together with PSK authentication. This combination has inherent security weaknesses, and many vendors implement it in a way that permits user enumeration.
Because of the method that IKE uses to derive the keying material with PSK authentication, it is not possible to use this authentication method with main mode unless the IP address of the initiator is known before the connection is made. Where the client IP address is not known in advance (such as with remote access) and PSK authentication is required, aggressive mode must be used.
Many vendors use IKE aggressive mode with PSK authentication in their default configurations, and some of these will respond differently depending on whether the user is valid or not. Example 12-5 shows an example of this vulnerability on a Juniper NetScreen VPN server, which will only respond if the specified ID is valid. This allows us to confirm that the user [email protected] exists, but [email protected] does not.
$ike-scan --aggressive --multiline [email protected] 10.0.0.254Starting 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 $ike-scan --aggressive --multiline [email protected] 192.168.124.155Starting 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
This technique can be surprisingly effective at discovering valid VPN usernames, especially once you discover the first one and determine the pattern (as many organizations use easily guessable username formats).
It is also possible to obtain valid usernames by sniffing the
connection between the VPN client and server, as the first aggressive
mode packet containing the client ID is sent in the clear. Example 12-6 shows tcpdump being used to sniff an initiator’s
aggressive mode IKE packet from eth0. We can see the ID
[email protected] at the very end of the
packet.
$tcpdump -n -i eth0 -s 0 -X udp port 500listening 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.....@[email protected]..|. 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 ^[email protected] 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 [email protected] 0x0160: 0500 0018 d415 b54b 1884 9dec 0dea 762a .......K......v* 0x0170: 5cdb ce04 278f 31f8 0000 001c 0311 01f4 ...'.1......... 0x0180:726f 7968 696c 6c73 4068 6f74 6d61 696c royhills@hotmail0x0190:2e63 6f6d .com
Aggressive Mode IKE PSK Cracking
Once you have a valid ID, you can use it to obtain a hash from
the server. The hash is made up of several things, but the only
unknown element is the password. Once you obtain the hash, it is
possible to mount an offline dictionary or brute-force grinding attack
to crack the password. Example 12-7 shows how to run
ike-scan with the --pskcrack option to output the PSK hash to
the specified file (netscreen.psk), and then use psk-crack to crack the password.
$ike-scan --aggressive --multiline [email protected] -pskcrack=netscreen. psk 10.0.0.254Starting 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) $psk-crack netscreen.pskStarting 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)
It is also possible to sniff the aggressive mode IKE exchange and crack the PSK using Cain & Abel, a Windows tool available from http://www.oxid.it/cain.html.
Upon compromising the user ID and password, you can use PGPnet, SafeNet, or a similar IPsec VPN client to establish a VPN tunnel and assess the amount of internal network access granted. Michael Thumann has written a step-by-step guide for configuring PGPnet, available as part of his PSK attack paper; you can download it from http://www.ernw.de/download/pskattack.pdf.
Some vendors use initial PSK
authentication for IKE phase one, and then use XAUTH to provide a second level of
authentication. These two authentication phases are often called
“group authentication” and “user authentication,” respectively. The
second authentication mechanism may use RSA SecureID or a similar
two-factor system. Unfortunately, XAUTH relies on the strength of the initial
phase one key exchange, leaving it susceptible to a man-in-the-middle
attack, as described in John Pliam’s paper at http://www.ima.umn.edu/~pliam/xauth/.
Microsoft PPTP
Microsoft’s Point-to-Point Tunneling Protocol (PPTP) uses TCP port 1723 to negotiate and establish the connection and IP protocol 47 (GRE) for data communication. Due to protocol complexity and reliance on MS-CHAP for authentication, PPTPv1 and PPTPv2 are vulnerable to several offline cryptographic attacks, as described in Bruce Schneier’s page dedicated to the protocol at http://www.schneier.com/pptp.html.
PPTP was the most commonly used VPN protocol between Microsoft systems until Windows IPsec support was introduced in Windows 2000. Now it is more of a legacy protocol, and its use is in decline. However, it is still supported, and many networks still use PPTP.
Active PPTP brute-force password grinding can be launched using THC-pptp-bruter (http://www.thc.org/releases.php?q=pptp&x=0&y=0). This tool is fast and has been tested against Windows and Cisco PPTP servers. Example 12-8 shows the tool in use.
$ cat wordlist | thc-pptp-bruter 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)The THC-pptp-bruter tool enumerates the hostname and vendor information as provided by the PPTP service. Even if brute-force password grinding is not effective, hostname and OS platform details are useful.
No other active information leak or user enumeration vulnerabilities have been identified in PPTP to date, and so the service is adequately secure from determined remote attack (if the attacker has no access to the PPTP traffic). However, a number of publicly available network sniffers can compromise PPTP traffic from the wire, including:
SSL VPNs
SSL VPNs are often used as an alternative to IPsec for remote access. They are not suitable for site-to-site VPN links. The main advantage of SSL VPNs is that they only require a web browser on the client side (although they often require additional add-ons or plug-ins) and use the SSL protocol for communications. This means that there is often no need to reconfigure firewalls to allow traffic through or to install additional VPN software on the client.
SSL uses TCP for both connection establishment and data transfer. This is often the standard TCP port 443 (for HTTP over SSL), but it can use any port. Because SSL VPN servers use TCP, Nmap can be used to detect and fingerprint them.
Basic SSL Querying
Once you have identified and fingerprinted an SSL VPN with Nmap, you can probe it using the OpenSSL s_client program (available from http://www.openssl.org) to obtain the server certificate and determine if the server supports weak encryption protocols or features, such as PCT. Example 12-9 shows the OpenSSL tools being used to connect to a Check Point SSL VPN server. I use s_client to obtain the server certificate and show the negotiated cipher. I then use the x509 tool to decode the certificate upon pasting it.
$openssl s_client -connect 172.16.2.2:443CONNECTED(00000003) depth=1 /O=CA/CN=172.16.2.2 verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/CN=172.16.2.2 i:/O=CA/CN=172.16.2.2 1 s:/O=CA/CN=172.16.2.2 i:/O=CA/CN=172.16.2.2 --- Server certificate -----BEGIN CERTIFICATE----- MIIB6TCCAVKgAwIBAgIEa4tFZzANBgkqhkiG9w0BAQUFADAiMQswCQYDVQQKEwJD QTETMBEGA1UEAxMKMTcyLjE2LjIuMjAeFw0wNjA4MjMxNTE0MzFaFw0xNjA4MjAx NTE0MzFaMBUxEzARBgNVBAMTCjE3Mi4xNi4yLjIwgZ0wDQYJKoZIhvcNAQEBBQAD gYsAMIGHAoGBALmjIa5sySoVBv2QdIrN9LpSoL85ugaCFtmVCaCKK5JCGYU7spoo mhioTUrtJjXyu7qnjD88vGXKw34O8pDckcwpmPIA7WgEVHYRWAcHP1HVb8BaPx/v p76mi1ugGI6hSu0OBGjOO+i4QMXscS3CUtxRMUd/zJUlWY0NY8LpE2IJAgEDozsw OTAPBgNVHRMBAQAEBTADAQEAMBYGA1UdJQEBAAQMMAoGCCsGAQUFBwMBMA4GA1Ud DwEBAAQEAwIFoDANBgkqhkiG9w0BAQUFAAOBgQANkp0U5JlpriFzeITIulPndY+g tGPnH2hmZlICUBIyVgohxC+IPJtBnELa9ppasZUdiSt6KPjCuEun138O6+UzPQ8w m5zwg9zUnbdKN0Xoq1JesZtQbojj+rrfSvT5O/Ojnf4e61s57a9fLETY9XC+pwL4 LOtIGyzSCKCLVyCqZA== -----END CERTIFICATE----- subject=/CN=172.16.2.2 issuer=/O=CA/CN=172.16.2.2 --- No client certificate CA names sent --- SSL handshake has read 1097 bytes and written 332 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 1024 bit SSL-Session: Protocol : TLSv1 Cipher : DES-CBC3-SHA Session-ID: Session-ID-ctx: Master-Key: 957CCB0805FEF3242896DDB4C9ADB96FF482B7EA8FCF680B2768AC8D6486 292FCAB327B5599A67FCB0328B78DFA83EAD Key-Arg : None Start Time: 1172515604 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- DONE $openssl x509 -text -noout -----BEGIN CERTIFICATE----- MIIB6TCCAVKgAwIBAgIEa4tFZzANBgkqhkiG9w0BAQUFADAiMQswCQYDVQQKEwJD QTETMBEGA1UEAxMKMTcyLjE2LjIuMjAeFw0wNjA4MjMxNTE0MzFaFw0xNjA4MjAx NTE0MzFaMBUxEzARBgNVBAMTCjE3Mi4xNi4yLjIwgZ0wDQYJKoZIhvcNAQEBBQAD gYsAMIGHAoGBALmjIa5sySoVBv2QdIrN9LpSoL85ugaCFtmVCaCKK5JCGYU7spoo mhioTUrtJjXyu7qnjD88vGXKw34O8pDckcwpmPIA7WgEVHYRWAcHP1HVb8BaPx/v p76mi1ugGI6hSu0OBGjOO+i4QMXscS3CUtxRMUd/zJUlWY0NY8LpE2IJAgEDozsw OTAPBgNVHRMBAQAEBTADAQEAMBYGA1UdJQEBAAQMMAoGCCsGAQUFBwMBMA4GA1Ud DwEBAAQEAwIFoDANBgkqhkiG9w0BAQUFAAOBgQANkp0U5JlpriFzeITIulPndY+g tGPnH2hmZlICUBIyVgohxC+IPJtBnELa9ppasZUdiSt6KPjCuEun138O6+UzPQ8w m5zwg9zUnbdKN0Xoq1JesZtQbojj+rrfSvT5O/Ojnf4e61s57a9fLETY9XC+pwL4 LOtIGyzSCKCLVyCqZA== -----END CERTIFICATE-----Certificate: Data: Version: 3 (0x2) Serial Number: 1804289383 (0x6b8b4567) Signature Algorithm: sha1WithRSAEncryption Issuer: O=CA, CN=172.16.2.2 Validity Not Before: Aug 23 15:14:31 2006 GMT Not After : Aug 20 15:14:31 2016 GMT Subject: CN=172.16.2.2 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:b9:a3:21:ae:6c:c9:2a:15:06:fd:90:74:8a:cd: f4:ba:52:a0:bf:39:ba:06:82:16:d9:95:09:a0:8a: 2b:92:42:19:85:3b:b2:9a:28:9a:18:a8:4d:4a:ed: 26:35:f2:bb:ba:a7:8c:3f:3c:bc:65:ca:c3:7e:0e: f2:90:dc:91:cc:29:98:f2:00:ed:68:04:54:76:11: 58:07:07:3f:51:d5:6f:c0:5a:3f:1f:ef:a7:be:a6: 8b:5b:a0:18:8e:a1:4a:ed:0e:04:68:ce:3b:e8:b8: 40:c5:ec:71:2d:c2:52:dc:51:31:47:7f:cc:95:25: 59:8d:0d:63:c2:e9:13:62:09 Exponent: 3 (0x3) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Key Usage: Digital Signature, Key Encipherment Signature Algorithm: sha1WithRSAEncryption 0d:92:9d:14:e4:99:69:ae:21:73:78:84:c8:ba:53:e7:75:8f: a0:b4:63:e7:1f:68:66:66:52:02:50:12:32:56:0a:21:c4:2f: 88:3c:9b:41:9c:42:da:f6:9a:5a:b1:95:1d:89:2b:7a:28:f8: c2:b8:4b:a7:d7:7f:0e:eb:e5:33:3d:0f:30:9b:9c:f0:83:dc: d4:9d:b7:4a:37:45:e8:ab:52:5e:b1:9b:50:6e:88:e3:fa:ba: df:4a:f4:f9:3b:f3:a3:9d:fe:1e:eb:5b:39:ed:af:5f:2c:44: d8:f5:70:be:a7:02:f8:2c:eb:48:1b:2c:d2:08:a0:8b:57:20: aa:64
Useful data that is enumerated through this process includes the certificate chain details (whether the certificate is self-signed or issued by a given certificate authority), server public key size, and server name (which is an IP address in this case, but is sometimes an internal hostname). Often, other useful information is found in the certificate, such as user email addresses and office details.
Enumerating Weak Cipher Support
Support for weak single DES (56-bit) and export-grade encryption ciphers allows attackers to perform man-in-the-middle session security downgrade attacks—forcing the server and client to communicate using very weak encryption that is easily attacked and compromised. This is a significant issue in large e-commerce and other types of environments, but not so much in smaller networks.
You can use the OpenSSL tools to enumerate the ciphers that a
given server supports by attempting to connect with each possible
cipher and noting those that the server will accept. To do this, you
first obtain a list of all the possible ciphers with the openssl ciphers command, specifying the
cipher list ALL:eNULL to include
all possible ciphers including those with NULL encryption, as shown in
Example 12-10.
$ openssl ciphers ALL:eNULL
ADH-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:ADH-AES128-SHA:DHE-
RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:DHE-DSS-RC4-SHA:EXP1024-DHE-DSS-RC4-SHA:
EXP1024-RC4-SHA:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:
EXP1024-RC4-MD5:EDH-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:
EDH-DSS-DES-CBC3-SHA:EDH-DSS-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:DES-CBC3-SHA:DES-
CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:RC4-SHA:RC4-MD5:EXP-RC4-MD5:ADH-DES-CBC3-SHA:
ADH-DES-CBC-SHA:EXP-ADH-DES-CBC-SHA:ADH-RC4-MD5:EXP-ADH-RC4-MD5:RC4-64-MD5:DES-CBC3-
MD5:DES-CBC-MD5:RC2-CBC-MD5:EXP-RC2-CBC-MD5:RC4-MD5:EXP-RC4-MD5:NULL-SHA:NULL-MD5For more details about the ciphers, you can include the -v (verbose) option to openssl ciphers. This provides a detailed
listing including the protocol type, key exchange, authentication,
encryption, and MAC algorithms used, along with key size restrictions
and whether the algorithm is classed as an export-grade cipher.
Example 12-11, Example 12-12, and Example 12-13 show three ciphers being used to connect to the target SSL server. The ciphers we attempt to use are:
RC4-MD5, which is a
strong cipher using 128-bit RC4 encryption |
EXP-RC4-MD5, which is a
weak cipher using exportable (40-bit) RC4 |
NULL-MD5, which performs
no encryption at all |
$ openssl s_client -cipher RC4-MD5 -connect 172.16.3.18:443
CONNECTED(00000003)
depth=0 /C=GB/ST=Kent/L=Rochester/O=NTA Monitor Ltd/OU=Demo Network/CN=debian31.
demo.nta-monitor.com/[email protected]
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=GB/ST=Kent/L=Rochester/O=NTA Monitor Ltd/OU=Demo Network/CN=debian31
.demo.nta-monitor.com/[email protected]
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=GB/ST=Kent/L=Rochester/O=NTA Monitor Ltd/OU=Demo Network/CN=debian31.
demo.nta-monitor.com/[email protected]
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=GB/ST=Kent/L=Rochester/O=NTA Monitor Ltd/OU=Demo Network/CN=debian31.demo.
nta-monitor.com/[email protected]
i:/C=XY/ST=Snake Desert/L=Snake Town/O=Snake Oil, Ltd/OU=Certificate Authority
/CN=Snake Oil CA/[email protected]
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDRzCCArCgAwIBAgIJAPFPsPPMQepoMA0GCSqGSIb3DQEBBAUAMIGpMQswCQYD
VQQGEwJYWTEVMBMGA1UECBMMU25ha2UgRGVzZXJ0MRMwEQYDVQQHEwpTbmFrZSBU
b3duMRcwFQYDVQQKEw5TbmFrZSBPaWwsIEx0ZDEeMBwGA1UECxMVQ2VydGlmaWNh
dGUgQXV0aG9yaXR5MRUwEwYDVQQDEwxTbmFrZSBPaWwgQ0ExHjAcBgkqhkiG9w0B
CQEWD2NhQHNuYWtlb2lsLmRvbTAeFw0wNTEwMDUxNDMzNDVaFw0xNTEwMDMxNDMz
NDVaMIGuMQswCQYDVQQGEwJHQjENMAsGA1UECBMES2VudDESMBAGA1UEBxMJUm9j
aGVzdGVyMRgwFgYDVQQKEw9OVEEgTW9uaXRvciBMdGQxFTATBgNVBAsTDERlbW8g
TmV0d29yazEmMCQGA1UEAxMdZGViaWFuMzEuZGVtby5udGEtbW9uaXRvci5jb20x
IzAhBgkqhkiG9w0BCQEWFHJveWhpbGxzQGhvdG1haWwuY29tMIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDMoOcf5VsbAeiw5egQ15/KmVZlkAS3yk81Wc1E3qD8
gyPzN8s7KII3Jfb14jEgX3cuZdmrcf8y5Ec1/NR1b7t7pCn+PcWwIqyLMURKDXQf
8mKOx1DZVqE+l06uboBUyCwkEBYQ8eLMFy8sV2UFkTX84rwWWSX3SAOhnWOeCDK5
XQIDAQABo3AwbjAfBgNVHREEGDAWgRRyb3loaWxsc0Bob3RtYWlsLmNvbTA4Bglg
hkgBhvhCAQ0EKxYpbW9kX3NzbCBnZW5lcmF0ZWQgdGVzdCBzZXJ2ZXIgY2VydGlm
aWNhdGUwEQYJYIZIAYb4QgEBBAQDAgZAMA0GCSqGSIb3DQEBBAUAA4GBALiM09Wp
ccfeQsLzT5sE4brai7hVRZo8Gji05HqU+dNz+3kwE3xQ9tsJ9L++i/Al8CqPX3+g
mrgzs9i1MUd0IfjeHvu+hxwEnScujcC03epUQvjirPJ60SPaMbnstOrK4NZqZLvC
MGzXHAe3hcPZ4zvBSRTwfpbHidgJbMq917oI
-----END CERTIFICATE-----
subject=/C=GB/ST=Kent/L=Rochester/O=NTA Monitor Ltd/OU=Demo Network/CN=debian31.
demo.nta-monitor.com/[email protected]
issuer=/C=XY/ST=Snake Desert/L=Snake Town/O=Snake Oil, Ltd/OU=Certificate Authority/
CN=Snake Oil CA/[email protected]
---
No client certificate CA names sent
---
SSL handshake has read 957 bytes and written 231 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID:
Session-ID-ctx:
Master-Key: C24B7A8E03840450C9317FCE5736E545A7A49693C6399C76EEDA38724809C7F55
728517FA4D0067352A432D94A2C5AF5
Key-Arg : None
Start Time: 1181055284
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)$ openssl s_client -cipher EXP-RC4-MD5 -connect 172.16.3.18:443
CONNECTED(00000003)
depth=0 /C=GB/ST=Kent/L=Rochester/O=NTA Monitor Ltd/OU=Demo Network/CN=debian31.
demo.nta-monitor.com/[email protected]
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=GB/ST=Kent/L=Rochester/O=NTA Monitor Ltd/OU=Demo Network/CN=debian31.
demo.nta-monitor.com/[email protected]
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=GB/ST=Kent/L=Rochester/O=NTA Monitor Ltd/OU=Demo Network/CN=debian31.
demo.nta-monitor.com/[email protected]
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=GB/ST=Kent/L=Rochester/O=NTA Monitor Ltd/OU=Demo Network/CN=debian31.demo.
nta-monitor.com/[email protected]
i:/C=XY/ST=Snake Desert/L=Snake Town/O=Snake Oil, Ltd/OU=Certificate Authority/
CN=Snake Oil CA/[email protected]
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDRzCCArCgAwIBAgIJAPFPsPPMQepoMA0GCSqGSIb3DQEBBAUAMIGpMQswCQYD
VQQGEwJYWTEVMBMGA1UECBMMU25ha2UgRGVzZXJ0MRMwEQYDVQQHEwpTbmFrZSBU
b3duMRcwFQYDVQQKEw5TbmFrZSBPaWwsIEx0ZDEeMBwGA1UECxMVQ2VydGlmaWNh
dGUgQXV0aG9yaXR5MRUwEwYDVQQDEwxTbmFrZSBPaWwgQ0ExHjAcBgkqhkiG9w0B
CQEWD2NhQHNuYWtlb2lsLmRvbTAeFw0wNTEwMDUxNDMzNDVaFw0xNTEwMDMxNDMz
NDVaMIGuMQswCQYDVQQGEwJHQjENMAsGA1UECBMES2VudDESMBAGA1UEBxMJUm9j
aGVzdGVyMRgwFgYDVQQKEw9OVEEgTW9uaXRvciBMdGQxFTATBgNVBAsTDERlbW8g
TmV0d29yazEmMCQGA1UEAxMdZGViaWFuMzEuZGVtby5udGEtbW9uaXRvci5jb20x
IzAhBgkqhkiG9w0BCQEWFHJveWhpbGxzQGhvdG1haWwuY29tMIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDMoOcf5VsbAeiw5egQ15/KmVZlkAS3yk81Wc1E3qD8
gyPzN8s7KII3Jfb14jEgX3cuZdmrcf8y5Ec1/NR1b7t7pCn+PcWwIqyLMURKDXQf
8mKOx1DZVqE+l06uboBUyCwkEBYQ8eLMFy8sV2UFkTX84rwWWSX3SAOhnWOeCDK5
XQIDAQABo3AwbjAfBgNVHREEGDAWgRRyb3loaWxsc0Bob3RtYWlsLmNvbTA4Bglg
hkgBhvhCAQ0EKxYpbW9kX3NzbCBnZW5lcmF0ZWQgdGVzdCBzZXJ2ZXIgY2VydGlm
aWNhdGUwEQYJYIZIAYb4QgEBBAQDAgZAMA0GCSqGSIb3DQEBBAUAA4GBALiM09Wp
ccfeQsLzT5sE4brai7hVRZo8Gji05HqU+dNz+3kwE3xQ9tsJ9L++i/Al8CqPX3+g
mrgzs9i1MUd0IfjeHvu+hxwEnScujcC03epUQvjirPJ60SPaMbnstOrK4NZqZLvC
MGzXHAe3hcPZ4zvBSRTwfpbHidgJbMq917oI
-----END CERTIFICATE-----
subject=/C=GB/ST=Kent/L=Rochester/O=NTA Monitor Ltd/OU=Demo Network/CN=debian31.
demo.nta-monitor.com/[email protected]
issuer=/C=XY/ST=Snake Desert/L=Snake Town/O=Snake Oil, Ltd/OU=Certificate
Authority/CN=Snake Oil CA/[email protected]
---
No client certificate CA names sent
---
SSL handshake has read 1167 bytes and written 167 bytes
---
New, TLSv1/SSLv3, Cipher is EXP-RC4-MD5
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : EXP-RC4-MD5
Session-ID:
Session-ID-ctx:
Master-Key: 2491FD85A9546D384D585BFBF888E9AA1AE5E2DBBE31564DFB973FDEF831F563DB
139E49A9342212CBD500E86ACF0C81
Key-Arg : None
Start Time: 1181055019
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)In these two examples, we see that the server at 172.16.3.18 supports both RC4-MD5 and EXP-RC4-MD5, because the server responds
positively to these requests. Example 12-13 shows that the server
does not support NULL-MD5, as the server responds with a failure. In
practice, a penetration tester would use a script to iterate through
all the possible ciphers, then analyze the output to deduce which were
supported.
Known SSL Vulnerabilities
In recent years, a number of serious memory corruption attacks have been identified in numerous SSL implementations (primarily OpenSSL and Microsoft SSL), resulting in remote code execution, as outlined in Table 12-2.
Date | Notes | |
CVE-2007-2218 | 12/06/2007 | Microsoft Secure Channel digital signature parsing overflow |
CVE-2004-0123 | 13/04/2004 | Microsoft ASN.1 heap overflow |
CVE-2003-0719 | 13/04/2004 | Microsoft SSL PCT buffer overflow |
CVE-2003-0818 | 10/02/2004 | Microsoft ASN.1 heap overflow |
CVE-2003-0545 | 04/11/2003 | OpenSSL 0.9.7d and earlier ASN.1 double-free vulnerability |
CVE-2002-0656 | 30/07/2002 | OpenSSL 0.9.7-b2 and 0.9.6d SSL2 client master key overflow |
SSL implementation exploits
MSF has exploit modules for CVE-2000-0719 (Microsoft SSL PCT overflow, MS04-011) and CVE-2003-0818 (Microsoft ASN.1 heap overflow) that can be used to exploit Microsoft IIS services in particular. For the full list of exploit modules that MSF supports in its stable branch, see http://framework.metasploit.com/exploits/list.
In terms of commercial exploitation frameworks, CORE IMPACT supports CVE-2003-0818, CVE-2003-0719, CVE-2003-0545 (OpenSSL 0.9.7d double-free bug), and CVE-2002-0656 (OpenSSL 0.9.7-b2 and 0.9.6d master key overflow); and Immunity CANVAS supports CVE-2003-0818, CVE-2003-0719, and CVE-2002-0656 at the time of this writing.
SSL VPN web interface issues
Upon establishing an SSL session to an SSL VPN server, we can use standard web application testing approaches to test for vulnerabilities including information leak, brute-force password grinding, command execution, and other application-level issues. Known vulnerabilities in F5 and Nortel Networks SSL VPN implementations (effectively web application flaws) are listed in Table 12-3.
VPN Services Countermeasures
The following countermeasures should be considered when hardening VPN services:
Ensure that firewall or VPN gateway appliances have the latest security hotfixes and service packs installed to minimize the risk of a known publicized attack.
Use digital certificates for both IPsec and SSL VPNs to negate reliance on user passwords (preshared keys). When certificates are used for authentication within IPsec, there is no need to use aggressive mode, so main mode should be used.
Consider use of separate VPN and firewall devices. If you use a single device, a compromise can put your entire infrastructure at risk. By using a separate firewall with the VPN server on a DMZ network, you retain control of the inbound VPN traffic and the traffic from the VPN server to the internal network, even if the VPN server is compromised.
Aggressively firewall and filter traffic flowing through VPN tunnels so that network access is limited in the event of a compromise. This point is especially important when providing access to mobile users.
Where possible, limit inbound IPsec security associations to specific IP addresses or network blocks. This ensures that even if an attacker compromises a preshared key, she can’t easily access the VPN.
For IPsec VPN servers, disable weak authentication modes and encryption algorithm support. Don’t rely on client settings to ensure that these features will not be used. You should disable IKE aggressive mode, single DES encryption support, and the use of the AH protocol unless it is combined with ESP.
For SSL VPN servers, ensure that all weak encryption algorithms are disabled. These include single DES (56-bit) and all of the 40-bit export-grade ciphers.
Make sure that SSL VPN servers use a 1,024-bit public key, as a 512-bit key is not sufficiently strong.