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)

data^pseudo_pad=enc_data

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}

Where:
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 192.168.182.136
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.

Conclusion:

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.

Universal way to bypass Group Policy (SRP) by Limited User

(It's the post from July 2011)

What is it? Group policy is a powerful feature of Windows OS.
From wiki: “Group Policy is a set of rules which control the working environment of user accounts and computer accounts. Group Policy provides the centralized management and configuration of operating systems, applications and users' settings in an Active Directory environment“

For example, it can block users’ access to Regedit or IE proxy changing. So it is additional limits for users, besides file system and other permissions. One of the main parts of Group Policy is represented by Software Restriction Policy (SRP). Administrator can set a little list of software which can be run by limited user with SRP. Therefore, SRP can level up security of whole system by restricting user’s rights.

How does it work? 

When a user launches a process it’s the parent process that checks SRP to see if the execution of the child should be allowed or blocked. The parent process uses NtQueryValueKey to query the Registry value HKLM\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\TransparentEnabled, which if present and non-zero indicates that SRP is turned on.

How can we bypass it? 

There are few different ways. Their main idea is that SRP check is situated in user space. A parent process is owned by a limited user. Therefore, a user can bypass SRP by different memory manipulations.

Attack!

Marc Russinovich posted a great tool – Gpdisable and a good explanation of SRP on his blog. Gpdisable is now unavailable, but it can be found in Internet Gpdisable uses dll-injection techniques, to inject into a parent process memory. Then “it fools the SRP code by returning an error value”, when SRP tries to query TransparentEnabled. Therefore, a parent process can run any other process.

Problem. 

Gpdisable consists of 2 files – gpdisable.exe and gpdisable.dll. gpdisable.exe – inject DLL into process. gpdisable.dll – DLL for bypassing SRP. But in real life, there is a problem - to inject gpdisable.dll. Because in a good restricted system a user has access to run only software from white list. So you should run gpdisable.exe, but you don’t have right to do it.

Real Attack!

When I read about binary planting, I’ve got an idea how we can inject gpdisable.dll in process. It’s simple – dll-hijacking. But almost all big software (like MS Word, Excel and Notepad :) doesn’t have such vulnerabilities. That’s bad. But if we use "advanced" dll-hijacking (COM server-based binary planting), we can do it almost of all software. I won’t retell an idea of such binary planting, but you can get it from Acros Security Blog.

Steps to bypass SRP for XP:

• rename gpdisable.dll to deskpan.dll;
• create a new folder and name it as files.{42071714-76d4-11d1-8b24-00a0c9068ff3};
• place deskpan.dll to the new folder;
• open the folder;
• create a new rich text document in the folder;
• double-click the rich-text document.
• Wordpad runs with gpdisable.dll
• Bypassed :) We can run any process.

There are similar steps for Windows Vista/7 and others. In addition, all that steps we can do from “Open” or “Save As” dialogue, that can be useful for Citrix systems.

Thanks to Ryan Sears.
And thank you, for your attention. Alexey Tyurin

NetBIOS spoofing for attacks on browser

(It's the post from January 2012)
Sometime ago during pentest NetBIOS protocol got my attention. Especially, NetBIOS naming and its co-work with DNS.
NetBIOS is an old protocol, distributed world-wide, but it doesn’t have many security mechanisms. And I think that many interesting things are born in different technologies’ interception. So I started a little research and I want to show some results of it.

NetBIOS Intro

When I got into the NetBIOS-protocol, I’ve got an idea to create a Metasploit module to perform NBNS-spoofing, but Tim Medin passes ahead of me :) Almost a year ago, he created that module (auxiliary/spoof/nbns/nbns_response). In addition, he wrote a great post about using of NBNS-spoofing for NTLM-relay attack. A bit later I’ll add his trick to SMBRelay Bible, if he accepts it :)
Then I tried to improve his ideas…

Old Tricks 

Tim wrote two interesting details.
The first is a sequence of resolution IP-addresses in Windows OS:
1) local hosts file - C:\Windows\System32\drivers\etc\hosts
2) DNS
3) NetBIOS Name Service

Secondly, all modern browsers have “intelligent address bar”. This bar is used as address bar and as a search bar at the same time. When a user enters a word in it, a browser tries to access a host with such name and only then it tries to search this word.
For example, if I enter “dsecrg” in address bar of my browser, it tries to get IP-address of “dsecrg” by DNS, then by NetBIOS Name Service and after all “dsecrg” is gone to default search engine.

Therefore, we can use a NBNS-spoofing attack and send reply with our IP-address to user’s browser, when it tries to resolve “dsecrg” by NBNS. Then user’s browser connects to our web-server.

New Tricks

But let’s go forward. As we can see, if Windows can’t perform IP-resolution via DNS, it tries NBNS.
And what will be if we try to connect to aaa.google.com?

There is analogue situation. DNS is the first, NBNS is the second… And we can spoof Internet addresses! So, there we have that NBNS-spoofing is analogue to DNS-spoofing.

Is NBNS-spoofing attack better than DNS-spoofing?
No, it is not. Because NBNS-spoofing attack has some rough limitations:
1) It works only in local networks
2) It has hostname length limitation (15 characters)
3) It can spoof only hostnames which DNS can’t resolve. But we can bypass this limitation, if we can make DoS attack on DNS server.

By the way, NBNS-spoofing attack can be very useful in some situations. The main plus of this attack is that it doesn’t send any illegal traffic. DNS-spoofing or arp-poisoning are “aggressive” attacks and perform much “bad” traffic. So, it’s harder to detect NBNS-spoofing attack by IPS/IDS systems. In addition, it can be useful when DNSSEC is used in a network.

Ok, but what can we gain with NBNS-spoofing’s limitations?
Yes, we can spoof only hostname which it can’t find via DNS (without DoS of DNS server), but we can spoof subdomains! And it is enough for us.
There is a list, what we can do, if we can spoof subdomain of attacking domain and “redirect” user to our web-server.

1) Stole session cookie
Cookies can be set to all subdomains of a domain (domain=.foo.com;). So if we spoof a subdomain of a domain, browser sends us a victim’s session cookies.
Therefore, if a cookie is set without a domain-field (such situation is very often), Internet Explorer sets them to a domain and all its subdomains. But, by RFC, IE should set it only to current domain. (Researched by d0znpp)
As we can see, we can steal cookies very often. 

2) Session Fixation
Same Origin Policies set an interesting exception to cross domain interaction rules. Subdomain can set (and rewrite) a cookie of domain. For example, aaa.google.com can set cookie to google.com, but couldn’t set to bbb.google.com or zzz.aaa.google.com.
We can use it.
If a web-application of a server has session fixation vulnerability, we can spoof subdomain of this server and set cookie to it.*A strange moment. During test I was trying to set cookie to “localhost” from subdomain of localhost, but I couldn’t do it. 

3) Cross domain policies bypass.
It is a frequent situation, when * is used for domain in crossdomain.xml.
For example, adobe.com:
<allow-access-from domain="*.adobe.com">
We can spoof subdomain (aaa.adobe.com) and get full session riding via Flash.

4) Phishing
Classic phishing attacks…

Catch a user

In all these attack vectors, we have a little problem. How to enforce user to come to our (fake) subdomain? For resolving the problem, we can use a NBNS-spoofing attack :)
Example of cookie stealing for example.com:
1) Run NBNS-spoofing against all domains
2) Run our web-server with a little script, which should:
- Collect incoming cookies (sorted by Host http-request field)
- Reply a simple html page with hidden iframe with “src=aaa.example.com”
3) When user inserts into browser any inexistent domain name, our NBNS-spoofing attack will work and his browser will come to our web-server. Then the browser will try to open aaa.example.com, NBNS-spoofing attack will work again and we’ll get cookies from example.com.

Outro

NBNS-spoofing attack is an interesting stuff and it’s not looking too hard to realize such attacks in real life.