Anatomy of IPsec. Check the strength of the legendary protocol

In today's world, various VPN technologies are used everywhere. Some (for example, PPTP) are recognized as unsafe with time and gradually die off, others (OpenVPN), on the contrary, increase turnover every year. But the undisputed leader and the most recognizable technology for creating and maintaining secure private channels is still IPsec VPN. Sometimes with Pentest, you can detect a seriously protected network with only the 500th UDP port sticking out. Everything else can be closed, patched and filtered securely.

In such a situation, it may be thought that there is nothing special to do here. But it's not always the case. In addition, the idea is widespread that IPsec is impregnable even in default configurations and provides an adequate level of security. This is the situation today and look at the case. But first, in order to effectively deal with IPsec, you need to figure out what it is and how it works. This will do!

Ipsec inside

Before going directly to IPsec itself, it would be nice to remember what types of VPNs there are. There are a lot of VPN classifications, but we will not dive deep into network technologies and take the simplest. Therefore, we will divide the VPN into two main types - site-to-site VPN connections (they can also be called permanent) and remote access VPN (RA, they are temporary).
')
The first type is used for the permanent connection of various network islands, for example, the central office with many scattered branches. Well, RA VPN is a scenario where a client connects for a short period of time, gets access to certain network resources and disconnects safely after shutdown.

We will be interested in the second option, since in the event of a successful attack, it is possible to immediately gain access to the internal network of the enterprise, which is quite a serious achievement for the pentester. IPsec, in turn, allows both site-to-site and remote access VPN to be implemented. What is this technology and what components does it consist of?

It is worth noting that IPsec is not one, but a whole set of different protocols that provide transparent and secure data protection. The specificity of IPsec is that it is implemented at the network level, complementing it in such a way that everything happens unnoticed for subsequent levels. The main difficulty is that in the process of establishing a connection, two participants of a secure channel need to agree on a fairly large number of different parameters. Namely, they must authenticate each other, generate and exchange keys (and through an untrusted environment), and also agree on which protocols to encrypt data.

It is for this reason that IPsec consists of a protocol stack, the responsibility of which lies in ensuring the establishment of a secure connection, its operation and its management. The entire process of establishing a connection involves two phases: the first phase is used to ensure the secure exchange of ISAKMP messages already in the second phase. ISAKMP (Internet Security Association and Key Management Protocol) is a protocol that serves to negotiate and update security policies (SA) between participants in a VPN connection. These policies specify exactly what protocol to encrypt (AES or 3DES) and how to authenticate (SHA or MD5).

The two main phases of IPsec

So, we found out that the participants first need to agree on the mechanisms by which a secure connection will be created, so now the IKE protocol comes into play. IKE (Internet Key Exchange) is used to form an IPsec SA (Security Association, the very same security policy), to put it simply - coordinating the work of participants in a secure connection. Through this protocol, the participants agree on which encryption algorithm will be applied, on which algorithm the integrity check will be performed and how to authenticate each other. It should be noted that today there are two versions of the protocol: IKEv1 and IKEv2. We will be interested only in IKEv1: although the IETF (The Internet Engineering Task Force) was first introduced in 1998, it is still very often used, especially for RA VPN (see Figure 1).


Fig. 1. Cisco ASDM VPN Wizard

As for IKEv2, its first sketches were made in 2005, it was fully described in RFC 5996 (2010), and only at the end of last year it was declared for the role of the Internet standard (RFC 7296). More details about the differences between IKEv1 and IKEv2 can be found in the sidebar. Having dealt with IKE, we return to the phases of IPsec. During the first phase, participants authenticate each other and agree on the parameters for setting up a special connection, intended only for exchanging information about the desired encryption algorithms and other details of the future IPsec tunnel. The parameters of this first tunnel (also called the ISAKMP tunnel) are determined by the ISAKMP policy. First of all, the hashes and encryption algorithms are consistent, then the Diffie-Hellman (DH) keys are exchanged, and only then the determination of who is who is occurs. That is, the last is the authentication process, either by PSK or by RSA key. And if the parties came to an agreement, then an ISAKMP tunnel is established, through which the second phase of IKE already passes.

In the second phase, those already trusting each other agree on how to build a main tunnel for transmitting data directly. They offer each other the options specified in the transform-set parameter, and, if they agree, raise the main tunnel. It is important to emphasize that after its establishment, the auxiliary ISAKMP tunnel does not go anywhere - it is used to periodically update the SA of the main tunnel. As a result, IPsec in some way installs not one, but two whole tunnels.

How to process data

Now a few words about transform-set. It is necessary, after all, to somehow encrypt the data going through the tunnel. Therefore, in a typical configuration, transform-set is a set of parameters that explicitly indicate how the package should be processed. Accordingly, there are two options for such data processing - these are the ESP and AH protocols. ESP (Encapsulating Security Payload) deals directly with data encryption, and can also provide data integrity checks. AH (Authentication Header), in turn, is only responsible for authenticating the source and checking the integrity of the data.

For example, the command `crypto ipsec transform-set SET10 esp-aes` will indicate to the router that the transform-set with the name` SET10` should work only over the ESP protocol and with AES encryption. Looking ahead, I’ll say that hereinafter we will use Cisco routers and firewalls as targets. Actually, everything is more or less clear with ESP, its business is to encrypt and thus ensure confidentiality, but then why is AH needed? AH provides data authentication, that is, it confirms that this data came from the person with whom we contacted and were not changed along the way. It provides what else is sometimes called anti-replay protection. In modern networks, AH is practically not used, everywhere you can find only ESP.

Parameters (they are also SA), selected to encrypt information in an IPsec tunnel, have a lifetime after which they must be replaced. By default, the lifetime IPsec SA is 86,400 s, or 24 h.

As a result, participants received an encrypted tunnel with parameters that suit them all, and send data streams to be encrypted there. Periodically, in accordance with the lifetime, the encryption keys for the main tunnel are updated: the participants again connect via the ISAKMP tunnel, go through the second phase and re-establish the SA.

IKEv1 Modes

We looked at the first approximation of the basic mechanics of IPsec, but we need to focus on a few more things. The first phase, among other things, can operate in two modes: main mode or aggressive mode. We have already considered the first option above, but we are interested in just the aggressive mode. In this mode, three messages are used (instead of six in main-mode). In this case, the one who initiates the connection, gives all his data at once - what he wants and what he can, as well as his part of the exchange of DH. The counterpart then immediately completes its part of the DH generation. As a result, in this mode, in fact, only two stages. That is, the first two stages of the main mode (matching hashes and DH exchange), as it were, are compressed into one. As a result, this mode is much more dangerous for the reason that a lot of technical information in plaintext comes in response. And most importantly, the VPN gateway can send a password hash that is used for authentication in the first phase (this password is often referred to as a pre-shared key or PSK).

Well, all subsequent encryption occurs without changes, as usual. Why then is this mode still in use? The fact is that it is much faster, about two times. Of particular interest to the pentester is the fact that the aggressive mode is very often used in IPsec VPN RA. Another small feature of RA IPsec VPN when using aggressive mode: when a client accesses the server, it sends an identifier (group name) to it. Tunnel group name (see Figure 2) is the name of the entry that contains the set of policies for this IPsec connection. This is one of the features specific to Cisco equipment.


Fig. 2. Tunnel group name

Two phases were not enough

It would seem that the result is a not so simple scheme of work, but in fact it is still a bit more complicated. Over time, it became clear that only one PSK is not enough to ensure security. For example, in the event that an employee’s workstation was compromised, the attacker could immediately access the entire internal network of the enterprise. Therefore, phase 1.5 was developed right between the first and second classical phases. By the way, this phase is usually not used in a standard site-to-site VPN connection, but is used in the organization of remote VPN connections (our case). This phase contains two new extensions - Extended Authentication (XAUTH) and Mode-Configuration (MODECFG).

XAUTH is an additional user authentication within the IKE protocol. This authentication is sometimes referred to as the second IPsec factor. Well, MODECFG is used to transmit additional information to the client, it can be an IP address, a mask, a DNS server and so on. It can be seen that this phase simply complements the previously discussed ones, but its utility is undoubted.

IKEv2 vs IKEv1

Both protocols work on the UDP port with number 500, but are incompatible with each other, the situation is not allowed, that at one end of the tunnel there should be IKEv1, and at the other - IKEv2. Here are the main differences of the second version from the first:

- In IKEv2, there are no more such concepts as aggressive or main modes.
- In IKEv2, the term first phase is replaced with IKE_SA_INIT (two message exchange, which provides for the negotiation of encryption / hashing protocols and DH key generation), and the second phase - by IKE_AUTH (also two messages that implement authentication itself).
- Mode Config (what was called phase 1.5 in IKEv1) is now described directly in the protocol specification and is an integral part of it.
- In IKEv2 added an additional mechanism to protect against DoS-attacks. Its essence is that before responding to each request to establish a secure connection (IKE_SA_INIT) IKEv2, the VPN gateway sends a cookie to the source of such a request and waits for a response. If the source replied - everything is in order, you can start generating DH with it. If the source does not respond (in the case of a DoS attack, this is the case, this technique resembles a TCP SYN flood), then the VPN gateway just forgets about it. Without this mechanism, with every request from anyone, the VPN gateway would try to generate a DH-key (which is a fairly resource-intensive process) and would soon encounter problems. As a result, due to the fact that all operations now require confirmation from the other side of the connection, a large number of half-open sessions cannot be created on the device under attack.

We reach the line

Finally, having understood the peculiarities of the work of IPsec and its components, you can proceed to the main point - to practical attacks. The topology will be fairly simple and at the same time close to reality (see Fig. 3).


Fig. 3. General network layout

The first step is to determine the presence of an IPsec VPN gateway. You can do this by scanning the ports, but there is a small feature here. ISAKMP uses the UDP protocol, port 500, and meanwhile the default scan using Nmap only affects TCP ports. And the result will be a message: `All 1000 scan filtered ports on 37.59.0.253 are filtered`.

It seems that all ports are filtered and there are no open ports, as it were. But having executed the command

nmap -sU --top-ports=20 37.59.0.253 Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-21 12:29 GMT Nmap scan report for 37.59.0.253 Host is up (0.066s latency). PORT STATE SERVICE 500/udp open isakmp 

make sure that this is not the case and we really have a VPN device.

Attack the first phase

Now we will be interested in the first phase, the aggressive mode and authentication using the pre-shared key (PSK). In this scenario, as we remember, the VPN device or the responding party sends the hashed PSK to the initiator. One of the most well-known utilities for testing the IKE protocol is ike-scan, it is part of the Kali Linux distribution. Ike-scan allows you to send IKE messages with different parameters and, accordingly, decode and parse response packets. We try to probe the target device:

 root@kali:~# ike-scan -M -A 37.59.0.253 0 returned handshake; 0 returned notify 

Fig. 4. Ike-scan aggressive mode

The key `-A` indicates that you should use the aggressive mode, and` -M` says that the results should be displayed line by line (multiline), for easier reading. It is seen that no result was obtained. The reason is that you need to specify the same identifier, the name of the VPN group. Of course, the ike-scan utility allows you to set this identifier as one of its parameters. But as long as it is unknown to us, we take an arbitrary value, for example, 0000.

 root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Aggressive Mode Handshake returned 

Fig. 5. Ike-scan ID

This time we see that the answer was received (see Fig. 5) and we were given quite a lot of useful information. The rather important part of the information received is the transform-set. In our case, it says that “Enc = 3DES Hash = SHA1 Group = 2: modp1024 Auth = PSK”.

All these parameters can also be specified for the ike-scan utility using the `--trans` key. For example, `--trans = 5,2,1,2` will say that the 3DES encryption algorithm, HMAC-SHA hashing, PSK authentication method and the second type of DH group (1024-bit MODP). You can view the table of correspondence values ​​at this address Add another key (`-P`) in order to directly output the payload of the packet, or more precisely the PSK hash.

 root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 -P 

Fig. 6. Ike-scan payload

We overcome the first difficulties

It would seem that the hash was received and you can try to tweak it, but it's not that simple. Once upon a time, in 2005, on some pieces of hardware, Cisco had a vulnerability: these devices gave the hash only if the attacker passed the correct ID value. Now, of course, it is almost impossible to meet such equipment and the hashed value is always sent, regardless of whether the attacker sent the correct ID value or not. Obviously, it is pointless to bruise the wrong hash. Therefore, the first task is to determine the correct ID value in order to get the correct hash. And this will help us recently discovered vulnerability.

The fact is that there is a slight difference between the responses during the initial exchange of messages. In short, using the correct group name makes four attempts to continue establishing the VPN connection, plus two encrypted packets of the second phase. While in the case of an incorrect ID, only two packets arrive in response. As you can see, the difference is quite significant, so SpiderLabs (the author of the no less interesting Responder tool) first developed PoC, and then IKEForce utility to exploit this vulnerability.

What is the strength of IKE

You can install IKEForce in an arbitrary directory by running the command

 git clone https://github.com/SpiderLabs/ikeforce 

It works in two main modes - the `-e` (enumeration) calculation mode and` -b` (bruteforce) bruteforce mode. We will reach the second when we look at the attacks on the second factor, but now we’ll deal with the first one. Before you begin the ID definition process directly, you need to set the exact transform-set value. We have already defined it before, so we will specify it with the `-t 5 2 1 2` option. As a result, the process of finding the ID will look like this:

 python ikeforce.py 37.59.0.253 -e -w wordlists/group.txt -t 5 2 1 2 

Fig. 7. IKEForce enumeration

As a result, we quickly managed to get the correct ID value (Fig. 7). The first step is passed, you can move on.

Get PSK

Now it is necessary, using the correct group name, to save the PSK-hash to a file, you can do this with the help of ike-scan:

 ike-scan -M -A --id=vpn 37.59.0.253 -Pkey.psk 

And now, when the correct ID value has been selected and we managed to get the correct PSK hash, we can finally start offline brute force. There are a lot of variants of such bruteforce - this is both the classic psk-crack utility, and John the Ripper (with the jumbo-patch), and even oclHashcat, which, as we know, allows using the power of the GPU. For simplicity, we will use psk-crack, which supports both direct brute force and dictionary attack:

 psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk 

Fig. 8. Psk-crack

But even successfully recovering PSK (see Figure 8) is only half the battle. At this stage, you need to remember what's next for XAUTH and the second factor IPsec VPN.

Dealing with the second IPsec factor

So, let me remind you that XAUTH is an additional protection, the second factor of authentication, and it is in phase 1.5. There can be several XAUTH options - this is both a RADIUS check, one-time passwords (OTP), and a regular local user base. We will focus on the standard situation when a local user base is used to test the second factor. Until recently, there was no publicly available tool for XAUTH brute-force. But with the advent of IKEForce, this task received a worthy solution. Running bruteforce XAUTH is quite simple:

 python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+]Program started in XAUTH Brute Force Mode [+]Single user provided - brute forcing passwords for user: admin [*]XAUTH Authentication Successful! Username: admin Password: cisco 

Fig. 9. IKEForce XAUTH

All the previously found values ​​are indicated: ID (key `-i`), restored PSK (key` -k`) and intended login (key `-u`). IKEForce supports both coarse enumeration of a login, and enumeration of a list of logins, which can be specified with the `-U` parameter. In case of possible selection locks there is an option `-s`, which allows to reduce the speed of brute force. By the way, several quite good dictionaries are included with the utility, especially useful for establishing the value of the ID parameter.

Enter the internal network

Now that we have all the data, the last step remains - the actual penetration into the local network. For this we need some VPN client, of which there are a great many. But in the case of Kali, you can easily use the pre-installed VPNC. In order for it to work, you need to correct one configuration file - `/ etc / vpnc / vpn.conf`. If not, then you need to create and fill in a number of obvious parameters:

IPSec gateway 37.59.0.253
IPSec ID vpn
IPSec secret cisco123
IKE Authmode psk
Xauth Username admin
Xauth password cisco

Here we see that absolutely all the data found in the previous steps was used - the value of the ID, PSK, login and password of the second factor. After that, the connection itself is a single command:

 root@kali:~# vpnc vpn 

Disabling is also quite simple:

 root@kali:~# vpnc-disconnect 

You can test the connection using the command `ifconfig tun0`.

Fig. 10. VPNC

How to build a reliable protection

Protection against the attacks examined today must be comprehensive: patches must be installed on time, strong pre-shared keys must be used, which, if possible, should be replaced with digital certificates. Password policy and other obvious elements of information security also play their important role in ensuring security. It should be noted that the situation is gradually changing, and over time only IKEv2 will remain.

What is the result

We covered the RA IPsec VPN audit process in detail. Yes, of course, this task is far from trivial. You need to take a lot of steps, and each of them can face difficulties, but if successful, the result is more than impressive. Getting access to the internal resources of the network opens up a wide scope for further action. Therefore, those who are responsible for protecting the network perimeter should not rely on ready-made default templates, but carefully consider each security layer. Well, for those who carry out pentests, the discovered 500th UDP port is a reason to conduct an in-depth analysis of IPsec VPN security and, possibly, to get quite good results.



First published in Hacker Magazine # 196.
Author: Alexander Dmitrenko, PENTESTIT

Subscribe to "Hacker"

• Site materials
• Paper version
• Hacker on iOS / iPad
• "Hacker" on Android