понедельник, 23 ноября 2015 г.

3 Attacks on Cisco TACACS+: Bypassing the Cisco's auth

I would like to tell the results of my little security research of TACACS+ protocol.

What is TACACS+?

Usually, if a company has a big network with a lot of network devices, it may be a big problem to manage access to them. Thus, companies implement one of the protocols for centralized access management. Cisco devices support TACACS+ and RADIUS protocol.

So, Terminal Access Controller Access-Control System Plus (TACACS+) is a special protocol of AAA (Authentication, Authorization, Accounting) from Cisco. TACACS+ uses 49 TCP port.

So, usually there is a special server with TACACS+ service, and all network devices are configured to use it. Consequently, when a user authenticates on a switch, a router or another network device, the network device resends the user’s credentials to the TACACS+ service, where they are verified and then it decides to grant access to the device. The decision returns to the device in a reply packet.

It’s handy, and centralized. There is an opportunity to set different privileges for users on different devices. There is logging of access and operations on the server side (accounting).There is the opportunity to add another one centralized management, like Active Directory or LDAP. There is an open source realization of TACACS+ service (once Cisco opened the specification of the protocol).

Attack #1

The first attack looks more like a trick, and not likethan a full attack type. But it could be useful in some situations.

Let’s pretend a situation.imagine, that dDuring a pentest we grabbed a configuration file of a Cisco device (for example, we downloaded it from a company’s TFTP server). That’s cool, but even if we successfully bruteforce a local account of the device, we will not be able to log into the device, because the device will verify the local account on a TACACS+ service…

But here we should have a look at a typical configuration of a network device in case of usage the TACACS+. AssumeLet’s pretend , that something is has happened with a TACACS+ server and the serverit is not accessible from the network device. And an An admin wants to log in, but he cannot do it. To solve such a typical situation, Cisco devices support different kinds on of authentication (fallback), which the admin have has to set up in a config.

So, the classic authentication configuration of authentication on a cisco Cisco device with the TACACS+ looks something like that:
aaa authentication login default group tacacs+ local
There are two important words for us at the end.Only two last words are important for us. They set indicate that at first the TACACS+ is used for authentication and then the network device verifies a user’s credentials in a local db. Also, if the user’s credentials is are not found by TACACS+, they will not be verifies verified localylocally.

The idea of the first attack is pretty simple. We, as pentesters, perform a DoS attack on the TACACS+ service, and then we connect to the Cisco device with the local account (that we got from TFP in our example). And as the TACACS+ service is not accessible, the network device gives as us a desired access. We can use different kind of DoS attacks. For example, we can created a lot of TCP- connections to the service and perform temporary DoS.

Intro for attacks №2 and №3

Before we move on to next attacks, we should know learn something else about the TACACS+ protocol. The data of the protocol is transmitted in plain- text or encrypted. It uses a custom encryption based on PSK (Pre-Shared Key). An admin set one encryption key on a TACACS+ server and on all network devices, which have to be able to connect to the server.

It’s important to notice that only “user’s” data is encrypted. Main headers of TACACS+ protocol are not encrypted. As I know, the encryption works in next the following way:

Encrypted data (enc_data) is a result of the XOR operation with data (data) and a special string (pseudo_pad)
pseudo_pad is a concatenation of several MD5 hashes.
pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]}
MD5-hashes are created from data of headers of TACACS+ packets and the key (PSK) and a previous MD5 hash (consequently, there is no a previous hash for a first MD5 hash).
MD5_1 = MD5{session_id, key, version, seq_no}
MD5_2 = MD5{session_id, key, version, seq_no, MD5_1}
MD5_n = MD5{session_id, key, version, seq_no, MD5_n-1}
session_id – is a random identifier of a session; version – a version of TACACS+ protocol;
seq_no – incremented number of a packet of a session; key – PSK.

And as we can see from the picture the data is encrypted.

Attack №2

So, let’s set the situation for the next attack. There is a Cisco network device and there is a TACACS+ server. And we’ve got some of encrypted TACACS+ traffic between the device and the server (with obtained by Man-in-the-Middle attack, for example). It’s obviously, that our goal is to get a PSK. With it we will be able to decrypt the traffic and get valid accounts from it.

Now, let us see how we can do it. At first, we can see that any MD5 hash (especially first MD5) consists of several values. But only one of them is unknown for us – a PSK. All other values (session_id, version, seq_no) we can get from headers of the TACACS+ packet. Thus, the whole idea of the task comes to a typical one – the local/offline bruteforce attack to get the PSK. And we know that we can bruteforce really-really fast with MD5. But at firstin the beginning we need to get a first MD5 hash (MD5_1)

Now, let’s remember that XOP is a reversibility operation. In the other words, as we have the operation “data^pseudo_pad=enc_data”, we can convert it to “pseudo_pad=data^enc_data”. Also, there is another property: changing of a part of string doesn’t influence (change) other parts of string in the XOR operation. So, we have that MD5_1 is just a first part of “pseudo_pad”. Exactly, 128 bits (or 16 bytes) of “pseudo_pad”. And if we want do get MD5_1, we need to know 16 bytes of encrypted and decrypted data (“data”). We can get any amount of encrypted data from the traffic. But where/how can we get 16 bytes of decrypted data?

It is important to note that formats of requests and responses are different for Authentication, Authorization, Accounting types of the TACACS+ packets. However, there is a common idea for all of them: there is almost no unknown or random values in the first 16 bytes of any packet type.

I will not go deep in technical details of each packet types. Just one example to show an the idea. This is the first response (pic. below) from a TACACS+-server. It consists of several fields having single meaning and a greeting message of a Cisco device for a user. As we can easily get the message from the Cisco device with any connection to it. Thus, we know all values of fields.
Therefore, we almost always know decrypted data of the first 16 bytes of any packet. So we can get MD5_1 and perform a bruteforcing attack locally. If we have success with our attack, we will be able to decrypt the whole traffic.

To simplify packet parsing and receiving MD5_1, I've created a little script – tac2cat.py. It’s a part of the TacoTaco project.

Attack №3

So, the situation of the last attack. There is a Cisco network device and a TACACS+ server. We perform an active MaiMan-In-the-Middle attack (we can change the traffic). Our goal is to get full access to the Cisco device.

Reviewing the protocol, I have spotted two additional “features”.

The first one is that the protocol doesn’t have the integrity checking. So, if we change some parts of the encrypted traffic, it changes decrypted traffic (because it’s just XOR), but a TACACS+ server can’t find out the changes and processes the changed traffic in a usual way.

The second feature is about the format of TACACS+ packets. For Authentication and Authorization process, the first byte of reply contains the result of access granting.
For example, “0x01” if the server authenticates the user (grants access), and “0x02” if the user’s credentials is not valid.
Altogether, we just need to change one byte of the reply from the server! In a common view, we need to perform next consequence:
  • Get the “pseudo_pad” of this byte: XOR the encrypted byte and the decrypted byte (we know the value of the decrypted byte, because if we input incorrect credentials, we know that the server refuses the access and sets 0x2.
  • XOR this “pseudo_pad” with the byte for successful authentication (0x01)
  • Out this new byte into the encrypted packet and sent it to the server.
Therefore, with the MitM attack we can change the traffic and grant access (authentication, authorization) for any user with invalid credentials. Also we can bypass the authentication for the privilege escalation on a Cisco device (“enable” password).

To perform the MitM attack I created a little tool – tacflip.py. It’s a part of the TacoTaco project.

I’ve successfully checked the attack (authentication, authorization bypass and privilege escalation) on a 7200 Cisco route in GNS3 and an open source realization of a TACACS+ server – tac_plus. There is a part of configuration file of the router:

aaa authentication login default group tacacs+ local
aaa authentication enable default group tacacs+
aaa authorization exec default group tacacs+ local
tacacs-server host
tacacs-server directed-request
tacacs-server key 12345

And there is a small demo video of authentication/authorization bypass, privilege escalation and following command execution on the Cisco route.

Sometimes it happens…

In 2000 Solar Designer made an interesting research of the TACACS+ protocol https://goo.gl/E2IGnk. For example, he found the opportunity of a replay attack, a user’s password’s length disclosure, a bit flipping attack and etc. But I didn’t find PoCs for them.

My “research” of TACACS+ protocol is just some thoughts after some random interactions with the protocol during long time. Because of that, I forgot
about the results of Solar Designer and reopened some of his findings.

So, may be the most important result of my work may be is the TacoTaco project https://github.com/GrrrDog/TacoTaco. It consists of scripts for to realization execute of the attacks of this article.


In my opinion, the TACACS+ protocol does not give a necessary level of protection against MitM attacks nowadays.

On the other hand, sometimes it’s hard to perform all of these attacks due to the fact of Cisco’s recommendation to locate a TACACS+ server in a special management VLAN (it is accessible only for admins and network devices). Of course, there are ways to penetrate to a management VLAN, but it’s another task.