Schluss mit dem Freifahrtschein ins Betriebssystem: Angriffe auf SAP-Umgebungen erkennen und eindämmen

SAP-Anwendungen existieren nicht isoliert für sich, sondern sind eng mit dem darunter liegenden Betriebssystem verbunden. Unabhängig davon, ob es um das Schreiben von Logfiles, die Verarbeitung von eingegebenen Daten, das Ausführen von Hintergrund-Jobs oder Health Checks geht – immer wird Zugriff auf die Ressourcen des Betriebssystems benötigt, um Systemfunktionen aufzurufen oder Operationen im Dateisystem durchzuführen.

Alle von SAP auf Betriebssystem-Ebene angestoßenen Prozesse werden dort von einem dedizierten Betriebssystem-Nutzer gestartet, der auf Linux-Systemen nach dem SAP System Identifier benannt ist und beispielsweise adm heißwt. Das Betriebssystem kennt weder die Business-Prozesse aus der SAP-Ebene noch die dortigen Benutzer, Rollen, Transaktionen und Autorisierungen. Umgekehrt weiß SAP nicht, welche Funktionen im Betriebssystem ausgeführt wurden oder welche Zugriffe es gab – die SAP-Anwendungen stellen lediglich eine Anfrage und erhalten ein Ergebnis zurück. Die Sichtbarkeit zwischen den beiden Ebenen ist somit relativ eingeschränkt, der Austausch basiert auf gegenseitigem Vertrauen.

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ührung von Betriebssystem-Befehlen kümmert. Er validiert die Anfragen der Anwendungen und nutzt den Betriebssystem-Nutzer von SAP, um Befehle oder Dateizugriffe auszuführen. In den meisten Fällen ist genau definiert, welche Befehle und Zugriffsmöglichkeiten das sind. ABAP-Anwendungen rufen sie mittels standardisierter Funktionsmodule auf – der Kernel löst diese auf, validiert die Autorisierungen, organisiert die Parameter und führt sie schließlich aus.

Es gibt allerdings aus der Vergangenheit noch die Möglichkeit, dass ABAP-Anwendungen die konkreten Betriebssystem-Befehle über Statements wie CALL ‘SYSTEM‘ oder CALL ‘CFUNC‘ direkt an den Kernel übermitteln. Davon wird dringend abgeraten und in modernen Umgebungen wird diese Option zunehmend eingeschränkt, doch in Legacy-Code ist sie nach wie vor häufig zu finden. Zudem können natürlich auch Kernel-Komponenten selbst Befehlsaufrufe initiieren, um beispielsweise Instanzen zu steuern, Checks des Systemstatus durchzuführen oder Ressourcen zu überwachen. Am grundlegenden Prinzip, dass der Kernel die Befehle über den Betriebssystem-Nutzer von SAP ausführt, ändert das aber nichts.

Dateizugriffe mit hohem Gefahrenpotenzial

Gelingt es Angreifern, Schwachstellen oder Fehlkonfigurationen in der SAP-Ebene auszunutzen oder gestohlene Zugangsdaten zu missbrauchen, können sie über den Betriebssystem-Nutzer mit der Betriebssystem-Ebene interagieren. Die konkreten Auswirkungen hängen 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ür Aktivitäten: Sie können unter anderem Konfigurationsdateien, Verbindungsparameter, Schnittstellendefinitionen und Zertifikate auslesen, Skripte verändern oder sogar austauschen.

Angreifer sind damit in der Lage, das System auszuspionieren, zu manipulieren und sich dauerhafte Zugriffsmöglichkeiten zu sichern – für den Fall, dass Passwörter geändert oder Schwachstellen gepatcht werden. Dafür kann es ausreichen, Startup-Skripte, Cronjobs und andere Elemente anzupassen oder zu ersetzen, die zu bestimmten Zeiten oder bei bestimmten Ereignissen automatisch ausgeführt werden. Oft richten Angreifer darüber hinaus Hintertüren, geschützte Kommunikationswege und Hacking-Tools für ihre künftigen Aktivitäten ein. Damit diese nicht auffallen, verändern sie Logfiles, löschen forensische Spuren oder stören das Monitoring.

Unabhängig 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.

Mögliche Angriffsszenarien in der Praxis

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, über die SAP-Oberfläche auf vordefinierte Verzeichnisse zuzugreifen. Werden in der Verzeichnisliste neue Einträge ergänzt, lassen sich die dort liegenden Dateien direkt aus SAP heraus öffnen – ohne Shell-Zugang zum Server. Abhängig 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ührung weiterer Aktivitäten helfen.

Über die nativen Funktionen von ABAP für das File-Handling und die Transaktion SE38 lassen sich darüber 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önnten in einem solchen Szenario beispielsweise Konfigurationen und Skripte verändern oder neu erstellen. Handelt es sich um Elemente, die das Betriebssystem zu bestimmten Zeiten oder Anlässen selbst startet, benötigen sie nicht einmal die Berechtigungen zum Ausführen von Dateien und Code, um größere Schäden anzurichten.

Allerdings können sich Angreifer diese Rechte durchaus erschleichen. Eine Möglichkeit ist es, die Transaktion SM69 auszunutzen, um eigene Befehle zu definieren, die sich anschließend über die Transaktion SM49 von der SAP-Oberfläche aus aufrufen lassen. SAP öffnet eine Shell, die den Befehl – etwa das Starten eines Skripts – auf Betriebssystem-Ebene ausführt. In der Demonstration der Experten handelte es sich lediglich um eine harmlose „Hello from the OS“-Nachricht, die direkt an die SAP-Ebene zurückgespielt wurde. Im Angriffsfall können es gefährliche Binaries, Skripte oder Systemtools sein.

Neben SM49 und SM69 enthält SAP auch Funktionen, die eine direkte Interaktion mit der Betriebssystem-Shell ermöglichen, darunter den ABAP-Report RSBDCOS0, der Betriebssystem-Befehle ausführt und die daraus resultierenden Ausgaben innerhalb der SAP-Oberfläche anzeigt. In ihren Demonstrationen nutzten die Experten den Report und zunächst einfache Befehle wie whoami, um zu ermitteln, ob Befehle als SAP-Betriebssystem-Nutzer ausgeführt werden. Anschließend wurde mit Netcat eine Reverse-Shell initiiert und eine ausgehende Verbindung zu einem externen System aufgebaut. Über ein solches könnten sich Angreifer einen kontinuierlichen Zugriff auf das Betriebssystem sichern und Dateien durchsuchen und anlegen, beliebige Befehle ausführen und sich dauerhaft einnisten. Im Grunde haben sie dieselben Möglichkeiten wie ein lokal angemeldeter Nutzer, was die Natur der Kompromittierung im Vergleich zu den zuvor beschriebenen Angriffsszenarien über SAP-Transaktionen deutlich verändert. Die SAP-Anwendung dient hier nur noch als initialer Angriffsvektor.

Mehrstufige Sicherheit wird Pflicht

Um Angriffe und eine Kompromittierung von Systemen zu verhindern, ergreifen Unternehmen in der Regel eine ganze Reihe von Maßnahmen: Sie härten Betriebssysteme, installieren Sicherheitslösungen, dichten Schwachstellen ab, segmentieren Netzwerke, führen 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ützung attackiert werden, reichen solche präventiven Maßnahmen 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äche zu verkleinern und den Handlungsspielraum von Eindringlingen einzuschränken.

Dieser auch Defense in Depth genannte Ansatz fußt darauf, dass mehrere Sicherheitsmechanismen ineinandergreifen, damit – wenn einer überwunden wird – 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, über den SAP-Stack Betriebssystem-Befehle auszuführen oder Operationen im Dateisystem durchzuführen, sind die präventiven Schutzmechanismen bereits überwunden. Zu diesem Zeitpunkt läuft der Angriff und kann nicht mehr verhindert, sondern nur noch eingedämmt werden.

Im Ironroot-Projekt haben die Experten von Fortinet, No Monkey, PwC und Red Hat daher Maßnahmen entwickelt, die Möglichkeiten von Angreifern auf Betriebssystem-Ebene zu beschneiden und das Ausspionieren und Infiltrieren weiterer Systeme zu erschweren. Die konkreten Ziele sind:

• den Zugriff auf das Dateisystem zu begrenzen. Ein kompromittiertes SAP-Konto darf lediglich einen Zugriff auf Verzeichnisse und Dateien erlauben, die für den normalen SAP-Betrieb notwendig sind. Der Zugriff auf dafür nicht relevante Betriebssystem-Ressourcen, sensible Credentials und administrative Dateien soll so weit wie möglich unterbunden werden.
• die Ausführung von Prozessen einzuschränken. Da Angreifer häufig eigene Tools, Skripte und Binaries ausführen, nachdem sie sich Zugriff auf ein System verschafft haben, sollen diese Möglichkeiten beschnitten werden, um zu verhindern, dass sie bösartigen Code ausführen, sich dauerhaft einnisten oder weitere Systeme auszukundschaften.
• Rechteausweitungen und laterale Bewegungen zu erschweren. Wird der Zugriff auf gemeinsam genutzte Ressourcen, Verwaltungstools und vertrauenswürdige Kommunikationswege limitiert, können Angreifer nicht mehr so leicht über das ursprünglich kompromittierte System hinaus vordringen.
• die Eindämmung zu verbessern. Selbst wenn es Angreifern gelingt, das Betriebssystem-Konto von SAP zu kompromittieren, sollen die sich daraus ergebenden Handlungsmöglichkeiten auf einen eng definierten Bereich beschränkt bleiben.

Eine Kombination aus Discretionary Access Control (DAC), der Linux-Kernel-Erweiterung SELinux und dem Framework fapolicyd (File Access Policy Daemon) kann als zusätzlicher Security-Layer auf Betriebssystem-Ebene dienen und helfen, diese Ziele zu erreichen.

Granulare Steuerung von Zugriffen

Werden Discretionary Access Controls sorgfältig nach dem Least-Privilege-Prinzip vergeben, bieten sie einen guten Grundschutz, weil Benutzer und Gruppen nur auf die Verzeichnisse und Dateien zugreifen können, die sie tatsächlich für ihre Arbeit benötigen. In SAP-Umgebungen sollten Administratoren bei der Rechtevergabe ein besonderes Augenmerk auf verteilte Dateisysteme, Transportverzeichnisse, Backup-Speicher, Integrationsskripte und Admin-Tools haben. Agiert ein Angreifer allerdings im Security-Kontext eines vertrauenswürdigen Accounts, sieht das Betriebssystem sämtliche seiner Aktionen als legitim an. Hier kommen SELinux und fapolicyd ins Spiel.

SELinux ergänzt Linux um eine Mandatory Access Control (MAC), bei der Zugriffe nicht basierend auf der Identität des Benutzers und dem Objekt, auf das er zugreifen möchte, genehmigt oder abgelehnt werden, sondern auf Basis zentral definierter Richtlinien. Dieser Ansatz erlaubt eine granulare Steuerung, denn mit den Richtlinien lässt sich genau festlegen, auf welche Dateien ein Prozess zugreifen, welche Netzwerkverbindungen er aufbauen, welche Ressourcen er ändern und welche Interaktionen zwischen Systemkomponenten er anstoßen darf. Selbst wenn ein Angreifer die Kontrolle über einen SAP-Prozess oder ein Betriebssystem-Konto übernimmt, erhält er keine Zugriffsberechtigungen auf Ressourcen, die über die in den Richtlinien definierten hinausgehen. Jeder Versuch wird vom Kernel blockiert und in Form eines „avc: denied“-Eintrags unter /var/log/audit/audit.log oder /var/log/messages vermerkt. Diese Protokolle lassen sich bei Bedarf in SIEM-Systeme einbinden und zentral auswerten, sodass laufende Angriffe zuverlässig erkannt werden.

Über fapolicyd wiederum kann gesteuert werden, welche ausführbaren Objekte tatsächlich ausgeführt werden dürfen – Linux selbst bietet hier relativ wenige Einschränkungen, wenn ein Angreifer erst einmal einen Account mit ausreichend Berechtigungen übernommen hat. Statt einer simplen Whitelist nutzt fapolicyd Informationen zur Integrität und Vertrauenswürdigkeit von Dateien, Metadaten aus dem Paketmanagement und vom Administrator definierten Richtlinien. So lässt sich festlegen, dass Binaries aus genehmigten Repositories, vertrauenswürdige SAP-Software und explizit freigegebene Anwendungen ausgeführt werden dürfen. Ausführbare Dateien aus unbekannten oder zweifelhaften Quellen hingegen werden blockiert, sodass Angreifer keine hochgeladenen Skripte, Tunneling-Tools und andere Hacking-Werkzeuge starten können.

Fertige Richtlinienpakete für schnellen Schutz

SELinux und fapolicyd sind Bestandteil vieler Linux-Distributionen, darunter auch Red Hat Enterprise Linux. Andere Distributionen bringen teilweise ähnliche Module und Funktionen mit, etwa AppArmor, oder können nachträglich damit ausgerüstet werden.

Für einen zuverlässigen Schutz in SAP-Umgebungen müssen SELinux und fapolicyd angepasst werden. Im Rahmen von Ironroot wurde ein Richtlinienpaket für Red Hat Enterprise Linux entwickelt, das installiert werden kann, nachdem die bestehenden Richtlinien und Ressourcen-Labels entfernt wurden. Das Paket definiert dann neue Labels und verbessert die Richtlinien für den Zugriff darauf, damit beispielsweise:

• der ABAP-Administrator nicht mehr per sudo zu root-Rechten wechseln kann, was Angreifer oft für die Ausbreitung innerhalb der Infrastruktur missbrauchen.
• der SAP-Administrator keinen Reserved Port mehr nutzen kann, was Angreifer oft für den Export von vertraulichen Daten missbrauchen.
• der HANA-Datenbankadministrator keine temporären Dateien des ABAP-Administrators mehr verändern kann, was Angreifer oft missbrauchen, um schädliche Befehle einzufügen.

Unternehmen können natürlich auch eigene Labels und Richtlinien für SELinux und fapolicyd definieren.

Wichtig ist es, DAC, SELinux und fapolicyd als mehrschichtigen Schutz zu verstehen, der erst im Zusammenspiel seiner Einzelkomponenten seine volle Wirkung entfaltet, weil Angreifer mehrere Sicherheitsmechanismen überwinden müssen, um auf sensible Daten zuzugreifen, eigenen Code auszuführen oder weitere Systeme zu infiltrieren. DAC legt fest, welche Benutzer und Gruppen auf bestimmte Ressourcen zugreifen dürfen. SELinux ergänzt Regeln, die das Verhalten von Prozessen einschränken, selbst wenn die normalen Dateizugriffsberechtigungen die Aktivitäten gestatten würden. Und fapolicyd schließlich regelt grundlegend, welche Software auf dem System überhaupt ausgeführt werden darf.

Zum Partnereintrag: