Network Working Group R. Chou Internet Draft Aruba Networks Expires: January 28, 2005 M. Andrade Aruba Networks J. Wright The SANS Institute July 28, 2004 RADIUS Vulnerabilities in Wireless and Wired Environments Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC-3668 [1]. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC-2026 [2]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The RADIUS protocol utilizes a shared secret-based authentication mechanism that has long been known to be vulnerable to dictionary attacks. As a result, RFC-2865 [3] requires that the RADIUS shared secret SHOULD be at least as large and unguessable as a well chosen password, and RFC-3579 [4] RECOMMENDS that IPsec be used to protect RADIUS. Unfortunately, more than a decade after the deployment of the first RADIUS implementations, popular RADIUS clients still do not comply with the RADIUS standards, requiring the use of short and easily Chou, et al. Expires - January 28, 2004 [Page 1] RADIUS Vulnerabilities in a Wireless Environment July 2004 guessable shared secrets, and lacking support for IPsec protection of RADIUS. As a result, many common implementations remain vulnerable to dictionary attacks. This document describes the implementation of an attack tool that enables the recovery of the shared secret from RADIUS implementations not fully compliant with RFC-2865 and RFC-3579. The attack tool requires only the capture of a single RADIUS Request/Response exchange, and is applicable to any device implementing RADIUS -- including popular switches, routers, VPN concentrators and access points. Once obtained, the RADIUS shared secret will in many cases enable the attacker to gain full control of the device, enabling a wide spectrum of mischief, including the replacement of firmware, and the snooping and decryption of traffic. Given that vendors continue to ship RADIUS implementations with major security flaws years after the approval of the RADIUS standards, the authors recommend that the language of the RADIUS RFC's be strengthened to require vendors to implement IPsec support for RADIUS traffic on NAS devices. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [5]. Table of Contents 1. Introduction...................................................3 1.1 RADIUS Background..........................................3 1.2 Scope of Vulnerability.....................................4 1.3 Practicality of Vulnerability..............................4 2. Description of Attack..........................................5 2.1 Outline of Steps - Wireless Key Recovery...................5 2.2 Details of Steps - Wireless Key Recovery...................5 2.3 Outline of Steps - Compromised Authentication..............7 2.4 Details of Steps - Compromised Authentication..............8 3. Recommendations................................................9 3.1 RADIUS Over IPSEC..........................................9 3.2 Protect Distributed Encryption Implementations.............9 4. Unsuccessful Improvements.....................................10 5. Security Considerations.......................................11 6. Acknowledgements..............................................11 7. References....................................................11 7.1 Normative References......................................11 7.2 Informative References....................................12 8. Author's Addresses............................................12 Chou, et al. Expires - January 28, 2005 [Page 2] RADIUS Vulnerabilities in a Wireless Environment July 2004 1. Introduction This document presents a practical attack that can be mounted against RADIUS implementations not fully conformant with RFC-2865 and RFC- 3579, enabling recovery of the RADIUS shared secret. Once the RADIUS shared secret is compromised, in many implementations the attacker gains administrator level access to the device. This enables reconfiguration of the network at will, as well as decryption of traffic. This document first presents practical attacks on wireless and wired networks by breaking the RADIUS shared secret. Once the secret is compromised, an adversary has several attack vectors to exploit including the ability to passively decrypt the contents of wireless traffic or circumvent the security of RADIUS-based authentication mechanisms. This document then analyzes an attempt to mitigate the weakness, and finally presents two different network designs that prevent the weakness. 1.1 RADIUS Background Defined in RFC-2865, RADIUS is an authentication, authorization and accounting protocol used to control access to the network. In some implementations, RADIUS is also utilized to authorize administrator- level access to network devices themselves. Since RADIUS utilizes an MD5-based authentication mechanism, it is vulnerable to dictionary attacks. As a result, RFC-2865 Section 3 states that: The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well- chosen password. It is preferred that the secret be at least 16 octets. In addition, RFC 3579 Section 4.2 states: To address the security vulnerabilities of RADIUS/EAP, implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with non-null transform SHOULD be supported, and IPsec ESP with a non-null encryption transform and authentication support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay Chou, et al. Expires - January 28, 2005 [Page 3] RADIUS Vulnerabilities in a Wireless Environment July 2004 protection. IKE SHOULD be used for key management. Unfortunately, the vast majority of existing RADIUS client implementations do not implement either these recommendations, leaving them vulnerable to attack. For wireless networks, RADIUS is used in conjunction with the extensible authentication protocol (EAP) to support multiple authentication mechanisms and IEEE 802.1x. A mechanism described in IEEE 802.1x section 7.6 is the ability to distribute encryption keys to wireless users using the EAPOL-Key description mechanism. These keys are distributed by the RADIUS server using vendor-specific attributes and MAY be protected with MS- MPPE-Send-Key and MS-MPPE-Recv-Key attributes, described in RFC-2548, section 2.4 [6]. The confidentiality of the EAPOL-Key messages between the NAS and authentication server are paramount to ensure the privacy of wireless networks using IEEE 802.1x, regardless of the encryption mechanism used to protect data confidentiality. 1.2 Scope of Vulnerability By exploiting the vulnerability detailed in this document against a wireless network, an adversary is able to decrypt all packets gathered on the wireless network without knowledge of user authentication credentials or certificate secrets. This vulnerability affects all known 802.1x authentication mechanisms including but not limited to EAP/TLS, TTLS, PEAP and LEAP, as well as dynamic WEP and 802.11i (RC4, AES) encryption mechanisms. Where RADIUS is used to authorize administrative access to the device, this vulnerability enables the attacker to gain complete control of the device, enabling a wide range of mischief, including replacement of firmware, rerouting of traffic, etc. Since RADIUS is implemented on a wide range of network devices, including switches, routers, VPN concentrators, as well as Access Points, the scope of this vulnerability is quite large. 1.3 Practicality of Vulnerability The authors believe this attack is simple to mount, requiring only the ability to sniff traffic between the NAS and the authentication server to be effective. The exposure of an organization is exacerbated when access points that act as NAS devices regularly Chou, et al. Expires - January 28, 2005 [Page 4] RADIUS Vulnerabilities in a Wireless Environment July 2004 communicate with the RADIUS server to exchange link layer encryption keying material. Tools to aid an adversary in sniffing the network from a compromised wired node or a compromised wireless link are publicly available and effective at collecting the information needed to mount this attack. 2. Description of Attack 2.1 Outline of Steps - Wireless Key Recovery These steps detail how an adversary could exploit a wireless network using any EAP type and RC4 or AES encryption (dynamic WEP, WPA1 or WPA2). 1. Access or break the RADIUS shared secret. Since RADIUS secrets are typically used throughout a group of NAS devices, many people have direct access to the secret. If it is not available, it can be cracked in most cases: - Sniff packets between AP and RADIUS Server. - Initiate any 802.1x wireless connection. - Crack RADIUS shared secret between AP and RADIUS Server. 2. Wait for a valid 802.1x wireless station to connect and go through 802.1x handshake. 3. Using the shared secret, decrypt MPPE keys sent from RADIUS to AP for the valid station. 4. Decrypt the EAPOL key messages between AP and station using key from #3. 5. Decrypt data packets in the air based on key decrypted from #4. 2.2 Details of Steps - Wireless Key Recovery The first requirement is to have the ability to sniff packets between the NAS (AP) and the Authentication Server (RADIUS Server). This can be accomplished in many ways. Here are the 2 most popular: - ARP poisoning. An adversary-controlled machine or rogue AP is placed on any VLAN where the communication between the NAS and Authentication Server pass through. Note that this VLAN does not have to be the VLAN on which the NAS or the AS resides. The adversary then sends out gratuitous ARPs to each side of the communication, one closest to the NAS and the other closest to the Authentication Server. All subsequent communication between the two sides will then need to pass through the adversary-controlled machine. Note that this attack could also be mounted from a compromised wireless connection, by exploiting weaknesses in static WEP keys, or weak authentication mechanisms. Chou, et al. Expires - January 28, 2005 [Page 5] RADIUS Vulnerabilities in a Wireless Environment July 2004 - In some cases, it may be possible for an adversary to execute an ARP poisoning attack from a VLAN that does not accept or forward traffic between the NAS and the authentication server. By exploiting ICMP Redirect and Proxied ARP support on popular router hardware, an adversary may be able to launch a man-in-the-middle attack from a neighboring network on a different VLAN. - Connect a hub or enable port monitoring anywhere along the path where the NAS and Authentication Server communicate. Trigger any wireless station to start an 802.1x handshake. This does not need to be a station with valid credentials, as we only need the AP and RADIUS Server to exchange 2 packets. These 2 packets will not actually authenticate the station just yet, so any station can trigger the generation of these 2 packets. The purpose of these packets is to receive a RADIUS request and response with the authenticator fields. The response-authenticator field is derived from the request authenticator in the following way: Response Authenticator = MD5(code + id + len + request Authenticator + Attributes + RADIUS Secret) In this equation, the code, ID, length, request authenticator and attributes are transmitted in plain-text in the RADIUS header. Only the RADIUS secret is not known to an adversary who is able to capture this frame. Therefore, a dictionary or brute force attack can be mounted very efficiently, especially because the RADIUS secret is the last component in the formula. Since the MD5 context can be saved for the calculation leading to the secret, only the computation of the secret needs to be calculated for each pass in the attack. A typical high end Intel Pentium 4 processor with optimized assembly code for MD5 can calculate approximately 4-5 million passes per second. This type of hardware would be effective to launch a dictionary attack, or an attack against a limited ASCII character set, up to 8 characters in length. A distributed attack would make it possible for an adversary to reduce the timeframe to recover the RADIUS secret further. As an alternative to standard Intel Pentium 4 hardware, specialized encryption hardware with microcode enhancements could do the same task approximately 10,000 times faster. In cases where an attack against the RADIUS secret encompasses all 94 printable ASCII characters, specialized crypto hardware would be able to try all possible permutations in approximately 34 days, with the probability of a successful attack after 17 days. Aiding an adversary in this attack, many vendors require users to limit the content of their RADIUS secret to only alphabetic and Chou, et al. Expires - January 28, 2005 [Page 6] RADIUS Vulnerabilities in a Wireless Environment July 2004 numeric characters. In the case of specialized crypto hardware, eight character passwords consisting of any combination of lower and upper alphabetic characters and numbers can be recovered in less than 90 minutes. Remember that this is an offline attack, where an adversary only has to capture 1 packet from the NAS to the authentication server to mount their attack. Since few organizations rotate RADIUS secrets regularly, it is practical for an adversary to spend a considerable amount of time to recover the RADIUS secret before returning to continue the next steps of the attack. Once the RADIUS secret is cracked, we can then sniff for valid 802.1x handshakes transmitted between the AP and RADIUS server. The packet of interest is the one that contains the MPPE key information. This key is encrypted as follows: Keys = MD5(RADIUS secret + request authenticator + 2 byte salt) XOR "MPPE packet" This is the key that will then be used to encrypt all EAPOL-Key messages for both unicast and multicast data encryption between the valid wireless station and the AP. Finally an attacker sniffs for EAPOL packets in the air and decrypts their contents using the MPPE keys. For WPA1, the keys are encrypted using RC4. In WPA2, the keys are encrypted in AES. The method used is irrelevant as the attacker now has the key that encrypted it. An adversary only needs to determine how the traffic was encrypted and use such method to decrypt wireless traffic. The keys transmitted in the EAPOL messages are the keys actually used to encrypt data packets in the air. Once that is available, an adversary is able to decrypt any packet between that valid station and AP. This is the case even if the more secure AES-CCM encryption method is used for encryption. As the keys update in accordance to the layer 2 encryption mechanism in use (RC4, AES), an adversary simply decrypts the contents of the new EAPOL-Key message, and begins using the new keys, as needed. An adversary would be able to sustain this attack for the duration of the connectivity of the wireless client, despite roaming and regular key rotation. 2.3 Outline of Steps - Compromised Authentication These steps detail how an adversary could exploit weak RADIUS implementations to circumvent the authentication requirements on nodes that utilize RADIUS to authenticate users. This is commonly implemented on routers, switches and other devices. Chou, et al. Expires - January 28, 2005 [Page 7] RADIUS Vulnerabilities in a Wireless Environment July 2004 1. Access or break the RADIUS shared secret. Since RADIUS secrets are typically used throughout a group of NAS devices, many people have direct access to the secret. If it is not available, it can be cracked in most cases: - Sniff packets between AP and RADIUS Server. - Initiate a connection to the device using RADIUS for authentication, and supply enough information to initiate an exchange between the NAS and the authentication server by supplying an invalid username and password. - Crack RADIUS shared secret between the NAS and RADIUS Server. 2. Attempt to gain administrative access to the device by establishing a connection and supplying an invalid authentication credentials. 3. Using the recovered RADIUS shared secret, forge an Access-Accept granting administrator privileges to the attacker. 4. Using administrative privilege, carry out a wide spectrum of mischief, including snooping of traffic. 2.4 Details of Steps - Compromised Authentication In this attack, an adversary desires access to a device (NAS) that authenticates users via the RADIUS protocol, such as a router or switch. The first requirement is to have the ability to sniff packets between the NAS device and the authentication server. The methods used to capture this information are detailed in section 2.2. After establishing the ability to sniff packets between the NAS and the authentication server, the adversary attempts to connect to the NAS device to initiate the authentication process. In most cases, the adversary does not need valid authentication credentials (including a valid username); they only need to attempt to authenticate to the NAS device, triggering an Access-Request message from the NAS to the authentication server. The Access-Request message has sufficient information for an attacker to mount an offline brute-force attack as illustrated in section 2.2. After recovering the RADIUS secret, an attacker attempts to connect to the NAS device with an invalid username and password. While monitoring the RADIUS exchange, an attacker extracts the 16-octet Request Authentication value from the Access-Request frame transmitted for this invalid user. While the authentication server attempts to authenticate the credentials of the invalid user, the attacker creates a forged Access-Accept packet using the source address of the authentication server and a calculated response authenticator value, using the following formula: Chou, et al. Expires - January 28, 2005 [Page 8] RADIUS Vulnerabilities in a Wireless Environment July 2004 Response Authenticator = MD5(code + id + len + request Authenticator + Attributes + RADIUS Secret) Upon receiving the forged Access-Accept packet, the NAS device accepts the invalid authentication credentials and grants access to the attacker. 3. Recommendations If encryption must be done at the AP, the AP must communicate with Authentication Server (RADIUS Server) through IPSec. Avoid distributed encryption if at all possible. The distribution of encryption keys should reside in as few devices as possible. This can only be accomplished by not doing encryption at the AP as any midsize enterprise would typically have hundreds to thousands of AP's. 3.1 RADIUS Over IPSEC If RADIUS NAS devices and RADIUS secrets must be distributed throughout an enterprise network, the NAS device MUST support IPsec ESP [RFC2406] with non-null encryption transform. IKE MUST be used for key management. Note that only RADIUS traffic MUST be transmitted with the protection of IPsec to mitigate this flaw, representing a small fraction of traffic from a typical NAS device. 3.2 Protect Distributed Encryption Implementations Distributed encryption models for wireless networks rely on offloading the task of encrypting the contents of wireless traffic at the access point, relying on the confidentiality and integrity of the wired network for management traffic such as RADIUS. As we have seen, this model is susceptible to the attack described in this document, exploiting the implied trust of the wired network for insecure protocols. Some distributed encryption mechanisms use non- IPSEC schemes for protecting control traffic while leaving the data exposed. Alternatively, centralized encryption mechanisms mitigate this flaw, protecting wireless traffic over the wired network to a centralized crypto engine. While the centralized crypto system still uses RADIUS for authentication, it reduces the number of NAS devices that have knowledge of the RADIUS secret. Further, the centralized system can Chou, et al. Expires - January 28, 2005 [Page 9] RADIUS Vulnerabilities in a Wireless Environment July 2004 also benefit from an increase in trust over the wired network to the RADIUS server, as in the case of a data center VLAN. Instances of centralized encryption using a decentralized model (e.g. wireless switches distributed to single buildings) are still susceptible to attack and therefore MUST implement the recommendations in section 3.1 by implementing support for IPsec ESP [RFC2406] with non-null encryption transform for all RADIUS traffic. 4. Unsuccessful Improvements Attacks against the RADIUS secret are not new; they are well documented in RFC-2548, RFC-3579 and RFC-3580 [7]. However, the authors believe that few organizations have heeded the recommendations of the RFC's, resulting in weak RADIUS implementations. Further, the authors believe that the extension of this attack to compromise the confidentiality of the wireless network has not been previously documented. As this vulnerability can be leveraged to exploit WPA1 and WPA2 networks with any known EAP type, it is considered imperative that organizations adopt the recommendations in this document. One attempt to remediate flaws in the weak exchange of keys over vendor-specific RADIUS attributes was submitted as draft-zorn-radius- keywrap-01 titled "RADIUS Attributes for Key Delivery" [8]. This draft extends the integrity of RADIUS messages using a Message- Authentication-Code using HMAC-MD5 or HMAC-SHA-1, and AES Key Wrap with 128-bit key-encryption-key [RFC3394] to encrypt the contents of keys transmitted in RADIUS key delivery messages. In this memo, a RADIUS configuration would include two additional shared secrets between the NAS and the authentication server for use as KEK's to protect the confidentiality of encryption keys exchanged between the NAS and the authentication server. This draft does not adequately address the vulnerability described in this memo, exposing one of the keys to valid stations for use in decrypting EAPOL-Key messages. By using an account with valid authentication credentials (such as a guest account, or other compromised user credentials), an attacker will be able to mount an offline dictionary attack against the KEK used to protect keys exchanged between the NAS and the authentication server. Once this key becomes compromised, an attacker has defeated the security of this draft, and can continue their attack as described in this memo. Chou, et al. Expires - January 28, 2005 [Page 10] RADIUS Vulnerabilities in a Wireless Environment July 2004 The recommendations in "RADIUS Attributes for Key Delivery" continue to extend weak password-based systems to protect the confidentiality of keys. It is recommended that RADIUS use IPsec instead, which is significantly more resistant to password-based attacks. 5. Security Considerations It is RECOMMENDED in this memo that RADIUS only be run on a trusted network with as little distribution of the RADIUS secret as possible. It is REQUIRED in this memo that RADIUS servers support IPSec and IKE to provide a secure mechanism for tunneling EAP traffic to an authentication server. Organizations SHOULD take special precautions to mitigate the attacks described herein. 6. Acknowledgements The authors would like to thank William Arbaugh and Robert Moskowitz for their valuable feedback. 7. References 7.1 Normative References [1] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC-3668, February 2004. [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC-2026, October 1996. [3] Rigney, C., "Remote Authentication Dial In User Service (RADIUS)", RFC-2865, June 2000. [4] Aboba, B., "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC-3579, September 2003. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC-2119, March 1997. [6] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC- 2548, March 1999. [7] Congdon, P., "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC-3580, September 2003. Chou, et al. Expires - January 28, 2005 [Page 11] RADIUS Vulnerabilities in a Wireless Environment July 2004 [8] Zorn, G., "RADIUS Attributes for Key Delivery", Internet-Draft, July 7 2004. 7.2 Informative References Kent, S., "Security Architecture for the Internet Protocol", RFC- 2401, November 1998. Harkins, D., "The Internet Key Exchange", RFC-2409, November 1998. Kent, S., "IP Encapsulating Security Payload (ESP)", RFC-2406, November 1998. Schaad, J., "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC-3394, September 2002. 8. Author's Addresses Randy Chou Aruba Networks 180 Great Oaks Boulevard San Jose, CA 95119 Phone: +1 408 227 4500 Email: rchou@arubanetworks.com Merwyn Andrade Aruba Networks 180 Great Oaks Boulevard San Jose, CA 95119 Phone: +1 408 227 4500 Email: merv@arubanetworks.com Joshua Wright The SANS Institute 8120 Woodmont Avenue Suite 205 Bethesda, MD 20814 Phone: +1 401 524 2911 Email: jwright@sans.org Chou, et al. Expires - January 28, 2005 [Page 12]