Security | IPNET

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: http://www.cisco.com/en/US/products/products_security_advisory09186a0080b74117.shtml

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.

Cisco: How can MSS help to solve issues in VPN communication

Since a week, I’m stretching my brains to solve a communication problem over a VPN connection. The problem was that connections like SSH over VPN were not successfully completed. Imagine site A (Paris – remote end) and site B (Hamburg – local end).

In the back, of this sites, servers and clients. If somebody tried to connect from a client in site A over SSH to a server in site B, the initial authentication protocol was successful, but as soon as a command was typed on the terminal (like ls -la or ps aux) and the server had to return a bunch of results, the SSH console was completely stuck

Immediately I was thinking that this has to do with MTU size (default 1500 bytes on each site) and the DF (Don’t fragment) bit being set. I have tested SSH over Windows and Linux machine and all the time the DF bit was set ON:

I think it is obvious why I did paint over IP addresses. Interesting part is that only SSH was having this DF bit set. I’ve tried also FTP or regular ping, and there, I could not see the DF bit on.

You image what problems I had. MTU being 1500 Bytes and DF bit on, the packet was not fragmented. With the IPsec VPN overhead, the packet could end up to 1604 bytes (together with point-to-point GRE overhead), so most of the packets got dropped.

If I would decrease the MTU size on the client / server interface to let’s say 1300 bytes, then everything was working fine. However, this was not a scalable solution when you have more clients and servers, so to prevent future issues, I keep on looking for another solution. The salvation came from “ip tcp mss-adjust” command.

You probably know what MSS is, but here is a small description. The maximum segment size (MSS) is an option of the TCP protocol that specifies the largest amount of data, specified in bytes, that a computer or communications device can receive in a single, unfragmented piece. It does not count the TCP header or the IP header. For optimum communications, the number of bytes in the data segment and the headers must not add up to more than the number of bytes in the maximum transmission unit (MTU).

This Maximum Segment Size (MSS) announcement (often mistakenly called a negotiation) is sent from the data receiver to the data sender and says “I can accept TCP segments up to size “X bytes”.

Typically a host bases its MSS value on its outgoing interface’s maximum transmission unit (MTU) size because if the MSS value is set too low, the result is an inefficient use of bandwidth; More packets are required to transmit the data. An MSS value that is set too high could result in an IP datagram that is too large to send and that must be fragmented. In my case if the MTU was 1500, the MSS was also 1500 bytes. This value didn’t help me at all, due to the issues that I’ve mentioned above.

So, instead of changing every device MTU size to a lower value than 1500 bytes, I’ve decided to change the MSS to a reasonable value that would solve my problem. On Cisco devices, you can configure the MSS in a few straightforward steps:

# configure terminal
# interface FastEthernet 0/0
# ip tcp adjust-mss 1300

The 1300 Bytes is just an example in my case. This value can be something between 500 and 1460 bytes.

Next time when you have problems with connections over VPN, try to se the MSS to a lower value and see if it’s working. If it is, then you are saved. If not…maybe your problem is not related to this topic.

Web Server Directory Traversal Vulnerability in Cisco CDS

The Cisco Internet Streamer application, part of the Cisco Content Delivery System, contains a directory traversal vulnerability on its web server component that allows for arbitrary file access. By exploiting this vulnerability, an attacker may be able to read arbitrary files on the device, outside of the web server document directory, by using a specially crafted URL.

An unauthenticated attacker may be able to exploit this issue to access sensitive information, including the password files and system logs, which could be leveraged to launch subsequent attacks.

All versions of system software on the Cisco Internet Streamer application are vulnerable prior to the first fixed release, but Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available.

This vulnerability can be exploited over all open HTTP ports; TCP ports 80 (Default HTTP port), 443 (Default HTTPS port) and 8090 (Alternate HTTP and HTTPS port), as well as those that are configured as part of the HTTP proxy.

As an interim step prior to upgrading the Cisco content delivery system software, it is possible to deny access to sensitive directories via service rules. The following example shows denying access to move up a directory level. This also caters for other directory moves, such as “\.\./”, “.\./” or “\../”:

rule enable
rule action block pattern-list 1
rule pattern-list 1 url-regex ^http://.*/../.*
rule pattern-list 1 url-regex ^https://.*/../.*

If you are affected by this issue or just want to read more please do it at http://www.cisco.com/warp/public/707/cisco-sa-20100721-spcdn.shtml.

Cisco: Multiple Vulnerabilities in Cisco PGW Softswitch

Multiple vulnerabilities exist in the Cisco PGW 2200 Softswitch series of products and they are related to processing Session Initiation Protocol (SIP) or Media Gateway Control Protocol (MGCP) messages.

SIP is a popular signaling protocol used to manage voice and video calls across IP networks such as the Internet. SIP is responsible for handling all aspects of call setup and termination. Voice and video are the most popular types of sessions that SIP handles, but the protocol is flexible to accommodate for other applications that require call setup and termination. SIP call signaling can use UDP (port 5060), TCP (port 5060), or Transport Layer Security (TLS; TCP port 5061) as the underlying transport protocol.

MGCP is the protocol for controlling telephony gateways from external call control elements known as media gateway controllers or call agents. A telephony gateway is a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or other packet networks.

Multiple DoS vulnerabilities exist in the Cisco PGW 2200 Softswitch SIP implementation, and one vulnerability is in the MGCP implementation.

The following vulnerabilities can cause affected devices to crash:

CSCsl39126 (registered customers only), CVE ID CVE-2010-0601
CSCsk32606 (registered customers only), CVE ID CVE-2010-0602
CSCsk40030 (registered customers only), CVE ID CVE-2010-0603
CSCsk38165 (registered customers only), CVE ID CVE-2010-0604
CSCsk44115 (registered customers only), CVE ID CVE-2010-1561
CSCsj98521 (registered customers only), CVE ID CVE-2010-1562
CSCsk04588 (registered customers only), CVE ID CVE-2010-1563
CSCsz13590 (registered customers only), CVE ID CVE-2010-1567

The following vulnerability may cause an affected device to be unable to accept or create a new TCP connection. Existing calls will not be terminated, but no new SIP connections will be established. If exploited, this vulnerability will also prevent the device from establishing any new HTTP, SSH or Telnet sessions.

CSCsk13561 (registered customers only), CVE ID CVE-2010-1565

There are no workarounds for the vulnerabilities in this advisory.