Microsoft Exchange is one of the most popular email applications worldwide. An estimated 43% of organizations that use Microsoft Exchange for email use Microsoft Exchange Server. Every one of these organizations who allow their users to access their Exchange application directly from the open internet has been at risk for some time. Attacks were discovered as early as January 6th, and several sources estimate that by March 9th 250,000 servers worldwide had fallen victim. 

Microsoft Exchange Server ProxyLogon 

ProxyLogon leads to a remote code execution (RCE) vulnerability, which grants a bad actor complete access with high privileges to the Microsoft Exchange server where they can access files, mailboxes, and potentially stored user credentials. A highly motivated attacker then uses this access to move laterally in the internal network of the organization; compromising the internal network and accessing other applications and data. 

These attacks are exploiting vulnerabilities that existed in all versions of the product from 2013 through 2019.  Microsoft has issued patch updates for these application vulnerabilities and IT security teams are scrambling to update their Exchange servers to mitigate the impact. Unfortunately, it’s too late for those 250,000 servers that have already been compromised in high probability. 

The Vulnerabilities

Hafnium targeted Microsoft Exchange servers by exploiting a chain of 4 different vulnerabilities ( CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065 ). Here’s a summary on how it works and a little good news for organizations using zero trust to isolate and broker access to their Microsoft Exchange Server application.

These Microsoft Exchange Server vulnerabilities will allow an attacker to implant  a SYSTEM privileged webshell on the remote server.  An attacker with remote access to this webshell can execute high privileged commands that will enable them to gain control of the server. All an attacker has to do to initiate an attack is to find an Exchange Login page on the internet and send a few requests. The attacker doesn’t need Login credentials and they can skip identity authentication altogether. This is a big problem for any organization who publishes their Exchange Login page to the internet and relies 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 an Exchange server to target. A simple 3rd party service like Shodan gives them all the information they need to discover the IP addresses of  internet facing Microsoft Exchange Servers and a passive DNS service helps them target victims by identifying the domain names associated with these IPs.   

Step 2. 

Using a script that can be found on github, the bad actor exploits a chain of vulnerabilities. The first, CVE-2021-26855, an SSRF vulnerability is used to bypass authentication. Then, exploitation of another vulnerability, CVE-2021-26857, elevates  their privileges to a SYSTEM user. Eventually, they’ll use their new privileged access to exploit two arbitrary file-write vulnerabilities, CVE-2021-26858 & 27065, to implant a highly privileged webshell to ensure persistence. Sounds complicated? It’s not. All of this can be achieved by a press of a button, thanks to publicly available exploitation scripts.

Step 3. 

The bad actor can now use this webshell to execute high privileged commands on the compromised server. Using lateral movement techniques, they can also try to spread in the company network. 

Break the Kill Chain

None of these organizations would have been compromised if their Microsoft Exchange Server application was not published directly to the internet. If direct access from any user on the public internet had never been enabled, then no bad actor ever finds that vulnerable Microsoft Exchange Server application 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 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. 

It’s far safer to just keep your applications isolated from both the internet and your internal network. Hey, I understand. It’s important to the business to make resources like Microsoft Exchange easily accessible for authorized users and these servers compromised by ProxyLogon are set up to require user authentication for access…unfortunately this level of security isn’t enough if the platform has a vulnerability that can be exploited to bypass authentication.  

With a zero trust access approach that operates at the application-layer, you can enable remote access to applications and services without exposing these potentially vulnerable platforms to attacks like ProxyLogon. This is the good news for organizations using brokered, zero trust access for services like Microsoft Exchange Server. For organizations using the Axis Security Application Access Cloud with Application Isolation Technology, 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 how Armis uses the Axis Security Application Access Cloud with Application Isolation Technology here.

The post Microsoft Exchange Server ProxyLogon and the Hafnium Attacks – Protecting Vulnerable Apps with ZTNA appeared first on Axis Security.

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. 

The post Protecting Vulnerable Apps – SolarWinds SUPERNOVA appeared first on Axis Security.