Den Kern ausnutzen: Ein Blick auf die BTP- und ABAP-Sicherheitslücken, die von Angreifern ausgenutzt werden
Da Unternehmen zunehmend auf die SAP Business Technology Platform BTP) setzen, um eine moderne, agile Architektur zu erreichen, verschiebt sich die traditionelle Sicherheitsgrenze rund um das ERP-System. SAP treibt die „Clean Core“-Strategie voran, um kundenspezifische Logik aus dem Kernsystem auszulagern. Die Migration kundenspezifischer Anwendungen in die cloud jedoch cloud automatisch Sicherheitsrisiken.
In Folge 1 unserer Doku-Serie „Hacking & Defending SAP Applications Live“ analysierten die Onapsis-Forscher Ignacio Favro und Fabian Hagg die erste massenhaft ausgenutzte SAP-Zero-Day-Sicherheitslücke (CVE-2025-31324 und CVE-2025-42999). Raffinierte Angreifer nutzten diese bislang unbekannte Schwachstelle aus, um Hunderte von SAP-Kunden zu kompromittieren.
Aufbauend auf diesen Erkenntnissen Hacking und Verteidigung von SAP-Anwendungen live: Clean Core, Dark Shadows (Folge 2 unserer Doku-Serie) den Fokus von Perimeter-Bedrohungen auf die Anwendungsebene. In diesem Briefing präsentiert JP Perez-Etchegoyen, CTO von Onapsis, zwei risikoreiche Bedrohungsszenarien, die zeigen, wie unüberprüfter ABAP-Custom-Code und BTP-Erweiterungen eine breite, komplexe Angriffsfläche geschaffen haben, die Cyberkriminelle aktiv ausnutzen.
Szenario 1: Der wohlmeinende BTP-Entwickler und die Nutzung von Cloud
Das erste Szenario handelt von einer klassischen Herausforderung in der modernen Unternehmensentwicklung: Ein hochqualifizierter, wohlmeinender BTP-Anwendungsentwickler erstellt benutzerdefinierte Node.js- und cloud , ohne über fundierte Kenntnisse im Bereich Anwendungssicherheit zu verfügen. Bei dem Versuch, zentrale Self-Service-Funktionen für das Kerngeschäft bereitzustellen, verursacht dieser Entwickler kritische Programmierfehler, die es einem externen Angreifer ermöglichen, sich direkt Zugang zum Backend-Produktionssystem zu verschaffen.
Architekturdiagramm, das den Angriffspfad eines externen Angreifers von der ersten Anmeldung bei einer BTP-Fiori-Anwendung über IDOR- und OS-Befehlsinjektionsschwachstellen bis hin zur Exfiltration von VCAP_SERVICES und die Entführung von Ziel-Anmeldedaten, um den lokalen S/4HANA-Kern zu kompromittieren.
Angriffskette:
[Angreifer-Anmeldung] ➔ [IDOR-Ausnutzung] ➔ [OS-Befehlsinjektion] ➔ [Exfiltration von VCAP_SERVICES] ➔ [Zugriff auf gestohlenen OAuth-Client] ➔ [Kompromittierung des lokalen Kernsystems]
Der erste Einstieg: Unsichere direkte Objektverweise (IDOR)
Ein Angreifer meldet sich bei einer sauberen, modernen Fiori-Self-Service-Anwendung mit einem legitimen Mitarbeiterkonto mit geringen Berechtigungen an, das einem Benutzer namens Sam Brennan gehört. Beim Durchsehen seines eigenen Profils bemerkt der Angreifer, dass Benutzerinformationen über bestimmte Parameter in der URL-Zeichenkette der Anwendung abgerufen werden.
Durch die Ausführung eines einfachen IDOR-Angriffs und die Änderung des Parameterwerts versäumt es die Anwendungslogik, eine explizite Autorisierungsprüfung durchzuführen. Diese Schwachstelle ermöglicht es einem Benutzer mit geringen Berechtigungen, sofort auf die geschützten Profildaten und Vergütungsunterlagen anderer Benutzer, einschließlich des Unternehmensvorstands, zuzugreifen.
Der Dreh- und Angelpunkt: Cross-Site-Scripting (XSS) und Session-Exfiltration
Der Angreifer stellt fest, dass der Textblock in der Profilbeschreibung keine ordnungsgemäße Eingabevalidierung und -bereinigung aufweist. Durch das Einfügen einer persistenten XSS-Nutzlast in das Feld wird der Schadcode direkt in der Datenbank gespeichert. Jeder nachfolgende Benutzer oder Systemadministrator, der dieses bestimmte Profil aufruft, löst das Skript aus, wodurch der Angreifer unbemerkt Sitzungsdaten abgreifen und Konten von Führungskräften kompromittieren kann.
Waffenisierung: OS-Befehlsinjektion und Diebstahl von Daten aus Cloud
Die Anwendung enthält ein legitimes Dienstprogramm, mit dem Mitarbeiter ihre monatlichen Gehaltsabrechnungen exportieren können. Der Angreifer stellt fest, dass die Dateiverarbeitungsfunktion Eingabezeichen ohne strenge Validierung akzeptiert, wodurch eine Schwachstelle für die Einschleusung von Betriebssystembefehlen entsteht.
Der Angreifer gibt bösartige Befehlszeichenfolgen in den Parameter „filename“ ein und zwingt so das zugrunde liegende Cloud -Backend dazu, seine interne Systemarchitektur und Umgebungsdatenvariablen (VCAP_SERVICES) auszugeben.
Code-Schnipsel: Anfälliger Node.js-Endpunkt auf SAP BTP
app.get(‘/payslip-download/:filename’, function (req, res) {
var filename = req.params.filename;
try {
const output = cp.execSync(
„cat /tmp/payslips/“ + Dateiname + „.txt“,
Onapsis Control der Probleme
Exfiltration der Anmeldedaten des Ziel-Dienstes
Die Rohdaten von VCAP_SERVICES enthalten streng vertrauliche Client-IDs und Client-Geheimnisse, die zur Verbindung der BTP-Anwendung mit dem zentralen BTP-Zielservice verwendet werden. Mit diesen gestohlenen Anmeldedaten führt der Angreifer ein benutzerdefiniertes Skript direkt am API-Endpunkt des Zielservices aus.
Der BTP-Zielservice speichert die technischen Benutzernamen und Passwörter, die zur Verbindung von cloud mit lokalen Netzwerken verwendet werden, auf sichere Weise. Da es der Zielkonfiguration an robusten Zero-Trust-API-Einschränkungen mangelt, gibt das Skript die Administrator-Anmeldedaten für den S/4HANA-Kern im Produktions-Backend im Klartext zurück.
Der Angreifer nutzt diese gestohlenen technischen Zugangsdaten, um eine direkte Verbindung zur Unternehmensdatenbank herzustellen, und erhält so uneingeschränkten Zugriff auf sensible Tabellen sowie die Möglichkeit, wichtige Partnerdaten zu manipulieren.
Szenario 2: Der böswillige Insider und die nicht nachverfolgbare Backdoor im Benutzerpuffer
Das zweite Szenario konzentriert sich auf eine vorsätzliche Insider-Bedrohung: Ein erfahrener ABAP-Entwickler mit den üblichen Entwicklerberechtigungen, der eine versteckte Hintertür einbaut, um massiven Finanzbetrug völlig außerhalb der Reichweite klassischer Sicherheitsprüfungen zu begehen.
Die Architektur eines Angriffs durch Insider zeigt, wie ein funktionaler Entwickler eine versteckte Hintertür in einem Standard-ABAP-Transport nutzt, um die USRBF2 Speicherpuffer manipuliert und dabei die standardmäßigen rollenbasierten Kontrollen vollständig umgeht.
Einbau der Hintertür über legitime ABAP-Transporte
Die kaufmännische Abteilung fordert ein ordnungsgemäßes benutzerdefiniertes Dienstprogramm an, um die Stammdaten nach doppelten Lieferantenkonten und fehlenden Steuernummern zu durchsuchen. Der Entwickler erstellt ein einfaches Programm, das die erforderliche Analyse durchführt, und ordnet es einem benutzerdefinierten Transaktionscode (zVMR) zu. Der Code durchläuft grundlegende Funktionsprüfungen und wird über die Standardlandschaft in das Produktivsystem transportiert.
Tief in der benutzerdefinierten Logik verbirgt sich jedoch ein versteckter Ereignisblock, der nur dann ausgelöst wird, wenn ein ganz bestimmter, undokumentierter Funktionscode in das Befehlszeilenfenster des Systems eingegeben wird.
Code-Schnipsel: Bösartige ABAP-Backdoor über Benutzerbefehl
„Eine strukturelle Abstraktion des Exploits zur Manipulation des versteckten Benutzerpuffers“
Auf Befehl des Benutzers.
CASE sy-ucomm.
WENN „XACCESS“.
„Manipulation des Speichers interner Systempuffer unter Umgehung von Rollenberechtigungen“
INSERT usrbf2 FROM TABLE lt_ins, wobei doppelte Schlüssel zugelassen werden.
ENDCASE.
Umgehung Control rollenbasierten Control Manipulation von USRBF2
Unter normalen Umständen hat der Entwickler keine Berechtigung, auf streng eingeschränkte Transaktionen der Benutzerverwaltung (SU01) oder der Geschäftspartnerverwaltung (BP) zuzugreifen. Um diese Einschränkungen zu umgehen, führt der Insider den benutzerdefinierten Bericht aus und gibt die geheime Befehlszeichenfolge in das Befehlsfeld ein.
Dieser versteckte Code interagiert direkt mit der Tabelle USRBF2, der speziellen Low-Level-Datenbanktabelle, die die aktiven Benutzerberechtigungspuffer im Systemspeicher verwaltet. Die Hintertür fügt direkt einen temporären Eintrag in den lokalen Benutzerpuffer des Entwicklers ein und gewährt ihm damit umfassende Berechtigungen, die denen der Rolle SAP_ALL entsprechen, über den gesamten Anwendungsstack hinweg.
Unauffindbare Betrugsdelikte begehen und die Spuren verwischen
Da diese Rechteausweitung vollständig innerhalb des flüchtigen Speicherpuffers der aktiven Benutzersitzung stattfindet, umgeht diese Änderung herkömmliche Tools zur Sicherheitsprotokollierung vollständig. Verwendet ein Prüfer Standard-Berichtstools wie RSUSR002 oder das Benutzerinformationssystem (SUIM), erscheint das Profil des Entwicklers völlig unverändert und auf grundlegende Entwicklerberechtigungen beschränkt.
Angriffskette:
[Profil eines legitimen Entwicklers] ➔ [Manipulation des Speicherpuffers] ➔ [Vorübergehende Eskalation auf SAP_ALL] ➔ [Ausführung von Kontenbetrug] ➔ [Löschen der Sitzungspuffer]
Sobald die volle Zugriffsberechtigung aktiv ist, initiiert der Entwickler die Geschäftspartner-Transaktion, wählt ein aktives globales Lieferantenprofil aus und aktualisiert die Zahlungsdaten mit seinen eigenen privaten Bankdaten. Bei jeder automatisierten Rechnungsabwicklung werden nun echte Unternehmensgelder direkt auf das Konto des Insiders überwiesen.
Sobald der Betrug abgeschlossen ist, gibt der Insider eine zweite, nicht protokollierte Befehlsfolge ein, die die in den Puffer eingeschleusten Änderungen sofort aus der aktiven Benutzersitzung löscht. Das Entwicklerprofil kehrt innerhalb von Sekunden in seinen eingeschränkten Zustand zurück, ohne Spuren in den Standardkonfigurationsprotokollen zu hinterlassen.
So sichern Sie benutzerdefinierte Logik in BTP- und ABAP-Umgebungen
Das Verlassen auf manuelle Code-Prüfungen oder statische Konfigurationsanalysen reicht nicht aus, um komplexe, moderne IT-Landschaften vor raffinierten Bedrohungen zu schützen. Um strenge Compliance-Vorgaben einzuhalten und eine kontinuierliche Transparenz der Geschäftsabläufe zu gewährleisten, müssen Unternehmen ein automatisiertes Zero-Trust-Qualitätskontrollsystem in ihre Code-Bereitstellungsprozesse integrieren.
Voraussetzungen
- Aktive control das SAP Business Technology Platform und die S/4HANA-Umgebungen.
- Vollständige Automatisierungsintegration über moderne Git-Code-Repositorys und Change-Management-Frameworks hinweg.
- Einführung einer speziellen SAP-Software für Anwendungssicherheitstests zur Gewährleistung einer kontinuierlichen Validierung der Entwicklung.
Schritt-für-Schritt-Anleitung
- Inline-IDE-Analyse implementieren: Integrieren Sie Echtzeit-Code-Scans direkt in Entwicklerumgebungen wie SAP Business Application Studio, Visual Studio Code und Eclipse. Geben Sie Entwicklern sofortiges Feedback im Stil einer Rechtschreibprüfung, damit sie häufige Injektionsfehler und Validierungsprobleme bereits während der Eingabe beheben können.
- Automatisierung der Repository-Validierung: Planen Sie automatisierte Massen-Scans für gemeinsame Git-Repositorys, um sicherzustellen, dass der gesamte vorhandene Code überprüft wird, bevor Abhängigkeiten in die saubere Kernarchitektur integriert werden.
- Durchsetzung von Change-Management-Prüfpunkten: Konfigurieren Sie die automatisierte platform sie als obligatorischer Qualitätsprüfpunkt innerhalb des SAP-Transportmanagementsystems fungiert. Legen Sie Regeln fest, die böswillige Pufferanpassungen oder fehlende Berechtigungsprüfungen kennzeichnen und anfällige Transportaufträge automatisch stoppen, bevor sie in die Produktion gelangen.
- Schaffung einer zentralen Übersicht: Verknüpfen Sie alle Schwachstellen in benutzerdefinierten Anwendungen, Fehler im Repository und Probleme mit der Produktionskonfiguration auf einer einzigen zentralen platform Sicherheitsstandards zu überwachen und über einen längeren Zeitraum hinweg lückenlose Prüfpfade zu gewährleisten.
Überprüfung
Versuchen Sie, einen ABAP-Transportauftrag zu verpacken und zu übertragen, der Änderungen direkt in Speicherpuffertabellen einfügt, oder ein externes BTP-Anwendungsskript, das eine ungeprüfte Dateinamenzeichenfolge enthält. Stellen Sie sicher, dass ein automatisiertes Testtool wie Onapsis Control den Auftrag Control abfängt, die Bereitstellung daran hindert, die Änderungsvalidierungsprüfungen zu passieren, und das Security Operations Center über Ihre SAP-Software zur Erkennung von Bedrohungen mit genauen Kontextinformationen zur Behebung des Problems benachrichtigt.
Häufig gestellte Fragen
Kann die SAP-Clean-Core-Methodik Angriffe auf Code auf Anwendungsebene vollständig verhindern?
Nein, der Clean-Core-Ansatz beseitigt Software-Risiken nicht; er verlagert lediglich benutzerdefinierte Erweiterungen vom lokalen On-Premise-Kern in die cloud von SAP BTP. Wenn Entwickler cloud mit mangelhaften Authentifizierungsverfahren oder Schwachstellen bei Betriebssystembefehlen bereitstellen, können Angreifer diese Integrationen kompromittieren und sich so einen direkten Zugang zu kritischen internen Datenbanken verschaffen.
Wie umgehen böswillige interne Entwickler die üblichen Sicherheitsüberprüfungen control ?
Böswillige Entwickler nutzen ihr technisches Fachwissen, um während der Laufzeit Backdoors direkt in Low-Level-Speichertabellen wie die Benutzerautorisierungspuffertabelle USRBF2 einzuschleusen. Da diese Berechtigungsanpassungen vorübergehend innerhalb von Speicherpuffern und nicht in permanenten Sicherheitsrollen erfolgen, zeigen Standard-Auditprotokolle und herkömmliche Tools zur Rollenüberprüfung keine Änderungen an, sodass die Ausnutzung für menschliche Prüfer nicht nachvollziehbar ist.
Warum erkennen herkömmliche Sicherheitsscanner und Netzwerk-Firewalls Schwachstellen im benutzerdefinierten SAP-Code nicht?
Netzwerk-Firewalls konzentrieren sich stark auf Perimetergrenzen und die Überprüfung auf Paketebene, sodass sie nicht in der Lage sind, die Geschäftslogik zu interpretieren oder zu analysieren, die in benutzerdefinierter ABAP-Syntax oder cloud OData-Integrationen ausgeführt wird. Herkömmlichen Sicherheitsscannern fehlt ein tiefgreifendes, anwendungsspezifisches Verständnis der SAP-Protokolle. Aus diesem Grund benötigen Unternehmen spezialisierte Automatisierungslösungen, um ein echtes SAP-Schwachstellenmanagement zu unterstützen und benutzerdefinierten Code zu bewerten, bevor dieser in die Produktion gelangt.
Über den Autor
