‍

Kennen wir diese Anfrage nicht schon? SAML-Replay-Angriffe

‍

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. Auf diese Weise hoffen wir, 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 verfasst von Kaou Tamine

Credits: Die Schwachstelle dieses Monats wurde von dem Hacker simioni gemeldet

Kontext des Bug-Bounty-Programms

• Ein zeitlich und budgetär begrenztes privates Programm
• Im Scope befinden sich mehrere cloudbasierte Systeme des Kunden
• Zeitraum zwischen Programmstart und Einreichung des Berichts: ~2 Monate

Warum diese Schwachstelle

‍

Ein echter Klassiker! Wann immer Authentifizierungsprotokolle im Spiel sind, ist der Umgang mit Authentifizierungs-Tokens und all ihren Eigenschaften wie Ablaufdatum und Nonce eine Herausforderung. Geschieht dies nicht korrekt, ist das System anfällig für Replay-Angriffe aller Art.

Das betroffene System

‍

Ein Cloud-basiertes System, das einen Datenkatalog sowie Metadaten zu verschiedenen, an anderer Stelle gespeicherten Daten enthält. Konkret geht es um den Endpunkt, der die Authentifizierung abwickelt und die vom zentralen Identitätsanbieter (IdP) des Kunden bereitgestellten SAML-Assertions verarbeitet.

Die vom Hacker beschriebene Schwachstelle

‍

Bei dieser Schwachstelle dreht sich alles um die sorgfältige Beobachtung und ordnungsgemässe Überprüfung von Daten an den Endpunkten.

‍

Hier bemerkt der Hacker, dass es kein Ablaufdatum für das SAML gibt (die «NotOnOrAfter»-Bedingung). Er stellt zudem fest, dass die SAML-Assertion nach der Verwendung nicht ungültig wird und wiederverwendet werden kann. Der Angriff wird auf unserer Plattform durch seine Manipulationen mit der Burp Suite verdeutlicht (ein grosses Dankeschön an Roland Bischofberger und Emanuel Duss für das grossartige Burp Suite-Plugin 🙂):

‍

• 1^. Anfrage mit der SAML-Assertion, ausgestellt um 18:39 Uhr:

‍

‍

• Die 2^. Anfrage, die dieselbe SAML-Assertion enthält, ausgestellt um 18:51 Uhr:

‍

‍

• Die gleiche Anfrage mit dekodierter SAML-Antwort (bitte beachten Sie den Unterschied zwischen GMT und Ortszeit):

‍

‍

Wir können Folgendes feststellen:

‍

Eine Anfrage mit einer wiederverwendeten SAML-Assertion wird auch nach Ablauf des «NotOnOrAfter»-Zeitstempels akzeptiert; die Weiterleitung zum SSO-Callback mit einem gültigen Zugriffstoken erfolgt wie bei der ursprünglichen, gültigen Assertion.

Auswirkungsanalyse

‍

Die Kritikalität ist begrenzt, da die Voraussetzung besteht, zunächst eine gültige SAML-Assertion zu erlangen. Sobald eine solche jedoch vorliegt, kann die Assertion über einen längeren Zeitraum wiederverwendet werden, wodurch das System hinter der SAML-basierten SSO-Authentifizierung gefährdet wird.

Lassen Sie uns zusammenarbeiten!

‍

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.

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

‍