Ike-scan User Guide
Contents
- 1 Introduction to ike-scan
- 2 Introduction to IPsec
- 3 IPsec VPN discovery
- 4 IPsec VPN Fingerprinting
- 4.1 Getting an IKE handshake
- 4.2 UDP Backoff Fingerprinting
- 4.3 Vendor ID Fingerprinting
- 4.4 IKE Aggressive Mode
- 4.5 Differences in Behaviour
- 4.5.1 Encryption key length for ciphers with fixed-length keys
- 4.5.2 Variable length attribute encoding for small values
- 4.5.3 Maximum number of transforms inspected
- 4.5.4 ISAKMP Responder Cookie Format
- 4.5.5 Transform attribute ordering
- 4.5.6 Response to malformed or non-compliant IKE packets
- 4.5.7 Supported Attribute Values
- 5 Transform Attribute Enumeration
Introduction to ike-scan
ike-scan is a command-line tool for discovering, fingerprinting and testing IPsec VPN systems. It constructs and sends IKE Phase-1 packets to the specified hosts, and displays any responses that are received.
ike-scan allows you to:
- Send IKE packets to any number of destination hosts, using a configurable output bandwidth or packet rate.
- This is useful for VPN detection, when you may need to scan large address spaces.
- Construct the outgoing IKE packet in a flexible way.
- This includes IKE packets which do not comply with the RFC requirements.
- Decode and display any returned packets.
- Crack aggressive mode pre-shared keys.
- You can use ike-scan to obtain the PSK hash data, and then use psk-crack to obtain the key.
ike-scan is free software, licensed under the GPL. It runs on Windows, Linux and most Unix systems. If you don't already have ike-scan installed on your system, read the installation guide.
Introduction to IPsec
IPsec is a group of protocols rather than a single protocol.
As the diagram on the right shows, there are three main protocols that are used by IPsec: IKE, AH and ESP. IKE provides authentication and key exchange, and AH and ESP are used to send the data over the VPN connection. Some old implementations used "manual IPsec" connections which did not require the use of IKE. However, these are now obsolete and all modern IPsec systems will use IKE. Of these three protocols, IKE is by far the most complex. In this document we are only concerned with the IKE protocol, so we will not cover AH or ESP any further.
The use of IKE to authenticate and exchange key material for an ESP or AH connection is a two-phase process. Phase-1 authenticates the peers and establishes a secure channel (called an IKE SA) for Phase-2, which negotiates the IPsec mode and establishes a secure channel for the AH or ESP traffic called an IPsec SA.
Phase-1 can run in one of two modes: either Main Mode or Aggressive Mode, whereas Phase-2 only has a single mode called Quick Mode. When testing IPsec VPN systems you will be dealing primarily with IKE Phase-1, as Phase-2 is only accessible upon successful authentication. For the remainder of this document, we will only be considering IKE Phase-1.
Main Mode is the standard Phase-1 mode, and all IKE implementations must support it. Main Mode provides identity protection by not passing the identities until the channel is encrypted, and also avoids some denial of service attacks by performing a proof of liveness check before undertaking the expensive Diffie-Hellman exponentiation.
Aggressive Mode is an optional Phase-1 mode, which not all implementations support. It is a simpler exchange, requiring less packets, but is less flexible than Main Mode and also has a number of security weaknesses. The main use of aggressive mode in practice is to allow the use of Pre-Shared Key authentication for remote access solutions. Because of the way the keying material is calculated, it is not possible to use main mode with PSK authentication, unless the IP address of the initiator is known beforehand (which is not normally the case in a remote access situation).
The following RFCs pertain to IPsec:
- RFC 2409 The Internet Key Exchange (IKE)
- RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP)
- RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP
- RFC 2406 IP Encapsulating Security Payload (ESP)
- RFC 2402 IP Authentication Header
We will be making reference to these in this document, especially to the first two which describe the IKE protocol, and the structure of the ISAKMP packet.
IPsec VPN discovery
IPsec VPN servers generally will not be detected by a port scan. This is because they don't listen on any TCP ports, so a TCP port scan won't find them. What is more, they don't normally send ICMP unreachable messages, so a UDP port scan won't pick up IKE on port 500 (a standard port for such connections) and a raw IP scan won't pick up ESP or AH with IP protocols 50 and 51. In addition, the IPsec RFCs specify that incorrectly formatted packets should be ignored, so sending random garbage to UDP port 500 or IP protocols 50 and 51 will not normally elicit any response either.
The effective way to detect IPsec VPN systems is to send a correctly formatted IKE packet to each of the systems that you want to check, and display any IKE responses that are received. This method is able to detect IPsec VPNs that use IKE for key exchange and do not restrict the source IP addresses that they will respond to. In practice, almost all modern IPsec implementations use IKE; the alternative is manual key exchange, which is very rare nowadays. The ike-scan program allows us to send an IKE packet to the specified target systems and display the responses.
Using ike-scan with default settings
To start with, we run ike-scan against the target hosts using the default settings. With these settings, ike-scan will send an IKE Main Mode packet to each target. This packet consists of an ISAKMP header followed by a Security Association (SA) payload. The SA payload contains a single proposal, which in turn contains eight transforms.
The diagram below shows the structure of the IKE Main Mode packet that is send by ike-scan with the default settings.
The structure of the various payloads: ISAKMP Header, SA, Proposal and Transform are defined in RFC 2408.
Each transform contains a number of attributes. The attributes for each of the eight transforms in the default proposal are:
| No. | Encryption Algorithm | Hash Algorithm | Authentication Method | Diffie-Hellman Group | Lifetime (seconds) |
|---|---|---|---|---|---|
| 1 | Triple-DES | SHA1 | Pre-Shared Key | 2 (1024 bit modp) | 28800 |
| 2 | Triple-DES | MD5 | Pre-Shared Key | 2 (1024 bit modp) | 28800 |
| 3 | DES | SHA1 | Pre-Shared Key | 2 (1024 bit modp) | 28800 |
| 4 | DES | MD5 | Pre-Shared Key | 2 (1024 bit modp) | 28800 |
| 5 | Triple-DES | SHA1 | Pre-Shared Key | 1 (768 bit modp) | 28800 |
| 6 | Triple-DES | MD5 | Pre-Shared Key | 1 (768 bit modp) | 28800 |
| 7 | DES | SHA1 | Pre-Shared Key | 1 (768 bit modp) | 28800 |
| 8 | DES | MD5 | Pre-Shared Key | 1 (768 bit modp) | 28800 |
These eight transforms represent the following attribute combinations:
- Encryption algorithm: DES or Triple DES
- Hash algorithm: MD5 or SHA1
- Authentication method: Pre-Shared Key
- Diffie-Hellman group: 1 or 2
- SA Lifetime: 28800 seconds
The listing below shows an example of the ike-scan output for this initial discovery run. In this example we specify the target hosts as the network 10.0.0.0/24, which results in us scanning a total of 256 systems from 10.0.0.0 to 10.0.0.255 inclusive. The -M (multiline) option causes each payload to be shown on a separate line, which makes the output easier to read.
$ ike-scan -M 10.0.0.0/24 Starting ike-scan 1.7 with 256 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.5 Notify message 14 (NO-PROPOSAL-CHOSEN) 10.0.0.6 Main Mode Handshake returned SA=(Enc=3DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation) 10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080) Ending ike-scan 1.7: 256 hosts scanned in 19.22 seconds (13.32 hosts/sec). 17 returned handshake; 32 returned notify
We can see that some systems have responded with a Main Mode Handshake, which means that they are willing to perform IKE negotiation with us, and at least one of our eight transforms is acceptable. We can also see that some other systems have responded with a Notify message, which means either that the system is not willing to negotiate with us (for example, because it only accepts requests from certain source IP addresses), or that none of our transforms are acceptable. Because we are only interested in discovering VPN systems at this stage, we're not concerned whether the systems respond with a handshake or a notify message - either way, they have revealed themselves.
For those systems that respond with a handshake we can see the details of the transform that was accepted in the SA payload, for example Enc=3DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800 which means Triple-DES for encryption, MD5 for the HMAC hash algorithm, Diffie-Hellman group 2 (which is a 1024-bit MODP group), Pre-Shared Key (PSK) authentication, and an SA lifetime of 28800 seconds. Some systems also include a Vendor ID (VID) payload in their response - we'll be looking at these later when we discuss fingerprinting. For systems that respond with a notify message we get the message number and, where the number is known, the name corresponding to that number, for example: Notify message 14 (NO-PROPOSAL-CHOSEN).
Trying Different Transforms
Not all VPN systems respond with a notify message when none of the transforms are acceptable. Some just ignore IKE packets with invalid attributes instead. We must find an acceptable transform in order to get these types of systems to respond.
Each transform consists of a variable number of attributes, but in practice there are only four that we need to consider at this stage: the encryption algorithm (and key length for variable length ciphers), the hash algorithm, the authentication method and the Diffie-Hellman group. The SA lifetime in seconds can safely be left at the default of 28800 because that's almost always acceptable, and there's no need to add any other attributes. The value for each of the four attributes is a 16-bit unsigned number, and therefore has 65536 possible values. If all the values were possible, then there would be a total of 65536^4 (about 18 million trillion) different combinations, and it would be infeasible to try them all. However in practice each attribute only uses a few of the possible values, and some of these values are much more common than others, so it is possible to detect most systems with a reasonable number of transforms. The tables below list the transform attribute values that are defined in the various IPsec RFCs and IETF drafts.
Encryption Algorithm Values
| Value | Encryption Algorithm | Comments |
|---|---|---|
| 1 | DES | Common |
| 2 | IDEA | Very rare |
| 3 | Blowfish | Rare |
| 4 | RC5 | Very rare |
| 5 | Triple DES | Common |
| 6 | CAST | Rare |
| 7 | AES | Common on modern systems, three key lengths: 128, 192 and 256 |
| 8 | Camellia | Very rare |
Hash Algorithm Values
| Value | Hash Algorithm | Comments |
|---|---|---|
| 1 | MD5 | Common |
| 2 | SHA1 | Common |
| 3 | Tiger | Rare |
| 4 | SHA2-256 | Rare |
| 5 | SHA2-384 | Rare |
| 6 | SHA2-512 | Rare |
Authentication Method Values
| Value | Authentication Method | Comments |
|---|---|---|
| 1 | Pre-Shared Key | Common |
| 2 | DSS Signature | Rare |
| 3 | RSA Signature | Common |
| 4 | RSA Encryption | Rare |
| 5 | Revised RSA Encryption | Rare |
| 6 | ElGamel Encryption | Rare |
| 7 | Revised ElGamel Encryption | Rare |
| 8 | ECDSA Signature | Rare |
| 64221 | Hybrid Mode | Common on Checkpoint systems |
| 65001 | XAUTH | Common on remote access systems |
Diffie-Hellman Group Values
| Value | Diffie-Hellman Group | Comments |
|---|---|---|
| 1 | MODP 768 | Common |
| 2 | MODP 1024 | Common |
| 3 | EC2N 155 | Rare |
| 4 | EC2N 185 | Rare |
| 5 | MODP 1536 | Common |
| 6 | EC2N 163 | Rare |
| 7 | EC2N 163 | Rare |
| 8 | EC2N 183 | Rare |
| 9 | EC2N 183 | Rare |
| 10 | EC2N 409 | Rare |
| 11 | EC2N 409 | Rare |
| 12 | EC2N 571 | Rare |
| 13 | EC2N 571 | Rare |
| 14 | MODP 2048 | Rare |
| 15 | MODP 3072 | Rare |
| 16 | MODP 4096 | Rare |
| 17 | MODP 6144 | Rare |
| 18 | MODP 8192 | Rare |
Looking at the common values in the transform attribute tables, we can see that there are five encryption algorithms (AES counts as three, because it has three different key lengths), two hash algorithms, four authentication methods, and three Diffie-Hellman groups. This gives a total of 120 combinations of these common values, which is low enough to allow us to try each one.
ike-scan allows the authentication method in the default transform set to be changed with the --auth option. Alternatively, a custom transform can be specified with the --trans option, and it is possible to use this option multiple times to add an arbitrary number of transforms to the SA payload. Because it's possible to specify an arbitrary number of transforms with the --trans option, we might be tempted to specify all one hundred and twenty combinations. However that won't work, because many IPsec implementations place a limit on the number of transforms that they will process. The maximum number varies from one manufacturer to another, one example being Checkpoint which accepts a maximum of twenty transforms. Therefore, we must perform multiple scans, with each one containing a reasonable number of transforms.
The first thing to try, is to use the standard transform set but change the authentication method from Pre-Shared Key to one of the other common options. You can use the --auth option to do this, for example ike-scan --auth=3 10.0.0.0/24 will use the standard transform set with the authentication method set to RSA Signature instead of the default Pre-Shared key for each transform. This method is surprisingly effective at discovering VPN servers that won't respond to the standard transform set.
The recommended alternative authentication methods to try are:
- --auth=3: RSA Signature
- --auth=64221: Hybrid Mode, commonly used on Checkpoint systems.
- --auth=65001: XAUTH, commonly used on many remote access systems.
An alternative and more thorough method is to create a script to generate all the transform combinations, and then use xargs to run ike-scan as many times as necessary with a specified maximum number of transforms. Here is an example shell script that could be used to generate a list of transform options containing every possible combination of the commonly used transform attributes:
#!/bin/sh
#
# Encryption algorithms: DES, Triple-DES, AES/128, AES/192 and AES/256
ENCLIST="1 5 7/128 7/192 7/256"
# Hash algorithms: MD5 and SHA1
HASHLIST="1 2"
# Authentication methods: Pre-Shared Key, RSA Signatures, Hybrid Mode and XAUTH
AUTHLIST="1 3 64221 65001"
# Diffie-Hellman groups: 1, 2 and 5
GROUPLIST="1 2 5"
#
for ENC in $ENCLIST; do
for HASH in $HASHLIST; do
for AUTH in $AUTHLIST; do
for GROUP in $GROUPLIST; do
echo "--trans=$ENC,$HASH,$AUTH,$GROUP"
done
done
done
done
If this script is called generate-transforms.sh, we could use it to run ike-scan with up to eight transforms in each run as follows:
generate-transforms.sh | xargs --max-lines=8 ike-scan 10.0.0.0/24
This will result in 15 ike-scan runs, each against 256 targets.
Other Useful Options for VPN Discovery
You may find the following ike-scan options useful when performing VPN server discovery, especially if you are dealing with a large list of target IP addresses:
- --retry - specifies the maximum number of times to try an unresponsive host. The default is three, but you can normally reduce it to one unless there is packet loss between you and the target. Reducing this speeds up the scanning process.
- --bandwidth - specifies the outbound bandwidth usage. You can increase this to speed up the scanning if you have sufficient bandwidth, or decrease it to make the scanning more stealthy. The default output bandwidth is 56000 bits per second.
- --random - randomises the order in which the targets are scanned. This can make the scanning a little less obvious, especially if you are scanning very large ranges.
IPsec VPN Fingerprinting
Once we have discovered the VPN servers, the next step is to find out as much information about them as we can. Using the fingerprinting techniques detailed in this section, we can often determine the vendor and model of the VPN server, and sometimes we can also determine the software version number. This information can be valuable to an attacker, because they could use it to search for known vulnerabilities associated with that brand of VPN, or download the appropriate VPN client software and try username and password guessing. The VPN server is also often the firewall, in which case the fingerprinting will identify the firewall brand as well.
Often just one fingerprinting technique is sufficient to identify a VPN server implementation. However, when we cannot get a definite match with any one technique, the combination of methods will usually give us enough information to determine the implementation, or at least make an educated guess.
Getting an IKE handshake
The first step is to try to get an IKE handshake from each of the systems that we want to fingerprint, and note down the acceptable transform attributes. If we've already got a handshake from the discovery stage, then we can just note down the transform attributes from the SA payload. However, if all we've got is a notify message, then we must try to get a handshake before we can proceed with the fingerprinting.
The process of trying to obtain a handshake involves trying all combinations of transform attributes until we find one which is acceptable. This is the same process as we used in the discovery phase to try to detect VPN systems which did not respond to the standard transform set, the only difference is that we are dealing with a much smaller number of systems at this stage and can therefore try more attributes.
Once we've obtained an IKE handshake, we will use the acceptable transform in future scans. For example, if the SA payload returned was SA=(Enc=AES KeyLength=256 Hash=SHA1 Group=5:modp1536 Auth=PSK LifeType=Seconds LifeDuration=28800), we would specify --trans=7/256,2,1,5. Note that for variable-keylength ciphers like AES, you specify the keylength as "/bits" after the encryption algorithm.
UDP Backoff Fingerprinting
IKE uses the UDP transport, which is unreliable. It must therefore implement its own retransmission strategy to cope with lost packets. Because the IPsec RFCs don't specify the precise details of the backoff strategy, each IPsec vendor generally invents their own scheme. We can use these different backoff strategies to fingerprint the VPN server.
To obtain the details of the backoff pattern, we send an IKE packet with an acceptable transform, but do not reply to any of the VPN server's responses. The server will assume that the packet got lost, and will re-try according to its backoff strategy. By recording the time when each of the packets from the server is received, and calculating the difference between the times, we can determine the backoff strategy and thus fingerprint the server.
A normal Main Mode packet exchange between a VPN client and server looks like this:
If we use ike-scan in backoff fingerprinting mode, it will not respond to the packets from the server, which will cause the server to retransmit. In this case, the packet exchange will look like this:
ike-scan allows us to obtain the backoff pattern from a VPN server, and it will also try to match the pattern received against a database of known patterns. To perform backoff fingerprinting we need to specify the --showbackoff option, which will cause ike-scan to record the times of all the response packets, and to wait for up to sixty seconds after the last packet to ensure that it has seen all of them before displaying the details of the times and trying to match the pattern. Because we need to wait until all the packets have been sent, and then wait an extra minute to be sure that no more are coming, the backoff fingerprinting process takes between one and two minutes.
Below are four examples of backoff fingerprinting in action. The meanings of the columns in the backoff patterns are:
- IP Address - The IP address of the VPN server that this pattern relates to.
- No. - The number of the response packet from this host with the first response packet being 1.
- Recv time - The time when this response packet was received. This time is shown as the number of seconds and microseconds since midnight on Jan 1, 1970 (the Epoch used by Unix systems).
- Delta Time - The difference between the time when this response packet was received and the time when the previous response packet was received in seconds. This is always zero for the first response packet.
$ ike-scan -M --trans=5,2,1,2 --showbackoff 10.0.0.1 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080) IKE Backoff Patterns: IP Address No. Recv time Delta Time 10.0.0.1 1 1121251508.773117 0.000000 10.0.0.1 2 1121251510.772474 1.999357 10.0.0.1 3 1121251512.775259 2.002785 10.0.0.1 4 1121251514.777952 2.002693 10.0.0.1 5 1121251516.780746 2.002794 10.0.0.1 6 1121251518.783504 2.002758 10.0.0.1 7 1121251520.786298 2.002794 10.0.0.1 8 1121251524.791781 4.005483 10.0.0.1 9 1121251528.797329 4.005548 10.0.0.1 10 1121251532.802822 4.005493 10.0.0.1 11 1121251536.808370 4.005548 10.0.0.1 12 1121251540.813874 4.005504 10.0.0.1 Implementation guess: Firewall-1 4.1/NG/NGX
$ ike-scan -M --trans=5,1,1,2 --showbackoff 10.0.0.2 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.2 Main Mode Handshake returned SA=(Enc=3DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation) IKE Backoff Patterns: IP Address No. Recv time Delta Time 10.0.0.2 1 1121252105.954742 0.000000 10.0.0.2 2 1121252113.946698 7.991956 10.0.0.2 3 1121252121.944037 7.997339 10.0.0.2 4 1121252129.945608 8.001571 10.0.0.2 Implementation guess: Cisco VPN Concentrator
$ ike-scan -M --trans=5,2,1,2 --showbackoff 10.0.0.3 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.3 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080) IKE Backoff Patterns: IP Address No. Recv time Delta Time 10.0.0.3 1 1121252226.796701 0.000000 10.0.0.3 2 1121252242.606684 15.809983 10.0.0.3 3 1121252258.419674 15.812990 10.0.0.3 4 1121252274.559528 16.139854 10.0.0.3 Implementation guess: Nortel Contivity
$ ike-scan -M --trans=5,2,3,2 --showbackoff 10.0.0.4 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.4 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=RSA_Sig 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\n) IKE Backoff Patterns: IP Address No. Recv time Delta Time 10.0.0.4 1 1121252667.865074 0.000000 10.0.0.4 2 1121252668.971457 1.106383 10.0.0.4 3 1121252670.973030 2.001573 10.0.0.4 4 1121252674.972099 3.999069 10.0.0.4 5 1121252682.966370 7.994271 10.0.0.4 6 1121252698.968920 16.002550 10.0.0.4 7 1121252730.975145 32.006225 10.0.0.4 Implementation guess: Windows 2000, 2003 or XP
We can see that each of the four servers responded with a different pattern, and in each case we were able to determine the brand of VPN server. You may also have noticed that some of the servers have responded with additional "VID" payloads - these are Vendor ID payloads, and we'll be looking at them in the next section.
The times that we observe may be a fraction of a second different from the values used by the server in the backoff algorithm due to latency differences, scheduling delays on the server, and other issues. However, if we round the observed delays to the nearest second, we can see that the four patterns are:
- Checkpoint Firewall-1 - 0, 2, 2, 2, 2, 2, 2, 4, 4, 4, 4, 4
- Cisco VPN Concentrator - 0, 8, 8, 8
- Nortel Contivity - 0, 16, 16, 16
- Microsoft Windows - 0, 1, 2, 4, 8, 16, 32
You can see other examples of backoff patterns in the ike-backoff-patterns file, which is included in the ike-scan distribution.
Vendor ID Fingerprinting
The IKE protocol defines an optional Vendor ID payload (VID), which can be included in an IKE Phase-1 packet, and may contain arbitrary data. This payload is used by vendors to exchange details about proprietary extensions or to recognise their own implementations. The data in the payload is often the MD5 hash of a text string.
We can use any Vendor ID payloads that are sent by the VPN server to help identify it. Ike-scan will automatically display any Vendor ID payloads that it receives, and will attempt to match them against a database of known Vendor ID patterns. It also allows Vendor ID payloads to be added to the outgoing packet with the --vendor option.
Not all VPN servers send Vendor IDs, and those that do sometimes only send them if they receive a specific Vendor ID first, or only in IKE Aggressive Mode (which we'll be covering later in this article). If a VPN server doesn't send a Vendor ID, and you think that you know what the server is, then it's worth sniffing the outbound traffic from the associated VPN client application with tcpdump or ethereal to observe any Vendor IDs sent by that client. Sending that Vendor ID to the server will often make it respond with its own Vendor ID.
The example below shows the Vendor ID payloads returned by a Microsoft Windows 2003 IPsec server. The first VID is the most interesting one: this is the MD5 hash of the string MS NT5 ISAKMPOAKLEY with the number four appended as a 32-bit value in big-endian format. All Microsoft IPsec implementations send the same hash, but different windows versions append different numbers to the end of the hash, which allows us to narrow down the software version. The values that ike-scan knows about are:
- 00000002 - Windows 2000 Server
- 00000003 - Windows XP SP1
- 00000004 - Windows 2003 Server and Windows XP SP2
- 00000005 - Windows Vista and Windows 2008 server
$ ike-scan --trans=5,2,3,2 --multiline 10.0.0.4
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.4 Main Mode Handshake returned
SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=RSA_Sig 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\n)
Here is an example of Checkpoint Firewall-1. The version in this example will only return a Vendor ID payload if it is sent a VID payload containing f4ed19e0c114eb516faaac0ee37daf2807b4381f, which is the first twenty bytes of the VID that all Checkpoint products send. We see that the server returns a Vendor ID which not only identifies it as Checkpoint Firewall-1 (because the VID starts with the same twenty bytes), but also identifies the exact software version in the remaining twenty bytes. In this case, the target is running Checkpoint Firewall-1 NG AI R54. See http://www.nta-monitor.com/news/checkpoint2004/index.htm for more details on the structure of this Vendor ID.
$ ike-scan --trans=5,2,1,2 --vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f --multiline 10.0.0.1
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.1 Main Mode Handshake returned
SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c000000000000000018a00000 (Firewall-1 NG AI R54)
Finally, this example shows the Vendor ID payload returned by a Nortel Contivity (now known as Nortel VPN router). This system will only return a VID payload if it is sent one in the request packet. However, unlike Checkpoint, Nortel doesn't care what Vendor ID it is given, so we send a single byte with the value zero. The Vendor ID that is returned consists of four bytes which are the text string BNES followed by the number nine as a 32-bit value in big-endian format. BNES stands for Bay Networks Enterprise Switch, which was the name of the product before Bay Networks were acquired by Nortel, and the number at the end probably represents the software version.
$ ike-scan --trans=5,2,1,2 --vendor=00 --multiline 10.0.0.3
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.3 Main Mode Handshake returned
SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
VID=424e455300000009 (Nortel Contivity)
IKE Aggressive Mode
All the examples up to now have used IKE Main Mode, which should be supported by all VPN servers. Some VPN servers, especially remote access servers, also support aggressive mode. If a server supports aggressive mode, then we can use that to obtain additional information. Aggressive mode is typically used for remote access with pre-shared key authentication.
The diagram below shows the structure of the first IKE aggressive mode packet. You can see that it is more complex than the Main Mode packet shown earlier, because it contains three additional payloads:
- Key Exchange - The Diffie-Hellman public value
- Nonce - Random data to prove liveness and prevent replay
- Identification - The identity of the peer
Because the first aggressive mode packet contains the Diffie-Hellman public value, only a single Diffie-Hellman group may be specified in the proposal. Therefore the standard ike-scan proposal is different when aggressive mode is used - it only contains four transforms rather than the eight transforms in a normal main mode packet because it only uses Diffie-Hellman Group 2.
The four transforms in the ike-scan standard Aggressive Mode proposal are:
| No. | Encryption Algorithm | Hash Algorithm | Authentication Method | Diffie-Hellman Group | Lifetime (seconds) |
|---|---|---|---|---|---|
| 1 | Triple-DES | SHA1 | Pre-Shared Key | 2 (1024 bit modp) | 28800 |
| 2 | Triple-DES | MD5 | Pre-Shared Key | 2 (1024 bit modp) | 28800 |
| 3 | DES | SHA1 | Pre-Shared Key | 2 (1024 bit modp) | 28800 |
| 4 | DES | MD5 | Pre-Shared Key | 2 (1024 bit modp) | 28800 |
These four transforms represent the following attribute combinations:
- Encryption algorithm: DES or Triple DES
- Hash algorithm: MD5 or SHA1
- Authentication method: Pre-Shared Key
- Diffie-Hellman group: 2
- SA Lifetime: 28800 seconds
It can sometimes be difficult to get a VPN server to handshake with IKE aggressive mode, because many servers won't respond unless a valid ID is supplied in the identification payload. This ID is typically a username or email address. In fact, only responding to valid IDs introduces a username enumeration vulnerability because it allows us to distinguish between valid and invalid usernames.
The example below shows an aggressive mode response from a Cisco VPN Concentrator. For this system, we need to specify a valid username in the identity payload (although for more recent versions of Cisco Concentrator software this is not the case). We can see that the response contains several interesting payloads:
- ID - The server uses its IP address in the identity payload. If the server is behind a NAT device, then this will reveal its real address.
- Hash - This is an MD5-based HMAC hash. We can use this to mount an offline password cracking attack.
- VIDs - A total of five Vendor ID payloads are returned, which identify the system as a Cisco VPN Concentrator.
$ ike-scan --aggressive --multiline --id=finance_group 10.0.0.2
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.2 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.2)
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 next example shows an aggressive mode response from a Cisco PIX firewall. We don't need to supply a valid ID with this system. This system uses its hostname for the ID, and the name chosen gives us a clue as to the make and model of the system. If we look carefully, we can also see that the VPN Concentrator puts its payloads in a different order to the PIX: the VPN Concentrator sends SA, Key Exchange, Nonce, ID, Hash, VID x 5; whereas the PIX sends SA, VID x 4, Key Exchange, ID, Nonce, Hash. This difference indicates that although the two systems are from the same manufacturer, they are based on different underlying IPsec implementations. We'll be looking at these sorts of different responses in the next section.
$ ike-scan --trans=7/256,2,1,2 --aggressive --multiline 192.168.91.2
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
192.168.91.2 Aggressive Mode Handshake returned
SA=(Enc=AES KeyLength=256 Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
VID=09002689dfd6b712 (XAUTH)
VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection)
VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
VID=11f27f551d0760dfc9ca6f5670fe5291
KeyExchange(128 bytes)
ID(Type=ID_FQDN, Value=pix520-internet.company.com)
Nonce(20 bytes)
Hash(20 bytes)
You can specify a custom transform set for aggressive mode in the same way as for aggressive mode. But there are two important differences for aggressive mode transforms, both of which are related to the fact that the first packet contains the key exchange payload,
The first difference is that all aggressive mode transforms should use the same Diffie-Hellman group. This is a limitation of aggressive mode; RFC 2409 states: Due to message construction requirements the group in which the Diffie-Hellman exchange is performed cannot be negotiated. ike-scan will allow you to specify different Diffie-Hellman groups, which may be useful if you want to determine how the server responds to non compliant payloads. But for normal usage, make sure that all transforms have the same Diffie-Hellman group when using aggressive mode.
The second difference is that you will need to specify the Diffie-Hellman group to use for the key exchange payload for groups other than the default group 2. This is achieved with the --dhgroup option. ike-scan allows you to use any Diffie-Hellman group for the key exchange payload, but for normal usage always specify the Diffie-Hellman group with the --dhgroup option for aggressive mode, and ensure that the group number is the same as the one specified in the transforms.
Differences in Behaviour
We've already discussed differences in the behaviour of different IPsec implementations with backoff strategies, Vendor IDs and the ordering of payloads in the IKE packet. This section outlines some other examples of differences that can be used to fingerprint IPsec implementations.
Some of the differences are things that are not fully defined, others are because the RFCs can be interpreted in a number of different ways, and one or two just make no sense at all.
The IKE_Implementation_Analysis section contains examples of several IKE implementations, and includes details of how they respond to different IKE packets. This can be a useful resource if you are trying to fingerprint a system which does not have a unique backoff pattern or vendor ID.
Encryption key length for ciphers with fixed-length keys
The key length transform attribute is used for encryption algorithms with variable length keys, for example AES. It is not meant to be used for encryption algorithms with fixed length keys such as DES and Triple-DES, and RFC 2409 says: _This [key length] attribute MUST NOT be used when the specified Encryption Algorithm uses a fixed length key_. We find that different implementations handle this situation differently: some reject the transform, some accept the transform but ignore the key length attribute, and some accept the transform and return the invalid keylength attribute.
The examples below show the response of three different systems to a key length attribute specifying the absurd value of twenty seven with the triple DES cipher, which uses a fixed length key. Looking at the responses, we see the following behaviour:
- Checkpoint Firewall-1 - Accepts the transform and returns the same key length in its response,
- Cisco VPN Concentrator - Does not respond at all,
- Nortel Contivity - Responds with a No Proposal Chosen notify message,
- Windows 2003 - Accepts the transform but does not return a key length attribute.
$ ike-scan --trans=5/27,2,1,2 -M 10.0.0.1 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 KeyLength=27 LifeType=Seconds LifeDuration(4)=0x00007080)
$ ike-scan --trans=5/27,1,1,2 -M 10.0.0.2 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
$ ike-scan --trans=5/27,2,1,2 -M 10.0.0.3 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.3 Notify message 14 (NO-PROPOSAL-CHOSEN)
$ ike-scan --trans=5/27,2,3,2 -M 10.0.0.4 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.4 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=RSA_Sig 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\n)
Variable length attribute encoding for small values
There are two types of transform attribute: basic attributes which take a 16-bit value, and variable attributes whose value can be of any size. An example of a variable attribute is the lifetime in seconds.
Ike-scan will always send the lifetime in seconds as a variable attribute, but the server sometimes returns this as a basic attribute if the value will fit in 16 bits. This is allowed by RFC 2409, which says: Variable length attributes MAY be encoded as basic attributes if their value can fit into two octets.
If a basic attribute is returned then ike-scan will display the value as a decimal number, for example LifeDuration=28800. If a variable attribute is returned, then ike-scan will display the number of bytes followed by the value as a hexadecimal number, for example LifeDuration(4)=0x00007080.
Using the default lifetime of 28800 seconds, which will fit in 16 bits, we find that the Cisco VPN Concentrator and Cisco PIX return a basic attribute for the lifetime, but Checkpoint Firewall-1, Nortel Contivity and Windows 2003 return a variable length attribute.
The [transform attribute ordering] section details how you can use the advanced transform specification to specify an attribute as either fixed or variable length, and to give a variable length attribute any value length.
Maximum number of transforms inspected
The number of transforms that can be contained in an SA proposal is only limited by the maximum IP datagram size of 64 kilobytes, which allows approximately 1800 transforms. However, most IPsec implementations will only process a limited number of transforms. The limit is implementation dependent, but is generally far lower than the theoretical limit.
This limitation of the number of supported transforms is allowed by RFC 2409, which states: There is no limit on the number of offers the initiator may send to the responder but conformant implementations MAY choose to limit the number of offers it will inspect for performance reasons.
We can determine the maximum number of transforms that a given implementation will inspect by sending a number of unacceptable transforms followed by an acceptable transform, and varying the number of unacceptable transforms to find the point at which the VPN server no longer accepts the proposal. Because we will often need to generate hundreds of transforms, it is easiest to use a simple Perl script to generate the ike-scan options. For example, if we know that the VPN server will accept a transform with attributes Enc=3DES, Hash=SHA1, Auth=PSK, Group=2, and will not accept a transform with attributes Enc=IDEA, Hash=Tiger, Auth=RSA_enc, Group=5, we could send a proposal with 99 invalid transforms followed by a valid transform to the VPN server at 10.0.0.1 with: ike-scan `perl -e 'print "--trans=2,3,4,5 " x 99 . "--trans 5,2,1,2";'` 10.0.0.1. If the VPN server responds with a handshake, then we know that it supports at least 100 transforms.
For example, with Checkpoint Firewall-1, we find that it will only inspect a maximum of twenty transforms. The example below shows the response from a Firewall-1 systems first with twenty transforms (nineteen unacceptable followed by one acceptable) and then with twenty one.
$ ike-scan -M `perl -e 'print "--trans=2,3,4,5 " x 19 . "--trans 5,2,1,2";'` 10.0.0.1 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
$ ike-scan -M `perl -e 'print "--trans=2,3,4,5 " x 20 . "--trans 5,2,1,2";'` 10.0.0.1 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.1 Notify message 14 (NO-PROPOSAL-CHOSEN)
ISAKMP Responder Cookie Format
The response from the server will contain a Responder Cookie. This is a 64-bit number, which should be unique and non-predictable.
Most VPN servers create responder cookies which appear to be random to the client. However, some implementations' responder cookies show a recognisable structure.
For example, Checkpoint Firewall-1 will always use a zero-valued cookie when sending a notification message:
$ ike-scan -M 172.16.2.2
Starting ike-scan 1.8.4 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2 Notify message 14 (NO-PROPOSAL-CHOSEN)
HDR=(CKY-R=0000000000000000, msgid=d44ad35f)
With Cisco PIX, the first 32-bits of the responder cookie are constant for a given PIX system:
$ ike-scan -M 10.0.38.226
Starting ike-scan 1.8.4 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
217.205.38.226 Main Mode Handshake returned
HDR=(CKY-R=ff553a4d65572e8a)
SA=(Enc=3DES Hash=SHA1 Group=1:modp768 Auth=PSK LifeType=Seconds LifeDuration=28800)
$ ike-scan -M 10.0.38.226
Starting ike-scan 1.8.4 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
217.205.38.226 Main Mode Handshake returned
HDR=(CKY-R=ff553a4d957eb6cb)
SA=(Enc=3DES Hash=SHA1 Group=1:modp768 Auth=PSK LifeType=Seconds LifeDuration=28800)
Transform attribute ordering
The attributes within a transform may be in any order. By default, ike-scan will send the attributes in the order:
- Encryption Algorithm
- Hash Algorithm
- Authentication Method
- Diffie-Hellman Group
- Key Length (if specified)
- LifeType (Seconds or KB)
- LifeDuration
However, it is possible to send any combination of attributes in any order by using the advanced form of the --trans option as follows:
--trans=(attr1=val1, attr2=val2, ...)
The parentheses are special to some shells (for example bash), so you may need to enclose the option value in quotes like this: --trans="(attr1=val1, attr2=val2)"
You can specify as many attributes as you like in this way, including no attributes at all.
Each attribute may be encoded as a basic attribute, which has a 16-bit value giving a value range from 0 to 65,535; or as a variable attribute, which has a variable length value. To specify a basic attribute, give the value as a decimal value; to specify a variable attribute, give the value in hexadecimal with a leading 0x. The value length for a variable-length attribute depends on the length of the hex value specified after the 0x, so 0xff, 0x00ff, 0x0000ff and 0x000000ff would all specify the value 255 but encoded as one, two, three and four bytes respectively.
The table below shows the attributes that are defined in RFC 2409.
| Attribute Value | Attribute Name | Basic or Variable |
|---|---|---|
| 1 | Encryption Algorithm | Basic |
| 2 | Hash Algorithm | Basic |
| 3 | Authentication Method | Basic |
| 4 | Group Description | Basic |
| 5 | Group Type | Basic |
| 6 | Group Prime/Irreducible Polynomial | Variable |
| 7 | Group Generator One | Variable |
| 8 | Group Generator Two | Variable |
| 9 | Group Curve A | Variable |
| 10 | Group Curve B | Variable |
| 11 | Life Type | Basic |
| 12 | Life Duration | Variable |
| 13 | PRF | Basic |
| 14 | Key Length | Basic |
| 15 | Field Size | Basic |
| 16 | Group Order | Variable |
Here are some examples using CheckPoint NGX as the VPN server. We first send a single transform with attributes Enc=3DES, Hash=SHA1, Auth=RSA, DHgroup=2. Then we send the same attributes but in the reverse order: DHgroup=2, Auth=RSA, Hash=SHA1, Enc=3DES. Both orderings are accepted by the VPN server (most implementations don't care about the attribute ordering), and this system returns the attributes in the same order that they were specified.
$ ike-scan -r 1 --trans="(1=5,2=2,3=3,4=2)" -M 172.16.2.2
172.16.2.2 Main Mode Handshake returned
HDR=(CKY-R=3cf85f6cc2c81a2e)
SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024)
VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d454c90cf0000000018000000 (Firewall-1 NGX)
$ ike-scan -r 1 --trans="(4=2,3=3,2=2,1=5)" -M 172.16.2.2
172.16.2.2 Main Mode Handshake returned
HDR=(CKY-R=2c6daa3aafdf0b12)
SA=(Group=2:modp1024 Auth=RSA_Sig Hash=SHA1 Enc=3DES)
VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d454c90ee0000000018000000 (Firewall-1 NGX)
Here is another example using the AES encryption algorithm, which has a variable key length. For variable key length ciphers, the keylength is specified as a separate attribute. In this example, we specify a keylength of 256 bits.
$ ike-scan --trans="(1=7,14=256,2=2,3=3,4=2)" -M 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2 Main Mode Handshake returned
HDR=(CKY-R=1796d77085c73fd7)
SA=(Enc=AES KeyLength=256 Hash=SHA1 Auth=RSA_Sig Group=2:modp1024)
VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45e59b160000000018000000 (Firewall-1 NGX)
Here is a final example, which adds a lifetime of 123 seconds and a lifetime of 456 KB. The lifetime specifications each consist of a pair of attributes: one to specify the lifetype (either seconds or KB) and another to specify the life duration. We specify the durations as four-byte variable-length attributes, with the values represented in hex (123 = 0x7b and 456=0x1c8).
$ ike-scan --trans="(1=7,14=256,2=2,3=3,4=2,11=1,12=0x0000007b,11=2,12=0x000001c8)" -M 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2 Main Mode Handshake returned
HDR=(CKY-R=a5cf73ed86ee10af)
SA=(Enc=AES KeyLength=256 Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x0000007b LifeType=Kilobytes LifeDuration(4)=0x000001c8)
VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45e59c380000000018000000 (Firewall-1 NGX)
Response to malformed or non-compliant IKE packets
Different implementations vary in their response to malformed or non-compliant IKE packets. ike-scan can generate a large number of different malformed and non-compliant packets, and we can use some of these to fingerprint the target system.
You should be very careful when sending malformed packets because it is possible to crash the target server, thus causing a denial of service. All of the methods shown below have been found to be safe on the products that I've tested, but there can be no guarantees.
The IKE Implementation Analysis section shows how systems that I've tested respond to these malformed and non-compliant packets, and is a useful resource when trying to fingerprint devices.
Note that some firewalls and IDS systems may see some of these malformed packets as attack signatures and block them. The SmartDefense functionality in CheckPoint Firewall-1/VPN-1 is an example of a system that can do this.
In general, a target system will respond in one of the following ways to a malformed or non-compliant packet:
- Ignore the packet, and not respond in any way;
- Respond normally, ignoring or not checking the part in error; or
- Respond with a notify message.
Some examples of malformed or non-compliant IKE packets are:
- No Acceptable Transforms - An SA payload where none of the transforms have acceptable attributes.
- Bad IKE version - The version number in the ISAKMP header is not valid. Either the major version, the minor version or both may be invalid.
- Invalid DOI - The Domain of Interpretation in the SA header is not valid.
- Invalid Situation - The Situation in the SA header is not valid.
- Invalid Initiator Cookie - The initiator cookie is zero.
- Invalid Flags - The flags field in the ISAKMP header is not valid.
- Invalid Protocol - The protocol ID in the proposal payload is invalid.
- Invalid SPI - The size of the SPI in the proposal payload is not valid.
- Non-Zero Reserved Fields - The reserved (must be zero or MBZ) fields in the IKE packet are non-zero.
The table below shows the ike-scan options that can be used to create these IKE packets, and what the RFCs say about how an implementation should handle them.
| Type | ike-scan options | RFC Ref |
|---|---|---|
| No Acceptable Transforms | --trans=2,3,5,3 | RFC 2408 Sec 5.4: If the Security Association Proposal is not accepted ... An Informational Exchange with a Notification payload containing the NO-PROPOSAL-CHOSEN message type MAY be sent to the transmitting entity |
| Bad IKE version | --headerver=0x30 --headerver=0x11 --headerver=0x31 |
RFC 2408 Sec 5.2: Check the Major and Minor Version fields to confirm they are correct. If the Version field validation fails ... An Informational Exchange with a Notification payload containing the INVALID-MAJOR-VERSION or INVALID-MINOR-VERSION message type MAY be sent to the transmitting entity |
| Invalid DOI | --doi=2 | RFC 2408 Sec 5.4: Determine if the Domain of Interpretation (DOI) is supported ... If the DOI determination fails ... An Informational Exchange with a Notification payload containing the DOI-NOT-SUPPORTED message type MAY be sent to the transmitting entity |
| Invalid Situation | --situation=2 | RFC 2408 Sec 5.4: Determine if the given situation can be protected. If the Situation determination fails ... An Informational Exchange with a Notification payload containing the SITUATION-NOT-SUPPORTED message type MAY be sent to the transmitting entity |
| Invalid Initiator Cookie | --cookie=0000000000000000 | RFC 2408 Sec 5.2: Verify the Initiator and Responder "cookies". If the cookie validation fails ... An Informational Exchange with a Notification payload containing the INVALID-COOKIE message type MAY be sent to the transmitting entity' |
| Invalid Flags | --hdrflags=255 | RFC 2408 Sec 5.2: Check the Flags field to ensure it contains correct values. If the Flags field validation fails ... An Informational Exchange with a Notification payload containing the INVALID-FLAGS message type MAY be sent to the transmitting entity |
| Invalid Protocol | --protocol=2 | RFC 2408 Sec 5.5: Determine if the Protocol is supported. If the Protocol-ID field is invalid ... An Informational Exchange with a Notification payload containing the INVALID-PROTOCOL-ID message type MAY be sent to the transmitting entity |
| Invalid SPI | --spisize=32 | RFC 2408 Sec 5.5: Determine if the SPI is valid. If the SPI is invalid ... An Informational Exchange with a Notification payload containing the INVALID-SPI message type MAY be sent to the transmitting entity |
| Non-Zero Reserved Fields | --mbz=255 | RFC 2408 Sec 5.3: Verify the RESERVED field contains the value zero. If the value in the RESERVED field is not zero ... An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be sent to the transmitting entity |
Supported Attribute Values
Different implementations often have different acceptable values for transform attributes, and this can be used to assist fingerprinting in some situations. For example, one system may support both DES and Triple-DES encryption algorithms while another may support only Triple-DES. Attribute support fingerprinting is complicated by the fact that most implementations allow the user to configure the acceptable transform attributes, so the fact that a given implementation does not support DES encryption may mean either that the implementation cannot support it, or that the user has disabled that cipher.
One example where supported attributes can assist the fingerprinting process is when an implementation supports a recent attribute value, such as the AES cipher, SHA-512 hash algorithm or Diffie-Hellman group 5. If you already know the type of system that you are dealing with, then the presence of a recent algorithm can indicate the minimum version number. However, because the user may disable attribute values, you cannot determine anything from the absence of recent algorithm support.
For example, if a system has been fingerprinted as Cisco PIX and is observed to support AES, then it must be version 6.3 or later because AES support was added in version 6.3.
Another example where attribute support can help is where an implementation supports an unusual algorithm such as Twofish encryption. Some algorithms are sufficiently rare that they can narrow down the possible implementations to just one or two possibilities.
Transform Attribute Enumeration
Sometimes it is necessary to determine the list of transform attributes that the IPsec VPN server will accept for IKE Phase-1. For example, you may need to determine if the VPN server supports any weak encryption ciphers that are prohibited by the information security policy.
Attributes
The following four transform attributes are mandatory, and therefore must be present in all transforms:
- Encryption algorithm
- Hash Algorithm
- Authentication Method
- Diffie-Hellman Group
The following two attributes are sometimes required:
- Key Length (only for variable length ciphers)
- SA lifetime in seconds (encoded as two attributes: Life Type and Life Duration)
These attributes are defined in RFC 2409, Appendix A.
