Im dritten Teil der  Serie „Howto SAP Security“ (Teil 1 , Teil 2) steht die Datenbanksicherheit im Fokus.

Datenbanksicherheit bei SAP-Systemen

Obwohl HANA immer stärkere Verbreitung findet, ist weiterhin Oracle die meist genutzte SAP-Datenbank. Entsprechend liegt hier der Fokus auf Oracle Datenbanken . Dem Thema HANA widmen wir uns in einem späteren Post.

Kritische Daten

Zunächst ist zu verstehen, welche aus Sicht der Systemsicherheit kritischen Daten liegen in der Datenbank eines SAP-Systems?
Für einen Angreifer sind solche Daten von Interesse, die ihm helfen in das System einzudringen.
Generell liegen die SAP bezogenen Daten oftmals in einem Datenbankschema mit dem Namen SAPR3 oder SAP<SID>.

Für einen Angreifer besonders interessant sind folgende Tabellen:

Zuerst ist die Tabelle USR02 zu nennen. Hier sind alle Benutzer des Systems inklusive Passworthashes zu finden. Passwortcracker wie John oder Hashcat können diese Hashes in Klartextpasswörter überführen.

Als zweites folgt die Tabelle SSF_PSE_D. Hier sind Sicherheitszertifikate (PSE) gespeichert. Erhält ein Angreifer darauf Zugriff, kann er beispielsweise SSO-Tickets für ein Login verwenden.

Zuletzt sei noch die Tabelle UST04 zu nennen. Hat ein Angreifer schreibenden Zugriff auf die Daten, kann er hier beliebigen Benutzern SAP_ALL zuweisen .

Angriffe auf die Datenbank

In der Regel lauscht die Oracle Datenbank auf Port 1527 auf eingehende Verbindungen.

Zu den häufigsten Angriffsursachen zählt die Nutzung von Standardzugangsdaten. Dies gilt auch bei Datenbanken.

Für SAP gibt es diesen Standarduser

Benutzer „SAPR3“ mit dem Passwort „SAP“ .

Es gibt aber auch Oracle Standardbenutzer:

• SYS | CHANGE_ON_INSTALL
• SYSTEM | MANAGER
• SCOTT | TIGER
• DBSNMP | DBSNMP

Bei Oracle gibt es noch eine zweite Besonderheit. In der Konfiguration kann die REMOTE OS Authentifizierung (REMOTE_OS_AUTHENT) aktiviert werden. Ist diese aktiv, so überlässt Oracle die Authentifizierung des Benutzers dem entfernten Betriebssystem des Klienten.

Ein Angreifer kann diesen Umstand ausnutzen, indem er einfach auf seinem System einen Benutzer mit dem Namen <SID>ADM (oder mit einem anderen DB-User) anlegt und mit diesem eine Verbindung zur Datenbank aufbaut. Oracle lässt diesen Benutzer nun ohne Passwort rein, da es die Authentizitätsprüfung des Benutzers dem Betriebssystem des Angreifers überlässt.

Angriff auf die SAP Zugangsdaten in Oracle

Der zuvor genannten Umstand der Remote Authentication ermöglicht es auch die Zugangsdaten des SAPR3 Benutzers in Erfahrung zu bringen.

Dazu kann man einen Benutzer mit dem Schema OPS$<SID>ADM oder OPS$SR3ADM (je nach Version) anlegen. Dann verbindet man sich mit der Datenbank.

Nun kann man aus der SAPUSER Tabelle die verschlüsselten Passwörter auslesen. Diese sind mit DES und dem Schlüssel „BE_HAPPY“ zu dekodieren. Dann kann mit diesem Passwort und einem der Benutzernamen SAPR3, SAPSR3 oder SAPSR3DB eine Verbindung zur Datenbank aufgebaut werden.

Hier ist es dann möglich die Daten der Tabelle USR02 aus dem Schema SAPR3 oder SAP<SID> auszulesen. Die dort geladenen Hashes lassen sich dann mit Hashcat oder John knacken.

Die Datenbanksicherheit erhöhen

Zum Schutz vor den genannten Angriffen sind einige Maßnahmen möglich.

Zunächst sollte der Port 1527 nur für das SAP-System erreichbar sein. Der Zugriff auf die Datenbank sollte nur mit Authentifizierung möglich sein und diese ist von der Datenbank selbst vorzunehmen.

In den Passwortrichtlinien sind beschränkende Werte für Fehlanmeldungen (FAILED_LOGIN_ATTEMPTS) zu setzen. Ebenso sollten Passwörter einer gewissen Komplexität entsprechen. Dies ist in der PASSWORD_VERIFY_FUNCTION einzupflegen.

Nur Systeme in der Whitelist dürfen sich mit der Datenbank verbinden (tcp.validnode_checking=true und tcp.invited_nodes= (<ip>,…).

Weiterhin sind Standard-Zugangsdaten abzuändern. Letztlich sollte die Datenbank verschlüsselt kommunizieren und das Auditing in der Datenbank aktiviert sein.