Urgent Security Notice: NetExtender VPN Client 10.X, SMA 100 Series Vulnerability
Hi,
today a Security Notice came in, regarding a Vulnerability on SSL-VPN, which seems to affect SSL-VPN on Firewalls and SMA 100 series.
The notice does not disclose much information but it's sending a mixed message.
At one side it says:
- Use a firewall to only allow SSL-VPN connections to the SMA appliance from known/whitelisted IPs
- Disable NetExtender access to the firewall(s) or restrict access to users and admins via an allow-list/whitelist for their public IPs
Duh? There are no known public IPs for remote access, so I guess we can ignore this all the way.
And the mitigation actions just show some policy examples to restrict the access to resources for established connections, which is Configuration 101.
So what is it? Is the authentication on a SMA vulnerable? Then just the allowed resources are at risk?
I actually don't get it.
--Michael@BWC
Category: SSL VPN
Tagged:
0
This discussion has been closed.
Answers
And this information raises even more questions:
--Michael@BWC
The email is terrible explaining the problem, but I presume because the truth is very bad.
My guess is that the NetExtender 10.x client has an issue but anyone who already has access to this version can use the exploit. This means the fix needs to be implemented on the firewall or SMA and has to prevent that client connecting or stop packets passing from those clients. This isn’t just an updated client that will fix the problem.
One of the fixes is to whitelist the remote client. This is impossible, so we have to switch off remote access to all firewalls and SMA 100 series. This is huge and my customers are going to want answers quickly or want their licence money back and go to another vendor.
These are my thoughts, not official response.
We are going to need better information than this and fast.
Some more news around this got published, needs to be confirmed or denied by SNWL ASAP.
Before the news broke, SecurityWeek received an anonymous email claiming that SonicWall was hit by ransomware and that hackers managed to steal “all customer data.”
A second anonymous email said all internal systems went down on Tuesday at SonicWall and that the attackers left a message on Wednesday asking to be contacted by the company’s CEO. The same individual also claimed all source code was stolen from SonicWall’s GitLab repository as a result of the breach.
A screenshot described as proof that the hackers had full access to all internal systems at SonicWall only showed the results of a search conducted using the Shodan search engine.
SonicWall has not shared any information about ransomware or what type of data may have been compromised, and SecurityWeek has not been able to independently confirm the claims — they could be false claims that may have nothing to do with the actual breach suffered by SonicWall.
--Michael@BWC
Very unclear release, and provides a very unrealistic remedy, expecting mobile users to be locked down to a whitelisted connecting IP. We always whitelist and setup an access group for restricted wan access to the firewall, and most cases our remote users are setup with MFA, but we will be watching this issue unfold, as the only real option seems to be closing off remote access, which is not an option with our client base.
If it's the remote vpn software that's the problem, there are other options, such as mobile connect, but this sounds like a bigger problem.
We are standing by, and monitoring this thread in hopes of better direction and more realistic options coming to light.
Stay safe all, and keep your clients safe and properly informed,
-Lloyd-
This "security notice" leaves pretty much all the questions open that should come to the mind of any admin reading it.
It's neither clear what the issue is nor which products are affected. The wording seems to be self-contradictory. The notice, as it currently is, doesn't make much sense at all, actually.
We need clarification urgently!
Hello all,
I also got the email and was wondering what to do about all my users connecting with SSL-VPN when I stumbled on this in the community. I went looking for a solution on whitelisting public IP's per SonicWall's guidance and it looks like that cannot be done, at least according to the link below.
From user BecauseI'mGood :
"This isn't going to work. When you enable the SSLVPN, a rule is automatically created allowing traffic to the SSLVPN interface, as follows:
You cannot edit the source address field, it's hard set to "ANY." Also, out of curiosity I just tried this:
If you try to get around the default setup by creating a rule ahead of it allowing from a specific address, and another denying/discarding SSLVPN traffic from all addresses, the latter will be detected as an overlapping rule, so the system won't allow it.
So, you're just going to have to trust that the SSLVPN does the job it was meant to do, or use some other solution."
The majority of my users are in the healthcare world, does this mean that I need to disable SSL VPN until SonicWall figures out what is going on?
Is it as simple as having users uninstall NetExtender v10 and revert to NetExtender v9?
Sure would be helpful if SonicWall gave better links in their letter to Admins, I used the same link they provided to set up SSL VPN to begin with, and it mentions nothing about whitelisting IP addresses to connect.
Would it be an option to switch to Mobile Connect? I suppose since they recommend to just turn off SSLVPN that it doesn't matter what client you use. But that would be a pretty simple fix for me to just use that instead.
I just downloaded it from the Windows Store and noticed that the copyright is still set to 2019 in the About menu... Version 5.0.5.0. That's a little concerning though
Also...
@DavidS Your quote mentioned that you cannot edit the auto added rules/nats, but there is this option to get around that.
https://www.sonicwall.com/support/knowledge-base/how-to-edit-or-delete-auto-added-access-rule-s-and-nat-policies/170502578285909/
We are taking our own internal remediation steps as we speak but the response and guidance from SonicWALL thus far is severely insufficient as most comments above have pointed out.
We need more information from SonicWALL and we need it yesterday.
@JOSHZ - Thanks for that link, I did stumble on it and was about to implement it BUT...
I just got off the phone with Sonicwall Support and this is what they told me to do:
Start by following the instructions that @JOSHZ linked:
https://www.sonicwall.com/support/knowledge-base/how-to-edit-or-delete-auto-added-access-rule-s-and-nat-policies/170502578285909/
-----------------------------------------------------------------------------------
Create an Address Object, one for each user, with the following settings:
Name: I used the username
Zone: WAN
Type: Host
IP Address: Users Public IP Address
----------------------------------------------------------
Create Address Group
Go to Address Group, then click Add
Name: I used SSL VPN Users
Add all users that an Address Object was created for
--------------------------------------------------------------
Go to Rules -> Access Rules
Sort by From: WAN To: WAN
Edit the Default Rule that was created for SSLVPN and change the Source to the Address Group that you just created:
From: WAN
To: WAN
Source Port: Any
Service: SSLVPN
Source: SSL VPN Users (Address Group Created above) default is Any
Destination: Any
Users Included: All
Users Excluded: None
Schedule: Always On
Priority: Auto Prioritize
--------------------------------------------------------------------
I tested with Sonicwall on the phone and it worked. I did not have my public IP in there and was not able to connect. After creating an address object with my public IP address, then adding it to the Address Group, I was able to connect.
The only PITA step will be getting all of your users public IP address. The only issue I see is that if the user is travelling, they will need to provide their public IP for each network they connect to.
Hope this helps.
David
Mobile Connect is "end of support" on Windows:
It seems to still work with firewall appliances, but with SMA 100 series I had problems with it and had to switch users to NetExtender. So at the moment NetExtender is the only supported client on Windows.
This is speculation at this point, but it does not look good. This might be another SolarWinds.
The information until now only mentions NetExtender version 10 to be vulnerable, so perhaps it has been injected with malicious code that allows bypassing authentication. Hopefully they release more information soon, example a confirmation that downgrading to version 9 would plug the hole. Or that enabling two factor authentication mitigates it.
If they say that whitelisting IPs is a mitigation, it thankfully doesn't look like it's leaking passwords.
We are closing this Discussion to comments. Please post all further comments on this topic to the following thread:
Urgent Security Advisory - NetExtender VPN Client Version 10.x and SMA 100 Series — SonicWall Community
The above thread is being monitored and will be responded to by SonicWall with updates over the coming days.
VP, Web and Digital Experience, SonicWall. Get my attention by tagging @Terri on the Community.