- Section01. About the IPSec
- Section02. Vulnerability Reported for IKEv1
- Section03. Aggressive mode and its vulnerable points - RFC2409
학교 과제로 했던 건데, 내용이 좋아서 블로그에 백업! 오랜만에 어택 벡터 찾는 느낌이 나서 재밌었던 과제로 기억한다. 그리고…. 한국어 수업인데 정줄 놓고 쓰다 보니 영어로 쓰고 제출까지 하는 바람에 교수님께 양해를 구했던….. 과제다……. (당시 진짜 바빴고 참고 문서가 다 영어라서 정말 실수였다)
아무튼 읽으시는 분께. 미안합니다. DeepL이 번역을 솔찬히 잘하니 추천드립니다.
Section01. About the IPSec
- It is a well-known fact that if the logical complexity gets higher, the possibility of the existence of critical contradiction gets higher too. Hence, I am going to describe the subprotocols of IPSec and pick the most complex protocol among them.
- IPSec consists of ESP, AH, and IKE protocol. IKE is known as the most complex protocol because of its mathematical and dependency complexity. Therefore, I am going to find a vulnerability that exists in the design of the IKE.
- IKE is consisted of OAKLEY, SKEME, and ISAKMP and provides 1) PSK-based, 2) PKE-based, 3) RPKE-based, and 4) Signature-based encryption. Because PKE and RPKE are well-known secure protocols(at least their design is secure), I prefer delving into the PSK-based and Signature-based encryption of IKE.
- According to the inference above, I found a vulnerability that existed in the design of the IKEv1. Section 2 is the description of the vulnerability which is followed by section 3, details of the Aggressive mode of IKEv1 and attack vectors that exists in the protocol.
Section02. Vulnerability Reported for IKEv1
2-1) Description
CVE-2002-1623 / CVSS 2.0: 5.0 Medium
The design of the Internet Key Exchange (IKE) protocol, when using Aggressive Mode for shared secret authentication, does not encrypt initiator or responder identities during negotiation, which may allow remote attackers to determine valid usernames by (1) monitoring responses before the password is supplied or (2) sniffing.
This vulnerability is originally reported for Checkpoint FireWall-1 SecuRemote.
Because Checkpoint implemented the IKE standard for aggressive mode correctly, it could not keep itself from having the vulnerability.
2-2) Impact
Devices that implement this protocol in aggressive mode will leak username information while negotiating IKE sessions. This can be led to the reconnaissance of networks for further attacks.
The vulnerable product is CheckPoint VPN-1/FireWall-1 product, involving the use of SecuRemote/SecureClient and IKE Aggressive mode.
2-3) Solution
Use an alternative mode and authentication method.
For example, both the Main mode with PSK authentication and the Aggressive mode with PK authentication will provide identity protection.
2-4) Details of the vulnerability
-
usernames are susceptible to brute-force guessing when using IKE Aggressive Mode
By sending an IKE Phase-1 aggressive mode packet with the following payloads the firewall will either 1) send back an IKE notification message indicating that the user is not valid in some way, or 2) it will respond with an aggressive mode packet indicating that the user exists and is valid.
-
usernames are passed in cleartext using IKE Aggressive Mode
(Refer the Section 3-which discusses the attack vectors that could be found in the IKE specification)
Section03. Aggressive mode and its vulnerable points - RFC2409
While OAKLEY defines “modes”, ISAKMP defines “phases”. The relationship between the two is very straightforward and IKE presents different exchanges as modes that operate in one of two phases.
Phase 1 is where the two ISAKMP peers establish a secure, authenticated channel with which to communicate. This is called the ISAKMP Security Association (SA). “Main Mode” and “Aggressive Mode” each accomplish a phase 1 exchange. “Main Mode” and “Aggressive Mode” MUST ONLY be used in phase 1.
Phase 2 **is where Security Associations are negotiated on behalf of services such as IPsec or any other service which needs key material and/or parameter negotiation. “Quick Mode” accomplishes a phase 2 exchange. “Quick Mode” MUST ONLY be used in phase 2.
“Main Mode” for phase 1 provides identity protection. When identity protection is not needed, "Aggressive Mode" can be used to reduce round trips even further.
Four different authentication methods are allowed with either Main Mode or Aggressive Mode.
- digital signature
- two forms of authentication with public key encryption
- pre-shared key
3-1) IKEv1 Phase1 Authenticated with Signatures
Aggressive mode with signatures in conjunction with ISAKMP is described as follows:
IDii: Identity of the initiator
IDir: Identity of the Responder
KE: Key exchange payload which contains public information exchanged in a DHKE
As you can see above, the IDs of the party negotiating the signature are exposed on the network.
3-2) IKEv1 Phase1 Authenticated with Public Key Encryption (Has no vulnerability)
Unlike other authentication methods, authentication with public key encryption allows for identity protection in Aggressive Mode.
(If the authentication method is public key encryption, the nonce and identity payloads MUST be encrypted with the public key of the other party. Only the body of the payloads is encrypted, the payload headers are left in the clear.)
3-3) IKEv1 Phase1 Authentication with a Revised Mode of Public Key Encryption
Identical to 2), the body of the payloads is encrypted.
(In this mode, the nonce is still encrypted using the public key of the peer, however, the peer’s identity (and the certificate if it is sent) is encrypted using the negotiated symmetric encryption algorithm (from the SA payload) with a key derived from the nonce.)
3-4) IKEv1 Phase1 Authentication with a Pre-Shared Key
IDii: Identity of the initiator
IDir: Identity of the Responder
The key can only be identified by the IP address of the peers since HASH_I must be computed before the initiator has processed IDir.
As you can see above, the IDs of the party negotiating the SA are exposed on the network.
Conclusion
In conclusion, CVE-2002-1623 was meant to be discovered because the Aggressive mode of the IKE allows cleartext exchange of peer identifiers during phase 1-authentication using 1) Signatures or 2) Pre-Shared Key.
