Logische Datenbanken haben sich einmal großer Beliebtheit erfreut. Schließlich konnte man relativ leicht eine komplexe Selektion darstellen und musste dafür nicht aufwendige Reports schreiben. Auch die Art der dynamischen Selektion war bei Anwendern beliebt, sodass Entwickler immer wieder darauf zurückgriffen. Mit der Version 7.50 erklärte die SAP logische Datenbanken nun für obsolet – mit der Folge, dass keine neuen logischen Datenbanken mehr angelegt werden sollen, aber die alten wie gehabt weiterfunktionieren. Das zieht aber auch ein Sicherheitsproblem nach sich, welches alle Reporte betreffen kann.

 

Logische Datenbanken

Um einen Report im SAP System auszuführen, wird der Code, welchen der Programmierer schreibt, um viele interne Anweisungen erweitert. Beispielsweise wird die Konstante „SPACE“ über das Include <SYSINI> eingebaut. Im Kontext der logischen Datenbanken werden auch die beiden in der SAP Hilfe beschriebenen Aufrufe der Unterroutinen before_event und after_event implementiert. Diese Unterroutinen werden ebenfalls eingebaut, und falls es sich um eine logische Datenbank handelt, auch ausgeführt.

Innerhalb dieses automatisch eingebauten Include <SYSINI> gibt es eine Anweisung, die ein Angreifer ausnutzen kann:

Diese Anweisung wird in einem normalen Report immer mit festen (SAP-Standard-) Reports gefüllt und ist somit unkritisch. In dem Kontext der logischen Datenbanken aber wird der Inhalt der Systemvariable SY-LDBPG benutzt, um Standardroutinen aufzurufen. Ein generierter „normaler“ Report unterscheidet sich von einem generierten Report einer logischen Datenbank nur durch die Füllung dieses Feldes.

Wenn sich nun in einem Report ohne logische Datenbank eine Möglichkeit ergibt, das Feld SY-LDBPG zu füllen – beispielsweise über einen Userexit –, dann werden die bekannten Unterroutinen innerhalb des gleichen Programms gerufen. Da diese aber normalerweise nicht implementiert sind, stellt dies keine Gefahr dar. Die Unterroutine %_ROOT aber wird mit dem Programm des Systemfeldes gerufen. Somit kann dort ein Quellcodeabschnitt angegeben werden, der außerhalb der Kontrolle des Programms liegt.

Ein Beispiel: Dieser Report ohne logische Datenbank füllt das Feld direkt.

Der gerufene Report hat keine andere Aufgabe, als die Unterroutine zu beherbergen.

Das Ergebnis:

Wie Ihre ABAP-Codings Angriffen standhalten

Mit dem SAST Code Security Advisor der akquinet AG können Sie erkennen, ob Sie bereits Opfer dieses Angriffes sind und ausschließen in Zukunft Opfer zu werden. Denn eine belastbare und konsistente Grundsicherheit Ihrer SAP-Systeme erreichen Sie nur über einen wirklich ganzheitlichen Security-Ansatz. Und das schließt auch Ihr ABAP-Coding mit ein. Eine Risikobewertung, angereichert mit Kennzahlen wie beispielsweise Nutzerstatistiken, erleichtert Ihnen die Priorisierung bei der Bereinigung und bietet die Möglichkeit obsoleten Code ganz einfach stillzulegen. Der ideale Schutz vor einem Missbrauch potenzieller Backdoors.

Sie wollen mehr zum Thema Platform Security erfahren, oder interessieren sich für unseren SAST Code Security Advisor? Dann besuchen Sie uns gerne auf unserer SAST SOLUTIONS Website oder sprechen Sie uns an: knowhow@akquinet.de

Markus Rest, SAP ABAP Development (SAST SOLUTIONS)