[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.
Anzeige
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:
Anzeige
Critical CVEs
============================
* 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
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
Anzeige
Ich verfolge dieses Thema ziemlich interssiert, obwohl ich mit Exchange eigentlich nichts zu tun habe. Dabei kommen mir 2 Gedanken in den Sinn.
1.) In den IT Abteilungen läuft sicher einiges schief. Vom geizigen Boss bis zum überheblichen Admin. Das ändert nichts daran, dass so ein System von einem durchschnittlichen und ausreichend geschultem Admin wartbar bleiben müsste. Ansonsten liegt der Fehler bei MS. Vom viel zu kurzen Zeitfenster für das Patchen bis zu scheinbar regelmäßigen Problemen nach dem Patchen.
Wenn das bei Windows 10 so wäre, würde ich auch nicht ständig die Updates einspielen oder nur mit viel Sorge. Vor allem auf einem Produktivsystem.
Das geht also gar nicht.
2.) Bei einem so klagefreudigen Land wie die USA, müsste es doch langsam Sammelklagen hageln.
Die Sorgfaltspflicht hat MS doch sicher mehrfach verletzt.
Vielleicht sieht das ein IT Experte auch anders. Gewachsene Systeme können tückisch sein. Das kenne ich leider aus anderen Bereichen. Da kann man nicht beliebig verändern. Siehe auch einige Systeme der Banken, die ja teilweise noch steinalt sein sollen.
Angreifer sind den Angegriffenen immer mindestens einen Schritt voraus. Den Betroffenen bleibt dann eigentlich nur zu reagieren, Schadensbegrenzung zu betreiben und Vorkehrungen für die Zukunft zu treffen. Aber da beißt sich die Katze in den Schwanz und das Spiel beginnt von vorne.
Auch Microsoft ist hier ganz eindeutig Opfer und die müssen jetzt zusehen, wie sie die notwendigen Schutzvorkehrungen in die Tat umsetzen.
Schuld sind hier nur die Angreifer, sonst niemand. Hierbei von einer Verletzung der Sorgfaltspflicht zu reden und gar rechtliche Schritte einzufordern, ist vollkommen übers Ziel hinausgeschossen. Vor allem, wenn man die näheren Umstände nicht kennt.
"Die Sorgfaltspflicht hat MS doch sicher mehrfach verletzt."
Das ist (nicht nur) bei Microsoft Methode!
Beispiele:
1. Spätestens seit dem massgeblich von Steve Sutton (mit)verfassten und 1996/1997 veröffentlichten "NSA Guide" (Kurzfassung siehe ist "search order hijacking" (dort "DLL spoofing" genannt) wohlbekannt und wohldokumentiert.
Microsoft ignoriert dazu gemeldete Schwachstellen seit 25 Jahren, siehe u.a. https://seclists.org/fulldisclosure/2021/Mar/22
Für umfassende Dokumentation ihrer Unterlassungen siehe
https://skanthak.homepage.t-online.de/!execute.html, https://skanthak.homepage.t-online.de/verifier.html, https://skanthak.homepage.t-online.de/minesweeper.html, https://skanthak.homepage.t-online.de/sentinel.html, https://skanthak.homepage.t-online.de/detour.html
2. Ähnlich übel ist die Verwendung unqualifizierter Datei- statt vollqualifizierter Pfadnamen sowie von Umgebungsvariablen in diesen.
Siehe dazu https://skanthak.homepage.t-online.de/sloppy.html oder https://skanthak.homepage.t-online.de/offender.html
3. Microsoft unterläuft seit Beginn der NT-Zeiten die Benutzertrennung, beispielsweise durch das von unter SYSTEM-Konto laufenden Prozessen genutzte TMP-Verzeichnis C:WindowsTemp, in das unprivilegierte Benutzer schreiben können, oder die als "Benutzerkontensteuerung" vermarktete strunzende Dummheit.
Siehe dazu https://seclists.org/fulldisclosure/2021/Mar/7 bzw.
https://skanthak.homepage.t-online.de/tempest.html sowie https://skanthak.homepage.t-online.de/uacamole.html
Alleine mit diesen Schwachstellen können unprivilegierte Benutzer (nicht nur) in Standard-Installationen von Windows IMMER SYSTEM-Rechte erlangen.
All das sind ANFÄNGERFEHLER, die Microsoft problemlos abstellen könnte.
> Weil das PowerShell-Script von Microsoft bei Microsoft Exchange 2010 nicht greift
> (das läuft nicht)
Gibts dafür Quellen ? Wir haben das Script durchaus auf Ex2010 Servern ausgeführt, die einzigen "Fehlemeldungen" waren Hinweise, das die Prüfung auf Lücken für Ex2013,2016,2019 übersprungen wurden, …..
Die, Stand Montag, laufen alle, hab sie auch laufen lassen. Am letzten Freitag war tatsächlich eins, was ich nicht zum Laufen brachte, den Check (Logfiles nach bestimmten Einträgen durchsuchen) hab ich dann aber manuell gemacht, robocopy aller Logs von Exchange nach lokale und Notepad++ war da mein Freund… Das deutlich erweiterte Script vom Montag erledigte dann das, was ich am Freitag manuell gemacht hatte, nochmal viel schneller (und gründlicher)…
Was leider den einen oder anderen Gelegenheits-Exchange-Admin aus der Ruhe bringen kann, ist dass man für diese Scripte auch von den Rechten auf der Kiste auch Exchange-Admin sein muss…
Suche hier im Blog nach Exchange und gehe die Kommentare durch – gab mehrere Einträge diesbezüglich.
< und mir dabei die Finger verbrannt – der Exchange lief nicht mehr, sämtliche und
< darüber hinaus gehende Dienste waren deaktiviert.
Das habe wir auch immer wieder beobachtet, fast immer war die Ursache, das das Update nicht über eine Administrative CMD gestartet wurde…
siehe auch folgendes aktuelles Beispiel:
https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-march-2-2021-kb5000871-9800a6bb-0a21-4ee7-b9da-fa85b3e1d23b
Exchange services might remain in a disabled state after you install this security update. This condition does not indicate that the update is not installed correctly. This condition might occur if the service control scripts experience a problem when they try to return Exchange services to their usual state.
To fix this issue, use Services Manager to restore the startup type to Automatic, and then start the affected Exchange services manually. To avoid this issue, run the security update at an elevated command prompt. For more information about how to open an elevated Command Prompt window, see Start a Command Prompt as an Administrator.
@ Blog-Leser Jens H.:
Ja, ein Exchange-CU-Update verändert das ActiveDirectory – auch die Versionsnummer steht da drin.
Ich traue mich nicht eine „alte" ExchangeVM in eine „neue/upgedatete" AD-Domäne wiederherstellen. Da kannst vielleicht in sehr komische Situationen reinschlittern.
Wenn Du „zurück" musst: vielleicht geht bei Dir ja ein Restore aller DCs und des Exchanges?
Viel Glück!
Dietmar
Schöne Zusammenfassung. Ich verstehe aber folgendes Szenario nicht: Exchange ist auf C18, Patch dafür wird eingespielt, erstmal alles gut und im Nachgang CU 19 einspielen, und glauben, damit ist alles gut. Denn den Patch gibts ja auch für CU19, das ja älter ist, als der Patch. Da muss doch eigentlich klar sein, dass der Patch (für CU19) wieder installiert werden muss. Ansonsten müsste man auf CU20 warten, keine Option… Die Probleme mit dem Installieren vom Patch für CU19 könnte übrigens daran liegen, dass auf dem Server noch andere Updates fehlen. Und wenn das nur irgendwelche .NET Updates sind, die man vergessen hat, im WSUS freizugeben… Der Exchange-Server meldet dann auf Windows-Update-Ebene "alles gut", aber in Wirklichkeit fehlt ihm doch was für das erfolgreiche Update von Exchange, weil ihm der WSUS das nicht zugeteilt hat.
Hallo Admins,
wenn ich gelegentlich Exchange Servers patchen muss, benütze ich die ziemlich detaillierte Infos bei msxfaq.de
Zum Glück habe ich jetzt alle meine Kunden in Office365 migriert.
Hier sind also einige hilfreiche Links:
https://www.msxfaq.de/exchange/update/hafnium-exploit.htm
https://www.msxfaq.de/exchange/update/servicepack2016.htm
Und das noch, um zu prüfen ob man infiziert ist:
https://web.archive.org/web/20220810043533/https://www.welivesecurity.com/2021/03/10/exchange-servers-under-siege-10-apt-groups/
Viel Erfolg!
Danke – ich wollte heute noch ein Repository schreiben, wo ich die relevanten Infos verlinke – werde das mit aufgreifen.
Danke für die Links :)
"Zum Glück habe ich jetzt alle meine Kunden in Office365 migriert."
Mir ist schon der Gedanke gekommen das diese Attacken aufgrund dieser Exchange-Sicherheitslücke indirekt auch eine Werbung für Office 365 darstellt. Immer auf den aktuellsten Patchstand samt Backups inkl und dazu noch die Vermutung das Microsoft schon länger von der Lücke gewusst haben dürfte. Ein Schelm der böses denkt aber ich denke Microsoft wird diese Sicherheitslücke noch auf diversen Wegen noch lange unangenehm verfolgen.
Allerdings, wenn ich mir den Fall des französischen Cloud-Anbieter OVHcloud ansehe wo eines deren 4 Datenzentren in Flammen aufging und für einige Kunden deren Daten für immer verloren sind, ist die Cloud auch nicht das einzig wahre.
und was machst du wenn dein on-premise serverraum abbrennt?
Mir fallen hier z.B 2 mögliche Vorkehrungen ein:
– Backup an einem anderen Standort/Gebäude/Raum ablegen
– Spiegeln der Daten an einem anderen Standort/Gebäude/Raum
Könnte/Sollte/Wird der Cloud-Betreiber natürlich auch machen.
Diese Woche hatte ich ein Rollback eines angegriffenen Exchange Servers 2019 mit aktuellem CU aus dem Backup ausgeführt und musste danach das Sicherheitsupdate wieder einspielen.
Also gedacht "sorgst dafür, dass der Exchange Server mit seinem Netzwerkadapter keine Netzwerkverbindung ins LAN bekommt, installierst den Patch und verbindest wieder".
Erster Versuch nach einigem Gerödel "Kann nicht prüfen, ob das installierende Konto Mitglied der AD-Gruppe Exchange … ist" ohne Möglichkeit, vor dem Abbruch die Verbindung herzustellen und dann weiter zu machen.
Beim zweiten Versuch hatte ich die Verbindung zur rechten Zeit hergestellt (die OWA-Freigabe war in der Firewall abgeschaltet) und als die Installation anlief, wieder getrennt. Die lief dann bis zum Ende durch, konnte aber ohne Kontakt zu den DCs die Dienste nicht starten und führte dann einfach ungefragt einen Rollback aus. Das könnte ich verstehen, wenn ich über Windows Update installiere, doch bei einer manuellen Installation möchte ich eigentlich die Kontrolle und vor allem Eingriffsmöglichkeiten behalten wie die Möglichkeit, etwas zu ignorieren oder etwas zu wiederholen.
Der dritte Versuch lief dann durch – mit permanenter Verbindung zur Domäne.