RFC gehört zu den leistungsfähigsten Ausführungswegen in einer SAP-Landschaft – und gleichzeitig zu den am wenigsten überwachten. Ein Benutzer, der sich über eine RFC-Verbindung authentifiziert hat und über die Berechtigung S_RFC verfügt, kann Funktionsbausteine aufrufen, die praktisch beliebige Datenbanktabellen lesen, Benutzerkonten erstellen oder ändern, Systemeinstellungen anpassen und Transaktionen ausführen können.
Viele dieser Aktivitäten tauchen in der Geschäftsprozessüberwachung, die SAP-Teams im Alltag nutzen, überhaupt nicht auf.
Wie streng die Berechtigungsprüfung eines einzelnen Funktionsbausteins ausfällt, hängt stark von seiner Implementierung ab. Manche Prüfungen sind sehr konsequent. Andere sind deutlich schwächer. Bei einigen bekannten Funktionsbausteinen findet bei einem Aufruf über RFC kaum eine relevante Berechtigungsprüfung statt.
Genau deshalb sind RFC-basierte Angriffe ein dokumentierter Angriffsvektor, der sowohl bei SAP-Penetrationstests als auch bei realen Sicherheitsvorfällen eine Rolle spielt.
Dieser Artikel zeigt, wie unautorisierte RFC-Aktivitäten in der Praxis aussehen, wo die relevanten Monitoring-Signale zu finden sind und was für eine Erkennung in Echtzeit erforderlich ist.
Warum die RFC-Angriffsfläche größer ist als vielfach angenommen
Was ein Remote Function Call tatsächlich ausführen kann
RFC_READ_TABLE ist das wohl bekannteste Beispiel, weil sich die Problematik daran sehr gut verdeutlichen lässt.
Der Funktionsbaustein ist RFC-fähig, allgemein bekannt und für legitime Datenaustausch-Szenarien vorgesehen. Er erhält einen Tabellennamen und Selektionskriterien und liefert anschließend die entsprechenden Tabelleninhalte zurück.
Die Berechtigungsprüfung erfolgt über S_TABU_DIS. Dieses Berechtigungsobjekt steuert den Tabellenzugriff anhand von Berechtigungsgruppen. In der Praxis sind S_TABU_DIS-Berechtigungen in vielen SAP-Systemen jedoch breiter vergeben als notwendig. Eine granulare Pflege der Tabellen-Berechtigungsgruppen ist aufwendig und wurde bei vielen Implementierungen nicht konsequent umgesetzt.
Authentifiziert sich ein Angreifer über RFC mit einem technischen Benutzer, der über S_RFC und ausreichend weitreichende S_TABU_DIS-Berechtigungen verfügt, kann er über eine Reihe von RFC_READ_TABLE-Aufrufen beispielsweise USR02 mit Passwort-Hashes, UST04 mit Benutzer-Profil-Zuordnungen, AGR_USERS mit Rollenzuordnungen oder RSECTAB mit sicherheitsrelevanten Konfigurationen auslesen.
Dafür ist kein Zugriff auf SAP GUI erforderlich. Ist das Security Audit Log nicht korrekt konfiguriert, entstehen zudem nur minimale Spuren in den Standard-Logs. Der gesamte Vorgang lässt sich automatisieren und innerhalb weniger Minuten durchführen.
RFC ermöglicht jedoch nicht nur das Auslesen von Daten, sondern auch die Ausführung von Aktionen.
BAPI_USER_CREATE1 kann SAP-Benutzer anlegen, sofern der aufrufende Benutzer über die erforderlichen Berechtigungen verfügt. SUSR_USER_CHANGE_PASSWORD_RFC kann Passwörter ändern. SXPG_COMMAND_EXECUTE kann Betriebssystembefehle ausführen, wenn der Benutzer S_RZL_ADM besitzt.
All diese Funktionsbausteine haben legitime Einsatzbereiche in Integrationsszenarien. In Kombination mit einem kompromittierten oder überprivilegierten Account machen sie RFC jedoch zu einer vollständigen Remote-Ausführungsplattform.
Die Berechtigungslücke bei RFC
Das SAP-Berechtigungsmodell wurde in erster Linie für Dialogbenutzer entwickelt, die über Menüs und Transaktionscodes im System arbeiten.
Kommt ein Aufruf dagegen über RFC, hängen die ausgeführten Berechtigungsprüfungen vollständig davon ab, welche Kontrollen der Entwickler des jeweiligen Funktionsbausteins implementiert hat. Es gibt keine übergeordnete RFC-Berechtigungsschicht, die automatisch dieselben Prüfungen wie bei einer vergleichbaren Transaktion erzwingt.
Das Berechtigungsobjekt S_RFC legt fest, welche RFC-Funktionsgruppen und Funktionsbausteine ein Benutzer oder eine Rolle remote aufrufen darf.
In der Praxis wird S_RFC jedoch häufig auf Ebene der Funktionsgruppe und nicht für einzelne Funktionsbausteine vergeben. Wird beispielsweise der Zugriff auf die Funktionsgruppe SDTX freigegeben, um einen bestimmten Funktionsbaustein nutzen zu können, können dadurch auch weitere RFC-fähige Funktionsbausteine dieser Gruppe zugänglich werden.
Die Folge: In vielen SAP-Landschaften sind RFC-Berechtigungsprofile breiter als ursprünglich beabsichtigt. Eine exakte Einschränkung setzt voraus, dass bekannt ist, welche Funktionsbausteine sich in welchen Gruppen befinden – und dass diese Zuordnung dauerhaft gepflegt wird.
Achtung: Das SAP-Berechtigungsprofil RFC_NO_AUTHORITY gewährt uneingeschränkten RFC-Zugriff auf sämtliche Funktionsbausteine und Funktionsgruppen. Es wird während Implementierungen gelegentlich Service-Accounts oder technischen RFC-Benutzern zugewiesen, um Probleme bei Verbindungstests zu umgehen. Bei einer Berechtigungsprüfung sollte dies als kritischer Befund behandelt werden. Ein Benutzer mit RFC_NO_AUTHORITY kann jeden RFC-fähigen Funktionsbaustein im System aufrufen und umgeht damit die S_RFC-Berechtigungsschicht vollständig.
Wie unautorisierte RFC-Aktivität aussieht
Reconnaissance: Tabellenzugriffe und Berechtigungsabfragen
Ein Angreifer, der ein SAP-System über RFC untersucht, folgt häufig einem erkennbaren Muster.
Zunächst wird geprüft, welche Ressourcen erreichbar sind: RFC_READ_TABLE-Aufrufe mit bekannten Tabellennamen, um den verfügbaren Berechtigungsumfang zu testen, Funktionsbausteine aus den Gruppen SYST und SYSTEM zum Abrufen von Systeminformationen sowie Aufrufe aus der Benutzerverwaltung, um herauszufinden, welche administrativen Funktionen verfügbar sind.
Werden diese Aufrufe abgewiesen, können RFC-Berechtigungsfehler im Systemlog entstehen. Sind sie erfolgreich, wird unter Umständen überhaupt kein auffälliges Ereignis erzeugt.
Der Unterschied zwischen Reconnaissance und legitimer Nutzung zeigt sich vor allem in der Kombination aus Vielfalt und zeitlicher Häufung der Aufrufe.
Eine legitime RFC-Integration verwendet üblicherweise immer wieder dieselbe Gruppe von Funktionsbausteinen und folgt einem vorhersehbaren Zeitplan.
Eine Reconnaissance-Sequenz ruft dagegen innerhalb kurzer Zeit zahlreiche unterschiedliche Funktionsbausteine auf – häufig von einem Quellsystem oder einer IP-Adresse, die mit keiner bekannten Integration verbunden ist.
Die große Bandbreite der aufgerufenen Funktionsbausteine und das Fehlen einer passenden konfigurierten RFC-Destination in SM59 sind zwei besonders aussagekräftige Signale, um Angriffsverhalten von normalem Integrationsverkehr zu unterscheiden.
Privilegienausweitung und Persistenz über RFC
Sobald ein Angreifer herausgefunden hat, welche Funktionsbausteine verfügbar sind, kann die Privilegienausweitung sehr direkt erfolgen.
Ist BAPI_USER_CREATE1 aufrufbar, lässt sich ein neuer Benutzer mit bekanntem Passwort anlegen. Ist SUSR_USER_CHANGE_PASSWORD_RFC für ein bestehendes hochprivilegiertes Konto nutzbar, kann dessen Passwort zurückgesetzt werden.
Erlauben die Vertrauensstellungen des Systems einen Trusted-RFC-Logon vom kompromittierten System aus, kann diese Verbindung außerdem genutzt werden, um ohne erneute Authentifizierung auf verbundene Systeme zuzugreifen.
Trusted RFC Connections verdienen deshalb besondere Aufmerksamkeit.
Ist ein System in SM59 als vertrauenswürdig definiert und die entsprechende Vertrauensbeziehung eingerichtet, können Benutzer des vertrauenswürdigen Systems sich am Zielsystem anmelden, ohne ein Passwort anzugeben. Die Benutzer-ID genügt.
Wird ein solches Quellsystem kompromittiert, kann sich ein Angreifer am Zielsystem als jeder dort existierende Benutzer anmelden – auch als administrativer Benutzer – ohne dessen Zugangsdaten zu kennen.
Das Authentifizierungsereignis selbst wirkt legitim, weil der zugrunde liegende Anmeldemechanismus legitim ist. Die eigentliche Anomalie liegt dann in der verwendeten Benutzer-ID und im aufrufenden System.
Wo sich die Monitoring-Daten befinden
Security Audit Log: Welche Events relevant sind
Das SAP Security Audit Log, erreichbar über die Transaktion SM20 beziehungsweise auf neueren Systemen über RSAU_READ_AUD_LOG, zeichnet sicherheitsrelevante Ereignisse auf, darunter auch RFC-spezifische Aktivitäten.
Für das RFC Security Monitoring sind vor allem die Ereignisklasse AU5 für RFC-Funktionsbausteinaufrufe bei entsprechend aktivierten Audit-Log-Einträgen sowie Berechtigungsfehler der Klasse AUB relevant.
Insbesondere protokolliert der Nachrichtentyp AUB mit dem Subtyp AUB0003 fehlgeschlagene RFC-Berechtigungsprüfungen. Solche Ereignisse können beispielsweise entstehen, wenn ein Angreifer testet, welche Funktionsbausteine zugänglich sind.
Das Security Audit Log ist nicht auf jedem System standardmäßig vollständig aktiviert.
Es muss in SM19 explizit konfiguriert werden. Dazu gehört unter anderem, welche Mandanten überwacht werden, welche Ereignisklassen erfasst werden und ob die Protokollierung für alle oder nur für bestimmte Benutzer gilt.
In vielen produktiven SAP-Systemen ist die Konfiguration nur teilweise umgesetzt: Dialog-Logons werden erfasst, RFC-Ereignisse hingegen nicht. Oder RFC-Ereignisse werden lediglich für einzelne Benutzer protokolliert.
Bevor eine darauf aufbauende Überwachung sinnvoll funktionieren kann, muss daher geprüft werden, ob die relevanten RFC-Ereignisklassen tatsächlich für alle Benutzer im Produktivmandanten aktiviert sind.
SM21 und RFC-Berechtigungsfehler als Frühwarnsignal
Das Systemlog in SM21 protokolliert Berechtigungsfehler unter anderem in der Nachrichtenklasse UC.
Scheitert ein RFC-Aufruf, weil dem Benutzer die erforderliche S_RFC-Berechtigung fehlt, wird ein UC-Eintrag erzeugt, der sowohl den Funktionsbaustein als auch den aufrufenden Benutzer enthält.
Diese UC-Meldungen sind gewissermaßen das Protokoll der fehlgeschlagenen Versuche: Sie zeigen, welche Funktionsbausteine ein Angreifer oder auch ein falsch konfiguriertes System aufzurufen versucht hat.
Eine Häufung von UC-Berechtigungsfehlern desselben Benutzers oder derselben RFC-Destination, verteilt auf mehrere unterschiedliche Funktionsbausteine innerhalb kurzer Zeit, ist eines der deutlichsten Echtzeit-Signale für aktive RFC-Reconnaissance.
In einem normal laufenden Produktivsystem sind RFC-Berechtigungsfehler vergleichsweise selten. Werden von derselben Quelle mehrere Dutzend S_RFC-Fehler pro Minute erzeugt, spricht dies daher stark für einen laufenden Probeversuch.
Die Schwachstelle liegt weniger in den verfügbaren Daten als in deren Nutzung.
SM21 ist in erster Linie ein Werkzeug zur nachträglichen Analyse und kein Alerting-System. Die Informationen sind vorhanden. Um einen Angriff während seines Ablaufs zu erkennen, braucht es entweder eine Monitoring-Plattform, die SM21 nahezu in Echtzeit ausliest und entsprechende Warnungen erzeugt, oder einen Administrator, der das Log entsprechend häufig manuell überprüft.
Hinweis: Wenn das SAP Security Audit Log so konfiguriert ist, dass es seine Daten in eine Datenbanktabelle statt in eine Datei schreibt, kann sich die Abfrageperformance verschlechtern, wenn diese Tabelle über Monate hinweg wächst. Um die Datenmenge zu reduzieren, schränken Administratoren teilweise den Audit-Umfang ein – und deaktivieren dabei unbeabsichtigt auch RFC-relevante Ereignisse. Prüfen Sie deshalb in SM19, ob die aktuelle Audit-Konfiguration tatsächlich dem gewünschten Sicherheitsniveau entspricht.
Was Echtzeit-RFC-Security-Monitoring erfordert
Sowohl das Security Audit Log als auch SM21 enthalten die entscheidenden Daten. Die grundlegende Einschränkung besteht darin, dass sie häufig erst im Nachhinein ausgewertet werden.
Eine Monitoring-Plattform, die diese Quellen alle paar Minuten abfragt, kann die Erkennungszeit von mehreren Stunden auf wenige Minuten reduzieren. RFC-basierte Angriffe können jedoch schneller ablaufen.
Die automatisierte Extraktion von USR02 über RFC_READ_TABLE kann in weniger als einer Minute abgeschlossen sein. Ein Erkennungszyklus von mehreren Minuten schlägt somit möglicherweise erst Alarm, nachdem die Daten bereits extrahiert wurden.
Eine echte Echtzeiterkennung für RFC-Sicherheitsereignisse erfordert deshalb eine kontinuierliche Erfassung des Security Audit Logs in Intervallen von weniger als einer Minute. Gleichzeitig müssen die Alarmregeln typische Muster unautorisierter Aktivitäten erkennen und dürfen sich nicht nur auf einzelne Ereignisse konzentrieren.
Folgende Muster sollten eine unmittelbare Reaktion auslösen:
- mehr als drei fehlgeschlagene S_RFC-Berechtigungsprüfungen innerhalb von 60 Sekunden durch denselben Benutzer oder dieselbe Quell-IP;
- jeder erfolgreiche Aufruf eines Funktionsbausteins zur Benutzerverwaltung wie BAPI_USER_CREATE1 oder SUSR_USER_CHANGE_PASSWORD_RFC von einer Quelle, die nicht zu den bekannten Integrationssystemen gehört;
- jede RFC-Session von einer IP-Adresse, die keiner konfigurierten SM59-Destination zugeordnet ist;
- Trusted-RFC-Logons von Quellsystemen zu Zeiten, zu denen keine legitime Integrationsaktivität erwartet wird.
Der Unterschied zwischen einer musterorientierten und einer rein schwellenwertbasierten Alarmierung ist hier entscheidend.
Ein Schwellenwert könnte beispielsweise einen Alarm auslösen, wenn mehr als 50 RFC-Fehler pro Stunde auftreten. Eine gezielte Attacke mit zwölf präzisen Aufrufen sensibler Funktionsbausteine von einem kompromittierten Account würde dadurch möglicherweise überhaupt nicht auffallen – insbesondere dann, wenn alle Aufrufe erfolgreich sind.
Eine musterbasierte Regel, die Aufrufe von Benutzerverwaltungsfunktionen aus unerwarteten Quellen erkennt, kann dagegen bereits beim zweiten entsprechenden Aufruf reagieren, unabhängig davon, ob der erste erfolgreich war oder nicht.
Die Liste der SM59-Destinationen bildet dabei die Baseline.
Jede RFC-Quelle, die im Security Audit Log auftaucht, sollte einer konfigurierten und dokumentierten RFC-Destination entsprechen. Aufrufe von Quellen außerhalb dieser Baseline sind per Definition Anomalien und sollten unmittelbar untersucht werden – unabhängig davon, ob dabei ein Berechtigungsfehler erzeugt wurde.
RFC-Sicherheit ist keine reine Konfigurationsaufgabe, die einmal erledigt und anschließend abgehakt werden kann.
Die Angriffsfläche ergibt sich aus dem Zusammenspiel von drei Faktoren: welche Funktionsbausteine RFC-fähig sind, welche Benutzer über S_RFC-Berechtigungen mit welchem Umfang verfügen und welche externen Systeme Netzwerkzugriff auf das SAP Gateway haben.
Alle drei Faktoren verändern sich mit der Zeit.
Neue Integrationen bringen neue RFC-Quellen mit sich. Berechtigungsprofile verändern sich. Systeme werden in Vertrauensbeziehungen aufgenommen, ohne dass die Auswirkungen immer vollständig dokumentiert werden.
Ein Monitoring, das RFC-Ereignisse kontinuierlich erfasst, ungewöhnliche Muster nahezu in Echtzeit sichtbar macht und bei Abweichungen vom bekannten Integrationsverkehr alarmiert, verwandelt RFC von einem weitgehend undurchsichtigen Ausführungsweg in eine überwachte und auditierbare Schicht.
Die Daten sind bereits vorhanden. Entscheidend ist, ob sie mit der Geschwindigkeit ausgewertet werden, die das Risiko erfordert.
Redpeaks überwacht Ereignisse aus dem SAP Security Audit Log sowie Berechtigungsfehler in den Systemlogs in Echtzeit. RFC-spezifische Alarmmuster helfen dabei, Reconnaissance-Aktivitäten und unerwartete Aufrufe von Funktionsbausteinen zur Benutzerverwaltung frühzeitig zu erkennen.
