CVE-2020-12271: Sophos XG Firewall Pre-Auth SQL Injection Vulnerability Remediation Guidance and Exposure Overview

Last updated at Tue, 27 Feb 2024 17:20:32 GMT

What’s up?

On April 22, Sophos received a report documenting a suspicious field value visible in the management interface of an XG Firewall, which turned out to be caused by an attacker using a new exploit to gain access to and execute malicious code on the firewalls themselves.

This is a new pre-auth SQL injection vulnerability (CVE-2020-12271) to gain access to designed to exfiltrate XG Firewall-resident data, including all local usernames and hashed passwords of any local user accounts, including local device admin accounts, user portal accounts, and accounts used for remote access. Passwords associated with external authentication systems such as Active Directory (AD) or LDAP are not directly at risk from this vulnerability.

The attack can be performed against both user-facing and administrator-facing exposed services on the firewall.

Sophos issued a hotfix, but only around 25% of the 65,000 identified XG firewalls Rapid7 Labs has initially inventoried on the internet appear to be configured to automatically install patches. Sophos has published steps on how to manually install these fixes.

Part of the hotfix process includes a check for compromise. If an installation was compromised by an attacker, the Sophos console will report it this way:

Otherwise, the alert will just show the patch status and a note that the system is not compromised.

Organizations running Sophos XG firewalls are strongly encouraged to patch immediately and assess whether they have any downstream impacts from an initial compromise.

Exposure analysis of CVE-2020-12271

There are two primary outward facing service interfaces available on XG firewalls:

• Admin @ https://{host|ip}:{port}/webconsole/webpages/login.jsp
• User @ https://{host|ip}:{port}/userportal/webpages/myaccount/login.jsp

Most Rapid7 Labs Project Sonar HTTP studies generally do not use URL paths beyond / when collecting data from websites. However, it is possible to identify many (perhaps, most) Sophos systems without performing custom scans using these custom paths.

One way is to look at the Location HTTP header, since XG firewalls tend to redirect an initial request for/to either the user or admin URLs. Sure enough, the Rapid7 Labs team found thousands of systems this way just on port 443 (default HTTPS port), but we suspected there may be devices hanging off other ports (FWIW, you’re not being clever when you do this; we see you!) as well as devices that may not issue the Location redirect.

Querying for the Location header on other HTTPS port studies is just a simple query change to include all HTTPS study ports. But what about identifying stealthier Sophos systems? After a bit of digging into the initial results, it turns out Sophos XG firewalls, mail gateways, and other appliances have fairly uniform SSL certificates with a CN (Common Name) field that includes the prefix SophosApplianceCertificate_ (you can check out the recog fingerprint, submitted by HD Moore, on GitHub) with what appears to be a unique identifier at the end. When we expanded the search to include this criteria, we discovered just over 72,000 unique IPs with Sophos devices in April 2020 studies.

Top 20 Countries

The XXXXXXXXXXXXXXX component of the SophosApplianceCertificate_XXXXXXXXXXXXXXX string in the CN field seems to correspond to a licensed product, and if we look at the autonomous system names for one at random, it further appears that these may be deployed by telecoms/ISPs as part of an overall service package.

If you think you’re “hiding” your services on non-standard ports, think again. Here are all the ports we found Sophos appliances attempting to hide:

While there is some possible merit in using non-standard ports (lazy opportunistic attackers may just move on), you are better off applying said cleverness to robust configuration management, monitoring, patching, and use of multi-factor authentication for all your exposed services.

But, are they vulnerable to CVE-2020-12271?

It’s all well and good to find exposed Sophos appliances, but it would be better to know whether they are vulnerable. It turns out, this is fairly easy to find, since much like Microsoft in our recent OWA Exposure Post, Sophos thoughtfully includes the version/build string when referencing resources from the HTML of the admin/user pages. They look like this:

<link rel="stylesheet"
      href="/themes/lite1/css/loginstylesheet.css?ver=17.5.9.577"
      type="text/css">

We crafted a lightweight study (a more thorough one is in the works) to grab any accessible user and/or admin pages from the discovered nodes and extract that ver= build string. Just over 65,500 appliances happily gave up their version information as noted in the figure at the top of the post, with a fairly inexcusably sizable corpus (~25%) of unpatched (as of Monday, April 27, 2020) systems.

What’s next?

The Rapid7 Labs team is refining the Sophos version identification studies and will continue to monitor Project Lorelei for opportunistic exploitation attempts. We’ll update this blog post as more information surfaces.

Again, any service provider or individual organization running a Sophos XG appliance should remediate as quickly as possible.If you have any more details about this vulnerability or questions about the research behind this post, drop a note to research@rapid7.com.

Changelog

• April 28, 2020: Updated main graphic and text to reflect new XG firewall version counts and patch status.
• April 30, 2020: Sophos has provided details and indicators of compromise (IoC) lists of a widespread, malicious campaign against exposed, unprotected firewalls. Details can be found here.