Man sagt, dass Programmieren der Magie am nächsten kommt, die wir heute haben. Und wissen Sie was? Sie haben Recht. Mit ein paar Zeilen Code, die für Uneingeweihte wie Kauderwelsch aussehen, kann man ganze Welten erschaffen. Wie kann das etwas anderes als Magie sein?
Auf der anderen Seite kann man mit ein paar verschiedenen Codezeilen die kompliziertesten Sicherheitssysteme schaffen. Aber je komplizierter sie sind, desto schwieriger sind sie zu knacken. Hier kommen die Software-Sicherheitsbedrohungen ins Spiel. Bedrohungen wie eine falsche Sicherheitskonfiguration machen große und kleine Systeme anfällig für alle Arten von Cyberangriffen.
Aber ist eine falsche Sicherheitskonfiguration die größte Bedrohung? Und was verbirgt sich überhaupt hinter diesem, ehrlich gesagt, etwas vagen Begriff? Lesen Sie weiter, um das herauszufinden.
Fehlkonfiguration der Sicherheit: Erläuterung, Beispiele, Prävention
Sicherheitskontrollen, die unsicher oder falsch konfiguriert sind, wodurch die Daten und manchmal sogar das gesamte System gefährdet werden. Im Klartext: Jedes technische Problem in einer beliebigen Komponente, das auf die Konfigurationseinstellungen der Anwendung und nicht auf fehlerhaften Code zurückzuführen ist, kann als Sicherheitslücke durch Fehlkonfiguration eingestuft werden.
Verpfuschte Standardeinstellungen, schlampig dokumentierte Konfigurationsänderungen, falsche Berechtigungen – sie alle fallen unter diesen Begriff.
Die häufigsten Sicherheitslücken entstehen in der Regel durch die einfachsten Fehler (wie die unten aufgeführten Beispiele). Aber die Folgen, die diese Fehler für Unternehmen mit sich bringen, sind keineswegs einfach. Von der Offenlegung sensibler Daten bis hin zur vollständigen Übernahme von Servern, Webseiten und Anwendungen hat eine falsche Sicherheitskonfiguration in der Vergangenheit unzähligen Unternehmen schweren Schaden zugefügt. Und wenn man bedenkt, dass diese Bedrohung im letzten Jahr auf Platz 5 der Top-10-Sicherheitsrisiken für Webanwendungen von OWASP landete, wird sie auch in Zukunft nicht verschwinden. Sie können also beten, dass es Sie nicht erwischt, oder Sie können mehr über Sicherheitsfehlkonfigurationen erfahren, einschließlich der Frage, wie man sie verhindern und verwalten kann.
Klingt gut? Dann nichts wie los.
Wie es zu Sicherheitsfehlkonfigurationen kommt
Wie wir bereits gelernt haben, gibt es komplexere und ungewöhnlichere Gründe für eine Sicherheitslücke, aber auch einige unglaublich einfache und häufige. Zu letzteren gehören:
Debugging aktiviert
Die meisten Unternehmen arbeiten mit getrennten Umgebungen. Stellen Sie sich Folgendes vor: Sie aktivieren das Debugging in einer Entwicklungsumgebung, um den Debugging-Fortschritt zu beschleunigen. Nichts Ungewöhnliches, oder?
Aber es ist auch nichts Ungewöhnliches, wenn man vergisst, diese kleine Funktion vor der Produktionsphase zu deaktivieren. Die Angreifer müssen dann nur noch die ausführlichen Fehler auslösen, die interne Daten enthalten, und schon sind sie IN.
Standard-Anmeldeinformationen
Oftmals eine triviale Angelegenheit, aber auch Standard-Anmeldeinformationen können manchmal schwerwiegenden Schaden anrichten. Und in neun von zehn Fällen ist eine falsche Sicherheitskonfiguration der Schuldige dafür.
Standard-Anmeldeinformationen werden in der Regel mit einer Vielzahl integrierter Lösungen ausgeliefert. Diese finden sich in Webanwendungen, verschiedenen Netzwerkgeräten und so ziemlich allem, was eine Authentifizierung erfordert. Und wenn Sie diese nach der Installation nicht ändern, öffnen Sie damit die Türen weit auf. Und, wer hätte es gedacht, die ersten, die durch diese Türen gehen, sind in der Regel Hacker.
Falsch konfigurierte Berechtigungen
Nachlässigkeit. Es ist immer Nachlässigkeit. Aber ja, selbst die besten Entwickler vergessen manchmal, die richtigen Berechtigungen für exponierte (auch öffentliche) Verzeichnisse, Verwaltungskonsolen und Dashboards zu setzen. So können selbst die am wenigsten geschickten Hacker problemlos auf diese nicht autorisierten Dateien zugreifen.
Nun könnte man meinen, dass es sich hier um eine defekte Zugriffskontrolle handelt, aber das ist nicht der Fall. Nein, BAC ist das Ergebnis, aber der Schuldige ist ein Problem mit der Sicherheitskonfiguration. Es war schon vorhanden, bevor das Modul eine Funktion der Webanwendung erreicht hat, nur dass man es in der Regel erst in diesem Stadium herausfindet.
Cloud-Fehlkonfiguration
Die Cloud ist eine wunderbare Sache. Dank Cloud-Speicher- und Dateifreigabelösungen können sowohl kleine Unternehmen als auch Großkonzerne innerhalb von Minuten ganze Rechenzentren einrichten, ohne sich Sorgen machen zu müssen, dass sie nicht über die erforderlichen Ressourcen verfügen könnten.
Aber mit der großen Freiheit kommt die große… Sie kennen das Spiel. Darüber hinaus müssen die Unternehmen, die diese Lösungen nutzen, dem Modell der gemeinsamen Verantwortung folgen. Das heißt, was in der Cloud passiert, bleibt in der Cloud und liegt in der Verantwortung des Kunden, nicht der Eigentümer des Cloud-Dienstes.
Das bedeutet auch, dass es immer wieder zu Sicherheitsverletzungen aufgrund von Sicherheitsfehlern in der Cloud kommen wird, ob Sie es wollen oder nicht. Um Ihnen ein kurzes Beispiel für eine Sicherheitsfehlkonfiguration zu geben: Allein die Fehlkonfigurationen bei Amazon S3 führten zu über 400.000 Google-Ergebnissen, darunter auch Sicherheitsverletzungen bei den größten Unternehmen der Branche.
Hardware-Fehlkonfiguration
Auf der anderen Seite können Netzwerk- und andere Sicherheitsgeräte auch falsch konfiguriert werden, was sowohl im Nachhinein als auch von Anfang an zu echten Problemen führen kann.
Es kommt häufig vor, dass Netzwerktechniker bei der Konfiguration von Netzwerkgeräten ein wenig nachlässig sind. Und wir verstehen, dass die Behebung von Netzwerkproblemen sehr mühsam sein kann. Aber das ist kein Grund, die folgende Sicherheitskonfiguration zu vergessen.
Denn wenn Sie das nicht tun (oder nur halbherzig), haben Angreifer möglicherweise die Möglichkeit, auf interne Ressourcen zuzugreifen, Reverse Shells ohne Einschränkungen durchzuführen und vieles mehr. Außerdem können falsch konfigurierte Lösungen wie IPS, SIEM und IDS weitere Sicherheitslücken schaffen. Wenn Sie beispielsweise vergessen, während des Eingriffs eine Bind-Shell einzurichten, haben Hacker keine Probleme, Ihre Webseite zu verunstalten.
Und das sind nur einige Beispiele. Sicherheitslücken durch Fehlkonfigurationen entstehen auch durch:
- Aktivierung unnötiger (normalerweise standardmäßiger) Funktionen wie nutzlose Dienste, Konten, Berechtigungen, Ports, Seiten, usw.
- Arbeiten mit unsicheren Kopfzeilen und Verzeichnissen oder deren Einstellung auf unsichere Werte
- Übersehen der Sicherheitseinstellungen (d. h. auch NICHT auf sichere Werte setzen) in den App-Servern, App-Frameworks, Bibliotheken, Datenbanken usw.
- Verwendung anfälliger und/oder veralteter Komponenten (was übrigens auf der oben erwähnten Liste der 10 größten Sicherheitsrisiken für Webanwendungen von OWASP gleich hinter der Fehlkonfiguration liegt)
- Nichtimplementierung geeigneter Sicherheitsmaßnahmen für den gesamten Anwendungsstapel (so gut wie jeden Teil davon)
- Und, last but not least, das Nichtdeaktivieren von Standardkonten mit Standardpasswörtern (ja, ob Sie es glauben oder nicht, das passiert sehr oft).
Klingt ein wenig vage? Schauen wir uns ein paar Beispiele für Fehlkonfigurations-Angriffsszenarien an.
Mögliche Angriffsszenarien
Der Anwendungsserver wird mit Beispielanwendungen ausgeliefert, die noch nicht vom Produktionsserver entfernt wurden. Oftmals enthalten diese Beispielanwendungen bekannte Sicherheitslücken, die Angreifer ausnutzen können, um Ihren neuen Server zu kompromittieren. Angenommen, eine dieser Anwendungen ist eine Verwaltungskonsole mit aktivierten Standardkonten. In diesem Fall müssen die Hacker nur mit einem Standardpasswort auf diese Konsole zugreifen, und schon ist er der Kapitän.
Der Verzeichniseintrag wurde nicht deaktiviert. Auch dies ist kein ungewöhnliches Szenario, so unglücklich es auch ist. Hacker untersuchen Server in erster Linie auf diese Schwachstelle. Angenommen, sie entdecken, dass sie einfach Verzeichnisse auflisten können. Das ist zwar etwas komplizierter, aber erfahrene Angreifer werden dann keine Probleme haben, die kompilierten Java-Klassen zu finden und herunterzuladen. Von dort aus können sie diese Klassen dekompilieren und zurückentwickeln, um den Servercode einzusehen. An diesem Punkt ist das Auffinden einer kritischen Zugriffskontrollschwachstelle in der Anwendung eine Frage des Wann, nicht des Ob.
Der Anwendungsserver ist so konfiguriert, dass er detaillierte Fehlermeldungen (wie Stack Traces) an die Benutzer zurückgibt. In diesem Szenario können Sie alle Arten von zugrundeliegenden Fehlern offenlegen. Sicherlich sensible Informationen, aber auch die Komponentenversionen, die bekannte Schwachstellen aufweisen. Wenn sie diese herausfinden, gibt es für Hacker keine Grenzen, was sie mit Ihrem Server anstellen können. Und wie Sie sich denken können, brauchen sie nur diese detaillierten Fehlermeldungen anzufordern (und werden es wahrscheinlich auch tun), was ein Kinderspiel ist.
Die Cloud verfügt über Standardfreigabeberechtigungen, die von anderen Nutzern des Dienstes genutzt werden können (und für jeden verfügbar sind, der nett genug ist, danach zu fragen). Erinnern Sie sich an das Modell der gemeinsamen Verantwortung, das wir bereits erwähnt haben? Ja, das ist es. Es bedeutet, dass Sie es manchmal nicht einmal sein müssen. Es reicht aus, wenn einer Ihrer Cloud-Nachbarn vergisst, die Standardberechtigungen zu deaktivieren, und schon können Cyberkriminelle auf Ihre sensiblen Daten in diesem Cloud-Speicherdienst zugreifen. Je nach diesen Berechtigungen können Hacker sogar Zugriff auf das System auf höchster Ebene erhalten.
Denken Sie, dass dies nur Hypothesen sind, die im wirklichen Leben nicht vorkommen? Denken Sie anders.
Beispiele für Sicherheitsfehlkonfigurationen aus dem wirklichen Leben
Sicherheitsprobleme durch Fehlkonfigurationen sind so alt wie die Sicherheitsmaßnahmen selbst, so dass wir in der Vergangenheit unzählige Beispiele gesehen haben. Hier sind nur einige davon:
Der NASA/Jira-Vorfall
Man sollte meinen, dass eines der technologisch fortschrittlichsten und fortschrittsorientiertesten Unternehmen der Welt es besser wissen würde. Leider haben sie es nicht getan.
Es bedurfte nur eines bescheidenen Sicherheitsenthusiasten, um eine Sicherheitsfehlkonfiguration im größten (und vielleicht unbeliebtesten) Kollaborationstool der Welt – Jira – zu erkennen. Diese eine Fehlkonfiguration der Standardautorisierung machte mehrere Fortune-500-Unternehmen, darunter die NASA, angreifbar. Durch diese Sicherheitslücke konnten Dritte auf interne Benutzerdaten zugreifen, darunter Namen, E-Mail-IDs, Projektdetails und andere sensible Informationen.
Was war passiert? Als Jira Dashboards und Filter für einzelne Probleme oder ganze Projekte entwickelte, waren die Sichtbarkeitseinstellungen standardmäßig auf Alle Benutzer und Jeder eingestellt. Natürlich sollten Dinge wie Roadmap-Aufgaben idealerweise innerhalb des Unternehmens freigegeben werden, aber das “geliebte” Jira gab sie an die Öffentlichkeit weiter.
Wichtigste Erkenntnis: Stellen Sie sicher, dass Sie die Konfigurationen für die Dateifreigabe in jedem SaaS, das Sie verwenden, überprüfen, um zu vermeiden, dass vertrauliche Daten preisgegeben werden.
Amazon S3 Missgeschicke
Amazons Simple Storage Service, auch bekannt als Amazon S3, wurde schon öfter von Hackern missbraucht, als man zählen kann. Von dem falsch konfigurierten S3-Bucket, der 50.000 Patientendaten in den USA enthüllte, bis hin zu denjenigen, die über 80 US-Gemeinden offenlegten, verschonten die Angreifer niemanden.
Sogar das United States Army Intelligence and Security Command hat in der Vergangenheit mehrere sensible Dateien über Amazon S3 preisgegeben, darunter OVA-Volumes (Oracle Virtual Appliance), deren Teile als streng geheim gekennzeichnet waren.
Wichtigste Erkenntnis: Die Tatsache, dass Hunderte von Unternehmen (einschließlich Militär- und Regierungsbehörden) auf Amazon S3 vertrauen, bedeutet nicht, dass es sicher ist. In Anbetracht der Dutzenden von Sicherheitsvorfällen in der Vergangenheit sollten Sie die Autorisierung des Dienstes sorgfältig überwachen, wenn Sie sich für seine Nutzung entscheiden.
Wie man eine Fehlkonfiguration der Sicherheit verhindert
Erinnern Sie sich, wie es zu Sicherheitsfehlkonfigurationen kommt? Ja, genau das sollten Sie vermeiden. Mit anderen Worten:
Deaktivieren Sie das Debugging. Wenn Sie die Anwendung von der Entwicklungs- in die Produktionsphase überführen, stellen Sie sicher, dass Sie alle Debugging-Funktionen in der gesamten Konfiguration doppelt überprüfen. Das ist richtig, sie sollten ALLE deaktiviert werden.
Ändern Sie die Standard-Credentials. Das erste, was Sie nach der Installation einer Software tun sollten, ist, die Standard-Anmeldeinformationen zu ändern. Wir empfehlen Ihnen sogar, dies zu einer obligatorischen Gewohnheit in Ihrem Unternehmen zu machen.
Beschränken Sie den Zugang zu den Administrationspanels und Konsolen. Die zweite obligatorische Praxis, die Sie unternehmensweit umsetzen sollten, ist die Deaktivierung des Zugriffs auf Verwaltungstools vor der Bereitstellung. Es versteht sich von selbst, dass nur die Benutzer, die sie benötigen, Zugang zu ihnen haben sollten. Achten Sie auch darauf, dass diese Praxis durch systematische Audits eingehalten wird.
Deaktivieren Sie die Verzeichnisauflistung und überprüfen Sie die Berechtigungen der Verzeichnisse. Die bereitgestellte Anwendung sollte die Auflistung von Verzeichnissen nicht zulassen, ganz einfach. Vergewissern Sie sich außerdem, dass die Berechtigungen für die einzelnen Ordner und Dateien richtig eingestellt sind.
Erzwingen Sie wiederholbare Maßnahmen zur Sicherheitshärtung. Ein korrekt konfigurierter, wiederholbarer Härtungsprozess macht die Bereitstellung anderer Umgebungen (die ebenfalls korrekt abgesichert sind) schnell und einfach. Stellen Sie also sicher, dass die Entwicklungs-, QA- und Produktionsumgebungen identisch konfiguriert sind und verwenden Sie für jede Umgebung unterschiedliche Anmeldeinformationen. Wenn Sie dies automatisieren, können Sie mühelos neue sichere Umgebungen einrichten.
Verwenden Sie eine segmentierte Anwendungsarchitektur. Eine segmentierte App-Architektur gewährleistet eine effektive und vor allem sichere Trennung zwischen den Komponenten und Tenants. Neben der Segmentierung sollte die Architektur auch die Containerisierung und/oder Cloud-Sicherheitsgruppen (ACLs) umfassen.
Halten Sie die Plattform sauber. Trennen Sie sich von allen unnötigen Funktionen, Komponenten, Dokumentationen und Beispielen. Sie sind nicht nur im Grunde nutzlos (daher der Teil “unnötig”), sondern stellen auch eine Sicherheitsbedrohung dar. Entfernen Sie auch alle Frameworks, die Sie nicht verwenden. Idealerweise sollten Sie sie gar nicht erst installiert haben.
Rekapitulieren wir
Sicherheitsfehlkonfiguration ist ein Oberbegriff für jede unsichere oder falsch konfigurierte Sicherheitskontrolle. Wenn sie ausgenutzt wird, können Hacker auf vertrauliche Informationen zugreifen oder die Kontrolle über die gesamte Webseite, den Server oder die Anwendung übernehmen. Die Auswirkungen von Sicherheitsfehlkonfigurationen haben in der Vergangenheit unzählige Giganten lahmgelegt. Informieren Sie sich also über das Thema und befolgen Sie die Tipps zur Vermeidung von Sicherheitsfehlkonfigurationen, die wir oben beschrieben haben. Gute Reise und mögen die Chancen immer zu Ihren Gunsten stehen.
