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.

A breakdown of the ~65,000 Sophos XG firewalls we inventoried that could potentially be vulnerable to CVE-2020-12271

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:

Example of a Sophos XG firewall that is compromised by the CVE-2020-12271 vulnerability, via Sophos

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

Example of a Sophos XG firewall that is NOT compromised by the CVE-2020-12271 vulnerability, via Sophos

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

Country ct %
United States 9,126 12.54%
India 7,989 10.98%
Germany 5,433 7.47%
Japan 4,680 6.43%
Italy 4,338 5.96%
Australia 4,168 5.73%
Turkey 3,740 5.14%
Brazil 3,526 4.85%
France 2,567 3.53%
United Kingdom 1,822 2.50%
South Africa 1,779 2.44%
Canada 1,658 2.28%
Spain 1,644 2.26%
Malaysia 1,496 2.06%
Switzerland 1,261 1.73%
Colombia 1,124 1.54%
Thailand 1,087 1.49%
Netherlands 932 1.28%
Taiwan 681 0.94%
Portugal 611 0.84%
Geographic distribution of exposed Sophos appliances that could potentially be exposed to this SQL Injection vulnerability (CVE-2020-12271).

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.

AS Org ct
Telecom Italia 108

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:

Port ct
4443 33,469
8443 15,234
4433 6,923
50443 4,717
10443 3,835
9443 2,845
1443 1,867
443 1,621
4343 1,070
4434 1,063
7443 1,040
5443 775
11443 370
44443 313
6443 274
2443 266
12443 168
40443 143
8181 135
30443 96
60443 95
8090 62
55443 42
7002 26
25 19
5001 15
9043 15
8002 13
2083 10
2087 10
3001 10
3790 10
7548 10
7550 10
8009 10
8010 10
8984 10
16993 9
49592 9
50880 8
6984 7
10250 7
3780 6

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"

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 Heisenberg 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.


  • 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.