Category: Sophos

CRN has announced its annual Women of the Channel, and 13 Sophos executives have been named.

For the fourth year in a row we have the most executives from an IT security company honored and acclaimed for their “strategic vision and unique achievements… innovative thought leadership, and unwavering dedication to the IT channel”, as Bob Skelley, CEO of The Channel Company puts it.

Sophos executives recognized on the CRN list, which is comprised of women from all areas of the IT ecosystem, including technology vendors, distributors, solution providers, and other IT organizations, include:

• Kendra Krause, senior vice president, global channels and sales operations
• Justine Lewis, vice president, worldwide regional and channel marketing
• Erin Malone, vice president, North America channel sales
• Caralyn Stern, vice president, global channel and Americas marketing
• Regina Vignone, senior director of sales, channel east
• Nicki Dewhurst, senior marketing director, Asia Pacific and Japan
• Allison Clarke, director of global channel programs
• Andrea Carter, regional director marketing, NEMEA
• Maria Ardila, LATAM channel director
• Claudia Vizcarra, multi country sales director, LATAM
• Alejandra Garcia, country director, Mexico
• Christina Nairn, senior manager, channel marketing
• Tara Bresnahan, senior manager, channel marketing, Americas

2020 Power 100

Kendra Krause, Erin Malone and Caralyn Stern have also topped CRN’s 2020 Power 100, an elite subgroup of standout individuals from the Women of the Channel list.

These executives are recognized as extraordinary women who have inspired peers through their thought leadership and tireless dedication to channel advancement.

Michael Valentine, chief revenue officer at Sophos says of the achievement:

To keep pace with increasingly cunning cyber attackers, Sophos is arming IT professionals and the channel that serves them with the industry’s most innovative and highly effective next-generation cybersecurity solutions. These 13 women are committed to helping businesses stay one step ahead of cybercriminals’ advanced attacks, and together they’ve built and continue to enable the industry’s best channel program, bar none.

The Women of the Channel accolades are the latest in a series from CRN. Already this year, seven Sophos executives were named 2020 Channel Chiefs. We also received a 5-star rating in CRN’s 2020 Partner Program Guide for the competitive advantages only provided through the Sophos Partner Program.

Moving data and other corporate resources to the cloud makes a whole lot of sense, especially with more of us than ever needing flexibility in how, when, and where we get work done.

While cloud providers like AWS give you the flexibility to make your move to the cloud as temporary or permanent as you need, there are some practical considerations you need to manage.

For example, you need to provide users with essential virtual desktop services required for day-to-day work. You also need to provide secure remote access for administrators and developers to private applications running on virtual machines in the cloud, which is the focus of this article.

Simple, secure remote access with Sophos XG Firewall

VPN connections are crucial to enabling secure remote working. Sophos XG Firewall provides two options for creating secure access to services hosted in AWS:

Option 1: SSL VPN

If you have users working remotely the XG Firewall User Portal is a convenient and secure way to access resources within AWS. From it, users can download a customized SSL VPN client software bundle, which includes an SSL VPN client, SSL certificates, and a configuration.

You first need to deploy XG Firewall in your organization’s Virtual Private Cloud (VPC). In the example below, the XG is deployed in a single Availability Zone, with one Elastic Network Interface (ENI) in each of the two subnets, a Public subnet and a Private subnet.

The Public subnet ENI has an Elastic IP address mapped that can be either used directly or in a DNS record. (View instructions for deploying Sophos XG Firewall on AWS).

An alternative to the XG Firewall User Portal is to install the SSL VPN client (or SophosConnect) on user systems.

View SSL VPN Client Instructions or SophosConnect Instructions / Video.

To complete this setup in your AWS console:

1. Confirm your AWS route tables have a route for the Internet via the XG’s private interface (ENI) that the internal subnets use, and the public subnet table has an Internet route via the Internet Gateway, for the XG to use.
2. Confirm your XG security group(s) allow the SSLVPN port in use (may not be 443)
3. Confirm your other security group(s) allow traffic internally for the SSLVPN connections

Option 2: Sophos Remote Ethernet Device (RED)

If you want the ultimate in VPN reliability and security between your remote workers and your cloud environments, unique to Sophos is the Remote Ethernet Device (RED).

While perhaps not every employee in a business may require a RED, it may be a suitable choice for senior managers and people who deal with confidential information. Using a RED is simple:

1. The IT team preconfigures and registers the RED with the XG Firewall, then mails it out to the recipient.
2. The recipient plugs the device into their home router.
3. The recipient sets up a wireless or wired connection between their laptop and the RED device.

Once connected to the router the RED connects back automatically to the XG Firewall (in AWS) and establishes a secure RED Tunnel. (Full Instructions – with video).

Helpful Resources:

Now more than any other time in history, businesses are working remotely. Going virtual, while enabling collaboration and helping to maintain regular business operations in these trying times, introduces a fair amount of challenges.   

Data shows that businesses with smaller teams have been increasingly targeted by hackers and cybercriminals in recent years. In fact, about one third of the 850 global businesses in this study report suffering a cyberattack in the last year.  

Poor password hygiene in the workplace continues to be a problem. Data shows that employees consistently set basic, formulaic, and recycled passwords that can be easily exploited.  For any organization, this poses a security risk, and can lead to a loss of money, draining of IT resources, and a damaged brand. Businesses adapting to remote working infrastructures should prioritize password best practices to enable their newly remote teams to work efficiently and securely.  

So what’s the first step?  A fast and affordable way to ramp up security for a small yet mighty team is with a password manager. Password managers mitigate the inherent challenges of memorizing dozens of complex passwords by storing users’ passwords in an encrypted vault. Additionally, password managers can generate unique and extremely strong passwords for each online account and service.  

The next step is to enable YubiKey two-factor authentication (2FA) to your password manager to ensure that the passwords in your vault are protected by a physical key, regardless of operating system. The YubiKey delivers the strongest, hardware-based defense against phishing and other threats leading to account takeovers. The combined solution of a password manager and a YubiKey is an easy way for businesses to bolster account login security—no matter the size of their team. 

At Yubico, we take pride in our ecosystem of technology partners, a number of whom are password managers and services that advocate for better password management. 

“The workplace is changing more rapidly than we ever imagined, and this brings new security considerations. To keep a tight grip on who can access, amend, and share your data stored using the cloud, it’s best to use a password manager like 1Password in combination with multi-factor authentication.”

— Matt Davey, 1Password COO

“At Bitwarden, we empower individuals, teams, and organizations to store and share sensitive data easily and securely. We are proud to partner with Yubico to build a strong security foundation for our users.”

— Gary Orenstein, Chief Customer Officer, Bitwarden

“Our world and workspaces are changing fast due to the current crisis. Private devices are now used for work, which leaves user credentials at risk and in need of protection. With a smart password manager protected with a YubiKey, you keep important and confidential company data secure.”

— Sergej Schlotthauer, VP Security & Strategic Alliances, Matrix42

“Don’t give attackers a single target. Use a different password everywhere, a different email address, or alias with subscriptions, and protect your accounts with a hardware authenticator. Your other accounts won’t be at risk in the event one account is compromised.”

— Ricardo Signes, CTO, Fastmail

As your business transitions to an increasingly remote working environment, consider investing in a password manager plus the YubiKey for easy to use, hardware-backed 2FA. Want to learn more? Watch our roundtable Q&A with 1Password to hear expert insights and best practices on effective password management.

With hackers busy exploiting topical events to steal access credentials, properly maintaining the access roles and privileges for your AWS, Azure and Google Cloud Platform (GCP) accounts is an essential step in safeguarding the data and workloads you store with these cloud providers.

In this article I’ll walk through how Sophos Cloud Optix, our cloud security posture management tool, helps you secure access to your public cloud accounts.

Multi-factor authentication

Multi-factor authentication (MFA) adds an extra layer of protection on top of a username and password, protecting against password compromise. All user accounts should have MFA enabled. Cloud Optix ensures MFA is enabled for AWS accounts, and the Cloud Optix service itself.

Protecting cloud accounts with MFA

Identity and Access Management (IAM) is the AWS tool that controls access to services within your Amazon cloud account. You should ensure MFA is enabled for all IAM users that have AWS console access.

The Cloud Optix inventory view allows you to identify any IAM users without MFA enabled. This information is provided by an AWS Credentials report, which is updated by AWS every four hours.

To view this information in the Cloud Optix console, select ‘Inventory’ in the left-hand navigation > Select ‘IAM’ > Select ‘MFA Disabled’. Access to you AWS account is required to enable MFA for the users identified.

Protecting your Cloud Optix account with MFA

You can also use MFA to improve the security of your Cloud Optix console. This means you must use another form of authentication, as well as username and password, when you sign into Cloud Optix. Learn how to enable MFA for Cloud Optix.

Adopt the principle of Least Privileged Access

The services within your Amazon cloud account will include server instances, databases, storage – literally anything you run in Amazon. As best practice you should give users, groups and services only those privileges which are essential to perform their role. This minimizes risk and exposure.

However, keeping track of the actual use of the privileges assigned in IAM for all accounts, groups and roles can be a nearly impossible task without a lot of manual labor.

Cloud Optix IAM Visualization helps by visualizing these relationships, equipping your teams with a practical view to manage IAM and over-privileged access to cloud accounts and resources.

Avoid internet-facing resources

Accidental or malicious changes to the cloud resource configurations in AWS, Azure or GCP, such as S3 buckets, RDS, and EBS leave your organization exposed to automated hacker searches looking to exploit sensitive data.

Cloud Optix quickly identifies any publicly accessible data or website files, and provides guided or automated remediation pathways to make them private (and secure). Cloud Optix can also add an additional level of security to these critical services with Guardrails, ensuring no configuration changes are made without permission.

Helpful Resources:

In the matter of just one week, Google reported that it saw more than 18 million daily malware and phishing emails related to COVID-19. That’s an astonishing number, and one that is not likely to slow down any time soon. 

For organizations across the globe, it is imperative to quickly, securely, and affordably fill existing security gaps to effectively support remote workers. For government agencies, the stakes are even higher. It is critical to protect and sustain our government infrastructures in a time when many citizens are relying on these services more than ever before. 

Preventative measures against phishing are not new, but scaling them quickly across an organization is. This is uncharted territory for many government agencies, and the Personal Identity Verification (PIV) and Common Access Card (CAC) authentication infrastructure lacks the convenience and flexibility required to support a rapid shift to remote work environments. While PIV and CAC set a high bar for security, they rely on in-person identification to issue credentials — an impractical requirement when servicing droves of new remote workers or renewing recently expired credentials. 

US government releases guidance on securing remote workers

Recognizing the immediate need for increased security without disrupting productivity, the United States White House Office of Management and Budget (OMB) released a directive for the broader government. The memo acknowledges three main points: 

1. 1. Not all agencies may be able to issue PIV credentials during the time of remote work.
   2. Agencies are directed to use the breadth of available technology capabilities to fulfill service gaps and deliver mission outcomes. 
   3. Agencies should be prepared to issue an alternate credential or authenticator for physical and logical access.

YubiKey approved as PIV alternative for strong authentication 

For federal entities, we know that this means finding applications and solutions — like the YubiKey — that already have the government seal of approval and a federal terms of service agreement to enable rapid and seamless deployments. 

“A FIDO security key can help bridge the gap,” explains Jeremy Grant, Managing
Director of Cybersecurity at Venable, and former Senior Advisor to the Obama Administration’s National Strategy for Trusted Identities in Cyberspace. 

“Much like the PIV card, FIDO security keys leverage public key cryptography for authentication, which can’t be phished — an important benefit at a time when we’re seeing an explosion of COVID-related phishing attacks,” continues Grant. “Agencies can mail FIDO security keys directly to employees needing strong authentication, and because they work via USB and NFC, they don’t require a specialized reader as PIV cards do.”

FIDO security keys are 1 of 3 government-approved alternate authenticators, according to the Department of Defense. This guidance was released as early as 2018, demonstrating that the US government recognized the need for agile, adaptable, and affordable security solutions far before COVID-19. 

Global governments recommend multi-factor authentication to protect remote workers  

Efforts from the US government are underscored by similar initiatives by many other leading government agencies around the world. For example, the British NCSC (National Cyber Security Centre) and European Union Agency For Cybersecurity (ENISA) both issued guidance on best practices to secure citizens and employees working remotely, and strongly recommended multi-factor authentication (MFA) as a top priority. 

For more information on the YubiKey as a federally-approved authentication solution, tune into our latest on-demand panel webinar with Danelle Barrett, former US Rear Admiral, and Director Navy Cyber Security and Deputy Chief Information Officer. 

Additionally, read how FIDO2 is aiding eIDAS (electronic identification, authentication and trust services) as the legal basis for cross-border interoperability of electronic identification, authentication, and electronic signatures amongst EU Member States. 

Hi XG Community!

We’ve released XG Firewall 18.0 GA-Build379. Initially, the firmware will be available by manual download from the Licensing Portal. We will gradually release the firmware via auto-update to customers.

Please visit the following link for more information regarding the upgrade process: Sophos XG Firewall: How to upgrade the firmware.

Security Release

• Fixes SQL injection vulnerability and malicious code execution in XG Firewall/SFOS detailed out in KBA135412

Important note

Issues Resolved in XG Firewall 18.0 GA-Build379

• NC-59408 [API Framework, UI Framework] SQLi prevention in hybrid request – ORM fields and mode parameters (CVE-2020-12271)
• NC-58898 [Email] Potential RCE through heap overflow in awarrensmtp (CVE-2020-11503)
• NC-59300 [Email] Blind pre-auth SQLi in spxd on port 8094
• NC-59454 [UI Framework] Enable apache access logs

More on XG Firewall v18

Please refer XG Firewall v18 highlights for more details on all-new Xstream Architecture delivering extreme new levels of visibility, protection and performance. Also, check out our XG Firewall v18 playlist on YouTube to find out what’s new in XG Firewall v18!

Get it now!

As usual, this firmware update is no charge for all licensed XG Firewall customers. The firmware will be rolled-out automatically to all systems over the coming weeks but you can access the firmware anytime to do a manual update through MySophos.

For fresh installations, please find the following installer images:

Things to know before upgrading

Note: Please note that upgrading from SFOS v17.5.x to SFOS v18 GA-Build379 may take longer than normal, due to the file system correction checks. The approximate time is dependent on the hard disk size and state. More info available in this KBA.

Making the most of your new XG Firewall features

Free Online Training

• Available for free for all XG Firewall customers, our delta training program will help you make the most of the new features in XG Firewall v18.
• This online program walks you through the key enhancements since v17.5 and takes about 90 minutes to complete.

Customer Resources and How-To Videos

• Also be sure to visit the Customer Resource Center for the latest How-To Videos and links to documentation, the community forums, training and other resources.

Take advantage of Partner and Sophos Professional Services

• To augment your local Sophos partner’s services, we offer services to help you getting up and running and make the most of your XG Firewall, including the latest capabilities in v18.
• While Sophos Professional Services can help with any task, here are the most common services they provide:
  • XG Firewall deployment and setup
  • XG Firewall v18 DPI, FastPath and SSL Engine Optimization
  • XG Firewall Health Checks

Here are some direct links to helpful resources:

New to XG Firewall?

If you’re new to XG Firewall, see how it provides the world’s best network visibility, protection and response on the new XG Firewall website. 

Hi XG Community!

We’ve released XG Firewall 17.5 MR12. Initially, the firmware will be available by manual download from the Licensing Portal. We will gradually release the firmware via auto-update to customers.

Please visit the following link for more information regarding the upgrade process: Sophos XG Firewall: How to upgrade the firmware.

Note: The upgrade from version 17.5 MR12 to 18.0 will follow soon.

• Security Release
• Fixes SQL injection vulnerability and malicious code execution in XG Firewall/SFOS detailed out in KBA135412

Note: Hotfix referenced in KBA135412 is NOT required for 17.5 MR12 as CVE-2020-12271 has been fixed in this release version.

• NC-59408 [API Framework, UI Framework] SQLi prevention in hybrid request – ORM fields and mode parameters (CVE-2020-12271)
• NC-58898 [Email] Potential RCE through heap overflow in awarrensmtp (CVE-2020-11503)
• NC-59300 [Email] Blind pre-auth SQLi in spxd on port 8094
• NC-59454 [UI Framework] Enable apache access logs

To manually install the upgrade, you can download the firmware from the Licensing Portal. Please refer to Sophos XG Firewall: How to upgrade the firmware.

The number of devices managed in your Sophos Central will increase over time, and, as your estate evolves, some devices may not have a recent last activity date.

This could be due to a multitude of reasons. The device may have been decommissioned. It was set up as a quick test machine. Or the user has left the company. The list goes on.

Whatever the reason, you may already have a robust process in place for dealing with such devices. Perhaps your tenant is looking spick and span and is a model deployment. Although, I’m sure for many of us out there, there’s a device that may have slipped through the net and is lying dormant in Sophos Central.

So why do I need to do this?

Currently the Sophos Central Active Directory (AD) Sync Utility supports synchronizing AD users and user groups, but not devices and device groups. This means there is currently no native method to clear old devices from Sophos Central automatically. If there are many devices in need of deleting, we do not want to manually delete these through the UI of Sophos Central.

We have two options. The first is somewhat a manual process using the Sophos Central API to gather device information and manually cross reference those devices against your source of devices. You can create a script which will delete devices using the Sophos Central API.

At the end of this blog post there are two demo scripts to allow you to gather inactive devices and then delete them.

The second option still uses the Sophos Central API to gather device information, but with the added benefit of using a Security Information and Event Management (SIEM) and Security Automation and Orchestration (SOAR) tool to make it as automated as possible from end to end.

For the second option we need to answer a few questions:

• What data will I need to collect to help determine whether I can delete a device?
• What happens if an active machine is deleted automatically?
• What tools do I have to assist with this process?

To answer these questions, I will cover the basic components of our process as a template for you to implement into your own environment and processes. For a quick overview, below is a process diagram we have in place.

What data is needed?

Firstly, and most importantly, we need a source of truth for devices, and for most organizations this is AD. You will need to monitor the latest changes in the Disabled OU or equivalent location dependent on how your organization manages retired devices and rebuild processes. Important fields from this data source are:

• Hostname
• Domain
• Distinguished Name
• Operating System
• Operating System Build Number

We also need to establish the current devices in Sophos Central. We can gather an inventory list of devices using the Sophos Central API.

The fields will be gathered using the Sophos Central get endpoint API.

Key fields from this data for this process are:

• hostname
• id
• lastSeenAt
• os
• type
• associatedPerson
• tenant

Together, these will form a solid base to help determine which systems are potential candidates for deletion.

How can we validate the AD and Central data?

The data is correlated using the hostname and domain of the device. In an ideal world, we would want to have a universally unique identifier (UUID) which ties them together. You may have another method which works in your environment to achieve this correlation.

Once the two data sources are correlated, we need to establish some comparatives before we pass the data to a SOAR tool for processing to ensure there is some logic to handle the events.

What questions require some logic to answer?

Our aim for this process is to remove devices from Sophos Central which are no longer active. To achieve this without deleting valid devices we need to think of likely scenarios of when we do not want to delete a device.

Determine device inactive period:

The purpose of this is to allow a sensible period of inactivity for a system in the disabled OU. By only returning those devices inactive above a certain period of time, we are less likely to delete a device which may not need to be deleted from Sophos Central.

• Convert lastSeenAt field to Unix epoch time using strptime, lastSeenAt format is: “2019-09-23T12:02:01.700Z”
• Calculate how many days since device was last seen: (now() Unix epoch – lastSeenAt Unix epoch)/86400

Validate whether the OS build matches:

There could be a situation where the hostname and domain match a system in the inventory where the OS build does not match. In this instance, this device should have a flag set for manual intervention to avoid errors. The best method is comparing the OS build of the device in against the data from Sophos Central.

Automate

We now have several systems identified in the data which could be deleted from Sophos Central. Using a SOAR platform will allow you to pass each event through a flow process to determine what should happen to the device.

By checking the data you have from your SIEM against live Sophos Central Endpoint API data, you can make a final validation that the device is indeed inactive and can be deleted.

In addition to the automation aspect of deleting devices, we also need to do some auditing and perhaps include some scenarios to enforce manual intervention before deletion can be authorized.

Monitor VIP devices:

To avoid unintentional deletion of devices for VIP users, we would advise flagging these devices for manual intervention to verify whether the device can be deleted from Sophos Central. One possibility is using a specific user AD group to define who these users are.

Active devices:

After comparing the machine last activity with the data from the SIEM and that obtained through the live Sophos Central API query, it’s calculated that the device has reported back into Sophos Central recently. These machines should be raised for manual validation before they are deleted.

Avoid duplication of processing:

Logging which devices have been deleted allows for auditing and exclusion of these systems when collating the information at the start of the process.

Track active processing which has been passed for manual intervention:

Where devices require manual intervention and a ticket is opened, it is recommended to log these and exclude from future processing while the ticket is open. As part of the SOAR process intervention, this can be automated. Once the relevant response is received, the change can be made. Whether the device is deleted or not is noted and the ticket is updated, and the ticket log is removed as active.

Track deletion failures:

It is recommended to also flag failures to delete or verify device information so manual intervention can be applied to these.

Whoops, an active device was removed

In a situation where a device is removed incorrectly, the following steps are required to protect the endpoint:

• If the host does not have Sophos Endpoint Protection installed, simply download the latest installer from Sophos Central and install it to the endpoint.
• If the endpoint already has Sophos Endpoint Protection installed and Tamper Protection is not enabled, first uninstall Sophos Endpoint Protection and install using the latest installer from the correct Sophos Central tenant.
• If Sophos Endpoint Protection is installed and Tamper Protection is enabled, please follow the steps below:

1. Log on to the correct Sophos Central tenant: https://cloud.sophos.com/manage/login
2. Go to: Logs & Reports > Endpoint & Server Protection > Recover Tamper Protection passwords (Passwords will remain in this report for 60 days after deletion)
3. Search for the host name and click on ‘View details’ to view the latest Tamper Protection password that was active on the machine prior to deletion
4. Open Sophos Endpoint Protection UI on the device
5. Click on ‘Admin login’ and enter the Tamper Protection Password
6. Select ‘Settings’ and tick the box ‘Override Sophos Central Policy for up to 4 hours to troubleshoot’
7. Under ‘Control on Users’ turn off Tamper Protection
8. Uninstall Sophos Endpoint Protection
9. Reinstall Sophos Endpoint Protection with the latest installer from the correct Sophos Central tenant

Wind it up and let it go

With the basic building blocks in place you are ready to dry run the automation flow. Some key milestones are:

• In your chosen SOAR platform be sure to disable the final action to delete the device before testing.
• Validate whether each device meets its expected outcome before committing to delete.
• When going live with the automation start off by deleting devices slowly. This will allow time to further fine tune your process and find any more gotchas.
• Reach out to your AD admins and service desk teams for feedback. They can provide valuable insight to the process and could highlight a key point that may have been overlooked.

For us, this process of removing the clutter of unused devices in Sophos Central has been invaluable. It also gives Central admins time back to focus on other tasks, which would normally be taken up with a manual process of checking and deleting old devices.

Sample Python to gather devices

Gather old device data

To gather old devices to check against AD please use the following code example (you will need to have the Sophos Central API Connector installed). This will create JSON files of the devices.

You will need to change ‘find_old’ and ‘client_id’ variables.

# Demo code sample using Sophos Central API connector. Not intended for production use.

import getpass
import logging
from sophos_central_api_connector import sophos_central_api_tenants as api_tenant
from sophos_central_api_connector import sophos_central_api_auth as api_auth
from sophos_central_api_connector import sophos_central_api_connector_utils as api_utils
from sophos_central_api_connector import sophos_central_api_get_data as get_api
from sophos_central_api_connector.sophos_central_api_output import process_output_json as json_output
from sophos_central_api_connector.config import sophos_central_api_config as api_conf


def main():
    log_level = "INFO"
    log_name = log_level
    level = getattr(logging, log_name)
    logging.basicConfig(level=level, format='%(asctime)s - %(levelname)s - %(message)s',
                        datefmt='%d/%m/%Y %I:%M:%S %p')

    logging.info("Start of Logging")

    # Enter the variable to set how old devices you wish to return. E.g. for more than 30days enter '-P30D'
    find_old = "<ADD IN TIME>"

    # Enter your Sophos Central API Client ID (This is generated when setting up Sophos Central API credentials)
    client_id = "<ADD IN YOUR CLIENT ID>"

    # Set authorisation and whoami URLs
    auth_url = api_conf.auth_uri
    whoami_url = api_conf.whoami_uri
    partner_url = api_conf.tenants_ptr_uri
    organization_url = api_conf.tenants_org_uri

    # Get client secret by prompting user
    client_secret = getpass.getpass(prompt="Provide Sophos Central Secret ID: ", stream=None)

    # Get Sophos Central API Bearer Token for authorisation
    sophos_access_token = api_auth.get_bearer_tok(client_id, client_secret, auth_url)

    # Construct id_headers
    headers = api_auth.validate_id_headers(sophos_access_token)

    # Lookup up the unique ID assigned to the business entity for Sophos Central API
    whoami_id, whoami_type, whoami_data = api_auth.get_whoami_data(headers, whoami_url)

    # Obtain correct whoami uri/header based on the whoami type
    header_type, tenant_url = api_auth.validate_whoami_type(whoami_type, whoami_data, partner_url, organization_url)

    # Construct tenant headers
    tenant_headers = api_tenant.gen_tenant_headers(headers, whoami_id, whoami_type, header_type)

    # Check and gather tenant information
    if whoami_type == "tenant":
        tenant_info = api_tenant.type_tenant(tenant_headers, whoami_id, tenant_url, sophos_access_token)
    else:
        tenant_info = api_tenant.get_tenant_info(headers, tenant_url, sophos_access_token)

    # Generate urls for tenants
    api = "endpoint"
    page_size = "50&lastSeenBefore={0}&fields=tenant&fields=hostname&fields=id&fields=lastSeenAt&fields=os&fields=type&fields=associatedPerson".format(find_old)

    # Generate tenant url data
    tenant_url_data = api_utils.generate_tenant_urls(tenant_info, page_size, api, from_str=None, to_str=None)

    for ten_id, ten_item in tenant_url_data.items():
        # Pass the ten_url_data and gather devices
        tenant_id = ten_id
        # get data information for the tenant in the loop
        json_data = get_api.get_data(tenant_url_data, page_size, tenant_id, api)
        filename = tenant_url_data[tenant_id]['filename']
        json_output(json_data, filename, api)


if __name__ == "__main__":
    main()

Delete identified devices in Sophos Central

To delete the identified assets you can edit the JSON that was gathered previously and remove any devices which should not be deleted. The demo script assumes the JSON file is in the same location as the script. You will need to change ‘client_id’ variable.

# Demo code sample using Sophos Central API connector. Not intended for production use.

import getpass
import logging
import os
import json
import requests
from sophos_central_api_connector import sophos_central_api_tenants as api_tenant
from sophos_central_api_connector import sophos_central_api_auth as api_auth
from sophos_central_api_connector import sophos_central_api_connector_utils as api_utils
from sophos_central_api_connector.config import sophos_central_api_config as api_conf


def main():
    log_level = "INFO"
    log_name = log_level
    level = getattr(logging, log_name)
    logging.basicConfig(level=level, format='%(asctime)s - %(levelname)s - %(message)s',
                        datefmt='%d/%m/%Y %I:%M:%S %p')

    logging.info("Start of Logging")

    # Enter your Sophos Central API Client ID (This is generated when setting up Sophos Central API credentials)
    client_id = "<ADD IN YOUR CLIENT ID>"

    # Set authorisation and whoami URLs
    auth_url = api_conf.auth_uri
    whoami_url = api_conf.whoami_uri
    partner_url = api_conf.tenants_ptr_uri
    organization_url = api_conf.tenants_org_uri

    # Get client secret by prompting user
    client_secret = getpass.getpass(prompt="Provide Sophos Central Secret ID: ", stream=None)

    # Get Sophos Central API Bearer Token for authorisation
    sophos_access_token = api_auth.get_bearer_tok(client_id, client_secret, auth_url)

    # Construct id_headers
    headers = api_auth.validate_id_headers(sophos_access_token)

    # Lookup up the unique ID assigned to the business entity for Sophos Central API
    whoami_id, whoami_type, whoami_data = api_auth.get_whoami_data(headers, whoami_url)

    # Obtain correct whoami uri/header based on the whoami type
    header_type, tenant_url = api_auth.validate_whoami_type(whoami_type, whoami_data, partner_url, organization_url)

    # Construct tenant headers
    tenant_headers = api_tenant.gen_tenant_headers(headers, whoami_id, whoami_type, header_type)

    # Check and gather tenant information
    if whoami_type == "tenant":
        tenant_info = api_tenant.type_tenant(tenant_headers, whoami_id, tenant_url, sophos_access_token)
    else:
        tenant_info = api_tenant.get_tenant_info(headers, tenant_url, sophos_access_token)

    # Generate urls for tenants
    api = "endpoint"
    page_size = None

    # Generate tenant url data
    tenant_url_data = api_utils.generate_tenant_urls(tenant_info, page_size, api, from_str=None, to_str=None)

    logging.info("Creating device deletion URLs...")

    for file in [os.path.basename(file) for file in os.listdir() if file.endswith(".json")]:
        with open(file, 'r', encoding='utf8') as device_file:
            logging.info("Processing file: {0}".format(file))
            device_dict = json.load(device_file)
            for ten_id, ten_item in tenant_url_data.items():
                tenant_id = ten_id
                for item in device_dict.values():
                    tenant_ref = item['tenant']['id']
                    if tenant_ref == tenant_id:
                        orig_url = ten_item['orig_url']
                        headers = ten_item['headers']
                        device_id = item["id"]
                        endpoint_url = "{0}/{1}".format(orig_url, device_id)
                        del_ep = requests.delete(endpoint_url, headers=headers)
                        del_sc = del_ep.status_code
                        logging.info("Device ID: {0}, deletion status: {1}".format(device_id, del_sc))


if __name__ == "__main__":
    main()

As we described last week in this KBA, Sophos and its customers were the victims of a coordinated attack by an unknown adversary. This attack revealed a previously unknown SQL injection vulnerability that led to remote code execution on some of our firewall products. As described in the KBA, the vulnerability has since been remediated.

This post is the result of many hours of research and reverse-engineering by SophosLabs and Sophos internal security teams, working in conjunction with product management to coordinate a hotfix and global response within two days of discovering this attack. In the spirit of transparency, we want to describe the nature of the attack and a detailed analysis of the malware based on our investigation and current understanding.

There was significant orchestration involved in the execution of the attack, using a chain of Linux shell scripts that eventually downloaded ELF binary executable malware compiled for a firewall operating system. This attack targeted Sophos products and apparently was intended to steal sensitive information from the firewall.

How the attack began

The infection process started when an attacker discovered, and exploited, a zero-day SQL injection remote code execution vulnerability. The exploit of this vulnerability resulted in the attacker being able to insert a one-line command into a database table.

This initial injected command triggered an affected device to download a Linux shell script named Install.sh from a remote server on the malicious domain sophosfirewallupdate[.]com. The command also wrote this shell script to the /tmp directory on the device, used the chmod program to designate the file as executable, and executed it.

The script (written to the appliance as x.sh) ran a series of SQL commands and dropped additional files into the virtual file system to lay the groundwork for the rest of the attack.

The Install.sh script, initially, ran a number of Postgres SQL commands to modify or zero out the values of certain tables in the database, one of which normally displays the administrative IP address of the device itself. It appears that this was an attempt to conceal the attack, but it backfired: On some appliances, the shell script’s activity resulted in the attacker’s own injected SQL command line being displayed on the user interface of the firewall’s administrative panel. In place of what should have been an address, it showed a line of shell commands.

This script also dropped at least two other shell scripts into the /tmp directory, and modified at least one shell script that is part of the firewall’s operating system to add a set of commands to the end of the script. This last script, in particular, is relevant because the malware modified services to ensure it ran every time the firewall boots up; it served as a roundabout persistence mechanism for the malware.

The three shell ELF game

The installer script, x.sh, dropped two completely new shell scripts, and modified an existing script that’s part of the operating system.

One of the dropped shell scripts was named .lp.sh and its primary function was to connect to the malicious sophosfirewallupdate site, and download a Linux ELF executable file compiled to run on the firewall operating system named lp. The script wrote that downloaded file to /tmp with a filename of just b.

The b program, when run, deleted itself from the filesystem of the device, so it was only present in memory. It appeared in the process list as a program whose name, cssconf.bin, is one character off from a legitimate process that normally runs on a firewall, cscconf.bin. The highlighted process list below shows the malicious program as it would have appeared running on an infected firewall. It is also notable that it listed its parent process ID as 1, which the legitimate cscconf.bin would never have done.

While b was in memory, it repeated a series of tasks every 3 to 6 hours — a delay interval chosen at random the first time it ran, and reused thereafter.

First, b checks to see if it can make a connection to a machine with the IP address of 43.229.55.44. If the ELF cannot make a connection to that IP address, it attempted to resolve the IP address for the malicious domain sophosproductupdate[.]com.

If it resolved the IP for that domain, and DNS did not return a value of 127.0.0.1 as a result, then it downloaded another Linux ELF executable called sophos.dat, which we’ll discuss in the next section.

Shell script number two dropped by the Install.sh/x.sh script is written to the /tmp directory with a filename of .pg.sh. Its main purpose was to download a second, different ELF executable, which was called bk on the webserver and gets written to the filesystem with the name .post_MI.

Earlier we mentioned that Install.sh, the first stage dropper, ran a number of Postgres SQL commands. One of these commands modified a specific service value entry so that .post_MI executed whenever that service executed; this provided persistence by starting the malware at every reboot.

This executable had limited functionality: It checked to see whether a file named .a.PGSQL (more on this in a minute) has been written to the /tmp directory, and if it didn’t find it, it attempted to download a shell script from the web server hosted at ragnarokfromasgard.com, called patch.sh. At the time we performed the analysis of the attack, this server wasn’t responding.

The third shell script is a modification of a shell script that is already part of the firewall’s internal operating system, named generate_curl_ca_bundle.sh. The Install.sh/x.sh script makes a backup copy of the original (prepending a dot to the filename, .generate_curl_ca_bundle.sh) before it modified the original script to append code to the file. That code writes out and drops yet another shell script, /tmp/I (just a capital letter i).

The I script has two primary functions. First, it performs a “touch” of the /tmp/.a.PGSQL file (an act that, if the file does not exist, creates it in the /tmp directory). The previously-mentioned .post_MI ELF executable checks to see if .a.PGSQL exists as part of its execution.

I then retrieves a shell script file named lc from the sophosfirewallupdate domain, and writes that to the /tmp directory as .n.sh and executes it. This script replicated the same behavior as the .lp.sh script (mentioned above), and attempts to download and execute the b ELF executable from the malicious sophosfirewallupdate website. This download of b is the persistence mechanism, given that the b process deletes itself off disk as one of its first actions.

Data exfiltration process

Note: This section describes our understanding of the data exfiltration capabilities of the malware at the time of publication of this article, but we have not discovered any evidence that the data collected have been successfully exfiltrated.

The steps involving the shell scripts and ELF binary executables apparently were done in order to bring the attack to the point where the malware downloaded and executed a file that had been named Sophos.dat on the remote server, saved to the filesystem as 2own.

This malware’s primary task appears to be data theft, which it can perform by retrieving the contents of various database tables stored in the firewall, as well as by running some operating system commands. At each step, the malware collects information and then concatenates it to a file it stores temporarily on the firewall with the name Info.xg.

First, the binary attempts to retrieve the public-facing IP address where the firewall is installed. It does this first by querying the website ifconfig.me, and if that site is not reachable for some reason, it tries to do the same by contacting checkip.dyndns.org.

Next, it queries a number of data storage areas on the firewall to retrieve information about the firewall and its users.

This diagram below shows the capability of the malware to exfiltrate data.  As of the date of publication, we have not discovered any evidence that the data collected have been successfully exfiltrated.

The malware shows the capability to retrieve only firewall resident information, which may include:

• The firewall’s license and serial number
• A list of the email addresses of user accounts that are stored on the device, followed by the primary email belonging to the firewall’s administrator account
• Firewall users’ names, usernames, the encrypted form of the passwords, and the salted SHA256 hash of the administrator account’s password. Passwords were not stored in plain text.
• A list of the user IDs permitted to use the firewall for SSL VPN and accounts that are permitted to use a “clientless” VPN connection.

The malware then queried an internal database of the firewall to retrieve a list of the IP address allocation permissions for the users of the firewall, as well as information about the appliance itself: What version of the operating system is running, what type of CPU and amount of memory is present on the device; how long has it been operational since the last reboot (the ‘uptime’); and the output of the ifconfig and ARP tables.

Once the malware wrote all this information to Info.xg, it then compressed it using the tar compression tool, and then used OpenSSL to encrypt the archive file. The attackers used the Triple-DES algorithm to encrypt the file, and for a pass phrase, the word “GUCCI” in all capital letters. The malware is then intended to attempt to upload this encrypted file to a machine at the IP address 38.27.99.69, and then cleans up its tracks by deleting the files temporarily created while it collected the information.

Remediation and response

Files associated with this attack have been added to the definition Linux/Agnt-G and domains and IP addresses have been flagged as malicious in the SophosXL domain reputation service.

A hotfix update has already been released to Sophos customers to plug the hole used by the attackers to access the firewalls. If you don’t have automatic updates enabled in the firewall, please follow these instructions to enable them.

While the best source of information for sysadmins will be the Sophos knowledge base entry on this issue, there are a few steps Sophos customers can take immediately to prevent this from happening to firewall appliances.

Since the attack was discovered, Sophos has taken a number of steps, which we can summarize as follows: SophosLabs blocked domains found in initial forensic analysis of the attack, and later identified and blocked additional domains and IP addresses associated with the attack.  We notified customers about mitigation steps.  We issued a telemetry update to firewalls; and we designed, developed, and tested a hotfix to mitigate the SQL injection and this  attack, and then pushed the hotfix to supported devices. Sophos also has submitted a request for a CVE and will add the CVE number to the knowledge base article once available. We have also taken additional actions that fall outside the scope of this article.

This issue has manifested itself on systems that have exposed the HTTPS admin service or the User Portal on the WAN interface.  Community manager Marco Ginoccio writes: ” To prevent this issue, choose the Administration link on the left-hand navigation panel of the management console, then click the Device Access page illustrated below. Customers must ensure that both Admin services and User Portal are deactivated on the WAN interface as highlighted:”

Indicators of Compromise (IoCs)

Files described in this analysis

File Name	SHA256	FileType	Functionality
Install.sh [/tmp/x.sh]	736da16da96222d3dfbb864376cafd58239344b536c75841805c661f220072e5	Bash	Main install script. Compromised firewall settings, dropped two files and modified a third.
		Shell script
lc [/tmp/.n.sh]	a226c6a641291ef2916118b048d508554afe0966974c5ca241619e8a375b8c6b	Bash	Downloaded lp (ELF dropper)
		Shell script
bk [/var/newdb/global/.post_MI]	4de3258ebba1ef3638642a011020a004b4cd4dbe8cd42613e24edf37e6cf9d71	ELF	Downloaded patch.sh
		X86 binary
lp [/tmp/b]	9650563aa660ccbfd91c0efc2318cf98bfe9092b4a2abcd98c7fc44aad265fda	ELF	Main dropper. Downloaded 2own (data exfiltration) module
		X86 binary
in.s_h	8e9965c2bb0964fde7c1aa0e8b5d74158e37443d857fc227c1883aa74858e985	Bash	Slightly modified form of install.sh
		Shell script
2own	31e43ecd203860ba208c668a0e881a260ceb24cb1025262d42e03209aed77fe4	ELF	Data theft module. Exfiltrates to 38.27.99.69
		X86 script

 

Network indicators

URLs

hxxps://sophosfirewallupdate.com/sp/Install.sh

hxxp://sophosfirewallupdate.com/sh_guard/lc

hxxps://sophosfirewallupdate.com/bk

hxxps://sophosfirewallupdate.com/sp/lp

hxxps://ragnarokfromasgard.com/sp/patch.sh

hxxps://sophosfirewallupdate.com/sp/sophos.dat

hxxps://sophosfirewallupdate.com/in_exit

hxxps://sophosfirewallupdate.com/sp/lpin

hxxp://sophosfirewallupdate.com/bkin

hxxp://filedownloaderservers.com/bkin

hxxps://sophosfirewallupdate.com/sp/p.sh

hxxps://sophosfirewallupdate.com/sp/ae.sh

Domains

sophosfirewallupdate.com

filedownloaderservers.com

ragnarokfromasgard.com

sophosenterprisecenter.com

sophoswarehouse.com

sophosproductupdate.com

sophostraining.org

Additional suspicious domains

filedownloaderserverx.com

filedownloaderserver.com

updatefileservercross.com

IPs

43.229.55.44

38.27.99.69

Filesystem paths

/tmp/x.sh

/var/newdb/global/.post_MI

/scripts/vpn/ipsec/generate_curl_ca_bundle.sh (modified)

/scripts/vpn/ipsec/.generate_curl_ca_bundle.sh (original?)

/tmp/I

/tmp/.a.PGSQL

/tmp/.n.sh

/tmp/.pg.sh

/tmp/.lp.sh

/tmp/b

/tmp/2own

/tmp/Info.xg

/tmp/%s_.xg.rel

/tmp/%s_.xg.salt

/tmp/ip (result of http://checkip.dyndns.org/ip_dyn)

/tmp/ip_dyn (result of https://ifconfig.me/ip)

A popular solution for organizations looking to enable employees to work remotely, virtual desktops have come a long way from the clunky VPN sessions you may be used to. Services such as Windows Virtual Desktop delivered on Azure provide users with access to all the applications and services that they require for their day-to-day work.

Deploying Windows Virtual Desktop

When run on a virtual machine hosted with a cloud provider such as Azure, a large part of the virtual desktop solution is managed by the cloud provider. While this lightens the admin load, you still need to secure the service against cyber threats, and ensure compliance with your organization’s web browsing and data loss prevention policies.

To help you get started, we’ve created two demo videos to help you get setup quickly. The first guides you through deploying Windows Virtual Desktop in an Azure Subnet from Azure marketplace and securing it with Sophos Intercept X. The second walks you through configuring Windows Virtual Desktop to route traffic to your XG Firewall.

VDI or RDS – which virtual desktop deployment is right for you?

During deployment of your virtual desktop environment you’ll be asked to decide between two options, each with cloud provider cost implications.

• RDS (Remote Desktop Session) – also known as ‘Pooled’ or ‘Multi Session’. RDS utilizes the Windows Server operating system (Windows 10 multi-session) to support multiple user sessions on the same virtual machine, sharing the same resources (pool). This is the most cost-effective solution as one virtual machine is used by multiple users.
• VDI (Virtual Desktop Infrastructure) – also known as ‘Personal’. VDI utilizes the Windows client operating system (Windows 10 Enterprise) to provides a single user with a dedicated workstation experience. This means the solution will also use a single virtual machine for each user which can become costly but may be required for resource hungry users.

Securing Virtual Desktops with Sophos Intercept X

Virtual desktops are susceptible to the same threats as physical laptops and desktops such as malware and exploits. You can protect them with Sophos Intercept X for Server or Sophos Intercept X for Endpoint: which license you need will depend on whether you choose RDS or VDI.

Protecting RDS environments

In RDS environments you need to secure the session host i.e. the virtual machine used to run virtual desktops sessions for your user. As a result the Windows Virtual Desktop is detected as Windows Server in Sophos Central, our security management platform, and is protected with Sophos Intercept X for Server. Simply apply one server license for each virtual machine (VM).

The table below shows the default number of VMs provisioned based on usage profile and number of users:

Protecting VDI environments

VDI is a little different, as here we’re securing an individual user. Therefore, to secure VDI environments you need Sophos Intercept X for Endpoint – one licence per user.

Applying Sophos protection to Virtual Desktop for Azure

In our setup video, we selected Pooled (or RDS) as this is the most common scenario. After the initial setup of Virtual Desktop for Azure, the next step is to download the Intercept X for Server agent to protect your multi-session environment.

The second half of the demo video covers downloading the Sophos Intercept X for Server installer from Sophos Central, running the installer on the session host, and configuring your policy to protect users.

Securing the network with XG Firewall

Once your host session is secure, you now need to secure traffic going out to the internet, or to other networks. Sophos XG Firewall will secure the inbound and outbound traffic to your virtual desktop environments and enable your teams to enforce compliance on a network level.

Watch the second demo video to see how to configure Windows Virtual Desktop to route traffic to your XG Firewall and get best practices for configuring the XG Firewall to protect the Windows Virtual Desktop environment.

Helpful Resources: