5 Irrtümer bei Pentest Ergebnissen

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.

Worauf achten bei Pentests? Qualitätsmerkmale erklärt.

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.

Frühzeitiges Erkennen von Angriffen auf Active Directory mithilfe von „Deception“-Techniken

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.

active directory deception
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.

active directory deception
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.

active directory deception
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
active directory deception
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:

active directory deception
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:

New-ADUser -Name "DBAdmin" -DisplayName "DBAdmin" -SamAccountName "dbadm" -description "DatabaseAdministrationAccount" -UserPrincipalName "dbadm" -GivenName "Database" -Surname "Administrator" -AccountPassword ((ConvertTo-SecureString "kd329-/Sl2(2)02(§23kcJk3A$" -AsPlainText -Force)) -Enabled $true -Path "OU=ServiceAccounts, OU=AdministrativeAccounts, DC=WINDOMAIN, DC=LOCAL" -ChangePasswordAtLogon $false -PasswordNeverExpires $true

Im Anschluss kann mithilfe des „setspn“-Befehls eine SPN für den betroffenen Account gesetzt werden.

setspn -s http/wef.windomain.local:1433 windomain.local\dbadm

Nach Setzen des SPNs sollte folgende Meldung erscheinen:

active directory deception
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:

active directory deception
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:

active directory deception
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.

active directory deception
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.

active directory deception
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.

Angriff per SMS? Smishing unter der Lupe

Angriff per SMS? Smishing unter der Lupe

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.

Lies weiter

Die Vorbereitung auf einen Penetrationstest

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! 

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.

nmap -sS -Pn –open –-min-hostgroup 256 –min-rate 5000 –max-retries 3 -oA nmap_fullrange_portscan -vvv -p- <IP-1> <IP-2> <IP-RANGE>

Als Resultat erhalten Sie drei Ergebnisdateien sowie eine Ausgabe in Ihrem Terminalfenster wie folgt:

wMocvrl++Hd7gAAAABJRU5ErkJggg==

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.

nmap -sS -sV –script=default,vuln -Pn –open –-min-hostgroup 256 –min-rate 5000 –max-retries 3 –script-timeout 300 -d –stylesheet https://raw.githubusercontent.com/pentestfactory/nmap-bootstrap-xsl/main/nmap-bootstrap.xsl -oA nmap_advanced_portscan -vvv -p <PORT1>, <PORT2>, <PORT3> <IP-1> <IP-2> <IP-RANGE>

Nach Abschluss erhalten wir erneut drei Ergebnisdateien sowie eine erneute Ausgabe in dem Terminalfenster wie folgt:

yGQlDh5qNjcAAAAASUVORK5CYII=

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.

APvMurslNjwAAAAASUVORK5CYII=

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.

CVE Quick Search: Implementierung einer eigenen Schwachstellendatenbank

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

1Abbildung: Fehlerhafte Schwachstelleninfos für Windows 10

3Abbildung: 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.
  • Das System basiert auf dem Elastic Stack https://www.elastic.co/de/elastic-stack/ um Daten performant in Echtzeit zu durchsuchen und zu visualisieren.

Technischer Einblick: NIST NVD & Elastic Stack

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:

4Abbildung: Ü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.

5
6

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.

2021 09 17 09 56 10 ClipboardAbbildung: Vorschau unseres Schwachstellen-Suche Frontends

1. Datenformat von Produktversionen

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):

8

cpe:2.3:part:vendor:product_name:version:update:edition:sw_edition:target_sw:target_hw:language:other

  • 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:

9Abbildung: 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:

10Abbildung: Anzahl der registrierter Schwachstellen pro Jahr

11Abbildung: 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.

Automatisierte Cyberangriffe: Kein System bleibt unberührt

Automatisierte Angriffe

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:

Cyberangriffe 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:logs 2 cut

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.

logs 3 cut

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.

logs 4

Abbildung 4: Index-Anfragen verschiedener Quellen

Hierbei konnten wir verschiedene Anbieter und Tools identifizieren, die unseren Webserver auf Erreichbarkeit geprüft haben:

Schwachstellenscans von leakix.net (9%)

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:

logs 5

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:

logs 6

Abbildung 6: leakix.net – About

HAFNIUM Exchange Exploits (2,8%)

Des Weiteren konnten wir 20 Anfragen identifizieren, die versuchen verschiedene Teile der HAFNIUM Exchange Schwachstellen auszunutzen oder aufzuspüren. (Gängige IOCs lassen sich z.B. finden unter https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-ProxyLogon-Is-Just-The-Tip-Of-The-Iceberg-A-New-Attack-Surface-On-Microsoft-Exchange-Server.pdf):

  • 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

logs 7

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.

logs 8

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
  • Netgear Router DGN1000/DGN2200: Remote Code Execution Exploit: 2 Anfragen
  • Open Proxy CONNECT: 1 Anfrage

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

Weitere Informationen finden Sie unter: http://www.windowsecurity.com/uplarticle/Patch_Management/ASG_Patch_Mgmt-Ch2-Best_Practices.pdf

Härtungsmaßnahmen

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 setzenWeitere 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

https://github.com/fail2ban/fail2ban/blob/master/config/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.

Hier können Sie weitere vorgefertigte Fail2ban-Filterlisten entdecken: https://github.com/fail2ban/fail2ban/tree/master/config/filter.d  

Schwachstellen in NEX Forms < 7.8.8

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

nex forms schwachstelle formular
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:

34675 2

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:

34676 2

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.


Behebung der Schwachstellen

Die Schwachstellen wurden im nächsten Release des Herstellers behoben. Mehr Informationen hierzu finden sich unter https://codecanyon.net/item/nexforms-the-ultimate-wordpress-form-builder/7103891.

Vielen Dank dabei an das Envato Security Team für die Kommunikation mit den Entwicklern und die schnelle Behebung der identifizierten Schwachstellen!

Warum wir >80% Ihrer Mitarbeiterpasswörter knacken

Zusammenfassung des Fachartikels

Bei der Durchführung von technischen Passwort-Audits waren wir bislang in der Lage, über 40.000 Passwort-Hashes von Mitarbeitern zu analysieren und davon mehr als drei Viertel zu knacken. Dies ist in der Regel auf die Auswahl kurzer Passwörter, einer veralteten Passwortrichtlinie im Unternehmen sowie der hohen Wiederverwendung von Passwörtern zurückzuführen. Weiterhin kommt es oftmals vor, dass administrative Nutzer nicht an die unternehmensweite Passwort-Richtlinie gebunden sind und daraufhin schwache Passwörter wählen. Ebenfalls können prozessuale Probleme bei dem Onboarding von Mitarbeitern bestehen, die aktiv von einem Angreifer ausgenutzt werden können, um Passwörter zu knacken. Oftmals genügt ein richtiges Passwort eines privilegierten Nutzers, um ein Unternehmen vollständig kompromittieren zu können.

Beauftragen Sie einen Active Directory Passwort-Audit, um die Widerstandfähigkeit Ihres Unternehmens gegen Angreifer im internen Netzwerk zu erhöhen bzw. die Effektivität Ihrer Passwort-Richtlinien zu verifizieren. Gerne unterstützen wir Sie dabei, Probleme im Umgang mit Passwörtern und den dazugehörigen Prozessen zu identifizieren und zu beheben.

Einleitung

Die Corona-Pandemie sorgte für einen plötzlichen Wechsel vieler Mitarbeiter in das Home-Office. IT-Infrastrukturkomponenten, wie beispielsweise eine VPN-Lösung und entsprechende Mitarbeiterzugänge, für den Zugriff von Zuhause auf Unternehmensressourcen, waren jedoch nicht immer zu Beginn des Arbeitsplatzwechsels vorhanden. Viele Unternehmen mussten diese Lösungen erst nachreichen und den Aufbau ihrer IT-Infrastruktur überdenken bzw. nachrüsten.

Neben den neu dazugewonnenen IT-Infrastrukturkomponenten, die nun in der Regel öffentlich aus dem Internet erreichbar sein müssen, erhielten Mitarbeiter oftmals auch neue Zugangsdaten für den Zugriff auf Dienste und Ressourcen. Falls technisch möglich, implementierten Unternehmen eine sogenannte Single-Sign-On (SSO) Authentifizierung, wodurch der Nutzer sich lediglich einmalig mit seinen Domänen-Zugangsdaten anmeldet und anschließend auf die verschiedensten Unternehmensressourcen als bereits angemeldeter Nutzer zugreifen kann.

Laut Professor Christoph Meinel, dem Direktor des Hasso-Plattner-Instituts, vergrößerte die Corona-Pandemie die Angriffsfläche für Cyberangriffe stark und stellte IT-Abteilungen vieler Unternehmen vor große Herausforderungen.[1] Aufgrund des Zuwachses an Home-Office-Tätigkeit, der verstärkten Internetnutzung seit der Pandemie sowie der Erweiterung von IT-Infrastrukturen bei Unternehmen erhielten Cyber Threat Actors neue, lukrative Ziele für Hacking- und Phishing-Angriffe. Allein der DE-CIX Internetknoten in Frankfurt, wo Datenströme verschiedenster Internetanbieter zusammenlaufen, verzeichnete im März 2019 einen neuen Rekordwert in Höhe von 9,1 Terabit in der Sekunde. Dieser Wert kann mit dem Datenvolumen von 1800 heruntergeladenen HD-Filmen in der Sekunde verglichen werden. Ein neuer Höchststand zu den bisherigen Spitzenwerten von 8,3 Terabit.[2]

Assume Breach

Die Auswirkungen der Corona-Pandemie erhöhen demnach seither die Angriffsoberfläche von Unternehmen und ihren Mitarbeitern gegenüber realen Cyber-Angriffen. Vermehrt tauchen Begriffe wie „Supply Chain Attacks“ und „0-Day Schwachstellen“ in den öffentlichen Medien auf, wobei Unternehmen aktiv angegriffen und kompromittiert werden. Oftmals reicht hierbei die Kompromittierung eines einzelnen Mitarbeiters oder IT-Systems aus, um Zugriff auf das interne Netzwerk eines Unternehmens zu erhalten. Hierbei können sich eine Vielzahl von Angriffen ereignen, wie zum Beispiel Phishing-Angriffe oder das gezielte Ausnutzen von Schwachstellen in öffentlichen IT-Systemen.

Bereits Microsoft operiert nach der „Assume Breach“ Haltung und geht eher davon aus, dass ein Angreifer bereits Zugriff erhalten konnte, als dass eine 100-prozentige Sicherheit vorherrsche. Doch was passiert eigentlich, wenn ein Angreifer Zugriff auf ein Unternehmensnetzwerk erhalten konnte? Wie ist es möglich, dass ein Angreifer  einen normalen Mitarbeiteraccount kompromittiert und dadurch in der Lage ist, das vollständige Unternehmen lahmzulegen? Sensible Ressourcen und Serversysteme werden schließlich regelmäßig mit Sicherheitspatches bespielt und stehen nicht jedem frei zur Verfügung. Lediglich eine geringe Anzahl an Personen, wie Administratoren, besitzen Zugriff auf kritische Systeme. Weiterhin stellt eine unternehmensweite Passwortrichtlinie sicher, dass Angreifer die Passwörter von Administratoren und sonstigen Mitarbeitern nicht einfach erraten können. Wo liegt also das Problem?

IT-Sicherheit und Passwörter

Die alljährliche Statistik des Hasso-Plattner-Instituts aus dem Jahr 2020 [3] veranschaulicht erneut, dass die beliebtesten Passwörter der Deutschen abermals „123456“, „123456789“ oder „passwort“ lauten, wie bereits in den Statistiken aus den Vorjahren zuvor. Von einer ausreichend starken Passwortkomplexität ist hierbei nicht die Rede, geschweige denn davon, dass Passwörter nicht wiederverwendet werden.

Dieser Tatsache sind sich Unternehmen jedoch in der Regel bewusst und implementieren daraufhin technische Richtlinien, um dem Einsatz schwacher Passwörter vorzubeugen. Diese Regeln werden zum Beispiel mittels Gruppenrichtlinien über den Verzeichnisdienst Microsoft Active Directory für alle Mitarbeiter angewendet. Diese werden daraufhin gezwungen, Passwörter mit einer ausreichend starken Passwortlänge sowie gewissen Komplexitätsanforderungen zu wählen. Sätze wie „Ihr Passwort muss mindestens 8 Zeichen lang sein und mindestens ein Sonderzeichen oder eine Zahl enthalten“ kennt schließlich jeder. Somit gehören schwache Passwörter in heutigen Unternehmen der Vergangenheit an, oder? Leider nicht, denn ein Passwort wie „Winter21!“ ist noch immer schwach und erratbar, trotz Konformität zur unternehmensweiten Passwortrichtlinie.

Online-Angriffe vs. Offline-Angriffe

Für Online-Dienste wie Outlook Web Access (OWA) oder VPN-Portale, wo Nutzer sich mit Ihrem Nutzernamen und Passwort anmelden, ist die Gefahr eines erfolgreichen Angriffs in der Regel stark reduziert. Ein Angreifer müsste hierbei zuerst einen validen Nutzernamen identifizieren und anschließend das dazugehörige Passwort erraten. Weiterhin kommen oftmals technische Lösungen wie Account-Lockout nach mehrmaligen Fehlanmeldungen, eine Ratenlimitierung bei Login-Anfragen oder eine Zwei-Faktor-Authentifizierung (2FA) zum Einsatz. Diese Lösungen reduzieren die Erfolgschancen eines Angreifers erheblich, da nicht unendlich viele Rateversuche erfolgen können.

Doch selbst wenn solche Abwehrmechanismen nicht vorhanden sind, handelt es sich hierbei noch immer um einen Online-Angriff, bei dem der Angreifer ein Tupel aus Nutzernamen und Passwort wählt und diesen Rate-Versuch an den unterliegenden Server verschickt. Erst nach Verarbeitung der Anmeldeanfrage vom Server erhält der Angreifer das Ergebnis seines Passwort-Rate-Versuchs und entweder einen erfolgreichen Zugriff oder die Meldung über falsche Zugangsdaten. Diese Client-Server-Kommunikation schränkt die Performance eines Angreifers erheblich ein, da der Zeitaufwand und die Erfolgswahrscheinlichkeit eines Angriffs stark auseinanderdriften. Selbst ein einfaches Passwort, bestehend aus lediglich Kleinbuchstaben inkl. Umlauten und einer Länge von 6 Zeichen, würden 729 Millionen Serveranfragen eines Angreifers benötigen, um alle möglichen Passwortkombinationen durchzutesten. Zusätzlich müsste ein Angreifer hierbei bereits den Anmeldenamen seines Opfers kennen oder zusätzlich erraten. Unter Verwendung einer unternehmensweiten Passwortrichtlinie, inklusive den oben aufgeführten Abwehrmechanismen, geht die Wahrscheinlichkeit eines Online-Brute-Force-Angriffs gegen Null.

Anders hingegen sieht es für sogenannte Offline-Brute-Force-Angriffe aus, bei denen ein Angreifer typischerweise in den Besitz eines sogenannten Passwort-Hashes gelangt und diesen deutlich performanter mit seinen Passwort-Rateversuchen angreifen kann. Doch woher kommen diese Passwort-Hashes und warum sind diese anfälliger gegenüber Rateversuchen?

Passwort-Hashes

Lassen wir uns auf ein Gedankenspiel ein. Als großer Autoliebhaber sind wir, Max Muster, stets auf der Suche nach neuen Angeboten auf dem Automarkt. Dank des digitalen Wandels stehen uns nicht nur lokale Autohäuser und Makler zur Verfügung, sondern das gesamte Internet mit seiner Vielfalt an Suchplattformen, Webshops und Portalen. Von diesen Plattformen nehmen wir gerne Gebrauch und freuen uns darüber, mit einer einfachen Websuche viele interessante Angebote und Autoraritäten ergattern zu können. Für die Benutzung dieser Onlinedienste ist in der Regel ein Nutzerkonto erforderlich, um Favoriten abspeichern und Angebote abgeben zu können. Eine Registrierung mittels E-Mail und dem Passwort „Muster1234“ ist jedoch schnell erledigt. Doch wie funktioniert eine nachträgliche Anmeldung mit unserem neuen Nutzer eigentlich? Als Laie käme man schnell auf die Idee, dass der Anmeldename und das Passwort eines Nutzers einfach vom Dienstleister abgespeichert wird und beim Versuch der Anmeldung ein Abgleich stattfindet.

Dies ist generell gesprochen korrekt, jedoch fehlen der Vollständigkeit halber ein paar technische Details. Die Zugangsdaten werden korrekterweise bei der Registrierung abgespeichert und zwar in einer Datenbank. Die Datenbank enthält hierbei heutzutage jedoch nicht mehr das Klartextpasswort eines Nutzers, sondern einen sogenannten Passwort-Hash. Der Passwort-Hash wird mittels einer mathematischen Einwegfunktion aus dem Klartextpasswort des Nutzers errechnet. Anstelle unseres Passwortes „Muster1234“ steht in der Datenbank nun eine Zeichenkette wie „VEhWkDYumFA7orwT4SJSam62k+l+q1ZQCJjuL2oSgog=“ und die mathematische Funktion stellt hierbei sicher, dass diese Berechnung lediglich in eine Richtung („Einweg“) funktioniert. Aus der Zeichenkette ist es demnach nicht einfach möglich, erneut auf das Klartextpasswort zu schließen. Diese Methode stellt sicher, dass der Seitenbetreiber oder ein Angreifer mit Zugriff auf die Datenbank nicht einfach die Passwörter von Kunden im Klartext auslesen kann.

Bei einer Anmeldung wird nun das Klartextpasswort nach der Eingabe in der Loginmaske an den Anwendungsserver verschickt, welcher die Eingabe erneut in die mathematische Funktion einspeist und das Ergebnis mit dem abgespeicherten Passwort-Hash in der Datenbank abgleicht. Stimmen die Werte überein, so wurde das korrekte Passwort übermittelt und der Nutzer wird angemeldet. Unterscheiden sich die Werte, so wurde ein falsches Passwort übermittelt und der Nutzer erhält eine Fehlermeldung. Weiterhin kommen zusätzliche technische Gegebenheiten hinzu, wie die Replikation von Datenbanken, der Einsatz von “salted” Passwort-Hashes und vieles mehr. Für unser Gedankenspiel jedoch nicht weiter relevant.

Ein Angreifer, der nun versucht unser Nutzerkonto zu kompromittieren, steht erneut vor den Hürden eines Online-Angriffs. Der Anbieter der Suchplattform erlaubt z.B. lediglich drei Fehlanmeldungen, bevor das Nutzerkonto für 5 Minuten gesperrt wird. Ein automatisierter Angriff zum Erraten unseres Anmeldepasswortes ist demnach zeitlich nicht zu bewerkstelligen.

Anders sieht es jedoch aus, wenn ein Angreifer Lesezugriff auf die unterliegende Datenbank des Anbieters erhält, zum Beispiel mittels einer SQL-Injection-Schwachstelle in der Webanwendung. Nun ist der Angreifer in dem Besitz unseres Passwort-Hashes und kann auf Basis dessen einen Offline-Angriff durchführen. Die mathematische Einwegfunktion ist hierbei öffentlich bekannt und kann zur Berechnung herangezogen werden. Die Vorgehensweise eines Angreifers sieht nun wie folgt aus:

  1. Wahl einer beliebigen Input-Zeichenkette, welche den Rateversuch eines Passwortes widerspiegelt.
  2. Zeichenkette wird in die mathematische Einwegfunktion gespeist und der Passwort-Hash berechnet.
  3. Abgleich des errechneten Passwort-Hashes mit dem Passwort-Hash aus der echten Datenbank. Es folgt:
    1. Wenn identisch, wurde das Klartextpasswort erfolgreich erraten
    2. Wenn ungleich, wähle eine neue Input-Zeichenkette und starte erneut

Dieser Angriff ist deutlich performanter als Online-Angriffe, da hierbei keine träge Netzwerkkommunikation zwischen einem Client und einem Server erfolgen muss sowie Sicherheitsmaßnahmen wie 2FA, Ratenlimitierung oder Account Lockout nicht stattfinden. Jedoch gilt zu beachten, dass moderne und sichere Hashfunktionen in der Regel so ausgelegt werden, dass eine Hashberechnung für Angreifer ebenfalls aufwendig und nicht lukrativ ist. Hierbei wird der Aufwand einer einzelnen Hashberechnung um den Faktor n erhöht, welches für den einzelnen Abgleich eines Passwortes mit dem Hash in der Datenbank vernachlässigbar ist. Für einen Angreifer hingegen, der eine Vielzahl an Berechnungen seiner Passwort-Rateversuche benötigt, steigt der Aufwand jedoch erheblich um den Faktor n an, sodass ein erfolgreicher Passwort-Rateversuch mehrere Jahre benötigen würde. Unter der Verwendung moderner Hashfunktionen wie Argon2 oder PBKDF2 sind Offline-Angriffe demnach, ähnlich zu Online-Angriffen, eher komplex und zeitlich schwierig umzusetzen.

LM- und NT-Hashes

Unser Gedankenspiel können wir nun auf eine Vielzahl realer Anwendungsgebiete übertragen, wie zum Beispiel der Anmeldung an einem Windows-Betriebssystem. Ähnlich zu einem Nutzerkonto eines Online-Suchportals besteht unter Windows die Möglichkeit, Nutzer zu erstellen, die sich an dem Betriebssystem anmelden können. Für eine Anmeldung wird standardmäßig kein Passwort erfordert, kann jedoch für jeden Nutzer individuell konfiguriert werden. Ein Nutzerpasswort wird hierbei erneut als Passwort-Hash und nicht im Klartext abgespeichert. Microsoft verwendet hierbei zwei Algorithmen, um ein Nutzerpasswort in einen Hash umzuwandeln. Der ältere dieser beiden nennt sich LM-Hash und basiert auf dem bekannten DES-Algorithmus. Dieser wurde ab den Versionen Windows Vista bzw. Windows Server 2008 jedoch aus Sicherheitsgründen deaktiviert. Als Alternative wurde der sogenannte NT-Hash eingeführt, basierend auf dem MD4-Algorithmus.

Die Passwort-Hashes werden in einer so genannten SAM-Datenbank auf der Festplatte des Betriebssystems lokal abgelegt. Ähnlich zu unserem Gedankenspiel findet bei einer Windows-Anmeldung ein Abgleich zwischen dem Klartextpasswort der Nutzereingabe in den MD4-Algorithmus und dem abgelegten Passwort-Hash in der lokalen SAM-Datenbank statt. Sind die Hashes identisch, so wurde ein korrektes Passwort bei dem Anmeldeversuch übergeben und der Nutzer wird angemeldet.

Im Unternehmensumfeld und insbesondere in Microsoft Active Directory Umgebungen werden diese Passwort-Hashes neben weiteren Nutzerkennwerten und Objekten nicht nur lokal in einer SAM-Datenbank abgelegt, sondern ebenfalls auf einem dedizierten Server, dem Domain-Controller, in einer sogenannten NTDS-Datenbankdatei. Dies ist für eine einheitliche Authentifizierung gegenüber Datenbankserver, Dateiserver und sonstigen Ressourcen im Unternehmensumfeld mit Hilfe der Kerberos-Authentifizierung erforderlich. Weiterhin reduziert es die Komplexität bei einer Vielzahl von Mitarbeitern und IT-Assets im Unternehmen, da diese zentral an einer Stelle, dem Active Directory, verwaltet werden können. Mit Hilfe von Gruppenrichtlinien stellen Unternehmen zusätzlich sicher, dass Mitarbeiter ein Anmeldepasswort besitzen müssen und dieses auf einer strikten Passwort-Richtlinie basiert. Gegebenenfalls müssen Passwörter regelmäßig erneuert werden. Auf Basis dieses Domain-Nutzerpassworts können sich nun Single-Sign-On (SSO) Anmeldungen an vielen unterschiedlichen Unternehmensressourcen ereignen, da der NT-Hash des Passwortes zentral auf dedizierten Domain-Controllern aufbewahrt wird. Neben der lokalen SAM-Datenbank eines jeden Rechners und den Domain-Controllern einer on-premise Active Directory Umgebung steht ebenfalls die Möglichkeit zur Verfügung, die NT-Hashes eines Domain-Controllers mit der Cloud (z.B. Azure) zu synchronisieren. Hierdurch können auch SSO-Anmeldungen an Cloud-Assets, wie beispielsweise Office 365, realisiert werden. Die Passwort-Hashes eines Nutzers kommen demnach an vielen Stellen im Unternehmenskomplex zum Einsatz, welches die Wahrscheinlichkeit erhöht, dass diese entwendet werden können.

Zugriff auf NT-Hashes

Um als Angreifer Zugriff auf NT-Hashes erhalten zu können, gibt es eine Vielzahl an Möglichkeiten. Um diesen Fachartikel jedoch nicht unnötigerweise in die Länge zu ziehen, werden hier lediglich ein paar bekannte Wege aufgeführt:

  1. Kompromittierung eines einzelnen Mitarbeiterrechners (z.B. Phishing-E-Mail) und Auslesen der lokalen SAM-Datenbank des Windows Betriebssystems (z.B. mittels Mimikatz).
  2. Kompromittierung eines Domain-Controllers in der Active Directory Umgebung eines Unternehmens (z.B. mit Hilfe der PrintNightmare Schwachstelle) und Auslesen der NTDS-Datenbank (z.B. mittels Mimikatz).
  3. Kompromittierung eines privilegierten Domain-Nutzerkontos mit DCSync Berechtigungen (z.B. ein Domain Admin oder Enterprise Admin). Extrahierung aller NT-Hashes vom Domain-Controller einer AD-Domäne.
  4. Kompromittierung eines privilegierten Azure-Nutzerkontos mit Berechtigungen zur Durchführung einer Azure AD Connect-Synchronisierung. Extrahierung aller NT-Hashes vom Domain-Controller einer AD-Domäne.
  5. und viele weitere Angriffswege…

Passwort-Cracking

Nachdem NT-Hashes eines Unternehmens abgegriffen wurden, können diese entweder bei internen Angriffen „relayed“ werden oder ein Angreifer führt ein Passwort-Cracking durch, um an das Klartextpasswort eines Mitarbeiters zu gelangen.

Dies ist möglich, da NT-Hashes unter Windows und Active Directory Umgebungen einen veralteten Algorithmus namens MD4 verwenden. Diese Hashfunktion wurde 1990 von Ronald Rivest veröffentlicht und relativ schnell als unsicher befunden. Eine Hauptproblematik der Hashfunktion ist die fehlende Kollisionssicherheit, wodurch unterschiedliche Eingabewerte in die Hashfunktion zu dem gleichen Ausgabewert, dem Hash, führen. Dies unterwandert die Hauptaufgabe einer kryptologischen Hashfunktion.

Weiterhin ist die MD4-Hashfunktion äußerst performant und erschwert den Aufwand zur Hashberechnung, im Gegensatz zu modernen Hashfunktionen wie Argon2, nicht. Dies ermöglicht einem Angreifer, performante Offline-Angriffe gegen NT-Hashes durchzuführen. Ein moderner Gaming-PC mit aktueller Grafikkarte kann hierbei bereits zwischen 50-80 Milliarden Passwörter in der Sekunde berechnen. Das Knacken von kurzen oder schwachen Passwörtern wird hierdurch kinderleicht.

Um das Ausmaß dieser Geschwindigkeit zu verdeutlichen, gucken wir uns einmal die Anzahl aller möglichen Passwortkombinationen eines 8-stelligen Passwortes an. Hierbei nehmen wir der Einfachheit halber an, dass das Passwort lediglich aus Kleinbuchstaben sowie numerischen Werten besteht. Das deutsche Alphabet umfasst 26 Grundbuchstaben sowie die 4 Umlaute ä, ö, ü und Eszett ß. Numerische Werte bringen eine Auswahlmöglichkeit von 10 Werten mit, nämlich die Zahlen Null bis Neun. Das bedeutet, für jede Stelle unseres 8-stelligen Passwortes besitzt ein Nutzer 40 Auswahlmöglichkeiten. Dies entspricht ca. 6550 Milliarden Möglichkeiten bzw. der folgenden mathematischen Formel:

formel

Ein Gaming-PC, der in der Sekunde 50 Milliarden Passwort-Rate-Versuche durchführen kann, würde demnach nur 131 Sekunden benötigen, um alle 6550 Milliarden Möglichkeiten unseres 8-stelligen Passwortes durchzutesten. Ein solches Passwort wäre demnach in etwas mehr als 2 Minuten gebrochen. Hinzu kommt, dass reale Threat Actors spezielle Passwort-Cracking-Systeme einsetzen, die zum Teil 500 bis 700 Milliarden Passwort-Rate-Versuche in der Sekunde erreichen. Solche Systeme kosten in der Anschaffung jedoch bereits deutlich über 10.000 EUR.

Weiterhin bestehen eine Vielzahl weiterer Cracking-Methoden, um Passwort-Hashes knacken zu können, die nicht darauf abzielen, den vollständigen Keyspace (alle Passwortmöglichkeiten) zu berechnen. Dadurch wird es möglich, auch Passwörter zu knacken, die mehr als 12 Zeichen besitzen und bei einem regulären Brute-Force-Angriff über den gesamten Keyspace mehrere Jahre erfordern würden.

Hierzu zählen unter anderem:

  • Wörterbuchlisten (z.B. der deutsche Duden)
  • Passwortlisten (z.B. aus öffentlichen Leaks oder Breaches)
  • Regelbasierte Listen, Kombinationsangriffe, Keywalks, uvm.

Pentest Factory Passwort-Audit

Mit der Beauftragung eines Active Directory Passwort-Audits führen wir genau solch ein Angriffsszenario durch. Im ersten Schritt extrahieren wir mit Ihnen zusammen alle NT-Hashes Ihrer Mitarbeiter von einem Domain Controller ohne Nutzerbezug. Unser Vorgehen wird hierbei mit Ihrem Betriebsrat abgestimmt und basiert auf einem erprobten Prozess.

Anschließend unterziehen wir die extrahierten Passwort-Hashes einem realen Cracking-Angriff, um die Hashes in ihre Klartextform, also dem realen Nutzerpasswort, zurückzuführen. Hierbei kommen eine Vielzahl moderner und realer Angriffsmethoden zum Einsatz, unter der Verwendung eines moderaten Cracking-Servers mit der Hash-Power von 100 Milliarden Rateversuchen in der Sekunde.

Nach Abschluss der Cracking-Phase bereiten wir die Ergebnisse für Sie auf und erstellen einen finalen Abschlussbericht. Dieser beinhaltet messbare Kennzahlen zu den kompromittierten Mitarbeiterpasswörtern und gibt hilfreiche Empfehlungen dazu, wie die Passwortsicherheit in Ihrem Unternehmen langfristig verbessert werden kann. Oftmals können hierdurch prozessuale Probleme, zum Beispiel beim Onboarding von Mitarbeitern oder Fehlkonfigurationen in Gruppenrichtlinien und Passwortrichtlinien aufgezeigt werden. Weiterhin besteht die Möglichkeit einen Passwort-Audit mit Nutzerbezug durchzuführen. Hierbei sind lediglich Sie als Kunde in der Lage, geknackte Passwort-Hashes abschließend auf Ihre Mitarbeiter zurückzuführen. Der Prozess eines nutzerbasierten Audits wird ebenfalls mit Ihrem Betriebsrat abgestimmt und folgt geltenden Datenschutzbestimmungen.

Statistiken aus durchgeführten Passwort-Audits

Seit der Gründung der Pentest Factory GmbH im Jahr 2019 konnten schon eine Vielzahl an Passwort-Audits für unsere Kunden durchgeführt und der Umgang mit Passwörtern verbessert werden. Neben technischen Fehlkonfigurationen, wie zum Beispiel eine nicht einheitlich angewandte Passwortrichtlinie, konnten oftmals prozessuale Probleme aufgezeigt werden. Insbesondere bei dem Onboarding von neuen Mitarbeitern entstehen oftmals unsichere Prozesse, die zu einer schwachen oder unsicheren Passwortwahl führen. Ebenso kommt es vor, dass administrative Nutzer ihre Passwörter unabhängig von den geltenden Richtlinien wählen können. Da diese Nutzer im Unternehmen hoch privilegiert sind, geht hierbei ein erhöhtes Risiko bei der Verwendung schwacher Passwörter einher. Sollte ein Angreifer in der Lage sein, das Passwort eines administrativen Nutzers zu erraten, so kann das komplette Unternehmen und seine IT-Infrastruktur kompromittiert werden.

Um Ihnen einen Einblick in unsere Arbeit zu geben, möchten wir Ihnen Statistiken zu den von uns durchgeführten Passwort-Audits vorstellen.

Über alle Audits hinweg konnten bislang 32.493 einzigartige Passwort-Hashes untersucht werden. Inklusive wiederverwendeter Passwörter kommen wir hier bereits auf eine Anzahl von 40.288 Passwort-Hashes. Dies bedeutet, dass insgesamt bereits 7795 Mitarbeiterpasswörter geknackt werden konnten, die mehrmals über mehrere Nutzerkonten wiederverwendet wurden. Dazu gehören oftmals Passwörter wie „Winter2021“ oder Passwörter, die initial an Mitarbeiter beim Onboarding vergeben und nicht geändert wurden. Die höchste Wiederverwendung eines einzelnen Passwortes war circa 450-mal. Hierbei handelte es sich um ein initial vergebenes Passwort, welches von vielen Nutzern nachträglich nicht geändert wurde.

Von den insgesamt 32.493 einzigartigen Passwort-Hashes konnten während unserer Tests bereits 26.927 Klartextpasswörter zurückberechnet werden. Dies entspricht einem Prozentsatz von über 82%. Das bedeutet, dass wir in der Lage waren, deutlich mehr als zwei Drittel aller Mitarbeiterpasswörter bei Passwort-Audits zu brechen. Eine erschreckende Statistik.

cracked vs notcracked

Dies ist hauptsächlich darauf zurückzuführen, dass Passwörter mit einer Passwortlänge kleiner 12 Zeichen zum Einsatz kamen bzw. zu schwach gewählt wurden. Die folgende Grafik unterstreicht unsere Erkenntnis.

Anmerkung: Das unten aufgeführte Schaubild beinhaltet nicht alle gebrochenen Passwortlängen. Einzelne Ausreißer, wie Passwortlängen über 20 Zeichen oder sehr kurze bis hin zu leere Passwörter, wurden in der Grafik zum Beispiel vernachlässigt.

pwlength

Weiterhin zeigen unsere Statistiken die Auswirkungen einer zu schwach gewählten oder fehlenden Passwortrichtlinie sowie Probleme bei der Anwendung der Richtlinie auf alle Nutzerkonten.

Anmerkung: Das unten aufgeführte Schaubild beinhaltet nicht alle Passwortmasken gebrochener Passwörter, sondern lediglich eine Auswahl.

masks 1

Eine Vielzahl von Mitarbeiterpasswörtern waren demnach erratbar, da diese auf einer bekannten Passwortmaske beruhten. Über 12.000 geknackte Passwörter hatten hierbei einen Aufbau bestehend aus einer initialen Zeichenkette und einer abschließenden Verwendung numerischer Werte. Dazu gehören zum Beispiel äußerst schwache Passwörter wie „Sommer2019“ und „passwort1“.

Solche Passwörter stehen in der Regel bereits in öffentlich verfügbaren Passwortlisten zur Verfügung. Einer der bekanntesten Passwortlisten nennt sich „Rockyou“ und enthält über 14 Millionen einzigartige Passwörter aus einem ehemaligen Breach im Jahr 2009 der Firma RockYou. Die Firma wurde Opfers eines Hackerangriffs und speicherte alle Kundenpasswörter in einer Datenbank im Klartext. Die Hacker konnten auf diese Daten zugreifen und veröffentlichten den Datensatz im Nachhinein.

Auf Basis solcher Leaks ist es möglich, Statistiken zum Aufbau gewählter Nutzerpasswörter zu erstellen. Diese Statistiken, Muster und Regeln zum Passwortaufbau können anschließend verwendet werden, um eine Vielzahl neuer Passwort-Hashes effektiv zu brechen. Die Verwendung eines Passwortmanagers, der kryptografisch zufällige und komplexe Passwörter generiert, kann solche regelbasierten Angriffe oder wiederkehrende Muster erschweren bzw. verhindern.

Empfehlungen zur Passwort-Sicherheit

Unsere Statistiken haben gezeigt, dass die Wahl einer strikten und modernen Passwortrichtlinie die Erfolgswahrscheinlichkeit eines Cracking-Angriffes oder Rate-Versuchs drastisch vermindern kann. Jedoch basiert die Passwortsicherheit in einem Unternehmen auf mehreren Faktoren, welche wir gerne etwas erläutern.

Passwortlänge

Nehmen Sie Abstand von veralteten Passwortrichtlinien, die lediglich eine Passwortlänge von 8 Zeichen erfordern. Der Kostenaufwand für moderne, leistungsstarke Hardware sinkt stetig, wodurch auch Angreifer mit einem geringen Budget in der Lage sind, Passwort-Angriffe effektiv durchzuführen. Mit dem vermehrten Aufkommen kostengünstiger Cloudanbieter ist es weiterhin möglich, Angriffe flexibel mit einem fixen Budget durchzuführen, ohne effektiv Hardware kaufen oder Systeme aufsetzen zu müssen.

Bereits eine Passwortlänge von 10 Zeichen kann den Aufwand für einen Angreifer erheblich erhöhen, auch unter Verwendung moderner Cracking-Systeme. Für Unternehmen, die Microsoft Active Directory einsetzen, empfehlen wir jedoch den Einsatz einer Passwortrichtlinie, die eine Passwortlänge von mind. 12 Zeichen technisch erfordert.

Komplexität

Stellen Sie weiterhin sicher, dass Passwörter eine ausreichende Komplexität besitzen und aus den folgenden Mindestanforderungen bestehen:

  • Passwort enthält mind. einen Kleinbuchstaben
  • Passwort enthält mind. einen Großbuchstaben
  • Passwort enthält mind. eine Zahl
  • Passwort enthält mind. ein Sonderzeichen

Regelmäßige Passwortwechsel

Das regelmäßige Wechseln von Passwörtern wird vom BSI nicht mehr empfohlen, solange das Passwort lediglich autorisierten Personen zugänglich bzw. bekannt ist. [4]

Sollte das Passwort jedoch kompromittiert worden sein, also einer nicht autorisierten Person bekannt sein, so muss sichergestellt werden, dass das Passwort umgehend geändert wird. Weiterhin ist es ratsam, öffentliche Datenbanken bezüglich neuer Passwort-Leaks Ihres Unternehmens regelmäßig zu überprüfen. Gerne unterstützen wir Sie mit einem Cyber Security Check hierbei.

Passwort-Historie

Stellen Sie sicher, dass Nutzer bei dem Passwortwechsel keine bereits zuvor verwendeten Passwörter wählen können. Implementieren Sie hierzu eine Passwort-Historie, die die letzten 24 Nutzerpasswörter beinhaltet und deren Wiederverwendung verhindert.

Einsatz von Blacklisten

Implementieren Sie zusätzliche Checks bei der Passwortänderung, um die Verwendung bekannter Blacklist-Wörter zu unterbinden. Dazu gehört zum Beispiel der eigene Unternehmensname, die Jahreszeiten, der Name von Dienstleistern oder Produkten bis hin zu einzelnen Wörtern wie „Passwort“. Stellen Sie sicher, dass diese Blacklist-Wörter technisch unterbunden werden und nicht nur organisatorisch verboten werden.

Automatische Kontosperrung

Konfigurieren Sie eine automatische Kontosperrung bei mehrmaligen Fehlanmeldungen, um Online-Angriffe aktiv abzuwehren. Eine bewährte Richtlinie lautet, das Nutzerkonto nach 5 fehlgeschlagenen Logins für 5-10 Minuten zu sperren. Gesperrte Konten sollten nach einer fest definierten Zeitspanne automatisiert entsperrt werden, um einen Regelbetrieb zu ermöglichen und Help-Desk-Überlastungen zu vermeiden.

Sensibilisierung

Die Sensibilisierung aller Mitarbeiter, inklusive des Managements, ist essenziell wichtig, um das Sicherheitslevel gesamtflächig anzuheben. Regelmäßige Sensibilisierungsmaßnahmen sollten ein Bestandteil der Unternehmenskultur werden, um den korrekten Umgang mit sensitiven Zugangsdaten zu unterrichten.

Es bedarf einer bewussten Verhaltensänderung aller Mitarbeiter in sicherheitsrelevanten Situationen, zum Beispiel:

  • Den PC sperren, auch wenn man nur kurz den Arbeitsplatz verlässt;
  • Vertrauliche Unterlagen wegsperren;
  • Niemandem sein Passwort weitergeben;
  • Verwendung von sicheren (starken) Passwörtern;
  • Passwörter nicht doppelt bzw. mehrfach verwenden.

Trotz einer technisch strikten Passwortrichtlinie können Nutzer noch immer schwache Passwörter wählen, die relativ einfach erraten werden können. Lediglich die Durchführung regelmäßiger Passwortaudits und die Sensibilisierung von Mitarbeitern kann dies langfristig verhindern.

Verwendung von 2 Faktor-Authentifizierung

Konfigurieren Sie zusätzliche Sicherheitsmaßnahmen wie beispielsweise die Zwei-Faktor-Authentifizierung. Dies stellt sicher, dass selbst im Falle eines erfolgreichen Passwort-Rate-Versuchs, ein Angreifer ohne Besitz eines zweiten Tokens keinen Zugriff auf das Nutzerkonto und Unternehmensressourcen erhält.

Regelmäßige Passwort-Audits

Führen Sie regelmäßige Passwort-Audits durch, um Nutzerkonten mit schwachen oder wiederverwendeten Passwörtern zu identifizieren und diese vor zukünftigen Angriffen abzusichern. Durch eine beständige Re-Evaluierung Ihrer unternehmensweiten Passwortrichtlinie und Effektivität von Awareness-Schulungen auf technischer Ebene können sie Kennzahlen generieren, um die Passwortsicherheit in Ihrem Unternehmen zu messen und kontinuierlich zu verbessern.

Differenzierte Passwortrichtlinien

Führen Sie mehrere Passwortrichtlinien in Ihrem Unternehmen ein, basierend auf dem Schutzbedarf der darauf angewandten Zielgruppe. Niedrig privilegierte Nutzerkonten können so zum Beispiel technisch gezwungen werden, eine Passwortlänge von 12 Zeichen inkl. Komplexitätsanforderungen einzuhalten, während administrative Nutzerkonten eine striktere Richtlinie mit mind. 14 Zeichen befolgen müssen.

Zusätzliche Sicherheitsfeatures

Gerne beraten wir Sie zu zusätzlichen Sicherheitseinstellungen in Ihrer Active Directory Umgebung, um die Passwortsicherheit zu verbessern. Dazu gehören unter anderem:

  • Local Administrator Password Solution (LAPS)
  • Custom .DLL Password Filters
  • Logging und Monitoring von Active Directory Events

Beauftragung

Sollten wir Ihr Interesse an der Durchführung eines Passwort-Audits wecken können, so freuen wir uns über eine Kontaktaufnahme Ihrerseits. Gerne unterstützen wir Sie dabei, die Passwortsicherheit in Ihrem Unternehmen zu überprüfen sowie langfristig zu verbessern.

Verwenden Sie gerne unseren Online-Konfigurator zur Beauftragung eines Audits.

Weitere Informationen zum Passwort-Audit finden Sie unter: https://www.pentestfactory.de/passwort-audit

Quellen

[1] https://hpi.de/news/jahrgaenge/2020/die-beliebtesten-deutschen-passwoerter-2020-platz-6-diesmal-ichliebedich.html
[2] https://www.kas.de/documents/252038/7995358/Die+Auswirkungen+von+COVID-19+auf+Cyberkriminalit%C3%A4t+und+staatliche+Cyberaktivit%C3%A4ten.pdf/8ecf7084-704b-6810-4374-5840a6954b9f?version=1.0&t=1591354253482
[3] https://hpi.de/news/jahrgaenge/2020/die-beliebtesten-deutschen-passwoerter-2020-platz-6-diesmal-ichliebedich.html#:~:text=Das%20Hasso%2DPlattner%2DInstitut%20(,sind%20und%202020%20geleakt%20wurden.
[4] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium/IT_Grundschutz_Kompendium_Edition2020.pdf – Punkt ORP.4.A8

Schwachstellen in FTAPI 4.0 – 4.11

Um unsere Infrastruktur gegen Angriffe abzusichern, 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 Dateiaustauschplattform FTAPI konnten wir dabei die folgenden Schwachstellen 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 am Ende des Beitrags.


 

CVE-2021-25277: FTAPI Stored XSS (via File Upload)

Die Webanwendung ist anfällig für „Stored Cross-Site Scripting”: Der Dateiupload der Applikation erlaubt es Dateien mit unsicheren Namen hochzuladen. Beim Hovern über das Dateinamensfeld wird ein Alternativtext-Element eingeblendet (siehe folgender Screenshot), was den Dateinamen zeigt. Dieses dynamisch eingeblendete Element nimmt keine Filterung des Dateinamens auf bösartige Zeichen vor, wodurch eine XSS Schwachstelle entsteht.

25277 1

Abbildung 1: Verwundbares Alternativtextfeld der Dateinamens-Box

Proof-of-Concept

Beim Hochladen einer Datei mit dem folgenden Namen, wird exemplarisch eine Alert-Box ausgeführt, um die Schwachstelle zu visualisieren:

25277 2

Abbildung 2: Proof-of-Concept Dateiname mit alert() Ausführung

Damit der Upload erfolgreich ist, darf die Datei nicht leer sein. Sie lässt sich mit dem folgenden Linux Befehl erzeugen:

echo "test" >> "<iframe onload=alert('Pentest_Factory_XSS')>"

Das Dateinamensfeld wird nicht nur beim Upload, sondern auch für den Empfänger beim Abruf der Datei eingeblendet. Somit kommt es auch hier zu einer Ausführung unseres Codes, sobald die Maus das grüne Datei-Feld berührt:

25277 3

Abbildung 3: Proof-of-Concept alert() wird in der Inbox des Opfers ausgeführt


 

CVE-2021-25278: FTAPI Stored XSS (via Submit Box Template)

Die Webanwendung ist anfällig für „Stored Cross-Site Scripting”: Administrativen Nutzern ist es möglich das Submit Box Template zu ändern. Hierbei existiert eine Funktion zum Hochladen von Hintergrundbildern. Die Uploads werden dabei nicht auf bösartige Inhalte gefiltert, was es einem Angreifer erlaubt, eine SVG Datei mit eingebettetem XSS hochzuladen.

25278 1

Abbildung 4: Verwundbarer Hintergrundbild-Upload im Submit Box Layout Editor

Proof-of-Concept

Um die Schwachstelle exemplarisch auszunutzen, kann eine .svg Datei mit folgendem Inhalt als Hintergrundbild hochgeladen werden:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
   <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>
   <script type="text/javascript">
      alert('Pentest Factory XSS');
   </script>
</svg>
 

Die hochgeladene Datei wird im Verzeichnis /api/2/staticfile/ gespeichert und führt zu XSS, sobald diese aufgerufen wird:

25278 2

Abbildung 5: Stored XSS in Suchfunktion


 

Mögliche Auswirkungen

Ein Angreifer, der eine der Cross-Site Scripting Schwachstellen ausnutzt, könnte unter anderem folgende Angriffe ausführen:

  • Session Hijacking mit Zugriff auf vertrauliche Dateien und Identifikatoren
  • Veränderung der Präsentation der Webseite
  • Einfügen von schädlichen Inhalten
  • Umleiten von Anwendern auf schädliche Seiten
  • Malwareinfektion

 Dies könnte zum Verlust der Vertraulichkeit, Integrität und Verfügbarkeit der von FTAPI verarbeiteten Daten führen.


 

Behebung der Schwachstellen

Die Schwachstellen wurden im nächsten Release des Herstellers behoben. Mehr Informationen hierzu finden sich unter https://docs.ftapi.com/display/RN/4.11.0.

Vielen Dank dabei an das FTAPI Team für die schnelle und einfache Kommunikation mit uns und die schnelle Behebung der identifizierten Schwachstellen!