[German]The Exchange mass hacking by the Hafnium group as well as the issue around ProxyLogon vulnerabilities won't let us off the hook. To wrap up the week, here's a quick roundup: there are revisions from Microsoft on the topic (the last set of updates for unsupported CUs on Exchange Server has been released), there are publicly available proof of concept (PoC) samples, and the "issues list" for the Microsoft Support Emergency Response Tool (MSERT) is getting longer.
Advertising
Revision of Exchange security advisories
I received a notification regarding revisions to the Microsoft Exchange security advisories, that I am simply post here for your perusal.
********************************************************
Title: Microsoft Security Update Releases
Issued: March 11, 2021
********************************************************
Summary
=======
The following CVE and advisory have undergone a revision increments:
Critical CVEs
============================
Advertising
* CVE-2021-26855
* CVE-2021-27065
* CVE-2021-26857
Important CVEs
============================
Publication information
===========================
– Microsoft Exchange Server Remote Code Execution Vulnerability
– See preceding list for links
– Version 4.0
– Reason for Revision: Microsoft is releasing the final set of security updates for
CVE-2021-27065, CVE-2021-26855, CVE-2021-26857, and CVE-2021-26858 for several
Cumulative Updates that are out of support, including Exchange Server 2019, CU1
and CU2; and Exchange Server 2016 CU 8, CU 9, CU10, and CU11. These updates address
only those CVEs. Customers who want to be protected from these vulnerabilities can
apply these updates if they are not Exchange Server on a supported cumulative update.
Microsoft strongly recommends that customers update to the latest supported cumulative
updates.
– Originally posted: March 2, 2021
– Updated: March 11, 2021
So, Microsoft has released the final set of security updates for vulnerabilities CVE-2021-27065, CVE-2021-26855, CVE-2021-26857 and CVE-2021-26858 for several cumulative updates (CU) for Exchange Server that are no longer supported. This includes Exchange Server 2019, CU1 and CU2, and Exchange Server 2016 CU 8, CU 9, CU10 and CU11. I got also the feedback from my German blog readers, that these updates has arrived on WSUS.
Somewhat off-topic, Microsoft has removed information on some SSUs under ADV990001, as they have since been integrated into the cumulative updates for Windows 10 2004/20H2 as well as their server counterparts.
PoC available, wave of attacks expected
I had already pointed out in the blog post Exchange hack: new victims, new patches, new attacks that at least ten threat actors are attacking unpatched Exchange systems that are accessible via the Internet (port 443). This is likely to increase now, as I came across the following tweet.
A security researcher has published on Microsoft's GitHub platform his proof of concept (PoC) for the Exchange vulnerabilities (this is not a working exploit, mind you). Vice rehashed it here: Microsoft immediately deleted the code from the GitHub repository. Security researcher Nguyen Jang claims to have derived the whole thing from a working exploit. The shockwaves left by the ProxyLogon vulnerabilities in the Microsoft Exchange ecosystem will increase in the coming weeks. My German editor Jürgen Schmidt just hinted at it at heise that we are seeing something like a cyber war and that now a cybercrime wave with blackmail is comming. This also fits with the fresh tweet from Microsoft, where their security intelligence group is sounding the alarm.
Microsoft has just found the first ransomware family to exploit vulnerabilities on unpatched Exchange Servers. The ransomware family in question goes by the name Win32/DoejoCrypt.A – or "DearCry" for short and fitting – and is blocked by Microsoft's antivirus tools. When I heard the name DearCry, two things went through my mind: "Yes, there will be many tears, my dear" – and "it's stupid that they block it, let the attackers strike, then people will at least realize that they are sitting on a box with unpatched vulnerabilities". With the latter thought, the problem of the BSI writing to people and no one reacting would be elegantly solved. But since these are completely unchristian thoughts, I'll just keep them to myself and watch with interest which blog topics will jump out at me in the near future.
I would like to patch Exchange
Within my German (sorry no English version available) blog post Anatomie des ProxyLogon Hafinum-Exchange Server Hacks I mentioned that I think that Exchange is difficult to patch. This is my impression from observations and feedback I got. Microsoft Germany has also contacted me after I published some articles and pointed out some further details.
As part of the security warning above, the previous tweet came to my attention. The message: Microsoft Defender detects and protects against the new ransomware family. At the same time, Microsoft links to the Techcommunity article March 2021 Exchange Server Security Updates for older Cumulative Updates of Exchange Server, in which the Exchange team provides guidance on patching systems that are still on older Cumulative Update levels. And immediately browsed the comments, and yess, blog reader Karl has left this comment, pointing out the .NET Framework issue – that we are discussing since years. And German blog reader Jens H. hit me up with two mails, which I've translated:
Something related to the current Exchange activity and as you are gathering clues about sources of errors related to the updates: We unfortunately had a compromised customer server, Exchange 2016 CU18. I had given it the appropriate security update on the evening of March 3, but unfortunately the server had already been attacked. But that is probably irrelevant for the following:
I then, after we had examined the server and cleaned it to the best of our knowledge and belief (checked the updated hints again and again/also in the following days and closed the https port), wanted to update the Exchange to CU19 yesterday evening. That had also worked so far, disabled Unified Messaging again and restarted. System was running after reboot, virus scanner (Defender) still deactivated, because I wanted to apply the appropriate security patch for CU19.
Unfortunately, this went wrong: The update started, the services were deactivated extensively and in the middle of it the error message that the update had aborted ("prematurely ended", with error 1603). Also a new attempt brought no success, the Exchange was "dead". Since it was already 2:00 a.m., I decided to shut down the (virtual) server, make an image backup of the hard disks and continue to run the system until I have clarity whether the new patch is necessary at all or whether it is no longer needed (which I actually don't believe, since the CU19 is a newly installed Exchange).
What else surprised me: The Exchange is supposed to be a CU19 now according to the build number, but it definitely isn't – presumably it says so somewhere in AD. Here I lack the knowledge .
And it continued in a follow-up email:
I have now brought the (virtual) server yesterday evening to CU19 – but not yet dared to patch the system again with the SU. Possibly I will do that on the weekend.
Unfortunately, there are no instructions for my action from the Exchange team (at least last night). And I don't trust the thing "once patched is always valid" .
Jens still linked to this Techcommunity article, but it probably didn't fit for him, as the last sentence above suggests. Jens said he'd get back to me when he had a result. Here is the message:
just re-reading the text on the linked page:
- Installing the SUs mentioned here and then installing a later CU will make the server vulnerable to exploits again until the CU you install contains the March 2021 security fixes (Exchange 2016 CU 20 and Exchange 2019 CU 9 – and newer – will include March 2021 security updates).
Unfortunately, this means that I would actually have to install the SU again (the one for CU19) on the 2016 server that has since been patched to CU19. I did that last time and burned my fingers – Exchange stopped running, all services and more were disabled.
However, I guess there is a script that is supposed to re-enable them. Let's see – maybe I'll give it another try today.
MSERT tool: Placebo with long issues list?
Let's move on to the last snippet of information. Responsible administrators have the thankless task of quickly finding out where Exchange servers are located, whether they can be reached via the Internet, and whether they might be compromised. A few minutes ago I received an e-mail from Roman Romanchenko, who pointed out to me that his research has now revealed not 170,000 but almost 300,000 Exchange servers accessible via the Internet.
I can filter which ports are open on the search engine in question (at 443 I get 240,000 instances), but without an account I get no way to identify German systems. So administrators have to do it themselves. In the blog posts linked at the end of the article, I touched on the question of how to detect infections and how to proceed. Because Microsoft's PowerShell script doesn't work with Microsoft Exchange 2010 (reported from some blog readers), I mentioned the MSERT tool (Microsoft MSERT helps to scan Exchange Servers).
At first I thought "Wow, just run it and see if there is an infection". Then came the objection: If MSERT eliminates the malicious functions, it will be rather difficult with the forensics to work up the infection. Then came the hint from German security researcher Stefan Kanthak about the DLL hijacking vulnerabilities of the MSERT tool. Of course, this is nasty: In case, a malware lurks with restricted rights, the admin launches the MSERT tool with administrative rights, and the malware can highjack DLLs, which then executes them with administrative or system rights.
But there is more. Within this comment Greman blog reader Bastian points out that the tool seems to be more or less a placebo, driving admins' blood pressure to dizzying heights and promoting heart attacks. His quote:
MSERT shows "Files Infected: 8" while it is running. But at the end it says "No infection found." Confidence inspiring.
And Sebastian added:
Hello all, I had exactly the same problem. Infections during the scan and then the following result:
->msert.log
Results Summary:
——
No infection found.
Successfully Submitted MAPS Report
Successfully Submitted Heartbeat Report
These are not isolated cases, in the Technet there is a long thread, since 2014 with the title MSRT reports an infected file during scan, then reports no infections on completion, where this problem has been discussed for years and is confirmed by numerous users. So a medicine without effect or with side effect? So you have been warned.
Similar articles
Exchange server 0-day exploits are actively exploited
Important notes from Microsoft regarding the Exchange server security update (March 2021)
Exchange isues with ECP/OWA search after installing security update (March 2021)
Exchange Hack News – Test tools from Microsoft and others
Microsoft MSERT helps to scan Exchange Servers
Cyber attack on Exchange server of the European Banking Authority
Exchange hack: new patches and new findings
Exchange Server: Remote Code Execution Vulnerability CVE-2020-16875
Exchange hack: new victims, new patches, new attacks
