Was ist XML-Signaturumbruch?
XML Signature Wrapping (XSW) ist eine Klasse von Cyberangriffen , die die Art und Weise ausnutzen, wie XML-Signaturen in Anwendungen validiert werden, die XML-basierte Sicherheitsprotokolle verwenden, insbesondere in Security Assertion Markup Language (SAML), Simple Object Access Protocol (SOAP) und Web Services Security (WS-Security oder WSS).
Angriffe zum Umschließen von Signaturelementen zielen darauf ab, die Authentifizierung zu umgehen und unbefugten Zugriff zu erlangen, indem die Struktur eines XML-Dokuments manipuliert wird, ohne dessen digitale Signatur ungültig zu machen.
Ein XML-Signatur-Wrapping-Angriff nutzt die Lücke zwischen dem Signaturvalidierungsprozess und der Datenverarbeitung aus. Der Angreifer fügt ein doppeltes oder manipuliertes Element (z. B. eine gefälschte SAML-Assertion oder einen SOAP-Text) außerhalb des signierten Teils ein. Die Anwendung verarbeitet daraufhin die bösartigen Daten.
Würde Ihr Team den nächsten Zero-Day rechtzeitig erkennen?
Schließen Sie sich Führungskräften im Bereich Sicherheit an, die von den kuratierten Nachrichten zu KI, Cybersicherheit, Daten und Automatisierung im Think Newsletter profitieren. Lernen Sie schnell von Experten-Tutorials und Erläuterungen, die direkt in Ihren Posteingang geliefert werden. Weitere Informationen finden Sie in der IBM Datenschutzerklärung.
Extensible Markup Language (XML) ist ein textbasiertes Datenformat, mit dem Daten so strukturiert und gespeichert werden, dass sie sowohl für Menschen als auch für Maschinen lesbar sind. Es wird in Webdiensten, Identitätssystemen und beim Datenaustausch zwischen Anwendungen verwendet.
Wie HTML ist XML mit Tags strukturiert, die Daten darstellen sollen. Es unterstützt verschachtelte Elemente und Attribute, die komplexe Hierarchien ermöglichen.
XML wird häufig in SOAP-, SAML- und WS-Security-Protokollen verwendet.
Beispiel für XML
Eine XML-Signatur ist eine digitale Signatur, die auf XML-Daten angewendet wird und in der W3C-XML-Signaturspezifikation definiert ist. Das XML-Signaturelement trägt zur Gewährleistung der Datenintegrität bei, indem es sicherstellt, dass die Daten vertrauenswürdig und überprüfbar sind und nicht manipuliert wurden.
- Ein Teil des XML-Dokuments wird zum Signieren ausgewählt, indem ein
<Reference> -Element mit einer ID (z. B. #ID123).
Für diese Daten wird ein Hash oder Digest berechnet.
Der Hash wird mit dem privaten Schlüssel des Absenders verschlüsselt, um die Signatur zu bilden.
A
<Signature> -Block wird dem Dokument mit SignedInfo hinzugefügt, das die Referenz-URI, SignatureValue mit dem verschlüsselten Hash und KeyInfo wie öffentlicher Schlüssel oder Zertifikat enthält.
Beispiel für die Syntax einer XML-Signatur
<!-- Weitere Details wie DigestMethod, CanonicalizationMethod -->
XML-Signatur-Wrapping-Angriffe ausnutzen die strukturelle Flexibilität von XML, um Anwendungen dazu zu bringen, nicht authentifizierte Daten zu verarbeiten, während die Signaturvalidierung besteht. Angreifer erzeugen eine Diskrepanz zwischen dem signierten Element und dem tatsächlich verarbeiteten Element (in der Regel durch Duplizieren oder Verschieben von Elementen). Das Ergebnis ist, dass die Anwendung nicht signierte Inhalte verwendet, obwohl die Signatur gültig erscheint.
So funktionieren XML-Signature-Wrapping-Angriffe (XSW) normalerweise:
Angreifer beginnen mit einer echten, vertrauenswürdigen XML-Nachricht, beispielsweise einer gültigen Anmeldeantwort, die digital signiert ist (z. B. eine legitime SAML-Antwort).
Sie verschieben den signierten Teil (den, auf den in der) referenziert wird
<ds:Reference URI=”#ID123”/> ) an eine andere Stelle im Dokument ein, an der es technisch noch vorhanden, aber nicht verwendet wird.
Sie legen gefälschte Daten am ursprünglichen Ort ab. Diese gefälschten Daten sind nicht signiert, sehen aber legitim aus.
Die meisten Anwendungen suchen nach Daten anhand des Tag-Namens oder des XPath-Ausdrucks und nicht, indem sie prüfen, ob es sich um die signierte Version handelt, sodass sie am Ende die gefälschten Daten verwenden.
Die digitale Signatur ist immer noch aktiv, da sie den ursprünglichen (jetzt verborgenen) signierten Teil Verifyt und nicht den gefälschten Teil, den die App verwendet.
Die Anwendung denkt also, dass sie mit einem sicheren signierten Dokument arbeitet, aber in Wirklichkeit handelt es sich um nicht autorisierte, manipulierte Daten.
Exemplarische Vorgehensweise: Ein XSW-Angriff in der Praxis
Dieses Beispiel zeigt, wie ein Angreifer eine signierte SAML-Assertion manipulieren kann, um unbefugten Administratorzugriff zu erhalten, indem er eine schwache XML-Parsing- und Validierungslogik ausnutzt.
SAML ist ein XML-basiertes Protokoll, das für den sicheren Austausch von Authentifizierungsinformationen zwischen zwei Systemen verwendet wird: dem Identitätsanbieter (IdP) und dem Dienstanbieter (SP). Es ermöglicht Single Sign-On (SSO), sodass Benutzer sich einmal authentifizieren und ohne wiederholte Anmeldungen auf mehrere Dienste zugreifen können.
1. Ursprünglicher SAML-Antrag
Dies ist eine echte SAML-Anfrage, die von einem Tool wie SAML Raider in der Burp Suite erfasst wurde. Er enthält einen digital signierten Abschnitt, der als SAML-Assertion bezeichnet wird und die Identitätsdetails des Benutzers enthält. In dieser Aussage ist enthalten:
Die Anforderung enthält auch eine gültige digitale Signatur (
2. Beobachten des angemeldeten Benutzers
In der Antwort der App wird der Benutzer als mit der ursprünglichen Identität angemeldet angezeigt
3. Veränderte SAML-Assertion (XSW-Angriff durchgeführt)
Der Angreifer modifiziert die SAML-Anforderung heimlich, indem er die ursprüngliche, digital signierte Assertion in einen anderen Teil des XML-Dokuments verschiebt, sodass die Signatur gültig bleibt und die Überprüfung besteht.
Eine Fälschung
Diese Aktivität veranschaulicht das Kernkonzept eines XSW-Angriffs: Die digitale Signatur scheint gültig zu sein, aber die von der Anwendung verarbeiteten Daten sind gefälscht und nicht vertrauenswürdig.
4. Erfolgreicher Admin-Zugang
Als Ergebnis gewährt die Anwendung Administratorzugriff auf die vom Angreifer eingefügte gefälschte Assertion. Es kann nicht Verify, ob die verarbeitete Assertion die tatsächlich digital signierte Assertion war. Dieser Fehler ermöglicht es dem Angreifer, sich erfolgreich als Admin-Benutzer auszugeben. Das System, das es dem Benutzer ermöglicht, sich als admin@libcurl.so anzumelden, zeigt deutlich, dass der XML-Signatur-Wrapping-Angriff erfolgreich war.
Dieses Beispiel zeigt, wie eine schwache XML-Signaturprüfung dazu gebracht werden kann, gefälschten Daten zu vertrauen. Der Angreifer bricht die digitale Signatur nicht. Stattdessen werden die signierten Daten verschoben und gefälschte Informationen werden dort platziert, wo die App die echten Daten erwartet. Die Anwendung verarbeitet die gefälschten Daten dann fälschlicherweise und glaubt, dass sie sicher sind.
XSW-Angriffe lassen sich in der Regel in einige Hauptuntergruppen oder -typen einteilen, die jeweils die Art und Weise ausnutzen, wie die XML-Signaturüberprüfung und das Parsing implementiert werden.
Hier ist eine Aufschlüsselung der häufigsten:
1. Einfacher Wrapping-Angriff
Methode: Der Angreifer verschiebt das signierte Element in einen anderen Teil des XML-Dokuments und fügt an seiner ursprünglichen Stelle ein schädliches Element ein.
Ziel: Die Signatur wird weiterhin verifiziert (da die signierten Daten unverändert bleiben), aber die Anwendung verarbeitet stattdessen die injizierten Daten des Angreifers.
Beispiel: Signiert
2. ID-basiertes Wrapping
Methode: Der Angreifer nutzt die Verwendung von XML-ID-Attributen aus, um auf signierte Daten zu verweisen.
Ziel: Angreifer erstellt ein doppeltes Element mit derselben ID, platziert es aber an einem Ort, den die Anwendung zuerst verarbeitet.
Beispiel: Die Signatur verweist auf #ID-1234, aber der Parser verwendet das fake-Element des Angreifers mit dieser ID anstelle der signierten.
3. Wrapping für die Namespace-Injektion
Methode: Der Angreifer manipuliert XML-Namespaces, um die Signaturvalidierung zu verwirren.
Ziel: Elementinterpretation ändern oder strenge Schemaprüfungen umgehen und dabei die Signatur gültig halten.
Beispiel: Einfügen eines bösartigen <Assertion> -Elements in einen neuen Namespace, sodass die Validierung bestanden wird, die Verarbeitungslogik sie jedoch akzeptiert.
4. XSW mit umhülltem Signaturmissbrauch
Methode: Ändert die Platzierung von
Ziel: Der Validator soll denken, dass alles signiert ist, aber die vom Angreifer kontrollierten Teile von der Signaturabdeckung ausschließen.
Beispiel: Verschieben Sie das Original
5. XPath-Injektionsverpackung
Methode: Manipuliert XPath-Abfragen, die während der Signaturvalidierung verwendet werden, so, dass sie auf vom Angreifer kontrollierte Knoten statt auf den signierten Knoten verweisen.
Ziel: Den Signaturprüfer dazu zu bringen, harmlose Daten zu überprüfen, während die Anwendung bösartige Daten verarbeitet.
Beispiel: Passen Sie das XML so an, dass der XPath des Prüfers (z. B.
XSW-Angriffe können schwerwiegende reale Folgen haben, insbesondere wenn es um vertrauliche Daten oder entscheidende Vorgänge geht. Diese hypothetischen Szenarien verdeutlichen die potenziellen Auswirkungen solcher Angriffe.
Szenario 1: Umgehung der Authentifizierung in SAML SSO
Szenario: Eine Unternehmensanwendung verwendet SAML-basiertes Single Sign-On zur Authentifizierung von Benutzern. Jede Anmeldeantwort enthält eine digital signierte SAML-Assertion, die den Benutzer identifiziert.
XSW-Angriff: Ein Angreifer erfasst eine legitime SAML-Antwort, verschiebt die signierte Assertion in einen anderen Teil des XML-Dokuments und fügt an ihrer Stelle eine gefälschte Assertion ein, die sich als Administrator ausgibt.
Auswirkung: Das System validiert die Signatur auf der ursprünglichen Assertion, verarbeitet aber die nicht signierte, vom Angreifer eingefügte Assertion und gewährt dem Bedrohungsakteur als privilegierten Benutzer Zugriff.
2. Szenario: Rechteausweitung in Webdiensten
Szenario: Eine Web-Service-Anwendungsprogrammierschnittstelle (API) verwendet SOAP und WS-Security, um Anfragen zu verarbeiten. Der SOAP-Nachrichtentext ist digital signiert, um sicherzustellen, dass der Befehl vertrauenswürdig ist.
XSW-Angriff: Der Angreifer wickelt den ursprünglichen, signierten SOAP-Body in ein harmloses Wrapper-Element ein und ersetzt ihn durch einen neuen, unsignierten Body, der erhöhte Berechtigungen oder nicht autorisierte Aktionen enthält.
Aufprall: Wenn der Dienst den nicht signierten Text verarbeitet, kann der Angreifer Berechtigungen ausweiten oder eingeschränkte Aktionen wie das Anzeigen oder Ändern vertraulicher Daten ausführen.
3. Szenario: Unbefugter Zugriff auf kritische Funktionen
Szenario: Über eine administrative Schnittstelle können Benutzer XML-basierte Befehle absenden, z. B. das Löschen von Konten oder das Zurücksetzen von Passwörtern, die durch digitale Signaturen geschützt sind.
XSW-Angriff: Der Angreifer verschiebt den signierten Befehl an einen sekundären Ort und fügt an seiner Stelle einen nicht signierten Befehl (z. B. das Löschen des Kontos eines anderen Benutzers oder das Zurücksetzen des Administratorpassworts) ein.
Auswirkung: Wenn die Anwendung den nicht signierten Befehl verarbeitet, kann sie entscheidende Operationen im Namen eines nicht autorisierten Benutzers ausführen.
4. Szenario: Manipulation digital signierter Zahlungsaufforderungen
Szenario: Eine Bank sichert ihre Geldtransfervorgänge durch die Verwendung von XML-Signaturen ab. Jede Anfrage enthält Transaktionsdetails wie den Überweisungsbetrag sowie die Kontonummern des Absenders und des Empfängers. Anfragen werden digital signiert, um die Authentizität zu gewährleisten.
XSW-Angriff: Ein Angreifer erfasst eine gültige Überweisungsanforderung, verschiebt die signierten Daten in einen unkritischen Abschnitt des Dokuments und fügt eine gefälschte Transaktion mit einem größeren Betrag und einem anderen Empfängerkonto ein.
Auswirkung: Wenn die Anwendung nicht strikt überprüft, dass es sich bei der verarbeiteten Transaktion um die signierte handelt, kann sie die gefälschte Transaktion des Angreifers ausführen, was zu unautorisierten Überweisungen und finanziellen Verlusten führt.
5. Szenario: Manipulation von signierten Authentifizierungs-Tokens
Szenario: Eine Online-Plattform sichert ihre Token durch die Verwendung digitaler XML-Signaturen. Jedes Token enthält Informationen zur Benutzeridentität und Zugriffsrechte und ist kryptografisch signiert, um Manipulationen zu verhindern.
XSW-Angriff: Ein Angreifer erfasst ein gültiges Token, verschiebt den signierten Teil an eine andere Stelle innerhalb der XML und fügt ein neues, nicht signiertes Segment ein, das erhöhte oder nicht autorisierte Berechtigungen enthält.
Auswirkung: Wenn der Server den manipulierten Abschnitt anstelle des signierten Abschnitts verarbeitet, kann der Angreifer sich unbefugten Zugriff verschaffen oder privilegierte Operationen durchführen, was die Sicherheit der Anwendung gefährdet.
Um zu analysieren, ob eine Anwendung für XML-Signatur-Wrapping-Angriffe anfällig ist, ist es wichtig zu verstehen, wie sie XML-Daten analysiert und verarbeitet. Es ist besonders wichtig, das XML-Parsing und die Verarbeitung in sicherheitsrelevanten Kontexten wie SAML-Authentifizierung oder SOAP-Messaging zu verstehen.
Hier sind einige Techniken und Strategien zur Identifizierung solcher Schwachstellen in realen Umgebungen:
1. Analysieren Sie, wie die Anwendung XML analysiert
Überprüfen Sie, ob die Anwendung Elemente extrahiert wie
2. Verwenden Sie Burp Suite SAML Raider oder benutzerdefinierte Proxys.
Verwenden Sie die Burp Suite mit SAML Raider, um ein gefälschtes, nicht signiertes Element einzufügen und das signierte Element zu verpacken. Wenn die App die gefälschten Daten verarbeitet, während die Signatur noch validiert, ist sie anfällig für XSW.
3. Testen Sie auf doppelte Elemente mit demselben Tag
Fügen Sie eine signierte Assertion an einem versteckten Abschnitt und eine gefälschte an einer sichtbaren Stelle ein. Wenn die App die gefälschten Daten verarbeitet, ist sie anfällig für XSW.
4. Überprüfen Sie das Verhalten der Signaturreferenz
Verschieben Sie das signierte Element (dasjenige, auf das verwiesen wird in
Wenn die Anwendung die nicht signierte Version anstelle der tatsächlich signierten Version verarbeitet, ist die Anwendung anfällig für einen XSW-Angriff. Die App validiert die Signatur korrekt, kann jedoch nicht sicherstellen, dass sie den signierten Inhalt verwendet. Dadurch können Angreifer nicht autorisierte Daten einschleusen.
5. Überprüfen Sie die Fehlerbehandlung und das Protokollierungsverhalten
Senden Sie fehlerhafte Assertionen und beobachten Sie ausführliche Fehler oder inkonsistente Antworten. Diese Antworten können Schwachstellen in der XML-Sicherheits- und Validierungslogik der App aufdecken.
6. Nutzen Sie bekannte XSW-Ausbeutung-Techniken für Tests
Verwenden Sie Tools wie SAML Raider, SoapUI oder benutzerdefinierte XML-Testkabel, um XSW-Angriffsmuster anzuwenden. Wenn die Anwendung eine der Nutzlasten akzeptiert und verarbeitet, weist dies auf eine XSW-Schwachstelle hin.
7. Überprüfen Sie den Anwendungs-Code
Wenn die App XML-Daten liest, indem sie Elemente basierend auf dem Tag-Namen auswählt, ohne sicherzustellen, dass sie das signierte, vertrauenswürdige Element verwendet, kann sie zur Verarbeitung gefälschter Daten verleitet werden.
Um eine Anwendung vor XSW-Angriffen zu schützen, können Entwickler eine strikte XML-Verarbeitung implementieren, Signaturen korrekt validieren und sicherstellen, dass nur vertrauenswürdige, signierte Daten verwendet werden.
Hier sind einige spezifische Gegenmaßnahmen, die bei der Abwehr von XSW-Angriffen helfen können:
Stellen Sie sicher, dass das genaue XML-Element, das für die Authentifizierung oder Autorisierung verwendet wird, dasselbe ist, das digital signiert wurde. Dadurch wird verhindert, dass Angreifer eine zweite, nicht signierte Assertion anstelle der legitimen, signierten Assertion einschleusen, die von der Anwendung fälschlicherweise verarbeitet wird.
Eine umgeschlagene Signatur ist eine Signatur, die innerhalb des Elements, das sie signiert, platziert wird. Enveloping erschwert es Angreifern, bösartige Elemente außerhalb des signierten Inhalts einzufügen, ohne die Struktur zu beschädigen, und trägt so dazu bei, Wrapping oder Substitution zu verhindern.
Verwenden Sie einen sicheren XML-Parser, der so konfiguriert ist, dass Dokumente mit doppelten IDs, externen Entitätsverweisen oder unerwarteten Strukturen abgelehnt werden. XSW beruht auf der Manipulation der XML-Struktur, z. B. durch das Einfügen doppelter Tags oder mehrerer Assertionen. Durch striktes Parsen wird diese Angriffsfläche verringert, indem wohlgeformte, schemakonforme Eingaben erzwungen werden.
Verknüpfen Sie die Verarbeitungslogik der Anwendung direkt mit dem XML-Element, auf das in der Signatur verwiesen wird (durch Verwendung des ID-Attributs oder der Signatur).
Lehnen Sie SAML-Antworten ab, die mehr als eine <Assertion> enthalten, es sei denn, dies ist ausdrücklich erforderlich. XSW-Angriffe injizieren oft eine zweite Assertion. Wenn nur eine Verarbeitung erfolgt, werden Mehrdeutigkeiten vermieden und das Risiko verringert.
Verwenden Sie gut gewartete und sicherheitsorientierte Bibliotheken für die Validierung digitaler XML-Signaturen (z. B. Apache Santuario oder OpenSAML) mit sicheren Standardkonfigurationen. Diese Bibliotheken verfügen häufig über einen integrierten Schutz vor Signaturumbruch, wenn sie richtig konfiguriert sind.
Validieren Sie eingehende SAML-Asserments anhand der offiziellen SAML-XML-Schema-Definition (XSD). Die Validierung verhindert, dass Angreifer unerwartete Elemente oder Attribute einfügen, die die Geschäftslogik umgehen oder den XML-Parser verwirren.
Stellen Sie sicher, dass jedes ID-Attribut, das in signiertem XML verwendet wird (z. B. Assertionen), eindeutig ist und dass Referenzen nur mit einem Element übereinstimmen. XSW-Ausnutzung kann erfolgreich sein, indem sie auf ein Element in der Signatur verweisen und gleichzeitig ein anderes mit derselben ID oder demselben Tag-Namen einfügen. Durch Erzwingen von Einzigartigkeit kann diese Verwirrung vermieden werden.
Diese Praktiken können das Risiko verringern, dass Angreifer XML-Strukturen und die Logik der Signaturverarbeitung ausnutzen, und damit die Tür für viele XSW-Angriffe schließen.