SAP-Security Teil 2

SAP ist bekanntlich einer der weltweit größten Hersteller von Software zur Abwicklung sämtlicher Geschäftsprozesse eines Unternehmens. In den letzten Jahren hat sich SAP durch den Zukauf vieler Unternehmen strategisch auf den Bereich Cloud neu ausgerichtet („SAP – A Cloud Company“). Resultierend hieraus ist die Anzahl der durch SAP angebotenen und hergestellten Softwareprodukte stark gewachsen und durchaus schwer überschaubar.

Im vorangegangenen Teil 1 haben wir uns mit der grundlegenden Architektur sowie der Sicherheit auf Netzwerkebene eines SAP-Systems beschäftigt. Im vorliegenden zweiten Teil dieses Artikels werden wir das Augenmerk auf die SAP-Basis sowie die Sicherheit in der Anwendungsentwicklung legen. Aus Gründen der Kontinuität wird die Nummerierung fortgesetzt.

2.2 SAP-Basis

In diesem Abschnitt befassen wir uns mit einigen Aspekten der Sicherheit der SAP-Basis, also desjenigen Teils des SAP-Systems unterhalb der Applikationsschicht. Alle Business-Daten eines SAP-Systems werden in der unterliegenden Datenbank persistiert, wobei SAP eine Vielzahl von Datenbanksystemen unterstützt. Als Abstraktionsschicht der unterschiedlichen SQL-Dialekte der unterstützten RDBMS kommt das SAP-proprietäre OpenSQL zum Einsatz, das wiederum eine echte Teilmenge der Programmiersprache ABAP ist.

Um Geschäftsprozesse verschiedener Unternehmenseinheiten auf einem System abbilden zu können, ist das System als solches mandantenfähig. Diese Mandantentrennung findet ihre Grenzen jedoch innerhalb der unterliegenden Datenbank. Der Benutzer mit dem das SAP-System selber in die Datenbank hineingreift hat volle Berechtigungen auf das Datenbankschema und somit auch mandantenübergreifenden Zugriff auf alle Daten. Die Trennung wird durch das System sichergestellt indem bei jedem Datenzugriff implizit nur die Daten des aktuellen Mandanten berücksichtigt werden.

Es existieren auch einige mandantenübergreifende Tabellen, deren Inhalt für alle Mandanten relevant ist, wie beispielsweise die Tabelle RFCDES, die alle im System vorhandenen RFC-Destinationen speichert. Die grundlegende Administration eines Systems geschieht üblicherweise im eigens dafür vorgesehenen Mandanten 000.

2.2.1 Benutzer und Benutzertypen

2.2.1.1 Benutzertypen

Es ist darauf zu achten, dass die dem jeweiligen Einsatzzweck entsprechenden Benutzertypen gewählt werden. Die Verwendung nicht angemessener Benutzertypen kann gravierende Auswirkungen auf die Systemsicherheit haben.

2.2.1.2 Standardbenutzer

Ein SAP-System kennt eine Reihe von Standardbenutzern, die während der Installation angelegt werden. In älteren SAP-Releases waren diese mit wohlbekannten Standardkennwörtern versehen. Einer der ersten Schritte während der Sicherheitsanalyse ist daher die Prüfung auf das Vorhandensein von Benutzern mit Standardkennwörtern über die Transaktion RSUSR003. In neueren Releases werden keine Standardkennwörter mehr verwendet. Stattdessen wird ein bei der Installation zu vergebendes Masterkennwort für diese Benutzer gesetzt.

Die folgenden Standardbenutzer existieren in einem SAP-System: DDIC, SAP*, EARLYWATCH, TMSADM und SAPCPIC. Der Benutzer EARLYWATCH ist in neueren Releases nicht mehr notwendigerweise vorhanden.

Von besonderen Interesse ist der Benutzer SAP*. Dieser existiert a-priori in allen Mandanten des Systems und besitzt dort maximale Berechtigungen (SAP_ALL). Die besondere Bedeutung ergibt sich aus der Tatsache, dass dieser Benutzer im Falle einer gravierenden Störung des Systems als eingebauter Notfallbenutzer verwendet werden kann.

Ist beispielsweise durch eine Störung der Benutzerstammsätze keine Anmeldung am System mehr möglich, so kann mit der nachfolgend beschriebenen Prozedur ein Zugriff auf das System wiedererlangt werden.

• Der Benutzerstammsatz für SAP* wird aus der unterliegenden Datenbank gelöscht. Offensichtliche Voraussetzung ist also, dass der Zugriff auf die Datenbank noch gewährleistet ist.

• Der Konfigurationsparameter login/no_automatic_user_sapstar wird in der entsprechenden Profildatei auf den Wert 0 gesetzt.

• Das System wird neu gestartet.

• Mit dem Benutzer SAP* und dem Kennwort PASS ist eine Anmeldung am System möglich. 

Es handelt sich hierbei um ein offiziell dokumentiertes Feature. Offensichtlich kann jedoch das Nichtvorhandensein des Benutzers SAP* in einem Mandanten katastrophale Konsequenzen nach sich ziehen. Es ist also in jedem Fall sicherzustellen, dass in allen Mandanten der Benutzerstammsatz für SAP* existiert.

Im Allgemeinen gelten die folgenden Empfehlungen hinsichtlich der Absicherung der Standardbenutzer:

• Vorhalten einer Übersicht aller Mandanten eines Systems.

• Sicherstellen, dass SAP* existiert und in jedem Mandanten deaktiviert ist. Entfernen aller Berechtigungen von SAP*.

• Sicherstellen, dass – soweit zutreffend – die Standardkennwörter geändert wurden.

• Zugehörigkeit der Standardbenutzer in der Benutzergruppe SUPER sicherstellen.

• Im Regelfall sollten alle Standardbenutzer gesperrt sein und lediglich für notwendige Arbeiten temporär entsperrt werden.

2.2.2 Berechtigungen

SAP bietet ein granulares System zur Verwaltung von Berechtigungen. Diese werden über sogenannte Profile bzw. Rollen an einen Benutzer vergeben. Die atomare Einheit ist hierbei das Berechtigungsobjekt, eine Sammlung von bis zu 10 Key/Value-Paaren die simultan erfüllt sein müssen. 

In einzelnen Modulen wie z.B. HR oder CRM existieren über dieses grundlegende Berechtigungs-system hinaus weitere Berechtigungsmodelle. Diese strukturellen Berechtigungen sind nicht direkt an einen Benutzer, sondern an dessen Planstelle innerhalb der Organisationsstruktur des Unternehmens gebunden.

Im Regelfall werden einem Benutzer eine oder mehrere Rollen zugeordnet, die die Berechtigungen enthalten, die der Benutzer zur Erfüllung der ihm zugedachten Aufgaben und unter Einhaltung des Berechtigungskonzeptes benötigt. Auch hier zeigt sich in der Praxis häufig, dass mehr Berechtigungen vergeben wurden als tatsächlich benötigt.

2.2.2.1 SAP_ALL & Notfallberechtigungen

Die maximal möglichen Berechtigungen werden über das Profil SAP_ALL vergeben. Ein Benutzer, dem dieses Profil zugeordnet ist, hat die unmittelbare und vollständige, mandantenübergreifende Kontrolle über das System. In der Praxis findet sich dieses Profil häufig bei Basis-Administratoren, Entwicklern, technischen Benutzern (z.B. WF-BATCH) oder Beratern. 

Die flächige Vergabe dieses Profils ist jedoch keinesfalls notwendig. Ein ordnungsgemäßer und reibungsloser Betrieb des Systems ist möglich ohne, dass irgendeinem regulären Benutzer das Profil SAP_ALL zugeordnet sei muss. Natürlich erfordert dies im Vorfeld einen deutlichen Aufwand im Berechtigungsdesign, der aber durch den sich ergebenden Sicherheitsgewinn absolut gerechtfertigt ist.

Ein lokaler Notfallbenutzer mit SAP_ALL kann in einem System durchaus als (vor)letzte Rettungsleine vorhanden sein. In diesem Fall wird das Augenmerk in der Prüfung auf den den Einsatz dieses Benutzers umgebenden Kontrollprozessen liegen müssen. Zur feineren Steuerung von Notfallberechtigungen existiert beispielsweise SAP GRC AC, auf dessen Einsatz hier nicht näher eingegangen wird.

Es ist zu beachten, dass sich weitreichende Berechtigungen nicht nur hinter dem Profil SAP_ALL verbergen müssen. In mehreren durchgeführten Sicherheitsanalysen trat bereits der Fall auf, dass tatsächlich keinem Benutzer im System SAP_ALL zugeordnet war. Stattdessen war einigen Benutzern ein bis auf wenige Berechtigungsobjekte identisches Profil zugeordnet, das im Endeffekt ebenso die vollständige Kontrolle des Systems ermöglichte. In der Prüfung muss also auch beachtet werden, ob „verdächtige“ Profile (z.B. Z_NOTFALL) existieren und welchen Benutzern diese zugeordnet sind. Der Vergleich verdächtiger Profile gegen SAP_ALL kann dann leicht mittels des User Information Systems (SUIM) erfolgen.

2.2.2.2 Kritische Berechtigungen

Die Sicherheit eines SAP-Systems hängt wesentlich an dem implementierten Berechtigungs-konzept. Ein schwieriges Problem hierbei ist die Identifikation kritischer Berechtigungen, mit denen potentiell gefährliche oder disruptive Tätigkeiten im System durchgeführt werden dürfen.

Formal kann zwischen kritischen Berechtigungen innerhalb der SAP-Basis und innerhalb der Applikationsschicht unterschieden werden. Berechtigungsobjekte der SAP-Basis beginnen jeweils mit dem Präfix S_, solche der Applikationsschicht bspw. mit F_, M_, P_ oder V_. Kritische Basis-Berechtigungen haben grundsätzlich auch das Potential, um Auswirkungen auf die Applikations-ebene zu zeitigen.

Kritische Berechtigungen auf Applikationsebene sind in der Regel solche, die bspw. das Gebot der Funktionstrennung (SoD) oder das Radierverbot verletzen können. 

Insbesondere auf Applikationsebene ergeben sich durch individuell angepasste Geschäftsprozesse und deren Berechtigungsobjekte immense Aufwände in der Analyse und ggf. der nachfolgend notwendigen Trennung von Berechtigungen im Sinne einer SoD. 

SAP bietet im Auslieferungszustand eine vordefinierte Menge kritischer Berechtigungen an (Transaktion SE96). Diese sind jedoch bestenfalls eine Vorlage; die tatsächlichen kritischen Berechtigungen insbesondere auf Applikationsebene ergeben sich grundsätzlich erst aus der Analyse der im System abgebildeten Administrations- und Geschäftsprozesse. Nach Analyse der Geschäftsprozesse und der darauffolgenden Identifikation kritischer Berechtigungen kann beispielsweise die SAP GRC (Governance, Risk and Control) Suite zur Erkennung von Berechtigungskonflikten verwendet werden.

Die nachfolgende Tabelle dokumentiert exemplarisch einige wichtige Basis-Berechtigungsobjekte: 

Es ist jedoch darauf zu achten, dass das Vorhandensein eines einzelnen Berechtigungsobjektes in einer gewissen Ausprägung an und für sich noch nicht notwendigerweise kritisch ist, auch wenn dies gerne in Prüfungsleitfäden so dargestellt wird. Der Hintergrund ist, dass in den allermeisten Fällen mehr als ein Berechtigungsobjekt geprüft wird bevor eine – möglicherweise kritische – Operation durchgeführt werden kann.

Im Rahmen einer grundlegenden Sicherheitsanalyse ist immer auch das Berechtigungsobjekt S_DEVELOP zu betrachten. Wird dieses Objekt in einer Ausprägung vergeben, die ausschließlich Wildcards enthält, so ist dies funktional äquivalent zu SAP_ALL.

2.2.2.3 Zugriff auf Tabellen

Berechtigungen werden nur zu einem sehr geringen Teil durch das System selber geprüft. In den allermeisten Fällen ist es die Aufgabe der Applikationsentwickler, angemessene Berechtigungs-prüfungen zu implementieren. Wir wollen dies am Fall des Zugriffs auf eine einfache Tabelle erläutern.

Der Zugriff auf Tabellen kann über mehrere Berechtigungsobjekte gesteuert werden, deren Namen mit S_TABU_ beginnen. Wir betrachten hier nur die Objekte S_TABU_DIS sowie S_TABU_NAM.

Das Objekt S_TABU_DIS besteht aus den Feldern DICBERCLS und ACTVT. Das Feld DICBERCLS enthält die sog. Tabellenberechtigungsgruppe. Eine Tabellenberechtigungsgruppe ist eine logische Gruppierung einer oder mehrere Tabellen. Wollen wir nun auf eine Tabelle zugreifen, die bspw. der Tabellenberechtigungsgruppe SC zugeordnet ist, so muss unser Objekt S_TABU_DIS im Feld DICBERCLS den Wert SC beinhalten.

Die genaue Art des Zugriffs wird über den Wert des Feldes ACTVT gesteuert. Wollen wir bspw. nur lesend auf diese Tabelle zugreifen, so benötigen wir das das Feld ACTVT mit dem Wert 03. Die korrekte Prüfung innerhalb der Anwendung sollte dann ähnlich dem folgenden aussehen:

Hier wird zunächst die betreffende Tabellenberechtigungsgruppe der Tabelle tablename bestimmt, um im nächsten Schritt die entsprechende Prüfung des Objektes S_TABU_DIS vorzunehmen.

In Analysen zeigen sich auch immer wieder Fehler, die innerhalb der Berechtigungsprüfung auftreten können. Beispielsweise kann fälschlicherweise auf eine statische Tabellenberechtigungs-gruppe geprüft werden, anstatt diese aus der Tabelle TDDAT wie oben dargestellt auszulesen. Wird die Tabellenberechtigungsgruppe dann geändert – was selten vorkommen sollte – so wird die Prüfung fehlschlagen und der gewünschte Zugriff wird nicht gewährt. Ebenso kann der Programmierer die Überprüfung des Rückgabewertes des authoritycheck-Statements vergessen. In diesem Fall wird trotz nicht bestandener Prüfung im Programmfluss fortgefahren und der Tabellenzugriff gewährt.

Die Berechtigungssteuerung über Tabellenberechtigungsgruppen hat einige Nachteile: 

• Sie erlaubt Zugriff auf alle Tabellen innerhalb dieser Gruppe.

• Prüfungen müssen explizit programmiert werden.

• Systemupdates überschreiben durch den Kunden vorgenommene Änderungen im SAP-namensraum.

Um den Zugriff auf Basis individueller Tabellen zu steuern, wäre unter Verwendung von Tabellenberechtigungsgruppen eine Gruppe pro zu schützender Tabelle notwendig, was aus offensichtlichen Gründen nicht praktikabel ist.

Das Berechtigungsobjekt S_TABU_NAM adressiert die vorstehenden Probleme, ist aber nur in neueren SAP-Releases verfügbar. Dieses Objekt schützt Tabellen, die keiner Tabellen-berechtigungsgruppe zugeordnet sind. Darüber hinaus wird dieses Objekt implizit bei einem Tabellenzugriff über die Transaktionen SE16 bzw. SM30/SM31 sowie bei der Verwendung des Funktionsbausteines VIEW_AUTHORITY_CHECK geprüft.

Das Objekt enthält die Felder TABLE und ACTVT, die die betreffende Tabelle sowie die intendierte Aktivität (z.B. schreiben) spezifiziert.

2.2.2.4 RFC

Fehlende oder unzureichende Berechtigungsprüfungen sind insbesondere bei RFC-fähigen Funktionsbausteinen ein Sicherheitsrisiko. Das Berechtigungsobjekt S_RFC kontrolliert den grundlegenden Zugriff auf einen RFC-fähigen Funktionsbaustein.

Dieses Objekt ist auch ein gutes Beispiel anhand dessen eine Problematik in der Analyse von Berechtigungen verdeutlicht werden kann. Das Objekt besitzt die Felder ACTVT, RFC_TYPE und RFC_NAME. Das Feld ACTVT kann derzeit lediglich den Wert 16 (Ausführen) annehmen. Das Feld RFC_TYPE spezifiziert, ob es sich bei dem Wert in RFC_NAME um einen einzelnen Funktionsbaustein (FUNC) oder um eine logische Gruppierung von einem oder mehreren Funktionsbausteinen (FUGR) handelt.

Eine mögliche Berechtigungsprüfung könnte also wie folgt aussehen: 

Da das Feld ACTVT lediglich einen einzigen Wert annehmen kann, das System aber die Verwendung von Wildcards unterstützt, ist ACTVT=16 äquivalent zu ACTVT=*. Eine uneingeschränkte Berechtigung auf das Objekt S_RFC muss also nicht ausschließlich Wildcards enthalten. Dies ist ein generell bei allen Berechtigungsobjekten zu beachten, die mindestens ein Feld beinhalten, das lediglich einen einzelnen Wert annehmen kann.

Im Rahmen einer Sicherheitsanalyse stellt sich häufig die Frage, welche bzw. wie viele Benutzer eine durch eine – wie vorstehend beispielhaft abgebildete – Berechtigungsprüfung gesicherte Funktionalität ausführen können. Wie bereits ausgeführt, können innerhalb eines Berechtigungs-objektes Wildcards verwendet werden.

Um also alle Benutzer zu identifizieren, die das Objekt S_RFC in einer Ausprägung besitzen, die die obige Berechtigungsprüfung erfolgreich bestehen wird, sind die folgenden Randbedingungen zu prüfen:

• Feld ACTVT mit Wert 16 oder *

• Feld RFC_TYPE mit FUGR oder *

• Feld RFC_NAME mit FUGR oder * 

Dies kann beispielsweise über die Transaktion RSUSR002 geschehen. Hierbei ist jedoch zu beachten, dass in der Regel alle Reports nur auf den Daten des aktuellen Mandanten operieren. D.h. um mandantenübergreifend alle Benutzer mit einer bestimmten Berechtigung zu identifizieren ist es notwendig, diese Prüfung in allen Mandanten individuell auszuführen.

Unter Umständen kann diese sehr zeitintensive Prüfung jedoch vereinfacht werden, wenn mindestens in einem Mandanten Zugriff auf die Transaktion DBACOCKPIT besteht. Hierüber ist es möglich, mit geeigneten SQL-Statements mandantenübergreifend die Berechtigungen aller im System vorhandenen Benutzer zu analysieren. Der Zugriff auf diese Transaktion kann im Allgemeinen jedoch nicht vorausgesetzt werden.

2.2.2.5 Grenzen und Herausforderungen

Die Erfahrung zeigt, dass die Berechtigungen eines Benutzers innerhalb eines SAP-Systems über die Zeit grundsätzlich dazu neigen zu wachsen. Der Grund hierfür sind in der Regel Defizite in den organisatorischen Kontrollprozessen. Beispielsweise werden bei dem Wechsel des Benutzers auf eine andere Planstelle innerhalb der Organisationseinheit diesem die für diese Planstelle vorgesehenen Berechtigungen zugeordnet, aber es existiert kein Prozess zum regelmäßigen Review benötigter Berechtigungen.

Ein weiteres Problem ergibt sich in Szenarien, in denen der Betrieb der Systeme ganz oder Teilweise an einen externen Dienstleister ausgelagert wurde. In diesen Szenarien hat der externe Dienstleister für Gewöhnlich lediglich Zugriff auf den Mandanten 000. Innerhalb dessen ist jedoch davon auszugehen, dass SAP_ALL verwendet wird, oder zumindest der Zugriff hierauf mit geringem Aufwand beschafft werden kann. Wie wir gesehen haben, ist mit diesen Berechtigungen der mandantenübergreifende Zugriff auf alle Daten des Systems möglich. 

Gerade Systeme die von einem externen Dienstleister betrieben werden, können im Rahmen der Sicherheitsanalyse problematisch sein. Oftmals wird der Dienstleister nicht bereit sein, Zugriff auf den Mandanten 000 zu gewähren, so dass nicht alle notwendigen Prüfungen in der gebotenen Tiefe durchgeführt werden können. Wird auf externe Dienstleister zurückgegriffen, ist es daher wichtig sich ein uneingeschränktes Prüfrecht des oder der Systeme inklusive aller Mandanten in einem SLA einräumen zu lassen.

Die Mandantentrennung wird – in mandantenspezifischen Tabellen – über die Tabellenspalte MANDT realisiert, die die dreistellige Mandantennummer enthält. Bei einer Datenabfrage aus einer oder mehreren Tabellen wird das notwendige SQL-Statement durch das SAP-System implizit durch die Anweisung WHERE MANDT = <nnn> erweitert, wobei <nnn> die Nummer des Mandanten ist in dem der Benutzer, der die fragliche Anfrage veranlasst hat, angemeldet ist.

Die implizite Mandantentrennung kann jedoch über die spezielle ABAP-Anweisung CLIENT SPECIFIED aufgehoben werden. Diese Anweisung erlaubt die explizite Angabe eines Mandanten innerhalb eines OpenSQL-Statements.

Aus dem Prinzip der Mandantentrennung ergibt sich ein grundlegendes Problem in der Sicherheitsanalyse von SAP-Systemen. Sind dem Auditor keine ausreichenden Berechtigungen eingeräumt, so kann dieser entweder nur unvollständig prüfen oder muss in jedem Mandanten einen Benutzer haben.

2.2.2.6 Zusammenfassung

Zusammenfassend ergeben sich die folgenden Herausforderungen bzw. Prüfpunkte beim Design, der Implementation sowie der Analyse von Berechtigungen:

• Organisatorisch

o Ein Berechtigungskonzept muss vorhanden sein.

o Technische Berechtigungen müssen das beabsichtigte Berechtigungskonzept exakt umsetzen.

• Technisch

o Verwendung eines eigenentwickelten „Berechtigungsmechanismus“ anstatt des vorhandenen.

o Prüfung statischer Werte wenn die zu prüfende Berechtigung dynamisch sein kann.

o Prüfung auf den Wert DUMMY.

o Keine Prüfung des Rückgabewertes von authority-check.

o Benutzer mit SAP_ALL oder anderen kritischen Profilen.

o Benutzer mit S_DEVELOP/*.

o Verwendung des CLIENT SPECIFIED-Statements im ABAP-Code des Systems.

2.2.3 RFC

Ein zentraler Punkt in der Vernetzung von SAP-Systemen auf Anwendungsebene ist die RFC-Schnittstelle. Diese SAP-spezifische Implementation des Remote-Procedure-Call-Konzepts ermöglicht über das gleichnamige RFC-Protokoll die systemübergreifende Bereitstellung von Diensten und Funktionalitäten. Hierbei müssen nicht zwingend SAP-Systeme miteinander kommunizieren. Über von SAP zur Verfügung gestellte RFC-Bibliotheken können auch Nicht-SAP-Systeme per RFC kommunizieren.

Um per RFC bereitgestellte Funktionalität nutzen zu können, müssen die Endpunkte der RFC-Kommunikation, die sog. Destinationen, im Ausgangssystem konfiguriert werden. Da ein SAP-System grundsätzlich keine anonymen Verbindungen zulässt, ist in jeder Destination die ohne Einwirkung eines Anwenders eingesetzt werden soll (z.B. zur Hintergrundverarbeitung) ein Benutzer zu konfigurieren, mit dem sich das rufende System authentifiziert. 

Aus der Natur der Sache ergibt sich, dass es somit nicht ohne weiteres möglich ist, zu identifizieren, von welchen Systemen aus RFC-Aufrufe in das zu prüfende System stattfinden. Diese Information ist jedoch vital in der Beurteilung des Sicherheitsniveaus des zu untersuchenden Systems. Sofern keine vollständige und aktuelle Übersicht über alle vorhandenen RFC-Kommunikationsbeziehungen vorhanden ist, kann an dieser Stelle keine abschließende Aussage über das Sicherheitsniveau der RFC-Schnittstelle getroffen werden. Im Rahmen des operativen Betriebs sowie des ISMS ist daher eine solche Kommunikationsmatrix zwingend erforderlich.

Das RFC-Protokoll kennt selbst keine Möglichkeiten der Absicherung auf Transportebene. Zur adäquaten Absicherung der RFC-Verbindungen sollten deshalb nach Möglichkeit alle RFC-Destinationen so konfiguriert werden, dass diese per SNC abgesichert werden.

Da die Kommunikation zwischen SAP-Systemen auch Trust-Boundaries überschreiten kann (z.B. Verbindung zwischen QA- und Produktivsystem), sollte bei der Konfiguration von RFC-Destinationen darauf geachtet werden, dass adäquate Sicherheitsmaßnahmen getroffen werden. Idealerweise sollte die RFC-Verbindung immer von dem System höherer Schutzstufe initialisiert werden. RFC-Verbindungen, insbesondere solche mit hinterlegten Zugangsdaten, aus einem System geringerer Schutzstufe in ein System höheren Schutzbedarfs sollte wenn überhaupt erst nach eingehender Analyse der damit verbundenen Risiken erstellt werden.

2.2.3.1 Benutzertypen in RFC-Destinationen

Bei der Verwendung von RFC-Destinationen ist darauf zu achten, dass für die Verbindungen die passenden Benutzertypen verwendet werden. Wie bereits dargestellt, existieren in SAP-Systemen unterschiedliche Benutzertypen, die jeweils einem Einsatzszenario entsprechen.

Der vorgesehene Benutzertyp für RFC-Kommunikation ist „Communication“. In der Praxis finden sich hier häufig Abweichungen mit schwerwiegenden Konsequenzen für die Sicherheit des entfernten SAP-Systems.

Über die Transaktion SM59 sind die im System vorhandenen RFC-Destinationen einsehbar. Diese Transaktion bietet unter anderem die Möglichkeit einen „Remote Login“ am entfernten Zielsystem durchzuführen. Aus diesem Grund sollten für RFC-Destinationen nur Benutzer vom Typ „Communication“ verwendet werden. Wird, wie in der Praxis immer wieder zu beobachten, ein Benutzer vom Typ „Dialog“ verwendet, so ist aus dem Quellsystem heraus per SAP GUI ein Absprung auf das Zielsystem unter der Identität und den Berechtigungen des in der Destination hinterlegten Benutzers möglich. 

2.2.3.2 RFC-fähige Funktionsbausteine

In der Standardinstallation enthält ein SAP-System je nach Release etwa 90.000 Funktions-bausteine wovon etwa 16.000 RFC-fähig sind. Ein Großteil der so angebotenen Funktionalität wird in der Regel entweder gar nicht oder zumindest nicht über RFC benötigt und daher auch nicht benutzt. Hierdurch ergibt sich bereits in der Grundinstallation eine sehr große Angriffsoberfläche.

Gerade in eigenentwickelten Funktionsbausteinen kommt es häufig vor, dass keine oder nicht ausreichende Berechtigungsprüfungen implementiert werden. Diese sind daher im Rahmen einer Sicherheitsanalyse eingehend auf die zur Verfügung gestellte Funktionalität, (nicht-)vorhandene Berechtigungsprüfungen und das sich daraus für das System ergebende Risiko zu analysieren.

Das grundlegende Berechtigungsobjekt anhand dessen der Zugriff auf RFC-fähige Funktions-bausteine festgemacht wird ist S_RFC. Hieran entscheidet sich jedoch lediglich der Zugriff. Alle notwendigen Berechtigungsprüfungen innerhalb des Funktionsbausteines müssen wiederum durch den Programmierer, den Vorgaben des Berechtigungskonzeptes entsprechend implementiert werden. Häufig kommt es jedoch vor, dass ein RFC-fähiger Baustein keine weiteren Berechti-gungsprüfungen implementiert, so dass lediglich die implizite Prüfung auf S_RFC durch das System durchgeführt wird. Die Überprüfung und Analyse RFC-fähiger Eigenentwicklungen ist daher ein integraler Bestandteil jeder Sicherheitsanalyse eines SAP-Systems.

Welche Möglichkeiten existieren nun, um die durch RFC-fähige Funktionsbausteine eröffnete Angriffsoberfläche einzuschränken? Bis vor einigen Jahren gab es hier keinerlei Möglichkeiten, die tatsächlich verwendeten Funktionsbausteine zu identifizieren.

Mittlerweile hat SAP mit dem Unified Connectivity Framework (UCON) diese Möglichkeit geschaffen. UCON ist eine zusätzliche Schicht in der Zugriffskontrolle auf RFC-fähige Bausteine, die unabhängig von etwaigen Berechtigungsprüfungen operiert. Mittels UCON können automatisiert diejenigen Bausteine erkannt werden, die tatsächlich per RFC aufgerufen werden.

• Logging: In dieser Phase werden Daten über RFC-Aufrufe gesammelt, ohne in deren Ausführung einzugreifen. Alle RFC-Aufrufe werden erlaubt und aufgerufene Bausteine in einer Whitelist eingetragen

• Auswertung: In dieser Phase werden weiterhin alle RFC-Aufrufe zugelassen. Aufrufe von nicht in der Whitelist vorhandenen Funktionsbausteinen erzeugen jedoch einen Alarm.

• Laufzeit: Alle Aufrufe von nicht in der Whitelist vorhandenen Funktionsbausteinen werden unterbunden.

Beim Einsatz von UCON ist darauf zu achten, dass auch geringfrequente Geschäftsprozesse, wie beispielsweise Quartals- und Jahresabschluss in die Datensammelphase mit einbezogen werden sollten. Andernfalls drohen Störungen der betreffenden Geschäftsprozesse in kritischen Phasen des Geschäftsjahres.

2.2.3.3 Zusammenfassung

Zur angemessenen Absicherung der RFC-Schnittstelle sollten mindestens die folgenden Tätigkeiten durchgeführt werden:

• Identifikation aller „eingehenden“ RFC-Benutzer und Analyse ihrer Berechtigungen in Hinblick auf die Einhaltung des Principle-of-Least-Privilege. Ebenso sicherstellen, dass der korrekte Benutzertyp verwendet wird.

• Identifikation von Benutzern mit uneingeschränkten RFC-Berechtigungen. Analyse der Notwendigkeit dieser Berechtigungen und ggf. Anpassung entsprechend dem Principle-of-Least-Privilege.

• Analyse RFC-fähiger Bausteine in den Kunden-Namensräumen. Hier finden sich häufig unzureichende oder fehlende Berechtigungsprüfungen mit potentiell gravierenden Auswirkungen auf das Gesamtsystem.

• Verwendung von UCON zur granularen Kontrolle von RFC-Aufrufen. 

2.3 Sicherheit in der Anwendungsentwicklung

Zum Schluss wollen wir uns in diesem Abschnitt mit der Sicherheit in der Anwendungsentwicklung auf SAP-Systemen befassen. Exemplarisch werden wir hier einige in der Praxis häufig auftretende Schwachstellen in der ABAP-Programmierung demonstrieren.

2.3.1 Umgehen des Berechtigungskonzeptes

Die Einhaltung des Berechtigungskonzeptes ist ein integraler Bestandteil der Sicherheit eines SAP-Systems.

Die Laufzeitvariable sy-uname enthält den Namen des aktuell angemeldeten Benutzers. Infolge dessen kann der Programmfluss anstatt von den Berechtigungen vom Benutzernamen abhängig gemacht werden:

Dieses einfache Statement dürfte noch von den meisten Codescannern gefunden werden und ist auch in einer manuellen Codeanalyse einfach zu identifizieren. Es ist jedoch ein leichtes, den Code durch Indirektionen komplexer zu gestalten und so die Chancen auf eine Identifizierung zu verringern:

Der Kreativität sind an dieser Stelle keine Grenzen gesetzt. Es ist evident, dass solche Statements niemals zufällig auftreten dürften. In der Regel wusste der Programmierer exakt um die Wirkung. 

In vielen in der Praxis aufgetretenen Fällen, war der Hintergrund weniger bösartig sondern schlicht Bequemlichkeit. Der Programmierer hatte keine Lust aufwändig eine Berechti-gungsprüfung, ggf. noch mit individuellem Berechtigungsobjekt zu erstellen und in das Berechtigungskonzept zu integrieren. Daher finden sich diese „Berechtigungsprüfungen“ häufig in administrativ genutztem Code und weniger im Code der abgebildeten Geschäftsprozesse.

Allen naheliegenden Gründen zum Trotz ist das Auftreten eines an den Benutzernamen gekoppelten Programmflusses in jedem Fall eine gravierende Feststellung, die umgehend behoben werden sollte.

2.3.2 Command Injection

Eine Command Injection kann auftreten, wenn Eingaben des Benutzers nicht oder nicht hinreichend geprüft an das unterliegende Betriebssystem weitergereicht werden. In einem SAP-System existieren verschiedene Möglichkeiten einen Betriebssystemaufruf auszulösen. Alle diese Möglichkeiten sind vorgesehene und dokumentierte Features in ABAP jedoch können diese offensichtlich missbraucht werden.

Das ABAP-Statement CALL ‚SYSTEM‘ ist grundsätzlich anfällig für Command Injection. Dieses Statement löst einen Aufruf des SAP-Kernels auf, der die übergebenen Argumente direkt und ohne weitere Behandlung an das unterliegende Betriebssystem durchreicht. Von der Verwendung von CALL ‚SYSTEM‘ wird daher durch SAP selber explizit abgeraten.

Betrachten wir beispielhaft den folgenden ABAP-Code:

Der Programmierer möchte hier das Programm ping aufrufen und einen einzelne ICMP-Request an ein entferntes System senden. Hierzu hat er die Möglichkeit vorgehsehen in die Variable lv_param den Hostnamen bzw. die IP-Adresse des Systems einzutragen. Der Inhalt dieser Variable wird z.B. in einer Eingabemaske durch den Benutzer gesetzt.

Die implizit angenommene Vorgehensweise des Benutzers wäre hier eine IP-Adresse oder einen Hostnamen einzutragen. In diesem Falle ergäbe sich bspw. bei der Eingabe von 8.8.8.8 für die Variable lv_cmd der Inhalt ping –c 1 8.8.8.8. Ebenso einfach ließe sich aber die Schwachstelle ausnutzen um beispielsweise an den Inhalt der Datei /etc/passwd zu gelangen. Hierzu gibt der Benutzer beispielsweise 8.8.8.8||cat /etc/passwd ein, woraus sich für die Variable lv_cmd der Inhalt ping –c 1 8.8.8.8||cat /etc/passwd ergibt. Es würde also zunächst der ICMP-Request geschickt und danach auf die gewünschte Datei zugegriffen.

Die Verfügbarkeit dieser Funktionalität kann über den Konfigurationsparameter rdisp/call_system gesteuert werden. Seiteneffekte sind hierbei jedoch nicht ausgeschlossen, worauf SAP wiederum explizit hinweist. In der Praxis wird dieser Parameter daher kaum verwendet.

Zur Vermeidung von Command Injections sollten die folgenden Maßnahmen eingehalten werden:

• Keine Verwendung von CALL ‚SYSTEM‘.

• Sind Aufrufe an das Betriebssystem nötig, so sollten diese über die SXPG* Funktionsbausteine erfolgen, z.B. SXPG_CALL_SYSTEM oder SXPG_COMMAND_EXECUTE.

2.3.3 Dynamisches SQL

Zur Interaktion mit der unterliegenden Datenbank wird in ABAP Open SQL verwendet. Diese proprietäre SQL-Implementierung dient der Abstraktion von der unterliegenden Datenbank über eine vereinheitlichte Sprache ohne auf Spezifika der genutzten Datenbank eingehen zu müssen.

Daher finden sich im Programmcode jedes SAP-Systems naturgemäß eine Vielzahl von SQL-Statements. Diese unterscheiden sich primär in sogenanntes „statisches“ und „dynamisches“ Open SQL. Statisches SQL wird intern in Prepared Statements umgewandelt. Hierdurch ergibt sich eine angemessene Trennung des SQL-Statements von den benutzerspezifizierten Daten:

Dynamisches SQL hingegen interpretiert Zeichen oder Zeichenketten als Teil des SQL-Statements. Eine adäquate Trennung des Statements von den benutzerspezifizierten Daten findet nicht mehr statt und macht eine Modifikation des SQL-Statements möglich:

Wird dynamisches SQL verwendet, so kann der betreffende Code mehrere potentielle Schwachstellen enthalten:

• Manipulation der WHERE-Bedingung

• Manipulation der SET-Bedingung in einem UPDATE-Statement

• Unberechtigter Lesezugriff auf eine Tabelle oder Spalten einer Tabelle.

Wo immer möglich sollten also statische SQL-Statements verwendet werden. Es liegt in der Natur der Sache, dass sich dynamische SQL-Statements nicht immer vermeiden lassen. In diesem Fall sollten die durch SAP bereitgestellten Mechanismen zum Prüfen und Bereinigen von Zeichenketten genutzt werden, wie sie beispielsweise die Klasse CL_ABAP_DYN_PRG bietet.

2.3.4 Zusammenfassung

Für die Sicherheit in der Anwendungsentwicklung sollten die mindestens folgenden Grundregeln eingehalten werden:

• So weit wie möglich Vermeidung dynamischer SQL-Statements.

• Keine Verwendung von CALL SYSTEM.

• Keine Verwendung von EXEC SQL.

• Keine Umgehung des Berechtigungskonzeptes durch Verwendung fest kodierter Benutzernamen.

• Verwendung adäquater Escaping-Mechanismen zur Bereinigung von Benutzereingaben und der Verhinderung von Injection-Schwachstellen jedweder Art.

• Verwendung angemessener und korrekter Berechtigungsprüfungen.

Die vorgenannten Aspekte sollten im Rahmen eines übergeordneten Software-Development-Lifecycles (SDLC) betrachtet werden, so dass eine gleichbleibende Codequalität gewährleistet und mithin die Sicherheit des Systems bzw. der gesamten SAP-Landschaft gewährleistet wird.

Ebenso empfiehlt sich der Einsatz eines automatisierten Codescanners zur Identifikation potentiell kritischen Codes. Insbesondere sollte ein Codescan vor jeder Freigabe eines Transportauftrages durchgeführt werden. Zur Durchführung von Codescans existiert mit dem SAP Code Inspector (Transaktion SCI) ein Bordmittel, es stehen jedoch am Markt auch Produkte von Drittherstellern zur Verfügung.

Im Rahmen des SDLC sollte ebenfalls eine Programmierrichtlinie erstellt werden, die genaue Vorgaben hinsichtlich der sicheren Programmierung enthält und die für die Programmierung verbindlich ist.

3 Fazit

Wie wir gesehen haben, weisen SAP-Systeme sowohl intern als auch hinsichtlich des Zusammenspiels mit weiteren Systemen einen hohen Komplexitätsgrad auf. Der vorstehende Text konnte daher lediglich die grundlegendsten Aspekte der Sicherheit eines SAP-Systems aufzeigen. Nicht zuletzt ist es diese Komplexität, die die adäquate Absicherung eines SAP-Systems zu einer nicht-trivialen Herausforderung macht.

Abschließend fassen wir die Kernaspekte der vorangegangenen Betrachtung zusammen. Diese sind jedoch nicht als vollständige Richtlinie anzusehen, sondern dienen primär als Anhaltspunkte für den tiefergehenden Einstieg in die Absicherung von SAP-Landschaften:

• Netzwerkseitige Absicherung

o Gateway, Message Server, WebDispatcher als Single-Point-of-Entry.

o Absicherung der RFC sowie der (hier nicht behandelten) ICM/ICF-Schnittstellen.

• Notfall- und Berechtigungskonzept, Privileged-Access-Management.

• Absicherung von Standardbenutzern.

• Sicherer Software-Development-Lifecycle.

Autor: Martin Monerjan, GAI NetConsult GmbH

4 Literatur

• Secure Configuration of SAP NetWeaver Application Server Using ABAP – SAP Securi-ty Recommendations, 2012. Verfügbar unter https://support.sap.com/content/dam/support/en_us/library/ssp/security-whitepapers/secure-config-netweaver-app-server-abap.pdf  

• Securing Remote Function Calls (RFC) – SAP Security Recommendations. SAP Though Leadership Paper, Christian Wippermann, 2014. Verfügbar unter https://support.sap.com/content/dam/support/en_us/library/ssp/security-whitepapers/securing_remote-function-calls.pdf 

Autor: Martin Monerjan