Everything we know about the SolarWinds Orion app vulnerability

The story so far

In December 2020 the widely used business software application Orion, a product of the popular IT management company SolarWinds, was reported to have been tainted with nation-state malware that affected versions 2019.4 through to 2020.2.1 of the application released between March and June 2020. This trojanized software update was swiftly identified by FireEye and Microsoft, who dubbed the vulnerability SUNBURST and Solorigate respectively. At the time of writing it is believed that more than 18,000 of SolarWinds’ 300,000 clients have been affected by the supply-chain attack.

In the weeks since, following the successful installation of the malicious software update, attackers have been quick to identify high-value targets among the compromised SolarWinds clients and have wasted little time in elevating credentials and stealing signed certificates. Considering how labor intensive such activities are known to be, it is widely believed that significant advanced planning was carried out prior to the successful launch of the trojanized update.

Weeks later, it is now known that the affected victims spanned government, consulting, technology, telecommunications, and extractive entities across the globe. Microsoft has since deduced that the majority of victims identified reside in the United States, though there are still significant cases globally, including Canada, Mexico, Belgium, Spain, the UK, Israel, the UAE, and elsewhere.

While neither SolarWinds nor the campaign victims have yet linked the attack to a specific actor, US federal officials believe it to be of Russian origin, with The Washington Post, via unnamed sources, reporting the attack to have been carried out by actor group APT29, a.k.a. Cozy Bear, a known ally of Russia’s foreign intelligence service.

Exploiting the SolarWinds Orion vulnerability

Solarwinds Orion (with Web Console WPM 2019.4.1, and Orion Platform HF4 or NPM HF2 2019.4) allows remote attackers to execute arbitrary code via a defined event, which is triggered when a user downloads a compromised update, giving them access to the victim’s entire network infrastructure.

From there the malware communicates back to the attackers via legitimate domains that have previously been purchased by the attacker and have laid dormant until now, allowing them to evade defences that should identify suspicious traffic. Once live, SUNBURST can transfer and execute files, profile the system, reboot the machine, and disable system services. The backdoor masquerades network traffic as the Orion Improvement Program (OIP) protocol and stores the stolen information within legitimate plugin configuration files.

Blueliv has identified two CVEs attached to this campaign: CVE-2020-14005 and CVE-2020-13169. At the time of writing little is known about CVE-2020-14005 other than the fact that it has already been modified since initial analysis by the National Vulnerability Database (NVD) and is currently undergoing reanalysis. Blueliv has already gathered significant insights into CVE-2020-13169 however, noting several severe attack patterns, particularly via variations of Cross-Site Scripting (XSS) associated with the vulnerability, including:

• AJAX Fingerprinting: This attack utilizes the frequent client-server round trips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. In many XSS attacks the attacker must get a “hole in one” and successfully exploit the vulnerability on the victim side the first time, once the client is redirected the attacker has many chances to engage in follow on probes, but there is only one first chance. In a widely used web application this is not a major problem because 1 in a 1,000 is good enough in a widely used application.
• Cross-Site Scripting (XSS): In this instance an adversary embeds malicious scripts in content that will be served to web browsers. The goal of the attack is for the target software, the client-side browser, to execute the script with the users’ privilege level. An attack of this type exploits a program’s vulnerabilities that are brought on by allowing remote hosts to execute code and scripts. Web browsers, for example, have some simple security controls in place, but if a remote attacker is allowed to execute scripts (through injecting them into user-generated content like bulletin boards) then these controls may be bypassed. These attacks are particularly difficult for an end user to detect.
• DOM-Based XSS: This type of attack is a variation form of Cross-Site Scripting (XSS), above. Here, content served by a vulnerable web application includes script code used to manipulate the Document Object Model (DOM). This script code either does not properly validate input or does not perform proper output encoding, thus creating an opportunity for an adversary to inject a malicious script and launch a XSS attack. A key distinction between other XSS attacks and DOM-based attacks is that in other XSS attacks, the malicious script runs when the vulnerable web page is initially loaded, while a DOM-based attack executes sometime after the page loads. Another distinction of DOM-based attacks is that in some cases, the malicious script is never sent to the vulnerable web server at all. An attack like this is guaranteed to bypass any server-side filtering attempts to protect users.
• Reflected XSS: This is another form of Cross-Site Scripting (XSS). The process starts with an adversary delivering a malicious script to a victim and convincing the victim to send the script to the vulnerable web application. The most common method of this is through the use of a phishing email in which the adversary embeds the malicious script with a URL that the victim then clicks on. In processing the subsequent request, the vulnerable web application incorrectly considers the malicious script as valid input and uses it to create a response that is then sent back to the victim. To launch a successful Reflected XSS attack, an adversary looks for places where user-input is used directly in the generation of a response. This often involves elements that are not expected to host scripts such as image tags (), or the addition of event attributes such as onload and onmouseover. These elements are often not subject to the same input validation, output encoding, and other content filtering and checking routines.

• Stored XSS: Another offshoot of Cross-site Scripting (XSS), Stored XSS is initially presented by an adversary to the vulnerable web application. The malicious script is quickly, and incorrectly, considered as a valid input and is not properly encoded by the web application. A victim is then convinced to use the web application in a way that creates a response that includes the malicious script. This response is subsequently sent to the victim and the malicious script is executed by the victim’s browser. To launch a successful Stored XSS attack, an adversary looks for places where stored input data is used in the generation of a response. This often involves elements that are not expected to host scripts such as image tags (), or the addition of event attributes such as onload and onmouseover. These elements are often not subject to the same input validation, output encoding, and other content filtering and checking routines.

Blueliv’s Threat Context module helps defenders identify and monitor threat actors that may be seeking to weaponize CVEs of this nature. Threat Context monitors mentions of CVEs across a spectrum of sources, including security vendor blogs, code repositories, and cybercriminal forums, among others, to garner insights, such as the above, as well as proactive steps in understanding the prerequisites for the attack and how best to mitigate it.

Threat actors

APT29, also popularly known as Cozy Bear, is a Russian state-sponsored APT group and the prime suspect behind the trojanized Orion update. The group is no stranger to attacks of this magnitude, having been behind various international espionage operations, including hacks against the Democratic National Committee (DNC) in the run up to the 2016 US presidential election (alongside fellow Russian APT Fancy Bear, the group that leaked documents stolen from the DNC to WikiLeaks).

The group has been active since 2008, conducting espionage operations against the diplomatic, governmental, think tank, healthcare, and energy sectors. The group has also targeted Chechen extremist groups and Russian organized crime, further cementing its ties with the Russian government. According to researchers at CrowdStrike, APT29 “casts a wide net” when conducting their campaigns, unlike most nation-state APTs which focus on a specific, relatively small range of intelligence targets. The group is also remarkable for the efforts it will take to stay in a network even after detection; whereas many APTs will desert a campaign after being uncovered, researchers have observed APT29 often doubling down and searching for new ways to maintain access.

APT29 is attributed to both the Russian Foreign Intelligence Service (SVR) as well as the Russian Federal Security Service (FSB) by the Estonian CERT and other organizations. ESET has hypothesized that APT29 is made up of several “sub-groups,” which could account for the disparate aims and tooling of the group, as well as the difficulties in attribution.

Kaspersky also identified that the malware Kazuar, attributed to actor group Turla, shares some code similarities with SUNBURST, though this doesn’t necessarily imply Turla was involved in this campaign. Instead, Kaspersky hypothesizes that Sunburst developers may have drawn inspiration from Kazuar; both attackers may have obtained malware from the same provider, Kazuar developers could have moved to another team, or SUNBURST developers may have introduced similarities on purpose as a false flag.

Intel 471, meanwhile, stated that in 2017, prolific initial access dealer “Fxmsp” offered access to SolarWinds computers on the top-tier Russian language forum Exploit, though it’s not clear whether Intel 471 was implying that said access was used in the 2020 SolarWinds incident. Blueliv analysts did not independently verify this claim, but assess the source as usually reliable and therefore the information to be probable.

Threat Score

The NVD gave CVE-2020-13169 a base CVSS score of 9.6/10, whilst CVE-2020-14005 is measured at 8.8/10 in its latest assessment. Both of these scores are critical, though do not match Blueliv’s score of 6.3/10 (CVE-2020-14005) and 5/10 (CVE-2020-13169). This is because, when evaluating CVEs and their potential impact on an organization, several factors must be analyzed and observed ‘in the wild’. In this respect, Blueliv generates its own dynamic risk score for CVEs, which is subject to change in line with ongoing insights and developments surrounding the vulnerability.

Threat Context grants defenders the ability to identify mentions of a specific CVE in various code repositories which in turn assists them in pinpointing whether there may be a working PoC for a CVE. This ultimately helps defenders better understand what a successful exploitation might look like and ensure they are prepared.

Conclusion

Orion is just one of countless tools used by organizations the world over, any one of which could suffer a breach of the same capacity – particularly those with internet-facing systems and access to critical user data – and likely will in the future.

Moving forward, this means that the supply-chain must be considered as the latest component in an organization’s ever expanding security perimeter, alongside an emphasis on the vetting of third-party threats and vulnerabilities. Therefore, it is vital that organizations look to incident response platforms equipped with the ability to run security automation, ideally from a one-panel dashboard, that can monitor, and be integrated with, third-party solutions.

Blueliv’s Threat Context module includes third-party assessment, granting users insights into hidden risks and vulnerabilities among their outside environments to ensure SOC teams are always aware of any third-party risks. Threat Context can also assist defenders in tackling similar vulnerabilities to the trojanized Orion update by providing a risk score as well as information into available exploits and PoCs; malware, threat actors, and campaigns leveraging a CVE; and mentions across different sources such as “Hacktivism,” “Dark Web,” or “Security News.” To provide further insights and assistance, Blueliv provides a dynamic scoring system for CVEs that offers real-time updates on the exploitation and weaponization of a vulnerability.

The post Everything we know about the SolarWinds Orion app vulnerability appeared first on Blueliv.

*** This is a Security Bloggers Network syndicated blog from Blueliv authored by The Blueliv Team. Read the original post at: https://www.blueliv.com/cyber-security-and-cyber-threat-intelligence-blog-blueliv/everything-we-know-about-the-solarwinds-orion-app-vulnerability/