Urgent Security Advisory - NetExtender VPN Client Version 10.x and SMA 100 Series
Terri
Administrator
Hi All,
In the interest of consolidating updates and dispersing information quickly to our Community, we will be closing all other threads related to this Security Advisory. Please leave your comments and questions on this thread and we will ensure that as answers are provided, and validated to be accurate, we will post them here in response.
Knowledge base article: Urgent Security Notice: NetExtender VPN Client 10.x, SMA 100 Series Vulnerability | SonicWall
We are expecting an update to both the Advisory and the Knowledge Base article within 24 hours (at some point on January 23, U.S. CT)
Thanks,
Terri O'Leary
Category: VPN Client
VP, Web and Digital Experience, SonicWall. Get my attention by tagging @Terri on the Community.
7
Comments
At least clarify the original email or denounce the internet rumours.
Would be nice if the article would be updated with information that is actually useful.
Currently it's a rather unclear and in parts self-contradictory mess. It's urgent that admins get more detailed information about what's actually going on in order to understand the scope of the issue and act accordingly.
At the moment the article does neither give a conceivable explanation about the issue nor does it make exactly clear which devices are affected under what circumstances. That's pretty bad for "urgent security notice",I have to say...
I just got off the phone with Sonicwall Support and this is what they told me to do in order to whitelist IP Addresses
Start by following the linked instructions:
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
Hi @peon2t
There will be an update to the Advisory today. We want to make sure we are as transparent as possible without exposing our end users to any unnecessary risk.
In relation to devices impacted, there are two issues highlighted here, impacting the following products:
and a second issue as follows:
My understanding from this is that firewalls are only impacted if they are using NetExtender 10.x. The linked KB gives some initial mitigation options for that scenario.
We understand the urgency here - more information is coming soon.
Thanks,
Terri O'Leary
VP, Web and Digital Experience, SonicWall. Get my attention by tagging @Terri on the Community.
@Terri
"My understanding from this is that firewalls are only impacted if they are using NetExtender 10.x. The linked KB gives some initial mitigation options for that scenario."
Well, but NetExtender is a client software that runs on the user's computers, not on the firewall. So the firewall is never using any version of NetExtender, is it?
If the firewall has a vulnerability in it's VPN server it's pretty much irrelevant which version of the NetExtender client our specific users run, right? Because what's (relevantly) vulnerable is the firewall, not the client software..?
And that all of what I just said is unclear (to me and to you, obviously) is exactly what I meant when I said that there is almost zero useful information in the article.
PEON2T: The fear is that there was a malicious code injection in the 10.x Netextender client, similar to the Solarwinds Orion issue, which would not be in previous versions. I hope this isn't true but that is why prior versions would not be affected (potentially). It's too early to jump to conclusions until we receive more info.
For me, whitelisting hundreds of public IP addresses is untenable. Using a prior version of the Netextender client is how I'm going to handle it, if it comes to that.
If indeed there is malicious code in 10.x client..... I don't want to think about the damage that has been done...
The answer is new firmware for all firewalls (past and present) and all SMA/SRA models.
Is this going to happen before Monday?
@scottybud
I still don't see the "scenario" we're getting at.
If what you say is true (client software has been trojanized) this would mean that there isn't actually a vulnerability on the firewall that can be mitigated by deactivating VPN. It would mean that potentially millions of Client-PCs are infected and have to get cleaned. This would possibly include resetting every credential (not just VPN) that could have been stolen from those Client-PCs. So shutting down VPN would only "scratch the surface" of the issue and prevent stolen VPN credentials from being used. In other words: The article would be completely misleading about the scope and scale of the issue. Also: it wouldn't be patchable with a firmware update on the firewall.
We’re going to need some serious explanation and plan to recover from this PR disaster.
I’ve sold SonicWall products for 20 years and want a good response, and hoping for some good news.
I echo @sonictek .
I would also ask all of us here that we do our best to refrain from speculation, at least on the forums. Obviously what could help with that is another response from SonicWALL, which we are all eagerly awaiting, and hoping is more transparent and informative.
Also, just to share, I spoke with SonicWALL support about 30 minutes ago and the internal investigation, as expected, is still active. They were unable to confirm that prior versions of NetExtender are not impacted. They were unable to confirm that Mobile Connect is not impacted. They were unable to confirm that enabling MFA and/or SSO via RADIUS would secure us against the vulnerability.
Speculation only comes from lack of facts.
Prior versions of NetExtender is irrelevant as anyone could find and download NetExtender 10.x. The only answer so far is to turn off remote access (whitelisting isn’t an option as we have many remote users on 3G/4G and fixed-line dynamic addresses, and remote users from moving locations).
The answer seems to be new firmware for all firewalls (past and present), and all SMA/SRA appliances.
I’m not being unduly negative, I just need answers so I can pass on to customers without pretence.
Excatly.
So far I have heard three completely different "theories" about what's going on. Each of them having very different consequences and each of them prompting the need for different actions on our side.
The communication form Sonicwall so far doesn't enable us to understand what's happening and what has to be done.
Hi All,
GOOD NEWS. We have an official update I can share as follows:
SonicWall engineering teams continued their investigation into probable zero-day vulnerabilities and have produced the following update regarding the impacted products:
NOT AFFECTED
REMAINS UNDER INVESTIGATION
For additional details, guidance and product usage, customers may reference the KB article, which we will continue to update throughout our investigation.
SonicWall fully understands the challenges previous guidance had in a work-from-home environment, but the communicated steps were measured and purposeful in ensuring the safety and security of our global community of customers and partners.
END OF OFFICIAL RESPONSE
Source of Update: Security Notice: Update on NetExtender VPN Client Version 10.x & SMA 100 Series Products - SonicWall
tl;dr - we previously communicated that we may have a zero-day in our NetExtender 10.x client. We DO NOT. As such, we can conclusively say none of our firewall products, our SMA 1000 series (enterprise) or any other product lines are impacted. The only outstanding item we are still digging into surrounds the SMA 100 Series. Update to come on that ASAP too.
Thanks,
Terri
VP, Web and Digital Experience, SonicWall. Get my attention by tagging @Terri on the Community.
In the referenced KB, there is this updated guidance:
"Current SMA 100 Series customers may continue to use NetExtender for remote access with the SMA 100 series."
"We advise SMA 100 series administrators to create specific access rules or disable Virtual Office and HTTPS administrative access from the Internet"
Can someone please explain the implementation steps for this??? Obviously, you've got the other two options of either completely blocking or restricting WAN access via firewall rules. We've already taken those steps, but the above is quite unfamiliar territory.
Thanks!
-Jim
I had the same thought. I just disconnected the whole unit hopefully there is a better fix before Monday.
Hi @Terri
thanks for sharing some information, no hard feelings for closing my thread though 😉. I can only imagine what's going on over there.
I'am somewhat certain that this /spog part messed things up, but that's just me playing the speculation game.
Because my customers heavily relying on the Virtual Office and Application Offload functionality I need reliable information if it's safe to still have this activated? At this point if I read the KB article right it's advised to have it disabled? Which would be a desaster.
--Michael@BWC
Hi @Terri
is really noone with a more technical expertise monitoring this thread? No offense but "Web and Digital Experience" can not answer the questions we have.
I'am still spinning my head around some proper mitigation actions and because I cannot allow/block any connection based on the Source IP address I came to the conclusion we have to advise our customers to block ANY connection to the SMA 100 series.
Your statement states we have to disable Virtual Office, which is IMHO not possible. A single Portal is often a two trick pony providing NetExtender and VirtualOffice access. We can disable NetExtender though, but this is according to your post not an issue anymore? We cannot disable a Portal, all we can do is to remove any Domain associated with it to avoid any log in.
At what point the SMA is vulnerable? Before or after the Authentication? Before or after showing the VirtualOffice? Does it help to activate Device Management to allow only specific devices, which kicks in AFTER Authentication of course.
Is GeoIP any good which just leaves the access open to bad actors in the allowed countries?
This whole situation is handled very bad, sorry to say that.
--Michael@BWC
There little is this thread that helps me to deal with this...
SonicWALL are saying that they are open about this issue but we really understand nothing about how we have been compromised...
Of course we have all been using 2FA and Geo-IP, but where does that fit in to this new picture...?
There is a major lack of information here..
Thanks for the update. One Question: What about SMA 4xx (or any other from the Series) with current stable firmware, also v9.0.0.9 (latest)? The information so far does not make this clear in my opinion.
Hi @BWC
No offense taken! You're right - I manage our web and social - I'm not a product SME. I am sharing our official statements as they are shared on our website. However, we absolutely do have engineers monitoring this thread and your questions are helping to shape our next update. I am working with a group of our best engineers right now and they will be posting updated information here shortly. Thank you all for your responses and input. More coming very soon -
Terri
VP, Web and Digital Experience, SonicWall. Get my attention by tagging @Terri on the Community.
Hi @Terri,
All of @BWC 's questions are important... We really need more information, here.
Our major issue is that your communication essentially tells our clients that there is a way of allowing NetExtender access through the SMA, without allowing access to the Web UI:
"Current SMA 100 Series customers may continue to use NetExtender for remote access with the SMA 100 series. We have determined that this use case is not susceptible to exploitation"
...But does not provide any guidance on how to do this. As far as I know, it isn't possible.
I have clients asking us to do this, particularly before start of business Monday.
Any update on this? Support gave me nothing and our account manager has gone to ground. Would love to know the answer to JPITERAK's question:
Our major issue is that your communication essentially tells our clients that there is a way of allowing NetExtender access through the SMA, without allowing access to the Web UI:
"Current SMA 100 Series customers may continue to use NetExtender for remote access with the SMA 100 series. We have determined that this use case is not susceptible to exploitation"
...But does not provide any guidance on how to do this. As far as I know, it isn't possible.
For limiting WAN access to the built-in LocalDomain's Administrator account, I suppose you could:
As to restricting that VPN users portal to NetExtender access only... 🤷♂️
Though you could configure two interfaces, and disable admin access on one of them, SonicWall's own KB typically recommends a 1-port deployment...
I've been testing several of these scenarios with mixed results tonight. Nothing really works 100%. There does not seem to be a way to prevent access to virtual office portal but still allow netextender. I am hoping for a new update on guidance that is simpler. Or maybe a firmware update...
I'm whitelisting end user home IP addresses on the firewall and only allowing those IP's to connect on port 443. I also set admin user login policy to only allow login from the LAN IP's that goes through to the DMZ with a single interface SMA on a one armed DMZ.
I did find that if I set each user logon policy to disabled, then the user can't login to either the web interface or the netextender, which is to be expected. However, I found that if I set an individual user logon policy to only allow logon from a fake IP address, then the user would no longer be able to login to the web interface, but Netextender still allowed them to login. I was not expecting this and it does not seem like the correct behavior. It does appear to be a way to prevent users from using Virtual Office but still allow them to use Netextender from anywhere.
We tried setting up a separate physical interface and disabling HTTPS management on it while disabling HTTPS management on the real DMZ interface. It still allowed management and virtual office access anyway. This was not expected behavior either.
We tried linking the virtual office portal to a second interface and separate IP address that was not accessible externally. It still allowed portal access and netextender on the outside/DMZ interface anyway.
We tried limiting logon times on the portal to never allow login. This still allowed admins to login to the portal. It prevented regular users from accessing the portal and netextender, so it wasn't really a viable option for us. Ideally, I want to block portal access but allow netextender.
I think we are all hoping for technical clarification on that second bullet so we can keep people productive on Netextender, but block whatever vulnerability is in the virtual office web portal interface.
@Josh4329 How did you restrict admin logins to only internal IPs? I would love to do that even after this saga is over.
You can do for admin users when you edit them. There's a defined IP range you can set
AH. HERE:
Thanks!
Hi all,
eagerly waiting for the 09:30 UTC metting with @DmitriyAyrapetov and hope for the best.
Rumors telling that the SMA is at risk even without the need of Authenfication which leaves only one option, to completely deny any traffic to the SMA or shutting it down.
SonicWall should make a clear statement here, all of my questions from the recent days are still unanswered.
--Michael@BWC
Hi - There are a lot of comments and @Terri has been holding the fort. The important point is that we suspect that there may be a vulnerability, and are working to either identify/resolve it or to add the SMA 100 series to the list of other products that are cleared.
The most important advice that I can give you is *TURN ON MFA*. Caps for emphasis, not yelling.
The advice to turn off virtual office will be removed Monday morning. As many others have pointed out, that's not something that can actually be done - our fault!
NetExtender is fully cleared, and is fine to use with FW and with SMA, with MFA of course.
Did I mention to turn on MFA?
I'll dig through the thread a little more tomorrow.