SAP-Entwicklungssystem: Ein kritischer Angriffspunkt

Es gibt keinen Satz, den ich in den letzten 25 Jahren öfter von SAP-Kunden gehört habe als: „Wenn ich meinen Entwicklern nicht vertrauen kann, habe ich sowieso ein Problem!“

Folglich werden Entwicklungssysteme bei der Erstellung von Berechtigungskonzepten für SAP-Projekte stets als Letztes berücksichtigt. Dies ist verständlich, da ein Entwicklungssystem im Vergleich zu einem Produktivsystem hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit offensichtlich weniger kritisch ist. 

Das Problem mit SAP-Entwicklungssystemen

Ein weiterer Grund dafür, Entwicklungssysteme gegenüber Autorisierungsprojekten zurückzustellen, ist, dass die Einschränkung von Berechtigungen in einem solchen System lediglich verhindern kann, dass Benutzer das System versehentlich beschädigen. Es kann jedoch nicht verhindern, dass Angreifer absichtlich böswillige Handlungen vornehmen. 

Der Hauptgrund dafür ist, dass Benutzer auf einem Entwicklungssystem in der Regel über Entwicklerberechtigungen verfügen (welch Überraschung). Das bedeutet:

1. Im Debug-Modus können Benutzer Fehler beheben und (in der Regel) die Werte einzelner Variablen ändern. Auf diese Weise können sie den Rückgabewert jedes AUTHORITY-CHECK-Aufrufs beeinflussen.
2. Sie können beliebige Tabellen im System bearbeiten, indem sie entsprechende ABAP-Anweisungen programmieren und ausführen. 
3. Auch bei 2) stellen implizite Berechtigungsprüfungen, die im SAP-Kernel durchgeführt werden (z. B. für den Dateizugriff), kein Hindernis dar. Eine einfache Möglichkeit, die eigenen Berechtigungen zu erweitern, besteht darin, die Benutzerberechtigungspuffertabelle USRBF2 zu bearbeiten. Bei fehlenden Dateizugriffsberechtigungen gewährt ein einfacher INSERT des folgenden Datensatzes Zugriff auf alle App-Server-Verzeichnisse und alle gemeinsam genutzten Verzeichnisse:

Wenn das Verzeichnis oder die Datei zusätzlich durch einen SPTH-Eintrag geschützt ist, können Angreifer entweder den oder die einschränkenden Datensätze aus der Tabelle SPTH löschen oder, falls der Zugriff für bestimmte Berechtigungsgruppen erlaubt ist, einfach einen zusätzlichen Datensatz zur Tabelle USRBF2 hinzufügen:

SAP-Entwicklungssysteme sind nicht isoliert

Die Möglichkeit, beliebige Elemente auf einem SAP-Entwicklungssystem zu manipulieren, bedeutet, dass Angreifer nur einen Schritt davon entfernt sind, auch das bzw. die entsprechenden Produktivsysteme zu manipulieren. Dazu benötigen sie lediglich die Möglichkeit, die schädlichen Einstellungen auf irgendeine Weise von der Entwicklung in die Produktion zu übertragen und dabei alle etablierten Qualitätskontrollen zu umgehen.

Die drei wichtigsten Schnittstellen zwischen Entwicklungs- und Produktionssystemen sind:

• Benutzerdefinierte RFC-Ziele

Kundendefinierte RFC-Verbindungen zwischen Entwicklungssystemen und QA- oder Produktivsystemen sollten grundsätzlich vermieden werden – auch wenn deren Missbrauch für böswillige Datenübertragungen oder andere Arten der Manipulation durch direkte Aufrufe von remote-fähigen Funktionsbausteinen entsprechende Berechtigungen auf dem Zielsystem für den RFC-Benutzer erfordert. Das Gleiche gilt für die umgekehrte Richtung. RFC-Ziele auf einem Produktivsystem, die dieses mit Entwicklungssystemen (oder QA-Systemen) verbinden, bergen das Risiko böswilliger Rückrufe in die Produktion.

• Das SAP-Transportmanagementsystem (SAP TMS)

Das SAP TMS ist ein unverzichtbarer Bestandteil jeder SAP-Landschaft. Es wird benötigt, um reguläre Entwicklungsobjekte und Customizing-Einstellungen über Transportaufträge aus der Entwicklung in die Produktion zu übertragen. Es nutzt zudem RFC-Destinationen für die systemübergreifende Kommunikation, doch die entsprechenden RFC-Benutzer unterliegen durch vordefinierte Standardrollen erheblichen Einschränkungen.

• In der gesamten Landschaft gemeinsam genutzte Benutzeranmeldedaten

Da SAP-Implementierungen komplex und mehrschichtig sind, werden über die verschiedenen Systeme hinweg zahlreiche Benutzerkonten eingerichtet, von denen viele technische Konten mit weitreichenden Berechtigungen sind. Ein Konto mit weitreichenden Berechtigungen in der Entwicklungsumgebung könnte potenziell auf gehashte Benutzerkennwörter oder sogar auf verschlüsselte Kennwörter für technische Konten zugreifen, die in der Regel in allen Systemen, einschließlich der Produktionsumgebung, mit denselben Anmeldedaten konfiguriert sind. Dies ist eine weitere Möglichkeit, wie Entwickler die gesamte Landschaft durchqueren und von Nicht-Produktionssystemen in Produktionsumgebungen gelangen können.

Risiken des SAP-Transportmanagementsystems

Das Hauptrisiko, das das SAP-Transportmanagementsystem mit sich bringt, besteht nicht darin, dass es über RFC kommuniziert. Das größte Risiko besteht vielmehr darin, dass es von den etablierten Qualitätskontrollen nicht erkannt wird, wenn Entwickler schädliche Objekte oder Einstellungen in einen SAP-Transportauftrag einfügen (z. B. die beiden oben genannten USRBF2-Sätze). Qualitätskontrollen können aus manuellen oder automatisierten Prüfungen bestehen. Das große Änderungsvolumen erfordert in der Regel eine automatisierte Prüfung. Solche automatisierten Prüfungen vergleichen die Objektliste eines Transportauftrags mit einer Liste kritischer Objekte. Das Problem besteht darin, dass die Liste der kritischen Objekte von SAP (entweder mit SAP TMS oder SAP CharM) leer ausgeliefert wird und in der Regel keine Kenntnisse darüber vorliegen, was dort hinzugefügt werden soll. Aber selbst wenn die Liste perfekt gepflegt wäre, gibt es einige konzeptionelle Schwachstellen im SAP TMS.

Konzeptionelle Schwächen im SAP-Transportmanagementsystem

Es gibt einen wesentlichen Mangel in der Architektur des SAP TMS, der ein erhebliches Sicherheitsrisiko darstellt und gleichzeitig bereits für viel Verwirrung in SAP-Projekten gesorgt hat, da Kunden versehentlich darauf stoßen. Das Problem besteht darin, dass SAP nicht auf doppelte Transportaufträge prüft. Beispiel für eine Sicherheitslücke: 

1. Ein Entwickler gibt einen SAP-Transportauftrag DEVK900123 frei, der eine angeforderte und gut dokumentierte Änderung am Kundenbericht ZHARMLESS enthält. Der Bericht wird exportiert und auf Betriebssystemebene in der entsprechenden Datendatei R900123.DEV gespeichert:

2. Die Anforderung DEVK900123 wird in das QA-System übertragen – entweder automatisch oder nach ausdrücklicher Genehmigung durch bestimmte Personen

3. Der Bericht ZHARMLESS wird im QA-System getestet und nach erfolgreichem Test für die Produktion freigegeben. Unabhängig vom Freigabeprozess (TMS-QA, CharM usw.) befindet sich die Anfrage bereits in der Importwarteschlange des/der Produktionssysteme(s).

4. Derselbe Entwickler (oder ein anderer) kann den Status des bereits freigegebenen Transportauftrags im Entwicklungssystem problemlos so ändern, dass er von „Freigegeben“ wieder auf „Bearbeitbar“ zurückgesetzt wird.

5. Anschließend können sie weitere Objekte in die Objektliste der Anfrage einfügen, z. B. den schädlichen Bericht „ZSYSTEMKILL“, und diesen (erneut) freigeben.
 

6. Entsprechend den Namenskonventionen erzeugt der Export erneut die Datei „R900123.DEV“ und überschreibt damit einfach die bereits vorhandene Datei.

7. Ein Administrator startet den Import des Transportauftrags in das/die Produktivsystem(e) (da dieser bereits genehmigt wurde – siehe Beispiel 3), ohne zu wissen, dass er inzwischen einen zusätzlichen schädlichen Bericht enthält.

Es ist von entscheidender Bedeutung, über eine Lösung zu verfügen, die nicht nur die Produktionssysteme vor einer Kompromittierung durch die Änderung von Transportaufträgen schützt, sondern auch verhindert, dass SAP-Kunden versehentlich doppelte Transportaufträge erhalten. Jede Wiederherstellung und jede Aktualisierung eines Entwicklungssystems (was in parallelen Entwicklungslandschaften eine regelmäßige Aufgabe ist) erfordert besondere Aufmerksamkeit hinsichtlich des Nummernkreises der Transportaufträge. Nach einer Systemwiederherstellung/Aktualisierung können bereits freigegebene SAP-Transportaufträge wieder den Status „änderbar“ haben oder gar nicht mehr existieren, sodass beim Anlegen neuer Transportaufträge dieselben Transportnummern erneut generiert werden und ihnen völlig andere Objekte zugeordnet werden können als ihren bereits exportierten Pendants:

Doppelte Transportaufträge sorgen in solchen Fällen stets für große Verwirrung. Objektlisten stimmen nicht mehr mit den Informationen überein, die möglicherweise bereits in Änderungsbelegen erfasst wurden, oder Objekte werden aufgrund des Genehmigungsstatus des ursprünglichen Transportauftrags ungeprüft in die Produktion übernommen usw.

Um Inkonsistenzen zu vermeiden, muss die höchste Nummer, die einem Transportauftrag zugewiesen wurde, gespeichert und erneut angewendet werden, bevor ein wiederhergestelltes/aktualisiertes System wieder für die Entwicklung freigegeben werden kann. Dazu sind zwei Schritte erforderlich:

1. Vor der Wiederherstellung/Aktualisierung: Notieren Sie den aktuellen Wert des Feldes E070L-TRKORR
2. Nach der Wiederherstellung/Aktualisierung: Aktualisieren Sie die Tabelle E070L so, dass der in 1 erfasste Wert wieder der Spalte E070L-TRKORR zugewiesen wird.

Wenn vor und nach der Wiederherstellung/Aktualisierung ein Tool oder Skript zum Exportieren und erneuten Importieren einiger Tabellen verwendet wird, fügen Sie einfach die Tabelle E070L zur Liste der zu verarbeitenden Tabellen hinzu.

Weitere Quellen für böswillige Manipulationen über SAP TMS

Im Jahr 2018 meldeten die Onapsis Research Labs ORL) SAP eine Sicherheitslücke, die es Angreifern ermöglichte, die Definition logischer Customizing-Objekte zu manipulieren, wodurch sie bösartige Einstellungen völlig verborgen (nicht sichtbar in der Objektliste des Transportauftrags) transportieren konnten. Der entsprechende SAP-Sicherheitshinweis Nr . 2671160 ist mit einem CVSS-Score von 5,5 versehen, und Onapsis Research Labs zeigen, dass durch Ausnutzung dieser Schwachstelle auch beliebige Workbench-Objekte in die Produktion eingeschleust werden können. Dies kann zu einem kritischen Problem werden, und die Ausnutzung dieser Schwachstelle ist sehr schwer zu erkennen. SAP hat den neuen TMS-Parameter TLOGOCHECK eingeführt, um das Problem zu beheben, und die neuesten Releases von SAP S/4HANA werden mit TLOGOCHECK=TRUE ausgeliefert, was die neue „Security by Default“-Philosophie von SAP verdeutlicht.

Zwar kann die zuvor beschriebene SAP-Sicherheitslücke als vollständig behoben und gepatcht angesehen werden, doch bestehen weiterhin zwei weitere Risiken. Beide stehen im Zusammenhang mit dem Funktionsbaustein TRINT_TP_INTERFACE, der das Herzstück des SAP TMS bildet. Über diesen Funktionsbaustein lassen sich die meisten Transportaktivitäten starten. Glücklicherweise ist dieser Funktionsbaustein nicht für den Fernzugriff freigegeben. Dennoch stellt er für lokale Angreifer eine Möglichkeit dar, Transportaufträge zu manipulieren.

Während bei regulären Exporten von SAP-Transportaufträgen über die Transaktionen SE01, SE09 oder SE10 eine Reihe von Konsistenzprüfungen vor dem Export durchgeführt wird, können diese Prüfungen umgangen werden, wenn der Export über TRINT_TP_INTERFACE gestartet wird. Dies ist äußerst kritisch, da Angreifer Tabellen exportieren können, die normalerweise nicht für Transporte zugelassen sind, da sie die Konsistenz und Integrität eines Zielsystems beeinträchtigen können. Noch kritischer ist die Tatsache, dass die Konsistenzprüfung für Customizing-Objekte wie View-Daten und View-Cluster-Daten umgangen werden kann. Dies ermöglicht es Angreifern, diese Customizing-Objekte als Container für den Transport bösartiger Einstellungen zu nutzen, ähnlich wie bei der Schwachstelle in logischen Customizing-Objekten, die mit dem SAP-Sicherheitshinweis Nr . 2671160 behoben wurde. 

Fazit

Unternehmen müssen zusätzliche Sicherheitsmaßnahmen ergreifen, um ein SAP-Entwicklungssystem umfassend vor Angreifern zu schützen, insbesondere vor solchen, die bereits über Zugriffsrechte verfügen. Umso wichtiger ist es, dass alle Schnittstellen zu QA- und Produktionssystemen so gut wie möglich gesichert werden. Ohne angemessenen Schutz stellt das SAP-Transportmanagement-System ein erhebliches Risiko dar, da es für die Migration von Tausenden neuer und aktualisierter Objekte sowie von Anpassungs-Einstellungen in Produktionssysteme zuständig ist. 

Onapsis Control automatisiert die Überwachung aller Änderungen, die das Entwicklungssystem verlassen, und bietet zusätzliche Genehmigungsworkflows für kritische Situationen. Control ideal für Unternehmen, die SAP-Transporte vor der Produktivschaltung auf Fehler überprüfen möchten, und bietet Prüfungen, die auch Aspekte der Robustheit, Compliance und Wartbarkeit abdecken.