Back To Blog

Protecting Vulnerable Apps – SolarWinds SUPERNOVA

SolarWinds customers are having a rough season. Research on the highly sophisticated SUNBURST compromise also uncovered SUPERNOVA, a separate but also ongoing threat campaign.  Now IT security teams are scrambling to mitigate the impact of both issues.

SUPERNOVA targets SolarWinds customers directly by exploiting a SolarWinds Orion code vulnerability. Here’s a summary on how SUPERNOVA works and a little good news for organizations using zero trust to broker access to their SolarWinds Orion application.

The Vulnerability 

The SolarWinds Orion application has a backdoor vulnerability that will allow a user to skip authorization when sending API commands to an Orion server.  All an attacker has to do to exploit this vulnerability and gain control of the server is find an Orion Login page and send a few requests.  They don’t need Login credentials; they can skip identity authentication altogether. This is a big problem for any organization that publishes the Orion Login page to the internet, relying solely on user authentication to prevent access by bad actors.

The Attack Process

Here’s how the attack goes down. 

Step 1. 

A bad actor discovers a SolarWinds Orion server to target. A simple service like Shodan gives them all the information they need to discover the IP addresses of  internet facing servers running the vulnerable Orion application code and a passive DNS service helps them target victims by identifying the domain names associated with these IPs.   

Step 2. 

With 2 simple requests to the SolarWinds Orion URL: HTTP/S:// <insert IP address here> / the bad actor can bypass the API authorization process, which can allow them to execute unauthenticated API commands on the server. 

Step 3. 

The bad actor can use API commands to read sensitive information or to modify files. For example: they can modify a normally benign DLL file on the server with malicious web shell code that they can use to maintain perpetual access to that server.  Once that web shell is installed that bad actor can control that server and potentially move laterally to spread inside the network perimeter of the organization.

Break the Kill Chain

If the application is never published to the internet, the bad actor never finds that SolarWinds Orion server to start the attack in the first place and the kill chain falls apart at Step 1.  

Okay, so what if you keep that application only accessible via your internal network and you use a VPN? This is better than exposure to the wild public internet but still leaves you with an exposed and vulnerable application if a bad actor gets access to your internal network using another method, for example if they are able to get onto your VPN. 

Better to keep your applications isolated from both the internet and your internal network.

Hey, we get it. It’s important to the business to make resources like SolarWinds easily accessible for authorized users and these instances compromised by SUPERNOVA are set up to require user authentication for access…unfortunately this isn’t enough if the platform has a vulnerability that can be exploited.  

With a zero trust application access approach, you can enable remote access to applications and services without exposing these potentially vulnerable platforms to attacks like SUPERNOVA. This is the good news for organizations using brokered, zero trust application access for services like SolarWinds Orion. For organizations using Axis, the vulnerable application is accessible for authorized remote users but is never published to the public internet or even directly accessible from the internal network and user requests to the server are always brokered at the application layer.

Read an analysis of SUPERNOVA and CVE-2020-10148 in this paper from our threat researcher, Shay Shwartz

Start Simplifying Your App Access