Da sind wir wieder bei unserem Nebenjob in der „Mittelstand & Co GmbH“. Wir haben Budget erkämpft und der SAP-Sicherheitscheck steht an. Es ist unser erster „SAP-Pentest“, was uns da wohl erwartet? Aus meiner persönlichen Erfahrung kann ich sagen, dass ein Pentest immer eine spannende Angelegenheit ist. Jeder Auftrag ist individuell mit seinen eigenen Herausforderungen.
„SAP-Penetrationstest sollten durch erfahrene Experten durchgeführt werden. Dies natürlich vor dem Hintergrund der Bedeutung der Systeme, ebenso sind gerade deshalb zuverlässige und ganzheitliche Aussagen durch einen Experten zu bewerkstelligen. Zur Durchfürung eines SAP-Pentest müssen dem Tester die typischen SAP Umgebungen und deren Schwachstellen sowie die Systemarchitektur und deren Security Architektur gut bekannt sein. Er muss zudem fähig sein den idealen Scope für den jeweiligen Kunden zu erkennen.“
Thomas Werth – Geschäftsführer werth IT
Im Vorfeld wurde bereits viel über das Thema SAP-Sicherheit diskutiert bis endlich die Roadmap stand und das Budget genehmigt wurde. Das große Ziel ist der sichere Betrieb der SAP-Systeme. Doch bevor man zu diesem Ziel aufbrechen kann, gilt es herauszufinden wo man aktuell steht. Dazu soll der Sicherheitscheck dienen. Welche Ergebnisse dieser bringt, kann niemand seriös keiner vorhersagen. In all den Jahren des SAP-Betriebs bei der Mittelstand & Co GmbH ist bisher nichts vorgefallen. Darf man Schlussfolgern, dass es maximal ein paar Schrammen, aber keinen Knock-Out im Pentest gibt?
Ziele des Sicherheitschecks
Unser klar formuliertes Ziel für die Vergabe eines Pentests ist die Identifizierung von Schwachstellen im System. Dies soll zur Transparenz von Risiken für das Unternehmen führen. Die Risikominderung soll durch die Systemhärtung erzielt werden, was langfristig durch die Maßnahmen für den sicheren Betrieb dauerhaft gewährleistet werden soll.
Wichtig ist insbesondere, dass die Ergebnisse verständlich und detailliert dargestellt werden, da für uns in der Rolle als IT-Leiter das Gebiet SAP-Sicherheit Neuland (ob wir dort Frau Merkel treffen?) ist und kaum Expertise im Unternehmen existiert.
Hilfreich wären für uns zu jeder ermittelten Schwachstelle eine Schritt für Schritt Anleitungen zur Behebung.
Ein kurzfristiges Ziel wird dann sein die Daten (Business, Kunden, Mitarbeiter) im System zu schützen, um auch regulatorischen Anforderungen (z.B. DSGVO) gerecht zu werden.
Vorbereitung durch Auftraggeber
Was ist eigentlich für einen „Security-Check“ vorzubereiten, damit der Auditor „arbeiten“ kann? Braucht der Tester einen Arbeitsplatz oder bewerfen wir ihn besser mit der Firewall-Hardware aus dem ersten Stock? Er muss diese ja „überwinden“ können.
Der Tester hat unsere Gedanken wohl erahnt und uns eine Checkliste zur Vorbereitung ausgehändigt. Kurzer Check: Firewall Weitwurf steht nicht drin. Schade!
Die Liste ist gut strukturiert und auf einen authentifizierten Scan ausgerichtet, damit der Tester fundierte Aussagen kann:
- Auf jedem SAP-System im Scope ist ein Audit-Benutzer mit einer mitgelieferten Berechtigungsrolle einzurichten.
- Zugänge mit spezifizierten Berechtigungen für Whitebox-Checks auf Betriebssystem- und Datenbankebene sind vorzubereiten.
- Einige Informationen zu den Zielsystemen und Administratoren werden benötigt
- Für eine Remote-Prüfung wird ein sicherer VPN-Zugang benötigt und ein kurzer Testlauf vor Projektbeginn.
Das klingt machbar, trotz der alltäglichen Arbeitspflichten. Schön, dass nicht mehr Aufwand nötig ist.
Der Benutzeradministrator übernimmt den Punkt Anlegen des Audit-User mitsamt einspielen der Berechtigungsrolle. Die IT-Administration erstellt die Zugangsdaten für OS- und DB-Zugriff. Das SAP-Team stellt die angeforderten Informationen (SID, IP, Mandant, Stack, OS- und DB-Typ) zusammen. Nur das VPN muss der Firewall-Dienstleister einrichten. Das dauert wieder: Ticket beantragen, Rückfragen, Zuständigkeiten, … Da planen wir besser gleich etwas mehr Zeit für diesen Punkt ein.
Am Ende zittern wir ein wenig ob der Dienstleister bis zum angesetzten Termin endlich das VPN aufbaut, doch intern hat die Vorbereitung keinen Stress verursacht. Es ist ganz angenehm, wenn keine aufwendigen Änderungen (wie Custom Code) in den SAP-Systemen durchgeführt werden müssen. So lief auch der produktive Betrieb ungestört fort.
Der Security Check
Es ist soweit, die Vorbereitungen sind abgeschlossen: Heute wird getestet und geprüft. Als IT-Leiter ist uns ein reibungsloser Betrieb wichtig. Der Tester hat versprochen „wir werden nichts merken“. Warum hat er dabei nur so komisch gegrinst? Zur Sicherheit beobachten wir den Workload des Systems mit der ST03N. Der Tester hat sich vor ein paar Stunden gemeldet und den Start des Tests bekannt gegeben. In den Statistiken ist bisher nichts Auffälliges und bisher hat noch kein Mitarbeiter etwas von einem laufenden Pentest bemerkt. Ob wir das als gutes Zeichen werten können? Jedenfalls haben wir uns die Berechtigungsrolle für den Tester genau angesehen. Dabei haben wir Festgestellt, dass auch höhere Privilegien angefordert wurden. Doch der Tester hat uns beruhigt. Das ist alles nur zur Erhebung des Ist-Status. Die erhaltenen Zugriffsrechte werden bei der Verifizierung potentieller Risiken komplett außer Acht gelassen. „Schummeln habe ich nicht nötig!“ hat er lachend gesagt. Was kommt da auf uns zu?
Was macht der Pentester?
Ich bin ja von Natur aus Neugierig und frage mich: „Was macht denn so ein Pentester in seinem stillen Kämmerlein?“ Wollen wir mal gemeinsam ein wenig zuschauen?
Der Tester startet mit dem authentifizierten Whiteboxscan. Der Vorgang dauert seine Zeit, doch parallel kann er schon die ersten Ergebnisse sichten. Der Tester hat viel Routine und arbeitet seine geistige Checkliste anhand der eintreffenden Test-Ergebnisse ab:
- Unsicheres SAP Gateway *OK*
- SAP Standard Zugangsdaten *OK*
- Patchstatus *OK*
- Ablauf Initialkennwörter *NIE*
- User mit Initialkennwort *MSCHULZ*
- Default Initialkennwort im Unternehmen *init,1234*
- FUN MODE *STARTING*
Bingo! Damit kann ein Pentester arbeiten. Der Zugang zum System steht. Welche Berechtigungen besitzt der übernommene Account? Die Antwort liefert eine schnelle Berechtigungssimulation mit seinem Audit-Werkzeug. Oh, schön! Debug mit Wertänderung ist in den Rollen des Users enthalten. Der Tester versteht sein Handwerk und 3,7 Sekunden später besitzt MSCHULZ das Profil SAP_ALL.
Es stehen jedoch noch weitere Prüfungen an, denn letztlich geht es bei einem Security Check nicht darum EINEN Weg in das System zu finden, sondern ALLE Risiken zu ermitteln. Lassen wir den Tester mit seiner Arbeit in Ruhe fortfahren.
Ende des Scans
Der Whiteboxscan lief ohne Auswirkungen auf den SAP-Betrieb durch. Der Tester sichtet die ermittelten Schwachstellen und bereitet den Abschlussbericht vor.
Damit wissen wir nun zumindest, es gibt etwas zu berichten. Welche Risiken hat der Tester wohl gefunden?
Gibt es Sicherheitsrisiken in dem Custom ABAP-Code?
Sind die RFC-Destinations zu dem BW-System sicher?
Welche Berechtigungen sind noch mal in unseren Standard-Rollen vergeben?
Ergebnisse
Endlich bekommen wir die Ergebnisse präsentiert.
Der Tester berichtet er hat SAP_ALL Zugriff erreicht. Der SAP_ALL Zugriff auf das System wurde Mehrstufig erreicht. Der Einstieg war möglich, da die Generierung der Initial-Kennwörter nicht sicher ist. Weil diese jedoch niemals ablaufen, konnte der Tester einen verwaisten User übernehmen. Als dritter Aspekt kamen dann zu weitreichende Berechtigungen in dessen Standard-Rollen zum Tragen und der Tester konnte so die Berechtigungsprüfungen in dem SAP-System umgehen und SAP_ALL erhalten.
Doch das ist nicht alles, es gibt da noch einen weiteren Punkt der zu untersuchen ist: Im ABAP Code wurde eine 8 Monate alte Backdoor gefunden. Diese erlaubt das Ausführen von Systembefehlen als <SID>Adm – ohne Protokollierung.
Insgesamt war die Abschlusspräsentation auf den Punkt gebracht. Die zusätzliche Dokumentation bestehend aus verschiedenen Zielgruppen orientierten Berichten enthält wertvolle Details und Anleitungen zur der Härtung der Systeme.
Insgesamt lief die Präsentation sehr anschaulich und die passenden Handlungsempfehlungen nehmen direkt den Schrecken.
Konzentrieren wir uns auf das Positive: Die Handlungsempfehlungen. Die Punkte „Ablauf Initialkennwörter“ und „Generierung Initialkennwörter“ lassen sich schnell abstellen. Die Anpassung der Berechtigungen wird eine größere Baustelle, da dort noch weitere Aspekte im Rahmen der Testergebnisse aufgefallen sind.
Die Backdoor im System ist da schon ein anderes Kaliber. Glückicherweise hat der Tester den Benutzernamen des Erstellers identifiziert und nach Rücksprache mit dem externen Berater ließ sich Sinn und Zweck dieser Pseudo-Shell zumindest Nachvollziehen. Der Report mit der Backdoor ist zwar schnell gelöscht, doch was, wenn das nicht so glimpflich ausgegangen wäre, wie läuft denn eine „Spurensuche“ im SAP-System“?
Ich finde das ist eine sehr gute Frage und denke der sollten wir im nächsten Beitrag nachgehen. Ob ich zur nächsten Kolumne meine Forensik-Lupe finden werde?
