Neues zur ProxyLogon-Hafnium-Exchange-Problematik (12.3.2021)

[English]Das Thema Exchange-Massenhack durch die Hafnium-Gruppe sowie die Problematik um die ProxyLogon-Schwachstellen lässt uns nicht vom Haken. Zum Wochenabschluss noch ein schneller Rundumschlag: Es gibt von Microsoft Revisionen zum Thema (der letzte Satz an Updates für nicht mehr unterstützte CUs auf Exchange Server ist freigegeben), es gibt öffentlich verfügbare Proof of Concept (PoC) Beispiele, und der „Beipackzettel“ für das Microsoft Support Emergency Response Tool (MSERT) wird immer länger.

Revision der Exchange Sicherheitshinweise

Die Nacht ist bei mir eine Benachrichtigung zu Revisionen der Sicherheitshinweise zu Microsoft Exchange eingetroffen. Ich stelle die Information einfach zur Kenntnisnahme hier ein.

********************************************************
Title: Microsoft Security Update Releases
Issued: March 11, 2021
********************************************************

Summary
=======

The following CVE and advisory have undergone a revision increments:

Critical CVEs
============================

* CVE-2021-26855
* CVE-2021-27065
* CVE-2021-26857

Important CVEs
============================

*  CVE-2021-26858

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

Microsoft hat also den letzten Satz von Sicherheitsupdates für die Schwachstellen CVE-2021-27065, CVE-2021-26855, CVE-2021-26857 und CVE-2021-26858 für mehrere kumulative Updates (CU) für Exchange Server, die nicht mehr unterstützt werden, veröffentlicht. Das umfasst Exchange Server 2019, CU1 und CU2 sowie Exchange Server 2016 CU 8, CU 9, CU10 und CU11.

Etwas off-topic: Microsoft hat unter ADV990001 die Informationen zu einigen SSUs entfernt, da diese inzwischen in den kumulativen Updates für Windows 10 2004/20H2 sowie die Server-Pendants integriert wurden.

PoC verfügbar, Angriffswelle zu erwarten

Ich hatte ja bereits im Blog-Beitrag Exchange-Hack: Neue Opfer, neue Patches, neue Angriffe darauf hingewiesen, dass mindestens zehn Bedrohungsakteure ungepatchte Exchange-Systeme, die per Internet (Port 443) erreichbar sind, angreifen. Das dürfte jetzt noch zunehmen, denn die Nacht ist mir auf Twitter der nachfolgende Tweet untergekommen.

Ein Sicherheitsforscher hat auf der Microsoft Plattform GitHub sein Proof of Concept (PoC) für die Exchange-Schwachstellen veröffentlicht (das ist wohlgemerkt kein funktionierender Exploit). Vice hat es hier aufbereitet: Microsoft hat sofort den Code aus dem GitHub-Repository gelöscht. Sicherheitsforscher Nguyen Jang gibt an, das Ganze von einem funktionierenden Exploit abgeleitet zu haben. Die Schockwellen, die die ProxyLogon-Schwachstellen im Microsoft Exchange-Eco-System hinterlassen, werden in den kommenden Wochen zunehmen. Mein Redakteur Jürgen Schmidt hat es gerade bei heise im Artikel Exchange-Lücken: Jetzt kommt die Cybercrime-Welle mit Erpressung angedeutet. Dazu passt auch der frische Tweet aus der Microsoft-Schmiede, wo deren Security Intelligence-Gruppe Alarm schlägt.

Microsoft hat gerade die erste Ransomware-Familie gefunden, die die Schwachstellen auf ungepatchten Exchange Servern ausnutzt. Die betreffende Ransomware-Familie läuft unter dem namen Win32/DoejoCrypt.A – oder kurz und passend „DearCry“ und wird von Microsofts Antivirus-Tools blockiert. Beim Namen DearCry gingen mir zwei Sachen durch den Kopf: „Ja, es werden noch viele Tränen fließen, my dear“ – und „schon doof, dass die das Blockieren, sollen die Angreifer doch zuschlagen, dann bekommen die Leute wenigstens mit, dass sich auf einer Kiste mit ungepatchten Schwachstellen sitzen“. Mit letzterem Gedanken wäre das Problem, dass das BSI die Leute anschreibt und niemand reagiert, elegant erledigt. Da es aber gänzlich unchristliche Gedanken sind, behalte ich die einfach mal für mich und beobachte interessiert, welche Blog-Themen mich demnächst so anspringen.

Ergänzung: Arstechnica listet in diesem Artikel inzwischen sechs Gruppen auf, die die ungepatchten Schwachstellen auf Exchange Servern angreifen. Da stehen sich die Hacker gegenseitig auf den Füßen oder sperren sich gegenseitig aus.

Ich täte ja Exchange gerne patchen

Im Blog-Beitrag Anatomie des ProxyLogon Hafinum-Exchange Server Hacks hatte ich ja angedeutet, dass ich die gesamte Exchange-Geschichte für schwierig im Hinblick auf das Patchen halte (ist mein Eindruck aus Beobachtungen). Speziell mein heise-Artikel zum Thema hat ein sehr breites Spektrum an Leserreaktionen (von sinnbildlich „Hornochse“ und „Rant eines Wutbürgers“ bis zu „kann ich voll unterschreiben“) provoziert. Ich sitze hier auf meinem Bürostuhl und lese die meisten Kommentare mit diebischer Freude.

Auch Microsoft hat mich kontaktiert und auf einige Sachverhalte hingewiesen (sinnvolles Feedback), die ich in obigem Blog-Beitrag ergänzt habe. Bei einigen Rückmeldungen erkennst Du „wow, da steckt ein Praktiker dahinter“, und gehst sofort dem Thema nach. Einiges muss ich noch sortieren, manches habe ich im erwähnten Nachtrag im Blog-Beitrag Anatomie des ProxyLogon Hafinum-Exchange Server Hacks schon angedeutet. So ganz daneben lag ich mit meinem Bauchgefühl zum Exchange-Patchen wohl nicht.

Im Rahmen der obigen Security-Warnung ist mir der vorhergehende Tweet unter die Augen gekommen.  Die Botschaft: Der Microsoft Defender erkennt und schützt vor der neuen Ransomware-Familie. Gleichzeitig verlinkt Microsoft auf den Techcommunity-Artikel March 2021 Exchange Server Security Updates for older Cumulative Updates of Exchange Server, in dem das Exchange-Team Hilfestellung zum Patchen von Systemen gibt, die noch auf älteren Cumulative Update-Ständen sind.  Interessent sind für euch Exchange-Administratoren die Leserkommentare, die teilweise auch hier im Blog aufschlagen.

Ich habe natürlich sofort gescrollt, ob ich was zur .NET Framework-Problematik finde – und Yess, Blog-Leser Karl ist mit diesem Kommentar aufgeschlagen. Und Blog-Leser Jens H. ist mit zwei Mails bei mir aufgeschlagen, die ich einfach mal einstelle:

Etwas in Zusammenhang mit den aktuellen Exchange-Aktivitäten und da Sie Hinweise auf Fehlerquellen in Bezug auf die Updates sammeln: Wir hatten leider einen kompromittierten Kunden-Server, Exchange 2016 CU18. Dem hatte ich noch am Abend des 3. März das passende Sicherheitsupdate verpasst, der Server war da leider bereits schon angegriffen worden. Das tut aber für das Folgende vermutlich nichts zur Sache:

Ich habe dann, nachdem wir den Server untersucht und nach bestem Wissen und Gewissen gesäubert hatten (immer wieder die aktualisierten Hinweise geprüft/ auch in den Folgetagen und den https-Port dicht gemacht), gestern Abend den Exchange noch auf CU19 aktualisieren wollen. Das hatte auch soweit geklappt, Unified Messaging wieder deaktiviert und neu gestartet. System lief nach Neustart, Virenscanner (Defender) noch deaktiviert, da ich danach noch einmal den passenden Securitypatch für CU19 aufspielen wollte.

Das ging leider schief: Das Update begann, die Dienste wurden großflächig deaktiviert und mittendrin die Fehlermeldung, dass das Update abgebrochen hätte („prematurely ended“, mit Fehler 1603). Auch ein neuer Versuch brachte keinen Erfolg, der Exchange war „tot“. Da es schon 2.00 Uhr nachts war, habe ich mich entschieden, den (virtuellen) Server herunterzufahren, eine Imagesicherung der Festplatten einzuspielen und damit das System zunächst weiter zu betreiben, bis ich Klarheit habe, ob der erneute Patch überhaupt notwendig ist oder ob der nicht mehr gebraucht wird (was ich eigentlich nicht glaube, da der CU19 ja ein neu installierter Exchange ist).

Was mich noch überrascht hat: Der Exchange soll jetzt ein CU19 sein laut Build-Nummer, das ist er aber definitiv nicht – vermutlich steht das irgendwo im AD. Hier fehlt mir das Wissen.

Und weiter ging es in einer Folgemail:

Ich habe den (virtuellen) Server nun gestern Abend auf CU19 gebracht – mich aber noch nicht getraut, dass System erneut mit dem SU zu patchen. Eventuell mache ich das am Wochenende.

Leider gibt es für mein Vorgehen vom Exchange-Team keine Handlungsanweisung (zumindest gestern Abend). Und ich traue der Sache „einmal gepatched gilt immer“ nicht.

Jens hat mir noch den Techcommunity-Artikel verlinkt, der für ihn aber wohl nicht passte, wie der obige letzte Satz suggeriert. Jens wollte sich melden, wenn er ein Ergebnis hat. Hier die Meldung:

gerade lese ich den Text auf der verlinkten Seite nochmal:

• 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).

Das bedeutet leider, dass ich eigentlich bei dem inzwischen auf CU19 gepatchten 2016er Server ERNEUT das SU einspielen müsste (das für CU19). Das hatte ich letztes Mal gemacht und mir dabei die Finger verbrannt – der Exchange lief nicht mehr, sämtliche und darüber hinaus gehende Dienste waren deaktiviert.

Allerdings gibt es wohl ein Skript, dass diese wieder aktivieren soll. Mal sehen – vielleicht gebe ich der Sache doch heute noch einmal einen Versuch.

Ähnliche Rückmeldungen von Admins, die bildlich gesprochen „im Wald zwischen den Bäumen herum irren und den Durchblick verloren haben“, gab es hier im Blog ebenfalls. Ich nehme es ja der Fraktion „bei mir klappt alles problemlos“ ab, dass das im speziellen Szenario so ist. Nützt dem Admin oder IT-Dienstleister aber nichts, wenn er vor einem System steht, welches sich update-mäßig sperrt. Ja, ich kenne den Reflex „die sind nur zu blöde dafür“ – aber das ist zu kurz gesprungen. Einmal habe ich von Blog-Leser Karl mal wieder einige Fragmente (aus Erlebnissen mit Exchange-Kunden-Systemen von dieser Woche) vor die Füße geworfen bekommen (viele Systeme sind ja historisch gewachsen), die mir zeigen „der Teufel steckt im Detail“ und es erfordert viel Wissen und Erfahrung, um da durch zu kommen.

Möglicherweise schimmert die Altersmilde durch – vermutlich bin ich aber mehr von meiner Denke als Ingenieur mit angehängtem Informatikstudium geprägt, der vor den Exit als IT-Schreiberling Software-Entwicklergruppen zu verantworten hatte. Aus dieser Zeit ist mir hängen geblieben: Man kann zwar alle Mitarbeiter sind Dummköpfe und alles Idioten hier postulieren. Dann fällt man aber schnell auf den Bauch. Dort hatte ich die Haltung „rechne mit allem und versuche die Systeme so zu konzipieren, dass die diesbezüglich möglichst fail-save und wartbar bleiben“. Vom Bauchgefühl her täte dieser Denkansatz für Verantwortliche im Exchange-Umfeld sicher not – etwas schief gehen lassen, ist keine Kunst. Die Meisterschaft besteht darin, die Mannschaft so zu ertüchtigen, dass die auftauchenden Klippen umschifft werden.

MSERT-Tool: Placebo mit Beipack-Zettel?

Kommen wir zum letzten Informationsschnipsel. Verantwortlichen Administratoren obliegt die undankbare Aufgabe, schnell herauszufinden, wo Exchange-Server stehen, ob die per Internet erreichbar sind und ob die vielleicht kompromittiert sind. Vor einigen Minuten ist eine Mail von Roman Romanchenko bei mir eingetroffen, der mich darauf hinwies, dass seine Recherchen inzwischen nicht 170.000 sondern fast 300.000 per Internet erreichbare Exchange Server ergeben haben.

Ich kann auf der betreffenden Suchmaschine filtern, welche Ports offen sind (bei 443 komme ich auf 240.000 Instanzen), bekomme ohne Konto aber keine Möglichkeit, deutsche Systeme zu identifizieren. Also müssen Administratoren selbst ran. Ich hatte ja in den am Artikelende verlinkten Blog-Beiträgen die Frage nach dem Erkennen von Infektionen (Neues zum Exchange-Hack – Testtools von Microsoft & Co.) und die Vorgehensweise (Exchange-Hack: Neue Opfer, neue Patches, neue Angriffe) angerissen. Weil das PowerShell-Script von Microsoft bei Microsoft Exchange 2010 nicht greift (das läuft nicht), kam das MSERT-Tool ins Spiel (Microsoft MSERT hilft bei Exchange-Server-Scans).

Im ersten Augenblick dachte ich „Wow, einfach laufen lassen und angezeigt bekommen, ob einen Infektion vorliegt“. Dann kam der Einwand: Wenn MSERT die Schadfunktionen eliminiert, wird es mit der Forensik zur Aufarbeitung der Infektion eher schwierig. Dann kam noch der Hinweis von Stefan Kanthak zu den DLL-Hijacking-Schwachstellen des MSERT-Tools. Kommt natürlich besonders gut: Eine Malware lauert mit eingeschränkten Rechten, der Admin startet das MSERT-Tool mit administrativen Rechten und die Malware kann dem Scanner DLLs unterschieben, die dieser dann mit administrativen oder System-Rechten ausführt.

Aber es geht noch weiter, der Beipackzettel für MSERT wird immer länger. Im Kommentar hier weist Bastian darauf hin, dass das Tool mehr oder weniger ein Placebo zu sein scheint, welches den Blutdruck der Admins in schwindelnde Höhen treibt und Herzinfarkte befördert.

MSERT zeigt während es läuft an „Files Infected: 8“. Am Ende dann aber „No infection found.“ Vertrauenserweckend.

Und Sebastian ergänzt:

Hallo zusammen,
genau das gleiche Problem hatte ich auch. Infections während des Scans und dann folgendes Ergebnis:
->msert.log
Results Summary:
—————-
No infection found.
Successfully Submitted MAPS Report
Successfully Submitted Heartbeat Report

Sind keine Einzelfälle, im Technet gibt es einen langen Thread, seit 2014 mit dem Titel MSRT reports an infected file during scan, then reports no infections on completion, wo sich dieses Problem durch die Jahre zieht und von zahlreichen Nutzern bestätigt wird. Also eine Medizin ohne Wirkung oder mit Nebenwirkung? Zumindest kennt ihr nun den Beipackzettel.

Ähnliche Artikel:
Exchange-Server 0-day-Exploits werden aktiv ausgenutzt, patchen!
Wichtige Hinweise Microsofts und des BSI zum Exchange-Server Sicherheitsupdate (März 2021)
Exchange-Probleme mit ECP/OWA-Suche nach Sicherheitsupdate (März 2021)
Neues zum Exchange-Hack – Testtools von Microsoft & Co.
Microsoft MSERT hilft bei Exchange-Server-Scans
Exchange-Hack: Neue Patches und neue Erkenntnisse
Anatomie des ProxyLogon Hafinum-Exchange Server Hacks
Exchange-Hack: Neue Opfer, neue Patches, neue Angriffe
Neues zur ProxyLogon-Hafnium-Exchange-Problematik (12.3.2021)
Gab es beim Exchange-Massenhack ein Leck bei Microsoft?
ProxyLogon-Hack: Repository für betroffene Exchange-Administratoren