In diesem Artikel analysieren wir, wie SQL-Injections trotz Anti-CSRF-Maßnahmen mit SQLMap ausgenutzt werden können. Dabei beschreiben wir ein real angetroffenes Pentesting-Szenario, in dem gängige Schutzmechanismen umgangen wurden.
Während unserer Tests stießen wir auf einen bisher unbekannten Bug in SQLMap, der dazu führte, dass das Tool in bestimmten Fällen nicht wie erwartet funktionierte und wie wir dennoch in der Lage waren, die Schwachstelle auszunutzen.
Zum praktischen Nachvollziehen haben wir eine CTF-Challenge erstellt, die es ermöglicht, diese Techniken selbst auszuprobieren. Unser Ziel ist es, praxisnahe Einblicke in moderne Angriffsmethoden und deren Abwehr zu geben.
So oder so ähnlich lautet bereits ein Werbeslogan einer weltweit bekannten Süßigkeiten-Marke aus den United States of America. Im Bereich Offensive Security und Pentesting geht es hier allerdings weniger um Snacks.
Hierbei handelt es sich um die visuelle Darstellung verschiedener Testkonzepte im Bereich IT-Security. Neben zahlreichen Begriffen wie Black-Box, Grey-Box und White-Box werden häufig auch Farben zur Veranschaulichung eingesetzt.
Um diesen Regenbogen einmal in das Farbspektrum aufzubrechen und die Unterschiede zu verstehen, sehen wir uns die Begriffe Red Teaming, Purple Teaming und Blue Teaming genauer an.
Red Teaming ist eine Methode zur Überprüfung der Cyber-Sicherheit, bei der ein dediziertes Team (das „Red Team“) die Sicherheitssysteme einer Organisation durch simulierte Angriffe testet. Im Gegensatz zu traditionellen Sicherheitsaudits umfasst Red Teaming aktive Angriffssimulationen, bei denen das Team versucht, Schwachstellen zu identifizieren und zu kompromittieren. Dadurch erhalten Organisationen realistische Einblicke in ihre Sicherheitslage und können ihre Verteidigungsstrategien verbessern.
Blue Teaming ist der Gegenpart zum Red Teaming und bezeichnet die interne Sicherheitsabteilung einer Organisation, die sich mit der Erkennung und Abwehr von Angriffen befasst. Im Rahmen von Blue Teaming arbeiten Sicherheitsexperten daran, potenzielle Angriffe zu erkennen, zu analysieren und zu stoppen, die von einem Red Team simuliert werden. Im Gegensatz zum Red Team konzentriert sich das Blue Team darauf, die Verteidigungsfähigkeiten der Organisation zu stärken und Sicherheitslücken zu schließen, um potenzielle Angriffe abzuwehren.
Purple Teaming ist eine Methode, die das Beste aus Red und Blue Teaming kombiniert. Dabei arbeiten das Red und Blue Team eng zusammen, um Angriffsszenarien zu simulieren, Schwachstellen zu identifizieren und die Verteidigungsfähigkeiten der Organisation zu verbessern. Im Gegensatz zu reinem Red oder Blue Teaming legt Purple Teaming den Schwerpunkt darauf, die Zusammenarbeit zwischen Angriffs- und Verteidigungsteams zu stärken, um die Reaktionsfähigkeit der Organisation auf realistische Bedrohungen zu optimieren. Wenn hierfür ein spezielles Team eingesetzt wird spricht man vom Purple Team.
Green Teaming ist ein Konzept, das sich darauf konzentriert, die Sicherheitsbewusstseinskultur innerhalb einer Organisation zu stärken. Im Gegensatz zu Red, Blue oder Purple Teaming liegt der Schwerpunkt beim Green Teaming nicht auf der Simulation von Angriffen oder der Erkennung von Sicherheitslücken, sondern vielmehr auf der Förderung von Sicherheitsbewusstsein und Best Practices bei den Mitarbeitern. Das Green Team bietet Schulungen, Sensibilisierungsmaßnahmen und Ressourcen zur Unterstützung der Mitarbeiter bei der Erkennung und Vermeidung von Sicherheitsrisiken im Arbeitsalltag.
Black-Box-Tests beziehen sich auf Sicherheitsüberprüfungen, bei denen die Tester keinerlei Kenntnisse über die internen Strukturen oder Systeme des zu testenden Systems haben. Sie finden buchstäblich im Dunklen statt und die Tester arbeiten sich hier voran. Im Gegensatz dazu beziehen sich White-Box-Tests auf Tests, bei denen die Tester detaillierte Kenntnisse über die interne Funktionsweise und Implementierung des Systems haben. Dies ermöglicht genaue Ergebnisse mit geringer Fehlerquote gegenüber false/positive-Findings. Grey-Box-Tests liegen dazwischen, wobei die Tester über begrenzte Kenntnisse verfügen, die ihnen einen teilweisen Einblick in das System ermöglichen, aber nicht die gesamte interne Funktionsweise offenlegen. Hier wird versucht das beste aus Black- und White-Box Tests zu kombinieren und möglichst reale und genaue Ergebnisse zu liefern.
Was sind die Aufgaben der Teams?
Blue Teaming:
Blue Teaming konzentriert sich auf die Verteidigungsseite der Sicherheit. Es beinhaltet die interne Sicherheitsabteilung oder Sicherheitsteams, die sich darauf konzentrieren, Sicherheitsmaßnahmen zu entwickeln, zu implementieren und zu verbessern, um Angriffe zu verhindern oder zu erkennen.
Diese Teams führen interne Penetrationstests selbstständig durch, analysieren Sicherheitsprotokolle und -richtlinien, überwachen Netzwerke auf verdächtige Aktivitäten und reagieren auf Sicherheitsvorfälle.
Red Teaming:
Red Teaming ist im Wesentlichen das Gegenteil von Blue Teaming. Diese Teams fungieren als Angreifer und versuchen, Schwachstellen in den Sicherheitssystemen eines Unternehmens aufzudecken, indem sie realistische Angriffsszenarien simulieren. Schwachstellen werden aktiv ausgenutzt.
Das Ziel von Red Teaming ist es, die Effektivität der Sicherheitsmaßnahmen zu testen, indem sie die Perspektive eines tatsächlichen Angreifers einnehmen. Dadurch können Sicherheitslücken und Schwachstellen aufgedeckt werden, die möglicherweise von den Blue Teams übersehen wurden.
Purple Teaming:
Purple Teaming ist eine Kombination aus Red und Blue Teaming. Hierbei arbeiten beide Teams Hand in Hand zusammen, um die Sicherheitslage zu verbessern.
Während ein Red-Team Angriffe simuliert, um Schwachstellen aufzudecken, arbeitet das Blue-Team daran, diese Schwachstellen zu identifizieren, zu beheben und präventive Maßnahmen zu entwickeln, um ähnliche Angriffe in Zukunft zu verhindern.
Durch diese Zusammenarbeit erhalten beide Teams ein besseres Verständnis für die Stärken und Schwächen der Sicherheitssysteme und können effektivere Verteidigungsstrategien entwickeln.
Green-Teaming:
Das Green Team hilft dabei, Best Practices zu identifizieren und sicherzustellen, dass die durchgeführten Übungen die Sicherheitsfähigkeiten des Unternehmens stärken und weiterentwickeln.
Das Green Team überwacht den Purple Teaming-Prozess neutral und unterstützt die Zusammenarbeit zwischen Red und Blue Teams.
Ziel des Green Teams ist es, die Effektivität der Purple Teaming-Übungen zu maximieren, indem es Feedback gibt und sicherstellt, dass die Ergebnisse den Sicherheitszielen des Unternehmens entsprechen.
Teamaufgaben im Überblick
Red Team
Offensive Security / Ethical Hacking
Aktive Ausnutzung von Schwachstellen
Black Box Pentesting
Angriffe auf Webseiten
Zielorientierung
Social Engineering Angriffe
Purple Team
Ausarbeiten von Verbesserungen in Verteidigung und Angriffstests
Schulungsaufgabe gegenüber Red und Blue Team
Zuständig für Stichprobenkontrolle in größeren Organisationen
Informationsaustausch und Aufbereitung
Blue Team
Defensive Security
Infrastruktur Härtung
Schadesnkontrolle
Incident Response (IR)
Operationssicherheit
Proaktive Suche nach Konfigurationsfehlern
Digitale Forensik
Unterschied zwischen einem Pentest und Red-Team-Assessment
Die Hauptunterschiede zwischen einem klassischen Penetrationstests und einem Red-Teaming Ansatz liegen im Wesentlichem am Ansatz sowie Ziel des Projektes. Darüber hinaus unterscheidet sich die Projektdauer bei beiden Testarten in der Regel erheblich.
Während ein klassischer Penetrationstest einen festen Projektrahmen bezüglich Zeit und Testinhalt ausfüllt, kann sich ein Red Teaming Assessment potenziell über einen sehr weiten Zeitraum erstrecken. Dies ist darin begründet, dass beim Red Teaming in der Regel nur das Ziel, jedoch nicht der Weg dorthin, definiert wird. Mitglieder eines Red Teams besitzen deshalb verschiedene Möglichkeiten und Wege, um das definierte Ziel zu erreichen. Eine Einschränkung der potenziell kompromittierbaren Zielsysteme oder erlaubten Angriffswege findet in der Regel weniger statt. Bei einem Penetrationstest hingegen wird sehr detailliert vorgegeben, welches Prüfobjekt getestet werden soll, welche Tests exkludiert werden, welche Methologien zum Einsatz kommen und es findet ein reger, transparenter Austausch während des Tests statt.
Darüber hinaus finden Red-Team-Assessments zumeist in der Testart „Black-Box“ statt. Die Mitglieder eines Red Teams, demnach die simulierten Angreifer, besitzen im Vorfeld kaum bis keine Informationen über den Aufbau der IT-Infrastruktur eines Unternehmens. Durch diese „blinde“ Herangehensweise kann zwar ein realistischer Angriff simuliert werden, dieser erfordert jedoch mehr Zeit und Aufwand in der Vorbereitung (OSINT, Recherche zum Unternehmen, Entwurf zugeschnittener Exploits und Möglichkeiten zur Umgehung von AV/EDR).
Sobald ein zuvor definiertes Ziel bei einem Red-Team-Assessment erreicht wurde, gilt das Assessment als abgeschlossen. Der Angriffsweg wird hierbei von den Mitgliedern des Red Teams protokolliert, alle ausgenutzten Schwachstellen und Fehlkonfigurationen in einem Bericht erläutert und Empfehlungen zur Behebung gegeben. Ob es neben diesen einem Angriffsweg noch weitere Wege gibt, um das Ziel des Red Teaming Assessment zu erreichen, bleibt unbekannt.
Um dies durch Stichpunkte kurz darzustellen:
Red-Teaming:
Red-Teaming ist ein umfassenderer Ansatz, der darauf abzielt, realistische Angriffsszenarien zu simulieren, indem er die Taktiken, Techniken und Verfahren (TTPs) von potenziellen Angreifern (Advanced Persistent Threat; APT) nachahmt. Das Red Team handelt wie ein echter Angreifer, indem es verschiedene Angriffspfade und -techniken ausnutzt, um Schwachstellen in den Sicherheitssystemen eines Unternehmens aufzudecken.
Das Ziel des Red-Teams ist es, die Effektivität der Sicherheitsmaßnahmen ganzheitlich zu testen, einschließlich der Erkennung, Reaktion und Wiederherstellung nach einem Angriff. Dabei werden nicht nur technische Schwachstellen, sondern auch Schwachstellen in Prozessen, Richtlinien und menschlichem Verhalten berücksichtigt.
Sobald ein zuvor definiertes Ziel bei einem Red-Team-Assessment erreicht wurde, gilt das Projekt als abgeschlossen. Anderweitige Angriffswege, welche ggf. ebenfalls zur Erreichung des Ziel führen könnten, werden vernachlässigt.
Penetrationstest (Pen-Test):
Ein klassischer Penetrationstest konzentriert sich hauptsächlich darauf, Schwachstellen in einem bestimmten System, einer Anwendung oder einem Netzwerk zu identifizieren. Ein Pentest wird in der Regel von Sicherheitsexperten durchgeführt, die gezielt nach Sicherheitslücken suchen, um sie zu dokumentieren und zu beheben.
Im Gegensatz zum Red-Teaming zielt ein Pentest in der Regel nicht darauf ab, realistische Angriffsszenarien zu simulieren oder den gesamten Angriffspfad eines Angreifers über mehrere Infrastrukturkomponenten zu replizieren. Stattdessen konzentriert er sich darauf, Schwachstellen zu identifizieren und den Kunden Berichte darüber zu liefern, wie diese behoben werden können.
Penetrationstest
Standardisierte IT-Sicherheitsüberprüfung
ab
2 PT Projektzeit
Fokus auf Vollständigkeit und allen Schwachstellenklassen
Insbesondere für Unternehmen, die größere Infrastrukturen betreiben, können aus einem Pentest oft mehr Erkenntnisse gewonnen werden, als typischerweise angenommen wird. Wir zeigen Ihnen, wie Sie Pentest Ergebnisse richtig interpretieren und einen maximalen Nutzen daraus ziehen.
Einer der Hauptgründe ist eine falsche Perspektive auf die Ergebnisse eines Tests. Typische Annahmen sind:
Irrtum 1: Ein Pentest findet sämtliche Schwachstellen die auf dem Target vorhanden sind
Eine erste wichtige Erkenntnis ist, dass Penetrationstests nie alle Schwachstellen auf einem Zielsystem erkennen können. Dies hat folgende Gründe: Zum einen ist der Test zeitlich begrenzt, zum anderen sind bei den meisten Tests nicht alle Konfigurationsparameter über das System bekannt.
Fazit: Ein Pentest kann nicht allein dazu herangezogen werden eine Zielanwendung sicherer zu machen. Ein Pentest Bericht ohne kritische Feststellungen bedeutet nicht, dass die Anwendung absolut keine Schwachstellen enthalten kann.
Konsequenz: Nutzen Sie bei Anwendungs-Audits die volle Bandbreite an Testmöglichkeiten: Code-Reviews, Peer-Reviews, Schulungen zum Secure Software Development. Je früher Schwachstellen entdeckt werden, desto höher ist der Gewinn. So lassen sich durch frühzeitige Code-Reviews mit Fokus auf Schwachstellen, Code-Komplexität und „Bad Smells“ Fehler im Design, im Datenmodell oder im Verständnis der Programmierer aufdecken. Ein Pentest erfolgt meist erst zu einem Release-Status der Anwendung, wo größere Änderungen nicht mehr möglich sind.
Wenn Schwachstellen in einem Pentest identifiziert werden, so sollte immer ausgewertet werden, ob diese Fehler womöglich auch in anderen Applikationskomponenten vorhanden sein können. Gerade bei Schwachstellen bei der Eingabevalidierung lassen sich in einem Test oft nicht alle verwundbaren Parameter identifizieren. Ebenfalls sollte analysiert werden, ob das fehlerhafte Design ggf. in anderen Anwendungen zum Einsatz kam.
Irrtum 2: Ein Pentest trifft eine Aussage darüber, wie sicher das System gegenüber (zukünftigen) Angriffen ist
Ein Pentest ist immer nur eine Momentaufnahme aktuell bekannter Schwachstellen und des Zielsystems in seiner Konfiguration und Version zur Testzeit. Nur weil ein aktueller Bericht als Gesamtrisiko „niedrig“ ausweist, heißt dies nicht, dass nicht zukünftig eine neue Schwachstelle veröffentlicht wird, die das gesamte System kompromittiert.
Pentests sollten daher nicht als einmalige Maßnahme betrachtet werden, sondern sind vielmehr eine Methode zur regelmäßigen Überprüfung einer Anwendung oder eines IT-Systems auf bekannte Schwachstellen.
Irrtum 3: Risikobewertung ist gleich Priorität
Wir sehen oft, dass Pentestergebnisse ohne eine nähere Diskussion des Risikos weiterverarbeitet werden. Die Risikobewertung der Pentester wird als „in Stein gemeißelt“ gesehen. Hier weisen wir drauf hin, dass eine Diskussion der identifizierten Schwachstellen mit Ihrem IT-Sicherheitsteam zu einer sinnvollen Gewichtung oder Priorisierung der Ergebnisse führen kann. Je nachdem, welches Threat Model Sie erarbeitet haben (z.B. in einer Risk/Impact-Analyse als Teil der ISO 27001 Zertifizierung) kann es Schwachstellen geben, deren Behebung anders priorisiert werden sollte, als es der Pentestbericht von außen beurteilt.
Gerne können wir als Pentest Factory diese Diskussion (z.B. in einem gemeinsamen Meeting) unterstützen, um ein Gesamtbild des Zielsystems und Risikos in seiner Umgebung zu kreieren.
Ein weiterer Gesichtspunkt ist das Risikobewertungssystem selbst. Bei der Verwendung des Standard CVSS Systems (ohne Environment-Metriken), wird das Gesamtrisiko aus einer Formel errechnet, die uns als Testern wenig Freiraum zur kontextabhängigen Herauf- oder Herabstufung von Risiken lässt. Beispielsweise lässt sich für die Metrik „Attack Complexity“ ausschließlich zwischen „High Attack Complexity“ und „Low Attack Complexity“ wählen. Dementsprechend lassen sich Angriffe mit einer mittleren Komplexität hier nicht abbilden. Dies ist ähnlich für die weiteren Metriken im CVSS-System. Somit kann es z.B. vorkommen, dass wir eine Feststellung mit mittlerer Kritikalität als „hohes Risiko“ einstufen, weil die CVSS-Formel dies errechnet.
Generell macht eine Besprechung der einzelnen Ergebnisse und zugewiesenen Risiken im Team somit Sinn.
Irrtum 4: DIe Behebung von Schwachstellen löst das Problem
Das Ergebnis eines Pentests ist ein Abschlussbericht. Dieser führt identifizierte Schwachstellen auf und gibt konkrete Empfehlungen zur Behebung der Feststellungen.
Es erscheint auf den ersten Blick, dass die Behebung dieser Schwachstellen die Hauptaufgabe nach Abschluss des Tests ist.
Als Pentest Dienstleister sehen wir jedoch häufig, dass die Behebung von Schwachstellen die einzige resultierende Tätigkeit aus einem Testergebnis ist. Aus diesem Grund ist es umso wichtiger zu verstehen, dass der eigentliche Wert des Pentests in der Identifikation von fehlerhaften Prozessen liegt. Bei jeder Schwachstelle lohnt es sich zu fragen „Warum ist es zu dieser Schwachstelle gekommen? Wie können wir den Prozess dahinter korrigieren?„
Nur auf diese Weise kann gewährleistet werden, dass z.B. ein fehlender Patch-Management-Prozess oder ein mangelhaftes Asset-Management korrigiert werden und Software-Deployments nicht nach einem Monat wieder mit fehlenden Updates laufen.
Da wir sehr häufig sehen, dass eine Ursachenanalyse nach Abschluss des Pentests entfällt, möchten wir ein zweites Beispiel zeigen, bei dem ein Verständnis des fehlerhaft abgelaufenen Prozesses einen deutlichen Mehrwehrt in der Sicherheit bringen kann:
In einem Pentest-Bericht wird festgestellt, dass im Web-Verzeichnis des Anwendungsservers eine Datei mit sensitiven Umgebungsvariablen gespeichert wurde. Die Datei mit dem Namen „.env“ wurde bereits während des Pentests an den Kunden kommuniziert und dieser hat die Datei unmittelbar entfernt. Belässt der Kunde seine Behebungsmaßnahmen bei diesem Schritt, so ignoriert er eine komplette Ursachenanalyse und womöglich weitere Schwachstellen, die bestehen.
Stellen wir uns die Frage: Warum hat es die .env Datei in das Webverzeichnis geschafft? Nach einer Analyse des Entwicklungs-Repository’s (z.B. GIT) stellen wir fest, dass ein Entwickler die Datei 2 Monate vor Release angelegt hat und in ihr sensitive Umgebungsvariablen speichert. Dies beinhaltet den AWS Secret Key, sowie die Kennwörter des Administrator-Accounts. Dabei hat der Entwickler vergessen, die Datei von der Repository-Indizierung zu exkludieren. Dies wird erreicht, indem die Datei in die „.gitignore“ Liste aufgenommen wird.
Wie können wir diesen Fehler in Zukunft beheben?
Erkenntnis 1: Mögliche Ursache im Missverständnis der Entwickler: „Entwickler verstehen nicht, welches Risiko fest eingespeicherte („hardcoded“) Passwörter und Schlüssel haben“. –> Awareness Seminar mit Entwicklern zum Thema Secure Software Development
–> Monatliche Session zum Thema „Secrets im Quellcode“
Erkenntnis 2: Der Fehler wurde 2 Monate lang nicht bemerkt und erst im Pentest festgestellt. –> Möglichkeiten der automatischen Erkennung von Secrets: „Statische Quellcode Analyse“, „Automatisierte Analyse von Commits“, „Automatisierte Scans des Quellcode-Repositories“
–> Anpassung der CI/CD Pipeline um automatisch sensitive Commits zu Stoppen
Erkenntnis 3: Schlechtes Management von sensitiven Schlüsseln –> Neues zentrales Tool zum Secrets-Management einführen – Dies verbessert ebenfalls die Durchsetzung von Password-Policies, Passwort-Rotation
Haben wir diesen Fehler in der Vergangenheit mehrmals begangen?
Erkenntnis 1: Entwickler haben nicht nur eine Anwendung programmiert. Wir stellen fest, dass derselbe Fehler auch in einer benachbarten Anwendung begangen wurde.
–> Pentest Ergebnis lässt sich auf ähnliche Systeme und Prozesse übertragen
Erkenntnis 2: Das Versionsmanagement Tool enthält einen Verlauf aller jemals eingefügten Änderungen
–> Analyse des gesamten Repository’s auf sensitive Commits
Irrtum 5: Hohe Risiken im Abschlussbericht = "Das Produkt ist schlecht"
Nur weil eine „kritische“ Schwachstelle identifiziert wird, heißt dies nicht, dass die Entwicklung oder das Produkt „schlecht“ sind. Gerade Produkte, die besonders viele Funktionen bereitstellen, haben besonders viele mögliche Angriffsflächen. Bestes Beispiel sind bekannte Produkte wie Browser oder Betriebssyteme, die monatliche Sicherheitspatche herausbringen.
Als langjährige Experten im Bereich Cybersecurity sehen wir, dass die größten Probleme durch eine defensive Denkweise und eine unzureichende Beantwortung (=Reaktion) von Risiken auftreten. Konkret kommt es zu den folgenden fatalen Entscheidungen:
Fehlentscheidung 1: „Je weniger wir über die Schwachstelle bekannt geben, desto weniger negative Aufmerksamkeit erzeugen wir.“
–> Gerade nach Bekanntwerden einer Schwachstelle ist maximale Transparenz die einzig richtige Antwort. Was genau ist die Schwachstelle? Wo tritt diese auf? Was ist das worst-case Szenario? Nur durch maximale Transparenz kann eine genaue Ursachenbestimmung erfolgen und sichergestellt werden, dass alle Beteiligten das Risiko ausreichend verstehen, um Gegenmaßnahmen einzuleiten.
Die Schwachstelle sollte nie als Fehler einer einzelnen Person oder des Unternehmens angesehen werden, sondern als eine Möglichkeit zu Reagieren. Die Antwort auf eine Schwachstelle (nicht die Schwachstelle selbst) bestimmt in großem Rahmen, welcher Schaden tatsächlich angerichtet werden kann.
Fehlentscheidung 2: Es werden verantwortliche Personen für die Schwachstelle gesucht. –> Es kommt zu einer fatalen Fehlerkultur im Unternehmen, bei der Fehler nicht mehr offen kommuniziert und korrigiert werden. –> Fehler werden als Versagen interpretiert. Lerneffekte und gemeinsames Wachstum bleiben aus.
Fehlentscheidung 3: Um im Vorhinein die Identifikation einer kritischen Schwachstelle unwahrscheinlicher zu machen, wird bewusst ein stark eingeschränkter Scope für den Pentest gewählt. Hier ein paar Beispiele:
Es wird nur ein bestimmtes Nutzer-Frontend als „in-scope“ betrachtet. Administrative Komponenten dürfen nicht getestet werden.
Für den Pentest wird eine Nutzerumgebung bereitgestellt, die keine oder unzureichend viele Testdaten enthält, wodurch essentielle Anwendungsfunktionen nicht getestet werden können.
In der produktiven Umgebung „dürfen keine Daten abgesendet werden“. Der Pentest kann somit effektive keine Eingabeverarbeitung testen.
Der Einsatz von Intrusion Prevention Systemen oder Web Application Firewalls wird nicht angegeben. Der Pentest wird durch diese Systeme behindert. Ein Ergebnis bildet nicht mehr adäquat das Risiko der Anwendung selbst ab.
–> Diese oder weitere Beschränkungen führen zu einem falschen Risiko-Abbild des Zielsystems. Anstelle Schwachstellen so früh wie möglich zu erkennen, wächst die Komplexität und das Risikopotential der Anwendung schrittweise. Wenn eine Schwachstelle verspätet erkannt wird, wird es aufwändiger und damit kostenintensiver diese zu schließen.
Fazit
Als Pentest Dienstleister ist es uns wichtig, dass unsere Kunden den maximalen Nutzen aus einem Pentest ziehen können. Aus diesem Grund führen wir häufig Diskussionen im Team, um Trends zu erkennen und bestmögliche Empfehlungen zu geben. Dieser Artikel ist das Resultat dieser Diskussionen über die letzten Jahre und möchte neue Sichweisen auf die Pentest Ergebnisse eröffnen.
Haben Sie Fragen oder brauchen Sie Unterstützung bei den Themen Pentesting, Secure Software Development oder der Verbesserung von internen Prozessen? Nutzen Sie gerne das Kontaktformular, wir unterstützen Sie gerne.
Häufig können wir in Gesprächen mit Neukunden feststellen, dass der Markt der Penetration Testing Dienstleistungen undurchsichtig erscheint und es schwer ist, sich für einen Dienstleister zu entscheiden. Dabei wird oftmals Fokus auf den Preis eines Pentests gesetzt und andere Entscheidungskriterien entfallen.
Mit diesem Artikel wollen wir Ihnen eine grundlegende Orientierungshilfe geben, um Penetration Testing Dienstleister qualitativ bewerten zu können und Ihre Entscheidungsfindung zu vereinfachen.
Grundqualifikation der Penetrationstester
Eine Problematik die sich im Bereich Pentesting ergibt ist das Thema Erfahrung. Das Angreifen von Computersystemen erfordert Kreativität, Flexibilität und ein Verständnis von einer Breite an Technologien und Plattformen. Während mehrjährige Erfahrung als Entwickler oder Security Officer den Einstieg erleichtern können, ersetzen diese trotzdem keine praktischen Kenntnisse in der Funktionsweise von Sicherheitsmechanismen und wie diese angegriffen werden können.
Aus diesem Grund empfehlen wir einen Fokus darauf zu legen, wie viele Jahre ein Penetration Tester bereits Tests durchführt und welche praktisch orientierten Qualifikationen dieser besitzt. Im Folgenden haben wir einige häufig zu findende Qualifikationen aufgeführt und welche Kenntnisse hiermit effektiv attestiert werden.
Offensive Security Certified Professional (OSCP): Mehrere Computersysteme müssen in einer 24 stündigen praktischen Prüfung vollständig kompromittiert werden. Anschließend muss innerhalb von weiteren 24 Stunden ein ausführlicher Pentest Abschlussbericht erstellt werden. Nur wenn beide Teile qualitativ ausreichend fertiggestellt werden, wird der Titel des „Offensive Security Certified Professional“ vergeben. (https://help.offensive-security.com/hc/en-us/articles/360040165632-OSCP-Exam-Guide)
Certified Red Team Professional (CRTP): Um zertifiziert zu werden, müssen die Teilnehmer praktische und realistische Aufgaben in einer vollständig gepatchten Windows-Infrastruktur mit mehreren Windows-Domänen und -Forests lösen. Die Zertifizierung fordert die Teilnehmer heraus, Active Directory zu kompromittieren, indem sie Features und Funktionalitäten missbrauchen, ohne sich auf patchbare Exploits zu verlassen. Die Teilnehmer haben 24 Stunden Zeit für die praktische Zertifizierungsprüfung. Anschließend folgen weitere 24h für die Erstellung eines Penetrationsberichts. (https://www.alteredsecurity.com/adlab)
Burp Suite Certified Practitioner (BSCP): Die Zertifizierung zum Burp Suite Certified Practitioner demonstriert ein tiefes Wissen über Web-Sicherheitsschwachstellen, die richtige Denkweise, um sie auszunutzen, und natürlich die Burp Suite-Fähigkeiten, die für die Durchführung dieser Maßnahmen erforderlich sind. Im Rahmen der Prüfung müssen innerhalb von vier Stunden zwei Webanwendungen untersucht und sämtliche darin vorhandenen Schwachstellen identifiziert und ausgenutzt werden. (https://portswigger.net/web-security/certification/)
Certified Professional Penetration Tester (eCPPTv2): Es handelt sich um eine 100% praktische Zertifizierung in welcher die Prüfungskandidaten bis zu 7 Tage Zeit haben, um die Übungen zu absolvieren, und weitere 7 Tage für Ihre schriftliche Ausarbeitung. Um diese Prüfung zu bestehen, müssen die Teilnehmer die Beherrschung einer Vielzahl von Bereichen wie Network Pentesting, Web Application Pentesting und Systemsicherheit nachweisen. (https://elearnsecurity.com/product/ecpptv2-certification/)
HTB Certified Penetration Testing Specialist (HTB CPTS): Der Kandidat muss Blackbox-Web-, externe und interne Penetrationstests gegen ein reales Active Directory-Netzwerk durchführen. Zu Beginn des Prüfungsprozesses wird ein Letter of Engagement zur Verfügung gestellt, in dem alle Details, Anforderungen, Ziele und der Umfang des Auftrags klar dargelegt sind. (https://academy.hackthebox.com/preview/certifications/htb-certified-penetration-testing-specialist)
Wie aus den Beschreibungen ersichtlich wird, weist einzig der OSCP von den hier aufgeführten Zertifizierungen tatsächliche praktische Kenntnisse in der Kompromittierung von Computersystemen nach. Wir empfehlen Ihnen Tester zu beauftragen, die eine praktische Qualifizierung ähnlich zu OSCP besitzen. Um die erfolgreiche Qualifizierung und Gültigkeit einsehen zu können, empfehlen wir den Dienstleister nach einem Nachweis zu fragen (z.B. digitaler Link zu Credly, Credential.net oder ein Scan-Abzug des erworbenen Zertifikats eines Testers).
Spezialisierung der Penetrationstester
Wie zuvor beschrieben bietet die OSCP Zertifizierung einen guten Anhaltspunkt, um essentielle Kompetenzen eines Penetrationstesters verifizieren zu können. Mit der OSCP Zertifizierung sind Kenntnisse für die Enumerierung und das Testen von einzelnen Hosts und Diensten nachgewiesen.
Da moderne Anwendungen jedoch in ihrer Komplexität extrem gewachsen sind, empfehlen wir den Dienstleister zu fragen, welche Spezialisierungen die einzelnen Tester besitzen und diese Spezialisierungen nachweisen zu lassen (z.B. Zertifizierungen, Kundenreferenzen, CVE-Einträge). Besonders bei komplexen Prüfobjekten sollte der Tester mit den Technologien vertraut sein und sich im entsprechenden Bereich spezialisiert haben. Das gilt insbesondere für Bereiche wie Webanwendungen, API-Schnittstellen, Active Directory, Mobilanwendungstests, SAP Tests und viele mehr.
Angebot und Scoping
Wenn Sie ein Angebot anfragen, so sollte das Angebot auf die zu testende Applikation oder Infrastruktur abgestimmt sein. Hierzu sollte der Dienstleister in Erfahrung bringen, welchen Umfang das Testobjekt besitzt und auf dieser Grundlage eine Einschätzung treffen, wie viele Tage getestet werden müssen.
Sollte der Dienstleister keine Details über Ihr Prüfobjekt erfragen und Ihnen „blind“ ein Angebot zusenden, so kann es entweder vorkommen, dass zu wenige Tage einkalkuliert wurden, was dazu führt, dass die Applikation weniger tief getestet werden kann oder sogar bestimmte Komponenten ausgelassen werden. Alternativ kann es ebenso passieren, dass zu viele Tage für das Testobjekt veranschlagt werden und Sie diese einfach bezahlen müssen, obwohl der Test schon im Vorfeld hätte abgeschlossen werden können.
Tipp: Sollten Sie sich an mehrere Dienstleister gleichzeitig wenden (z.B. in einer Ausschreibung), so sollten Sie das Testobjekt so genau wie möglich beschreiben (verwendete Technologien, typische Applikationsfunktionen und Abläufe, Anzahl der Hosts). Diese Angaben erleichtern das Erstellen eines passenden Angebotes und reduzieren die Wahrscheinlichkeit, dass der Testumfang oder die Testmethodik falsch gewählt wird.
Abschlussbericht
Nach der Durchführung eines Penetrationstests ist der Abschlussbericht das zentrale Dokument, was die Ergebnisse des Pentests festhält. Achten Sie daher besonders auf die Qualität des Abschlussberichtes und lassen Sie sich einen Beispielbericht im Vorfeld der Beauftragung zukommen.
Jede Feststellung sollte eine klare Beschreibung mit Screenshots beinhalten, die den Weg zur Identifikation und Ausnutzung der Schwachstelle darstellt, damit Sie oder Ihre Entwickler die Problematik verstehen und gegebenenfalls nachstellen können. Ebenfalls sollte jede Feststellung eine Erläuterung enthalten, welches Risiko der Schwachstelle zugeordnet wurde und worauf diese Zuordnung basiert (z.B. anhand Risikobewertungsmethoden wie CVSS oder OWASP).
Der Bericht sollte alle Rahmenparameter des Tests eindeutig aufführen und typische W-Fragen erläutern, wie zum Beispiel:
– Wann wurde getestet (Zeitraum)? – Was wurde getestet (Prüfumfang)? – Was wurde ggf. nicht getestet (Scope)? – Wie wurde getestet (Methodik)? – Wer hat den Test durchgeführt (Ansprechpartner)? – Welche Risikobewertungsmethode kam zum Einsatz? – Welche Tools, Skripte und Programme kamen zum Einsatz?
Fragen Sie den Dienstleister nach einem Beispielbericht und vergleichen Sie die Berichte miteinander, um das ideale Berichtformat für Sie zu wählen. Achten Sie ebenfalls auf eine Management Summary, welche die Testergebnisse in einer nicht technischen Sprache auf Managementebene zusammenfasst. Dies ist besonders wichtig, da die Details von Feststellungen oftmals sehr technisch bzw. komplex sind und nur von technischem Personal nachvollzogen werden können.
Schwachstellenscan versus Penetrationstest
Oftmals vermischen sich die Begriffe Schwachstellenscan und Penetrationstest. Ein Schwachstellenscan ist ein automatisiertes Verfahren, mit dem ein Programm eigenständig oder auf der Basis bestimmter Scanparameter das Testobjekt auf Schwachstellen testet. Hierbei erfolgt kein manuelles Testen durch einen Menschen.
Seien Sie vorsichtig, wenn anstelle eines Penetrationstests ein Schwachstellenscan beworben wird. Viele Schwachstellen sind kontextabhängig und lassen sich nur durch manuelles Testen identifizieren. Zudem können Schwachstellenscanner False-Positive-Ergebnisse liefern, die also keine tatsächlichen Schwachstellen darstellen.
Um effizient zu testen, können ein oder mehrere automatisierte Scans Teil eines Penetrationstests sein. Sie sollten jedoch sicherstellen, dass der Dienstleister einen Fokus auf manuelle Verifikation der Ergebnisse und manuelles Testen des Prüfobjekts legt. Die automatisch generierten Testergebnisse sollten nicht direkt in den Bericht einfließen, lediglich nach einer manuellen Verifizierung. Jede Feststellung sollte eine genaue Darstellung beinhalten, wie die Schwachstelle verifiziert wurde.
Technische und Legale Grundlagen
Bevor ein Penetrationstest legal durchgeführt werden kann, muss die Erlaubnis des Hosters zwingendermaßen eingeholt werden. Sollten Sie Ihre Anwendung oder Infrastruktur nicht selbst hosten, so müssen Sie unbedingt den Hoster nach einer Erlaubnis zum Testen fragen. Ausgenommen hiervon sind einige Cloud-Hoster, die Penetrationstests explizit erlauben (z.B. Microsoft Azure, Amazon AWS, Google Cloud). Stellen Sie sicher, dass alle Freigaben vor Testbeginn erteilt wurden. Der Penetrationstest Dienstleister sollte diese Problematik von sich aus aufbringen und unbedingt mit Ihnen vor Testbeginn abklären.
Damit eindeutig zugeordnet werden kann, welche Angriffe von Ihrem Dienstleister durchgeführt werden und welche Angriffe eine reale Bedrohung darstellen, sollte der Dienstleister die Tests von einer festen IP-Adresse durchführen. Fragen Sie hierzu Ihren Dienstleister, ob eine solche statische IP-Adresse besteht und bringen Sie diese im Vorfeld der Tests in Erfahrung. Sie können während des Tests ebenso Ihre Logdateien nach der IP-Adresse durchsuchen und Einblicke bekommen, welches Anfragevolumen der Test generiert hat. Seien Sie vorsichtig bei der Wahl des Dienstleisters, sollte dieser keine eindeutige IP-Adresse für seine Tests nutzen. Lassen Sie sich darüber hinaus immer die Kontaktdaten der Person geben, welche die technischen Tests durchführt. So haben Sie die Möglichkeit bei Problemen oder technischen Fragen unmittelbar einen technischen Ansprechpartner zu kontaktieren und umgehend Rückmeldung zu erhalten. Weiterhin können Sie so ausschließen, dass ein Subdienstleister für die Durchführung der Tests intransparent oder ggf. inoffiziell beauftragt wurde.
Spezifisches Vorgehen
Tests von Webanwendungen
Ein Penetrationstest einer Webanwendung sollte sich an der öffentlichen Standard-Testmethodologie „OWASP“ orientieren. Das OWASP Konsortium stellt Vorgehensweisen für das Testen von allen aktuellen Schwachstellenkategorien zur Verfügung. Diese sollte unbedingt getestet werden.
Sollten Sie eine Anwendung testen wollen, die eine Nutzeranmeldung und geschützte Nutzerbereiche zur Verfügung stellt, so empfehlen wir die Durchführung eines „grey-box“ Tests. Hierbei werden dem Dienstleister Testkonten bereitgestellt, wodurch interne Bereiche hinter einer Anmeldung effizienter und granularer getestet werden können. Achten Sie darauf, ob der Dienstleister diese Testmethodik vorschlägt oder fragen Sie ggf. aktiv nach der Testmethodik.
Falls eine API-Schnittstelle getestet werden soll, so sollte der Dienstleister eine Schnittstellendokumentation oder eine Sammlung an beispielhafter API-Anfragen anfragen (z.B. Swagger.json, Postman Collections). Ohne eine API-Dokumentation ist das Testen von APIs nicht zielführend, da Endpunkte und Parameternamen erraten werden müssen. Dies kann zur Folge haben, dass wichtige Endpunkte übersehen und Schwachstellen nicht entdeckt werden.
Tests von IT-Infrastrukturen
Ein Infrastrukturtest bei dem mehrere Hostsysteme auf ihre verfügbaren Dienste getestet werden, besteht in der Regel aus mehreren automatisierten Scans am Anfang eines Tests kombiniert mit manuellen Testeinheiten und einer anschließenden Verifikation der Scanergebnisse.
Active Directory Sicherheitsanalyse
Active Directory Umgebungen sind sehr dynamisch und erfordern Spezialwissen, das über eine Grundqualifikation wie OSCP hinausgeht. Vergewissern Sie sich, dass der Tester Ihrer AD Umgebung Fortbildungen und Zertifizierungen im Bereich Windows und Active Directory Sicherheit besitzt. Dazu können zum Beispiel die praktischen Zertifizierung Certified Red Team Professional (CRTP) oder Certified Red Team Expert (CRTE) gehören. Jedoch auch viele andere Weiterbildungen im Bereich Azure AD und Windows Umgebungen.
Die meisten Organisationen und Unternehmen verwenden das Active Directory in ihrer Infrastruktur als zentrale Lösung für die Verwaltung ihrer Ressourcen. Dabei stehen viele vor großen Herausforderungen bei der Absicherung und Stärkung dieser Active Directory-Umgebungen. Fehlendes Fachwissen, begrenzte Budgets, architektonische Herausforderungen aufgrund historisch-gewachsener Systemlandschaften sowie die daraus resultierende Notwendigkeit, Legacy-Systeme zu unterstützen, sind mögliche Ursachen für anfällige IT-Systeme.
Für Bedrohungsakteure stellt das Active Directory eine verlockende Zielscheibe dar, da eine erfolgreiche Kompromittierung in der Regel Zugang zu fast allen Unternehmensressourcen ermöglicht. Dies bietet Angreifern eine ideale Möglichkeit, z. B. Ransomware in das Netzwerk einzuschleusen, um finanzielle Forderungen stellen zu können.
Durch das Bekanntwerden von Schwachstellen im Active Directory besteht jederzeit die Gefahr, dass ganze Active Directory-Umgebungen ohne großen Aufwand kompromittiert werden können. Dabei ist es zunächst einmal unerheblich, über welchen Account oder über welche Schwachstelle der Einbruch gelungen ist. Denn ist den Angreifern der initiale Einbruch in das Firmennetzwerk gelungen, suchen sie nach sogenannten „Low-Hanging-Fruits“ innerhalb der Active Directory Umgebung, um Ihre Rechte auszuweiten.
Gerade für kleinere und mittelständische Unternehmen gestaltet sich das frühzeitige Erkennen von Angriffen auf das Active Directory als schwierig. Aufgrund der Firmengröße verfügen deren IT-Abteilungen in der Regel nicht über ein zureichendes Budget und die notwendigen Ressourcen für den Betrieb von Enterprise Security Lösungen wie SIEM oder EDRs. Doch gerade das rechtzeitige Erkennen von Angriffen ist entscheidend, um schnell zu reagieren und Schäden an der Reputation sowie finanzielle und datenschutzrechtliche Folgen zu vermeiden, bevor sie sich verschlimmern können.
Dennoch können mit Hilfe von „Deception“-Techniken auch Unternehmen, die lediglich über geringe IT-Security-Budgets verfügen, produktunabhängig bestimmte Angriffe wie Kerberoasting auf das Active Directory frühzeitig erkennen und deren Ausführung verzögern. Hierfür müssen gewisse Voraussetzungen erfüllt und präventive Maßnahmen bei der Nutzeranlage von sogenannten „Decoys“ getroffen werden. Diese „Decoys“ werden innerhalb einer Active Directory Umgebung platziert, um die Aufmerksamkeit von Angreifern auf diese zu ziehen, um so einen Alert auszulösen.
Praxisbeispiel: Anwendung von „Deception“-Techniken zur Erkennung von Kerberoasting Aktivitäten
Kerberoasting ist eine effiziente Technik für Angreifer, die lediglich über wenig Rechte innerhalb einer Domäne verfügen. Im Jahr 2014 präsentierte Tim Medin den Kerberoasting-Angriff bei seiner Präsentation „Attacking Microsoft Kerberos – Kicking the Guard Dog of Hades“ auf der Derbycon Konferenz. Beim Kerberoasting wird die Eigenheit bei der User-Anlage in Microsoft Kerberos ausgenutzt, dass jeder gültige Domain-User einen Ticket Granting Server (TGS) für einen beliebigen Dienst beantragen und anschließend das Ticket für Offline-Passwort-Cracking-Versuche verwenden kann.
Je nach Stärke der Passwörter können Angreifer in kurzer Zeit und in den meisten Fällen relativ unbemerkt Benutzeraccounts kompromittieren und diese für weitere Angriffe verwenden.
Die einzige Voraussetzung für die Durchführung eines solchen Angriffs ist die Kenntnis über die existierenden Benutzerkonten, die einen sogenannten „Service Principal Name“ (SPN) gesetzt haben. Da alle existierenden SPNs mit einem simplen LDAP Query abgerufen werden können, stellt dies eine vergleichsweise geringe Einstiegsbarriere dar.
LDAP Query zum Extrahieren von allen Domain Accounts die einen SPN gesetzt haben
Gelingt es also dem Angreifer einzelne oder alle SPNs zu kennen, kann er im System Service Tickets (TGS) für ebenjene anfragen. Die durch die Abfrage erlangten Service-Tickets residieren im Arbeitsspeicher des Angreifers, aus welchem er diese anschließend extrahieren und auf einer Festplatte speichern kann. Nachdem der Eindringling nun über die TGS-Tickets aller Service Accounts verfügt, kann er versuchen, die verschlüsselten Teile der Tickets mit Hilfe eines Brute-Force-Angriffs zu entschlüsseln.
Cracking-Prozess von TGS-Tickets
Praktische Durchführung des Kerberoasting-Angriffs mit GetUserSPNs.exe
Zur praktischen Ausnutzung der gefundenen Schwachstelle in Microsoft Kerberos stehen mehrere öffentlich verfügbare Tools bereit. Die bekanntesten sind das Python-Skript GetUserSPNs.py und das PowerShell-Script Invoke-Kerberoast. In diesem Beispiel verwendet unser fiktiver Angreifer GetUserSPNs.exe (eine statisch kompilierte Version von GetUserSPNs.py für Windows) für die Durchführung.
Um den Angriff möglichst realistisch zu beschreiben, verfügt der Angreifer in unserem Szenario zunächst lediglich über ein unprivilegiertes Benutzerkonto, um die TGS Tickets anzufordern und deren Hashes für den Cracking-Prozess zu extrahieren. Dieser Account ist jedoch für das Tool GetUserSPNs.exe bereits ausreichend.
Durchführung des Angriffs mit GetUserSPNs.py
Die gewonnene Ausgabedatei kann im Anschluss in jedes beliebige Passwort-Cracking Tool importiert werden, mit deren Hilfe ein Offline-Brute-Force Angriff auf die extrahierten Hashes durchgeführt wird. Der Vorteil von Offline-Cracking Angriffen besteht darin, dass sie selbst keine Spuren im System des angegriffenen Unternehmens hinterlassen und somit nicht entdeckt werden können. Darüber hinaus ermöglichen sie eine deutlich höhere Anzahl von Brute-Force-Versuchen pro Sekunde im Vergleich zu jeglichen Online-Angriffen.
hashcat -a 0 -m 13100 -O kerberoasted_impacket.txt /opt/wordlists/Top2Billion-probable-v2/Top2Billion-probable-v2.txt -r rules/hob064.rule
Erfolgreiches Cracking eines der extrahierten Hashes
Wie in der oberigen Abbildung sichtbar, war es dem Passwort-Cracking-Tool möglich, einen der extrahierten Hashes in die Klartextform zurückzurechnen. Dem Angreifer erlaubt die gewonnene Information die Kontrolle über den betroffenen Account und ermöglicht es ihm so, seine Rechte im Netzwerk auszuweiten.
Anzeichen eines Kerberoasting-Angriffs im Domain-Controller
Auch wenn Kerberoasting-Angriffe vergleichsweise unbehelligt erfolgen, gibt es doch einige Hinweise, die ein aufmerksamer Administrator im Domain-Controller selbst erkennen kann. Denn analysiert man die Logging-Aktivitäten auf dem Domain-Controller während eines Angriffs, dann fallen folgende Events auf:
Relevanter Auszug des Event-Logs während des Angriffs
Die oben beschriebene Anfrage eines TGS-Tickets für einen SPN hinterlässt in Form der erzeugten Event-ID 4769 ihre Spuren im angegriffenen System. Sieht man sich das erzeugte Event genauer an, findet man dort weite Angaben zum angefragten „Service Name“, dem „Ticket Encryption Type“ sowie der IP-Adresse des anfragenden Systems. Diese Attribute helfen, einen Angriff frühzeitig zu erkennen.
Integration einer „Deception“-Technik mittels „Honeypot“-Accounts
Auch wenn Kerberoasting-Angriffe die oben beschriebenen Spuren im System hinterlassen, ist es doch relativ unwahrscheinlich, dass ein Administrator diese sofort bemerkt und dementsprechend zeitnah agieren kann. Daher ist es sinnvoll bereits bei der Implementierung der Active Directory die Deception-Techniken mit einzuplanen und umzusetzen.
Hierfür werden sogenannte „Decoys“ – also ungenutzte „Honeypot“-Accounts – erstellt, die als leere Attrappen für potenzielle Angreifer dienen. Hierbei wird die Tatsache ausgenutzt, dass während eines Kerberoasting-Angriffs mehrere Anomalien in den Windows-Logs zu sehen sind. Insbesondere die Tatsache, dass die bekannten Tools standardmäßig SPN-Tickets für alle Accounts, die ein „SPN-Attribut“ gesetzt haben, anfordern (siehe Abbildung 1: LDAP Query zum Extrahieren von allen Domain Accounts die einen SPN gesetzt haben), kann als Frühwarnsystem verwendet werden.
Diese „Honeypot“-Accounts haben nämlich keine eigentliche Funktion im Active Directory und sollten im Regelfall nicht verwendet werden. Im „normalen“ Betrieb werden für diese also keine „TGS“-Tickets für den Service angefragt. Ist dies doch der Fall, handelt es sich mit hoher Wahrscheinlichkeit um den Versuch eines Kerberoasting-Angriffs.
Bei der Anlage des Honeypot-Accounts im Active Directory gelten einige Besonderheiten im Vergleich zu normalen Usern, wie der folgende PowerShell-Befehl zeigt:
Nach Setzen des SPNs sollte folgende Meldung erscheinen:
Erstellung des Honeypot-Accounts und Setzen eines SPN
SPN-Anfragen für den Honeypot-Account mit Windows-Board-Mitteln frühzeitig erkennen
Wir verwenden in diesem Beispiel den Windows Event Viewer zur Erkennung eines potenziellen Angriffs, um zu demonstrieren, dass dies bereits mittels Standard-Funktionen innerhalb des Active Directorys bzw. Windows realisierbar ist. Selbstverständlich ist es auch möglich dies mittels Monitoring-Lösungen von Drittanbietern umzusetzen.
Der Windows Event Viewer bietet sich für das Tracking von Anomalien bei „Honeypot“-Accounts an, da dort sogenannte „Custom Views“ erstellt werden können, die nach spezifischen Events filterbar sind. Um Ticket-Anfragen des erstellten Honeypot Accounts herauszufiltern, kann folgende XML-Syntax verwendet werden:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[EventData[Data[@Name='ServiceName'] and (Data='dbadm')]]
and
*[System[(EventID='4769')]]
</Select>
</Query>
</QueryList>
Eine mögliche „Custom“-View würde bei einer SPN Ticket-Anfrage des Honeypot-Accounts wie folgt aussehen:
Custom-View zum Filtern von SPN-Anfragen für den angelegten Honeypot-Account
Die „Custom View“-Ansicht erlaubt neben der einfachen Anlage von Events auch die Einstellung von „geplanten Aufgaben“, die im Falle eines neuen Events für den im „Custom View“ eingestellten Filter ausgeführt werden.
Windows Event Viewer bietet dafür folgende bereits eingebaute Funktion an:
Erstellen eines Tasks in Bezug des erstellten „Custom Views“
In diesem Beispiel wird eingestellt, dass bei Auslösen des Events eine E-Mail an den „Administrator“ der AD-Umgebung gesendet wird.
Event Viewer Task führt ein PowerShell-Skript aus im Falle eines SPN-Requests für den betroffenen Account
Bei der Ausführung des Kerberoasting-Angriffs auf den Honeypot-Account erhält dieser eine E-Mail zur Alarmierung bei potenziell bösartigen Aktivitäten.
Automatisch versendete E-Mail nach der Anfrage eines SPN-Ticket für den „Honeypot“-Account
Fazit
Bereits mit einem geringen IT-Security-Budget ist es möglich, Angriffe wie Kerberoasting frühzeitig zu erkennen. Gelingt es, den Angriff zu verzögern oder im besten Fall sogar zu stoppen, können schlimmere Folgen für das Unternehmen abgewendet werden. Natürlich bilden derartige Alert-Systeme nur einen Baustein bei der Einführung und Umsetzung von Sicherheitssystemen, um die eigene IT-Infrastruktur zu schützen. Dennoch zeigt das Beispiel Kerberoasting, wie einfach und wirksam Deception-Techniken implementiert werden können.
Fast jeder kennt das Thema Spam: Man erhält E-Mails die von unschlagbaren Rabatten, Millionengewinnen für das eigene Portemonnaie oder einem gesperrten Bankaccount erzählen.
Während unseres Arbeitsalltages bei der Pentest Factory konnten wir jedoch eine weitaus effektivere Methode als Smishing aufdecken, die uns gezielt dazu verleiten sollte auf einen bösartigen Link zu klicken.
In diesem Fachartikel stellen wir die Techniken und unsere Analysen vor.
Penetrationstests sind ein sinnvolles Tool, um die Sicherheit von IT-Infrastrukturen sowie Anwendungen zu verbessern. Sie helfen dabei, Sicherheitslücken frühzeitig aufzudecken und bieten einem Unternehmen die Chance, Lücken noch vor einer realen Ausnutzung zu beheben. Penetrationstests stellen demnach ein effektives Mittel dar, um die Sicherheit eines Unternehmens zu erhöhen bzw. bestätigen zu lassen. Seien es Kundenanforderungen, eine bevorstehende Zertifizierung oder ein intrinsisches Bedürfnis Ihres Unternehmens nach Sicherheit. Oftmals ist die Durchführung eines Penetrationstests durch einen externen Dienstleister die zielführende Maßnahme.
Im Vorfeld der Beauftragung eines Penetrationstest wird jedoch häufig angenommen, dass das eigene Unternehmen prinzipiell sicher sei. Ein Penetrationstest sollte demnach nur wenige bis gar keine Schwachstellen identifizieren und eine Behebung dieser Feststellungen sollte ebenfalls zeitnah umgesetzt werden können. Der Einsatz monetärer Mittel und Personalressourcen sei überschaubar. Es wird demnach ein zeitnaher Pentest durch einen Externen durchgeführt, der die Sicherheit des eigenen Unternehmens mit einem grünen Siegel schriftlich festhält. Das klingt definitiv nach einem wünschenswerten Ablauf, nicht nur für Sie!
Eine der häufigsten Fragen im Initialgespräch mit Kunden"Was passiert eigentlich, wenn Sie keine Schwachstellen finden? Gibt es dann überhaupt einen Abschlussbericht?"
Problemstellung
In der Realität weichen die Ergebnisse eines Penetrationstests jedoch oftmals von dem erhofften Positiv-Ergebnis ab. Selbst in den wenigen Fällen, wo Anwendungen oder IT-Infrastrukturen sicher aufgebaut und betrieben werden, sind die dazugehörigen Pentest-Abschlussberichte in der Regel niemals leer. Eine Vielzahl eingesetzter Standardkonfigurationen von Webservern, Firewalls oder sonstigen Netzwerkkomponenten bieten eine Vielzahl an zu berichtender Feststellungen in einem Abschlussbericht. Gepaart mit einer standardisierten Risikobewertungsmethode wie das Common Vulnerability Scoring System (CVSS) landen solche Fehlkonfigurationen oftmals als Feststellung mit einem mittleren Risiko im Abschlussbericht.
Das Ergebnis des Penetrationstests wird daraufhin von Unternehmen als Überraschung wahrgenommen, da der Abschlussbericht die Sicherheit des Unternehmens nicht mit einem grünen Siegel bestätigt. Dadurch kommt oftmals die Notwendigkeit eines zweiten Tests, einer Wiederholungsprüfung nach Implementierung von Behebungsmaßnahmen, auf. Dies führt zu potenziell ungeplanten, jedoch erzwingenden Mehrkosten, da das Initialergebnis des Penetrationstests nicht an Dritte wie Kunden, Versicherungen usw. weitergereicht werden möchte.
Auch wenn dieser sehr wahrscheinliche Verlauf bereits im Vorfeld des Penetrationstests angesprochen wird und auch das Angebot bereits eine Wiederholungsprüfung inhaltlich sowie aufwandstechnisch aufführt, sind Kunden oftmals von dem Ergebnis eines Penetrationstests überrumpelt. Das Zusammenspiel aus einer fehlerhaften Erwartungshaltung und einer kognitiven Verzerrung wie „Survivorship Bias“, wo stets nur andere Firmen gehackt werden und man selbst noch nie einen Vorfall hatte, lassen die emotionale Erfahrung eines Penetrationstests oftmals negativ ausklingen.
Dies muss jedoch nicht sein. Durch eine eigenständige Vorbereitung auf einen Penetrationstest können vielzählige Feststellungen im Vorfeld vermieden werden. Hierdurch kommen Sie als Kunde Ihrem Wunschziel eines leeren Abschlussberichts etwas näher und ermöglichen uns Penetrationstester ein zielführenderes Testen. Dies kann zu einem frühzeitigeren Abschluss des Pentestprojekts führen und effektiv Kosten einsparen, sollte der Pentestanbieter wie die Pentest Factory transparent nach Maximalaufwänden abrechnen.
Möglichkeiten der Vorbereitung
Die Vorbereitungen auf einen Penetrationstest basieren natürlich auf den Rahmenparametern des zugrundeliegenden Penetrationstests. Da es eine Vielzahl von Testarten und Prüfobjekten gibt, werden wir uns auf allgemeine Vorbereitungsmöglichkeiten fokussieren. Diese können und sollten in einen internen Unternehmensprozess eingegliedert werden, der regelmäßig und bewusst durchgeführt wird. Unabhängig davon, ob ein Penetrationstest ansteht oder nicht.
Darüber hinaus möchten wir klarstellen, dass eine Vorbereitung im Vorfeld eines Penetrationstests nicht immer wünschenswert ist. Sollten Sie zum Beispiel seit Jahren die fehlenden Ressourcen für Ihre IT-Abteilung in der Geschäftsleitung ansprechen und endlich eine Freigabe zur Durchführung eines Penetrationstests erhalten, so sollten Sie im Vorfeld nichts selbst tätig werden. Eine temporäre Beschönigung der Ergebnisse wäre hier der falsche Ansatz, schließlich erhoffen Sie sich ein realitätsnahes Ergebnis des Penetrationstests, welches die aktuelle Situation und Abwehrkraft Ihres Unternehmens darstellt. Nur durch ein Negativergebnis können Sie Missstände in Ihrem Unternehmen auch für die Geschäftsleitung signalisieren. Auch bei der Durchführung von Phishing-Kampagnen, Interview-basierten Audits oder der Überprüfung Ihres externen IT-Dienstleisters sollten Sie die Füße still halten. Ein echter Angreifer kündigt sich schließlich auch nicht vorher an, um seine Opfer zu sensibilisieren.
Die folgenden Vorbereitungsmöglichkeiten stehen prinzipiell zur Auswahl:
Durchführung eines aktiven Portscans auf Ihre IT-Infrastrukturkomponenten
Identifizierung von nicht benötigten Netzwerkdiensten und Ports
Identifizierung von fehlerhaften Firewall-Regeln
Identifizierung von veralteten Softwarekomponenten und Schwachstellen inkl. CVEs
Identifizierung von typischen Fehlkonfigurationen
die Preisgabe von Versionsinformationen in HTTP-Header und Softwarebannern
Der Einsatz von Inhalten aus einer Standardinstallation (IIS Default Webseite, Nginx oder Apache „It works“ Webseite)
Fehlende Weiterleitung von unverschlüsseltem HTTP auf das sichere HTTPS Protokoll
uvm.
Durchführung eines automatisierten Schwachstellenscans
Eigenständige Identifizierung sogenannter „Low-hanging fruit“ Feststellungen eines Penetrationstests
Identifizierung von veralteten und unsicheren Softwarekomponenten inkl. CVEs
Erhalt von empfohlenen Maßnahmen zur Behebung der identifizierten Schwachstellen
In diesem Blogeintrag fokussieren wir uns auf die Durchführung von aktiven Portscans mittels des populären Portscanning-Tools „Nmap“. Die Resultate werden hierbei visuell als HTML-Ergebnisdatei aufbereitet, um Probleme identifizieren zu können. Darüber hinaus reißen wir den Einsatz von automatisierten Schwachstellenscannern wie Greenbone OpenVAS oder Nessus Community an.
Durchführung von Portscans
Für alle nicht technischen Leser dieses Blogeintrags möchten wir kurz erläutern, was Portscanning ist und welche Vorteile es mitbringt. Netzwerkdienste, wie beispielsweise ein Webserver zur Bereitstellung einer Homepage, werden auf sogenannten Netzwerkports betrieben. Ein Netzwerkport ist eine eindeutige Adresse, mit deren Hilfe sich Verbindungen eindeutig zu Anwendungen zuordnen lassen. Eine Webseite wie dieser Blog wartet demnach auf eingehende Verbindungen auf den standardisierten Ports 80 und 443. Der Netzwerkport 80 wird hierbei üblicherweise für eine unverschlüsselte Verbindung (HTTP) eingesetzt und sollte automatisch auf den sicheren Port 443 weiterleiten. Hinter dem Port 443 verbirgt sich das sichere und verschlüsselte HTTPS-Protokoll, welches die Seiteninhalte vom Server lädt und Ihrem Clientbrowser zur Darstellung bereitstellt. Aus Angreifersicht sind diese Netzwerkports sehr interessant, da sich hinter diesen üblicherweise Dienste oder Anwendungen befinden, die potenziell angegriffen werden können. Insgesamt gibt es 65353 Ports, jeweils für verbindungslose (UDP) als auch verbindungsorientierte Kommunikationsprotokolle (TCP). Die Zuordnung zwischen einem Port und dem dahinter befindlichen Dienst ist standardisiert. Jedoch kann die Konfiguration frei variieren und muss sich nicht nach dem Standard richten. Aus der Sichtweise eines Angreifers müssen diese Ports also enumeriert werden, um zu wissen, welche Dienste angegriffen werden können. Aus Unternehmenssicht sind diese Ports wichtig, um sicherzustellen, dass nur diejenigen Dienste angeboten werden, die auch erreicht werden sollen. Alle nicht benötigten Dienste sollten geschlossen werden oder deren Eingangstür von einer Firewall abgesichert werden.
Die Identifizierung von Netzwerkports kann mittels frei verfügbarer Netzwerktools erfolgen. Eines der bekanntesten Tools zur Identifizierung von offenen Ports und Erkennung von Netzwerkdiensten nennt sich „Nmap“. Dieses Programm ist kostenlos, quelloffen und kann sowohl unter Windows als auch Linux gestartet werden. Es stellt eine Vielzahl von Aufrufparametern bereit, welche im Detail nicht gänzlich erklärt und besprochen werden können.
Nichtsdestotrotz möchten wir Ihnen mit diesem Blogeintrag die grundlegenden Informationen vermitteln, um eigene Scans durchführen zu können. Für den erfolgreichen Start eines Nmap Portscans benötigen Sie lediglich die IP-Adresse(n) der zu überprüfenden IT-Systeme. Alternativ können Sie auch den DNS-Hostnamen bereitstellen und Nmap löst die dahinter befindliche IP-Adresse selbstständig auf.
Mithilfe des folgenden Befehls können Sie nach der Installation von Nmap einen Portscan starten. Hierbei werden alle offenen TCP-Ports der Range 0-65535 identifiziert und zurückgegeben. Eine Erklärung der Aufrufparameter finden Sie hier.
Als Resultat erhalten Sie drei Ergebnisdateien sowie eine Ausgabe in Ihrem Terminalfenster wie folgt:
Die Ergebnisse des ersten Portscans listen lediglich die als offen identifizierten Netzwerkports auf. Zusätzlich erhalten wir den dahinter befindlichen Netzwerkdienst, welcher sich standardmäßig hinter dem Port befinden sollte (RFC Standard). Wie jedoch bereits erwähnt, müssen sich Netzwerkbetreiber nicht an diese Portzuordnungen halten und können ihre Dienste tendenziell hinter jeglichem Port betreiben. Aus diesem Grund benötigen wir einen zweiten Portscan, um die echten Netzwerkdiensten hinter den nun als offen identifizierten Ports offenzulegen.
Hierzu führen wir den folgenden Befehl aus, unter Angabe der zuvor identifizierten Ports und derselben IT-Systeme, die gescannt werden sollen. Eine Erklärung der Aufrufparameter finden Sie hier.
Nach Abschluss erhalten wir erneut drei Ergebnisdateien sowie eine erneute Ausgabe in dem Terminalfenster wie folgt:
Die resultierende „nmap_advanced_portscan.xml“ Datei kann darüber hinaus mit einem Browser Ihrer Wahl geöffnet werden, um die Ergebnisse des Portscans als HTML-Webseite visuell darzustellen. HTML-Berichte werden von Nmap zwar standardmäßig nicht unterstützt, jedoch kann ein individuelles Stylesheet wie „https://raw.githubusercontent.com/pentestfactory/nmap-bootstrap-xsl/main/nmap-bootstrap.xsl“ beim Scanaufruf definiert werden, welches die Ergebnisse als HTML-Bericht visualisiert. Weiterhin können die Ergebnisse gefiltert werden und es besteht eine Möglichkeit zum CSV-, Excel- und PDF-Download.
Die Resultate des Portscans sollten nun von einem technischen Ansprechpartner, vorzugsweise aus der IT-Abteilung, überprüft werden. Stellen Sie hierbei sicher, dass lediglich die Netzwerkdienste von Ihren IT-Systemen angeboten werden, die zur Erbringung des Geschäftszwecks wirklich notwendig sind. Legen Sie darüber hinaus einen genauen Blick auf offenbarte Softwareversionen und überprüfen Sie, ob die eingesetzten Versionen aktuell sind und mit allen verfügbaren Sicherheitspatches gehärtet wurden. Überprüfen Sie ebenfalls identifizierte SSL-Zertifikate auf ihre Gültigkeit und halten Sie Abstand von der Verwendung von unsicheren Signierungsalgorithmen wie MD5 oder SHA1. Für interne IT-Infrastrukturen werden Sie in der Regel eine Vielzahl an Netzwerkdiensten identifiziert haben, da Sie von einer privilegierten Netzwerkposition innerhalb des Unternehmens gescannt haben. Hier sind Firewall-Einschränkungen in der Regel etwas weniger strikt umgesetzt, als für öffentlich erreichbare IT-Systeme oder Dienste innerhalb einer Demilitarisierten Zone (DMZ).
Durchführung von automatisierten Schwachstellenscans
Bei der Durchführung von Schwachstellenscans kommen in der Regel automatisierte Softwarelösungen zum Einsatz, welche IT-Systeme auf bekannte Schwachstellen und Fehlkonfigurationen hin überprüfen. Die resultierenden Feststellungen sind Probleme, welche öffentlich bekannt sind und für welche automatisierte Skripte geschrieben wurden, um diese zu erkennen. Bitte beachten Sie, dass automatisierte Schwachstellenscanner nicht in der Lage sind, alle potenziell vorhandenen Schwachstellen zu identifizieren. Jedoch sind sie eine große Hilfe, um standardmäßige Probleme schnell sowie automatisiert erkennen zu können.
Die regelmäßige Durchführung von automatisierten Schwachstellenscans sollte hierbei in Ihren internen Unternehmensprozess eingebunden werden. Dieser Prozess ist unabhängig davon, ob und wie oft Sie Penetrationstests durchführen lassen. Es wird jedoch allgemein empfohlen, ebenfalls Penetrationstest durch einen externen Dienstleister durchführen zu lassen, da hier sowohl automatisierte als auch manuelle Techniken zur Identifizierung von Schwachstellen Einsatz finden. Lediglich durch eine Kombination beider Testarten sowie dem Testen durch einen erfahrenen Penetrationstester können nahezu alle IT-Schwachstellen erkannt und letztlich von Ihnen behoben werden. Führen Sie demnach einen Schwachstellenmanagementprozess in Ihrem Unternehmen ein und scannen Sie Ihre IT-Assets regelmäßig und selbstständig.
Für die Durchführung eines automatisierten Schwachstellenscans kommen mehrere Produkte zum Einsatz. Für diesen Blogpost fokussieren wir uns auf kostenlose Alternativen. Dazu gehören die folgenden Produkte:
OpenVAS by Greenbone
Nessus Community by Tenable
Die Produkte sind nach einer Installation in der Regel selbsterklärend. Nach Angabe des Scan-Typs und der zu überprüfenden IT-Assets findet ein automatisierter Scan statt und die Resultate werden übersichtlich in der Webanwendung des Schwachstellenscanners dargestellt. Alle Feststellungen werden in der Regel mit einer Beschreibung, einer Risikobewertung sowie Empfehlung zur Behebung berichtet. Darüber hinaus erhalten Sie die Möglichkeit zum Exportieren der Ergebnisse als CSV, HTML, PDF usw.
Nicht nur für die Durchführung von Penetrationstests ist es interessant zu wissen, welche Schwachstellen in einem Softwareprodukt bestehen. Auch aus der Perspektive eines IT Teams kann es nützlich sein, schnell Informationen zu einer eingesetzten Produktversion zu erhalten. Bisher gab es für diese Form von Anfragen verschiedene Datenbanken wie z.B. https://nvd.nist.gov/vuln/search, https://cvedetails.com oder https://snyk.io/vuln
Über die letzten Jahre konnten wir jedoch folgende Probleme mit diesen Datenbanken feststellen:
Viele Datenbanken indizieren Schwachstellen nur für bestimmte Produktgruppen (z.B. Snyk: Web Technologien)
Viele Datenbanken führen eine Stichwortsuche durch. Eine Suche nach spezifischen Produktversionen ist somit ungenau
Viele Datenbanken sind nicht aktuell oder weisen Fehler auf
Abbildung: Fehlerhafte Schwachstelleninfos für Windows 10
Abbildung: Stichwortsuche zeigt anderes Produkt als das eigentlich gesuchte
Aus diesem Grund haben wir uns entschieden, eine eigene Lösung zu implementieren. Diese Lösung hat die folgenden Vorteile:
Produkte und Versionsnummern werden anhand eindeutiger Identifikatoren gesucht. Somit können die Suchergebnisse genauer beschränkt werden.
Unser System importiert täglich die Schwachstellendatenbank des National Institute of Standards and Technology (NIST). Schwachstellen sind somit tagesaktuell und haben einen verifizierten CVE Eintrag.
Wenn Schwachstellen in Produkten veröffentlicht werden, so registrieren Sicherheitsforscher gewöhnlich einen CVE Eintrag pro gefundener Schwachstelle. Diese CVE Einträge erhalten eine einzigartige ID, genaue Informationen, welche Produkte betroffen sind sowie eine Beschreibung der Schwachstelle.
CVEs lassen sich auf https://cve.mitre.org registrieren und werden von der National Vulnerability Database (NVD) in Echtzeit indiziert. (https://cve.mitre.org/about/cve_and_nvd_relationship.html) Hierbeit stellt das NIST öffentliche und frei nutzbare Dateisammlungen zur Verfügung, die alle registierten Schwachstellen enthalten. Wir nutzen dieses frei vefügbare Angebot als Basis für unsere eigene Datenbank.
Der vollständige technische Ablauf für den Import dieser Daten und die anschließende Bereitstellung als Datenbank werden im Folgenden geschildert:
Abbildung: Überblick der technischen Komponenten unserer Schwachstellendatenbank
1. Täglicher Import von Schwachstellendateien der NIST NVD
Die Dateisammlungen sind in Jahreszahlen unterteilt und werden von NIST täglich aktualisiert. Wir laden jede Nacht die neuesten Dateien auf unseren Dateiserver herunter.
2. Vor-Verarbeitung der Schwachstellendateien
Anschließend werden die Dateien nach dem Download vorverarbeitet, um Sie besser lesbar für den Elastic Stack Parser zu machen. Ein Vorgang der hierbei erfolgt ist eine Expandierung von allen JSON Dateien: Die Dateien enthalten die CVE Einträge als JSON Objekte, jedoch sind diese oft geschachtelt, was es dem Parser schwer macht einzelne Objekte zu erkennen. Wir lesen das JSON ein und schreiben alle Objektseparatoren sowie Parameter in separate Zeilen. Somit kann mittels eines Regex ( ‚^{‚ ) genau erfasst werden, wann ein neues Objekt beginnt.
Des weiteren bereinigen wir die Dateien von allen nicht benötigten Metadaten (z.B. Autor oder Versionsnummern der Datei), wodurch nur noch die CVE Einträge als gereihte JSON Objekte übrig bleiben.
3. Einlesen der vor-verarbeiteten Schwachstellendateien mittels Logstash
Nachdem die Daten in das bereinigte Format überführt wurden, kann unser Logstash Parser mittels des Multiline Codecs (https://www.elastic.co/guide/en/logstash/current/plugins-codecs-multiline.html) die einzelnen Zeilen einlesen und jedes Mal wenn ein vollständiges JSON Objekt erkannt wurde, schickt Logstash dieses CVE Objekt an unsere Elasticsearch Instanz weiter.
Der CVE Grepper – Datenformat und Suche von Schwachstellen
Nachdem nun alle CVE Einträge in unsere Elasticsearch Datenbank gespeist wurden, müssen wir verstehen, welches Format diese Einträge besitzen und wie wir nach spezifischen Produkten oder Produktschwachstellen suchen können. Unser finales Ergebnis ist in folgendem Screenshot sichtbar: Mittels eindeutigem Identifikator können wir alle Schwachstellen für die gesuchte Produktversion zurückgeben.
Wenn wir das generelle Datenformat von Produktversionen betrachten, so ist dieses in einer eigenen NIST Spezifikation definiert. Absatz 5.3.3 der Spezifikation gibt einen kurzen Überblick (https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf):
part: ist entweder ‚a‘ (application), ‚o‘ (operating system) oder ‚h‘ (hardware)
vendor: gibt den Hersteller des Produktes eindeutig an
product_name: gibt den Namen des Produktes eindeutig an
version: gibt die Versionsnummer des Produktes an
edition: veraltet
sw_edition: Versionsangabe für Marktbeschränkungen
target_sw: Softwareumgebung in der das Produkt verwendet wird
target_hw: Hardwareumgebung in der das Produkt verwendet wird
language: Unterstützte Sprache
other: anderweitige Beschreibungen
Der Doppelpunkt wird als Separator verwendet. Asterisk (*) als Wildcard-Symbol.
In unserem Screenshot: „cpe:2.3:o:juniper:junos:17.4r3:*:*:*:*:*:*:*“ können wir das Betriebssystem JunOS von Hersteller Juniper in der Version 17.4r3 als verwundbar für eine Schwachstelle bestimmen.
Beim Betrachten der JSON Datei ist ersichtlich, dass es zwei Formate gibt, in denen Versionsnummern für eine Schwachstelle angegeben werden.
Format 1: Mittels der Attribute „versionStartIncluding/versionStartExcluding“ und „versionEndIncluding/versionEndExcluding“ wird eine Spanne an verwundbaren Versionen definiert.
Format 2: Eine einzelne verwundbare Softwareversion wird im Attribut „cpe23Uri“ angegeben.
2. Durchsuchen der Datenbank
Um die Datenbank nach bestimmten Produkten zu durchsuchen muss zum einen eine einfache Produktsuche möglich sein, die anschließend den korrekten Produkspezifikator wählt, um in beiden beschriebenen Versionsformaten nach Treffern zu suchen. Wir haben uns hierbei für eine JavaScript Auto-Complete Variante entschieden, die Produkte und ihre CPE Werte dynamisch anzeigt:
Abbildung: Autocomplete-Funktion des Such-Frontends
Nachdem eine Auswahl getroffen wurde, können Schwachstellen für den cpe Produktidentifikator angefragt werden.
Ausblick: Kibana – Schwachstellen und Trends visualisieren
Ein großer Vorteil den die Speicherung von Schwachstellendaten in einer Elasticsearch Datenbank hat, ist die unmittelbare Anbindung an Kibana. Kibana stellt dabei eigenständig Anfragen an Elasticsearch und erzeugt hieraus Visualisierungen. Im Folgenden haben wir ein paar Darstellungsbeispiele unserer Schwachstellendaten ausgesucht:
Abbildung: Anzahl der registrierter Schwachstellen pro Jahr
Abbildung: Anteile der jeweiligen Risikobewertungsgruppen pro Jahr
Wir sehen großes Potential darin, diese Daten in Echtzeit auf unsere Homepage einzubinden und somit tagesaktuelle Statistiken zu Trends und Schwachstellen zur Verfügung zu stellen.
Ausblick – Threat Intelligence und Automatisierung
Ein weiterer Punkt auf unserer CVE Datenbank Roadmap ist die Programmierung eines Systems, dass Kunden automatisiert benachrichtigen kann, sobald neue Schwachstellen für einen CPE Identifikator gefunden wurden. Dadurch dass Elasticsearch eine sehr umfangreiche REST API zur Verfügung stellt, können wir auch diese Aufgabe mit dem bereits implementierten ELK Stack umsetzen.
Aktuell arbeiten wir an der Umsetzung der Kibana Live Statistiken auf der Homepage. Sobald dieser Meilenstein abgeschlossen ist, beginnen wir mit dem Thema „Threat Intelligence“. Wie Sie sehen können, beschäftigen wir uns bei der Pentest Factory GmbH nicht nur mit der Thematik Penetrationstests, sondern haben großes Interesse daran, interessante Forschungsbereiche der IT Sicherheit zu erschließen und unser Verständnis zu erweitern.
Unabhängig von der Unternehmensgröße oder der Branche müssen alle Unternehmen damit rechnen das Ziel von Cyberangriffen zu werden. Diese Cyberattacken sind nicht nur zielgerichtet, sondern passieren zufällig sowie automatisiert. Bei der Inbetriebnahme eines neuen Servers zur Bereitstellung einer Schwachstellendatenbank, ist uns aufgefallen, dass bereits in den ersten 20 Stunden des Online-Betriebs des Servers fast 800 Anfragen auf dem Webserver geloggt werden konnten. In diesem Fachartikel werden wir genauer betrachten, welchen Ursprung diese Anfragen haben und aufzeigen, dass Angreifer längst nicht mehr nur bekannte Systeme und Unternehmen ins Visier nehmen. Natürlich geben wir auch konkrete Empfehlungen, um Systeme gegen diese Angriffe abzusichern.
Legitime Anfragen an die Schwachstellendatenbank (37%)
In einem ersten Schritt wollen wir alle Anfragen aus der Logdatei filtern, die reguläre Anfragen an die Schwachstellendatenbank darstellen und von uns zu Testzwecken ausgeführt wurden. Hierzu filtern wir alle bekannten Quell-IP-Adressen sowie gewöhnliche Anfragen auf bestehende Endpunkte. Die Schwachstellendatenbank stellt dabei die folgenden API Endpunkte für die Abfrage von Schwachstellendaten zur Verfügung:
/api/status
/api/import
/api/query_cve
/api/query_cpe
/api/index_management
Nach unserer ersten Analyse konnten wir feststellen, dass von insgesamt 724 Anfragen 269 Anfragen legitime Anfragen an die Schwachstellendatenbank darstellen:
Abbildung 1: Auszug legitimer Anfragen an den Webserver
Doch welchen Ursprung haben die verbleibenden 455 Anfragen?
Verzeichnisenummerierung von administrativen Backends für Datenbanken (14%)
Eine einzelne IP-Adresse fiel besonders auf: Mit 101 Anfragen versuchte ein Angreifer diverse Backends für die Datenbankadministrierung zu finden:
Abbildung 2: Scannen von Verzeichnissen um Datenbank-Backends zu finden
Schwachstellenscans unbekannter Quellen (14%)
Weiterhin konnten wir 102 Anfragen identifizieren, bei denen unsere Versuche die Quell-IP-Adressen zu identifzieren (mittels nslookup, user-agent) erfolglos waren. Die 102 Anfragen stammen von 5 verschiedenen IP-Adressen oder Subnetzbereichen. Somit wurden pro Schwachstellenscan ca. 20 Anfragen ausgeführt.
Abbildung 3: Verschiedene Schwachstellenscans mit unbekannter Herkunft
Geprüfte Komponenten waren dabei:
boaform Admin Interface (8 Anfragen)
/api/jsonws/invoke: Liferay CMS Remote Code Execution und andere Exploits
Anfragen auf / (11,5%)
Insgesamt konnten wir 83 Anfragen feststellen, die die Index-Datei des Webservers angefragt haben. Diese dienen zur Ermittlung, ob ein Webserver online ist und zur Identifikation, welcher Dienst initial zurückgegeben wird.
Abbildung 4: Index-Anfragen verschiedener Quellen
Hierbei konnten wir verschiedene Anbieter und Tools identifizieren, die unseren Webserver auf Erreichbarkeit geprüft haben:
Während unserer Auswertung der Logdatei konnten wir weitere 65 Anfragen identifzieren, die von zwei IP Adressen stammen, die in Ihrem User-Agent die Adresse „leakix.net“ nennen:
Abbildung 5: Schwachstellenscan von leakix.net
Auf der Seite selbst wird erklärt, dass der Dienst das gesamte Internet zufällig auf bekannte Schwachstellen durchsucht:
autodiscover.xml: Versuch, das Administratorkonto des Exchange Servers zu ermitteln
\owa\auth\: Ordner in den Shells nach einer Kompromittierung für weiteren Fernzugriff geladen werden
Abbildung 7: Versuchte Ausnutzung der HAFNIUM/Proxlogon Exchange Schwachstellen
NGINX .env Preisgabe von sensitiven Informationen der Serverumgebung (1,5%)
11 Anfragen haben versucht die .env Datei im Webserver Wurzelverzeichnis auszulesen. Diese Datei kann oft sensitive Umgebungsvariablen (und Passwörter) enthalten.
Abbildung 8: Versuch die .env Datei des Servers auszulesen
Verbleibende Anfragen (10,2%)
Weitere 58 Anfragen waren nicht Teil eines größeren Scans und haben gezielt einzelne Schwachstellen abgefragt:
Server-Side Request Forgery Versuche: 12 Anfragen
CVE-2020-25078: D-Link IP Kamera Admin Passwort Exploit: 9 Anfragen
Hexkodierte Exploits/Payloads: 5 Anfragen
Spring Boot: Actuator Endpunkt zur Darstellung von Serverinformationen: 3 Anfragen
Verschiedene einzelne Exploits oder Schwachstellentests: 27 Anfragen
Weiterhin wurden die folgenden harmlosen Dateien angefragt:
favicon.ico – Lesezeichen-Grafik: 7 Anfragen
robots.txt – Datei für Suchmaschinenindizierung: 9 Anfragen
Fazit
Mit Tools wie zmap scannen Angreifer das gesamte Internet in unter 5 Minuten (siehe https://www.usenix.org/system/files/conference/woot14/woot14-adrian.pdf). Die aufgeführten Statistiken haben gezeigt, dass IT-Systeme ein unmittelbares Ziel automatisierter Angriffe und Schwachstellenscans sind, sobald diese von außen aus dem Internet erreichbar sind. Die Größe eines Unternehmens oder der Bekanntheitsgrad spielen hierbei keine Rolle, da Angreifer das komplette Internet nach anfälligen Hosts durchforsten und oftmals den vollständigen IPv4-Adressraum abdecken. Selbst unter Einsatz herkömmlicher IT-Infrastrukturkomponenten wie z.B. Reverse Proxies oder Load Balancers, die lediglich unter Angabe eines validen Hostnamens eine Anwendung zurückgeben, können sich automatisierte Angriffe ereignen. Der Hostname ist nämlich, wie oftmals fälschlicherweise angenommen, kein Geheimnis bzw. ein ausreichender Schutz vor unautorisierten Zugriffen. Bereits bei der Anforderung von SSL-Zertifikaten für Ihre Dienste und Applikationen werden Hostnamen in sogenannten SSL-Transparency-Logs protokolliert und stehen öffentlich zur Einsicht verfügbar. Hierdurch können sich erneut automatisierte Angriffe ereignen, da die Hostnamen durch Online-Dienste wie crt.sh öffentlich in Erfahrung gebracht werden können. Weitere Informationen finden Sie in unserem Fachartikel Subdomains unter der Lupe: SSL Transparency Logs.
Die Implementierung von Zugriffskontrollen oder Härtungsmaßnahmen zum Schutz vor unautorisierten Handlungen in Ihren Diensten und Anwendungen muss demnach noch vor der eigentlichen Veröffentlichung im Internet erfolgen. Denn sobald ein IT-System im öffentlichen Internet erreichbar ist, müssen Sie mit aktiven Angriffsversuchen rechnen, die im schlimmsten Fall Erfolg haben könnten.
Empfehlung
Lediglich notwendige Netzwerkdienste bereitstellen
Bei der Veröffentlichung von IT-Systemen in das öffentlich erreichbare Internet sollten lediglich diejenigen Netzwerkdienste preisgegeben werden, die für den Geschäftszweck notwendig sind und nach außen hin offenbart werden müssen. Bei dem Betrieb einer Webanwendung oder Dienst auf Basis des HTTP-Protokolls ist dies in der Regel der eingesetzte Webserver, dessen Netzwerkdienst üblicherweise über den TCP-Port 443 angeboten wird.
Halten Sie davon Abstand, den kompletten Host, also alle verfügbaren Netzwerkdienste eines IT-Systems, im Internet preiszugeben.
Netzwerktrennung
Implementieren Sie eine demilitarisierte Zone (DMZ) mittels Firewalls, um eine zusätzliche Netztrennung zwischen dem öffentlichen Internet und Ihrer internen IT-Infrastruktur zu erhalten. Platzieren Sie alle Infrastrukturkomponenten, welche Sie nach außen ins Internet preisgeben möchten, in der dafür entworfenen DMZ. Weitere Informationen finden Sie im IT-Grundschutz-Katalog des Bundesamts für Sicherheit in der Informationstechnik (BSI).
Patch-Management und Inventarisierung
Halten Sie alle Softwarekomponenten auf einem aktuellen Stand und richten Sie einen Patch-Management-Prozess ein. Führen Sie eine Inventarisierung über alle IT-Infrastrukturkomponenten ein, unter Auflistung der eingesetzten Softwareversionen, virtuellen Hostnamen, SSL-Zertifikatsablauf, Konfigurationseinstellungen und Co.
Härten Sie Ihre offenbarten Netzwerkdienste und IT-Komponenten nach Angaben des Herstellers bzw. den spezifischen Härtungsempfehlungen des Center for Internet Security (CIS). Ändern Sie zudem alle Standardpasswörter oder einfache Logins aus der Entwicklungszeit ab und konfigurieren Sie Ihre Dienste für den produktiven Betrieb. Dazu gehört ebenfalls die Deaktivierung von Debug-Features oder Test-API-Endpunkte. Implementieren Sie weiterhin alle empfohlenen HTTP-Response-Header und härten Sie Ihre Webserver-Konfiguration. Stellen Sie sicher, dass sensitive Cookies über das Secure, HttpOnly und SameSite Cookie-Flag verfügen, falls möglich.
Transportverschlüsselung
Achten Sie darauf, Ihre Netzwerkdienste über einen verschlüsselten Kommunikationskanal anzubieten. Dies stellt die Vertraulichkeit und Integrität von Daten sicher und sorgt dafür, dass die Authentizität Ihres Servers validiert werden kann. Halten Sie Abstand von der Verwendung von veralteten Algorithmen wie RC4, DES, 3DES, MD2, MD4, MD5 oder SHA1. Verwenden Sie SSL-Zertifikate, welche von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt worden sind, wie z.B. von Let’s Encrypt. Halten Sie Ihre Zertifikate fortlaufend aktuell und erneuern Sie diese frühzeitig. Verwenden Sie für jeden Ihrer Dienste ein einzigartiges SSL-Zertifikat unter Nennung des korrekten (Sub)Domainnamen im Common Name des Zertifikats. Die Verwendung von SSL-Wildcard-Zertifikaten ist lediglich in seltenen Fällen notwendig und zu empfehlen.
Zugriffsschutz und zusätzliche Sicherheitslösungen
Beschränken Sie den Zugriff auf Ihre Netzwerkdienste, sollten diese nicht für alle Teilnehmer im öffentlichen Internet zur Verfügung stehen. Hierbei kann es sich anbieten, ein IP-Whitelisting einzurichten, wodurch lediglich Anfragen von vertrauenswürdigen, statischen IPv4-Adressen entgegengenommen werden. Konfigurieren Sie dieses Verhalten entweder in Ihrer eingesetzten Firewall-Lösung oder unmittelbar in dem bereitgestellten Netzwerkdienst, falls möglich. Alternativ können auch SSL-Client-Zertifikate oder Basic-Authentication eingerichtet werden.
Implementieren Sie für Ihre Netzwerkdienste zusätzliche Sicherheitslösungen wie Intrusion Prevention Systeme (IPS) oder eine Web Application Firewall (WAF), um einen zusätzlichen Schutz gegenüber Angriffen zu erhalten. Als IPS können wir die quelloffene Software Fail2ban empfehlen. Als WAF kann ModSecurity mit dem bekannten OWASP Core Rule Set eingerichtet werden.
Fail2ban ist ein in Python geschriebenes Intrusion Prevention System, welches auf Basis von Protokolleinträgen (Logs) und Regex-Filtern auffällige Aktivitäten identifizieren und automatische Maßnahmen ergreifen kann. So ist es z.B. möglich, automatisierte Schwachstellenscans, Brute-Force-Angriffe oder Bot-basierte Anfragen erfolgreich zu erkennen, blockieren und Angreifer mittels IP-Tables zu bannen. Fail2ban ist eine quelloffene Software und kann kostenfrei eingesetzt werden.
Installation von Fail2ban
Fail2ban kann in der Regel über die reguläre Paket-Verwaltung Ihrer Linux-Distribution installiert werden. Dazu genügt der folgende Befehl:
sudo apt update && sudo apt install fail2ban
Danach sollte der Fail2ban-Dienst automatisch gestartet worden sein. Überprüfen Sie dies mittels des folgenden Befehls:
sudo systemctl status fail2ban
Konfiguration von Fail2ban
Nach der Installation von Fail2ban steht ein neues Verzeichnis namens /etc/fail2ban/ zur Verfügung, worunter alle relevanten Konfigurationsdateien vorgefunden werden können. Standardmäßig werden zwei Konfigurationsdateien /etc/fail2ban/jail.conf und/etc/fail2ban/jail.d/defaults-debian.conf mitgeliefert. Diese sollten jedoch nicht bearbeitet werden, da sie bei einer Paketaktualisierung überschrieben werden können.
Stattdessen sollten spezifische Konfigurationsdateien mittels der .local Erweiterung angelegt werden. Konfigurationsdateien mit dieser Dateierweiterung überschreiben Direktiven in der übergeordneten .conf Konfigurationsdatei. Für die meisten Benutzer ist der einfachste Konfigurationsweg die mitgelieferte Datei jail.conf nach jail.local zu kopieren und anschließend die .local-Datei abzuändern. Die .local-Datei muss hierbei nicht alle Einstellungen aus der .conf-Datei enthalten, sondern nur diejenigen, die Sie überschreiben möchten.
Fail2ban für SSH
Nach der Installation von Fail2ban ist standardmäßig bereits der Schutz für den Netzwerkdienst SSH auf dem default TCP-Port 22 aktiv. Sollten Sie einen anderweitigen TCP-Port für Ihren SSH-Netzwerkdienst einsetzen, so müssen Sie die Konfigurationseinstellung port in Ihrer jail.local Datei für die SSH-Jail anpassen. Hier können Sie ebenfalls wichtige Direktiven wie findtime, bantime und maxretry anpassen, sollten Sie eine spezifischere Konfiguration benötigen. Sollten Sie diesen Schutz nicht benötigen, so können Sie ihn über die Direktive enabled auf den Wert false setzen. Weitere Informationen finden Sie unter: https://wiki.ubuntuusers.de/fail2ban/
Fail2ban für Webdienste
Weiterhin kann mittels Fail2ban ein Schutz vor automatisierten Webangriffen eingerichtet werden. Hierbei können beispielsweise Angriffe zur Enumeration von Webverzeichnissen (Forceful Browsing) oder bekannte Anfragen von Bots zur Durchführung von Schwachstellenscans erkannt und blockiert werden.
Die Community stellt hierfür bereits vorgefertigte Konfigurationsdateien zur Verfügung, welche verwendet werden können:
Legen Sie diese beispielhaften Filter-Konfigurationen in dem Verzeichnis /etc/fail2ban/filter.d/ ab und konfigurieren Sie eine neue Jail in Ihrer jail.local Datei. Ein Beispiel folgt.
Blockieren von Suchanfragen durch Bots
Automatisierte Bots und Schwachstellenscanner durchforsten fortlaufend das gesamte Internet, um anfällige IT-Hosts zu identifizieren und Exploits auszunutzen. Hierbei kommen oftmals bekannte Tools zum Aufdecken solcher Schwachstellen zum Einsatz, dessen Namen bei HTTP-Anfragen im User-Agent HTTP-Header mitgeschickt werden. Anhand diesem Header können viele einfache Bot-Angriffe erkannt und aktiv blockiert werden. Angreifer können diesen Header jedoch auch abändern, wodurch ausgeklügelte Angriffe unentdeckt bleiben. Die Fail2ban-Filter *badbots.conf sind in der Regel solche Filter, die auf dem HTTP-Header „User-Agent“ basieren.
Alternativ bietet es sich an, alle Anfragen zu verwerfen, welche ein typisches Angriffs-Muster an den Tag legen. Dazu gehören unter anderem automatisierte Anfragen, welche fortlaufend versuchen, Dateien oder Verzeichnisse auf einem Webserver zu identifizieren. Da diese automatisierten Angriffe eine Vielzahl von Dateien und Verzeichnisnamen zufällig anfragen, ist die Wahrscheinlichkeit gegeben, dass viele dieser Versuche ins Leere führen und eine 404 Not Found Fehlermeldung verursachen. Anhand dieser Fehlermeldungen und dazugehörigen Logs kann Fail2ban einen Angriffsversuch erkennen und das Angreifer-System frühzeitig bannen.
Hier am Beispiel eines nginx Webservers:
1. Speichern Sie die folgende Datei unter /etc/fail2ban/filter.d/nginx-botsearch.conf
2. Fügen Sie die folgenden Konfigurationsanweisungen in Ihrer /etc/fail2ban/jail.local ein:
[nginx-botsearch] ignoreip = 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 enabled = true port = http,https filter = nginx-botsearch logpath = /var/log/nginx/access.log bantime = 604800 # Bann für 1 Woche maxretry = 10 # Bann bei 10 Fehlermeldungen findtime = 60 # zurücksetzen von maxretry nach 1 Minute
3. Inkludieren Sie falls nötig weitere vertrauenswürdige IP-Adressen unter ignoreip Ihres Unternehmens, welche von Fail2ban erlaubt und nicht blockiert werden sollen. Passen Sie ggf. die anderweitigen Direktiven auf Ihre Wünsche hin an und verifizieren Sie den angegebenen Port Ihres Webservers sowie dass der Logpfad /var/log/nginx/access.log vorhanden und ausgelesen werden kann.
4. Starten Sie anschließend den Fail2ban-Dienst neu
sudo systemctl restart fail2ban
Bei automatisierten Suchanfragen zum Auffinden von Verzeichnissen und Dateien können nun Bots gebannt werden, welche mehr als zehn 404-Fehlermeldungen innerhalb einer Minute erzeugen. Die IP-Adresse des angreifenden Systems wird anschließend von Fail2ban mittels IP-Tables automatisch für eine Woche gebannt und anschließend automatisch wieder freigegeben. Auf Wunsch können Sie sich durch weitere Konfigurationseinstellungen per E-Mail über IP-Banns informieren lassen. Eine Push-Benachrichtigung ans Smartphone über einen Telegram-Messenger-Bot in Fail2ban ist ebenfalls denkbar.Allgemein ist Fail2ban sehr anpassbar und erlaubt beliebig viele banactions, wie z.B. selbst entwickelte Shell-Skripte, sollte ein Filter greifen.
Um bereits gebannte IP-Adressen anzeigen zu lassen, verwenden Sie den folgenden Befehl:
Verfügbare Jails anzeigen lassen
sudo fail2ban-client status
Gebannte IP-Adresse der Jail anzeigen
sudo fail2ban-client status
Fail2ban bietet viele weitere Möglichkeiten, um Ihre Dienste zusätzlich abzusichern. Informieren Sie sich gerne über zusätzliche Filter und implementieren Sie diese, falls gewünscht. Alternativ können Sie auch eigene Filter unter Verwendung von Regex kreieren und diese auf Logeinträge testen.
Um unsere Infrastruktur gegen Angriffe abzusichern und Schachstellen zu finden, sind interne Penetrationstests ein fester Bestandteil unserer Strategie. Wir prüfen dabei besonders die Systeme, die zur Verarbeitung von Kundendaten eingesetzt werden. In einem Penetrationstest unserer Homepage vor dem initialen Go-Live konnten wir dabei zwei Schwachstellen in dem bekannten WordPress-Plugin NEX Forms zur Erstellung und Verwaltung von Formularen identifizieren.
Nach der Entdeckung haben wir die Schwachstellen an den Hersteller weitergeleitet, womit diese im nächsten Release geschlossen werden konnten. Weitere Details finden sich hierzu im folgenden Beitrag.
Hintergrund
NEX-Forms ist ein beliebtes WordPress-Plugin für die Erstellung von Formularen sowie der Verwaltung übermittelter Formulardaten. Es wurde bereits über 12.500 mal verkauft und kann auf vielen WordPress-Webseiten vorgefunden werden. Das Plugin bietet zusätzlich eine Funktion zur Erstellung von Formular-Berichten an, wobei diese entweder als PDF- oder Excel-Datei exportiert werden können. In genau dieser Komponente konnten wir zwei Schwachstellen identifizieren.
CVE-2021-34675: NEX Forms Authentication Bypass für PDF Berichte
Der „Reporting“ Bereich des NEX-Forms-Backends erlaubt es Nutzern, Formulareinsendungen zu aggregieren und diese in das PDF-Format zu überführen. Sobald eine Auswahl als PDF exportiert wird, speichert der Server die Ergebnisdatei unter dem folgenden Pfad:
/wp-content/uploads/submission_report.pdf
Darstellung des Formulars der NEX Forms schwachstelle
Abbildung 1: Exportfunktionen im „Reporting“ Bereich
Während unserer Tests konnten wir feststellen, dass diese Exportdatei nicht zugriffsgeschützt ist. Ein Angreifer kann somit die Datei ohne Authentifizierung herunterladen:
Abbildung 2: Proof-of-Concept: Zugriff auf die PDF-Datei ohne Authentifizierung
CVE-2021-43676: NEX Forms Authentication Bypass für Excel Berichte
Ähnlich zur zuvor beschriebenen Feststellung existiert eine weitere Schwachstelle für die Export-Funktion in das Excel-Format. Hierbei wird die Excel-Datei nicht im Dateisystem des Webservers abgelegt, sondern durch den Server direkt zurückgegeben.
Um die Schwachstelle auszunutzen muss zunächst ein Bericht in das Excel-Format exportiert worden sein. Der Server gibt danach die letzte erzeugte Excel-Datei zurück, sobald im Backend der GET Parameter „export_csv“ mit dem Wert „true“ übergeben wird. Für diesen URL-Handler werden jedoch keine Authentifizierungsparameter geprüft, was es einem Angreifer erlaubt, ohne Authentifizierung auf die Inhalte zuzugreifen:
Abbildung 3: Proof-of-Concept: Zugriff auf die Excel-Datei ohne Authentifizierung
Mögliche Auswirkungen
Ein Angreifer, der eine dieser Authentifizierungslücken ausnutzt, könnte unter anderem folgende Schäden bewirken:
Zugriff auf vertrauliche Daten, die über das Kontaktformular eingesendet wurden
Zugriff auf personenbezogene Daten wie Name, E-Mail-Adresse, IP-Adresse oder Telefonnummern
Dies könnte zu einem signifikanten Verlust der Vertraulichkeit, der von NEX-Forms verarbeiteten Daten, führen.
Abbildung: Fehlerhafte Schwachstelleninfos für Windows 10
Abbildung: Stichwortsuche zeigt anderes Produkt als das eigentlich gesuchte
Abbildung: Überblick der technischen Komponenten unserer Schwachstellendatenbank
Abbildung: Vorschau unseres Schwachstellen-Suche Frontends
Abbildung: Autocomplete-Funktion des Such-Frontends
Abbildung: Anzahl der registrierter Schwachstellen pro Jahr
Abbildung: Anteile der jeweiligen Risikobewertungsgruppen pro Jahr
Abbildung 1: Auszug legitimer Anfragen an den Webserver
