{"id":166670,"date":"2026-10-01T10:00:00","date_gmt":"2026-10-01T08:00:00","guid":{"rendered":"https:\/\/e3mag.com\/?p=166670"},"modified":"2026-09-28T10:45:19","modified_gmt":"2026-09-28T08:45:19","slug":"schluss-mit-dem-freifahrtschein-ins-betriebssystem-angriffe-auf-sap-umgebungen-erkennen-und-eindaemmen","status":"publish","type":"post","link":"https:\/\/e3mag.com\/de\/schluss-mit-dem-freifahrtschein-ins-betriebssystem-angriffe-auf-sap-umgebungen-erkennen-und-eindaemmen\/","title":{"rendered":"Schluss mit dem Freifahrtschein ins Betriebssystem: Angriffe auf SAP-Umgebungen erkennen und eind\u00e4mmen"},"content":{"rendered":"\n

SAP-Anwendungen existieren nicht isoliert f\u00fcr sich, sondern sind eng mit dem darunter liegenden Betriebssystem verbunden. Unabh\u00e4ngig davon, ob es um das Schreiben von Logfiles, die Verarbeitung von eingegebenen Daten, das Ausf\u00fchren von Hintergrund-Jobs oder Health Checks geht \u2013 immer wird Zugriff auf die Ressourcen des Betriebssystems ben\u00f6tigt, um Systemfunktionen aufzurufen oder Operationen im Dateisystem durchzuf\u00fchren.<\/p>\n\n\n\n

Alle von SAP auf Betriebssystem-Ebene angesto\u00dfenen Prozesse werden dort von einem dedizierten Betriebssystem-Nutzer gestartet, der auf Linux-Systemen nach dem SAP System Identifier benannt ist und beispielsweise adm hei\u00dfwt. Das Betriebssystem kennt weder die Business-Prozesse aus der SAP-Ebene noch die dortigen Benutzer, Rollen, Transaktionen und Autorisierungen. Umgekehrt wei\u00df SAP nicht, welche Funktionen im Betriebssystem ausgef\u00fchrt wurden oder welche Zugriffe es gab \u2013 die SAP-Anwendungen stellen lediglich eine Anfrage und erhalten ein Ergebnis zur\u00fcck. Die Sichtbarkeit zwischen den beiden Ebenen ist somit relativ eingeschr\u00e4nkt, der Austausch basiert auf gegenseitigem Vertrauen.<\/p>

\"\"<\/a><\/div><\/div>\n\n\n\n

Zwischen dem ABAP-Code der SAP-Anwendungen und dem Betriebssystem sitzt als Mittler der SAP-Kernel, der sich um Prozesserstellung, Speicherverwaltung, Netzwerkkommunikation, Zugriffe auf das Dateisystem und die Ausf\u00fchrung von Betriebssystem-Befehlen k\u00fcmmert. Er validiert die Anfragen der Anwendungen und nutzt den Betriebssystem-Nutzer von SAP, um Befehle oder Dateizugriffe auszuf\u00fchren. In den meisten F\u00e4llen ist genau definiert, welche Befehle und Zugriffsm\u00f6glichkeiten das sind. ABAP-Anwendungen rufen sie mittels standardisierter Funktionsmodule auf \u2013 der Kernel l\u00f6st diese auf, validiert die Autorisierungen, organisiert die Parameter und f\u00fchrt sie schlie\u00dflich aus.<\/p>\n\n\n\n

Es gibt allerdings aus der Vergangenheit noch die M\u00f6glichkeit, dass ABAP-Anwendungen die konkreten Betriebssystem-Befehle \u00fcber Statements wie CALL \u2018SYSTEM\u2018 oder CALL \u2018CFUNC\u2018 direkt an den Kernel \u00fcbermitteln. Davon wird dringend abgeraten und in modernen Umgebungen wird diese Option zunehmend eingeschr\u00e4nkt, doch in Legacy-Code ist sie nach wie vor h\u00e4ufig zu finden. Zudem k\u00f6nnen nat\u00fcrlich auch Kernel-Komponenten selbst Befehlsaufrufe initiieren, um beispielsweise Instanzen zu steuern, Checks des Systemstatus durchzuf\u00fchren oder Ressourcen zu \u00fcberwachen. Am grundlegenden Prinzip, dass der Kernel die Befehle \u00fcber den Betriebssystem-Nutzer von SAP ausf\u00fchrt, \u00e4ndert das aber nichts.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Dateizugriffe mit hohem Gefahrenpotenzial<\/h2>\n\n\n\n

Gelingt es Angreifern, Schwachstellen oder Fehlkonfigurationen in der SAP-Ebene auszunutzen oder gestohlene Zugangsdaten zu missbrauchen, k\u00f6nnen sie \u00fcber den Betriebssystem-Nutzer mit der Betriebssystem-Ebene interagieren. Die konkreten Auswirkungen h\u00e4ngen von der jeweiligen SAP-Landschaft, der Betriebssystem-Konfiguration und der umgebenden Infrastruktur ab. Allein der Zugriff auf das Dateisystem bietet ihnen aber schon viel Raum f\u00fcr Aktivit\u00e4ten: Sie k\u00f6nnen unter anderem Konfigurationsdateien, Verbindungsparameter, Schnittstellendefinitionen und Zertifikate auslesen, Skripte ver\u00e4ndern oder sogar austauschen.<\/p>\n\n\n\n

Angreifer sind damit in der Lage, das System auszuspionieren, zu manipulieren und sich dauerhafte Zugriffsm\u00f6glichkeiten zu sichern \u2013 f\u00fcr den Fall, dass Passw\u00f6rter ge\u00e4ndert oder Schwachstellen gepatcht werden. Daf\u00fcr kann es ausreichen, Startup-Skripte, Cronjobs und andere Elemente anzupassen oder zu ersetzen, die zu bestimmten Zeiten oder bei bestimmten Ereignissen automatisch ausgef\u00fchrt werden. Oft richten Angreifer dar\u00fcber hinaus Hintert\u00fcren, gesch\u00fctzte Kommunikationswege und Hacking-Tools f\u00fcr ihre k\u00fcnftigen Aktivit\u00e4ten ein. Damit diese nicht auffallen, ver\u00e4ndern sie Logfiles, l\u00f6schen forensische Spuren oder st\u00f6ren das Monitoring.<\/p>\n\n\n\n

Unabh\u00e4ngig davon kann das kompromittierte SAP-System auch als Sprungbrett zu anderen Systemen innerhalb der SAP-Umgebung dienen, etwa zu Datenbank- und File-Servern, Backup-Systemen oder Monitoring-Plattformen.<\/p>\n\n\n\n

<\/div>\n\n\n\n

M\u00f6gliche Angriffsszenarien in der Praxis<\/h2>\n\n\n\n

Verschiedene Angriffsszenarien, die Experten von Fortinet, No Monkey, PwC und Red Hat im Rahmen eines Ironroot genannten Projekts demonstrieren konnten, basieren auf dem Missbrauch verschiedener SAP-Transaktionen. AL11 etwa erlaubt es Administratoren, \u00fcber die SAP-Oberfl\u00e4che auf vordefinierte Verzeichnisse zuzugreifen. Werden in der Verzeichnisliste neue Eintr\u00e4ge erg\u00e4nzt, lassen sich die dort liegenden Dateien direkt aus SAP heraus \u00f6ffnen \u2013 ohne Shell-Zugang zum Server. Abh\u00e4ngig von den Berechtigungen des SAP-Nutzers auf dem Host-System besteht damit Zugriff auf sensible Informationen wie Konfigurationen, Logs, Credentials und Anwendungsdaten, die Angreifern bei der Planung und Durchf\u00fchrung weiterer Aktivit\u00e4ten helfen.<\/p>\n\n\n\n

\u00dcber die nativen Funktionen von ABAP f\u00fcr das File-Handling und die Transaktion SE38 lassen sich dar\u00fcber hinaus Dateien auf dem System bearbeiten und erstellen. In einer Demonstration wurde auf diese Weise ein Report erzeugt, der im Dateisystem eine harmlose Datei anlegte. Angreifer k\u00f6nnten in einem solchen Szenario beispielsweise Konfigurationen und Skripte ver\u00e4ndern oder neu erstellen. Handelt es sich um Elemente, die das Betriebssystem zu bestimmten Zeiten oder Anl\u00e4ssen selbst startet, ben\u00f6tigen sie nicht einmal die Berechtigungen zum Ausf\u00fchren von Dateien und Code, um gr\u00f6\u00dfere Sch\u00e4den anzurichten.<\/p>\n\n\n\n

Allerdings k\u00f6nnen sich Angreifer diese Rechte durchaus erschleichen. Eine M\u00f6glichkeit ist es, die Transaktion SM69 auszunutzen, um eigene Befehle zu definieren, die sich anschlie\u00dfend \u00fcber die Transaktion SM49 von der SAP-Oberfl\u00e4che aus aufrufen lassen. SAP \u00f6ffnet eine Shell, die den Befehl \u2013 etwa das Starten eines Skripts \u2013 auf Betriebssystem-Ebene ausf\u00fchrt. In der Demonstration der Experten handelte es sich lediglich um eine harmlose \u201eHello from the OS\u201c-Nachricht, die direkt an die SAP-Ebene zur\u00fcckgespielt wurde. Im Angriffsfall k\u00f6nnen es gef\u00e4hrliche Binaries, Skripte oder Systemtools sein.<\/p>\n\n\n\n

Neben SM49 und SM69 enth\u00e4lt SAP auch Funktionen, die eine direkte Interaktion mit der Betriebssystem-Shell erm\u00f6glichen, darunter den ABAP-Report RSBDCOS0, der Betriebssystem-Befehle ausf\u00fchrt und die daraus resultierenden Ausgaben innerhalb der SAP-Oberfl\u00e4che anzeigt. In ihren Demonstrationen nutzten die Experten den Report und zun\u00e4chst einfache Befehle wie whoami, um zu ermitteln, ob Befehle als SAP-Betriebssystem-Nutzer ausgef\u00fchrt werden. Anschlie\u00dfend wurde mit Netcat eine Reverse-Shell initiiert und eine ausgehende Verbindung zu einem externen System aufgebaut. \u00dcber ein solches k\u00f6nnten sich Angreifer einen kontinuierlichen Zugriff auf das Betriebssystem sichern und Dateien durchsuchen und anlegen, beliebige Befehle ausf\u00fchren und sich dauerhaft einnisten. Im Grunde haben sie dieselben M\u00f6glichkeiten wie ein lokal angemeldeter Nutzer, was die Natur der Kompromittierung im Vergleich zu den zuvor beschriebenen Angriffsszenarien \u00fcber SAP-Transaktionen deutlich ver\u00e4ndert. Die SAP-Anwendung dient hier nur noch als initialer Angriffsvektor.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Mehrstufige Sicherheit wird Pflicht<\/h2>\n\n\n\n

Um Angriffe und eine Kompromittierung von Systemen zu verhindern, ergreifen Unternehmen in der Regel eine ganze Reihe von Ma\u00dfnahmen: Sie h\u00e4rten Betriebssysteme, installieren Sicherheitsl\u00f6sungen, dichten Schwachstellen ab, segmentieren Netzwerke, f\u00fchren sichere Praktiken in der Software-Entwicklung ein und implementieren ein kontinuierliches Monitoring. In komplexen und sich stetig weiterentwickelnden Enterprise-Umgebungen, die von Angreifern zunehmend auch mit KI-Unterst\u00fctzung attackiert werden, reichen solche pr\u00e4ventiven Ma\u00dfnahmen allerdings nicht mehr aus. Schwachstellen, Fehlkonfigurationen und andere Angriffspunkte lassen sich mit KI schneller denn je finden und ausnutzen, weshalb es mehrstufige Sicherheitskonzepte braucht, um die Angriffsfl\u00e4che zu verkleinern und den Handlungsspielraum von Eindringlingen einzuschr\u00e4nken.<\/p>\n\n\n\n

\"\"
Discretionary Access Control (DAC), SELinux und fapolicyd erg\u00e4nzen sich und verhindern, dass kompromittierte Accounts oder Schwachstellen auf SAP-Ebene f\u00fcr weitreichende Aktionen auf Betriebssystem-Ebene missbraucht werden k\u00f6nnen. (Quelle: Red Hat)<\/em><\/figcaption><\/figure>\n\n\n\n

Dieser auch Defense in Depth genannte Ansatz fu\u00dft darauf, dass mehrere Sicherheitsmechanismen ineinandergreifen, damit \u2013 wenn einer \u00fcberwunden wird \u2013 weitere bereitstehen und Angreifer aufhalten oder zumindest ausbremsen. Gerade in SAP-Umgebungen ist das aufgrund der Vertrauensbeziehung zwischen SAP- und Betriebssystem-Ebene wichtig, denn schafft es ein Angreifer, \u00fcber den SAP-Stack Betriebssystem-Befehle auszuf\u00fchren oder Operationen im Dateisystem durchzuf\u00fchren, sind die pr\u00e4ventiven Schutzmechanismen bereits \u00fcberwunden. Zu diesem Zeitpunkt l\u00e4uft der Angriff und kann nicht mehr verhindert, sondern nur noch einged\u00e4mmt werden.<\/p>\n\n\n\n

Im Ironroot-Projekt haben die Experten von Fortinet, No Monkey, PwC und Red Hat daher Ma\u00dfnahmen entwickelt, die M\u00f6glichkeiten von Angreifern auf Betriebssystem-Ebene zu beschneiden und das Ausspionieren und Infiltrieren weiterer Systeme zu erschweren. Die konkreten Ziele sind:<\/p>\n\n\n\n