Simon Josefsson, RSA Laboratories
August 27, 2001
The Telnet Protocol [1] provides a generic communications facility, primarily used to interface terminal devices with terminal-oriented processes to each other. Implementations of the protocol are often used to perform remote work on Unix-like computers or routers. The core protocol does not support authentication, data encryption nor data integrity. Two framework documents, Telnet Authentication Option [5] and Telnet Data Encryption Option [7], describe how the core protocol may be enhanced with authentication, encryption or data integrity. Several authentication mechanisms have been specified within the framework, but we will focus only on the Kerberos version 4 mechanism [4]1 and the Kerberos version 5 [6] mechanism. Both of these authentication mechanisms also provide keying material for use by the Telnet Encryption option.
The authentication framework specified in [5] describes a three-step authentication process. We will give a brief description here, using a simplified notation of Telnet commands for legibility. Readers familiar with the Telnet protocol and the Authentication Option in particular should note that when we talk about the WILL, DO, WONT, DONT authentication command, we are referring to the IAC * AUTHENTICATE commands. When we talk about the SEND, NAME, IS, REPLY commands, we refer to the IAC SB AUTHENTICATION * IAC SE commands. Also, we will talk about these commands as being sent individually, when in practice they are usually bundled together with other commands. The three steps of the authentication protocol are:
The client begins by sending the WILL authentication command to signal that it wishes to initiate authentication. It expects a DO or DONT command in return. The DO command indicates that authentication is supported by the server and that the client should proceed with authentication. The DONT command indicates that the server is not willing to negotiate authentication. If DO is not received, the client aborts its attempts of negotiating authentication. These commands are not integrity protected.
In the second step, the server sends the SEND command which contain a ordered list of acceptable (to the server) authentication and encryption options. Each entry include indicators for which authentication mechanism to use (e.g. Kerberos 4 or Kerberos 5); if mutual or client-only authentication should be used; and how encryption should be negotiated. Note that the ordered list is not integrity protected, an attacker may remove entries or re-order the list at will. The specification suggest that the ordered list may be integrity protected by the mechanism, however neither the Kerberos 4 or the Kerberos 5 Telnet Authentication Protocols implement this feature.
The clients selects one of the authentication mechanisms supported by the server, and commences step three. In the Kerberos case, the account name is transferred using a NAME command. Then a Kerberos structure called KRB_AP_REQ is sent in the IS authentication command. The KRB_AP_REQ structure contains authentication information and keying material. It also contains a check sum calculated on the authentication type chosen by the client. This indicates that some attempts to protect from active attackers were made. However, we will see that leaving the server authentication list unprotected may leave enough room to mount an attack in practice.
The Telnet Encryption Option [7] is similar to the Telnet Authentication Option, the first step negotiate whether encryption should be used at all or not. It uses the WILL, DO, WONT, and DONT encryption commands. The client sends a WILL encryption command indicating that it is willing to send encrypted data, and a DO encryption command indicating it is willing to receive encrypted data. The client expects a WILL and DO response back from the server, indicating that the server is also willing to send and receive encrypted data. The WONT and DONT commands are sent when the sender refuses to send or receive encrypted data. Once the parties has agreed to use encryption, the Telnet Encryption framework proceeds similar to the authentication framework, by negotiation which encryption mechanism to use, and then the parameters for that mechanism.
The weaknesses in the negotiation phase, that the list of server supported authentication and encryption mechanisms is not integrity protected, can be exploited in current implementations2. We describe the simplest attack, where we are able to disable the Telnet Encryption option - which is responsible for negotiating data encryption and optionally data integrity3 - and ultimately impersonate a server from the point of view of the end user.
By intercepting the (unprotected) WILL and DO commands sent by the server, the Telnet client is fooled into a state where it does not proceed to require negotiation of the encryption option even though this was requested by the user. Once the mutual authentication is done, it is possible to cover up for the disabled Encryption option by inserting data into the stream that resembles those messages inserted by the client to inform the user that encryption has been enabled. This step is of no theoretical interest, most users expect that encryption is properly negotiated if she requests it, and that a error or at least a warning is given if encryption isn't enabled. There is a lesson to be learned here though: Never reuse a stream for both insecure data and security information. The user will not be able to tell whether the security information was sent by the possibly insecure remote system (which may be a attacker) or generated by the locally trusted application.
Once any encryption and integrity functionality has been disabled, it is trivial to hijack the session. The following is a excerpt from a terminal session where a user requests a remote session, which is overtaken by a active attacker. The output to the user looks identical to when a mutual authenticated and encrypted channel is opened. In the text below, the session is hijacked right after the mutual authentication, and the active attacker inserts the encryption status information and removes a security warning from the remote system. Familiarity with the Kerberos Telnet system is necessary to appreciate it.
alice$ telnet -x bob.example.com Encryption is verbose Trying 10.0.0.1... Connected to bob.example.com. Escape character is '^]'. [ Trying mutual KERBEROS5 (host/bob.example.com@EXAMPLE.COM)... ] [ Kerberos V5 accepts you as ``alice@EXAMPLE.COM'' ] [ Output is now encrypted with type DES_CFB64 ] [ Input is now decrypted with type DES_CFB64 ] eve$
Varying this approach, we was able to come up with a similar attack against Kerberos V4 Telnet. Apparently, tricking the client into using client-only authentication, by modifying the Authentication negotiation, disables the attempt to use encryption (even though encryption was requested by the user). However, the Kerberos V4 authentication mechanism actually negotiates a mutually agreed key during the server authentication phase, so the logic of disabling encryption when mutual authentication is unsuccessful is not necessary (and is indeed harmful as it opens up for the attack).
The attack we have seen is made possible by combining two things:
This first is well-known and well-documented weakness in the Authentication and Encryption Options. The Authentication option specifications suggests that the entire negotiation phase may be protected by a check sum by the mechanism. Neither the Kerberos V4 or the Kerberos V5 Telnet protocols implement this. This results in a unwanted characteristic in a security negotiation protocol: It is impossible to know whether the eventually selected authentication and encryption suite was the strongest one possible. The reasonable approach in a client, to only accept client-only authentication if mutual authentication was not available, cannot be securely implemented in this protocol. The client is not able to distinguish between the case when no server-side authentication is available and the case when it is under attack. A prudent Kerberos Telnet client has to consider an authentication announcement which lacks mutual authentication as possibly being under attack. Ideally, Kerberos V4 and V5 Telnet Authentication should not leave themselves open to these attacks. However, the Kerberos Telnet specifications does not claim to protects from this attack, so we do not claim to have ``broken'' it, but we do feel that this is a unwanted characteristic of a security protocol that warrant some concern.
To exemplify to what extent the weakness is known, we quote part of the security considerations for the Telnet Encryption Option [7]:
The ENCRYPT option used in isolation provides protection against passive attacks, but not against active attacks. In other words, it will provide protection from someone who is just watching the IP packets as they pass through the network. However, a attacker who is able to modify packets in flight could prevent the ENCRYPT option from being negotiated. This flaw can be remedied by using the Telnet Authentication option alongside the ENCRYPT option. Specifically, setting ENCRYPT_USING_TELOPT in the authentication-type-pair can be used to force that Encryption be negotiated even in the face of active attacks.
It is not stated explicitly, but the suggested remedy assumes that the Telnet Authentication option is being integrity protected, otherwise the active attacker is able to modify the Telnet Authentication option as well. This is were the Kerberos Telnet Authentication Option fails, it does protect the Telnet Authentication option from the client to the server, but the initial list of supported mechanisms from the server to the client is never protected. Hence whenever a client and server accepts weaker mechanisms, an attacker is able to force the weaker mechanism to be used. Since the list sent by the server is an ordered list, in practice servers include all the mechanisms they are able to support, thus letting the client (or an attacker) pick the ``best'' one. This is unlike TLS [10] that protects the entire negotiation phase from any tampering.
Since the attack was based on combining two different ideas, we identify two solutions that prevent the possibility of combining them into a successful attack:
Ideally both solutions should be implemented, but either one of them will suffice. The first approach is needed to make the Kerberos authentication protocol more cryptographically sound by itself. We recognize that keeping backwards compatibility may be the deciding factor here.