Cisco Secure ACS Unauthorized Password Change Vulnerability

I just finished testing a solution involving ACS 5.2 and Active Directory, when this “good news” hit me in face. It seems that ACS has a vulnerability that allow an unauthenticated attacker to change the password of any user account to any value without providing the account’s previous password.

You might think that this affects older version of the ACS, but in fact all recent versions are affected by this bug (CSCtl77440):

Vulnerable Products

The following Cisco Secure ACS versions are affected by this vulnerability:

  • Cisco Secure ACS version 5.1 with patch 3, 4, or 5 (or any combination of these patches) installed and without patch 6 or later installed
  • Cisco Secure ACS version 5.2 without any patches installed
  • Cisco Secure ACS version 5.2 with patch 1 or 2 (or both of these patches) installed and without patch 3 or later installed

The previous list applies to both the hardware appliance and the software-only versions of the product.

There is no workaround for this bug, but Cisco recommend some actions to limit this problem. One of the recommendation is to limit the number of machines that have direct access to the ACS environment. If you provide UCP (User Change Password) service, then it is recommended to stop it and don’t allow any machine that offer UCP access to ACS. These actions would help if you have a central management area where you connect remotely in order to access your ACS servers.

Now for some good news. It seems that this vulnerability works only if the user is defined in the ACS internal identity store, so if you are using external identity store like Active Directory you are somehow safe. Here are the situations in which this exploit does not work:

This vulnerability cannot be used to change the password for the following types of users accounts:

  • User accounts that are defined on external identity stores such as a Lightweight Directory Access Protocol (LDAP) server, a Microsoft Active Directory server, an RSA SecurID server, or an external RADIUS server
  • System administrator accounts for the Cisco Secure ACS server itself that have been configured through the web-based interface
  • Users accounts for the Cisco Secure ACS server itself that have been configured through the username username password password CLI command

This vulnerability does not allow an attacker to perform any other changes to the ACS database. That is, an attacker cannot change access policies, device properties, or any user attributes except the user password.

For more information have a look to:

ACS 5.1 integration with Active Directory [Part 1]

If sometime you need to test a configuration regarding ACS integration with Microsoft Active Directory, or if you think that this is something that you want to try, then continue reading:

Part 1 – Active Directory installation

Part 2 – ACS 5.1 integration with AD

Part 3 – Some basic testing to prove that everything is working

I really hope that I’ll have sufficient time to complete this tutorial in the next weeks. As you probably saw already, in last months there were just some articles posted here due to the fact I’m very busy (daily business, CCIE learning, some new projects…). Anyway, let’s proceed….

My scenario is based on 2 virtual machines (VirtualBox) and 2 switches (C3560) for testing. I’ll add a topology design in Part 2 of this tutorial. One of the virtual machines is hosting the ACS system and the other one a Windows server (2003 / 2008) with Active Directory.

Let’s start with Active Directory installation. You need a Windows 2003 or 2008 system installed on one virtual machine, or if you afford physical hardware then you can use one. Windows 2003 / 2008 can be a trial from Microsoft website, as you can use that trial up to 240 days. Much more than the ACS trial (90 days). I have a 2003 distribution and I really recommend it because you need less resources than with Win 2008. Be aware that latest version of 2008, called R2 support only 64 bit processor. If you have an older machine, just stick with Win 2003 or some early version of 2008 than R2 release.

After you have a fresh machine with Windows 2003 / 2008 installation, please follow the next steps:

1. Click Start, click Run, type dcpromo.exe, and then click OK. You should see something like this:

2. Click Next and you can start the Active Directory installation

3. Choose Domain controller for a new domain. I assume, that you will not try this in a productive AD environment, as it can break things. Just resume to your virtual machines or close test environment and everything will be fine

4. Pick Domain in a new forest.

5. This domain can be whatever you want. Really! Just remember what you type in there. I have there testdomain.local

6. The NetBIOS field will be automatically completed. If for some reason it is empty, add there whatever you have in from of your . (dot) in the FQDN. I have here TESTDOMAIN

7. The location where AD will be install on your hard drive. It is automatically completed and for this test I think is the best to let it default

8.Again, a default location that you better not touch

9. If you really want to test something, you can choose a different option below, but again for this test is the best to let AD Wizard to install the DNS server also. The best thing here is that if you let the Wizard install it then you don’t have to worry that you are missing some entries there, as everything will be in place.

10. I’m using in the example below a Windows 2003 distribution. If you have a 2008 one, then the next screen might look different. Just keep in mind to choose the highest possible option. Anyway you will not need backward compatibility with older systems.

11. Choose a password and remember it

12. You have a summary there. Check it to see that everything is as you want.

13. Let it work for some minutes and you’re done.

You’re done setting up the Active Directory. Come back for Part 2 where we will connect ACS 5.1 to AD and for Part 3  where we will add some users on AD and do a little testing.