Gefahren im SAP®-Transportmanagement – Teil 4
Willkommen zurück zu unserer Blogreihe über die Gefahren im SAP®-Transportmanagement. In diesem vierten Teil konzentrieren wir uns auf die automatisierte Codeausführung beim Import. In Teil eins haben wir einen Überblick über das SAP-Transportmanagement gegeben. In Teil zwei haben wir uns mit dem Ausgangspunkt dieses Angriffs, der Transaktion SU24, befasst, und in Teil drei haben wir einen Blick auf die Manipulation der Jobverwaltung und die damit verbundenen Risiken für SAP-Transporte geworfen.
Nearly every SAP® Basis administrator knows how dangerous XPRA entries can be in transport requests (R3TR XPRA <report name>). In principle, any report that does not require any mandatory parameters can be executed, triggered by importing a transport request. If a report is not already on the target system, it can either be imported with the same request or imported with a previous transport request. The latter method is better for covering up attacks as the immediate connection between planting the code and executing it is not as easy to detect.
After-Import-Methoden sind wesentlich gefährlicher. Dies liegt daran, dass das Einfügen und Ausführen des Codes fast unbemerkt erfolgt. After-Import-Methoden werden von SAP für Nachbearbeitungsvorgänge nach dem Import von Customizing-Objekten verwendet, beispielsweise zur Generierung von Objekten auf der Grundlage neuer oder geänderter Einstellungen oder zur Durchführung von Konsistenzprüfungen (z. B. beim Import von Nummernkreisobjekten). Ein Angriff über die After-Import-Methode umfasst drei Schritte:
Schritt 1: Einbinden des Code-
s Da während der After-Import-Methode auf einen Funktionsbaustein zugegriffen wird, muss dieser zunächst in das Zielsystem übertragen werden. Dies lässt sich relativ einfach bewerkstelligen, indem man den Funktionsbaustein innerhalb einer vollständigen, möglicherweise sehr umfangreichen Funktionsgruppe transportiert.
Schritt 2: Zuordnung der Code-
-Anpassungsobjekte werden in der Transaktion SOBJ definiert. In dieser Transaktion kann jedem Pflegeobjekt ein Funktionsbaustein als After-Import-Methode zugewiesen werden. Änderungen werden automatisch im entsprechenden R3TR-TOBJ-Objekt dokumentiert.
TOBJ-Objekte fallen nicht besonders auf, da sie in der Regel für den Transport von Wartungsobjektdefinitionen verwendet werden. Fehlt die Berechtigung für die Transaktion SOBJ, kann die Tabelle OBJM für die Zuordnung auch direkt bearbeitet werden.
(Eine Überprüfung auf TOBJ-Objekte mittels einfacher „kritischer Objekte“-Prüfungen führt in diesem Fall zu vielen Fehlalarmen. Onapsis Control Transport liest den Inhalt der Transportdatei aus und kann daher feststellen, ob tatsächlich eine After-Import-Methode in der Objektdefinition gespeichert ist.)
Schritt 3: Ausführen der Code-
Sobald die TOBJ-Definition in das Zielsystem importiert wurde, löst jeder Datenimport für das jeweilige Pflegeobjekt im Zielsystem die Ausführung der After-Import-Methode aus.
Besonders wichtig: XPRAs und Nachimport-Methoden werden in der Regel als Importschritt im Kontext des Benutzer-DDIC oder eines gleichwertig berechtigten Benutzers ausgeführt.
Aus der Prüfung des Antrags lässt sich Folgendes schließen:
- R3TR XPRA
- Möglicher Angriffsversuch
- The respective transport should be inspected. One should be especially skeptical in the case of the report to be executed being transported into the target system with the same transport request for the first time or when it is being updated (R3TR PROG, LIMU REPS <report name>)
- R3TR TOBJ
- Mögliche Vorbereitung eines Angriffsversuchs
- Es sollte geprüft werden, ob dem Objekt eine „After-Import-Methode“ zugewiesen ist, und wenn ja, welchem Zweck diese dient.
- R3TR TABU OBJM
- Ein eindeutiger Angriffsversuch!
- Diese Tabelle wird vom SAP-Standard in der Transaktion SE09/10 abgefangen. Sie kann einem Transportauftrag hinzugefügt und mithilfe eines kurzen ABAP-Reports exportiert werden.
Um einen Angriff noch besser zu verschleiern, können Einträge in der Tabelle OBJM in einem übergeordneten Objekt verborgen werden. Dazu gehören:
- View Cluster (R3TR CDAT <random object name>)
- Maintenance View (R3TR VDAT <random object name>)
- Customizing Data (R3TR TDAT <random object name>)
In diesen Fällen muss ein Eintrag ebenfalls als eindeutiger Angriffsversuch gewertet werden! Nur die Überprüfung aller Transportanfragen, wie sie oben beschrieben wurden, schützt vor einem solchen Angriff.
*Diese Prüfung sowie über 100 weitere werden in der Platform automatisch Platform interne und externe Transportobjekte durchgeführt. Weitere Informationen zur Funktionsweise der Technologie und dazu, wie sie mithilfe der Platform in Ihre Geschäftsprozesse integriert werden kann, finden Sie im Anwendungshinweis zur SAP-Transportprüfung (PDF).