Die Säulen der SAP Sicherheit

Seit es vor mehreren Jahren es wichtig wurde, dass Sicherheits-Analysen wie SAP Penetration Tests durchgeführt werden, hat es sich auch gezeigt, dass in diesen Tests immer wieder drei große Themen als sicherheitstechnische Herausforderungen sich heraus gebildet haben. DIese Tests zeigen immer wieder die drei Grundstützen, auf denen sich eine allgemeine SAP Sicherheit aufbaut und zusammen setzt.

Säule 1: Remote Function Call

Hauptangriffsvektor für SAP Systeme ist nach wie vor der Remote Function Call (RFC) , das Aufrufen der SAP-Systeme und deren Funktionalitäten über entfernte Programme. Diese RFCs unterliegen nicht den klassischen Endanwender-SAPGUIS, sondern es sind aufrufbare Schnittstellen (APIs), die sich aus jeden entfernten Programmen, von Java über Python bis Microsoft Excel, aufrufen lassen.

Die Technik der RFC erlaubt es, beliebige Funktionalität eben aufzurufen, zu parametrisieren und auszuführen, Dieses können solch illustre Bausteine sein wie BAP_USER_CREATE (das Anlegen eines Benutzers in SAP), das Auslesen ganzer Datenbank-Bereiche oder das Ausführen von betriebssystem-Kommandos mit ROOT-ähnlichen Berechtigungen (Stichwort SIDadm).

In älteren Systemen war es einfach möglich, sich direkt mit dem SAP zu verbinden, man brauchte nur eine beliebige Programmiersprache und die dazu zugehöre SAP RFCLIB, die SAP Bibliothek für die Betriebssystem-Anbindung.

Was dann noch fehlte, war ein technische Benutzer für diese Schnittstelle, ein sogenannter RFC-User, der die nötigen Autorisierungen und Authentifizierungen mitbrachte. Aber auch war so oft kein Problem, da man in vergangenen Zeiten immer wieder gerne diesen Benutzern SAP_ALL  gab.  ( Siehe auch diesen Blog )

Inzwischen gibt es mehr und mehr Schutzmechanismen gegen diese Art der Angriffe. Vor allem hat SAP mehr und mehr die anonyme Ausführung der Bausteine verhindert, so dass es kaum entsprechende Bausteine gibt, die ohne Berechtigungen funktionieren.

Und auch die sogenannte Gateway-Security, die ein Monitoring und Blacklisting/Whitelisting bestimmter RFC-Aufrufe erlaubt, gehört in diesen Projekt.

Der zentrale Schutz gegen RFC-Angriffe, der effektiv ist, wurde von der SAP als UCON-Technologie (Unified Connectivity) eingeführt. Hier werden alle SAP RFC Schnittstellen protokolliert und können dann ebenfalls in Blacklist/Whitelist Szenarios überführt werden. Parallel werden Berechtigungs-Traces mitgeschnitten, die es zusammen mit den Whitelist-Szenarien ermöglichen, gezielte Berechtigungen für diese Schnittstellen zu vergeben und zu kontrollieren.

Ein klassisches RFC-Sicherheits-Projekt besteht aus einer initialen Datensammlung und Quantifizierung der Schnittstellen, aus einer längeren (mehrmonatigen) Analyse –Phase mit den SAP-Werkzeugen aus UCON und dem SAP Gateway. Dem schließt sich eine Realisierungsphase an, in dem die Whitelist erstellt werden sowie die Rollen und Berechtigungen der Remote-Benutzer zugeschnitten werden.

In neueren Release der SAP kann sich dann eine Übergangsphase (Simulationsphase) anschließen, in der Whitelist, Blacklist und Berechtigungen simuliert werden. Fehler, Zurückweisungen oder Blocken von Elementen werden dann in nur in einem Log angezeigt. Wenn dann mit der Zeit die Events aus dem Log ausgewertet und behoben sind, kann das System live genommen und die Blacklist, Whitelist und Autorisierungen scharf geschaltet werden.

Als Resultat einer initialen Sicherheitsanalyse, eines Pen-Tests, sollte bei entsprechendem Auftreten von Schwachstellen (und dies war bisher bei allen meinen Pen-Tests der Fall) ein RFC-Projekt auf der Basis von SAP UCON durchgeführt werden. Dies schließt die Phasen Assessment, Monitoring und Simulation ein.

Säule II ABAP Code Analyse

Ein zweiter, großer Bereich ist der Bereich der Code-Analyse, der Auswertung von kundeneigenen SAP Programmen auf Schwachstellen. Auch hier können, wie in jeder Programmiersprache, klassische Sicherheitslücken einprogrammiert werden – sei dies nun bewusst oder unbewusst erfolgt. 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.

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.

Wichtig ist vielleicht noch an dieser Stelle festzustellen, dass diese Art von Code-Analyse kein riesiges Programm mit einem Big-Bang Go Live sein muss. Es handelt sich hier vor allem um das Bewusstmachen dieser Thematik bei den Entwicklern, der evolutionären Änderung der Programmierung durch sichere Programmiermuster und damit verbunden der kontinuierlichen Schulung und „Awareness“ für Entwickler.

Gerade verbunden mit SCRUM-Methoden aus der agilen Entwicklung kann man hier hervorragende Projektmechanismen und Projektelemente schaffen, die zu einer andauernden Verbesserung der Sicherheit bei kundeneigenen SAP ABAP Entwicklungen führen.

Als Resultat einer initialen Sicherheitsanalyse, eines Pen-Tests, sollte bei entsprechendem Auftreten von Schwachstellen (und dies war bisher bei allen meinen Pen-Tests der Fall) ein Projekt zur Sicherheit in den kundeneigenen Entwicklungen durchgeführt werden. Dies schließt eine Get-Clean-Phase und eine Stay-Clean-Phase eines Projektes ein

Säule III Password, Roles&Authroizations, Segregation of Duty.

Die dritte Säule ist die Säule der Berechtigungen, des Zugangs mit Passwort und die “Segregation of Duty”, des Trennens von Verantwortlichkeiten.

Für das Hacken und den Schutz von Passwörtern gibt es hier einen eigenen Blog: HACK PASSWORTS.

Wichtig ist es hier fest zu halten, das vor allem die alten Passwörter der technischen Benutzer und der Schnittstellen-Benutzer ein hohes Risiko darstellen. Sie sind oft 6 Stellen lang und haben zudem noch die universale Berechtigung SAP_ALL. Das macht Sie zu gefährlichen Optionen für einen erfolgreichen System-Hack.

Neben den Passwörtern und deren Schutz sind Autorisierungen, die SAP-Rollen, ein sehr großes Feld von Bedrohungsvektoren. In der SAP-Modulsprache sind dies die „GRC“-Anforderungen, die Anforderungen und Berechtigungen, die sich aus Governance, Risk und Compliance ergeben. Hier wird sozusagen die „Best Practice“ beschrieben, wie eine SAP Rechtevergabe aus Sicht von Gesetzgebungen, Datenschutz, Richtlinien und Vorschriften sein erfolgen sollte.

Vor allem der technische Schutz der Funktionsbausteine ist immer wieder Gegenstand von Diskussionen über Berechtigungsvergabe. Letztendlich muss, wie bei UCON-Projekten, eine dedizierte Praxis der Analyse und Vergabe von Rollen und Rechten für RFC-Benutzer aufgestellt werden.

Ein weiteres Sicherheitsrisiko sind die Zuteilung von Rollen und Rechten an Dialog-Benutzer, die ihre tägliche Arbeit verrichten, Auch hier muss man darauf achten, das alle notwendigen GRC-Regeln eingehalten werden und vor allem,, das diese Benutzer durch das „Wandern“ durch Fachabteilungen keine gefährlichen Häufungen von Berechtigungen haben. Einkäufer, die Berechtigungen zum Buchen von Wareneingang haben und auch die Freigabe der Zahlungen durchführen dürfen, wären ein maximaler Verstoß gegen Compliance-Regeln, da hier Missbrauch Tür und Tor geöffnet wird.

Klassische GRC-Projekte, Analyse von Benutzern mit hoher Berechtigung (Administratoren) und Projekte zum Segregieren von technischen Benutzer sind arbeitsintensive Projekte, die lange laufen und in der Regel von und mit entsprechenden Werkzeugen durchgeführt werden.