Thread Info
  • State Verified Answer
  • +4 person also asked this people also asked this
  • Locked Locked
  • Replies 25 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 7074 views
  • Users 0 members are here
Options
Suggested
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

Jon Beets

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.
  • 0 in reply to MichaelAshby

    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.

  • 0 in reply to wineoh

    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.

  • 0 in reply to FloSupport

    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.

  • 0 in reply to jamesharper

    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

  • 0 in reply to FloSupport

    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.