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!

 

Subdomains unter der Lupe: SSL Transparency Logs

Seit der Gründung der Zertifizierungsstelle Let’s Encrypt im Jahr 2014 und Inbetriebnahme Ende 2015 wurden bislang mehr als 182 Millionen aktive Zertifikate und 77 Millionen aktive Domänen registriert (Stand 05/2021). [1]

Um die Zertifizierungsvorgänge transparenter zu machen, werden dabei alle Registrierungen öffentlich protokolliert. Im Folgenden betrachten wir, wie diese Information aus der Perspektive eines Angreifers genutzt werden kann, um Subdomänen ausfindig zu machen und welche Maßnahmen Unternehmen treffen können, um diese zu schützen.

Let’s Encrypt

Mittels Let’s Encrypt wurde die Art und Weise der Handhabung von SSL-Zertifikaten revolutioniert. Jeder, der heutzutage einen Domainnamen besitzt, ist in der Lage, ein kostenfreies SSL-Zertifikat über Let’s Encrypt zu beziehen. Mittels quelloffener Tools wie z.B. Certbot kann die Beantragung und Konfiguration von SSL-Zertifikaten intuitiv, sicher und vor allem automatisiert stattfinden. Zertifikate werden automatisch erneuert und dazugehörige Webserver-Dienste wie Apache oder Nginx im Nachhinein vollautomatisch neugestartet. Das Zeitalter von teuren SSL-Zertifikaten und komplexen, manuellen Konfigurationseinstellungen ist nahezu vorüber.

stats 1 Wachstum von Let’s Encrypt

Certificate Transparency (CT) Logs

Weiterhin trägt Let’s Encrypt zur Transparenz bei. Alle ausgestellten Let’s Encrypt Zertifikate werden zu „CT Logs“ gesendet sowie ebenfalls in einem eigenständigen Logging-System mittels Google Trillian in der AWS Cloud von Let’s Encrypt selbst protokolliert. [2]

Die Abkürzung CT steht hierbei für Certificate Transparency und erklärt sich wie folgt:

„Certificate Transparency (CT) ist ein System zur Protokollierung und Überwachung der Ausstellung eines TLS Zertfikates. CT ermöglicht es jederman, Zertifikatsausstellungen zu überprüfen und zu überwachen […].“ [2]

Certificate Transparency war eine Reaktion auf die Angriffe auf DigiNotar [3] und anderen Certificate Authorities im Jahr 2011. Diese Angriffe zeigten, dass die fehlende Transparenz in der Arbeitsweise von CAs ein erhebliches Risiko darstellten. [4]

Durch CT ist es demnach jeder Person mit Zugriff zum Internet möglich, ausgestellte Zertifikate öffentlich einzusehen und zu überprüfen.

Problemstellung

Die Beantragung und Einrichtung von Let’s Encrypt SSL-Zertifikaten erweist sich demnach als äußerst einfach. Dies zeigt ebenfalls die hohe Anzahl an täglich ausgestellten Zertifikaten durch Let’s Encrypt. Pro Tag werden hierbei über 2 Millionen Zertifikate ausgestellt und deren Ausstellung transparent protokolliert (Stand 05/2021) [5].

issued certs Pro Tag ausgestellte Let’s Encrypt-Zertifikate

Zertifikate werden hierbei für allerlei Systeme oder Vorhaben ausgestellt. Seien es Produktivsysteme, Testumgebungen oder temporäre Projekte. Nutzer oder Unternehmen sind in der Lage, kostenfreie Zertifikate für ihre Domänen und Subdomänen zu beantragen. Ebenfalls stehen Wildcard-Zertifikate seit dem Jahr 2018 zur Verfügung. Alles transparent protokolliert und öffentlich einsehbar.

Transparenz ist doch klasse, oder?

Aufgrund der Tatsache, dass alle ausgestellten Zertifikate transparent protokolliert werden, können diese Informationen von jeder Person eingesehen werden. Zu diesen Informationen zählt z.B. der Common Name eines Zertifikats, welcher den Domänennamen oder die Subdomäne eines Dienstes preisgibt. Ein Angreifer oder Pentester ist dadurch in der Lage, den Hostnamen und potenziell sensitive Systeme in den Certificate Transparency Logs zu identifizieren.

Dies stellt auf erste Sicht kein Problem dar, unter der Prämisse, dass die Systeme bzw. angebotenen Dienste hinter den Domänennamen gewollt öffentlich erreichbar sind, aktuelle Softwareversionen einsetzen und ggf. durch eine Authentifizierung vor unbefugten Zugriffen geschützt sind.

Unsere Erfahrung bei Penetrationstests und Sicherheitsanalysen zeigt jedoch auf, dass oftmals Systeme ungewollt im Internet preisgegeben werden. Entweder geschieht dies aus Versehen oder unter der Annahme, dass ein Angreifer ja den Hostnamen benötige, um überhaupt Zugriff zu erhalten. Weiterhin haben viele Unternehmen aufgrund von gewachsenen Strukturen keine Übersicht mehr über Ihre vorhandenen und aktiven IT-Assets. Durch ein Ausschalten der Indexierung von Webseiteninhalte (z.B. durch Google) wird zusätzlich ein vermeintlicher Schutz bei Testumgebungen implementiert. Ein Angreifer habe demnach keinerlei Kenntnisse über das System und man sei sicher. Entwicklern oder IT-Admins ist zudem meist nicht bekannt, dass die Beantragung von SSL-Zertifikaten protokolliert wird und hierdurch Domänennamen öffentlich eingesehen werden können.

Auslesen von CT-Logs

Um auf die Informationen öffentlicher CT-Logs zugreifen zu können, gibt es mittlerweile eine Vielzahl von Methoden. Diese Methoden kommen oftmals in so genannten Open Source Intelligence (OSINT) Operationen zum Einsatz, um interessante Informationen und Angriffsvektoren eines Unternehmens zu identifizieren. Auch wir als Pentest Factory greifen auf diese Methoden und Webdienste zu, um bei unserer passiven Reconnaissance an interessante Systeme unserer Kunden zu gelangen.

Ein bekannter Webdienst lautet: https://crt.sh/

certsh 1 Beispielhafter Auszug aus öffentlichen CT-Logs der Domäne pentestfactory.de

Weiterhin bestehen eine Vielzahl automatisierter Skripte im Internet (z.B. GitHub), um die Informationen auch automatisiert extrahieren zu können.

Der Mythos des Wildcard-Zertifikats

Nach Erkenntnis der Möglichkeit zum Auslesen von CT-Logs und der daher eingehenden, potenziellen Problematik, kommen Unternehmen oftmals auf eine grandiose Idee. Anstelle der Beantragung von individuellen SSL-Zertifikaten für unterschiedliche Subdomänen und Dienste, wird ein allgemeines Wildcard-Zertifikat generiert und über alle Systeme bzw. Dienste eingerichtet.

Die Subdomänen werden hierdurch nicht mehr in Transparency Logs veröffentlicht, da der Common Name des Zertifikats lediglich einen Wildcard-Eintrag wie z.B. *.domain.tld darstellt. Externe Angreifer sind dadurch nicht mehr in der Lage, die unterschiedlichen Subdomains und Dienste eines Unternehmens zu enumerieren. Problem gelöst, oder?

Teilweise. Korrekterweise werden die Hostnamen oder Subdomains nicht mehr in Transparency Logs veröffentlicht. Jedoch bestehen weiterhin viele Möglichkeiten für einen Angreifer, passiv an interessante Dienste bzw. Subdomains eines Unternehmens zu gelangen. Die unterliegende Problematik, dass Systeme ggf. ungewollt im Internet stehen, veraltete Software mit öffentlichen Schwachstellen einsetzen oder keinen Schutz vor unbefugten Zugriffen implementieren, besteht weiterhin. Der Ansatz, mithilfe eines Wildcard-Zertifikats für mehr Sicherheit zu sorgen, bei dem Informationen lediglich versteckt werden, nennt man Security through Obscurity. In Wirklichkeit wird die Sicherheit eines Unternehmens durch die Wiederverwendung eines einzigen Wildcard-Zertifikats über mehrere Dienste und Server verringert.

Ein Angreifer kann beispielsweise einen Brute-Force-Angriff mit Hilfe einer großen Liste oft genutzter Domänennamen durchführen. Öffentliche DNS-Server wie Google (8.8.8.8) oder Cloudflare (1.1.1.1) geben hierbei Rückmeldung, ob eine Domäne erfolgreich aufgelöst werden kann oder nicht. Dies gibt einem Angreifer erneut die Möglichkeit, interessante Dienste und Subdomänen zu identifizieren.

gobuster 2
Beispielhafter Brute-Force-Angriff auf die Domäne pentestfactory.de zur Enumeration valider Subdomains

Die Gefahren eines Wildcard-Zertifikats

Von der Wiederverwendung eines Wildcard-Zertifikats über mehrere Subdomains und unterschiedlichen Servern wird dringend abgeraten. Die Problematik liegt hierbei in der Wiederverwendung des Zertifikats.

Sollte es einem Angreifer gelingen, einen Webserver erfolgreich zu kompromittieren, der ein Wildcard-Zertifikat einsetzt, so muss das Zertifikat als vollständig kompromittiert angesehen werden. Die Vertraulichkeit und Integrität des Datenverkehrs zu jedem Dienst eines Unternehmens, der das Zertifikat einsetzt, wird dadurch gefährdet. Ein Angreifer, im Besitz des Wildcard-Zertifikats, wäre in der Lage, den Datenverkehr von allen Diensten, die das Zertifikat verwenden, zu entschlüsseln, auszulesen oder sogar zu verändern. Ein Angreifer muss sich hierbei in einer Man-in-the-Middle (MitM) Position zwischen Client und dem Server befinden, um den Datenverkehr abfangen zu können. Dieser Angriff ist demnach nicht trivial, jedoch von versierten Angreifern praktisch durchführbar.

Wäre bei dem obigen Angriff anstelle eines Wildcard-Zertifikats ein einzigartiges SSL-Zertifikat für jede Domäne/Dienst verwendet worden, so wäre der Angreifer lediglich in der Lage gewesen, den Datenverkehr der kompromittierten Domäne zu attackieren. Anderweitige Domänen und Unternehmensdienste wären hierbei nicht betroffen, da einzigartige Zertifikate zum Einsatz gekommen wären und lediglich eines davon erfolgreich kompromittiert wurde. Das Unternehmen müsste demnach lediglich ein einzelnes Zertifikat widerrufen sowie neu ausstellen und nicht das umfangreich wiederverwendete Wildcard-Zertifikat über mehrere Server und Dienste. Weiterhin kann der Schaden durch die Verwendung von einzigartigen Zertifikaten reduziert und im Falle eines erfolgreichen Angriffs in seinem Umfang bemessen werden. Unternehmen wissen dann genau, welches Zertifikat für welche Domäne oder Dienst kompromittiert wurde und wo gegebenenfalls bereits Angriffe stattgefunden haben können. Bei der Verwendung von Wildcard-Zertifikaten und eines erfolgreichen Angriffs sind potenziell alle Domänen und Dienste kompromittiert und die Auswirkungen des Schadens undurchsichtig bzw. schwer einzuschätzen.

Weitere Informationen über Wildcard-Zertifikate:

Empfehlung

Seien Sie sich stets bewusst, dass Angreifer an viele Informationen über Ihr Unternehmen gelangen können. Seien es öffentliche Quellen oder aktive Tests zum Erhalt von wertvollen Informationen. Die Sicherheit und Widerstandsfähigkeit eines Unternehmens steht und fällt mit dem schwächsten Kettenglied der IT-Infrastruktur. Nehmen Sie allgemein Abstand von Security through Obscurity Praktiken und halten Sie Ihre Systeme stets auf einem aktuellen Stand (Patch-Management).

Stellen Sie vielmehr sicher, dass alle Ihre öffentlich erreichbaren Systeme gewollt im Internet stehen und eine Zugriffskontrolle implementieren, falls notwendig. Entwicklungsumgebungen oder Testinstanzen sollten stets vor der Öffentlichkeit verborgen bleiben und lediglich dem Unternehmen selbst und seinen Entwicklern zur Verfügung stellen. Dies kann über eine Firewall-Whitelist Ihrer unternehmensweiten IP-Adressen erfolgen oder einfach halber mittels einer vorgeschalteten Abfrage von Nutzername und Passwort (z.B. mittels Basic-Authentication für Webdienste). Setzen Sie hierbei ein komplexes Passwort mit einer ausreichend großen Länge (> 12 Zeichen) ein.

SSL-Zertifikate sollten den exakten (Sub)Domänennamen im Common Name des Zertifikats definieren sowie von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt worden sein. Stellen Sie weiterhin sicher, dass das Zertifikat gültig ist und vor Ablauf frühzeitig erneuert wird. Weiterhin wird empfohlen, lediglich starke Algorithmen für die Hash-Signierung des Zertifikats zu verwenden, wie z.B. SHA-256. Von der Verwendung des veralteten SHA-1 Algorithmus sollte Abstand genommen werden, da dieser anfällig gegenüber praktischen Kollisions-Angriffen ist [6].

Professionelle Unterstützung

Sie sind sich unsicher, welche Informationen über Sie im Internet kursieren und welche Systeme öffentlich aus dem Internet erreichbar sind? Beauftragen Sie eine passive Reconnaissance über unseren Pentest Konfigurator und wir tragen diese Informationen gerne für Sie zusammen.

Sie interessieren sich für die Widerstandsfähigkeit Ihrer öffentlichen IT-Infrastruktur gegenüber externen Angreifern? Sie möchten das schwächste Glied Ihrer IT-Assets identifizieren und Ihre SSL-Konfiguration technisch überprüfen lassen? Dann beauftragen Sie einen Penetrationstest Ihrer öffentlichen IT-Infrastruktur über unseren Pentest Konfigurator.

Quellen

[1] https://letsencrypt.org/de/stats/#
[2] https://letsencrypt.org/de/docs/ct-logs/
[3] https://www.eff.org/de/deeplinks/2011/09/post-mortem-iranian-diginotar-attack
[4] https://certificate.transparency.dev/community/
[5] https://letsencrypt.org/de/stats/#
[6] https://portswigger.net/daily-swig/researchers-demonstrate-practical-break-of-sha-1-hash-function

Code-Assisted Pentests

Zahlreiche Unternehmen setzen auf regelmäßige Penetrationstests, um ihre Anwendungen und IT-Infrastrukturen auf Schwachstellen zu prüfen. Meist wird hier aus der Sicht eines externen Angreifers mit einem Black-Box Ansatz, also ohne Informationen über die Anwendung oder Infrastruktur, getestet. Dies ist in vielen Situationen ein Kompromiss aus Testtiefe und der verfügbaren Testzeit. Ein beauftragter Penetrationstest hat das Ziel, in einer definierten Zeit möglichst viele potenzielle Schwachstellen aufzufinden.

Bei einem Code-Assisted Pentest steht dem Pentester der Quellcode oder zumindest ein Auszug relevanter Quellcode-Teile während der Analyse zur Verfügung. Diese Analysemethode bringt wesentliche Vorteile hinsichtlich der Effektivität und der Prüftiefe eines Pentests mit sich.

Im Folgenden betrachten wir die Vorteile aus Unternehmenssicht sowie konkrete Probleme, die sich für einen Tester ergeben und wie diese mit einem Code-Assisted Pentest gelöst werden können.

Code-Assisted Pentesting bedeutet Effizienz

Viele Penetrationstest gehen von der Annahme aus, dass ein möglicher Angriff durch einen externen Hacker nachgestellt werden soll. Die Frage, die oft hinter der Beauftragung steht, lautet: Kann ein externer Angreifer meine Anwendung kompromittieren?

Dementsprechend wird die Vorgehensweise eines Angriffs von außen oftmals gewählt und entspricht üblicherweise einem Black-Box-Ansatz. Der Pentester hat also keinerlei Informationen über die Anwendung, wie vermeintlich ein echter Hacker. Allerdings muss berücksichtigt werden, dass ein Pentester auch nur eine endliche Zeit für seinen Pentest zur Verfügung hat. Dies trifft auf einen realen Angreifer nicht unbedingt in gleichem Maße zu. Daher ist der Pentester darauf angewiesen, möglichst effektiv in der vorgegebenen Zeit zu testen.

Durch einen Code-Assisted Pentest kann sich der Testfokus hauptsächlich auf das Auffinden von Schwachstellen konzentrieren und ist beispielsweise nicht davon abhängig, eine zeitraubende, initiale Informationsgewinnungsphase (Enumeration) durchgeführt zu haben. Die folgenden Beispiele veranschaulichen die Probleme bei einem Black-Box-Ansatz.

Problematik 1: Enumerieren von Verzeichnissen und Endpunkten

Zu Beginn eines jeden Penetrationstests ist es notwendig, die Struktur der Applikation kennenzulernen und so viele Endpunkte wie möglich ausfindig zu machen. Die einzelnen Endpunkte interagieren mit dem Nutzer und können potenziell Schwachstellen beinhalten.

Da der Tester von außen auf den Applikationsserver zugreift, hat er nicht die Möglichkeit sich die Verzeichnis- oder Routenstruktur auf dem Server selbst anzusehen. Er muss somit eine Wörterliste mit möglichen Endpunkten nutzen und jeden einzelnen Eintrag vom Applikationsserver anfragen, um herauszufinden welche Endpunkte existieren. Die folgende Abbildung zeigt diesen Vorgang:

cap 1
Abbildung 1: Enumerieren von Applikationsendpunkten mit Wortlisten

Die Wortliste enthält meist mehrere 100.000 Einträge.  Oft sind Scan-Wiederholungen erforderlich, um die Scankonfiguration optimal auf das Antwortverhalten des Servers anzupassen.

Enthält die Wortliste den Namen eines verwundbaren Endpunktes nicht, so bleibt dieser meist unangetastet und wir nicht entdeckt. Gerade die zeitliche Begrenzung eines Penetrationstests limitiert den Tester in seinen Möglichkeiten zum Auffinden von Endpunkten oder Routen. Sollen Produktnamen des Kunden in die Wortliste aufgenommen werden, um so potenzielle Endpunkte zu finden? Soll die Webpräsenz des Kunden herunterladen und alle auf ihr enthaltenen Wörter in einem Scan inkludieren? Dies sind Entscheidungen mit meist unbekannten Folgen – auf jeden Fall erfordern sie zusätzliche Zeit, ohne die Trefferquote zum Auffinden eines Endpunkts sicher zu erhöhen.

Ohne einen Code-Assisted Pentest können Endpunkte und damit mögliche Schwachstellen unentdeckt bleiben.

Problematik 2: Eingabevalidierung

Nachdem eine Übersicht der Endpunkte erstellt wurde, identifiziert der Tester, welche Schnittstellen Nutzereingaben verarbeiten und prüft diese auf gängige Schwachstellentypen wie Cross-Site Scripting (XSS), Command Injection oder SQL Injection (SQLi). Hierbei tritt oft das Problem auf, dass der Anwendungsserver die Eingaben filtert und bösartige Zeichen entfernt, dem Pentester im Black-Box-Ansatz jedoch unbekannt ist, wie diese Filterung implementiert wurde.

Im Folgenden ist ein Codebeispiel (download.php) zu sehen, dass den Download von Systembackups in einer Webanwendung implementiert.

<?php
$file = str_replace('../', '', $_GET['file']);
if(isset($file)){ 
   downloadBackup("backups/$file");
}

Die Applikation liest den file Parameter einer Nutzeranfrage und gibt die angegebene Datei als Download zurück. Um das Ausbrechen aus dem aktuellen Verzeichnis zu verhindern, wird die Verzeichniswechselsequenz “../” mit einem Aufruf von str_replace() gefiltert. Ein Angreifer kann somit keinen unmittelbaren Angriff auf die Applikation ausführen, indem er mit einer Anfrage wie GET /download.php?file=../../../../../etc/passwd die Passwortdatei des Systems herunterlädt (sogenanntes Path Traversal). Als externer Tester ist jedoch ebenso unklar, wie der Server die Eingabe validiert.

Durch die zeitliche Begrenzung des Penetrationstests beginnt ein Spiel, bei dem der Tester abwägen muss, wie viele Eingaben er an den Server schickt, um mit hoher Wahrscheinlichkeit eine korrekte Aussage treffen zu können, dass die Komponente sicher implementiert wurde. In unserem Beispiel könnte er ein weiteres “../” an seine bösartige Anfrage anhängen – vielleicht waren es zu wenige Wechselsequenzen um in das Stammverzeichnis des Servers zu wechseln?

Nach einigen weiteren Tests kommt er möglicherweise zu der Entscheidung, dass die Komponente kein ausnutzbares Verhalten zeigt. Mit Sicht auf den Code wäre die Schwachstelle eindeutig: Die str_replace() Funktion ersetzt bösartige Sequenzen nicht rekursiv, sondern lediglich einmalig. Ein Angreifer könnte folgende Anfrage an den Server stellen, um die Passwortdatei auszulesen:

GET /download.php?file=….//….//….//….//….//etc/passwd

Die str_replace() Funktion ersetzt im file Parameter nun alle bösartigen “../” Sequenzen – was bleibt ist der Parameterwert: ../../../../../etc/passwd – dieser enthält nun die Wechselsequenz, die ein Ausbrechen aus dem backup Verzeichnis ermöglicht!

Bei einem Black-Box-Pentest ist es praktisch unmöglich alle denkbaren Varianten durchzuprobieren. Ein Code-Assisted Pentest würde diese Schwachstelle schnell und effizient identifizieren.

Code-Assisted Pentesting als Ansatz zur Lösung

Wie in den Beispielen erläutert, weitet sich diese Problematik auf viele Testabschnitte eines Penetrationstests aus. Folgende Fragen stehen beispielhaft für weitere Themen, die in einem Black-Box-Verfahren nicht oder nur unzureichend getestet werden können:

  • Wie sind die Passwörter in der Applikation gespeichert? Sind Kundenpasswörter bei einer Kompromittierung unmittelbar auslesbar oder als „Salted Hash“ gesichert?
  • Sind zufällige Tokens (z.B. zum Zurücksetzen eines Nutzeraccounts) tatsächlich zufällig? Existiert genügend Entropie, um einen Brute-Force Angriff zu verhindern?
  • Wurde ein Endpunkt in der Implementierung der Zugriffskontrolle vergessen?

Um diese Fragen beantworten zu können und kritische Applikationen mit der notwendigen Detailtiefe zu testen, bietet sich ein Code-Assisted Pentest an. Gemeinsam mit dem Penetrationstester werden kritische Applikationskomponenten identifiziert und der Quellcode selektiert. Dadurch kann sichergestellt werden, dass der Quellcode nicht vollständig beim Pentester vorliegen muss, sondern nur die Teile, die für die Analyse zwingend notwendig sind.

Der Aufwand eines Code-Assisted Pentests ist nur unwesentlich höher als bei einem Pentest nach dem Black-Box-Ansatz. Dieser Aufwand wird durch einen Gewinn an Effektivität und Prüftiefe problemlos ausgeglichen. Das Ergebnis ist ein Pentest, der deutlich mehr Schwachstellen abdeckt und in der vorgegebenen Zeit daher wesentlich genauere Ergebnisse liefert.