SAP ABAP Code Security – Alles über Projekt und Durchführung

Wenn alle aktuellen Projekte gestoppt werden, man mehr oder weniger in das Home-Office gesteckt wird und interaktive Arbeit remote stattfindet: Dann ist es Zeit, sich auf klassische Dinge wie Reinigung, Housekeeping und Aufräumen zu konzentrieren.
Gerade bei SAP-Systemen ist das Thema SAP-ABAP Code Security ein Sicherheits-Bereich, der stark vernachlässigt wird. Gerade hier ist es eigentlich wichtig, eine klassische Front der Angriffe auf SAP-Systeme zu eliminieren.

Häufigkeit des Missbrauchs von kundeneigemen SAP ABAP Code

Aus praktischer Erfahrung in der Forensik bei unseren Kunden haben wir die Erkenntnis gewonnen, das in allen Fällen von SAP-Einbrüchen, zu denen wir gerufen wurden, der Haupt-Angriffsvektor in den kundeneigenen Programmen lag. Auch wenn emotet und andere Ransomware in der Non-SAP-IT die Schlagzeilen beherrschen, so sind die SAP-Systeme hier meist der (teure) Kollateralschaden. Aber es ist doch der Insider-Angriff über klassische SAP-ABAP-Trojaner, der in den meisten Fällen gezielt die SAP-Produktionssysteme angreift.
Hier hilft vor allem die Analyse der kundeneigenen SAP-Programme, die klassisch in der proprietären SAP-Sprache ABAP geschrieben werden. Was verbirgt sich in den kundeneigenen Programmen, die meist in die Tausende gehen. Wie viele Fälle von verletzbaren und Angreifbaren, hochkritischem SAP-ABAP Code in kundeneigenen Programmen gibt es denn in einem System?

Hier ein paar repräsentative Zahlen aus bestehenden SAP-Systemen:

Wir gehen von einem Kunden-System aus, in dem seit 10 bis 20 Jahren ABAP-Programme entwickelt wurde. Hier sind es meistens 3000-10.000 Programme, die analysiert werden. Durchschnittlich sehen wir 20-60 ABAPS, die hoch-kritischen Code enthalten, dessen Ausführung direkt entweder zur Übernahme des Systems oder zum Totalverlust der Daten führen würden.
Weitere etwa 300-600 ABAPS stellen ein hohes Sicherheits-Risiko dar, dass innerhalb von Wochen beseitigt werden sollte.

Die meisten dieser ABAPS kommen bei dieser Altersstruktur aus alten Migrationen, Hilfsprogramme von Programmieren oder alte Programme aus der Open-Source-Community („Nuggets“), die gerade in aktuellen Produktivsystemen extremen Schaden anrichten können.
Immer mehr Angriffsvektoren auf SAP-Systeme haben mit ABAP Code zu tun, der als Trojaner benutzt wird oder der schon für sich eine Gefahr darstellt. Bei einem unserer letzten Untersuchungen bei einem SAP-Kunden haben wir einen ABAP-Report in der Produktionsumgebung gefunden, der kommentarlos alle FI-Tabellen löschte (DROP Table Statements), ohne Warnung! Ein unbeabsichtigtes Ausführen hätte desaströse Folgen gehabt. Es stellte sich heraus, dass dieser ABAP bei der Ersteinführung in den 90ern benutzt wurde, um bei Fehlern in der initialen Beladung das System wieder zurück zu setzen. Der ABAP wurde vergessen und nie gelöscht.

Architektur von SAP ABAP Code

Denn auch in ABAP kann, wie in jeder Programmiersprache, klassische Sicherheitslücken programmiert werden – sei es nun bewusst oder unbewusst. Auf 10 Kunden, in denen wir Projekte zur Codebereinigung durchführten, kommt mindestens ein Fall von Mitarbeitern, die bewusst Schadcode in ein Produktivsystem eingeführt haben (Zumindest, die, die „erwischt“ wurden. Die Dunkelziffer dürfte, wie bei allen Kriminalstatistiken, höher sein.
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, die vor allem mit Programmiermustern zu tun haben.

Werkzeuge zur Analyse

Es gibt Werkzeuge, mit denen sich die kundeneigenen Programme in einem Massenverfahren analysieren lassen. Die daraus gewonnen Ergebnisse und Erkenntnisse müssen dann in ein Projekt zur Schwachstellen-Behebung („Get Clean“) und dann in ein Projekt „Sichere ABAP-Programmierung“ („Stay Clean“) überführen.

Aber wie entdeckt man nun solche Schwachstellen?

Der einfachste Weg ist die Benutzung von Standard-ABAP-Programmen wie dem RS_ABAP_SOURCE_SCAN Hier kann nach angreifbaren Mustern kundeneigenen Code gesucht werden. Die Auswertung erfolgt manuell, kann aber einen ersten Eindruck vom Bedrohungsvektor geben.

Ein Muster, das man analysieren kann, wird in dieser Blogreihe beschrieben: Den Anfang macht ein Beitrag über SAP ABAP und Command Execution:

SAP ABAP Code Security: SYS CMD Execution

XITING Alchemist

Weiterhin gibt es ein sehr gutes Tool von der Firma xiting, den Alchemist, der Bestandteil der XAMS Suite ist. Das benutzen wir vor allem für eine erste Analyse der Systeme. Aber natürlich ist es auch ein hervorragendes Werkzeug für das gesamte Projekt „Sicherer kundeneigener Code“.
Auch die SAP hat ein Werkzeug, den SAP Code Vulnerability Analyzer, das wie alle SAP Standard-Produkte, die hauseigene Antwort der SAP auf die Thematik „Angriffsvektor ABAP“ ist.
Wenn man ein solches Werkzeug eingespielt hat (das meist in wenigen Stunden erfolgen kann) sieht man als Ergebnis der ersten Analyse, welche Bedrohungen und vor allem in welcher Quantität man unsicheren ABAP-Code im eigenen System hat.

Cleanup & Housekeeping

Dann fängt aber gerade erst die Stunde des Projektes an. Die Projekte sind keine Projekte, die eine permanente Menge an Ressourcen und Zeit benötigen. Sie brauchen aber eine punktuelle Steuerung und einen langen Atem, denn die Menge der zu ändernden Programme kann groß sein.
Man unterscheidet zwei Phasen:

Get Clean

Hier versucht man, initial die kritischsten Schwachstellen zu bereinigen und zu einem weiteren langfristigen nächsten Projekt-Schritt zu kommen. In der „Get Clean“ Phase wird mit vermehrten Anstrengungen alles bereinigt, was in der Prüfung als extrem kritisch angezeigt wurde.
Der Aufwand liegt hier weniger in dem direkten „Fix“ des Programms, sondern in dem klassischen Testen, das jedem SAP-ABAP Projekt innewohnt. Ausführliches Testen der abhängigen Geschäftsprozesse ist hier definitiv ein Aufwandstreiber

Stay Clean

Wenn man die erste Phase in Angriff genommen hat, versucht man dann in einer zweiten Phase, einen permanenten Qualitätssicherungsprozess zu etablieren. Hierzu wird das Werkzeug aktiv in das Transportwesen eingeklinkt, und verhindert, dass kundeneigener AQBAP-Code über das Transportwesen mittels Freigabe transportiert werden kann.
Dies heißt meistens auch, dass nicht nur Neu-Programme, sondern auch Programme, die gewartet werden, alle sicherheitsüberprüft werden und erst ohne Schwachstellen freigegeben und transportiert werden können.

S/4 HANA Migration

Die Bereinigung von kundeneigenem SAP ABAP Code auf Basis eines Security-Projektes ist auch ein Anfang in Bezug auf eine anstehende SAP HANA Migration. Denn die Benutzung des SAP ATC (ABAP Test Cockpit) für die Sicherheitsanalysen und die Bereinigung der betroffenen Programme ist auch der Themenkomplex, wenn es um robusten ABAP Code, Performance und zentrale Verwaltung von Richtlinien geht. Ein SAP Security Projekt ist oft der technologische Wegbereiter, auf dessen Basis sich sowohl technologisch wie organisatorisch die S/4 HANA Migration anschließt. Denn auch die Migration setzt Voraus, das keine Sicherheitslücken mehr existieren, aber auch, dass der kundeneigene Code darüber hinaus allen modernen ABAP-Richtlinien entspricht.

Housekeeping

Dies heißt nicht, dass das eigentliche Projekt und die Analyse ein Projekt mit hohem Aufwand ist. Mit wenigen Stunden pro Woche, mit Webex und remote Sessions für die Entwickler kommt man meistens mit einem Jour Fixe die Woche aus. Auch die Verwaltung hinter den Kulissen braucht nicht viel Aufwand.
Der Aufwand liegt in dem Bereinigen des Source Codes und dem Testen. Aber diese Arbeit muss ja ohne hin gemacht werden.

Die Wichtigkeit des Projekts

Deshalb ist dieses Projekt prädestiniert, in diesen Zeiten angefangen zu werden. Unternehmen sind in Krisenzeiten verletztbarer und angreifbarer denn je, denn zu den wachsenden externen Bedrohungen kommt eine wachsende Unsicherheit und damit potentielle Gefährdung durch interne Bedrohungen hinzu. Dies sollte gerade diese Zeiten ausnutzen, sich der eigenen Systeme zuzuwenden und diese aufzuräumen und sicher zu gestalten.