Ist eine Backdoor eine Tür zur Bäckerei? – Welche Logs helfen, wenn das SAP-System gehackt wurde?

Erinnern wir uns doch kurz was wir bisher bei der Mittelstand & Co GmbH erlebt haben. Da war der Sicherheitscheck mit brisanten Ergebnissen: SAP_ALL User gewürzt mit einer unbemerkten Backdoor im System. Zumindest haben die Ergebnisse des Sicherheitschecks dem Thema SAP-Sicherheit die Unterstützung des Managements verschafft. Das Budget für die in den Budgetverhandlungen vorgelegte Roadmap wurde nachträglich genehmigt. Aufgrund der Hintertür im System ist ein weiteres Thema in den Fokus gerückt: „SAP-Forensik“.

„Damit eine forensische Auswertung eines SAP-Systems erfolgen kann, muss der Analytiker zwingend wissen an welcher Stelle im System welche Sicherheitsrelevanten Ereignisse protokolliert werden. Ebenso muss er die Einschränkungen und Eigenschaften der jeweiligen Log-Daten kennen, um den Inhalt (oder eben den fehlenden Inhalt) korrekt in seine Untersuchung einfließen lassen zu können.

Weiterhin ist zu beachten, dass die meisten Logging-Mechanismen zunächst deaktiviert sind und erst noch zu aktiviveren sind. Es gilt also zu prüfen, welche Logs stehen überhaupt zur Verfügung und wo sind diese zu finden.“

Thomas Werth – Geschäftsführer werth IT

Was sind die ersten Schritte, wenn man etwas Verdächtiges bemerkt? Halten wir uns einfach an die Polizei, die sammelt doch ständig Beweise. Bei der Incident Response ist daher auch einer der ersten Schritte „Beweise sichern“. Im Fall von SAP bedeutet dies relevante Logs zu sichern. Jedoch sind diese Logs teilweise im Standard deaktiviert. Sie helfen also nur, wenn man sie VOR einem Vorfall manuell aktiviert hat.

Erstreaktion: Übersicht der Logs

Welche Logs sind denn im Fall der Falle konkret zu sichern und wo „wohnen“ diese?

Da man in kritischen Situationen ruhig und strukturiert vorgehen soll, sind wir an dieser Stelle ganz ordentlich und bringen die Logs in eine Tabellenform. Diese enthält Stichpunkte zu dem Namen, dem Speicherort und welche zusätzlichen Konfigurationsoptionen im Rahmen einer Auswertung zu beachten sind oder den Dateinamen/Speicherort spezifizieren.

LOGSPEICHERORTKONFIGURATION PRÜFEN
SECURITY AUDIT LOGusr/sap/<SID>/<instance>/log/audit_instance_nummerProfilparameter / Kernelparameter rsau/enable, rsau/local/file, rsau/max_diskspace_local, rsau/selection_slots,rsau/max_diskspace/per_file
SYSTEMLOG/usr/sap/<SID>/< instance>/log/SLOG<SYSNR>Profilparameter rslg/max_diskspace/local
GATEWAY LOG/usr/sap/<SID>/<instance>/work/Profilparameter gw/logging, gw/acl_mode, gw/acl_file, gw/sec_info, gw/reg_info  
ICM LOG/usr/sap/<SID>/<instance>/work/Profilparameter icm/security_log, icm/HTTP/logging_<xx>
J2EE LOG/usr/sap/<SID>/<instance>/j2ee/cluster/server<number>/log/ /usr/sap/<SID>/<instance>/j2ee/cluster/server<number>/log/system 
MESSAGE SERVER LOG/usr/sap/<SID>/<CentralInstance>/work/Profilparameter ms/audit, ms/conn_timeout
WEB MESSAGE SERVER/usr/sap/<SID>/<CentralInstance>/work/Profilparameter ms/http_logging, ms/HTTP/logging_<x>
ENQUEUE SERVER/usr/sap/<SID>/<CentralInstance>/work//usr/sap/<SID>/<instance>/work/Profilparameter enque/logging, enque/log_file
HANA/usr/sap/<sid>/<instance>/<host>/trace/*.ltc/usr/sap/<sid>/HDB<instance>/exe/hdbtracediag/usr/sap/<sid>/SYS/global/hdb/custom/config/global.ini/usr/sap/<sid>/HDB<inst>/<host>/nameserver.ini/usr/sap/<sid>/HDB<inst>/<host>/global.ini/usr/sap/<sid>/SYS/global/hdb/custom/config/nameserver.iniDB Audit Views CAUDIT_LOG, XSA_AUDIT_LOG

Parallel zu dem Sichern der Logs empfiehlt es sich externe Hilfe anzufordern. Dies ist eine Ausnahmesituation in der auf solche Fälle spezialisierte Personen übernehmen sollten. Also auf „sicheren“ Weg den Dienstleister zur Unterstützung kontaktieren und weitere Schritte (System-Isolation?) abstimmen. Sichere Kommunikation bedeutet hier nicht SSL, sondern einen Kommunikationsweg der sicher nicht von dem Cyber-Angriff betroffen ist. E-Mail ist hier nicht die erste Wahl.

„Ich brauche mehr Informationen!“

Die Checkliste für die Logs ist ideal um schnell die richtigen Logs zu finden und zu sichern. Doch was steht in diesen Logs? Was muss ich zusätzlich beachten? Lernen wir die wichtigsten Logs doch mal kennen.

SECURITY AUDIT LOG

Dieses Werkzeug zeichnet detailliert die Ereignisse im SAP-System auf. Die zu protokollierenden Ereignisse sind durch einen Admin zu konfigurieren. Die Ereignisse sind so zu wählen, dass folgende Daten aufgezeichnet werden:

  • Sicherheitsbezogene Änderungen an der SAP-Systemumgebung (z. B. Änderungen an Benutzerstammsätzen)
  • Informationen, die mehr Transparenz bieten (z. B. erfolgreiche und erfolglose Anmeldeversuche)
  • Informationen, die der Nachvollziehbarkeit einer Reihe von Ereignissen dienen (z. B. erfolgreiche oder erfolglose Transaktionsstarts)

ACHTUNG:

Das Security Audit Log ist im Standard nicht aktiv und ist manuell zu aktivieren!
Die Größe der Logdatei kann über den Profilparameter rsau/max_diskspace/local definiert werden. Der Vorschlagswert ist 1MB. Wird dieses Limit erreicht stoppt das Logging und erst mit dem nächsten Tag und einer neuen Logdatei wird wieder protokolliert!

Der Inhalt des Logs kann über die SAP-Transaktion SM20 eingesehen werden.

Jede Logmeldung verfügt über folgende Informationen:

•             Servername

•             Instanzname

•             Workprozess-Typ

•             SAP-Benutzer

•             Terminalname

•             Workprozessnummer

•             Transaktionscode

•             Programmname

•             Mandant

•             Meldungstext

•             Meldungsgruppe

•             Untergeordneter Name (wird zur Bestimmung der Meldungsgruppe verwendet)

•             Audit-Klasse

•             Sicherheitsstufe

•             Dateinummer

•             Adresse in Datei

•             Parameter, die für den Meldungstext verwendet werden

Damit lässt sich der genaue Zeitpunkt, der verursachende User und Quellcomputer sowie die protokollierte Aktion bestimmen.

SYSTEMLOG

Das Systemlog dient eigentlich der Fehlerkontrolle und ist automatisch aktiv. Die maximale Größe wird durch den Profilparameter rslg/max_diskspace/local bestimmt und liegt im Standard bei 1MB.  

Ein Eintrag beinhaltet immer Daten zu dem User, Clienten sowie der Aufgerufen Transaktion oder dem Programm und Details zu dem Fehler.

SAP-Gateway-Logging

Dieses Log überwacht die Aktivitäten des SAP-Gateways (Schnittstelle zu andern SAP-Systemen und Programmen).

Das SAP-Gateway-Logging ist per Default nicht aktiviert. Die maximale Größe richtet sich nach der Option MAXSIZEKB .

Sobald die maximale Dateigröße erreicht ist, wird eine neue Datei angelegt und das Logging läuft weiter. Es sei denn die Option FILEWRAP wird auf „on“ gesetzt, dann wird die vorhanden Logdatei einfach wieder geöffnet und überschrieben.

Der Zugriff auf die Loginhalte erfolgt im SAP-System über die Transaktion SMGW.

Das Gateway-Log liefert Informationen zu dem Datum und der Uhrzeit, dem Quellserver und der ausgeführten Aktion (Verbindung zu Server, Start Server, Register Server, usw.) .

Aus forensischer Sicht wird in den Log-Einträgen nach der Ausführung von Monitor-Befehlen, Änderungen in der Sicherheitskonfiguration sowie der Registrierung potentiell schädlicher RFC-Server oder dem Start kritischer RFC-Server gesucht.

ICM LOG

Das Security Log ist nur bei dem ICM standardmäßig aktiviert und liegt in dem Pfad

/usr/sap/<SID>/<INSTANCE>/work/dev_icm_sec .

Wie sich das Log verhalten soll, wenn das Limit erreicht ist, spezifiziert der Parameter FILEWRAP. Wird dieser Parameter auf on gesetzt, wird bei Erreichen der Maximalen Größe die Logdatei zurückgesetzt und neu geschrieben. Alle Logeinträge gehen verloren!

Dieses Log kann genutzt werden, um fehlgeschlagene Loginversuche an der Web Administration zu erfassen. Sowie HTTP Fuzzing Versuche aufzudecken.

Das Log bietet dabei die Informationen über Datum und Uhrzeit, der IP des Angreifers und Inhalt der Anfrage in Abhängigkeit des eingestellten Loglevels.

Neben dem Security Log existiert noch das HTTP Log. Dies ist nicht per Voreinstellung aktiv. Der Speicherort wird über den Parameter icm/HTTP/logging_XX  angegeben.

Wie bei dem Security Log wird die maximale Dateigröße durch den Parameter MAXSIZEKB und das Verhalten bei Erreichen der Grenze durch den Parameter FILEWRAP gesteuert

Das HTTP Log vermerkt spezifische Zugriffsereignisse wie Zugriffe ohne Authentifizierung (HTTP Code 401) oder Fuzzing Zugriff (HTTP Code 400). Generell wird auch der Zugriff auf kritische Webseiten hier protokolliert.

Das Log bietet dabei die Informationen über Datum und Uhrzeit, der IP des Angreifers, den angegebenen Benutzer zur Autorisierung, die HTTP Anfrage mit Parametern und Headern, den HTTP Antwort Code sowie den Inhalt der Anfrage in Abhängigkeit des eingestellten LOGFORMATes.

J2EE Logging

SAP Java Instanzen haben Standardmäßig das Logging aktiv. Dabei wird es im „simple mode“ betrieben, es werden also nur schwerwiegende Fehler und Ereignisse protokolliert, die sicherheitsrelevante und administrativen Tätigkeiten des Systems umfassen oder die Geschäftslogik betreffen.

Die Java Server-Logs beinhalten die Logdatei für die Responses. In dieser sieht man wann das System wie auf HTTP-Anfragen reagiert hat.

Finden sich in diesem Log „HEAD“ Anfragen, so können diese Einträge als Hinweise auf Verb Tampering Angriffe gesehen werden. Hier gilt es dann besonders gründlich die Angefragte URL mitsamt Ihren Parametern zu prüfen.

Ebenso lassen sich XSS Angriffe durch die Suche nach Schlüsselwörtern wie „%3C/script%3E“ identifizieren. Auch die berühmten Diretory-Traversal-Angriffe können hier aufgespürt werden. Eine Suche nach „/../“ oder „!252f..!252f“ kann hier als Ausgangspunkt verwendet werden.

Message Server Logging

Über den Parameter ms/audit kann die Protokollierung für den Message Server eingeschaltet werden. Mit dem Wert 1 werden An- und Abmeldungen protokolliert und der Wert 2 loggt auch Aktivierungen und Suspends eines Clients.

Welche weiteren Logs existieren in SAP?

Nicht alle Logs liegen als Dateien auf dem Betriebssystem vor. Es gibt weitere Logs, die bei der Untersuchung eines Incidents weiterhelfen können. Man weiß niemals auf was man als nächstes trifft. Die Änderungsprotokollierung kann helfen gewisse Aktionen im System besser nachvollziehen zu können. Es gibt 3 wichtige Änderungsprotokolle:

Änderungsprotokollierung von Tabellen

Die Tabellenprotokollierung ist im Standard nicht aktiv. Zur Aktivierung der Protokollierung im System selbst ist der Profilparameter rec/client auf ALL oder eine Komma-getrennte Liste der zu überwachenden Mandanten zu setzen. Zur Überwachung des Transportwesens muss der Wert r3transoptions = recclient=“XXX“ in das Transportprofil aufgenommen werden.

Die Protokolldaten werden in der Tabelle DBTABLOG hinterlegt und es existiert keine Obergrenze für die Datengröße. Die Logdaten können über die SAP-Transaktion SCU3 eingesehen werden.

Ein Logeintrag liefert Informationen zu dem Zeitpunkt, zu dem Benutzer und dem Applikations-Server auf dem die Änderung vorgenommen wurde sowie zu der Tabelle und den Feldwerten (alt und neu).

Änderungsprotokollierung von Benutzer und Berechtigungen

Ein SAP-System protokolliert Änderungen an Benutzer- und Berechtigungsdaten automatisch.

Die Logdaten werden in den USHXX Tabellen (wie USH02, USH04,…) unbegrenzt abgelegt. Die historischen Daten sind über den ABAP-Report RSUSR100N einsehbar.

In den Logdaten ist ersichtlich wann und von wem eine Änderung vorgenommen wurde. Ebenso welcher Benutzer von der Änderung betroffen ist und über welchen Programm oder Transaktion die Änderung erfolgt ist.
Direkte Änderungen von Benutzer auf Datenbankebene können von diesem Log nicht erfasst werden. Unter normalen Umständen sollte so etwas jedoch niemals vorkommen. Interessant ist hier unter anderem welche Benutzer SAP_ALL oder SAP_NEW Profile erhalten bzw. verloren haben.

Protokollierung Änderungsbelege

SAP-Systeme protokollieren Änderungen an betriebswirtschaftliche Objekten in Änderungsbelegen. Dies ist besonders wichtig für Objekte die kritisch sind oder der Revisionen unterliegen. Oft ist es sinnvoll oder sogar notwendig, solche Änderungen später nachvollziehen zu können, z. B. zu Revisionszwecken. 

Die Daten der Protokollierung werden in den Tabellen CDHDR und CDPOS abgelegt. Eine Limitierung für den Speicherplatz gibt es nicht. Der Zugriff auf die Daten erfolgt über den ABAP-Report RSSCD200.

In den Logs ist der Benutzername, das Datum der Änderung die genutzte Transaktion sowie die Art der Änderung und die Änderungsnummer des Belegs einsehbar.

Rückblick

Genehmigen wir uns einen kurzen Rückblick. Am Steuer der Mittelstand & Co GmbH haben wir wilde Gewässer überquert und letztlich den richtigen Kurs gesetzt. Zu Beginn musste zunächst geklärt werden was „SAP-Sicherheit“ eigentlich bedeutet und welches Budget man jeweils benötigt. Dieses Budget musste dann noch erkämpft und ein passender Anbieter gefunden werden. Die Ergebnisse des SAP-Sicherheitschecks haben für dezente Schreckmomente gesorgt, doch inzwischen ist bei allen die Farbe ins Gesicht zurückgekehrt. Inzwischen macht die Härtung der Systeme Fortschritte und der zusätzliche Aspekt „Incident Response“ wurde angegangen.

Die erste Etappe ist gemeistert und die Reise zum sicheren Betrieb der SAP-Systeme jetzt in Angriff genommen werden. Dieses Thema habe ich hier bereits vorgestellt. Somit warten in der nächsten Kolumne neue unbekannte Gewässer auf uns!