SolarWinds Vulnerability Advisory
Multiple Vulnerabilities in SolarWinds N-Central Could Allow for Remote Code Execution
This response guide has been developed by Blackpanda following the SolarWinds attack 11 December 2020.
The guide largely follows advice published in CISA Emergency Directive 21-01 (https://cyber.dhs.gov/ed/21-01/) and Multi-State Information Sharing and Analysis Center (MS-ISAC) Advisory 2020-170 (issued December 18, 2020), and subsequent supplemental updates.
Background
SolarWinds Orion products (affected versions below) are currently being exploited by malicious actors. This tactic permits an attacker to gain access to network traffic management systems. Disconnecting affected devices, as described in Required Action 2, is the only known mitigation measure currently available.
CISA has determined that this exploitation of SolarWinds products poses an unacceptable risk and requires emergency action. This determination is based on:
- Current exploitation of affected products and their widespread use to monitor traffic on computer network systems;
- High potential for a compromise of information systems;
- Grave impact of a successful compromise.
CISA understands that the vendor is working to provide updated software patches. However, companies must wait until CISA provides further guidance before using any forthcoming patches to reinstall the SolarWinds Orion software in their enterprise. Please refer to the MITRE ATT&CK framework for possible tactics the threat actors are using to maintain persistence in the environment.
Systems Affected
SolarWinds N-Central Platform version 12.3 HF4. The following versions are considered affected versions:
- Orion Platform 2019.4 HF5, version 2019.4.5200.9083
- Orion Platform 2020.2 RC1, version 2020.2.100.12219
- Orion Platform 2020.2 RC2, version 2020.2.5200.12394
- Orion Platform 2020.2, 2020.2 HF1, version 2020.2.5300.12432
Technical Summary
Multiple vulnerabilities have been discovered in SolarWinds N-Central, two of which could allow for remote code execution when used in conjunction. Details of these vulnerabilities are as follows:
- An OS command-injection vulnerability due to traversal issue (CVE-2020-25617), can be used together with CVE-2020-25622 as a one-click root RCE attack chain
- A local privilege escalation vulnerability (CVE-2020-25618)
- An unauthorized access vulnerability due to built-in support and admin accounts with default credentials (CVE-2020-25620)
- An unauthorized access vulnerability due to an authentication mechanism in the local Postgres database (CVE-2020-25621)
- A CSRF vulnerability in N-Central Admin Console (CVE-2020-25622), can be used in conjunction with CVE-2020-25617 for a one-click root RCE attack chain
Successful exploitation of the most severe of these vulnerabilities could allow for remote code execution. Depending on the privileges associated with the user, an attacker could install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.
Recommendations Overview
We recommend the following actions be taken:
- Apply appropriate updates provided by SolarWinds to vulnerable systems, immediately after appropriate testing
- Run all software as a non-privileged user (one without administrative privileges) to diminish the effects of a successful attack
- Remind users not to visit untrusted websites or follow links provided by unknown or untrusted sources
- Inform and educate users regarding the threats posed by hypertext links contained in emails or attachments especially from an untrusted source
- Apply the Principle of Least Privilege to all systems and services
Detailed Remediation
This emergency directive requires the following actions:
1. Companies that have the expertise to take the following actions immediately must do so before proceeding to Action 2. Companies without this capability shall proceed to Action 2.
a. Forensically image system memory and/or host operating systems hosting all instances of SolarWinds Orion versions 2019.4 through 2020.2.1 HF1]. Analyze for new user or service accounts, privileged or otherwise.
b. Analyze stored network traffic for indications of compromise, including new external DNS domains to which a small number of agency hosts (e.g., SolarWinds systems) have had connections.
2. Affected Companies shall immediately disconnect or power down SolarWinds Orion products, versions 2019.4 through 2020.2.1 HF1, from their network. These versions are considered unsafe and should not be used going forward. All other versions from 2020.2 HF2 onwards can be used, if the instance did not previously use an affected version, but still will need to be updated immediately.
Additionally:
a. Block all traffic to and from hosts, external to the enterprise, where any version of SolarWinds Orion software has been installed.
b. Identify and remove all threat actor-controlled accounts and identified
persistence mechanisms.
3. By 12pm Eastern Standard Time on Monday December 14, 2020 companies shall report as an incident to CISA (at https://us-cert.cisa.gov/report) the existence of any of the following:
a. [SolarWinds.Orion.Core.BusinessLayer.dll] with a file hash of [b91ce2fa41029f6955bff20079468448]
b. [C:\WINDOWS\SysWOW64\netsetupsvc.dll]
c. Other indicators related to this issue to be shared by CISA
4. After (and only after) all threat actor-controlled accounts and identified persistence mechanisms have been removed:
a. Treat all hosts monitored by the SolarWinds Orion monitoring software as compromised by threat actors and assume that further persistence mechanisms have been deployed.
b. Rebuild hosts monitored by the SolarWinds Orion monitoring software using trusted sources.
c. Reset all credentials used by or stored in SolarWinds software. Such credentials should be considered compromised.
d. Take actions to remediate kerberoasting, including, as necessary or appropriate, engaging with a 3rd party with experience eradicating APTs from enterprise networks. For Windows environments, refer to the following:
•See Microsoft’s documentation on kerberoasting:
https://techcommunity.microsoft.com/t5/microsoft-security-and/detecting-ldap-based-kerberoasting-with-azure-atp/ba-p/462448
•Require use of long and complex passwords (greater than 25 characters) for service principal accounts and implement a good rotation policy for these passwords.
•Replace the user account by Group Managed Service Account (gMSA). See https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview and Implement Group Managed Service Accounts: https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview.
•Set account options for service accounts to support AES256_CTS_HMAC_SHA1_96 and not support DES, RC4, or AES128 bit encryption
•Define the Security Policy setting, for Network Security: Configure encryption types allowed for Kerberos. Set the allowable encryption types to AES256_HMAC_SHA1 and Future encryption types. https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos
•See Microsoft’s documentation on how to reset the Kerberos Ticket Granting Ticket password, twice: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-forest-recovery-resetting-the-krbtgt-password
5. By 12pm Eastern Standard Time on Monday, December 14, 2020, submit a report to CISA using the provided template. Department-level Chief Information Officers (CIOs) or equivalents must submit completion reports attesting to CISA that the affected devices were either disconnected or powered down.
Companies that were using affected versions at any time prior to the issuance of ED 21-01 must:
- Keep these products disconnected as required by ED 21-01 pending further CISA guidance and not rebuild or reimage the affected platforms and host operating systems (OS), including (re)joining the host OS to the enterprise domain, until such time as CISA directs otherwise.
- Label and isolate all backups of the affected versions from their systems to prevent accidental re-introduction of malicious code to the production environment.
- Conduct forensic analysis or search, as appropriate based on capability, for indicators of compromise (IOCs) or other evidence of threat actor activity.
a. Companies running affected versions that have no capability to conduct forensic analysis (system memory, host storage, network) shall, at minimum, search for IOCs or other evidence of threat actor activity published in ED 21-01, Activity Alert AA20-352A, and future associated guidance.
b. Companies that find matches to these IOCs or evidence of threat actor activity through forensics analysis must report this as an incident to CISA through https://us-cert.cisa.gov/report. If a reporting agency already submitted incident information to CISA, please send updates to CISA as you discover new evidence.
ac. Companies running affected versions that have no capability to conduct forensic analysis and no capability to search for IOCs shall assume breach, report the incident to CISA through https://us-cert.cisa.gov/report, and contact central@cisa.dhs.gov to coordinate finding a qualified service provider capable of conducting forensics.
Federal Information Systems Hosted in Third-Party Environments (such as Cloud)
CISA is working closely with FedRAMP to coordinate the response to ED 21-01 with FedRAMP Authorized cloud service providers (CSPs). FedRAMP Authorized CSPs have been informed to coordinate with their agency customers.
1. If FedRAMP Authorized CSPs are affected, their agency customers must report incidents to CISA in accordance with ED 21-01. Companies hosting information in any third-party environment (FedRAMP Authorized or otherwise) must identify and contact their third-party service providers directly for status pertaining to, and to ensure compliance with, ED 21-01.
2. Companies are also instructed to supplement their reporting under ED 21-01 to incorporate relevant information from third-party service providers (to the extent that Companies have not already included this information), including to report any incident through CISA. In your incident reporting, please identify what data was exposed to the third-party service provider.
Conditions for Reconnecting Unaffected Versions
At this time, CISA is still assessing whether it is appropriate to relax ED 21-01’s requirement that Companies not install patches for their SolarWinds Orion software. Some older versions of SolarWinds Orion have been identified as not affected by the malicious backdoor. However, operating such older versions carries significant risk, because (1) like other types of older software, older versions of SolarWinds Orion contain known vulnerabilities; (2) the adversary that inserted the SolarWinds Orion backdoor is likely to be intimately familiar with SolarWinds Orion code, including known or unknown vulnerabilities that may exist separate and apart from the backdoor; and (3) this adversary has demonstrated the capability and willingness to exploit SolarWinds Orion to compromise U.S. government Companies, critical infrastructure entities, and private organizations.
Companies are permitted to power back up and reintroduce into an agency production environment SolarWinds Orion instances that were disconnected pursuant to ED 21-01 only if each of the following conditions are met:
1. The instance currently uses an unaffected version of the SolarWinds Orion, which are listed below.
a. Orion Platform 2019.4 2019.4.5200.8890
b. Orion Platform 2019.4 HF1 2019.4.5200.8950
c. Orion Platform 2019.4 HF2 2019.4.5200.8996
d. Orion Platform 2019.4 HF3 2019.4.5200.9001
e. Orion Platform 2019.4 HF4 2019.4.5200.9045
2. The instance did not previously use an affected version (i.e., the instance was never rolled back from an affected version) and the instance is not restored from an affected version.
3. The agency first (1) hunts for threat actors in their environment using all IOCs and indicators of threat actor activity published about this threat activity in ED 21-01, Activity Alert AA20-352A, and any additional related guidance related to this activity published by CISA or provided by the information security community prior to the instance being reintroduced to the environment, and (2) finds no evidence of such threat actor activity.
4. The agency conducts a risk assessment to assess the impact of reintroducing the Orion Platform into agency production environments and accepts residual risk associated with running this unpatched software containing known vulnerabilities until such time as CISA permits companies to patch these products.
5. Block all incoming and outgoing (any:any) Internet traffic to and from hosts running SolarWinds Orion products (as required by ED 21-01).
6. Follow the SolarWinds hardening guidelines provided by the vendor, which can be found at: https://documentation.solarwinds.com/en/Success_Center/orionplatform/content/core-secure-configuration.htm
EXCEPT:
a. Companies shall not configure the SolarWinds software to implement SAML-based authentication that relies on Microsoft’s Active Directory Federated Services. This configuration is currently being exploited by the threat actor associated with this activity.
b. Companies shall not follow the hardening guideline’s requirement to ensure their SolarWinds instance is patched to the latest version, pending further direction from CISA to do so.
7. Ensure that the SolarWinds logs are being sent to the agency SOC for action.
Other Versions
Companies continuing to run instances of SolarWinds Orion with other versions must comply with steps 5-7 listed for unaffected versions.
Companies may apply updates to host operating system running SolarWinds Orion products in accordance with their respective vulnerability and patch management policies and programs.
All other provisions specified in ED 21-01 remain in effect.
References
SolarWinds:
https://documentation.solarwindsmsp.com/N-central/Rel_2020-1-2_HF2/N-central_2020-1-2_HF2_ReleaseNotes_en.pdf
Insinuator:
https://insinuator.net/2020/12/security-advisories-for-solarwinds-n-central/
CVE:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25617
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25618
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25620
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25621
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25622
