SAP ABAP Code Security: SYS CMD Execution

Ein wichtiger Bereich der SAP-Sicherheit, der erst in den letzten Jahren aktuell wurde, ist die Analyse der kundeneigenen SAP-Programme, die klassisch in der proprietären SAP-Sprache ABAP geschrieben werden.
Auch hier können, wie in jeder Programmiersprache, klassische Sicherheitslücken programmiert werden – sei es nun bewusst oder unbewusst.
Allerdings sind die Muster selbst deutlich anders gelagert als in einem Java-Stack oder einem Windows-Programm. Ziel bei diesen herkömmlichen Programmen ist es meistens, durch gezielte Falscheingaben das Programm entweder zum Absturz zu bringen (Buffer Overflow) oder künstlich eigenen Code zur Ausführung zu bringen (Code Injection).

Beides ist in einem ABAP-System nicht möglich, da ein Absturz eines Prozesses nichts anderes bewirkt als das Erzeugen eines Eintrags in der Log-Datenbank (Dump ST22) und ein Beenden des Programms mit Rückkehr an den Menü-Startpunkt.
Eine direkte Manipulation wie in anderen Hochsprachen oder Servern ist so also nicht möglich. Allerdings gibt es andere Manipulationsmöglichkeiten.
Viele kundeneigene ABAP-Programme arbeiten mit dem Hochladen oder Herunterladen von Daten. Hier sind möglicherweise große Lücken vorhanden, die Zugriff auf Serverdaten ermöglichen. Darüber hinaus ist der weitverbreitete direkte Aufruf von Betriebssystemkommandos, die nicht durch eine selbst programmierte Berechtigungsprüfung abgedeckt sind, ein großes Problem.

Auch wenn die klassische SQL Injection, also die Eingabe erweiterter SQL-Befehle, eine mögliche Sicherheitslücke ist, ist sie in SAP-Systemen eher ein Exot. Weiter verbreitet ist die ungewollte Dynamisierung von SQL-Aufrufen, weil man Eingangsparameter nicht deutlich genug prüft. Die Notwendigkeit, alle Eigenentwicklungen auch intern auf solche Sicherheitslücken zu überprüfen, bevor sie in den SAP-eigenen Code zur Auslieferung kommen, hat zur Entwicklung des Werkzeugs SAP Code Vulnerabilty Analysis geführt. Dieses werden wir in diesem Abschnitt genauer betrachten.
SAP Code Vulnerabilty Analysis ist in der internen SAP-Entwicklung

Durch den Einsatz eines Code-Scanners besteht die Möglichkeit, dass jeder Entwickler bei der erweiterten Prüfung seines Programms nun auch nach komplexen Sicherheitsmustern scannen kann, die ihm sagen, ob er – bewusst oder unbewusst – Schwachstellen in sein Programm eingebaut hat. Diese Schwachstellen werden erkannt und können nun in einem workflow-gesteuerten Prozess bearbeitet werden.

Aktuell gibt es zwei Produkte, die im Bereich der Überprüfung der kundeneigenen SAP-Programme den Kunden unterstützen können.

Das ältere und seit Jahren eingeführte Programm ist der „Code Profiler“ von Virtual Forge. Es ist eines der ersten Produkte in diesem Segment der SAP Sicherheit und wurde lange Jahre von der SAP selbst eingesetzt. Es ist sehr umfangreich und ist in der Lage, auch einzelne Variablen über den gesamten Kontrollfluss zu verfolgen. Dies führt zu sehr präzisen Aussagen und einer Reduzierung von Fehlalarmen, den „False Positives“
Das Produkt der SAP ist seit ca. 2 Jahren am Markt und entsprang dem Bedürfnis der SAP, ein eigenes Produkt zu dem Thema zu entwickeln. Es sollte zuerst in der eigenen, internen ABAP-Entwicklung eingesetzt werden und danach am Markt als eigenständiges Produkt zu platzieren.
Ich werde zu dem Thema jeweils einen eigenständigen Blog schreiben. Es bringt wenig, das eine gegen das andere Produkt zu positionieren, jeder Kunde muss für sich selbst entscheiden, welches der beiden Produkte zu der eigenen, spezifischen Situation am besten passt.
Funktional und im prinzipiellen Vorgehen sind beide Produkte sehr ähnlich.

Neben dem Scan und dem Aufzeigen der jeweiligen Sicherheits-Lücken eines Programme besteht auch die Möglichkeit, Aufgaben, die mit Sicherheitslücken in andere SAP-Systeme transportiert werden sollen, im weiteren Transportprozess anzuhalten. Dies betrifft das klassische Transportwesen SAP CTS (Correction & Transport System) als auch den Solution-Manager basierten CHARM-Prozess. Dadurch wird ein Programmierer (bzw. ein Entwicklungsleiter) gezwungen, die von ihm betreuten Programme nach gleichen Sicherheitskriterien sicher zu prüfen.

Sollte ein Programm dann noch Sicherheitsprobleme haben, kann es entweder über das Vier-Augen-Prinzip freigegeben oder zur weiteren Bearbeitung zurückgegeben werden.

Die Kernfrage beim Einsatz von solcher SAP Code Scanner ist natürlich die nach dem Schutz, den dieses Werkzeug in Bezug auf die eigene Code-Qualität liefert. Sicherheit in ABAP-Programmen war bisher kaum ein Thema, und Themen wie Viren und Trojaner, Schlupflöcher und Schläferprogramme waren in der ABAP-Welt unbekannt.

In einer durchschnittlichen SAP-Installation sind nach Jahrzehnten der Programmierung gute 10.000 kundeneigene Programme entstanden, die zwar im Hinblick auf Performance, Qualität und Wartung optimiert, aber nie auf Sicherheitsanforderungen überprüft wurden. Warum sollte das auch geschehen sein?
Also liegen die Angriffsvektoren durch unsicheren ABAP-Code auf einer anderen Ebene. Sie liegen in der Regel immer dann vor, wenn aus einer Eingangsvariablen (Bildschirmparameter) direkt etwas ausgelöst
wird.

Am Beispiel aus dem folgenden Listing, das generell für die dynamische Behandlung von Tabellen und Daten steht, soll gezeigt werden, worin die Problematik besteht.

In diesem Fall wird jedes beliebige Betriebssystemkommando ausgeführt, das in der Bildschirmvariablen unixcom eingegeben wird, ohne dass eine Sicherheitsüberprüfung ausgeführt wird. Dies sind also zwei Probleme: erstens der direkte Aufruf, der nach aktuellen Richtlinien veraltet ist und wegen fehlender Berechtigungsprüfungen nicht mehr verwendet werden sollte. Das zweite Problem ist die fehlende vorangestellte Berechtigungsprüfung, die zumindest existieren sollte.

Das Fixing würde in diesem Fall darin bestehen, den alten, direkten Systemaufruf durch einen von SAP speziell entwickelten Systembaustein zu ersetzen und das Programm entsprechend umzustellen.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE'
 EXPORTING
 commandname = 'ZPING'
 additional_parameters = ls_parameters
 operatingsystem = 'Windows NT'
 IMPORTING
 status = lv_status
 exitcode = lv_exitcode
 TABLES
 exec_protocol = lt_btcxpm
 EXCEPTIONS
 no_permission = 1

OTHERS = 15.
 IF sy-subrc <> 0.
 MESSAGE 'Fehler bei der Ausführung' TYPE 'E'.
 ENDIF.

An diesem Beispiel erkennt man, dass eine Verbesserung der Sicherheit einen Eingriff in den Quellcode bedeuten würde. Angenommen, die Funktion würde so gebraucht, wie sie in den Beispielen skizziert ist, wären die Änderungen doch substanziell, und ein neuer Test durch den Entwickler – und vor allem auch durch den Anwender – wäre zwingend notwendig.

Nachhaltig geführte Projekte zur ABAP Code Sicherheit kundeneigener Programme benötigen sehr viel Zeit. Wenn mehr als 3000 Programme zu überprüfen sind und wenn eine große Gruppe von Entwicklern zur nachhaltigen Programmierung im Bereich SAP Sicherheit geführt werden soll, dann dauert das mehr als ein Jahr. Sicherheit kommt nicht über Nacht und auch wenn der Fix eines fehlerhaften Programmes in einer Stunde ausgeführt werden kann, so dauert das Testen durch die Fachabteilung potentiell mehrere Stunden, die sich zu langen Projektzeiten summieren.

Trotzdem führt an dem Thema SAP Code Sicherheit kein Weg vorbei, denn hier existieren vor allem in historisch gewachsenen Systemen massive Sicherheitslücken.,