Major security hole in NetScreen OS?

I got a call today at work.

One of our VPN users was having trouble getting in. It turns out his password was set wrong, but how had he been getting in prior to that?

He said that it hadn't been prompting him for a username/password.

Hmm - that's weird.

I looked to see who was in the authentication table. He wasn't there, but he was on our network.

(BTW, I'm posting this from home, so don't think this security vulnerability exists from where I'm posting)

What the authentication table did show was that there was a completely different user coming in from, which also happened to be his private IP on his home network.

I checked the logs, and that user was definitely different - different public IP address showed during his authentication.

But since they had the same private IP, he was able to just come on in without any authentication at all.

It's small consolation, but users still have to have our VPN policy loaded on their PC - they just don't have to use their password to get in, although any persistent hacker could probably hit upon the right combination of encryption strategies through trial and error and if a legit user was already logged in with that private IP - they're in.

(Of course, they'd still have to hack the password on our servers to be able to do anything).

NetScreen support, as usual, were grossly incompetent. The guy simply refused to listen to what I was telling him.

He insisted on me sending him the client policy file and wouldn't believe me when I told him that was different between the policy files of the 2 users was their identity.

I told him if ANYTHING else were different, it wouldn't work, but he still insisted I send him copies of both of their policy files.

So, I sent him 2 copies of the same file with just the identity changed.

He tried it and said, "I get an authentication prompt, it's working fine".

I told him first of all, you're not coming from a private IP address and secondly there's not already a user authenticated on the system with the same private IP.

He still wasn't getting it.

I had to call up both users (interrupting one of them during dinner) and had them replicate the security flaw before he understood the problem (or at least he pretended to understand).

I'm still waiting for a solution.

I've complained about the incompetence of their Tier 1 support in the past, and all it gets me is an annoying phone call from their incompetent support specialist offering a forced apology.

If their goal is to force people to RTFM before calling, it's misguided. I do RTFM, FWIW, which very often isn't much in many cases, and when I do call, I have a very specific question, which I expect them to be able to answer.

Mgmt is already leaning towards replacing all the NetScreens with Cisco equipment and this will probably be the final nail in the coffin for them.

Reply to
Loading thread data ...

This is one of the main reasons many of our clients are moving from NetScreen to Fortigate; support problems. And it's not just on the small boxes, either.

I don't think you're really looking at a vulnerability -- rather a configuration issue where you're not really configuring what you think you're configuring. BTW the persistant hacker won't get into your VPN unless he can also guess the shared secret and the correct remote and local subnets. But anyway what you've probably done is configured the vpn such that it will accept any ID's without authentication. What I think you probably want to do is check 2 places -- 1) that in phase 1 you have it set to a dialup user or dialup user group, not to a static or dynamic IP address. Then make sure that the user referred to in this case is set as an Authentication User, not just an IKE User. Otherwise it will not need a password, only a user name for identification purposes.

You can easily put a username/password combination in the client so that the user won't be prompted.

You can also add xauth or something else to the policy itself to force authentiation at that point.

But configuring it up the way you describe is quite possible, such that no password need ever be entered. In none of those cases does it mean you really extra vunlerable to attack unless you have really badly configured other aspects of it.


Reply to
Somebody. Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.