This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

KBA 135412 Fixing SQL injection vulnerability and malicious code execution in XG Firewall/SFOS

I have to say this vulnerability in the device I use to protect my network, has me rattled. I hope that Sophos will be forthcoming with why this escaped the testing that you would have presumed they perform on the Sophos OS.

Two things concern me greatly:

Reset passwords for all local user accounts - does this mean all accounts used in my local network?

Note: While customers should always conduct their own internal investigation, at this point Sophos is not aware of any subsequent remote access attempts to impacted XG devices using the stolen credentials. So how do I check this out? Are the logs on the firewall any use?

At this time, there is no indication that the attack accessed anything on the local networks behind any impacted XG Firewall. F..k!

As I tweeted, had I known on the 23rd of what appears to be a very serious vulnerability, I would have taken preventative measures. Now I am not sure where to start.

I understand that COVID-19 is having impact, particularly in the UK. It is affecting us all. I feel for those users of Sophos devices with large client user bases who are all working remotely. What a nightmare.

What a way to end Anzac Day.



This thread was automatically locked due to age.
Parents
  • Hi  

    We sincerely regret any inconvenience this has caused.

    At this time, there is no indication that the attack accessed anything on the local networks behind any impacted XG Firewall. It appears the attack was designed to download payloads intended to exfiltrate XG Firewall-resident data.

    The data for any specific firewall depends upon the specific configuration and may include usernames and hashed passwords for the local device admin(s), portal admins, and user accounts used for remote access. Passwords associated with external authentication systems such as AD or LDAP are unaffected.

    We are continuing to investigate and expect to release more details of the attack. Please follow https://community.sophos.com/kb/en-us/135412 for further updates.

  • HI Sir,

     

    I found some information on this link https://news.sophos.com/en-us/2020/04/26/asnarok/ and saw this paragraph.."This initial injected command triggered an affected device to download a Linux shell script named Install.sh from a remote server on the malicious domain sophosfirewallupdate[.]com. The command also wrote this shell script to the /tmp directory on the device, used the chmod program to designate the file as executable, and executed it."

    What does the "remote server" mentioned there means, is it the one behind my firewall or from my local network?

    Sorry just share my unwanted feeling, we were infected by ransomware "lockbit" 3 of my servers were infected - they delete the files in local drives as well as the external drive connected on the affected server.

    How related does this trending news of Sophos on my end..I don't even have a concrete logs stating that my network or servers were being compromised.

    Hoping someone here enlighten me further. Thanks

  • FormerMember
    0 FormerMember in reply to Christopher de Vera

    Hi  

    Sending you a PM for further investigation.

    Thanks,

  • Guys,

     

    I reset all my local user passwords the day we got the email(whatever day that was ....Saturday morning I think) and that took me some time with about 5 or 6 sites..  Now I'm being prompted to change them again as of today when I log in with this new Captcha greeting me?   What a pain in the you know what.  Your algorithm for determining who needed to reset seems to be off a bit.

     

    -Scott

     

  • We reset 50+ devices with SFM, I have the log for audit purposes! Yet 5 devices i checked this morning are prompting for update to password and we've had two customers call us before 7am asking why we didn't do what we said we had as they got the email direct from SOPHOS. I'm on phone to support to get an explanation now.

     

    Also unable to find a chance log for the recapcha, it exists on both User and Admin pages - with everyone working remotely it would be nice to get some heads up....

     

     

    Edit: Updated: I'm on the phone with support, it seems the HF overnight has incorrectly triggered password prompts on some devices. They are continuing to gather information and have raised a priority case for investigation. So far we haven't seen it affect any V18 devices to re-prompt for password change.

  • Hi Andrew,

    I am not being prompted to change passwords, which would have been very annoying as I have already changed them on the 25th after the KB advisory was sent. I do see the alert however. I have not updated from 17.5.11 MR-11 yet; maybe that is why.

    Jon

  • Hi,

     

    The devices I have checked so far this morning also needing password resets again, even one device that the initial HF found to have not been affected?

    Did you get your dates muddled Sophos?

    At this stage I have checked two and they both needed new passwords after I spent most of Monday processing password changes.

     

    Michael

Reply
  • Hi,

     

    The devices I have checked so far this morning also needing password resets again, even one device that the initial HF found to have not been affected?

    Did you get your dates muddled Sophos?

    At this stage I have checked two and they both needed new passwords after I spent most of Monday processing password changes.

     

    Michael

Children
  • I was prompted to change PW on my Xg 125 even though I changed it the day after the attack after patches were applied. My XG 85s did not prompt, however, and they were also changed at the same time.

  • Hi All,

    Sophos is enforcing a password reset for the XG administrator and all other local administrator accounts that have not reset passwords since the security hotfix was applied at 2200 UTC on April 25, 2020. Where required, administrative accounts will be prompted to change passwords upon logging into an XG Firewall. The password reset is shown only on an XG Firewall that was identified as impacted AND the password has not been changed since 2200 UTC on April 25, 2020.

    Admins will still receive the password reset request even if multi-factor authentication is enabled. The last date/time check for the password change is determined locally on the firewall from logged events. In the event a positive determination cannot be made, admins will be forced to change their password.

  • Based on a very small number of data points, you may need to reset the password on the primary HA device, then force a failover, then reset the password on the secondary. That's the only explanation for the number of additional password resets we've had to do after we'd already reset passwords on everything.

  • After a bit more checking I think a better explanation is if things happened like this:

    • HA Node 1 is primary and is compromised
    • Firmware update is done as part of remediation works, making HA Node 2 primary
    • HA Node 2 is not compromised
    • Password is changed on HA Node 2
    • Failover occurs at some point making HA Node 1 primary again
    • HA Node 1 has no record of a password change (even though it was changed via sync from HA Node 2) and is compromised
    • HA Node 1 prompts for password reset at next logon

    That better matches the pattern of what i'm seeing, but still based on observations of a "black box" :)

    James

  • I have received feedback below from the GES team, which is frustrating as its significant work on our end to do the entire process we have already done once again. Not only that, it means we need to touch each device, entirely defeating the purpose of the central management that has been supplied.

    Hi Andrew

    Trust you are well.

    I have received feedback from development this issue of yours.  There appears to be a bug in the script whereby if another user change the "admin" user password, the script does not pick up this change.  There are also some other limitations that come with the script.

    So for now the workaround would be to login as the "admin" user and change the password 1 last time.  Alternatively you can wait until development can find a way forward with a fix to the script however this may not be possible.

    I will keep you updated going forward.

    Thanks.