KBA 135412 - What does Compromised mean in this fix

The hotfix has a verification script (/content/dr/3/dr/drrun.sh) which looks for specific file / certificate artifacts and entries present in the Postgres database.

• Files:
  • /tmp/x.sh
  • /scripts/vpn/ipsec/.generate_curl_ca_bundle.sh
  • /tmp/I
  • /tmp/.n.sh
  • /tmp/.pg.sh
  • /var/newdb/global/.post_MI
  • /scripts/._av_pre_script.sh
  • /tmp/.lp.sh
  • /tmp/b
  • /tmp/2own
  • /scripts/._av_pre_script
• SQL:
  • psql -U nobody -d corporate -tAc "select * from  tbltelemetry where argument='post_MI'"
  • psql -U nobody -d corporate -tAc "select servicevalue from tblclientservices where servicekey='CCCAdminIP'"
  • psql -U nobody -d corporate -tAc "select servicevalue from tblclientservices where servicekey='ha_aux_traffic'"
• Certificate:
  • grep -c sophosfirewallupdate /scripts/vpn/ipsec/generate_curl_ca_bundle.sh

One hypothesis is that the attacked wanted to connect the FW to a remote management IP.

As I applied the fix and only then realized this I cannot provide any insights into the actual values. But maybe someone else can.

The hotfix has a verification script (/content/dr/3/dr/drrun.sh) which looks for specific file / certificate artifacts and entries present in the Postgres database.

• Files:
  • /tmp/x.sh
  • /scripts/vpn/ipsec/.generate_curl_ca_bundle.sh
  • /tmp/I
  • /tmp/.n.sh
  • /tmp/.pg.sh
  • /var/newdb/global/.post_MI
  • /scripts/._av_pre_script.sh
  • /tmp/.lp.sh
  • /tmp/b
  • /tmp/2own
  • /scripts/._av_pre_script
• SQL:
  • psql -U nobody -d corporate -tAc "select * from  tbltelemetry where argument='post_MI'"
  • psql -U nobody -d corporate -tAc "select servicevalue from tblclientservices where servicekey='CCCAdminIP'"
  • psql -U nobody -d corporate -tAc "select servicevalue from tblclientservices where servicekey='ha_aux_traffic'"
• Certificate:
  • grep -c sophosfirewallupdate /scripts/vpn/ipsec/generate_curl_ca_bundle.sh

One hypothesis is that the attacked wanted to connect the FW to a remote management IP.

As I applied the fix and only then realized this I cannot provide any insights into the actual values. But maybe someone else can.

Thanks for that Information. I was checking drrun.sh. So from my point of view, we could remove the Database Entry in tblalertconfig manually, if we do not want to have that alert showed up in the GUI any longer.

By the way: This hotfix-script looks very basic. It doesn't proof whether there is any ongoing Communication between my XG and the Command and Control Servers.

So I wouldn't be really sure, whether we could trust this Hotfix for 100  Percent.

Furthermore, it would be interesting to know, whether this Hotfix will keep in place after an Upgrade of Sohpos XG. Maybe anyone can help with that?

Hi Christian,

This hotfix eliminated the SQL injection vulnerability which prevented further exploitation, stopped the XG Firewall from accessing any attacker infrastructure, and cleaned up any remnants from the attack.

This hotfix will persist across all supported SFOS versions.

We will soon release more details of the attack and its payloads. Please follow our https://community.sophos.com/kb/en-us/135412 for further updates.

Regards,

Thanks for this, gave me somewhere to start to look...One of the XG firewalls I manage is a virtual appliance and is backed up, so I could view the files that have been removed.

If someone from Sophos is viewing, can we have clarification of two points:

1 - Is the backup file encryption password hash included in the compromise?

2 - Were local users SSL VPN certificates/configs compromised in this attack?

The second point is important, if they are then we need to plan re-installing end users VPN clients with new certs.

After analyzing the components and intent of the attack, Sophos published a SophosLabs Uncut article, “Asnarok” Trojan targets firewalls, to share its current understanding of the malware.

Is the file cccopcode.log associated with this attack?

This file had the same timestamp as the original attack and contains sensitive information. I can't see any reference to it in the SophosLabs article.

An information that the investigation lacks is "how could the SQL-injection be exploited at all" meanig by which service could it be exploited?

At our customers "UserPortal" is the only service reachable from the internet to be able to configure SSL-VPN for external workers. And that only because there is no possibility to centrally download the config files from WebAdmin like we were able to with SGs.

The only other possibility in our installations could be WebAdmin or SSH, which are limited to our public ip address (both) and Sophos CFM (HTTPS).

Well.... the one device which was affected was connected to Sophos CFM... the other device was stand alone, never connected to Sophos CFM and was not affected. Is this perhaps an indication? Was the Sophos CFM first attacked and then the ip addresses were stolen? :O

Just a hypothesis! ;)

Tonight I will change the fixed IP address and the reverse DNS lookup entry of the affected internet connection. WebAdmin an UserPortal are now restricted by ACLs (whitelisting)... local passwords (IPSec tunnel PSK, local users and Active Directory Auth users) were changed. Now I'm thinking about to destroy the OTP hardware token.... surely the token seeds are also in the database... Sophos Authenticator App entry deleted and new set up... no big deal.

Sorry, the confidence is deeply disturbed.

Hi Michael Großmann 

We sincerely regret any inconvenience this has caused. Please take the preventive measure you have listed in your post. After analyzing the components and intent of the attack we published an article, “’Asnarok’ Trojan targets firewalls” to share our current understanding of the malware, which can be found here: https://news.sophos.com/en-us/2020/04/26/asnarok/

What is the restart of the XG Firewall for as descripted in the steps to remmediate this issue completely?

Hi kerobra_retired 

The attack affected systems configured with either the administration interface (HTTPS admin service) or the user portal exposed on the WAN zone. In addition, firewalls manually configured to expose a firewall service (e.g. SSL VPN) to the WAN zone that shares the same port as the admin or User Portal were also affected. For reference, the default configuration of XG Firewall is that all services operate on unique ports.

More info available in the KBA.