‍

AES-Bits wenden wie Pfannkuchen: Wie ein Hacker sich Admin-Zugriff verschaffte

‍

Willkommen zurück zu unserer Blogserie: Schwachstelle des Monats! Mit dieser Reihe möchten wir Ihnen Einblicke in unsere tägliche Arbeit und die unserer Hacker geben und über Sicherheitslücken sprechen. Wir hoffen, damit wichtiges Sicherheitswissen über spezifische Schwachstellen, deren Auffindung und die dabei verwendeten Techniken zu verbreiten und so das Bewusstsein für all die Sicherheitslücken zu schärfen, die möglicherweise noch existieren.

‍

Autor: Der Blogbeitrag dieses Monats wurde von Kaou Tamine verfasst

Credits: Die Schwachstelle dieses Monats wurde von Raphaël Arrouas („Xel“) gemeldet

‍

Kontext des Bug-Bounty-Programms

• Ein zeitlich und budgetär begrenztes privates Programm
• Nahezu die gesamte im Internet exponierte Angriffsfläche des Kunden war Teil des Scopes
• Zeitraum zwischen Programmstart und Einreichung des Berichts: 10 Tage

‍

Das betroffene System

‍

Ein System mit mehreren Websites, die verschiedene Dienste bereitstellen, von Stellenangeboten über interne Dateiaustauschplattformen bis hin zu Schnittstellen für sensible Datenbankabfragen.

‍

Die vom Hacker beschriebene Schwachstelle

‍

‍

Der Weg zum Hack

‍

Der erste Schritt besteht darin, einen Admin-Login-Bereich zu identifizieren, der durch eine WAF (Web Application Firewall) geschützt ist. Diese WAF lässt sich leicht umgehen, indem man die Schrägstriche im URL-Link von „/“ in „\“ umkehrt.

‍

Es gibt mehrere Dienste, die eine Authentifizierung am Backend ermöglichen. Einer davon zeigt bei der Weiterleitung eine [STATE]-Variable in der URL an. Aus einem früheren Schwachstellenbericht, der eine Offenlegung des Quellcodes enthielt, ist bekannt, dass diese Variable mit einem symmetrischen Verschlüsselungsverfahren namens AES-CBC verschlüsselt wird. Wenn es uns gelingt, diesen STATE-Parameter mit den richtigen Informationen zu manipulieren, kann ein Administratorzugriff auf das Backend erlangt werden; der Hack basiert also auf dieser Idee.

‍

Bei der Untersuchung des Quellcodes des Backend-Authentifikators fällt auf, dass zwar AES-CBC-Verschlüsselung (eine symmetrische Blockchiffre) für das SSO verwendet wird, jedoch keine Überprüfung auf Manipulation stattfindet. Genau das ermöglicht es, Daten in den State-Parameter einzuschleusen, ohne Alarm auszulösen.

‍

Betrachten wir den AES-CBC-Betriebsmodus:

‍

‍

Wir sehen, dass es möglich ist, beliebige Inhalte in einen Block einzuschleusen, indem man den vorherigen Block modifiziert, da der vorherige Block in den nächsten einfliesst. Der Hacker erklärt:

‍

‍

Die Auswirkungen des Angriffs beschränken sich auf die vollständige Kontrolle über einen Block N, wobei Block N-1 unbrauchbar wird. Da es keine Mechanismen zur Überprüfung auf Manipulationen gibt, löst Block N-1 im Backend keinen Alarm aus. Da nur das Feld für den Benutzernamen injiziert werden muss, reicht die Modifikation eines einzigen Blocks aus, um die Authentifizierung zu umgehen.

‍

Um die Sache zu vereinfachen, stellte der Hacker ein 15-zeiliges Python-Skript zur Verfügung, mit dem eine URL generiert werden kann, die bei einem Klick vollen Administratorzugriff auf das Backend gewährt – mehr ist nicht nötig:

‍

‍

Auswirkungsanalyse

‍

Vollständiger Administratorzugriff auf das Backend. Da der Authentifizierungsdienst aus einem Multi-Tenant-Unternehmenskontext stammt, sind auch alle anderen Kunden, die dasselbe System oder dieselbe Software nutzen, gefährdet.

‍

Laufende Schritte

‍

(Entweder durch uns, den Kunden oder in Kombination):

• Abstimmung mit dem Anbieter zur Behebung der Schwachstelle
• Herausgabe eines CVE-Advisory

‍

Unsere Perspektive

‍

Was ist schiefgelaufen?

‍

Der Hauptfehler bestand darin, dass AES-CBC nicht mit einem HMAC (Hash-based Message Authentication Code) kombiniert wurde, um Authentizität und Korrektheit zu überprüfen. Oder die Wahl des Algorithmus war wahrscheinlich nicht optimal – ein anderer, nicht anfälliger für Bit-Flipping-Angriffe, hätte problemlos gewählt werden können (Xel schlug AES-GCM vor).

‍

Der Zugriff auf den Backend-Quellcode des Authenticators ist aus unserer Sicht unproblematisch, da kryptografische Sicherheitsmodelle grundsätzlich davon ausgehen sollten, dass der Code, der die kryptografischen Protokolle ausführt, für Angreifer einsehbar ist.

‍

Die wichtigste Lektion

‍

Für Entwickler: Kryptografische Protokolle sollten immer aus einer offiziellen Quelle stammen und niemals selbst implementiert werden. Jeder Baustein eines kryptografischen Protokolls hat in der Regel seine Berechtigung. Wird einer dieser Bausteine weggelassen, kann die Sicherheit sehr leicht kompromittiert werden. Es sollte NIEMALS einen Grund geben, Teile eines Protokolls zu entfernen, um Backend-Anforderungen gerecht zu werden.

‍

Für White-Hat-Hacker: Die Überprüfung der korrekten Anwendung kryptografischer Protokolle ist immer eine gute Idee, da Kryptografie meist bei der Implementierung scheitert…

‍

Interessieren Sie sich für dieses Thema und möchten Sie mit unseren Kunden und Hackern an solchen Schwachstellen arbeiten? Wir stellen ein – melden Sie sich gerne bei uns.

‍

Interessiert daran, Schwachstellen zu finden? Wir sind immer auf der Suche nach neuen Hacking-Talenten – registrieren Sie sich bitte hier: www.signalfisher.com!