Gefahren im SAP-Transportmanagement: Teil 3

Bearbeitung der SAP-Jobverwaltung

Dies ist der dritte Teil unserer Blogreihe über die Gefahren im SAP-Transportmanagement. Im ersten Teil haben wir eine Einführung in SAP-Transporte gegeben. Im zweiten Teil haben wir uns mit dem Ausgangspunkt dieses Angriffs, der Transaktion SU24, befasst. In diesem dritten Teil konzentrieren wir uns auf die Manipulation der Jobverwaltung und die damit verbundenen Risiken für SAP-Transporte.

Die Jobverwaltung in SAP® bietet eine große Angriffsfläche für Manipulationen von außen. Die Möglichkeiten reichen vom Ausnutzen von Schwachstellen bestimmter SAP-Standardjobs, wodurch kritische Jobattribute geändert werden können, bis hin zur vollständigen Definition und Einplanung von Jobs über Transportaufträge.

Jeder SAP-Basis-Administrator kennt den Job SAP_COLLECTOR_FOR_PERFMONITOR. Er sammelt statistische Daten aus Dateien und fügt sie in Tabellen ein, die von Transaktionen wie ST03 und ST03N gelesen und verarbeitet werden können. Dazu nutzt der Job mehrere Reports, die er aus der Tabelle TCOLL ausliest. Obwohl bei der manuellen Pflege dieser Tabelle eine Überprüfung der hinzugefügten Reports anhand der festen Werte der Domäne COLL_RNAME erfolgt, um Missbrauch zu verhindern, ist es möglich, beliebige Reports per Transport hinzuzufügen. In diesem Fall werden die aus der Tabelle TCOLL auszuführenden Reports nicht anhand der festen Werte der Domäne überprüft, wenn der Job von SAP_COLLECTOR_FOR_PERFMONITOR gestartet wird. Zudem wird der Job SAP_COLLECTOR_FOR_PERFMONITOR im Kontext des Benutzers DDIC oder eines gleichwertigen Benutzers ausgeführt, was bedeutet, dass Angreifer selten auf Berechtigungsprobleme stoßen. Obwohl der Job im Mandanten 000 läuft, stellt dies für einen Angriff keine wirkliche Einschränkung dar.

Mit SAP S/4HANA hat SAP ein neues Job-Repository für Standard-Systemjobs eingeführt. Die neue Transaktion SJOBREPO ermöglicht es berechtigten Benutzern, bestehende Jobdefinitionen anzuzeigen und in gewissem Umfang anzupassen. Zudem ist es möglich, die Ausführung einzelner Jobs vollständig zu deaktivieren.

Noch interessanter ist die Tatsache, dass SAP zusammen mit dem neuen Job-Repository auch das neue Transportobjekt R3TR JOBD eingeführt hat. Sie können nun über die Transaktion SE80 auf dem Entwicklungssystem Jobdefinitionen anlegen und diese auf „legale“ Weise in die Produktion transportieren! Das bedeutet, dass bei der Genehmigung eines solchen Transportauftrags für die Produktion höchste Sorgfalt geboten ist. In früheren S/4HANA-Versionen laufen die Jobs im Kontext des festen Standardbenutzers SAP_SYSTEM mit dem Profil SAP_ALL. In neueren Versionen ist es möglich, pro Mandant einen Standardbenutzer zu definieren (die Beschränkung auf Mandant 000 besteht nicht mehr), der nicht unbedingt SAP_ALL benötigt. Dennoch empfiehlt SAP, mindestens eine generische Berechtigung für alle SAP-Basis- und alle SAP-HR-Berechtigungsobjekte zu vergeben (siehe SAP-Hinweis Nr. 2731999). Da Angreifer sich der besonderen Aufmerksamkeit bewusst sind, die dem Objekt R3TR JOBD zuteilwerden könnte, könnten sie einen Angriff über das Job-Repository tarnen, indem sie stattdessen die einzelnen Tabellen transportieren, die ein JOBD-Objekt definieren.

Ein Angreifer ist jedoch nicht auf Standard-Systemaufträge beschränkt und kann auch die übliche Architektur der Hintergrundverarbeitung für einen Angriff missbrauchen.

Generell gilt: Solange ein Angreifer die interne Auftragsnummer kennt, kann jeder vorhandene Auftrag als Trojaner für Angriffe missbraucht werden. Beispiele hierfür sind:

• Jobschritte hinzufügen/bearbeiten/löschen
• Den ausführenden Benutzer eines Jobschritts ändern
• Den Status eines Auftrags ändern

Ist die Auftragsnummer unbekannt, kann ein Angreifer über den Transport einen völlig neuen Auftrag in einem Produktionssystem definieren und einplanen. Dazu reichen die drei Tabellen TBTCO, TBTCP und TBTCS aus.

Was bedeutet das für diejenigen, die Transportaufträge oder Änderungsaufträge für die Produktion genehmigen?

Die folgenden Punkte müssen sorgfältig geprüft werden:

• R3TR TABU TCOLL
  • Möglicher Angriffsversuch
  • Wenn es sich nicht um einen Bericht handelt, der als festgelegter Wert der Domäne COLL_RNAME definiert ist, ist ein Angriffsversuch sehr wahrscheinlich!
  • Übertragungen in den Inhalt der Tabelle TCOLL sollten generell untersagt werden 
     
• R3TR JOBD
  • Erläutern Sie die Gründe für die Erweiterung der Liste der System-Standardaufträge
  • Prüfen Sie, ob der entsprechende Bericht nicht als allgemeiner Job in SM36 eingeplant werden kann
     
• R3TR TABU STJR_JOBD_ROOT, STJR_JOBD_TREP
  • Ein eindeutiger Angriffsversuch!
  • Jemand ist sich der besonderen Aufmerksamkeit bewusst, die dem neuen Jobdefinitionsobjekt R3TR JOBD zuteilwird, und versucht, die Sicherheitsprüfungen zu umgehen, indem er die einzelnen Tabellen transportiert
• R3TR TABU TBTC*
  • Eindeutiger Angriffsversuch!
    Jemand versucht, das Auftragsverwaltungssystem von außen zu umgehen, um bestehende Aufträge zu manipulieren oder neue Aufträge zu definieren und einzufügen

Um einen Angriff noch besser zu verschleiern, können Einträge der oben genannten Tabellen 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 jeder einzelnen Transportanforderung, wie in unseren früheren Blogbeiträgen erwähnt, bietet Schutz vor einem solchen Angriff.

*Dieser Test 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).