Der SAP 5-Minuten Hack

Auf meinen letzten Beitrag „Anatomie eines Pen Tests“ habe ich viele Reaktionen bekommen – natürlich ist ein SAP Hack immer ein spannendes Thema. Und natürlich wollen jetzt alle wissen, wie der 5-Minuten Hack so funktioniert.

Gerne würde ich jetzt schreiben, wie viele Jahre Forschung und Entwicklung in solch einen Extrem-Hack eingeflossen sind, aber die Wirklichkeit ist viel trivialer, denn sie lebt von der Bequemlichkeit der Beteiligten.

Alles, was man dazu braucht, ist ein System mit SAPGUI-Zugang zum Opfer-System und einen Rechner mit NVIDIA CUDA Grafikkarte – möglichst viel Grafikkarte, denn je mehr Rechenkerne die Karte und das System haben, umso schneller geht es. Ich habe zu diesem Zweck immer mein „Atomkraftwerk“ dabei, einen MSI Gamer Laptop mit NVIDIA Quad-Grafikkarte und 64 GB Hauptspeicher sowie XEON-Prozessor. Das Teil rockt, auf diesem System habe ich bei Security-Schulungen immer mehrere SAP IDES Server laufen, mit Router und Web Dispatcher.

Aber eben auch zum Hacken von Passworten.

Also, Produktions-System auswählen und anstatt auf dem Produktiv-Mandanten anmelden auf dem Mandant 066 anmelden. Dieser Mandant war früher für Diagnosezwecke und Early Watch Zugänge von der SAP benutzt worden. Aktuell sollte dieser Mandant nicht mehr genutzt und daher gelöscht werden. (Siehe SAP Note 1749142)

Aber wie das so ist, vieles, was aus Gründen der Sicherheit gemacht werden sollte, wird aufgeschoben, vergessen oder ignoriert.

DIESER HACK HAT BEI 30% MEINER PENTESTS FUNKTIONIERT – und ich mache eine Menge Pen-Tests und Sicherheits-Überprüfungen

Bei weiteren 20% meiner Kunden war der Mandant noch existent, aber zu leicht abgesichert – hier hat es ein paar weiterer Hacks und externe Python-Skripts gebraucht, aber nach 2-4 Stunden war auch die Arbeit getan

Im Mandant 066 also folgende Passwörter ausprobieren:

Je älter das System, desto mehr Glück hat man bei diesen Default-Werten. Aber das ist ja eines der Wesen der Pen Tests: Man sucht das eine, verletzbare Glied einer Kette, um diese zu hacken. Und gerade in größeren Landschaften gibt es noch immer diese alten Systeme, auch als Produktiv-Systeme.

Da diese Benutzer alle hoch privilegiert sind, hat man mit aller Voraussicht SAP_ALL-Berechtigung mit Debug-Rechten.

Also, wenn man nun im System ist, (im Mandant 066), ruft man die Transaktion SE16N auf und springt in den berühmten „/H“ SAP-Hoppel-Mode (Debug Modus).

Dann ändert man die Variable GD-READ_CLNT auf den Wert „X“ (true) und hat in der Transaktion SE16N ein neues Feld, in dem man die anderen Mandanten-Tabellen abfragen kann. (Das beschreibe ich jetzt nicht im Detail, ein SAP Hacker sollte das schon wissen)

Jetzt kommt der klassische Angriff auf die Kronjuwelen:

Aus der Tabelle USR02 im Produktivmandanten werden jetzt die Hashes geklaut. Hier sind vor allem die technischen RFC-User interessant, die älter sind – oft viele Jahre, Diese haben mit Sicherheit sechsstellige oder achtstellige Passwörter (alte Schnittstellen) und vor allem haben die meisten SAP_ALL-Berechtigungen, denn früher kannte man noch keine Sicherheitsbedenken.

Dann das Programm CUDA_HASHCAT (https://hashcat.net) anwerfen, und mit der Kommandozeile

Hashcat64 -a 3 -m 7700 bcode.txt

Ausführen, wobei BCODE TXT die User enthalten muss im folgenden Format:

DEMO_ME$9248902E24CC98A8

Zuerst der SAP Benutzer (aus der Tabelle USR02), dann das $-Zeichen als Trennzeichen und dessen gehashtes Passwort (Feld BCODE)

Sechsstellige Passwörter werden in Sekunden gehasht, Achtstellige in einigen Minuten.

Natürlich gibt es zu dem Thema noch viel mehr zu sagen, dies sollte nur der „Proof-of-Concept“ sein, dass ein geübter SAP Hacker in wenigen Minuten diese paar Schritte machen kann.

Schamlose Schleichwerbung: In meinem Security-Buch steht das alles im Detail drin (Siehe Buchseite)

Und dann hat man seinen SAP_ALL Benutzer auf dem Produktivsystem. Kleiner Mandant, große Wirkung.

Das Gegenmittel? Alle nicht benötigten Mandanten löschen, alle Default-Passwörter ändern auf mindestens 12-Stellen , den SAP-Sicherheitshinweisen folgen und immer einen möglichst hohen Release-Stand mit den neuesten Kernel-Patches haben.