<<< Date Index >>>     <<< Thread Index >>>

RE: Cisco VPN Concentrator Groupname Enumeration Vulnerability



Cisco has made public a Security Notice, available at

http://www.cisco.com/warp/public/707/cisco-sn-20050624-vpn-grpname.shtml

which includes information about the issue, mitigation measures and
fixed software 
availability.

We would like to thank Roy Hills and NTA-Monitor for following
responsible disclosure practices and working with us on this issue.

Quidquid latine dictum sit, altum viditur

Dario Ciccarone
CCIE #10395 
Product Security Incident Response Team (PSIRT)
Cisco Systems, Inc.
dciccaro@xxxxxxxxx 

> -----Original Message-----
> From: Roy Hills [mailto:Roy.Hills@xxxxxxxxxxxxxxx] 
> Sent: Monday, June 20, 2005 9:51 AM
> To: bugtraq@xxxxxxxxxxxxxxxxx
> Subject: Cisco VPN Concentrator Groupname Enumeration Vulnerability
> 
> Cisco VPN Concentrator Groupname Enumeration Vulnerability
> 
> 1. Overview:
> 
> NTA Monitor has discovered a groupname enumeration 
> vulnerability in the 
> Cisco VPN 3000 series concentrator products while performing 
> a VPN security 
> test for a customer.
> 
> The vulnerability affects remote access VPNs with groupname 
> authentication.  Site-to-site VPN operation is not affected, 
> nor is remote 
> access with certificate authentication.  In practice, we find 
> that most 
> concentrators are configured for remote access with groupname 
> authentication, so this bug will affect the majority of users.
> 
> The vulnerability allows an attacker to use a dictionary attack to 
> determine valid group names on the concentrator.  Once a 
> valid group name 
> is determined, the attacker can then use this to obtain a 
> hash from the 
> concentrator, which can then be cracked offline to determine 
> the group 
> password.
> 
> Once an attacker has a valid groupname and group password, they can 
> potentially mount a Man-in-the-Middle (MitM) attack against 
> the XAUTH user 
> authentication mechanism.  This allows the attacker to snoop on VPN 
> traffic, alter VPN traffic, or gain access to the network 
> protected by the 
> VPN.  This MitM attack works even if strong authentication 
> such as SecurID 
> is used for user authentication.
> 
> 2. Vulnerability Details:
> 
> The vulnerability allows an attacker to enumerate valid 
> groupnames on a 
> Cisco VPN concentrator through either a dictionary attack, or 
> a brute-force 
> attack.  The issue exists because the concentrator responds to valid 
> groupnames differently to the way in which it responds to 
> invalid groupnames.
> 
> The exploit involves sending an IKE Aggressive Mode packet with the 
> groupname to be tested in the Identity (ID) payload.  The ID 
> Type is 11, 
> which corresponds to ID_KEY_ID.  If the specified groupname 
> is valid, the 
> concentrator will respond; if it is not valid, then the 
> concentrator will 
> not respond.  The ike-scan tool can be used to demonstrate 
> this vulnerability.
> 
> The vulnerability is present in both normal IKE over UDP, and 
> also Cisco 
> proprietary TCP-encapsulated IKE.  The ike-scan tool can use either 
> transport type: for Cisco IKE in TCP, you need to specify the option 
> --tcp=2.  When using TCP encapsulation, an invalid groupname 
> causes the 
> concentrator to send a TCP RST packet, which causes ike-scan 
> to return the 
> error message "recvfrom: Connection reset by peer".
> 
> The groupname guessing rate depends on the bandwidth between 
> the attacker's 
> system and the concentrator.  Because most of the group names 
> tried will be 
> incorrect, and therefore the concentrator won't respond, it's 
> only the 
> bandwidth from the attacker to the concentrator that matters; 
> the bandwidth 
> from the concentrator back to the attacker is not important.
> 
> An IKE aggressive mode packet with a single transform, using 
> Diffie-Hellman 
> group 2, and having an eight character groupname has an IKE 
> packet size of 
> 256 bytes.  Adding the eight byte UDP header and 20 byte IP 
> header gives a 
> total size of 284 bytes or 2,272 bits.  Assuming a link speed of 
> 2Mbits/sec, this gives a guessing rate of 2,000,000 / 2,272 = 
> 880 guesses 
> per second.
> 
> A guessing rate of 880 per second is 3,168,000 per hour or 
> 76,032,000 per 
> day.  This rate is sufficient to perform an extensive 
> dictionary attack, or 
> a limited brute-force attack.  The concentrator does not limit the 
> groupname guessing rate, nor does it blacklist hosts that 
> perform groupname 
> enumeration: in tests, it was possible to get a successful 
> response to a 
> valid groupname immediately after thousands of incorrect attempts.
> 
> Once a valid groupname is obtained, it is possible to use 
> this groupname to 
> obtain a hash from the concentrator, and mount an offline 
> password-guessing 
> attack against this hash to obtain the group password.  Because the 
> password-guessing process is offline, it is fast (hundreds of 
> thousands of 
> guesses per second), and will not cause the concentrator to log any 
> authentication failures.
> 
> A valid groupname and password allows the attacker to 
> complete IKE Phase-1 
> and establish an ISAKMP SA to the concentrator.  They can 
> then mount a 
> Man-in-the-Middle (MitM) attack against the second-stage 
> user-authentication process, which is typically XAUTH.
> 
> The offline password guessing process and MitM attack against 
> XAUTH are 
> detailed in the VPN flaws whitepaper at 
> http://www.nta-monitor.com/news/vpn-flaws/VPN-Flaws-Whitepaper.pdf.
> 
> 3.  Example:
> 
> The example below shows the two different concentrator 
> responses: the first 
> is for the valid groupname "finance", and the second is for 
> the invalid 
> groupname "administration".  We see that the concentrator 
> responds to valid 
> groupname, but not to the invalid one.  Because of this difference in 
> behaviour, it is possible to determine whether a given 
> groupname is valid 
> or not.
> 
> The ike-scan options used in this example are:
> 
> -A              Specify IKE Aggressive Mode.  The default for 
> ike-scan is 
> Main Mode.
> --idtype=11     Specify ID Type 11 for the ID payload.  This 
> corresponds to 
> ID_KEY_ID.
> -M              Multiline: Display each payload on a separate 
> line, which 
> makes the output easier to read.
> --auth=65001    Specify authentication method 65001, which 
> corresponds to 
> XAUTH.
> --id=finance    Specify the string to be used for the ID payload.
> 10.0.0.1        The IP address of the target VPN concentrator.
> 
> 3.1.  Response to valid groupname "finance":
> 
> $ ike-scan -A --idtype=11 -M --auth=65001 --id=finance 10.0.0.1
> Starting ike-scan 1.7.2 with 1 hosts 
> (http://www.nta-monitor.com/ike-scan/)
> 10.0.0.1 Aggressive Mode Handshake returned
> SA=(Enc=3DES Hash=MD5 Group=2:modp1024 Auth=XAUTH LifeType=Seconds 
> LifeDuration=28800)
> KeyExchange(128 bytes)
> Nonce(20 bytes)
> ID(Type=ID_IPV4_ADDR, Value=10.0.0.1)
> Hash(16 bytes)
> VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
> VID=09002689dfd6b712 (XAUTH)
> VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection)
> VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation)
> VID=65963c60eacf802220adccf628738746
> VID=1f07f70eaa6514d3b0fa96542a500400 (Cisco VPN Concentrator)
> 
> Ending ike-scan 1.7.2: 1 hosts scanned in 0.423 seconds (2.36 
> hosts/sec). 1 
> returned handshake;
> 0 returned notify
> 
> 3.2.  Response to invalid groupname "administration":
> 
> $ ike-scan -A --idtype=11 -M --auth=65001 --id=administration 10.0.0.1
> Starting ike-scan 1.7.2 with 1 hosts 
> (http://www.nta-monitor.com/ike-scan/)
> 
> Ending ike-scan 1.7.2: 1 hosts scanned in 0.594 seconds (1.68 
> hosts/sec). 0 
> returned handshake;
> 0 returned notify
> 
> 4.  Affected Versions:
> 
> The issue is believed to affect all models of Cisco VPN 3000 
> Concentrator: 
> 3005, 3015, 3020, 3030, 3060 and 3080.  We believe that all software 
> versions prior to 4.1.7.F are vulnerable.
> 
> 5.  Solution:
> 
> Upgrade to software version 4.1.7.F or later.  Cisco 
> customers with a valid 
> login may obtain the new software from the Cisco website.  
> Cisco has stated 
> in the release notes that this software version is not 
> vulnerable to the 
> issue, but NTA Monitor have not verified this claim.
> 
> Alternatively, use certificate authentication rather than group 
> authentication.  This vulnerability does not apply to certificate 
> authentication.
> 
> 6.  Timeline:
> 
> The vulnerability was first discovered on 8th July 2004, and 
> was reported 
> to Cisco's security team (PSIRT) on 20th September 2004.  
> Cisco were able 
> to reproduce the issue using the ike-scan tool, and bug ID 
> CSCeg00323 was 
> opened on 11th October 2004.  Software version 4.1.7.F, which 
> claims to 
> have fixed the issue, was released on 19th May 2005.
> 
> 7.  References:
> 
> Cisco Bug ID CSCeg00323 "vpn3k - inconsistent behavior on scanning".
> NTA Monitor advisory 
> http://www.nta-monitor.com/news/vpn-flaws/cisco/VPN-Concentrat
> or/index.htm
> 
> 8.  Other Information:
> 
> This is one of the classes of vulnerability discussed in the 
> VPN flaws 
> whitepaper, which was released in January 2005.  This whitepaper is 
> available at: 
> http://www.nta-monitor.com/news/vpn-flaws/VPN-Flaws-Whitepaper.pdf
> 
> Roy Hills
> 
> 
> --
> Roy Hills                                    Tel:   +44 1634 721855
> NTA Monitor Ltd                              FAX:   +44 1634 721844
> 14 Ashford House, Beaufort Court,
> Medway City Estate,                          Email: 
> Roy.Hills@xxxxxxxxxxxxxxx
> Rochester, Kent ME2 4FA, 
> UK                  WWW:   http://www.nta-monitor.com/  
> 

Attachment: cisco-vpn-grpname-adv.txt.asc
Description: cisco-vpn-grpname-adv.txt.asc