FAQ: Sicherheitslücken bei Microsoft Exchange-Mail-Servern

Stand: 18.03.2021


Nach dem Bekanntwerden der Sicherheitsproblematik rund um Microsoft Exchange Server gingen beim BayLDA zahlreiche Anfragen von Verantwortlichen ein, die Hintergründe und weitere Vorgehensweisen zum Sachverhalt abklären wollten. Aufgrund der sehr hohen Anzahl an betroffenen Verantwortlichen kann mittlerweile keine tiefgreifende Individualberatung hierzu mehr stattfinden. Das BayLDA etablierte stattdessen einen Frage-und-Antwort-Bereich (FAQ) auf seiner Website gerade für die Verantwortlichen, die zu diesem Thema noch Datenschutzfragen haben. Die Basis dazu wurde gemeinsam mit dem Bayerischen Landesbeauftragten für den Datenschutz (BayLfD), der parallel Meldungen aus dem öffentlichen Bereich erhält, geschaffen und abgestimmt. Sollten weitere, darüber hinausgehende Fragen vorhanden sein, ist der Online-Service zur Beratung zu verwenden.

Frage Um welche Sicherheitsproblematik handelt es sich?

Antwort Durch Informationen von Microsoft und des Bundesamts für Sicherheit in der Informationstechnik (BSI) wurde Anfang März 2021 bekannt, dass vier Zero-Day-Sicherheitslücken in Microsoft Exchange Servern existieren. Diese Lücken machen Unternehmen oder andere Verantwortliche über das Internet angreifbar, sobald sie Microsoft Exchange Server unter einer bestimmten Konfiguration einsetzen. Das BSI stufte diese Sicherheitslücken als kritisch ein und informierte darüber, dass sie bereits flächendeckend aktiv ausgenutzt werden, wodurch die Wahrscheinlichkeit der Kompromittierung der betroffenen Systeme als realistisch anzusehen ist.
Den bayerischen Datenschutzaufsichtsbehörden liegen bereits unzählige Nachweise und entsprechend viele Meldungen dafür vor (Zeitraum von 09.03.2021 bis 17.03.2021 mehr als 750). Es handelt sich somit um keine abstrakte, sondern um eine akute Gefährdung, bei der zeitnahes Handeln erforderlich war und ggf. noch ist. Microsoft stellt sowohl Patches zum Schließen der Sicherheitslücken zur Verfügung als auch Anleitungen und Möglichkeiten, den eigenen Server gezielt auf eine Infektion hin zu prüfen. Das BSI bietet zudem Unterstützung zur Detektion und Reaktion.

Frage Was kann bei einem Angriff passieren und welche personenbezogenen Daten könnten betroffen sein?

Antwort Bekannt ist, dass Angreifer über die Schwachstellen meist eine Webshell auf den betroffenen Systemen einrichten, um aus der Ferne (Remote) Befehle auf dem System ausführen zu können. Damit erlangen sie potentiell Zugriff auf sämtliche Daten des angegriffenen Exchange Servers – mit den damit verbundenen Rechten des Servers im Netz des Verantwortlichen. E-Mail-Postfächer und Adressbücher können somit ausgelesen und gesteuert werden. Gezielte Schadcode-Infektionen und nachgelagerte Cyberattacken sind außerdem zu befürchten, wenn der verwundbare Server nicht (zeitnah) gepatcht wurde bzw. auf nachgelagerte Sicherheitsscans nach Patchen verzichtet wurde. Mittlerweile ist nach den aktualisierten Erkenntnissen des BSI und Microsoft davon auszugehen, dass es möglich ist, das in Einzelfällen auch Ransomware zur Verschlüsselung von Daten ein neues Angriffsmittel sein kann.

Frage Welche Systeme sind durch die Sicherheitslücken eigentlich gefährdet?

Antwort Potentiell gefährdet sind Server mit selbst betriebenen Exchange Servern 2013, 2016 oder 2019 (sog. On-Premise-Systeme), falls diese über das Internet mit Verbindungen auf Port 443 ohne zusätzliche Sicherheitsvorkehrungen erreichbar waren. Exchange Server, die dabei nur per VPN erreichbar waren und andere, nicht-vertrauenswürdige Verbindungen blockierten, sind demnach nicht durch die bekannten Schwachstellen gefährdet.

Frage Wie kann man feststellen, ob der eigene Exchange Server betroffen ist?

Antwort Zunächst ist die Version und das Patch-Level des Microsoft Exchange Servers zu prüfen, damit erkannt wird, ob überhaupt die Grundvoraussetzung für das Vorliegen der Schwachstellen gegeben war. Betroffen sind laut Microsoft und BSI folgende Exchange-Server-Versionen:

  • Exchange Server 2010 (RU 31 für Service Pack 3)
  • Exchange Server 2013 (CU 23)
  • Exchange Server 2016 (CU 19, CU 18)
  • Exchange Server 2019 (CU 8, CU 7)
Anschließend ist zu untersuchen, ob die bisherige Konfiguration eine Verwundbarkeit verursachte (u. a. Verbindungen über Port 443 ohne VPN).
Ein zentraler Schritt ist die Überprüfung der Logfiles des Exchange Servers auf die bekannten Indicators of Compromise, um unbefugte Zugriffe schnell zu erkennen. Entsprechende Hilfestellung mit einzelnen Schritten bieten das BSI und Microsoft an:
Zudem sind auch in der Praxishilfe des BayLDA und des BayLfD "Microsoft Exchange Security Check & Incident Response" die wesentliche Punkte aufgeführt.

Frage Welche Maßnahmen müssen ergriffen werden, wenn man als Verantwortlicher betroffen ist, d. h. der Exchange Server verwundbar war oder noch ist?

Antwort Besteht Gewissheit, dass der eigene Server potentiell verwundbar war, empfiehlt sich Folgendes:
Im Rahmen der akuten Gefährdungslage erfolgen die meisten Angriffe über HTTPS-Zugriffe auf TCP-Port 443 zu Exchange Servern. Aus diesem Grund sollten zunächst diese Außenverbindungen geschlossen werden, um diesen Angriffsvektor aktiv zu unterbinden.
Anschließend sind die Patches zu nutzen. Microsoft hat dafür entsprechende Sicherheitsupdates bereitgestellt, die umgehend zu installieren sind. Da diese Updates ggf. nur für Server zur Verfügung stehen, auf denen auch die aktuellsten Updates laufen, ist es wichtig, dass bei allen Servern die aktuellsten Updates zeitnah installiert werden, um so die Sicherheitslücke zu schließen. Gerade nicht aktuell gehaltene Server sind ansonsten höchst problematisch. Beim Einspielen der Updates sind die Anleitungen und Hinweise von Microsoft zu beachten.
Nach erfolgreichem Einspielen der Patches muss zwingend bedacht werden, dass betroffene Organisationen in der Zwischenzeit angreifbar waren und durch das Patchen alleine mögliche vorherige Schadcodeinfektionen nicht bereinigt wurden. Die eingespielten Updates blockieren zwar die bekannt gegebenen Angriffswege, lassen jedoch bereits geschehene Cyberattacken nicht rückgängig machen. Entsprechend müssen Verantwortliche auch prüfen, inwieweit Unregelmäßigkeiten im Betrieb festzustellen sind. Die Erkenntnisse der bayerischen Datenschutzaufsichtsbehörden zeigen bislang: Viele verwundbaren Server zeigen tatsächlich Webshells und andere Merkmale unbefugter Zugriffe auf (z. B. auf das Adressbuch), die sich auch nach dem Patchen feststellen haben lassen. Die Wahrscheinlichkeit, dass Angreifer sich verwundbare Systeme annahmen und die Sicherheit der Verarbeitung gefährden, ist daher als erhöht anzusehen.
Um Verantwortliche bei der Aufarbeitung zu unterstützen, hat das BayLDA mit dem BayLfD eine Praxishilfe "Microsoft Exchange Security Check & Incident Response" bereitgestellt.

Frage Muss eine Kompromittierung des Exchange Servers durch das Ausnutzen dieser Sicherheitslücken gemäß Art. 33 DS-GVO von einem Verantwortlichen gemeldet werden?

Antwort In der Regel: Ja. Jedoch sollte allen Datenschutzbeauftragten bewusst sein, dass nicht Sicherheitslücken als solche gemeldet werden müssen, sondern Datenschutzverletzungen nach bestimmten Kriterien. Eine solche Meldung an die zuständige Datenschutzaufsichtsbehörde gemäß Art. 33 DS-GVO ist nämlich immer dann notwendig, wenn es (z. B. aufgrund von Sicherheitslücken bei einem System) zu einer Verletzung der Sicherheit personenbezogener Daten gekommen ist – es sei denn, dass die Verletzung des Schutzes personenbezogener Daten voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Diese Meldeverpflichtung ist für Datenschutzbeauftragte kein Neuland, sondern bereits seit Anwendbarkeit der DS-GVO bekannter Alltag und wird in vergleichbaren Fällen gleichermaßen praktiziert.
In der vorliegenden Konstellation zu Microsoft Exchange, bei der kriminelle Angreifer gezielt und automatisiert nach verwundbaren, über das Internet leicht erreichbaren Exchange Server suchen, besteht in einer Vielzahl an Fällen eine solche Meldeverpflichtung für verwundbare Server, da Erkenntnisse (siehe BSI) vorliegen, dass massenhaft – teils automatisiert – unbefugte Zugriffe mit Schadensabsicht stattfanden/stattfinden und dann jeweils eine Kompromittierung, oftmals eben mit Risiko für die betroffenen Personen, gegeben ist. Häufig lassen sich entsprechende unbefugte Zugriffe in kurzer Zeit durch den Verantwortlichen selbst nachweisen, da entsprechende Verfahren nach Art 32 DS-GVO etabliert sind und bspw. Log-Files strukturiert ausgewertet werden können.
Im Einzelfall kann eine Meldung nicht erforderlich sein, falls Zugriffe (= Angriffe) ausgeschlossen werden können, kein personenbezogenen Daten betroffen waren (z. B. bei Testsystemen oder sog. Honeypots) oder ein Risiko für die Rechte und Freiheiten natürlicher Personen auszuschließen ist (kein Risiko/geringes Risiko). Die für den Verzicht einer Meldung maßgeblichen Feststellungen, d. h. insbesondere die kompletten Untersuchungen des Mail-Servers und seiner Verbindungen ins übrige Netzwerk des Unternehmens, sind Im Rahmen der Rechenschaftspflicht zum Nachweis der technischen und organisatorischen Maßnahmen nach Art. 32 DS-GVO umfassend zu dokumentieren.
Ergänzend bleibt hier der Hinweis, dass stets die Möglichkeit besteht, dass Webshells und andere Spuren unbefugter Zugriffe womöglich zwischenzeitlich wieder von Angreifern entfernt oder verwischt wurden. Gerade bei einer professionellen Angreiferinfrastruktur drohen dann bereits tiefergehende Eingriffe in das eigene Netzwerk. Technische Analysen im Rahmen der Aufarbeitung und daraus zu ziehende Schlussfolgerungen sind dementsprechend sorgfältig durchzuführen.
Letztendlich bleibt die technische Ausgangslage im Exchange-Sachverhalt zu berücksichtigen:

  • Die Schwachstellen wurden öffentlich bekannt.
  • Die Schwachstellen sind mit CVSS-Scores von bis zu 9.1 als kritisch zu bewerten (siehe BSI).
  • Die Angriffsmethodik wurde öffentlich bekannt.
  • Das massenhafte, teil automatisierte globale Ausnutzen der Schwachstelle wurde bekannt.
  • Die verwundbaren Server waren/sind über das Internet erreichbar.
  • Die verwundbaren Server sind i. d. R. ein wichtiger Bestandteil zur Verarbeitung personenbezogener Daten der jeweiligen Organisation.
  • Die verwundbaren Server finden sich zum Teil in öffentlichen Datenabfragen (u. a. Shodan).
  • Eine hohe Warnstufe durch nationale Sicherheitsbehörden wurde ausgerufen (u. a. BSI, CISA).
  • Das BSI hat aufgrund der Gefährdung Firmen nach der öffentlichen Warnung auch aktiv angeschrieben.
  • Deutsche Datenschutzaufsichtsbehörden erhalten unzählige Nachweise, dass deutsche Unternehmen und andere Verantwortliche kompromittierte Server feststellen (u. a. BayLDA, BayLfD).
In diesem Kontext stellt sich die Frage, wie realistisch es ist, dass ein erreichbarer, verwundbarer Server nicht (automatisiert oder manuell) angegriffen wurde – sei es als bewusstes Ziel oder als Beifang. Die bayerischen Datenschutzaufsichtsbehörden gehen daher seit Bekanntwerden vielmehr davon aus, dass entscheidender die Frage ist, welche Kompromittierung des Exchange-Servers und weiterer Systeme tatsächlich stattgefunden hat, um mögliche negative Folgen für den eigenen Systembetrieb aktiv abzufangen und auch die Frage der Meldeverpflichtung zu klären. Möglich ist durchaus, dass bei einzelnen Verantwortlichen durch individuelle Sicherheitsmaßnahmen Zugriffsversuche aktiv geblockt und somit erfolglos blieben – in diesem Fall beständen kein Risiko und keine Meldeverpflichtung.
Kommt man nach der Überprüfung der eigenen Systeme zu dem Schluss, dass die Sicherheitslücke (mit hinreichender Wahrscheinlichkeit) ausgenutzt wurde, ist im Regelfall eine Meldung bei der jeweils zuständigen Datenschutzaufsichtsbehörde zu tätigen – es sei denn, ein Risiko für die betroffenen Personen ist auszuschließen (bzw. gering).
Bayerische Verantwortliche aus dem nicht-öffentlichen Bereich nutzen hierfür den Online-Service des BayLDA unter https://www.lda.bayern.de/datenschutzverletzung.
Meldungen aus dem öffentlichen Bereich in Bayern sind beim Bayerischen Landesbeauftragen für Datenschutz einzureichen: https://www.datenschutz-bayern.de/service/data_breach.html

Frage Muss der Verantwortliche die betroffenen Personen gemäß Art. 34 DS-GVO benachrichtigen?

Antwort Die Frage kann nicht pauschal beantwortet werden. Falls aufgrund der Sicherheitslücke von einem hohen Risiko für die betroffenen Personen ausgegangen wird, müssen diese gemäß Art. 34 DS-GVO umgehend benachrichtigt werden. Eine generelle Einschätzung, ob ein solches hohes Risiko besteht, ist nicht möglich, sondern verlangt stattdessen eine umfassende Berücksichtigung der betroffenen Datenarten, der jeweiligen Sicherheitsverletzung und der konkreten Umstände der eigentlichen Verarbeitung.
Dabei müssen die eigenen Systeme und die Rahmenbedingungen zur Datenverarbeitung überprüft werden, um einschätzen zu können, ob durch die Sicherheitslücke Daten kompromittiert wurden, bei denen sich beispielsweise durch die Offenlegung für die Betroffenen ein hohes Risiko ergibt. Auch durch eine gezielte Datenmanipulation oder durch Ausfall zentraler Verarbeitungsdienste kann das Risiko für betroffene Personen jeweils wesentlich beeinflusst werden.

Frage Besteht eine Meldeverpflichtung alleine durch das Vorhandensein von Sicherheitslücken (d. h. ohne Kompromittierung) bzw. durch ein verspätetes Einspielen der Updates?

Antwort Nein. Wie in den vorherigen Antworten ausführlich beschrieben, sind dafür die Voraussetzungen aus Art. 33 DS-GVO zu erfüllen (u. a. Datenschutzverletzung nach DS-GVO und Risiko für betroffene Personen).
Das BayLDA und der BayLfD gehen ohne Kompromittierung eines Systems nicht per se von einer Meldepflicht aus – dies war auch in vergangenen, vergleichbaren Sachverhalten die Einschätzung der Behörden. Allerdings lassen die technischen Erkenntnisse in der konkreten, außergewöhnlichen Gefährdungslage der Sicherheitslücken des Exchange-Servers Rückschlüsse zu, dass, falls Updates verspätet eingespielt wurden, die Wahrscheinlichkeit einer Kompromittierung so hoch ist, dass von einer solchen auszugehen ist und entsprechend eine Meldeverpflichtung nach Art. 33 DS-GVO greift. Die Meldungen, die beim BayLDA und beim BayLfD bereits eingegangen sind, belegen diese technischen Schlussfolgerungen. Details zur Argumentation finden sich weiter oben in der Antwort zur Meldeverpflichtung nach Art. 33 DS-GVO.
Wenn die Server erst spät gepatcht wurden, ist mit einer hinreichenden Wahrscheinlichkeit davon auszugehen, dass diese Lücke ausgenutzt wurde und demnach ein Risiko für die betroffenen Personen nicht auszuschließen ist (Grob gilt: Je größer der Zeitraum bis zum Patchen, desto größer die Wahrscheinlichkeit der Ausnutzung – wenngleich das Ausnutzen solcher Lücken meist bereits innerhalb weniger Stunden automatisiert stattfinden kann). Aus diesem Grund gehen die bayerischen Datenschutzaufsichtsbehörden auch in dieser Konstellation davon aus, dass der Vorfall der zuständigen Datenschutzaufsichtsbehörde in der Regel gemeldet werden muss. Eine ausführlichere Einschätzung zur Meldeverpflichtung ist in der Praxishilfe "Microsoft Exchange Security Check & Incident Response" zu finden.

Frage Es ist kein Datenfluss erkennbar – besteht trotzdem eine Meldeverpflichtung?

Antwort Hier kommt es darauf an, ob die Fähigkeit, die Vertraulichkeit, Integrität, Verfügbarkeit der Systeme und Dienste im Zusammenhang mit der Verarbeitung, hier konkret der Exchange Server und der damit verbundenen Infrastruktur, nach Art. 32 Abs. 2 DS-GVO weiter sichergestellt werden kann oder ob eben eine Kompromittierung vorliegt/vorlag, die diese gefährdet. Ein Risiko für die betroffenen Personen kann sich nicht nur durch einen Datenabfluss ergeben, sondern bspw. auch durch eine gezielte Manipulation von personenbezogenen Daten. Diese Einschätzung ist ebenfalls nicht neu, sondern bezieht sich auf alle datenschutzrechtlichen Vorfälle in Bezug auf Art. 32-34 DS-GVO.
Wichtig dabei sollte bleiben: Verantwortliche müssen nach Art. 32 Buchstabe d DS-GVO ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung praktizieren bzw. etablieren. Bei Verantwortlichen sollten also die Voraussetzungen vorhanden sein, zeitnah überprüfen und bewerten zu können, ob und welche Kompromittierung vorlag. Mögliche Haltungen wie "Updates seien verspätet eingespielt worden, man könne aber nicht sagen, ob eine Kompromittierung vorlag" werfen Fragen auf, ob nicht nur das Patch Management unzureichend ist, sondern auch solch grundlegenden, essentiellen Verfahrensweisen für einen sicheren IT-Betreib bei der Verarbeitung personenbezogener Daten fehlen (u. a. Incident Response). Letztendlich bleibt stets eine detaillierte Einzelprüfung für Verantwortliche erforderlich, um festzustellen, ob und welcher Schaden eingetreten ist und welche Folgen sich dadurch datenschutzrechtlich ergeben.
Nachweisbare forensische Analysen nach Art. 5 Abs. 2 DS-GVO können durchaus ergeben, dass z. B. trotz Webshell keine weitere Kompromittierung stattgefunden hat und die Risikobewertung zum Ergebnis kommt, dass keine Meldevoraussetzungen nach Art. 33 DS-GVO gegeben sind.

Frage Was prüft das Bayerische Landesamt für Datenschutzaufsicht (BayLDA)?

Antwort Im Rahmen seiner Ad-hoc-Cybersicherheitsprüfung identifiziert das BayLDA potentiell anfällige Exchange Server in Bayern und kontaktiert anschließend deren Betreiber. Dabei werden stichprobenartig tausende Systeme hinsichtlich der beschriebenen Schwachstellen im Rahmen einer üblichen Online-Prüfung kontrolliert. Mehr als 250 Verantwortliche aus dem bayerischen, nicht-öffentlichen Bereich konnten dadurch über den Sachverhalt in Kenntnis gesetzt werden.

Frage Auf welcher rechtlichen Grundlage prüft das BayLDA derzeit die bayerischen Unternehmen?

Antwort Das BayLDA überwacht als Datenschutzaufsichtsbehörde nach Art. 58 DS-GVO die Einhaltung des Datenschutzrechts im nicht-öffentlichen Bereich im Bundesland Bayern und kann hierfür Kontrollen durchführen. Aufgrund der akuten Gefährdungslage unterstützen die Maßnahmen des BayLDA gefährdete Unternehmen bei der Wahrnehmung ihrer Verpflichtungen nach Art. 32 DS-GVO.
Online-Prüfungen dieser Art sind ebenfalls nicht neu und gehören zum üblichen Prüf-Repertoire einer Datenschutzaufsichtsbehörde: Das BayLDA hat im Laufe der Jahre mehrfach automatisiert Verantwortliche in der eigenen Zuständigkeit geprüft (u. a. Großprüfungen zu Google Analytics, Adobe Analytics, STARTTLS, Heartbleed, Magento-Online-Shops, WordPress-Websites, Cybersicherheit am Safer Internet Day).

Weitere Informationen