Exchange-Hack: patchen und gut ist?

Wer in den letzten Tagen nicht gerade völlig fernab von Internet und sonstigen News unterwegs war konnte eigentlich nicht übersehen dass Exchange-Server weltweit im Zentrum einer grossen Hacker-Attacke standen und stehen. Die Rede ist von 100’000en von Exchange-Installationen weltweit welche entweder anfällig sind oder bereits angegriffen wurden. Ausgenutzt werden dabei insgesamt vier Schwachstellen welche es insgesamt erlauben, sämtliche auf einem Exchange-Server gehaltenen Mails auszulesen sowie in Form einer Webshell einen separaten Zugang zum Server zu installieren welcher auch erhalten bleibt wenn die eigentliche Lücke gestopft ist.

“Was ist überhaupt Exchange und wieso ist das wichtig” wird jetzt vielleicht der eine oder die andere fragen. Vereinfacht gesagt ist dies die Email- und Kalender-Plattform von Microsoft welche weltweit bei vielen Unternehmen und Behörden sowohl für die interne wie auch die externe Email-Kommunikation im Einsatz ist. Die Plattform ist eng mit den übrigen Microsoft-Produkten verknüpft und aufgrund ihrer Grösse und Komplexität nicht immer ganz einfach zu betreiben und zu unterhalten. Microsoft bietet daher eine Cloud-Lösung an (welche von den aktuellen Schwachstellen offenbar nicht betroffen ist), diese kommt aber für viele Anwender nicht in Frage welche ihre Daten selber halten wollen oder müssen.

Beim Angriff werden sogenannte Zeroday-Lücken ausgenutzt. Dies sind Software-Fehler welche ein Eindringen in ein System erlauben und bisher nur dem Angreifer (oder den Angreifern) bekannt ist, nicht aber dem Systembetreiber oder dem Software-Anbieter. Die Lücke wird also bereits aktiv ausgenutzt wenn der Anbieter am aus seiner Sicht Tag 0 davon erfährt.

Wir wollen hier keine weitere Beschreibung der Schwachstellen machen, dazu findet sich in The Microsoft Exchange Hack and the Great Email Robbery oder Der Hafnium Exchange-Server-Hack: Anatomie einer Katastrophe bereits ein guter Überblick und weitere Links (zum Beispiel auf die Analyse einer der Sicherheits-Firmen welche bereits Anfang Januar erste Angriffe auf von ihnen betreuten Servern festgestellt hatte). Was sich aber zu betrachten lohnt, ist der generelle Ablauf solcher Angriffe, schlussendlich handelt es sich ja nicht um die erste derartige Lücke noch wird es die letzte gewesen sein. Und es hilft zu verstehen, dass in solchen Fällen nicht einfach am nächsten Tag jemand nen Schalter umlegt und alles ist wieder gut.

Zeroday-Lücken und deren Folgen

Ein Hacker oder eine Hackergruppe findet eine von aussen ausnutzbare Schwachstelle

Das Aufspüren von Schwachstellen ist meist harte Arbeit, bestehend aus viel Wissen über typische Programmierfehler, Analyse von Datenflüssen in Systemen, kreativem Denken und einigem Aufwand an Trial & Error. Wann und durch wen Schwachstellen (vor allem wenn sie für Hacker-Angriffe genutzt werden) entdeckt werden, bleibt oft unklar. Begünstigt werden solche Angriffe durch komplexe Software-Produkte welche viele Funktionen aufs Mal anbieten und oft undurchschaubar sind, durch aufwändige Update-Prozesse welche von Betreibern nur ungern ausgeführt werden; interessant gemacht werden sie zum Beispiel durch Software-Monokulturen weil dabei eine einzelne Schwachstelle global ausgenutzt werden kann.

Im aktuellen Fall kann das schon vor einiger Zeit geschehen sein, insbesondere da auch diverse ältere Exchange-Versionen betroffen. Und auch wenn momentan einiges darauf hindeutet dass der Angriff dann durch einen staatlichen Akteur erfolgte: Es gibt einen Markt für solche Schwachstellen, es ist also auch durchaus denkbar dass jemand die Lücke fand und sie dann an den Meistbietenden verkaufte.

Die Schwachstelle wird gezielt ausgenutzt

Das “Problem” sämtlicher Hacker-Angriffe ist, dass sie früher oder später entdeckt werden (und dann eben nicht mehr funktionieren weil sich die Opfer/Ziele schützen und/oder der betroffene Hersteller einen Update bereitstellt). Also legen es insbesondere staatliche Akteure darauf an, Zero Day-Lücken erst dann einzusetzen wenn sie einen konkreten Vorteil/Gewinn davon haben, zu gross ist sonst das Risiko, eine an sich vielversprechende Lücke mit einem unnötigen Einsatz quasi zu verbrennen. Der Tradeoff dabei ist natürlich dass man immer damit rechnen muss das der Hersteller den Fehler gezielt oder zufällig mit einem Upgrade behebt bevor man ihn ausnutzen kann.

Im konkreten Fall wurden Angriffe auf Exchange-Server Anfang Januar entdeckt. Es scheint aber noch unklar zu sein ob es frühere Angriffe gab (welche unentdeckt blieben).

Schadensminimierung

Als Serverbetreiber wie auch als Hersteller der betroffenen Software ist man nun in einer schwierigen Lage. Man muss, auf Basis oft noch unvollständiger Informationen, Wege finden um die Angriffe zu unterbinden und die Lücke schlussendlich zu schliessen. Beides ist oft komplexer als man meinen könnte:

• Um Angriffe zu unterbinden, muss man nicht nur die Lücke an sich kennen sondern auch die Art wie sie ausgenutzt wird. Und bevor man dann einfach einen Webservice abschaltet oder Zugriffe filtert muss man sich nach Möglichkeit vergewissern dass keine “normale” User ausgeschlossen werden. Gerade letzteres ist natürlich ein Tradeoff, je nach Schwere des Angriffs muss man verärgerte User in Kauf nehmen um das Gesamtsystem zu schützen
• Den Fehler zu beheben dauert dann oft noch deutlich länger, vor allem wenn wie im Fall von Exchange weltweit diverse Versionen in unterschiedlichen Konfigurationen im Einsatz sind. Es gilt schlussendlich zu vermeiden, dass durch ein übereiltes Patchen des Problems neue Fehler auftreten oder Administratoren die Patches nicht einspielen um ihr System nicht noch weiter zu destabilisieren
• In Bezug auf US-amerikanische Softwarehersteller hält sich im weiteren hartnäckig das Gerücht, dass diese beim Entdecken von Zero Day-Attacken die NSA etc informieren damit diese allenfalls die Lücke für eigene Operationen ausnützen können (ähnliches gilt wahrscheinlich auch für andere Länder und Geheimdienste, nur haben wir von dort weniger Software global im Einsatz). Je nach Situation und Kontext beschleunigt dies die Fehlerbehebung natürlich auch nicht

Ausweitung der Angriffe

Der Angreifer selbst ist in dieser Zeit natürlich nicht untätig. Spätestens wenn die ersten Angriffe auf die bereits bekannten Systeme blockiert werden, dürfte ihm klar sein dass er entdeckt wurde. Er hat nun keinen Grund mehr sich zurückhalten, er wird sogar eher die noch verbleibende Zeit dazu nutzen, mit seinem Angriff an möglichst viele Daten heranzukommen. Im konkreten Fall kombinierte er mehrere Schwachstellen um nicht nur an die in Exchange gehaltenen Emails zu gelangen sondern auch eine Hintertür (Webshell) zu installieren, in der Hoffnung diese auch nach dem Beheben des Fehlers durch Microsoft und der Installation des Patches durch den Betreiber weiterhin nutzen zu können.

Falls parallel dazu weitere Angreifer einsteigen weil durch die Schadensminderungs-Massnahmen weitere “interessierte” Kreise auf die Lücke aufmerksam werden, steigt die Wahrscheinlichkeit dass diese ohne Rücksicht auf Verluste agieren und erst recht möglichst viele Systeme angreifen. Das kann, wie im konkreten Fall, auch bedeuten dass diese neuen Angreifer ganz andere Ziele verfolgen: Unterdessen sind mehrere Ransomware-Angriffe auf Exchange-Systeme bekannt geworden welche über die bekannte Schwachstelle den Serverinhalt verschlüsseln und Lösegeld fordern. Böse gesagt sind die Emails damit immerhin vor dem Zugriff durch die ursprünglichen Angreifer geschützt, aber defacto ist spätestens ab diesem Zeitpunkt ein Neuaufsetzen des Systems unumgänglich, verbunden mit den entsprechenden Verfügbarkeitseinschränkungen für die Benutzer:innen.

Einspielen der Patches

Jetzt wird es spannend: Ein Patch steht bereit und kann durch die Systemverantwortlichen eingespielt werden. Man sollte ja meinen dass dies, gerade bei einem so kritischen Fehler wie hier, innert Stunden erfolgen würde. Warum also ist die Rede davon dass dies Tage und Wochen dauern wird?

• Teilweise haben Hersteller fixe Termine an denen sie Patches zur Installation freigeben (“Patch Tuesday”, “Quarterly Quality Release” etc.). Das ist normalerweise durchaus im Sinne der Kunden für welche fixe Termine Planungssicherheit bieten. Bei Notfällen sind solche Termine hingegen eher hinderlich.
• Aller Presse zum Trotz ist noch lange nicht allen Systemverantwortlichen die Kritikalität bewusst, sie schieben die Sache auf die lange Bank
• In grösseren Organisationen werden Hersteller-Patches zuerst auf Test-Systemen eingespielt um zu vermeiden, dass fehlerhafte Patches den Betrieb lahmlegen.
• Unter Umständen ist das Unternehmen mit dem Einspielen von Updates im Rückstand und muss zuerst mal all diese nachfahren bevor der Patch überhaupt installiert werden kann
• Allenfalls ist sogar eine alte Version der Software im Einsatz welche zwar die Lücke enthält aber offiziell nicht mehr vom Hersteller supported wird. Und wo man dann die Wahl zwischen einem überstürzten Upgrade und dem Abschliessen eines erweiterten Supportvertrags hat (letzteres nur falls der Hersteller sich drauf einlässt).

All diese Dinge brauchen Zeit, bei all diesen Dingen kann auch was schiefgehen. Die Lücke bleibt da dann halt weiterhin offen.

Was bedeutet das nun für die nächsten Jahre?

Wir erleben ein Zusammenspiel von

• kreativen Angreifern welche von jeder gefundenen Lücke profitieren,
• komplexer, oft über die Zeit gewachsener IT-Infrastruktur deren Zusammenhänge oft nicht mal vom Hersteller vollständig verstanden werden,
• Software-Anbieter welche im Spagat zwischen Stabilität und Funktionalität (zu) oft auf zweiteres setzen weil sich das besser verkaufen lässt
• Anwendern/Unternehmen welchen oft das Wissen fehlt um die eigenen Systeme sicher zu betreiben

Es ist daher nicht anzunehmen, dass dies die letzte ausgenutzte Zeroday-Lücke dieser Art war (es ist sogar eher anzunehmen, dass es noch unzählige davon gibt welche bisher entweder nicht ausgenutzt wurden oder deren Ausnutzung noch niemandem auffiel). Was könnte das aus Nutzer-Sicht bedeuten?

• Der Aufwand zur Absicherung und zum Aktuell halten von aus dem Internet erreichbaren Applikationen und Servern wird weiter zunehmen. Theoretisch können Hersteller hier durch entsprechende Produktgestaltung Gegensteuer geben, also zum Beispiel ihre Applikationen so bauen dass die einzelnen Funktionsbereiche besser voneinander getrennt sind und dass Updates einfacher eingespielt werden können. Praktisch gesehen ist es für die Anbieter aber lohnenswerter, ihre Cloud-Angebote auszubauen und die Kundenbindung über diese zu erhöhen. Ob Cloud-Lösungen für die Nutzer:innen dann effektiv ein Segen ist oder ob man ein Problem gegen ein anderes austauscht?
• Unternehmen sind heute schon auf funktionierende und sichere IT angewiesen, sie werden es in Zukunft noch mehr sein. Damit verbunden dürften auch die IT-Ausgaben eher ansteigen (oder, andersrum gesagt: wer bei den IT-Ausgaben spart der spart sich vielleicht früher oder später aus dem Geschäft)
• Gänzlich unbekanntes Territorium sind und bleiben IoT-Produkte. Zu den oben beschriebenen Problemen kommen noch deren völlig unüberwachte Einsatz (wer wertet schon die Fehlerlogs seiner Internet-Kamera oder seiner Heizungssteuerung aus) verbunden mit der oft mangelhaften Updatefähigkeit, da Hersteller lieber neue Produkte verkaufen als bestehende updaten. Da werden noch einige Überraschungen auf uns zukommen