Fehlkonfiguration von Webservern – Wie kommt es zu Datenlecks?

Regelmäßig stößt man derzeit auf Meldungen, dass wieder einmal ein Webserver eines Unternehmens mit sensiblen Daten offen im Internet stand. Mit Glück fällt dies lediglich einem Ethical Hacker auf, der das Unternehmen informiert. Doch oft exfiltrieren Angreifer die Inhalte des Serverund Millionen von Kunden- oder Projektdaten landen in den Händen Unbekannter. Wie kommt es dazu und wie lassen sich solche Probleme verhindern?

Weitreichende Nutzung von Cloud-Dienstleistern

Heutzutage ist die Nutzung von größeren Datenspeichersystemen und Webservern für viele Unternehmen unabdinglich. Wo früher noch eigene Systeme den Anfragen standhalten mussten und konnten, treten – primär aus Gründen der Praktikabilität – seit Jahren zunehmend Lösungen von externen Anbietern an deren Stelle.

Nur die wenigsten Firmen können oder wollen dabei auf die Nutzung von externen Cloud-Anbietern oder auch Webservern verzichten. Dienste wie AWS oder Azure machen hier einen Großteil der genutzten Cloud-Technologien aus. Doch auch komplett selbstverwaltete Cloud- oder Webserver gehören noch zum Portfolio vieler Unternehmen. Die Nutzung der genannten Cloud-Dienste steigt in jedem Fall jährlich weiter an. Und es ist davon auszugehen, dass dieser Trend auch weiterhin anhält.

Doch die fehlerhafte Konfiguration eben solcher Server – oder meist vielmehr der zugeteilten Speicherbereiche (beispielsweise als Blobs oder Buckets bekannt) – kann zu gravierenden Problemen führen. Sehr regelmäßig hört man heute von Sicherheitsvorfällen, in denen selbst namhafte Unternehmen einen Webserver nicht richtig konfigurierten. Prompt stehen Unmengen von Daten öffentlich im Internet. Dies reicht dann von internen Daten, wie Quellcode von unternehmensinternen Projekten, bis hin zu Millionen von (mitunter sensiblen) Kundendaten.

Webserver, Bucket, Blob – worauf wird da eigentlich gearbeitet?

Um eines der vielgenutzten Konzepte anhand des Beispieles AWS einmal zu erläutern: Wird sich dazu entschieden, einen entsprechenden externen Clouddienstleister zu nutzen, wird für die Dateien oftmals ein sogenannter Bucket eingerichtet. Hierbei handelt es sich oft um einen dedizierten, abgekapselten und virtualisierten Speicherbereich, meist auf einem System (Server) des Dienstleisters. In spezifischen Fällen können Unternehmen aber auch vollständige Systeme oder Plattformen anmieten.

Dieser Bucket, in dem später die Daten enthalten sein sollen, erhält nun eine Kennung. Diese besitzt beispielsweise das Format

A.B.C.s3.amazonaws.com

Den ersten Teil – bis zum s3 – wählt man dabei selbst. Dieser muss global eindeutig sein. Die Kennung ist dann funktional weitgehend identisch zu einer regulären URL und erlaubt den Mitarbeitenden den Zugriff auf den Speicherbereich sowie die darauf liegenden Ressourcen.

Um nun auch damit arbeiten zu können, sind die Systeme im Regelfall über das Internet erreichbar. Normalerweise wird der sogenannte „public access“ (also beliebige Zugriffe von außen) hierbei automatisch blockiert. Wird der Bucket anschließend aber falsch konfiguriert, kann unter Umständen jeder Nutzer die Inhalte an diesen Adressen einsehen, wenn man den entsprechenden Namen aufruft. Gleichzeitig finden in dieser Situation auch Seiten-Indizierungs-Bots (zum Beispiel die Bots von Google) diese Buckets und zeigen die Inhalte bei Internetsuchen an – wie auch normale Internetseiten.

Die Gefahr kommt von überall – und die Datenlecks mit ihnen

Hierbei wird oft der Fehler gemacht, anzunehmen, dass man ohne das passende Hintergrundwissen einen solchen Zugang schon nicht findet. Dies mag manchen dazu verleiten, proaktiv den Zugang für einen konkreten Personenkreis oder die gesamte Öffentlichkeit freizugeben. Vermeintlich ist dann die Nutzung lediglich für andere bekannte Personen erlaubt – oder das System wird zum Hosten genutzt. Doch falsche Einstellungen können hier schnell dafür sorgen, dass auch Nutzer Zugriffe erhalten, die nicht vorgesehen waren.

Ist ein solcher Server oder Speicherbereich dann erstmal falsch konfiguriert, kann ein Angreifer in der Lage sein, sämtliche dort abgelegten Daten einzusehen und auch herunterzuladen. Im schlimmsten Fall ist sogar ein Account mit Administrator-Rechten ohne eine Authorisierung verfügbar. Dann können Angreifer auf nahezu beliebige Daten und Ressourcen zugreifen, herunterladen, im schlechtesten Fall auch löschen oder Einstellungen verändern. Doch wie soll ein Angreifer den Storage denn überhaupt finden?

Für viele Angriffsvektoren sind Fehlkonfigurationen die Basis

Tatsächlich gibt es einige Möglichkeiten, offene Webserver oder Cloud-Storages zu suchen oder einzusehen. So gibt es beispielsweise gut auffindbare Datenbanken, die offene Storage-Systeme auflisten und aktuell halten. Auch kann man mithilfe des sogenannten „Google Dorkings“ aufgrund der vorhin benannten Seiten-Indizierung in Suchmaschinen nach entsprechenden Storage-Namen suchen. Nicht unerwähnt bleiben soll hier ebenfalls der Klassiker des IP-Bereich-Scans.

Natürlich kann ein Angreifer auch beliebige Wortkombinationen testen, um einen passenden Storage zu finden. Das funktioniert insbesondere, falls Teile der verwendeten Namen bereits bekannt sind und für mehrere Strukturen oder Buckets verwendet werden. Und für bekannt gewordene Namen mehrerer Speicherorte gibt es Scanner-Programme, die prüfen können, wieviel Zugriff diese von außen tatsächlich erlauben.

Das meiste davon ist ohne größere technische Kenntnisse möglich und auch schwer belangbar. Denn erst der tatsächliche Zugriff auf solche Geräte kann im Allgemeinen gut verfolgt werden – doch Auflistungen solcher Geräte sind an vielen Stellen aufzufinden und meist ohne Konsequenzen einsehbar. Auf diese Weise könnten sich Angreifer also über beliebige offene Server informieren. Sind die gesammelten Informationen ausreichend, ist ein Angriff auf die erfolgsversprechenderen Systeme dann oft ein Leichtes. Da es sich kaum verhindern lässt, dass Geräte, die nunmal offen im Internet stehen, auch einsehbar sind, liegt es also an den dafür zuständigen IT-Kräften, eine sichere Konfiguration einzurichten. Wo genau liegt also der Haken?

Wie man die Fehlkonfigurationen von Webservern verhindert

Die Konfigurationen sind dabei natürlich abhängig vom verwendeten Dienstleister. Für jeden Dienstleister und Anwendungsfall würde eine genaue Anleitung hier den Rahmen sprengen und möglicherweise auch dem Lauf der Zeit nicht standhalten. Jedoch bieten Dienstleister üblicherweise selbst Hilfestellungen an, wie man ihre zur Verfügung gestellten Dienste absichert. Hierfür reicht meist eine Recherche zum Thema „Absicherung“ (oder dem englischen Äquivalent) für das Storage-Konzept des verwendeten Anbieters.

Konkret für primär eigene Webserver veröffentlicht darüber hinaus das BSI jährlich eine Richtlinie (APP 3.2. Webserver), um die Sicherheit der Daten zu gewährleisten. Allgemein lässt sich jedoch festhalten, dass es in den meisten Fällen unterschiedliche „Access Level“, also Zugriffsebenen, gibt, die alle überprüft werden müssen. Andernfalls kann es passieren, dass trotz vermeintlich richtig eingestellter Konfigurationen dann doch einzelne Objekte oder ganze Buckets durch die Prüfung rutschen. Daher sollte man die meisten darüber- wie darunterliegenden Ebenen (bspw. Buckets vs. einzelne Objekte) genau überprüfen.

Insbesondere für externe Storage-Anbieter lassen sich folgende, allgemeine Empfehlungen aussprechen:

• Beschränken Sie die Anzahl an Speicherorten mit öffentlich erlaubtem Zugriff auf ein Minimum. Speichern sie auf denjenigen, auf denen dieser Zugriff möglich sein muss, keine sensitiven Daten.
• Versuchen Sie generell, die Zugriffsrechte auf das geringste (zum Arbeiten nötige) Level zu limitieren.
• Bereinigen Sie auch frühere Datensätze, besonders falls diese offen im Netz stehen oder ohnehin nicht mehr benötigt werden.
• Wenn bestimmte Nutzer Zugriff auf einen Speicherbereich haben dürfen, der öffentlich zugänglich ist, sollten Sie dafür sorgen, dass diese Personen informiert und ausreichend geschult sind.

Die Notwendigkeit der korrekten Einstellungen für Speicherorte

Letzten Endes ist es für alle Seiten – das Unternehmen selbst, seine Mitarbeiter und auch seine Kunden – von größter Wichtigkeit, Server zu schützen. Das gilt besonders für solche, die sensible Daten beinhalten. Berechtigungen für unauthorisierten Accounts oder Personen, sind auf ein Minimum zu beschränken. Das ist unabhängig davon, für wie wahrscheinlich man es hält, dass das zugehörige Medium überhaupt bekannt wird. Denn wenn das Schlachtfeld der IT-Sicherheit einen Umstand mit Gewissheit kennt: Zwischen öffentlich einsehbaren Ressourcen – und vielleicht sogar konkret Ihren – und einem Angreifer steht meist nur ein wenig Zeit. Doch der dadurch verursachte Schaden, gerade in diesem Fall, ist oft immens. Und das ließe sich mit etwas akribischerer Prüfung der genutzten Speicherorte sicherlich verhindern.