≡ Sitemap

Der Bayerische Landesbeauftragte für den Datenschutz; Stand: 15.03.2021

FAQ: Sicherheitslücken bei Microsoft Exchange-Servern

Um welche Sicherheitsproblematik handelt es sich?

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.

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

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.

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

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.

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

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" die wesentliche Punkte aufgeführt.

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

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.

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

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 DSGVO 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 DSGVO 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 DSGVO 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 DSGVO 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 (externer Link).

Meldungen aus dem öffentlichen Bereich in Bayern sind beim Bayerischen Landesbeauftragen für Datenschutz einzureichen: https://www.datenschutz-bayern.de/service/data_breach.html.

Muss der Verantwortliche die betroffenen Personen gemäß Art. 34 DSGVO benachrichtigen?

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 DSGVO 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.

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

Nein. Wie in den vorherigen Antworten ausführlich beschrieben, sind dafür die Voraussetzungen aus Art. 33 DSGVO zu erfüllen (u. a. Datenschutzverletzung nach DSGVO 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 DSGVO 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 DSGVO.

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.

Es ist kein Datenfluss erkennbar - besteht trotzdem eine Meldeverpflichtung?

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 DSGVO 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 DSGVO.

Wichtig dabei sollte bleiben: Verantwortliche müssen nach Art. 32 Buchstabe d DSGVO 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 DSGVO 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 DSGVO gegeben sind.

Weitere Informationen