Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
Cryptography Lab 2: IPSec isolation Objectives - Build MS DC and enable IPSec. - Create a file server that is isolated (using IPSec) such that replies are not given unless a computer is authenticated in the domain as an administrator.
Network Configuration
Isolated with IPsec
First Setup Attempt We tried to go through this lab 2 weeks ago, and the following explanations relate to what we did at that time. However, we were not successful in that even though logons and file transfers worked, IPSec was not appropriately applied, as we were not able to find any ESP packets in the traffic between the isolated server and the client. We have chosen to keep the material that we had started to include in this report at that time (i.e. before we realized that the captures did not meet the lab requirements). We have since tried several different configuration approaches – and sometimes asked either you or other people to review our settings – but we have still not figured out why the IPSec policies did not seem to be applied as expected. You will find our explanations regarding how we have eventually configured the domain and server for IPSec and what we have been able to achieve in a latter section.
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
Configuration of IP Security Policy for the Domain (AD KDC)
In the “Default Domain Security Settings” screen, a new IP Security Policy is created for the AD and enabled: “Papi IP Security Policy” and will be applied to the domain or part of it as we will set later. This Security Policy is based on a “full required IPSec” setting: all communications – except ICMP traffic – from and to the specified isolated server’s IP address are required to be encrypted with IPSec. We therefore use a filter that restrains the application of the “required encryption” policy to the isolated file server (10.200.200.21). With this setup, the hosts were able to logon, exchange Kerberos tickets but we were not able to capture encrypted IPSec packets. Obviously we all missed something in the setup since it should have worked the way you set it up.
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
Last Setup Attempt For this last attempt, we have tried to apply a straightforward process by removing all previous policies, configurations and AD customization: we reverted the situation back to a working Kerberos-based AD without IPSec. We then applied the existing “Secure Server (require security)” default policy to the file server, as follows:
Configuration of IP Security Policy for the Domain (AD KDC)
As you can see, the Secure Server policy is assigned for the domain as a default policy. Here is how it is configured:
3 rules are defined: “All ICMP Traffic” ensures that all ICMP communications are allowed even if no authentication / encryption are provided (for convenience). “” is a built-in rule related to Kerberos. “Traffic with File Server” dictates the server isolation and is detailed below.
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
In the rule’s properties, we have defined a specific filter that targets traffic with the file server which we want to isolate:
Here’s how the filter is set:
As you can see, this filter applies to all inbound and outbound (since the filter is mirrored) traffic with 10.200.200.21, which is the file server, for any protocol. Note: since the “All ICMP Traffic” rule is more specific (i.e. it specifically targets the ICMP protocol and not “any protocol”), it will have a higher priority and therefore “bypass” the “Traffic with File Server” rule. Excellent discussion and use of screen captures.
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
Let’s take a look at the rule’s action settings:
We applied the “Require Security” action. As you can see below, this rule requires all traffic (targeted by the defined filter i.e. with the file server) to be secured using IPSec encryption (ESP) and integrity. This screen also allows us to define the algorithms we want the file server to use (preferably) for IPSec communications, such as 3DES symmetric encryption and SHA1 hashes for integrity checks.
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
We now switch to the Active Directory configuration screen. As you can see below, “PROCESSI-JI33O” is the domain controller (KDC).
We have created a new Organizational Unit, named “Papi Domain Computers”, for our domain’s computers. These include “CONCORDI-J0CCG4” which is a simple client and “CONCORDITK97TO”, the file server. We then assign the previously defined Default Domain Policy to this Organizational Unit as you can see below:
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
Negotiation of Key Exchange Security Methods is configured as follows:
With these configuration settings for the Default Domain Policy and the Active Directory structure, we were not able to achieve logons and file transfer featuring ESP encryption even though our logons do use the ISAKMP protocol of the IPSec suite for identity protection. Therefore, we will in the next section discuss Wireshark captures provided by Indrajit Maitra’s group as they seemed to have got things working the right way (e.g. the captures contain IKE/ESP packets). We thought that, even though our setup did not properly function, it was still interesting to analyze and comment traffic generated by another group. traffic in a first part discuss the Wireshark capture of our configured domain’s network logons traffic and in a second part analyze the capture of an encrypted file transfer involving the teacher’s computers accessible as part of a demo domain configuration.
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
Analysis of Network Traffic Note: The captures used for analysis were provided by Indrajit Maitra’s group as we were not able to obtain the desired traffic but still wished to discuss ISAKMP and ESP traffic.
User Logons to Domain Logons to the domain are processed the same way then with Kerberos only: the client sends AS-REQ and then TGS-REQ messages to obtain granting tickets to the domain and its resources. However, this time the domain is set up to use IPSec, which provides integrity and encryption to IP traffic. Therefore, the first step here is to establish an IPSec connection between, say, the client and the domain controller it wishes to log on. Such an association is called an IPSec Security Association (SA) and defines the transforms (AH, ESP) that will be applied to the traffic and the algorithms that will be put in place to provide these transforms. Internet Key Exchange (IKE) is the protocol in charge of setting up these SA’s for IPSec communications. Currently version 1 is used and it runs on UDP port 500 (for the initiator and the responder of the IPSec SA establishment). Shared (secret) symmetric session keys are set up with Diffie-Hellman. Internet Security Association and Key Management Protocol (ISAKMP) is the very cryptographic key exchange protocol which provides the basis for the establishment of such IPSec SA’s, which must be set up prior to any secured IPSec communication. It is supported by Microsoft Windows IPSec Services. It manages the negotiation of security parameters (hash and encryption algorithms), primary host authentication and the key exchange itself. There are 2 phases in the ISAKMP process (diagram on next page):
Phase 1: Identity Protection (2 modes: “Main” or “Aggressive”) o Negotiation and establishment of an IKE SA for encrypted phase 2 communications; o Diffie-Hellman key exchange of symmetric key; o Remote host primary authentication.
Phase 2: Quick Mode o Set up of one or more IPSec SA’s (i.e. binding between two hosts defined by their identity and the selected AH/ESP transforms) for further communications (generally one for inbound and one for outbound traffic).
We will now analyze the traffic generated by these two phases upon establishment of an IPSec secure channel between the connecting client and the domain controller.
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
The diagram below (courtesy Ari Muittari at Nokia Networks) summarizes the ISAKMP Security Association establishment process and its goal:
Let’s now focus on the Identity Protection phase which establishes the initial IKE SA that will be used to set up one or more IPSec transform SA’s.
IKE/ISAKMP Main Mode (phase 1): Establishment of an IKE SA The entire ISAKMP/IKE phase 1 is completed with 8 messages (or 4 exchanges) when the “Main” mode is used (“Aggressive” mode is faster but contains serious security flaws), including the eventual deletion of the established IKE SA, as shown below (courtesy Anton Rager at Avaya Security):
Indrajit Maitra’s group network was set up as follows: • Domain Controller: 10.100.100.30 • Client: 10.100.100.31 • Isolated Server: 10.100.100.33
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
Excellent use of references in your discussion. Interesting use of another caputure to analyze. Excellent use of references to add to the analysis of the packet capture you examines.
Etienne Janot Vincent Gilbert Francis Wong •
Lab2 ISS 533 IPSec
February 17th, 2007
Message 1: Security Association (initiation)
This is the first message which is sent by the initiator (in this case the KDC) to the responder (the client in this case) to establish an IKE Security Association.
a b c
d
e
(a) The initiator sends its cookie (sort of identification hash) to the responder. (b) This message’s payload is Security Association data: algorithms proposals, identification host name (for negotiation). (c) The Message ID is null during ISAKMP phase 1. (d) The Proposal payload contains several transform (algorithms combinations) proposals, as we will see later. (e) The Vendor ID payload identifies the implementation vendor.
Excellent discussion.
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
Let’s take a closer look at the Proposal payload. We can see that it contains several Transform payloads (4 in this case), which each –even though only the first one is shown here – describe algorithms choices for integrity and encryption as well as other security parameters:
a
b
b
We focused here on the first (hence preferred) Transform proposal. (a) Some of the security parameters: Encryption: 3DES-CBC Hash (MAC): SHA Diffie-Hellman group description Aunthentication Method: Pre-shared (b) The initiator’s host Full Qualified Domain Name (FQDN): “
[email protected]” As you can see, the host name is sent in the clear (no encryption yet), as well as the algorithms proposals (~ cipher specs).
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
Now let’s take a quick look at the Vendor ID payloads:
These successive payloads describe the vendor implementation (for internal and external compliance). They are sent in the clear and can therefore be used to target particular implementations’ weaknesses. Good.
Etienne Janot Vincent Gilbert Francis Wong •
February 17th, 2007
Lab2 ISS 533 IPSec
Message 2: Security Association (response)
This is the first answer to the initiator’s ISAKMP Identity Protection (phase 1) message.
a
b
c
(a) The responder sends its cookie to the initiator, which cookie is also included in the message (and the next ones). (b) Apparently, on our case, the responder chose the Transform proposal #1 and therefore sends the agreed upon details again. (c) The responder sends its user FQDN (not seen here), in the clear again: “
[email protected]” Now, both sides have agreed upon the specifications of the IKE/ISAKMP SA to set up and can therefore proceed to the Diffie-Hellman key exchange. Excellent analysis.
Etienne Janot Vincent Gilbert Francis Wong •
Lab2 ISS 533 IPSec
February 17th, 2007
Messages 3 & 4: Key Exchange
This is the first Key Exchange message: the initiator sends the responder his 1024 bit public key (Diffie-Hellman exchange) and 160 bits of nonce data.
a
b c b c (a) This message’s first payload is Key Exchange data. (b) The Key Exchange payload contains the initiator’s Diffie-Hellman public key. (c) The initiator sends 20 bytes (160 bits) of nonce data.
The fourth message is the responder’s response to the initiator’s message. It contains the same fields, with a specific public key and nonce data. As we can see, the keys are sent in the clear, as usual for Diffie-Hellman key exchanges, and are thus subject to Man-In-The-Middle attacks. Now that the initiator and responder have agreed upon IKE SA’s specs and upon a shared symmetric key (Diffie-Hellman process), they can start communicating with their secure ISAKMP Security Association channel.
Etienne Janot Vincent Gilbert Francis Wong •
Lab2 ISS 533 IPSec
February 17th, 2007
Messages 5 & 6: Identification
These are the first encrypted messages exchanged by the initiator and the responder. The purpose of this last exchange before phase 2 begins is to exchange identity information for remote verification and, if needed, adequate policy use and/or change.
a b c
c
(a) This message’s payload is Identification data. (b) The “Encrypted” flag is on for the first as the Identification payload is encrypted accordingly to the IKE/ISAKMP SA’s definition. (c) Encrypted Identification payload: IP, host FQDN or user FQDN of the sender. This allows ISAKMP to provide primary remote host identity verification. The response is similar and contains identification information on the responder. The IKE/ISAKMP Security Association is now fully set up and tested (as the initiator and responder need to decrypt each other’s Identification payloads and verify their authenticity) and can therefore be used to set up IPSec SA’s during phase 2 (Quick Mode). Once phase 2 is over, the defined phase 1 IKE Security Association is of no use and it thus removed via the following control messages.
Etienne Janot Vincent Gilbert Francis Wong •
Lab2 ISS 533 IPSec
February 17th, 2007
Messages 7 & 8: Delete
Once the IPSec Security Associations have been appropriately set up during the Quick Mode (phase 2), there is no need to conserve the IKE/ISAKMP SA, which is removed. In order to safely remove the IKE Security Association, the initiator sends a Delete message to the responder. The Delete message contains the initiator and responder cookies, a specific Message ID and the ISAKMP SA’s Security Parameter Index (SPI) which corresponds to the concatenation of both cookies and identifies the ISAKMP SA.
There is a potential threat here as attackers in a MITM situation could terminate connections by sending a specially crafted Delete message containing the victims’ cookies (which are constantly sent in the clear) to the responder which would then remove his record of the SA, thus preventing the completion of ISAKMP phase 1. Exceptionally detailed analysis of the weaknesses to the clear text component of the exchange.
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
IKE/ISAKMP Quick Mode (phase 2): Establishment of IPSec SA’s As soon as the initiator and responder have exchanged their first encrypted messages (Main Mode 3rd exchange: Identification), ISAKMP’s second phase, Quick Mode, starts. It is shorter than the Main Mode: our capture contains 4 messages altogether. During this phase, and using phase 1’s established IKE SA, the remote hosts establish SA’s for other protocols than ISAKMP/IKE (as a Kerberos TGT allows to obtain connections/tickets to other hosts), such as IPSec protocols. It is common for hosts to negotiate 2 SA’s: one for inbound and one for outbound traffic. In our case, based on flags changes, it seems that the initiator and the responder established only one IPSec SA – but then since payloads are encrypted it is hard to tell). •
Quick Mode: Message 1
a b c d e Let’s take a closer look at the first ISAKMP phase 2 (Quick Mode) message: (a) Identifies the message’s payload as a Hash – that is actually the case for the 4 exchanged messages, even though SA definitions and keys are exchanged. (b) Identifies the Exchange as part of phase 2: Quick Mode. (c) The Encrypted flag is on as the communications now use the established ISAKMP/IKE SA secure channel which implements 3DES-CBC encryption. (d) The Message ID is a unique value replicated throughout the Quick Mode. Generated by the initiator, it identifies the state of the phase 2 negotiations. (e) The message carries 256 bytes of encrypted data, which would need cryptanalysis before examination is possible.
Etienne Janot Vincent Gilbert Francis Wong
•
Lab2 ISS 533 IPSec
February 17th, 2007
Quick Mode: Messages 2, 3 & 4
a b
The responder’s response (in the case of message 2) reproduces the Message ID (b) defined by the initiator and sets the Commit flag to 1 (a) to indicate key synchronization. This way, encrypted material is not sent before the SA is not completely established. Now that the needed IPSec SA’s have been established, the parties can eventually carry on application-layer traffic using the adequate secure channels. In our case, it is primarily Kerberos traffic that begins with the logon of the client to the KDC and the subsequent ticket exchanges (TGT, Service Tickets) that could be monitored – if the ESP payloads, similar to the 3 first ones below, could be decrypted:
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
ESP Mode: Encryption of Application-Level traffic Now that the needed IPSec SA’s have been established, the parties can eventually carry on application-layer traffic using the adequate secure channels. Good reference to the OSI model/internet model. In our case, it is primarily Kerberos traffic that begins with the logon of the client to the KDC and the subsequent ticket exchanges (TGT, Service Tickets) that could be monitored – if the ESP payloads, similar to the 3 first ones below, could be decrypted:
•
First ESP message: Initiator Responder
•
Second ESP message: Responder Initiator
•
Third ESP message: Initiator Responder
Each party:
possesses a SPI (0x17df7871 for the initiator, 0xb49e4663 for the responder);
increments a party-based Sequence number (counter) to prevent replay attacks.
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
File Transfer with Isolated Server Below is an extract of the PCAP capture of network traffic generated by the file transfer:
As we can see, the two parties (in this case, the client and the isolated file server), which had apparently previously established an IKE/ISAKMP SA still in use, set up an IPSec Security Association (phase 2: Quick Mode) as it was done for the logons. They eventually carry on with their application-level traffic, which in this case is composed of Kerberos tickets exchanges and of Microsoft network file sharing packets. As the ESP payloads are encrypted, we cannot see the traffic itself – nothing is sent in the clear, except for the ICMP traffic which is exempted from IPSec (AH/ESP) transformation, as it was defined in the Domain Security Policy (IPSec enabled for domain, file server isolated with “Require Security” rule). Note: the 2 first ESP packets displayed (# 557 and 558) are using a previously established IPSec Security Association.
Etienne Janot Vincent Gilbert Francis Wong
Lab2 ISS 533 IPSec
February 17th, 2007
Excellent discussion of the packets. Excellent analysis.
Weaknesses in the IPSec Protocol Suite: IKE/ISAKMP One major weakness - known or considered – in the IPSec Protocol Suite is its complexity. This applies very well to the IKE/ISAKMP protocols as they allow many modes: due to the difficulty to implement all possible functioning modes and to the superfluity of some of the modes, vendors implement the IPSec Security Association establishments differently, thus causing many interoperability problems which sometimes lead to security breaches. Many say that IKEv1/ISAKMP plague’s IPSec security level and that IKEv2 (current draft) should benefit from IPSec’s AH/ESP security countermeasures, such as a sequence number as anti-replay protection.
Below are briefly explained some of the attacks possible on ISAKMP: •
Discovery of IKE Service
Implementations of IKE services need to adopt a strategy for the retransmission of their packets – IKE/ISAKMP running on UDP. As there is no standard for these, vendors have developed their own strategies, thereby giving the possibility to attackers to observe the ISAKMP traffic and deduct the service’s specific vendor/implementation from its fingerprint (pattern). Then, the attacker can focus on the specific implementation’s security weaknesses.
•
Denial of Service (DoS) attacks
By performing a TCP Syn Flood-like attack on the responder (flooding the host with incomplete ISAKMP connection establishment messages), attackers can force hosts to run out of memory and/or CPU as cryptographic processes are heavy. This is made possible by the use of dedicated programs which enable malicious users to send “handcrafted” (e.g. intentionally malformed) ISAKMP messages.
Etienne Janot Vincent Gilbert Francis Wong
•
Lab2 ISS 533 IPSec
February 17th, 2007
Authentication attacks
When Pre-Shared Keys (PSK) are used as authentication method, those should be strong enough to be safe from PSK cracking attacks. When weak PSK are used it is fairly easy for an attacker to crack the key, using a combination of dictionary and brute force attack after having capture as little as one exchange (initiator’s hash not encrypted in the case of Aggressive Mode negotiation) or with a Man-In-The-Middle (MITM) attack (fabrication of the responder’s public key) in the case of Main Mode use. Moreover, some implementations contain flaws which allow attackers to use “degenerated” Diffie-Hellman public keys in order to discover the shared secret key (symmetric key for IKE SA).
•
Aggressive Mode ID attacks
ISAKMP’s first phase “Aggressive Mode” is faster but less secure:
Remote user ID’s can be obtained by eavesdropping on ISAKMP Aggressive Mode communications as the ID’s are sent in the clear. Furthermore, as IKE RFC’s do not specify how implementations should handle invalid ID’s, an attacker whishing to obtain remote users’ ID’s could enumerate them by performing a dictionary and/or brute force attack to the IKE service. Given the specific IKE service implementation’s pattern in its responses to invalid ID’s, the attacker could simply check the targeted system’s responses and make a list of known ID’s. Exceptionally good analysis of packets and weaknesses. Remember dictionary tools will be defeated by using tools to help users develop strong keys, passwords or preshared keys. 6/6*
