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.