Message-ID: <1ca1c14105081809062ca50867@mail.gmail.com>
Date: Thu Aug 18 17:07:32 2005
From: synfinatic at gmail.com (ADT)
Subject: Juniper Netscreen VPN Username Enumeration
	Vulnerability

Uh, wouldn't it just be a lot easier to sniff the traffic between the
client and VPN gateway and get the IKE user id that way?  Agressive
mode puts the IKE id in *clear text* in the first message.  I'm not
sure how this is any more "special".   I'll agree it's different, but
it doesn't change the basic problem with Agressive mode: the identity
is not protected.

Of course, the NetScreen's could reply with some kind of response, but
may lead to resource exhastion.  Quote[1]:

  In both modes, the responder MUST always supply the key exchange
  payload prior to any authentication of the initiating peer. Creation
  of the key exchange payload requires a costly calculation. This
  leaves the responder exposed to denial of service attacks. Although
  implementation notes have addressed this to some extent, this can
  still be seen as a security risk.

As for "offline hash breaking attempts", re-read RFC2409 and see how
easy it really is.  Hint: the use of nonces really make things
difficult.  Doesn't excuse people from using their cat as their
password, but effectively prevents rainbow table attacks.  Would be
attackers against NetScreen or any vendor for that matter are prolly
better off finding a disgruntled employee and buying their
username/password/securID token for $100 (or a bar of chocolate [2]).

Sorry, but I don't think there's anything new or interesting here,
other then to remind people that Aggressive Mode isn't as good as Main
Mode, but everyone should of already of known that.

Disclaimer: I used to work for NetScreen/Juniper (hi Eric/Brian who
are no doubt reading this thread :)


[1]: http://www.ietf.org/proceedings/00jul/I-D/ipsec-ike-base-mode-02.txt

[2]: http://www.theregister.co.uk/2004/05/28/password_advice/

-Aaron

-- 
http://synfin.net

On 8/18/05, Roy Hills <Roy.Hills@...-monitor.com> wrote:
> Juniper Netscreen VPN Username Enumeration Vulnerability
> 
> 1. Overview
> 
> NTA Monitor has discovered a VPN username enumeration vulnerability in the
> Juniper Netscreen integrated Firewall/VPN products while performing a VPN
> security test for a customer.
> 
> The vulnerability affects remote access VPNs (known as "Dialup VPNs" in
> ScreenOS) using IKE with pre-shared key authentication.  Certificate
> authentication is not affected, nor is manual key authentication.  In
> practice, we find that most Netscreen systems are configured for remote
> access with pre-shared key authentication (called "AutoKey IKE with
> Preshared keys" in ScreenOS), so this bug will affect the majority of users.
> 
> The vulnerability allows an attacker to use a dictionary attack to
> determine valid VPN usernames on the Netscreen.  Once a valid username is
> discovered, the attacker can then use this to obtain a hash from the
> Netscreen, which can then be cracked offline to determine the associated
> password.
> 
> Once an attacker has a valid username and password, they can potentially
> gain access to the resources protected by the VPN.
> 
> If XAUTH is used as a second-level of authentication, it is possible to
> 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.
> 
> 2. Vulnerability Details
> 
> The vulnerability allows an attacker to enumerate valid usernames (IKE IDs)
> on a Juniper Netscreen through either a dictionary attack, or a brute-force
> attack.  The issue exists because the IKE implementation in Netscreen's
> ScreenOS responds to valid usernames differently to the way in which it
> responds to invalid usernames.
> 
> The exploit involves sending an IKE Aggressive Mode packet with the
> username to be tested in the Identity (ID) payload.  If the specified
> username is valid, the Netscreen system will respond; if it is not valid,
> then it will not respond.  The ike-scan tool can be used to demonstrate
> this vulnerability.
> 
> The issue only occurs in IKE Aggressive Mode; IKE Main Mode is not
> vulnerable.  However, remote access users using pre-shared key
> authentication must use Aggressive Mode due to limitations in the IKE
> protocol.  This means that all remote access users using pre-shared key
> authentication on vulnerable versions of ScreenOS are affected.
> 
> The username guessing rate depends on the bandwidth between the attacker's
> system and the Netscreen.  Because most of the usernames tried will be
> incorrect, and therefore the Netscreen won't respond, it's only the
> bandwidth from the attacker to the Netscreen that matters; the bandwidth
> from the Netscreen 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 username 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 Netscreen does not limit the username
> guessing rate, nor does it blacklist hosts that perform username
> enumeration: in tests, it was possible to get a successful response to a
> valid username immediately after thousands of incorrect attempts.
> 
> Once a valid username is obtained, it is possible to use this to obtain a
> hash from the Netscreen, and mount an offline password-guessing attack
> against this hash to obtain the password.  Because the password-guessing
> process is offline, it is fast (many hundreds of thousands of guesses per
> second), and will not cause the Netscreen to log any authentication failures.
> 
> A valid username and password allows the attacker to complete IKE Phase-1
> and establish an ISAKMP SA to the Netscreen. For normal IKE users, this
> allows the attacker to gain access to the resources protected by the
> VPN.  If the VPN user is configured to use XAUTH as a second level of
> authentication, the attacker can mount a Man-in-the-Middle (MitM) attack
> against this second-stage user-authentication process.
> 
> The offline password guessing process and MitM attack against XAUTH are
> both 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 Netscreen responses: the first is
> for the valid username "finance", and the second is for the invalid
> username "administration".  We see that the Netscreen responds to the valid
> username, but not to the invalid one.  Because of this difference in
> behaviour, it is possible to determine whether a given username 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.
> 
> -M              Multiline: Display each payload on a separate line, which
> makes the output easier to read.
> 
> --id=string     Specify the string to be used for the ID payload.
> 
> 10.0.0.1        The IP address of the target Netscreen.
> 
> 3.1. Response to valid username "royhills@...mail.com"
> 
> $ ike-scan -A -M --id=royhills@...mail.com 10.0.0.1
> Starting ike-scan 1.7.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
> 10.0.0.1 Aggressive Mode Handshake returned
>          HDR=(CKY-R=21af4dbe2cecd5f0)
>          SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds
> LifeDuration=28800)
>          VID=64405f46f03b7660a23be116a1975058e69e83870000000400000403
> (Netscreen-05)
>          VID=4865617274426561745f4e6f74696679386b0100 (Heartbeat Notify)
>          KeyExchange(128 bytes)
>          Nonce(20 bytes)
>          ID(Type=ID_IPV4_ADDR, Value=10.0.0.1)
>          Hash(20 bytes)
> 
> Ending ike-scan 1.7.7: 1 hosts scanned in 0.136 seconds (7.37 hosts/sec). 1
> returned handshake; 0 returned notify
> 
> 3.2. Response to invalid username "invalid@...mail.com"
> 
> $ ike-scan -A -M --id=invalid@...mail.com 10.0.0.1
> Starting ike-scan 1.7.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
> 
> Ending ike-scan 1.7.7: 1 hosts scanned in 2.467 seconds (0.41 hosts/sec). 0
> returned handshake; 0 returned notify
> 
> 4. Affected Versions
> 
> The issue is believed to affect all models of Juniper Netscreen running all
> ScreenOS software versions up to 5.2.0.
> 
> 5. Solution
> 
> Use certificate authentication rather than pre-shared key authentication.
> 
> 6. Timeline
> 
> The vulnerability was reported to Juniper on 21st June 2005.
> 
> 7. References
> 
> NTA Monitor
> advisory
> http://www.nta-monitor.com/news/vpn-flaws/juniper/netscreen/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.
> 
> 
> --
> Roy Hills                                    Tel:   +44 1634 721855
> NTA Monitor Ltd                              FAX:   +44 1634 721844
> 14 Ashford House, Beaufort Court,
> Medway City Estate,                          Email: Roy.Hills@...-monitor.com
> Rochester, Kent ME2 4FA,
> UK                  WWW:   http://www.nta-monitor.com/
>

Powered by blists - more mailing lists