lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu Aug 18 20:54:02 2005
From: synfinatic at gmail.com (ADT)
Subject: Juniper Netscreen VPN Username Enumeration
	Vulnerability

The protocol itself makes no attempt to hide the user ID.  Claiming
that it is a "big risk" that you can brute force it is therefore a bit
silly IMHO.  People have been talking about the problems with
aggressive mode for years.  I know Brett Eldridge of NetScreen did a
presentation at DefCon back in 2002 on the problems with Aggressive
Mode and how best to reduce your risk.  One of his biggest points was
AM doesn't protect your identity.  Your post doesn't change the basic
risk model in any significant manner.

Perhaps ScreenOS could do things a little better to reduce the risk
for this specific "attack", but when you do the risk analysis, there
are easier ways to determine the userID w/o brute forcing as you
describe.  As long as their are other/easier ways to do the same
thing, I fail to see how making a code change provides the end user
with a solution.

As for brute forcing the PSK, well that isn't new either.  Every VPN
administrator should know that this is possible.  Picking a strong PSK
(nothing says you're limited to lower case or only 8 chars) is in your
best interest.   But cracking a password based on a hash is neither
new or limited to this situation.

Of course, using Main Mode w/ certificates is even better, but as you
point out (and I agree) it's just not used that often; unfortunately
it's a PITA to manage.

I'd also point out that if your goal is to MITM (their session or
XAuth as you point out), you obviously can sniff the user id, hence no
need to brute force it.

Honestly, if you want to complain about the vendors, why not that
nobody has come up with an easy to deploy and manage system to manage
certs so that customers actually use Main Mode for mobile end users? 
That would be a *real* solution to this problem, rather then hacks on
an inferior protocol to make it .001% more secure.

-Aaron


On 8/18/05, Roy Hills <Roy.Hills@...-monitor.com> wrote:
> At 17:06 18/08/2005, ADT wrote:
> >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?
> 
> The difference is that this attack does not require the attacker to
> be in the path of the VPN traffic.
> 
> >Of course, the NetScreen's could reply with some kind of response, but
> >may lead to resource exhastion.
> 
> True, but there are ways to minimise this problem (rate limiting, using
> random data for the KE payload if the ID is invalid, etc.).
> 
> Cisco, for one, have fixed the same problem in their VPN concentrator
> product.
> 
> >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]).
> 
> ike-scan includes a program called psk-crack which does just that.  Using
> OpenSSL's hash algorithms on a 2.8GHz P4 (not a super-fast system) you
> get about 350,000 attempts per second for MD5-based hashes, and about
> 250,000 for SHA1.
> 
> This is enough to crack a dictionary word in seconds, or to do a brute-force
> search of a 6-character lower-case password in about 15 mins or an
> 8-character lower-case password in about seven days (assuming
> MD5 hash).
> 
> >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.
> 
> The problem is that, in practice, users are not aware of this.  Witness the
> fact
> that I've managed to discover valid username/password combinations for several
> systems based on the username enumeration issue plus PSK cracking, and
> that's with large organisations who "should have known better".
> 
> What percentage of Netscreen VPNs are set up to use Aggressive Mode with
> PSK auth do you think?  My findings (albeit from a limited sample size)
> indicate
> that it's the vast majority.
> 
> In the real world, it is a big risk.
> 
> Roy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ