S3 Ep102.5: „ProxyNotShell“ Exchange Bugs – ein Experte spricht [Audio + Text]

Quellknoten: 1712650

KEINE PANIK… SONDERN SEIEN SIE BEREIT ZU HANDELN

Mit Paul Ducklin und Chester Wisniewski

Intro- und Outro-Musik von Edith Mudge.

Klicken und ziehen Sie auf die unten stehenden Schallwellen, um zu einem beliebigen Punkt zu springen. Du kannst auch direkt zuhören auf Soundcloud.

Ihr könnt uns auf hören Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher und überall, wo gute Podcasts zu finden sind. Oder lass es einfach fallen URL unseres RSS-Feeds in Ihren Lieblings-Podcatcher.


LESEN SIE DAS TRANSKRIPT

[MUSIKMODEM]


ENTE.  Hallo allerseits.

Willkommen zu einer weiteren speziellen Mini-Episode des Naked Security-Podcasts.

Ich bin Paul Ducklin, wieder mit dabei mein Freund und Kollege Chester Wisniewski.

Hallo Cheet.


CHET.  [FALSCHER AUSSIE-AKZENT] Guten Tag, Ente.


ENTE.  Nun, Chet, ich bin mir sicher, dass alle zuhören. wer kurz nach Erscheinen des Podcasts zuhört, weiß, wovon wir reden werden!

Und es muss so doppelläufig sein Zero-Day von Microsoft Exchange das so ziemlich am letzten Septembertag 2022 in der Wäsche rausgekommen ist:

Unsere Vertriebskollegen sagen: „Oh, es ist Monatsende, es ist Quartalsende, es ist eine hektische Zeit … aber morgen wird jeder auf 0 $ zurückgesetzt.“

So wird es dieses Wochenende für Sysadmins und IT-Manager nicht sein!


CHET.  Ente, denke ich, in den unsterblichen Worten des verstorbenen Douglas Adams, "KEINE PANIK" könnte in ordnung sein.

Viele Organisationen hosten ihre eigenen E-Mails nicht mehr vor Ort auf Exchange-Servern, sodass ein guter Teil der Leute dieses Wochenende tief durchatmen und ein wenig Zeit verstreichen lassen kann, ohne sich deswegen zu sehr zu stressen.

Aber wenn Sie Exchange lokal ausführen …

…wenn ich es wäre, würde ich vielleicht ein paar Überstunden machen, nur um ein paar Abschwächungen vorzunehmen, um sicherzugehen, dass ich am Montag oder Dienstag keine unangenehme Überraschung erlebe, wenn sich dies aller Wahrscheinlichkeit nach zu etwas anderem entwickelt dramatisch.


ENTE.  So ist es CVE-2022-41040 machen CVE-2022-41042… das ist ein ziemlicher Schluck.

Ich habe gesehen, dass es auf Twitter als bezeichnet wird ProxyNotShell, weil es einige Ähnlichkeiten mit dem hat ProxyShell Verwundbarkeit, das war die große Geschichte vor etwas mehr als einem Jahr,

Aber obwohl es diese Ähnlichkeiten hat, ist es ein völlig neues Paar von Exploits, die miteinander verkettet sind und möglicherweise eine Remote-Code-Ausführung ermöglichen – ist das richtig?


CHET.  So klingt es.

Diese Schwachstellen wurden während eines aktiven Angriffs auf ein Opfer entdeckt, und eine vietnamesische Organisation namens GTSC deckte diese beiden neuen Schwachstellen auf, die es den Angreifern ermöglichten, Zugriff auf einige ihrer Clients zu erhalten.

Es klingt, als hätten sie es verantwortungsbewusst offengelegt diese Schwachstellen an die von Trend Micro betriebene Zero Day Initiative [ZDI] für das verantwortungsvolle Melden von Zero-Day-Schwachstellen.

Und natürlich teilte ZDI dann wiederum all diese Informationen mit Microsoft, vor etwas mehr als drei Wochen.

Und der Grund, warum es heute herauskommt, ist meiner Meinung nach, dass die vietnamesische Gruppe…

… es klingt, als würden sie ein wenig ungeduldig und besorgt, dass es drei Wochen her ist und dass keine Warnungen oder Ratschläge ergangen sind, um die Menschen vor diesen mutmaßlichen nationalstaatlichen Akteuren zu schützen.

Also beschlossen sie, die Alarmglocken zu läuten und alle wissen zu lassen, dass sie etwas tun müssen, um sich zu schützen.


ENTE.  Und um fair zu sein, sagten sie vorsichtig: „Wir werden nicht genau verraten, wie diese Schwachstellen ausgenutzt werden können, aber wir werden Ihnen Abhilfemaßnahmen bieten, die wir für wirksam befunden haben.“

Es hört sich so an, als ob beide Exploits für sich genommen nicht besonders gefährlich sind …

… aber miteinander verkettet bedeutet dies, dass jemand außerhalb der Organisation, der die Fähigkeit hat, E-Mails von Ihrem Server zu lesen, tatsächlich den ersten Fehler verwenden könnte, um die Tür zu öffnen, und den zweiten Fehler, um im Wesentlichen Malware auf Ihrem Exchange-Server zu implantieren.


CHET.  Und das ist ein wirklich wichtiger Punkt, Ente, dass du gesagt hast, „Jemand, der E-Mails auf Ihrem Server lesen kann.“

Dies ist kein *nicht authentifizierter* Angriff, daher müssen die Angreifer einige Informationen über Ihr Unternehmen haben, um diese Angriffe erfolgreich auszuführen.


ENTE.  Jetzt wissen wir nicht genau, welche Art von Anmeldeinformationen sie benötigen, denn zum Zeitpunkt der Aufzeichnung [2022-09-30T23:00:00Z] ist alles noch weitgehend geheim.

Aber nach dem, was ich gelesen habe (von Leuten, denen ich eher glauben möchte), sieht es so aus, als ob Sitzungscookies oder Authentifizierungstoken nicht gut genug sind und dass Sie tatsächlich ein Benutzerkennwort benötigen würden.

Nachdem Sie das Passwort angegeben haben, wird jedoch bei einer Zwei-Faktor-Authentifizierung [2FA] der erste Fehler (der die Tür öffnet) *zwischen dem Punkt, an dem das Passwort bereitgestellt wird, und dem Punkt, an dem 2FA-Codes vorhanden wären, ausgelöst angefordert*.

Sie brauchen also das Passwort, aber Sie brauchen nicht den 2FA-Code…


CHET.  Es klingt wie eine „Mid-Authentication-Schwachstelle“, wenn Sie es so nennen wollen.

Das ist ein gemischter Segen.

Es bedeutet jedoch, dass ein automatisiertes Python-Skript nicht einfach das gesamte Internet scannen und möglicherweise jeden Exchange-Server der Welt innerhalb von Minuten oder Stunden ausnutzen kann, wie wir es bei ProxyLogon und ProxyShell im Jahr 2021 gesehen haben.

Wir haben in den letzten 18 Monaten die Rückkehr von Wurmerkrankungen gesehen, zum Nachteil vieler Organisationen.


ENTE.  „Wurmwurm“?


CHET.  Wurm, ja! [LACHT]


ENTE.  Ist das ein Wort?

Nun, wenn nicht, dann jetzt!

Das gefällt mir … Ich könnte es mir ausleihen, Chester. [LACHT]


CHET.  Ich denke, das ist leicht entwurmbar, oder?

Sie brauchen ein Passwort, aber leider ist es wahrscheinlich nicht allzu schwierig, eine Kombination aus E-Mail-Adresse und Passwort zu finden, die auf einem bestimmten Exchange-Server gültig ist.

Wenn Sie von Hunderten oder Tausenden von Benutzern sprechen … in vielen Organisationen haben wahrscheinlich ein oder zwei von ihnen schlechte Passwörter.

Und Sie wurden bisher möglicherweise nicht ausgenutzt, denn um sich erfolgreich bei Outlook Web Access [OWA] anzumelden, benötigen Sie ihr FIDO-Token oder ihren Authentifikator oder welchen zweiten Faktor Sie auch immer verwenden.

Aber dieser Angriff erfordert diesen zweiten Faktor nicht.

Es ist also eine ziemlich niedrige Hürde, nur eine Kombination aus Benutzername und Passwort zu erwerben …


ENTE.  Jetzt gibt es hier eine andere Komplexität, nicht wahr?

Nämlich das obwohl Microsofts Richtlinie sagt offiziell, dass Microsoft Exchange Online-Kunden von Blue Alert zurücktreten können, es ist nur gefährlich, wenn Sie Exchange vor Ort haben…

… es gibt überraschend viele Leute, die möglicherweise vor einigen Jahren in die Cloud gewechselt sind, die während der Umstellung sowohl ihren On-Premises- als auch ihren Cloud-Service gleichzeitig betrieben haben, die nie dazu gekommen sind, den On-Premises-Dienst abzuschalten Austausch server.


CHET.  Genau!

Wir haben gesehen, dass dies auf ProxyLogin und ProxyShell zurückgeht.

In vielen Fällen gelangten die Kriminellen über Exchange-Server in ihr Netzwerk, von denen sie dachten, sie hätten sie nicht.

Zum Beispiel hat jemand die Liste der VMs, die auf seinem VMware-Server ausgeführt werden, nicht überprüft, um festzustellen, dass seine migrierenden Exchange-Server ihn beim Forklifting der Daten zwischen seinem On-Premise-Netzwerk und dem Cloud-Netzwerk unterstützt haben …

… waren tatsächlich immer noch eingeschaltet und aktiviert und dem Internet ausgesetzt.

Und schlimmer noch, wenn nicht bekannt ist, dass sie dort sind, ist es noch unwahrscheinlicher, dass sie gepatcht wurden.

Ich meine, Organisationen, die zumindest über Exchange verfügen, bemühen sich wahrscheinlich, regelmäßige Wartungsarbeiten an ihnen zu planen.

Aber wenn Sie nicht wissen, dass Sie etwas in Ihrem Netzwerk haben, „weil Sie es vergessen haben“, was bei VMs wirklich einfach ist, befinden Sie sich in einer noch schlimmeren Situation, weil Sie wahrscheinlich keine Windows-Updates oder Exchange-Updates angewendet haben.


ENTE.  Und Murphys Gesetz besagt, dass, wenn Sie sich wirklich auf diesen Server verlassen und sich nicht richtig um ihn kümmern, er genau am Tag, bevor Sie ihn wirklich brauchen, abstürzt.

Aber wenn Sie nicht wissen, dass es da ist und es für schlechte Zwecke verwendet werden könnte, sind die Chancen, dass es jahrelang ohne Probleme läuft, wahrscheinlich ziemlich hoch. [LACHT]


CHET.  Ja, das ist leider meine Erfahrung!

Es klingt albern, aber wir würden Ihnen sowieso empfehlen, Ihr eigenes Netzwerk regelmäßig zu scannen, um herauszufinden, was Sie haben.

Aber wenn Sie von einem Bulletin wie diesem hören und es sich um ein Produkt handelt, von dem Sie wissen, dass Sie es in der Vergangenheit verwendet haben, wie Microsoft Exchange, ist es sicherlich ein guter Zeitpunkt, es intern auszuführen Nmap-Scan...

…und vielleicht sogar einloggen shodan.io und überprüfen Sie Ihre externen Dienste, nur um sicherzugehen, dass all diese Dinge ausgeschaltet wurden.


ENTE.  Wir wissen jetzt aus Microsofts eigener Antwort, dass sie wie wahnsinnig daran arbeiten, Patches herauszubringen.

Wenn diese Patches erscheinen, solltest du sie besser ziemlich schnell auftragen, nicht wahr?

Denn wenn jemals ein Patch für Reverse Engineering zum Einsatz kommt, um den Exploit aufzudecken, dann wird es so etwas sein.


CHET.  Ja, absolut, Ente!

Selbst nach dem Patchen wird es ein Zeitfenster geben, richtig?

Ich meine, typisch Microsoft veröffentlicht ihre Patches sowieso für Patch Tuesdays um 10.00:XNUMX Uhr pazifischer Zeit.

Im Moment haben wir Sommerzeit, das ist also UTC-7… also veröffentlicht Microsoft normalerweise um 17:00 UTC Patches, sodass die meisten ihrer Mitarbeiter den ganzen Tag Zeit haben, um dann auf eingehende Anfragen in Seattle zu antworten. [Der Hauptsitz von Microsoft befindet sich in Bellevue, Seattle, WA.]

Der Schlüssel hier ist, dass es eine Art „Rennen“ von Stunden, vielleicht Minuten gibt, je nachdem, wie einfach dies auszunutzen ist, bevor es beginnt.

Und noch einmal, wenn wir auf die früheren Exploits von Exchange mit ProxyShell und ProxyLogon zurückgehen, haben wir oft festgestellt, dass sogar Kunden, die innerhalb von drei, vier, fünf Tagen gepatcht hatten …

… was, um ehrlich zu sein, für einen Exchange-Server ziemlich schnell ist, sie sind sehr schwer zu patchen, mit vielen Tests, um sicherzustellen, dass es zuverlässig ist, bevor Sie Ihre E-Mail-Server unterbrechen.

Das war genug Zeit für diese Server Webshells, Kryptomacher, alle Arten von Backdoors auf ihnen installiert.

Wenn also der offizielle Patch herauskommt, müssen Sie nicht nur schnell handeln …

…*nachdem* Sie handeln, lohnt es sich, zurückzugehen und diese Systeme gründlich auf Anzeichen dafür zu überprüfen, dass sie möglicherweise in der Zeit zwischen dem Zeitpunkt, an dem der Patch verfügbar wurde, und dem Zeitpunkt, an dem Sie ihn anwenden konnten, angegriffen wurden.

Ich bin mir sicher, dass es viele Diskussionen über Naked Security und so weiter geben wird Twitter und an anderen Orten, um über die Arten von Angriffen zu sprechen, die wir sehen, damit Sie wissen, wonach Sie suchen müssen.


ENTE.  Während Sie nach einer Reihe von Hashes bekannter Malware suchen können, die bereits in einer begrenzten Anzahl von Angriffen verbreitet wurden …

…wirklich, das Endergebnis ist, dass alle Arten von Malware möglich sind.

Und so, wie ich glaube, du sagtest in der letzte Mini-Episode wie wir es getan haben, reicht es nicht mehr aus, nur auf Benachrichtigungen über etwas Schlimmes zu warten, das zufällig in Ihrem Dashboard auftaucht:

Sie müssen proaktiv rausgehen und nachsehen, ob sich schon Gauner in Ihrem Netzwerk aufgehalten haben und etwas hinterlassen haben (das schon seit Ewigkeiten dort sein könnte!), das Sie noch nicht bemerkt haben.


CHET.  Ich denke, das führt uns zu „Was machen wir jetzt, während wir auf den Patch warten?“

Der Blog des Microsoft Security Research Center (MSRC) wurde veröffentlicht einige Ratschläge zur Minderung und Details … so viel, wie Microsoft zu diesem Zeitpunkt bereit ist, offenzulegen.

Ich würde sagen, wenn du ein Reiner bist Microsoft Exchange Online Kunde, Sie sind ziemlich im Klaren und sollten nur aufpassen, falls sich die Dinge ändern.

Aber wenn Sie sich in einer hybriden Situation befinden oder Microsoft Exchange immer noch vor Ort ausführen, gibt es meiner Meinung nach wahrscheinlich einige Arbeiten, die es wert sind, heute Nachmittag oder morgen früh erledigt zu werden, wenn nichts anderes.

Zum Zeitpunkt der Aufnahme ist dies natürlich Freitagnachmittag … also wirklich, wenn Sie sich das anhören: „Sobald Sie es hören, sofort, wenn Sie es noch nicht getan haben.“

Was sind hier die besten Praktiken, Ente?

Natürlich können Sie den externen Webzugriff einfach deaktivieren, bis ein Patch verfügbar ist.

Sie könnten einfach Ihren IIS-Server herunterfahren, und das würde es tun!


ENTE.  Ich vermute, dass viele Unternehmen nicht in dieser Position sein werden.

Und Microsoft listet zwei Dinge auf, die sie sagen … nun, sie sagen nicht, „Das wird auf jeden Fall funktionieren.“

Sie schlagen vor, dass es Ihr Risiko stark begrenzen wird.

Zum einen gibt es eine Regel zum Umschreiben von URLs, die Sie auf Ihren IIS-Server anwenden können. (Mein Verständnis ist, dass es IIS ist, das die eingehende Verbindung akzeptiert, die in den Zugriff auf Exchange Web Services [EWS] umgewandelt wird.)

Es gibt also eine IIS-Einstellung, die Sie vornehmen können, um nach wahrscheinlichen Ausnutzungen der ersten Lücke zu suchen, wodurch verhindert wird, dass die PowerShell-Auslösung gestartet wird.

Und es gibt einige TCP-Ports, die Sie auf Ihrem Exchange-Server blockieren können.

Ich glaube, es sind die Ports 5985 und 5986, die das, was aufgerufen wird, stoppen PowerShell Remoting… es wird verhindern, dass diese bösartigen PowerShell-Remoteausführungsbefehle in den Exchange-Server eingeschleust werden.

Beachten Sie jedoch, dass Microsoft sagt, dass dies Ihre Exposition „begrenzen“ wird, anstatt zu versprechen, dass sie wissen, dass es alles behebt.

Und das kann daran liegen, dass sie vermuten, dass es andere Möglichkeiten gibt, wie dies ausgelöst werden könnte, aber sie haben einfach noch nicht ganz herausgefunden, was sie sind. [LACHT]

Keine der beiden Einstellungen nehmen Sie in Exchange selbst vor.

Einer davon befindet sich in IIS und der andere ist eine Art Netzwerkfilterregel.


CHET.  Nun, das ist hilfreich, um uns durch die nächsten Tage zu bringen, während Microsoft uns eine dauerhafte Lösung gibt.

Die gute Nachricht ist, dass ich denke, dass viele Sicherheitssoftware, sei es ein IPS, das möglicherweise in Ihre Firewall integriert ist, oder Endpoint-Sicherheitsprodukte, die Sie zum Schutz Ihrer Microsoft Windows Server-Infrastruktur haben, …

… die Angriffe dafür sehen in vielen Fällen (zumindest frühe Berichte) ProxyLogon sehr ähnlich, und daher ist unklar, ob bestehende Regeln vor diesen Angriffen schützen.

Sie können, aber darüber hinaus scheinen die meisten Anbieter zu versuchen, sie ein wenig zu straffen, um sicherzustellen, dass sie so bereit wie möglich sind, basierend auf allen Indikatoren, die derzeit öffentlich geteilt wurden, damit sie erkennen und senden Ihnen Benachrichtigungen, wenn diese auf Ihren Exchange-Servern auftreten sollten.


ENTE.  Das ist richtig, Chester.

Und die gute Nachricht für Sophos-Kunden ist, dass Sie Sophos-spezifische Erkennungen nachverfolgen können, wenn Sie Ihre Protokolle durchsuchen möchten.

Nicht nur für IPS, sei es das IPS auf der Firewall oder dem Endpunkt, sondern wir haben auch eine Reihe von Verhaltensregeln.

Sie können diese Erkennungsnamen verfolgen, wenn Sie nach ihnen suchen möchten ... folgen Sie dem auf der @SophosXops Twitter-Feed.

Wenn wir neue Erkennungsnamen erhalten, die Sie für die Bedrohungssuche verwenden können, veröffentlichen wir sie dort, damit Sie sie leicht nachschlagen können:


CHET.  Ich bin sicher, wir werden im Podcast nächste Woche mehr zu sagen haben, ob Doug wieder zu Ihnen kommt oder ob ich wieder auf dem Gastplatz sitze.

Aber ich bin ziemlich zuversichtlich, dass wir das jetzt noch eine ganze Weile nicht zu Ende bringen können….


ENTE.  Ich denke, wie ProxyShell, wie Log4Shell, wird es eine ganze Weile ein Echo geben.

Also sollten wir vielleicht besser sagen, wie wir es immer tun, Chester:

Bis zum nächsten Mal…


BEIDE.  Bleib sicher.

[MUSIKMODEM]


Zeitstempel:

Mehr von Nackte Sicherheit