exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

juniperEnum.txt

juniperEnum.txt
Posted Aug 19, 2005
Authored by Roy Hills | Site nta-monitor.com

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 issue is believed to affect all models of Juniper Netscreen running all ScreenOS software versions up to 5.2.0.

tags | advisory
systems | juniper
SHA-256 | c62ad783ef552c15a0b4c2b7381e46c7d0b0f66225ab7c1191509fba5dade3fc

juniperEnum.txt

Change Mirror Download
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@hotmail.com"

$ ike-scan -A -M --id=royhills@hotmail.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@hotmail.com"

$ ike-scan -A -M --id=invalid@hotmail.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@nta-monitor.com
Rochester, Kent ME2 4FA, UK WWW: http://www.nta-monitor.com/

Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close