Full Disclosure mailing list archives
Re: Juniper Netscreen VPN Username Enumeration Vulnerability
From: ADT <synfinatic () gmail com>
Date: Thu, 18 Aug 2005 12:53:51 -0700
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 () nta-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
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Juniper Netscreen VPN Username Enumeration Vulnerability Roy Hills (Aug 18)
- Re: Juniper Netscreen VPN Username Enumeration Vulnerability ADT (Aug 18)
- Re: Juniper Netscreen VPN Username Enumeration Vulnerability Roy Hills (Aug 19)
- Re: Juniper Netscreen VPN Username Enumeration Vulnerability ADT (Aug 18)
- Re: Juniper Netscreen VPN Username Enumeration Vulnerability Roy Hills (Aug 19)
- Re: Juniper Netscreen VPN Username Enumeration Vulnerability ADT (Aug 18)