so the conclusion of the call ended a second ago is "We don't know if there is a vulnerability on the 100 series, all we know all other products are ruled out". All the other open questions I have about the SNWL side totally left aside.
While playing the waiting game for futher information we have to assess the risk of leaving the SMA turned on or turning them off.
I can understand the process, but most customer probably won't.
We advise SMA 100 series administrators to create specific access rules or disable Virtual Office and HTTPS administrative access from the Internet while we continue to investigate the vulnerability.
I removed your comment because you posted a link to a Czech Republic website. The website that you posted said that the CVE was "N/A". If there is a specific CVE in question please post the NIST or MITRE link and we will check it out.
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. A little feedback to this detail would be nice!
Does that make the comments they've made invalid? Could you comment on whether you are investigating this?
It was posted on the 24th Jan, so it lines up with your announcement
Description
The vulnerability allows a remote attacker to compromise the affected system.
The vulnerability exists due to unspecified error in SSL-VPN service. The vulnerability is still being investigated by the vendor. A remote attacker can compromise the affected device.
Note, the vulnerability is being actively exploited in the wild.
Mitigation
Cybersecurity Help is currently unaware of any official solution to address this vulnerability. The vendor recommends disabling SSL-VPN access until further notice.
According to vendor, the following products are affected:
Physical appliances – SMA 200, SMA 210, SMA 400 and SMA 410.
Nope. We've implemented our WAN IP firewall rule via DEAG to make the update process faster, but that still places a burden on support staff to be as responsive as possible to help minimize remote employee productivity. Obviously cell-based connectivity can be problematic. I can't image the headache if we were fully dependent upon that.
That's our situation. Staff across two countries split across 4x SMA series devices for remote working. We've had go around and get everyone's IP addresses and get staff to email us should they change. It's an absolute mess
You are the best. You really think deleting comments making sonicwall trustful again?
You should just start working on information would help your customers and not cleaning the comments. All the comments are respectful but uncomfortable for sonicwall.
No useful information over 24h? Corona? Do you real know what admins atm facing because of you disinformations?
o They think the MFA mitigates the problem (as noted previously by @DmitriyAyrapetov), but are not yet willing to take the risk that there is something else in the WebUI that is a vulnerability.
o They are getting huge push-back on our recommendation to whitelist by IP, due to dynamic IPs and resources to support.
o They are trying to provide other, possibly less effective ways, of reducing access to the system as an alternative.
At this point, we are able to support the IP whitelisting, so we are sticking with that.
With regard to communications:
o I actually applaud SonicWall in their initial communications strategy. It takes some level of courage to notify the world of a potential 0-day vulnerability as early as they did, prior to digital forensics or code reviews. It was FAR better for everyone to be able to block SSL VPN access early on. The alternative, used by MANY vendors is to let the vulnerability fester until they have a patch or definitive information. We would much rather have the option of mitigating risk (with the knowledge that this may be over-reaction with more information), than open our clients to compromise through a product that we recommended.
o Their actual communications, however, were unclear and confusing ('SMA 100' vs 'SMA 100 series, including the SMA 100, 120, 200, 220, 400, 420 and 500v virtual appliance'; or "We are temporarily recommending disabling access to these devices, or strictly restricting access based on IP whitelisting, until we have more information and can provide updates.")
o Ongoing communications have been slow, spotty, and incomplete. There should be daily or semi-daily updates - even if there is no additional information.
o We should have some sense of the result of the forensic work that is being done on SonicWall's internal systems. We should by this point (4 days in) have some idea of whether SonicWall had been compromised, how long, and whether there is any possibility of supply-chain compromise (eg: SolarWinds), or exfiltration of source code or internal bug databases through any (reported) ransomware attack.
o SonicWall should know that there is going to be push-back, and deal with it gracefully. The sense I get is that people are getting defensive and claming up as a result. This is counter-productive, and leaves the impression that they are hiding information. Crisis management best practices is to: be as open as possible, be sympathetic to your customer's plight, incorporate information from trusted 3rd parties (forensic teams), tell your story first and honestly - across multiple media outlets. That is not currently happening.
I look forward to more information from SonicWall.
It is important that you answer, I cannot stay like this. The users, and us in the IT department, we do not understand why it is so long. We can no longer work remotely ... 250 users ... In the event that you cannot do anything, it must be said so that we buy another device from another supplier.
@Ach49 just think about it. No really useful information since time x. ->bigger problem or -> they don’t know or -> the attacker still own their network or -> files are encrypted
Speculation Yes but you already answer your question. Thats the way we did (unfortunately) because it coast more money without working VPN...
happy 7 Day Anniversary of the "SMA, you good?" hanging over us as a dark cloud. But it seems if there is no evidence of a 0day at this moment we can take a breath.
But SonicWall did not addressed the other elephant in the room.
Recently, SonicWall identified a coordinated attack on its internal systems by highly sophisticated threat actors exploiting probable zero-day vulnerabilities on certain SonicWall secure remote access products.
How do we have to evaluate this? Is it safe to send SNWL confidential data like Configuration files, TSRs etc.? This has to be cleared up real fast.
SonicWall has confirmed a zero-day vulnerability on SMA 100 series 10.x code. SMA 100 firmware prior to 10.x is unaffected by this zero-day vulnerability.
On Sunday, January 31, 2021, the NCC Group informed the SonicWall Product Security Incident Response Team (PSIRT) about a potential zero-day vulnerability in the SMA 100 series. Our engineering team confirmed their submission as a critical zero-day in the SMA 100 series 10.x code, and are tracking it as SNWLID-2021-0001.
SonicWall has identified the vulnerable code and is working on a patch to be available by end of day on February 2, 2021. This vulnerability affects both physical and virtual SMA 100 10.x devices (SMA 200, SMA 210, SMA 400, SMA 410, SMA 500v).
While we work to develop, test and release the patch, customers have the following options:
If you must continue operation of the SMA 100 Series appliance until a patch is available
Enable MFA. This is a *CRITICAL* step until the patch is available.
Reset user passwords for accounts that utilized the SMA 100 series with 10.X firmware
If the SMA 100 series (10.x) is behind a firewall, block all access to the SMA 100 on the firewall;
Shut down the SMA 100 series device (10.x) until a patch is available; or
Load firmware version 9.x after a factory default settings reboot. *Please back up your 10.x settings*
Important Note: Direct downgrade of Firmware 10.x to 9.x with settings intact is not supported. You must first reboot the device with factory defaults and then either load a backed up 9.x configuration or reconfigure the SMA 100 from scratch.
Ensure that you follow multifactor authentication (MFA) best practice security guidance if you choose to install 9.x .
SonicWall firewalls and SMA 1000 series appliances, as well as all respective VPN clients, are unaffected and remain safe to use.
I believe there's a misunderstanding here...I'm asking if someone uses a firewall (NOT vulnerable) to restrict WAN access to the SMA VPN appliance (vulnerable) to only KNOWN IP addresses if SonicWall views that as an acceptable risk mitigation step. Thanks!
Comments
Hi Guys,
so the conclusion of the call ended a second ago is "We don't know if there is a vulnerability on the 100 series, all we know all other products are ruled out". All the other open questions I have about the SNWL side totally left aside.
While playing the waiting game for futher information we have to assess the risk of leaving the SMA turned on or turning them off.
I can understand the process, but most customer probably won't.
Fingers crossed and best of luck.
--Michael@BWC
Good morning all,
This situation is frankly astounding.
Communication on this subject is not satisfactory and I have a complete loss of confidence ...
We have turned off our SMA solutions, 250 workers can no longer connect, in the midst of COVID19. !!!
Sonicwall announces that there is a computer security breach,
What exactly is this breach ? What does this allow?
Rarely seen such a mess ...
"Communication on this subject is not satisfactory and I have a complete loss of confidence ..."
Bingo.
disable Virtual Office and HTTPS administrative access from the Internetwhile we continue to investigate the vulnerability.+1
There's an issue with the SMA series. Well maybe. We don't really know but there might be. We're looking into it.
This is literally all I've been told. Anyone got anything different?
Yep, my CVE comment vanished
Hello @HLKNZ , I hope you are well.
I removed your comment because you posted a link to a Czech Republic website. The website that you posted said that the CVE was "N/A". If there is a specific CVE in question please post the NIST or MITRE link and we will check it out.
Kind Regards,
@micah - SonicWall's Self-Service Sr. Manager
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. A little feedback to this detail would be nice!
Thanks,
Jan
Does that make the comments they've made invalid? Could you comment on whether you are investigating this?
It was posted on the 24th Jan, so it lines up with your announcement
Description
The vulnerability allows a remote attacker to compromise the affected system.
The vulnerability exists due to unspecified error in SSL-VPN service. The vulnerability is still being investigated by the vendor. A remote attacker can compromise the affected device.
Note, the vulnerability is being actively exploited in the wild.
Mitigation
Cybersecurity Help is currently unaware of any official solution to address this vulnerability. The vendor recommends disabling SSL-VPN access until further notice.
According to vendor, the following products are affected:
Physical appliances – SMA 200, SMA 210, SMA 400 and SMA 410.
Virtual appliance – SMA 500v.
Nope. We've implemented our WAN IP firewall rule via DEAG to make the update process faster, but that still places a burden on support staff to be as responsive as possible to help minimize remote employee productivity. Obviously cell-based connectivity can be problematic. I can't image the headache if we were fully dependent upon that.
That's our situation. Staff across two countries split across 4x SMA series devices for remote working. We've had go around and get everyone's IP addresses and get staff to email us should they change. It's an absolute mess
You are the best. You really think deleting comments making sonicwall trustful again?
You should just start working on information would help your customers and not cleaning the comments. All the comments are respectful but uncomfortable for sonicwall.
No useful information over 24h? Corona? Do you real know what admins atm facing because of you disinformations?
I know this comment will also removed soon :)
Hello all,
There appears to be an update from yesterday on the KB article: https://www.sonicwall.com/support/product-notification/urgent-security-notice-probable-sma-100-series-vulnerability-updated-jan-25-2021/210122173415410/
My interpretation of this:
o They think the MFA mitigates the problem (as noted previously by @DmitriyAyrapetov), but are not yet willing to take the risk that there is something else in the WebUI that is a vulnerability.
o They are getting huge push-back on our recommendation to whitelist by IP, due to dynamic IPs and resources to support.
o They are trying to provide other, possibly less effective ways, of reducing access to the system as an alternative.
At this point, we are able to support the IP whitelisting, so we are sticking with that.
With regard to communications:
o I actually applaud SonicWall in their initial communications strategy. It takes some level of courage to notify the world of a potential 0-day vulnerability as early as they did, prior to digital forensics or code reviews. It was FAR better for everyone to be able to block SSL VPN access early on. The alternative, used by MANY vendors is to let the vulnerability fester until they have a patch or definitive information. We would much rather have the option of mitigating risk (with the knowledge that this may be over-reaction with more information), than open our clients to compromise through a product that we recommended.
o Their actual communications, however, were unclear and confusing ('SMA 100' vs 'SMA 100 series, including the SMA 100, 120, 200, 220, 400, 420 and 500v virtual appliance'; or "We are temporarily recommending disabling access to these devices, or strictly restricting access based on IP whitelisting, until we have more information and can provide updates.")
o Ongoing communications have been slow, spotty, and incomplete. There should be daily or semi-daily updates - even if there is no additional information.
o We should have some sense of the result of the forensic work that is being done on SonicWall's internal systems. We should by this point (4 days in) have some idea of whether SonicWall had been compromised, how long, and whether there is any possibility of supply-chain compromise (eg: SolarWinds), or exfiltration of source code or internal bug databases through any (reported) ransomware attack.
o SonicWall should know that there is going to be push-back, and deal with it gracefully. The sense I get is that people are getting defensive and claming up as a result. This is counter-productive, and leaves the impression that they are hiding information. Crisis management best practices is to: be as open as possible, be sympathetic to your customer's plight, incorporate information from trusted 3rd parties (forensic teams), tell your story first and honestly - across multiple media outlets. That is not currently happening.
I look forward to more information from SonicWall.
Hello, Do you have new information?
Did you make the fix?
It is important that you answer, I cannot stay like this. The users, and us in the IT department, we do not understand why it is so long. We can no longer work remotely ... 250 users ... In the event that you cannot do anything, it must be said so that we buy another device from another supplier.
Thank you for your reply
Speculation Yes but you already answer your question. Thats the way we did (unfortunately) because it coast more money without working VPN...
I take it there's no further updates on the vulnerability?
Welp, definitely going to consider how these IR comms went during our next hardware refresh.
Hey @Terri
Can we please have a time-frame for the next "installment" ?
Thanks, S.
Any updates on the zero day exploit?
Looks like there is an update.
Compromised "admin" credentials just doesn't sound good.
Hi @Halon5
happy 7 Day Anniversary of the "SMA, you good?" hanging over us as a dark cloud. But it seems if there is no evidence of a 0day at this moment we can take a breath.
But SonicWall did not addressed the other elephant in the room.
Recently, SonicWall identified a coordinated attack on its
internal systemsby highly sophisticated threat actors exploiting probable zero-day vulnerabilities on certain SonicWall secure remote access products.How do we have to evaluate this? Is it safe to send SNWL confidential data like Configuration files, TSRs etc.? This has to be cleared up real fast.
--Michael@BWC
Wow, this thread is dead. Any opinion on that?
--Michael@BWC
It's as if legal joined the chat and booted out the comms staff...
UPDATE: February 1, 2021, 2.30 P.M. CST
https://www.sonicwall.com/support/product-notification/210122173415410/
SonicWall has confirmed a zero-day vulnerability on SMA 100 series 10.x code. SMA 100 firmware prior to 10.x is unaffected by this zero-day vulnerability.
On Sunday, January 31, 2021, the NCC Group informed the SonicWall Product Security Incident Response Team (PSIRT) about a potential zero-day vulnerability in the SMA 100 series. Our engineering team confirmed their submission as a critical zero-day in the SMA 100 series 10.x code, and are tracking it as SNWLID-2021-0001.
SonicWall has identified the vulnerable code and is working on a patch to be available by end of day on February 2, 2021. This vulnerability affects both physical and virtual SMA 100 10.x devices (SMA 200, SMA 210, SMA 400, SMA 410, SMA 500v).
While we work to develop, test and release the patch, customers have the following options:
SonicWall firewalls and SMA 1000 series appliances, as well as all respective VPN clients, are unaffected and remain safe to use.
@micah - SonicWall's Self-Service Sr. Manager
Hi on Twitter you can find some additional information.
https://mobile.twitter.com/buffaloverflow/status/1355874671347044354?s=21
Is whitelisting client VPN connections on a firewall (NOT on the SMA itself) also an effective mitigation (along with MFA, etc.)?
Hello @TX_IT,
I hope you are well.
Our firewalls are not impacted by this issue and thus do not require/need VPN clients whitelisted.
Kind Regards,
@micah - SonicWall's Self-Service Sr. Manager
Hi Micah,
I believe there's a misunderstanding here...I'm asking if someone uses a firewall (NOT vulnerable) to restrict WAN access to the SMA VPN appliance (vulnerable) to only KNOWN IP addresses if SonicWall views that as an acceptable risk mitigation step. Thanks!