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.
Parents
  • +1

    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.

  • 0 in reply to JosefBergmann

    If your XG authenticates against AD, LDAP, RADIUS, etc then those passwords are stored with reversible encryption (by definition), and could be considered plaintext depending on what the attacker knows about how XG decrypts those password. I'd change those first.

    I would like to know though if we need to renew the hundreds of OTP keys we only just finished rolling out for remote workers...

    James

  • 0 in reply to jamesharper

    Hi James,

    I don't use any of these remote authentication schemes on my few customer XGs (another story), but Sophos explicitly excluded them in KB135412.

    On the other side, the OTP seeds are for sure stored on the firewall, the could be compromised (if stored plain).

  • 0 in reply to JosefBergmann

    The way I interpret the disclosure KB is that your user account, if stored in AD/LDAP, is not compromised because XG has no way of getting the security hashes. But XG uses a username and password to access AD/LDAP/RADIUS etc, and those credentials are stored on XG itself, presumably in the configuration partition. It is not clear to me from reading the KB if those credentials have been compromised.

    I've raised a ticket to get a straight answer on the OTP question. It may be that the answer is "we don't know", in which case we have to assume that the OTP secrets are compromised. Even if they aren't stored plain, they are still stored in reversible encryption (we can access them plain in the UI), and if XG can decrypt them then the attacker can access the keys used to decrypt them.

    James

  • 0 in reply to jamesharper

    You're right, I agree with the one account used to authenticate against the AD/LDAP/Radius-service itself. Usually this credentials could not be used for an unauthorized remote access (on the User Portal or VPN).

    To start an analyses of OTP-hashes yourself maybe you find my post here helpful (they are probably stored on a PostgreSQL-DB on the firewall).

Reply
  • 0 in reply to jamesharper

    You're right, I agree with the one account used to authenticate against the AD/LDAP/Radius-service itself. Usually this credentials could not be used for an unauthorized remote access (on the User Portal or VPN).

    To start an analyses of OTP-hashes yourself maybe you find my post here helpful (they are probably stored on a PostgreSQL-DB on the firewall).

Children
No Data