Jenseits der Checkliste: Warum Angreifer Ihre Fehlkonfigurationen lieben – und wie Sie sie stoppen können

Einige der schlimmsten Sicherheitsverletzungen der letzten Jahre gingen nicht auf raffinierte Malware oder hochmoderne Exploits zurück. Sie hatten eine viel einfachere Ursache: Irgendwo hatte jemand eine Einstellung offen gelassen. Ein falsch konfigurierter S3-Speicher-Bucket mit öffentlichen Leserechten, eine kurzlebige Testumgebung mit Produktionszugangsdaten, die ins Internet gelangten, eine zu freizügige Firewall-Regel mit einer zu weit gefassten CIDR-Notation, die den Zugriff aus nicht autorisierten Netzwerken ermöglichte. Diese Art von Sicherheitsfehlkonfigurationen verbreiten sich unbemerkt in ganzen Umgebungen und schaffen so ausnutzbare Angriffsvektoren für Angreifer.

Sie sind außerdem allgegenwärtig. Untersuchungen schätzen, dass Fehlkonfigurationen 10 bis 15 Prozent aller Sicherheitsvorfälle verursachen. Und sie betreffen nicht nur einen Teil Ihrer Umgebung, sondern treten in Multi-Cloud-Architekturen, lokalen Systemen, IAM-Konfigurationen, RESTful-APIs, containerisierten Microservices und darüber hinaus auf. Ein kleines Versehen an einer Stelle kann zu einem viel größeren Problem an einer anderen Stelle im Technologie-Stack führen. Der Grund? Angreifer wissen, wie sie Fehlkonfigurationen finden und diese nutzen können, um dauerhafte Angriffspunkte zu schaffen.

Die Frage ist: Kann Ihr Team diese Angriffsvektoren erkennen und kritische Schwachstellen beheben, bevor ein Angreifer sie ausnutzt?

Was sind Fehlkonfigurationen und warum sind sie wichtig?

Fehlkonfigurationen treten auf, wenn etwas aus Sicherheits- oder betrieblicher Sicht nicht ganz richtig eingerichtet ist. Ein S3-Bucket mit authentifizierter Lese-ACL, aber fehlenden Bucket-Richtlinienbeschränkungen, sodass jeder authentifizierte AWS-Benutzer über vorab signierte URLs auf sensible Daten zugreifen kann. Eine API ohne ordnungsgemäße Ratenbegrenzung und Eingabevalidierung. Eine Identität mit übermäßigen Berechtigungen, die gegen das Prinzip der geringsten Berechtigungen verstößt. Manchmal handelt es sich um so einfache Dinge wie Standardanmeldedaten, die in Produktionsumgebungen unverändert bleiben.

Sie sind leicht einzuführen – und schwer zu entdecken. Eine überstürzte Bereitstellung während der Ausführung einer CI/CD-Pipeline. Eine kopierte IAM-Richtlinie mit vererbten Berechtigungen. Eine wiederverwendete Infrastructure-as-Code-Vorlage mit eingebetteten Geheimnissen. Diese Schwachstellen verbreiten sich schnell und sind in komplexen, kurzlebigen Umgebungen selten erkennbar, bis ein Angreifer die Angriffskette ausnutzt.

Weitere häufige Beispiele sind:

• Schwache oder fehlende Zugriffskontrollen
• Deaktivierte Sicherheitseinstellungen
• Unverschlüsselte Daten während der Übertragung oder im Ruhezustand
• Zu weit gefasste Identitäts- oder Rollenberechtigungen
• Schlecht gesicherte APIs

Für sich genommen mag keiner dieser Punkte dringend erscheinen. Aber Angreifer denken nicht isoliert. Sie denken in Pfaden. Der falsch konfigurierte Testdienst, den Sie vergessen haben? Wenn er über wiederverwendete Anmeldedaten oder eine Rolle mit zu weitreichenden Berechtigungen mit der Produktion verbunden ist, wird er plötzlich viel wichtiger.

Das Problem ist in der Regel nicht Nachlässigkeit, sondern Komplexität. Verschiedene Teams verwalten unterschiedliche Teile des Stacks. Eines kümmert sich um die Cloud, ein anderes um Identitäten, ein drittes überwacht das Netzwerk. Da kann leicht etwas durch die Maschen fallen. Wichtig ist, zu verstehen, wie diese Lücken miteinander verbunden sind – und wie schnell jemand sie ausnutzen könnte.

Zuordnung von Fehlkonfigurationen zu MITRE ATT&CK-Techniken

Wenn Sie verstehen möchten, wie dies in der Praxis funktioniert, ist die Zuordnung von Fehlkonfigurationen zu MITRE ATT&CK-Techniken ein guter Ausgangspunkt. Das MITRE ATT&CK-Framework bietet eine perfekte Perspektive, um diese Risiken zu betrachten, und zeigt genau, wie Angreifer häufige Fehlkonfigurationen ausnutzen, um komplexe Angriffe durchzuführen.

Sehen wir uns hier einige davon an:

(Abb. 1: Tabelle der MITRE ATT&CK-Techniken, die Fehlkonfigurationen zugeordnet sind)

Was herkömmliche Tools übersehen

Die meisten Sicherheitstools können einzelne Fehlkonfigurationen erkennen. Sie melden einen offenen Port oder einen öffentlichen Bucket. Allerdings betrachten sie diese Probleme meist isoliert. Was sie oft übersehen, ist, wie ein kleiner Fehler Teil eines viel größeren Angriffspfads sein kann.

An dieser Stelle stoßen viele Teams an ihre Grenzen. Sie sehen die Warnmeldung – sie wissen, dass etwas falsch konfiguriert ist –, aber sie sind sich nicht sicher, ob dies tatsächlich gefährlich ist. Also versuchen sie entweder, alles schnell zu reparieren, oder ignorieren die meisten Warnmeldungen.

Die wirkliche Gefahr ist schwer zu erkennen – ob diese falsche Einstellung eine Tür zu etwas Öffnet, das wichtig ist. Ein offener Speicherort sollte behoben werden. Aber ein offener Speicherort voller Kundendaten, auf den über ein kompromittiertes Entwicklerkonto zugegriffen werden kann? Das ist etwas, das sofortige Aufmerksamkeit erfordert.

Aus diesem Grund gehen viele Teams zu einer vernetzten Sichtweise über und nutzen kontinuierliches Exposure Management, um zu verstehen, wie Fehlkonfigurationen miteinander zusammenhängen. Sie beginnen, bessere Fragen zu stellen: Ermöglicht diese Einstellung jemandem, tiefer in die Umgebung vorzudringen? Könnte sie ein kritisches System beeinträchtigen? Würde sie einem Angreifer helfen, tatsächlichen Schaden anzurichten?

Szenarien aus der Praxis

Fehlkonfigurationen verursachen in der Regel nicht von selbst Probleme. Sie bleiben einfach bestehen – unauffällig und leicht zu übersehen –, bis ein Angreifer sie miteinander verknüpft und alles zusammenbricht. So sieht das in der Praxis aus:

• Der Entwickler, der Zugriff auf alles hatte

Ein Entwickler hatte in Azure noch eine veraltete RBAC-Zuweisung, die ihm über seine funktionalen Anforderungen hinausgehende Berechtigungen gewährte. Niemand hat das bereinigt, weil ja nichts kaputt gegangen ist. Aber in dieser Rolle war die Berechtigung zum Ausführen beliebiger SQL-Abfragen an eine interne Datenbank eingebettet. Ein Angreifer hätte eine erfolgreiche Spear-Phishing-Kampagne gegen den Entwickler durchführen, dessen Anmeldedaten kompromittieren und sich dann lateral durch die Umgebung bewegen können. Keine Zero-Day-Exploits, keine Sicherheitswarnungen – nur die Ausnutzung legitimer Zugriffsrechte, um sich im Netzwerk zu bewegen. Die Kompromittierung dauerte tagelang, weil alle Aktivitäten als autorisiert erschienen – denn technisch gesehen „funktionierte alles wie vorgesehen“.

• Der Testcontainer, der zur Hintertür wurde

Jemand stellte einen Container in einer Entwicklungsumgebung bereit, um etwas schnell zu testen. Er wurde mit aktivierten Administratorrechten ausgeführt. Keine große Sache – es handelt sich ja nur um eine Nicht-Produktionsumgebung, oder? Nur dass die Firewall-Regel den Datenverkehr aus der Produktion zuließ. Und das von ihm verwendete Dienstkonto? Viel zu freizügig. Wenn ein Angreifer eine alte Schwachstelle im Container-Image finden würde, könnte er sich Zugang verschaffen und von dort aus direkt in die Produktion gelangen. Dieser Container sollte eigentlich nicht Teil der kritischen Infrastruktur sein, aber niemand hat daran gedacht, ihn zu sperren.

• Die SaaS-Einrichtung, die nie fertig wurde

Ein neues Tool für die Zusammenarbeit wurde schnell eingeführt – weil das Team es schon gestern brauchte. MFA war optional und für freigegebene Links war keine Anmeldung erforderlich. Jemand wurde Opfer eines Phishing-Angriffs, klickte auf eine gefälschte Dateifreigabe und schon waren interne Dokumente für die ganze Welt sichtbar. Niemand bemerkte dies, bis diese Dateien in den Suchergebnissen auftauchten. Die Einrichtung war nicht unbedingt falsch – sie war nur nicht ausreichend gesichert. Und niemand hatte sich die Mühe gemacht, dies zu überprüfen.

Warum Prävention allein nicht ausreicht

Es ist zweifellos wichtig, von Anfang an für eine sichere Einrichtung zu sorgen. Und die vorhandenen Tools bieten solide Grundlagen für die Prävention: automatisierte Konfigurationsprüfungen, intelligente Zugriffskontrollen, ordnungsgemäße Fehlerbehandlung. Das ist alles gut und schön.

Aber selbst die beste Einrichtung kann nicht alles abfangen. Neue Systeme werden eingeführt. Richtlinien ändern sich. Entwickler nehmen Anpassungen vor, damit Funktionen funktionieren. Administratoren nehmen unter Druck Änderungen vor. Irgendwann schlüpft etwas durch die Maschen.

Hier kommt die Validierung ins Spiel. Es geht nicht nur darum zu fragen: „Ist diese Einstellung korrekt?“. Es geht darum zu fragen: „Könnte jemand dies nutzen, um sich Zugang zu verschaffen, sich zu bewegen oder Schaden anzurichten?“. Wenn Sie sich nur auf statische Regeln oder einmalige Scans verlassen, übersehen Sie wahrscheinlich das Gesamtbild.

Ein effektiverer Weg (und natürlich der Weg von XM Cyber) besteht darin, Fehlkonfigurationen nicht nur aufzulisten, sondern sie zu vollständigen Angriffspfaden in Ihrer Umgebung zu verknüpfen. Auf diese Weise können Sie sehen, wie scheinbar kleine Probleme miteinander zusammenhängen, und diejenigen beheben, die tatsächlich ein Risiko darstellen.

(Abb. 2: Angriffsdiagramme zeigen, wie Probleme miteinander zusammenhängen)

Das Fazit: Von Listen zu Erkenntnissen

Sicherheitsteams brauchen keine weiteren Listen mit Problemen. Sie brauchen Klarheit. Sie müssen verstehen, was gefährlich ist, was nur Hintergrundrauschen ist und was zuerst behoben werden muss.

Hier zahlt sich ein kontextorientierter Ansatz zur Behebung von Fehlkonfigurationen aus. Damit können Teams erkennen, wie Fehlkonfigurationen in Angriffspfade passen, sodass sie sich auf die tatsächlichen Probleme konzentrieren können. Sie verschwenden weniger Zeit mit der Verfolgung von Fehlalarmen. Sie verbessern die Zusammenarbeit zwischen IT-, Cloud- und Sicherheitsteams. Und vor allem reduzieren sie das tatsächliche Risiko.

Fehlkonfigurationen kommen vor. Sie sind leicht zu machen und schwer vollständig zu beseitigen. Aber sie müssen nicht zu Kompromissen führen. Indem sie verstehen, wie sie sich in das Gesamtbild der Bedrohungen einfügen, können Teams die Kontrolle zurückgewinnen – und verhindern, dass Angreifer Zugriff auf Ihre kritischen Assets erhalten.

---

Weitere Informationen:

CTEM Section

Continuous Exposure Management

XM Cyber deckt auf, wie Angreifer Ihre Umgebung ausnutzen können – vollautomatisch. Unsere Lösung visualisiert sämtliche Angriffspfade zu kritischen Ressourcen in einem Diagramm. So können Sie sich auf die 2 % der Fixes konzentrieren, mit denen sich die wirklich relevanten Angriffspfade durchkreuzen lassen – und vergeuden keine Zeit mehr mit Maßnahmen, die sich nicht auf Ihr Risiko auswirken.

XM Cyber bei LinkedIn

---

Bild/Quelle: https://depositphotos.com/de/home.html