3 Attacks on TACACS + from Cisco
I would like to tell today the results of my small research related to the TACACS + protocol, moreover from the Pentester point of view. I did not have to use the protocol directly, so I can not mention any subtleties.
Terminal Access Controller Access-Control System Plus (TACACS +) is a special Cisco protocol for AAA (authentication, authorization, and accounting). That is, this is a protocol for centralized access control - most often access to Cisco, but you can screw something else.
So, usually one or two servers go up with a TACACS + service on port 49 of the TCP protocol, and on all devices it is configured to use it. Thus, when a user wants to authenticate on a switch, router or other device, the device sends its authentication data to the TACACS + server, where they are checked, and the decision is made to allow access, which is reported in the response packets
')
Convenient, centralized. You can configure different privileges for different users on different devices. There is access and action logging on the server side. You can tie on top of another access centralization, such as AD or LDAP. There is an open source server implementation (Cisco once officially posted the code).
The first "attack" is more like a trick than a full-fledged attack, but it can be useful in certain situations.
So, let us imagine that during pentest we received a config from a tsiska (for example, pulling it from a TFTP server). This, of course, is good, but even if we successfully scroll the local account from the device, we will not be able to log in as the device will check the account on the TACACS + server.
But here it is worth remembering the typical configuration when connecting to TACACS +.
Imagine that something happened with the TACACS + server and it is not available for a Cisco device, but the admin may need to log in to the device, but he cannot do it. For such purposes, Cisco devices support various “types” of authentication that the administrator must specify during configuration.
So, the classic authentication configuration for Cisco with TACACS + looks like this:
Here, the last two words are important to us, which indicate that the authentication will first be verified using TACACS +, and later - by searching the local user database. Moreover, if the user is not found in TACACS +, then it will not be checked locally.
The essence of the first attack lies in the fact that we, as attacking, doS server TACACS +, then connect to the desired Cisco device using a local account. And DoS is meant in a wider sense - you can send a special packet (once found) and a large number of TCP connections ...
Before proceeding to attacks 2 and 3, you need to learn something else about the TACACS + protocol. The data in the protocol is transmitted either by plain text, or you can enable encryption. It is organized on the basis of PSK (Pre-Shared Key), i.e. the administrator himself specifies one key on the TACACS + server and all clients connecting to it (devices). Moreover, only user data is encrypted, TACACS + headers are not encrypted. Encryption itself, as far as I know, happens as follows:
Encrypted data (enc_data) is the result of a XOR operation with data (data) and a special string - pseudo_pad.
pseudo_pad is a sequence of MD5 hashes.
MD5 hashes are created based on data from TACACS + -packets headers, plus a shared key (PSK), plus the previous hash (for the first MD5, respectively, it does not). Those.:
Where session_id is a random session identifier; version — protocol version; seq_no - incremental package number; key - psk.
And it seems like the data is encrypted ...
So, let's specify the task and clarify the situation. We have a Cisco device and a TACACS + server. And we can get encrypted TACACS + traffic between them (using Man-in-the-Middle, for example). Our goal is to get PSK, and using it to decrypt traffic and get valid accounts.
Now let's see what we can do. To begin with, as we see, the MD5 value is created from several values, but we don’t know just one of them - the common key, while all the others can be obtained from the TACACS + -packet headers. Thus, if one asks for the task, then it all comes down to brute-force (without this, nowhere :) pick up the key. At the same time, MD5 can be offline offline very quickly. But for this we need to get the value of MD5_1.
Next, we must remember that XOR is a reversible operation. Those. if we had the operation “data ^ pseudo_pad = enc_data”, then “pseudo_pad = data ^ enc_data”. At the same time, XOR is the simplest operation and changing a part of a string does not entail changes in another part of the string. We get MD5_1 - this is the initial part of the pseudo_pad. More specifically, 128 bits or 16 bytes. And so, to get MD5_1, we need to know the first 16 bytes of the encrypted data and 16 bytes of the original data. And if we have encrypted data in any amount of traffic, then how do we get 16 bytes of the original data?
It is important to note: the format is different for requests and responses, as well as for their various types (we must remember that TACACS + is AAA - Authentication, Authorization, Accounting).
But the general pattern is preserved in them - random or unknown to us values ​​in the first 16 bytes are almost absent.
I will not go into details and give only the most convenient example. This is the first response from the TACACS + server. It contains several fields with a single value and a welcome line from the Cisco device to the user. And since we can get a greeting line when connecting, it turns out that we all know the values ​​for sure.
Thus, we almost exactly know what unencrypted data is in the package, which allows us to get MD5_1 and locally locate it. If successful, we will be able to fully decipher the traffic.
To simplify the task of parsing the package and extracting MD5_1, I sketched the toolbar: tac2cat.py (as part of the TacoTaco project, see below)
I spoke about these two attacks at a recent meeting of Defcon Russia at CC'2015. And in the good traditions of our group, during the discussion I was given a couple of practical advice. One of them was to look at the possibility of bit flipping.
So, the script of the last attack. We have a Cisco device and a TACACS + server. We can conduct an active Man-in-the-Middle attack (i.e., we can change traffic). The goal is to “break everything”
Looking closely at the protocol, two more important features emerged. The first was that the protocol lacked integrity checking. Those. if we changed some value of the encrypted traffic, it affected the decrypted traffic (XOR) and the server “ate” it, not noticing the changes.
The second feature was in the package format. For both authentication packets and authorization, when requesting permission, the primary response is transmitted in the first byte of the response. For example, 0x01 - authentication is successful, 0x02 - not successful.
Total, you need to change only one byte! In its simplest form, we must do the following:
Thus, in the MitM attack, we will give permission for any incorrect data for authorization or authentication. Moreover, in the same way we bypass authentication for elevation of privileges on a Cisco device (enable password).
As a result, to implement this attack was written tulza - tacflip.py (as part of the TacoTaco project)
Its operation was tested (bypassing authentication and authorization) with 7200-ciska in GNS3 and open source implementation of TACACS + server - tac_plus.
A piece of TACACS + config looks like this.
And here is a small demo video of the input to the device, privilege escalation and command execution.
But my “resherch” of this protocol is just a list of random interactions with the protocol for a long time, and not a targeted study. Because of what I forgot about the results of the Solar Designer, I rediscovered something.
Perhaps the main result of my labors are working tools (while in the beta stage).
Meet the TacoTaco Project github.com/GrrrDog/TacoTaco
You can probably calculate that the TACACS + protocol with its implementation does not provide the necessary level of protection against MitM attacks.
On the other hand, these attacks are somewhat difficult, as often TACACS + servers are located in VLANs, available only to administrators and network equipment (such as recommendations from Cisco). But this is another task.
What is TACACS +
Terminal Access Controller Access-Control System Plus (TACACS +) is a special Cisco protocol for AAA (authentication, authorization, and accounting). That is, this is a protocol for centralized access control - most often access to Cisco, but you can screw something else.
So, usually one or two servers go up with a TACACS + service on port 49 of the TCP protocol, and on all devices it is configured to use it. Thus, when a user wants to authenticate on a switch, router or other device, the device sends its authentication data to the TACACS + server, where they are checked, and the decision is made to allow access, which is reported in the response packets
')
Convenient, centralized. You can configure different privileges for different users on different devices. There is access and action logging on the server side. You can tie on top of another access centralization, such as AD or LDAP. There is an open source server implementation (Cisco once officially posted the code).
Attack # 1
The first "attack" is more like a trick than a full-fledged attack, but it can be useful in certain situations.
So, let us imagine that during pentest we received a config from a tsiska (for example, pulling it from a TFTP server). This, of course, is good, but even if we successfully scroll the local account from the device, we will not be able to log in as the device will check the account on the TACACS + server.
But here it is worth remembering the typical configuration when connecting to TACACS +.
Imagine that something happened with the TACACS + server and it is not available for a Cisco device, but the admin may need to log in to the device, but he cannot do it. For such purposes, Cisco devices support various “types” of authentication that the administrator must specify during configuration.
So, the classic authentication configuration for Cisco with TACACS + looks like this:
aaa authentication login default group tacacs+ local Here, the last two words are important to us, which indicate that the authentication will first be verified using TACACS +, and later - by searching the local user database. Moreover, if the user is not found in TACACS +, then it will not be checked locally.
The essence of the first attack lies in the fact that we, as attacking, doS server TACACS +, then connect to the desired Cisco device using a local account. And DoS is meant in a wider sense - you can send a special packet (once found) and a large number of TCP connections ...
Intros for attacks 2 and 3
Before proceeding to attacks 2 and 3, you need to learn something else about the TACACS + protocol. The data in the protocol is transmitted either by plain text, or you can enable encryption. It is organized on the basis of PSK (Pre-Shared Key), i.e. the administrator himself specifies one key on the TACACS + server and all clients connecting to it (devices). Moreover, only user data is encrypted, TACACS + headers are not encrypted. Encryption itself, as far as I know, happens as follows:
Encrypted data (enc_data) is the result of a XOR operation with data (data) and a special string - pseudo_pad.
data^pseudo_pad=enc_data pseudo_pad is a sequence of MD5 hashes.
pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} MD5 hashes are created based on data from TACACS + -packets headers, plus a shared key (PSK), plus the previous hash (for the first MD5, respectively, it does not). Those.:
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} Where session_id is a random session identifier; version — protocol version; seq_no - incremental package number; key - psk.
And it seems like the data is encrypted ...
Attack # 2
So, let's specify the task and clarify the situation. We have a Cisco device and a TACACS + server. And we can get encrypted TACACS + traffic between them (using Man-in-the-Middle, for example). Our goal is to get PSK, and using it to decrypt traffic and get valid accounts.
Now let's see what we can do. To begin with, as we see, the MD5 value is created from several values, but we don’t know just one of them - the common key, while all the others can be obtained from the TACACS + -packet headers. Thus, if one asks for the task, then it all comes down to brute-force (without this, nowhere :) pick up the key. At the same time, MD5 can be offline offline very quickly. But for this we need to get the value of MD5_1.
Next, we must remember that XOR is a reversible operation. Those. if we had the operation “data ^ pseudo_pad = enc_data”, then “pseudo_pad = data ^ enc_data”. At the same time, XOR is the simplest operation and changing a part of a string does not entail changes in another part of the string. We get MD5_1 - this is the initial part of the pseudo_pad. More specifically, 128 bits or 16 bytes. And so, to get MD5_1, we need to know the first 16 bytes of the encrypted data and 16 bytes of the original data. And if we have encrypted data in any amount of traffic, then how do we get 16 bytes of the original data?
It is important to note: the format is different for requests and responses, as well as for their various types (we must remember that TACACS + is AAA - Authentication, Authorization, Accounting).
But the general pattern is preserved in them - random or unknown to us values ​​in the first 16 bytes are almost absent.
I will not go into details and give only the most convenient example. This is the first response from the TACACS + server. It contains several fields with a single value and a welcome line from the Cisco device to the user. And since we can get a greeting line when connecting, it turns out that we all know the values ​​for sure.
Thus, we almost exactly know what unencrypted data is in the package, which allows us to get MD5_1 and locally locate it. If successful, we will be able to fully decipher the traffic.
To simplify the task of parsing the package and extracting MD5_1, I sketched the toolbar: tac2cat.py (as part of the TacoTaco project, see below)
Attack number 3
I spoke about these two attacks at a recent meeting of Defcon Russia at CC'2015. And in the good traditions of our group, during the discussion I was given a couple of practical advice. One of them was to look at the possibility of bit flipping.
So, the script of the last attack. We have a Cisco device and a TACACS + server. We can conduct an active Man-in-the-Middle attack (i.e., we can change traffic). The goal is to “break everything”
Looking closely at the protocol, two more important features emerged. The first was that the protocol lacked integrity checking. Those. if we changed some value of the encrypted traffic, it affected the decrypted traffic (XOR) and the server “ate” it, not noticing the changes.
The second feature was in the package format. For both authentication packets and authorization, when requesting permission, the primary response is transmitted in the first byte of the response. For example, 0x01 - authentication is successful, 0x02 - not successful.
Total, you need to change only one byte! In its simplest form, we must do the following:
- Get the pseudo_pad of this byte, XOR'nuv encrypted byte and the value known to us (if we enter incorrect data during authentication, then we know that the authentication will be denied to us - that is, the value will be 0x02)
- Re-XOR'nut pseudo_pad of this byte with a successful authentication byte (0x01)
- Change the byte in the encrypted traffic.
Thus, in the MitM attack, we will give permission for any incorrect data for authorization or authentication. Moreover, in the same way we bypass authentication for elevation of privileges on a Cisco device (enable password).
As a result, to implement this attack was written tulza - tacflip.py (as part of the TacoTaco project)
Its operation was tested (bypassing authentication and authorization) with 7200-ciska in GNS3 and open source implementation of TACACS + server - tac_plus.
A piece of TACACS + config looks like this.
aaa authentication login default group tacacs+ local aaa authentication enable default group tacacs+ aaa authorization exec default group tacacs+ local tacacs-server host 192.168.182.136 tacacs-server directed-request tacacs-server key 12345 And here is a small demo video of the input to the device, privilege escalation and command execution.
Situation…
In 2000, Solar Designer made an interesting protocol goo.gl/E2IGnk . For example, the possibility of replay attacks, or disclosure of the user's password length (due to the lack of padding), and something else (bit flipping) was discovered. But I did not find the practical implementation of them in public ...But my “resherch” of this protocol is just a list of random interactions with the protocol for a long time, and not a targeted study. Because of what I forgot about the results of the Solar Designer, I rediscovered something.
Perhaps the main result of my labors are working tools (while in the beta stage).
Meet the TacoTaco Project github.com/GrrrDog/TacoTaco
Total:
You can probably calculate that the TACACS + protocol with its implementation does not provide the necessary level of protection against MitM attacks.
On the other hand, these attacks are somewhat difficult, as often TACACS + servers are located in VLANs, available only to administrators and network equipment (such as recommendations from Cisco). But this is another task.
Source: https://habr.com/ru/post/267467/
All Articles