A number of vulnerabilities exist in the TACACS+ protocol. These are part of the protocol, and as such do not affect only those products listed as being vulnerable, but any implementation of TACACS+, both on the client and on the server side. 1) Integrity Checking TACACS+ does not use any form of integrity checking to ensure a TACACS+ packet has not been tampered with. Due to the nature of its encryption mechanism, an attacker could potentially alter a packet by flipping bits. One example cited is the possibility of an attacker flipping a single bit to alter an accounting packet, changing the elapsed_time being reported from 9000 to 1000. 2) Vulnerability to Replay TACACS+ has no protection against replay attacks. So long as a packet has the correct TACACS+ sequence number, it will be accepted. As TACACS+ sequence numbers start at 1, the server will always process packets with the sequence number of 1. The description of this vulnerability noted that this is most easily used...
A number of vulnerabilities exist in the TACACS+ protocol. These are part of the protocol, and as such do not affect only those products listed as being vulnerable, but any implementation of TACACS+, both on the client and on the server side. 1) Integrity Checking TACACS+ does not use any form of integrity checking to ensure a TACACS+ packet has not been tampered with. Due to the nature of its encryption mechanism, an attacker could potentially alter a packet by flipping bits. One example cited is the possibility of an attacker flipping a single bit to alter an accounting packet, changing the elapsed_time being reported from 9000 to 1000. 2) Vulnerability to Replay TACACS+ has no protection against replay attacks. So long as a packet has the correct TACACS+ sequence number, it will be accepted. As TACACS+ sequence numbers start at 1, the server will always process packets with the sequence number of 1. The description of this vulnerability noted that this is most easily used against accounting packets, as they are single packet transactions. 3) Session ID collision The encryption mechanism for TACACS+ depends heavily on a unique session_id for each session. If multiple sessions get the same session_id and seq_no, it can become vulnerable to a frequency analysis attack. In addition, if plaintext is known in one packet, it is trivial to decrypt the corresponding portion of the other packet containing the same sequence and session id. It is possible to get a TACACS+ server to encrypt a reply packet using a chosen session_id. This makes it possible to compromise the encryption of packets from the server to client. 4) Session ID randomness Due to the length of the session_id, and an inability to prevent id collision across reboots and multiple servers, session id's will eventually be reused, which can result in the decryption of packets. For an ISP handling 20,000 dialup sessions a day, there could be over 100,000 session_id collisions in a year. 5) Lack of padding A lack of padding of fields in the protocol can reveal the length of these unpadded fields. This could result in revealing the length of a user password. 6) MD5 context leak A theoretical vulnerability exists whereby part of a packet may be decrypted, due to the presence of certain bytes. These attacks all require the attacker be present on the network where these transaction are taking place; in some cases, the attack may need to be on a machine or router seperating the client from the server. As such, while very real vulnerabilities, using them in a real world situation may be difficult.
