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 Jon,

    as I understand KB135412 only affects local accounts on the firewall (admin and users):

    "The attack ... was designed to download payloads intended to exfiltrate XG Firewall-resident data ... 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."

    So I changed all passwords on the firewall and deactivated also the User Portal, SSL VPN and L2TP VPN till monday. The admin services where allready limited by a ACL exception rule.

    Then I proved all "Authentication" entries in the Log Viewer for unusual "User name" "Src IPs" combinations.

  • Thanks Josef,

     

    I really appreciate your and others responses in this forum. It really helps.

    I have changed all my passwords just in case; it is not a bad thing to have to do, but it is a little scary how wide spread the use of your credentials are, particularly in the Microsoft space. I have also been more disciplined with the use of unique passwords, as the apparently easy extraction of hashes in this case, made that mandatory. I am fairly confident, with the caveat of not yet knowing the full extent of the exploit, that my internal network is safe; I use passwords everywhere, some obfuscation, but some devices, like my Vivotek cameras are on old firmware because it is such a pain to update them.

    With the log, I see no entries for any Authentication Log comp filters; am I looking in the right place?

     

    Jon

Reply
  • Thanks Josef,

     

    I really appreciate your and others responses in this forum. It really helps.

    I have changed all my passwords just in case; it is not a bad thing to have to do, but it is a little scary how wide spread the use of your credentials are, particularly in the Microsoft space. I have also been more disciplined with the use of unique passwords, as the apparently easy extraction of hashes in this case, made that mandatory. I am fairly confident, with the caveat of not yet knowing the full extent of the exploit, that my internal network is safe; I use passwords everywhere, some obfuscation, but some devices, like my Vivotek cameras are on old firmware because it is such a pain to update them.

    With the log, I see no entries for any Authentication Log comp filters; am I looking in the right place?

     

    Jon

Children
No Data