[English]Sind auf dem aktuellen Patch-Stand befindliche Microsoft Exchange Server über die Remote Code Execution-Schwachstelle CVE-2022-23277 immer noch angreifbar? Mir sind gerade einige Informationsfragmente unter die Augen gekommen, die zumindest nahelegen, dass da (zumindest theoretisch) Möglichkeiten zur Ausnutzung bestehen. Interessant ist auf jeden Fall die Offenlegung der Details, die zur Schwachstelle führten. Ich versuche mal die Informationen bestmöglich zusammen zu fassen.
Anzeige
Kurzer Rückblick auf CVE-2022-23277
Bei CVE-2022-23277 handelt es sich um eine als kritisch (Score 8.8) eingestufte Remote Code Execution-Schwachstelle, bei der ein Angreifer zwar authentifiziert sein muss. Es ist aber nur eine authentifizierte Rolle mit geringen Berechtigungen (PR:L) auf dem Exchange Server erforderlich. Der Angreifer für diese Sicherheitsanfälligkeit könnte die Serverkonten für eine beliebige oder entfernte Codeausführung angreifen. Als authentifizierter Benutzer könnte der Angreifer versuchen, über einen Netzwerkaufruf bösartigen Code im Kontext des Serverkontos auszulösen.
Gefunden und gemeldet wurde die Schwachstelle von Markus Wulftange. Microsoft hat im März 2022 zwei als kritisch eingestufte Schwachstellen, unter anderem die Remote Code Execution-Schwachstelle CVE-2022-23277 mit einem Patch für Exchange Server 2013 – 2019 geschlossen. Aber Details zur Schwachstelle wurden keine genannt. Damit war das Thema für mich abgehakt.
Offenlegung des Problems
Markus Wulftange hat zum 28. Juni 2022 seine Erkenntnisse im Beitrag Bypassing .NET Serialization Binders veröffentlicht. Er geht im Beitrag darauf ein, dass die Binder zur Serialisierung unter .NET-Framework oft verwendet werden, um die in den serialisierten Daten angegebenen Typen zu validieren. Ziel ist es, die Deserialisierung gefährlicher Typen, die mit den Laufzeit-Serialisierern wie dem BinaryFormatter bösartige Nebeneffekte haben können, zu verhindern.
In seinem Blog-Beitrag wirft Wulftange einen Blick auf Fälle, in denen diese Prüfung fehlschlagen kann und folglich eine Umgehung der Validierung ermöglicht. Er führt auch zwei reale Beispiele für unsichere Serialisierungsbinder im DevExpress-Framework (CVE-2022-28684) und Microsoft Exchange (CVE-2022-23277) an, die er diskutiert. Beide Schwachstellen ermöglichen eine Remotecodeausführung.
Anzeige
Ist "trocken Brot" für .NET-Entwickler, ich bin da schon zu viele Jahre sehr weit weg, um mich durch die Details zu wühlen. Das Fazit von Markus Wulftange: Die unsicheren Serialisierer BinaryFormatter, SoapFormatter und NetDataContractSerializer sollten nicht mehr verwendet werden und Legacy-Code sollte auf die bevorzugten Alternativen migriert werden. So weit so gut.
Tinfanu-CUP und Exchange-Hack
Wo es bei mir sofort geklingelt hat, war der nachfolgend gezeigte Tweet. Die Aussage: Der PoC-Exploit-Code für die Schwachstelle CVE-2022-23277, die bei Tianfu-Contest zum Hacken von Microsoft Exchange Server verwendet wurde (weiß nicht, ob der Contest 2021 oder 2022 war), funktioniert mit einem leicht angepassten Ansatz weiterhin. Im Screenshot sieht man, dass die MSExchangePowerShell benutzt wurde – hier um Paint aufzurufen.
Unklar war, ob das auch für einen vollständig gepatchten Exchange Server, bei dem im März 2022 die Sicherheitsupdates zum Schließen der Schwachstelle installiert wurden, gilt. Meine erste Interpreation war, dass ein angepasster Exploit auch auf einem gepatchten Exchange Server funktioniert. Im englischsprachigen Blog gibt es inzwischen einen Kommentar, den ich so interpretiere, dass nicht gesagt werden kann, ob der Exploit auf einem gepatchten Exchange ausnutzbar ist (der Microsoft Patch funktioniert, aber es wurde wohl nicht wirklich mit Exploits getestet). Ob da was ausnutzbar ist, bleibt unklar.
Für mich bedeutet das (vom Bauchgefühl her): Microsoft verwendet eine Menge alten Code, in dem die Serialisierungs-Bindung nicht korrekt auf bösartige Parameter überprüft werden kann – man scheint lediglich eine bestimmte Code-Stelle mit einem Patch versehen. Und beim Sharepoint-Server soll es im Mai 2022 einen ähnlichen Patch gegeben haben.
Bewertung offen
Ich kann an dieser Stelle nicht sagen, ob das eine negative Auswirkung auf Exchange- und Sharepoint-Installationen hat. Wenn ich es richtig interpretiere, müsste der Tinfu-Patch die konkrete Schwachstelle abdichten. Aber es bleibt das Gefühl, dass da weiterhin einige sicherheitstechnische Böcke bei der Prüfung der Serialisierungs-Bindungen im .NET-Code schlummern. Es ist nur eine Frage der Zeit, bis der nächste Patch fällig wird.
Was man als Administrator tun kann?
Abschließend bleibt die Frage, was Administratoren von Exchange Servern tun können, um weniger Angreifbar für solche Schwachstellen zu werden. Ad hoc fallen mir die üblichen Ratschläge ein: Sicherstellen, dass Exchange und OWA nicht direkt per Internet erreichbar ist und ggf. über einen Reverse Proxy abgeschottet werden (Frank Carius hat hier was zu geschrieben) und nur autorisierte Personen Zugriff auf Exchange-Konten haben.
Im konkreten Fall gibt es noch einen anderen Punkt. Um CVE-2022-23277 auszunutzen, benötigt der Angreifer einen authentifizierten Zugriff auf ein Exchange-Konto. Hier gilt es sicherzustellen, dass keine verwaisten Konten (ausgeschiedene Mitarbeiter) existieren und dass die Konten nicht über schwache Passwörter per Brute Force gehackt werden können. Falls was fehlt, könnt ihr das in den Kommentaren nachtragen.
Ähnliche Artikel:
Sicherheitsupdates für Exchange Server (Januar 2022)
Sicherheitsupdates für Exchange Server (8. März 2022)
Tianfu Cup 2021: Exchange 2019 und iPhone gehackt
Tianfu Cup Competition: Windows 10, iOS, Chrome, Firefox gehackt
Anzeige
Der Tweet-Poster scheint aber zurückgerudert sein:
https://twitter.com/testanull/status/1542409312337018880
Zitat: "
Janggggg
@testanull
What I want to mention in this post is: "The bug was patched in March"
I don't mean that " ̶I̶t̶ ̶still w̶o̶r̶k̶e̶d̶ ̶o̶n̶ ̶E̶x̶c̶h̶a̶n̶g̶e̶ ̶S̶e̶r̶v̶e̶r̶ ̶p̶a̶t̶c̶h̶e̶d̶ ̶i̶n̶ ̶M̶a̶r̶c̶h̶""
Danke für den Hinweis. Wer den obigen Beitrag genauer liest, wird bemerken, dass ich genau das bereits im Text korrigiert habe (der Nutzer hatte sich im englischen Blog per Kommentar gemeldet, wenige Minuten, nachdem ich das gelesen hatte, war der Text hier und drüben angepasst). Ich lasse mal offen, ob der Thread-Ersteller zurückgerudert ist, oder ob ich wegen der englischen Sprache die Nuancen falsch interpretiert habe.
Aus obigem Beitrag lässt sich aktuell folgendes herausziehen: Im Gegensatz zu den Microsoft-Beschreibungen der Schwachstelle ist nun bekannt, wo es geknackt hat. Und die Knackstelle ist alles andere als schön: Es werden Serializer Bindungen verwendet, die Daten in Streams schreiben und lesen – und der Fehler ist, dass nicht überprüft wurde, ob die Daten bösartig sind.
Ich bin zwar 14 Jahre aus der .NET-Programmierung raus. Wenn ich mir aber mal die alten Kenntnisse rauskrame, sagt mir mein Bauch: In den vielen Tausend Exchange Quellcode-Zeilen mag es einige Stellen geben, an denen dieses Konstrukt verwendet wird.
Preisfrage: Hat Microsoft genau die eine Stelle, die vom Sicherheitsforscher aufgezeigt wurde, im Code korrigiert? Oder sind die alle Instanzen, wo die kritischen Serilization-Bindungen verwendet werden, durchgegangen und habe den Code angepasst? Und ich schiebe noch eine dumme Frage nach: Wie wird in den Daten geprüft, ob die schädlich sind? Ich meine ja nur – bei PrintNightmare war es ja so, dass alle zwei Tage eine neue Erkenntnis kam, was noch alles angreifbar ist.
Damit überlasse ich es der Interpretation eines jeden Blog-Lesers und einer jeden Blog-Leserin, ob die gepatchte Schwachstelle jetzt wirklich sicher ist und ob nicht noch andere "Opsies" da lauern. Ich kann nur, basierend auf den Aussagen des Thread-Posters ausführen: Dass der dieser Person vorliegende PoC Exploit des Tianfu-Contest wohl bisher versagt – was aber nicht bedeutet, dass das nun als sicher angesehen werden kann. Möglicherweise reicht es, die böswilligen Daten anders anzuordnen – es hat nur noch niemand die "zündende Idee" dazu gehabt.
Lieber Herr Born, erst einmal vielen Dank für diesen großartigen und für mich über die Jahre sehr hilfreichen Blog! Ja, ich hatte gelesen, dass Sie die Information relativiert hatten. Ich wollte nur gestressten Exchange-Admins das Wochenende retten ;-). Ihre Einschätzung, dass in den vielen tausenden oder gar Millionen Zeilen Code (leider) noch viele Unwägbarkeiten lauern, teile ich. Bei gewachsener Closed Source Software ist das gar nicht zu vermeiden, weshalb ich selber eher ein Open Source Anhänger bin. Umso mehr freue ich mich, dass Sie sich nun vermehrt und mit sehr viel Expertise mit Windows-IT-Sicherheit beschäftigen! Und die Aktualität Ihres Blogs ist unschlagbar, Chapeau!