Sicherer Betrieb von SAP-Systemen Schwachstellen in der SAP-Landschaft

Anbieter zum Thema

Pathlock Deutschland | akquinet enterprise solutions GmbH

Specops Software GmbH

Wenn Unternehmen einmal jährlich ihre SAP-Lösung checken lassen und am Ende das erfolgreiche Testat durch die Wirtschafts­prüfungs­gesellschaft steht, dürfen sie davon ausgehen, dass das ERP-System ordnungsgemäß und sicher funktioniert. Vor allem, wenn zusätzlich noch ein Security Audit oder Penetrationstest über die produktiven SAP-Systeme absolviert und bestanden wurde. Bis das böse Erwachen kommt.

Nach erfolgreichen Sicherheitsprüfungen ist der Schock umso größer, wenn trotz alldem ein Angreifer das hochsichere System kapert und das Security-Monitoring Alarm schlägt. Wie kann das geschehen? Die Antwort: Der Prüfer hat eben nicht alle Q- und Dev-Systeme der SAP-Landschaft im Blick, den Solution Manager, Legacy-Systeme und die Clients der Anwender. Jede Fehlkonfiguration an diesen Stellen kann letzten Endes dazu führen, dass ein als sicher eingestuftes System dennoch kompromittiert wird. Seitenangriffe auf kritische Systeme sind immer möglich, wenn der Überblick darüber fehlt, wie die Systeme untereinander kommunizieren, welcher User auf welche Systeme zugreifen darf und welche Clients mit welchen Servern sprechen.

Drei beispielhafte Szenarien veranschaulichen, auf welche Art und Weise sich Kriminelle umfassenden Zugriff verschaffen können.

Angriffe über den Arbeitsplatz des SAP-User

Ob (Spear-) Phishing, Ransomware, APT-Kampagnen oder die nächste Welle an Schadprogrammen wie WannaCry – in Unternehmen geschieht es immer wieder, dass Client-PCs trotz aller Schutzmaßnahmen (Antivirus-Programm, Firewall) gekapert und ferngesteuert werden. Haben Angreifer erstmal die Kontrolle über einen Client, wird der Zugriff schnell auf weitere Clients ausgedehnt (lateral movement). Dabei ist es nur eine Frage der Zeit, wann ein Angreifer den Client eines SAP Basis- oder Benutzer-Admins kontrolliert. Bei all den ausgefeilten Angriffen auf Windows-Systemen und auf den Menschen davor ist es wesentlich leichter, hier Zugriff zu erlangen als direkt das SAP-System anzugreifen.

Viele Unternehmen gehen inzwischen den Schritt und nutzen Single-Sign-On zur Authentifizierung, um Passwörter zu eliminieren. Ohne Zwei-Faktor-Authentifizierung eignet sich SSO jedoch sehr gut als Türöffner zu SAP. Solange sich der Angreifer im Kontext des SAP-Admins auf dessen PC bewegt, wickelt der SSO-Mechanismus im Hintergrund die Authentifizierung ab und der Angreifer kann direkt und ohne weitere Mühen im Kontext des Admins auch auf das SAP-System zugreifen. Dafür genügen ihm schon ein paar Powershell-Skripte und eine RFC-Verbindung zum SAP-System. Um sich gegen solche Angriffe wirksam zu schützen, sollte daher unbedingt eine 2-Faktor Authentifizierung stattfinden.

Verbindungen zwischen den Systemen als „path to the kingdom“

Das zweite Szenario setzt auf RFC-Destinationen zwischen den SAP-Systemen. Wann immer neue Features oder Release zu testen sind, ist ein Sandbox-System nicht weit. Gerne wird hier das P-System kopiert, um einen realitätsnahen Test zu ermöglichen. Die Entwickler oder Tester erhalten erhöhte Rechte im System, um Probleme schnell zu identifizieren und zu lösen. Genau dieses Sandbox-System wird dann jedoch zum Ausgangspunkt für den Sturz des als hochsicher bewerteten Produktivsystems. Dies ist möglich, sobald sich ein Remote-Funktionsbaustein zum Passwort-Reset und eine RFC-Destination zu einem produktiven System / Solution Manager auswählen lassen. Daraufhin erhält ein ausgewählter Ziel-User ein neues Passwort – und der Angreifer kann ungehindert auf das produktive System zugreifen.

Derartige Angriffe lassen sich unterbinden, indem man konsequent keine privilegierten Verbindungen von „niedrigen“ zu „höherklassigen“ Systemen zulässt. Zudem müssen alle kritischen RFC-Destinationen nach der Systemkopie aus der Sandbox entfernt werden.

Der lange Arm von Legacy-Systemen

Eigene Beschäftigte wie auch Externe können heute einfach per VPN auf SAP-Systeme zugreifen. Im Laufe der Zeit verändert sich die Landschaft und ein System kann dabei schon mal in Vergessenheit geraten. Es dümpelt dann ohne Patches und weitere Beachtung vor sich hin, denn vielleicht wird es später noch einmal gebraucht.

Zufällig entdeckt dann jemand mit externem Zugriff via VPN dieses System. Ein rascher Blick offenbart einen sehr alten Release-Stand. Standardzugangsdaten genügen da oft schon. Möglicherweise ist „automatic_sap_star“ aktiv und der SAP-Benutzer „zur Sicherheit“ im System gelöscht? Schon öffnet das Legacy-System seine Pforten für den SAP-User. Als SAP_ALL User lassen sich schnell die Hashes aus der USR02 auslesen. Sogar BCODEs sind enthalten. In dem Stapel an Benutzern und Passwörtern aus grauer Vorzeit lässt sich bestimmt ein User finden, der wohlmöglich ohne Passwortänderung die Zeit überstanden hat.

Ein Benutzer in der Liste mit dem Namen CAD_RFC_CLIENT deutet auf einen technischen RFC Benutzer hin, wie er oft in Programmen genutzt wird. Meistens sind solche Passwörter fest im Programmcode eingeschrieben und werden eher selten bis nie geändert. Und darin liegt die Chance für den Angreifer, dass der Zugriff auf das produktive System über die RFC-Schnittstelle funktioniert. Dieser Seitenangriff wäre zu verhindern gewesen, wenn die Sicherheitsanalyse auch das Legacy-System geprüft hätte. Auch im SAP-Kontext gilt eben die Regel vom schwächsten Glied in der Kette.

Schutzmaßnahmen

Die drei Szenarien aus der Erfahrung zahlloser Security-Audits zeigen, dass sich auch sehr sichere Systeme mit wenig Aufwand kompromittieren lassen. Lektion sollte daher sein: Um einzuschätzen, ob einzelne Systeme sicher sind, muss die Sicherheit der gesamten SAP-Landschaft geprüft werden. Wer sich hier auf die produktiven Systeme oder nur die ERP-Linie beschränkt, wird immer wieder blinde Flecken in seiner Bewertung übrig lassen.

Wie lässt sich vor diesem Hintergrund die Sicherheit der SAP-Landschaft richtig bewerten? Natürlich sind weiterhin die Systeme individuell zu prüfen. Der Scope sollte dabei aber nicht zu klein gewählt, sondern auf alle Anwendungen, die das eigentliche Zielsystem umgeben, erweitert werden. Die genannten Beispiele vermitteln deutlich, welch bedeutenden Faktor die umgebende Landschaft darstellt. Es bedarf zwingend einer Übersicht der Verbindungen zwischen den Systemen. Welche RFC-Destinationen existieren? Wo sind kritische Benutzer hinterlegt oder Trusted-Verbindungen etabliert? Gibt es Verbindungen von niedrig privilegierten zu hoch privilegierten Systemen?

Im Rahmen einer solchen Analyse der Verbindungen ist es zudem sinnvoll zu prüfen, welche Verbindungen gar nicht mehr funktionieren. Sei es, weil die Zielsysteme verschwunden sind oder die Zugangsdaten nicht mehr gepflegt sind. Solche Altlasten sind aufzuräumen.

Mit Blick auf die Landschaft ist auch eine Prüfung der Identitäten sinnvoll. Welcher Benutzer darf auf welche Systeme zugreifen. Wo hat er dabei kritische Berechtigungen? Nutzt er eventuell dasselbe Passwort mehrfach? So ein User ist dann natürlich ein herrliches Sprungbrett zu anderen Systemen – sofern seine Identität „geklaut“ werden kann.

Ebenso sollte bei einem kritischen Blick auf die Landschaft kontrolliert werden,

• welche Systeme zu lange nicht mehr mit Updates und Patches versorgt worden sind,

• ob sich in der Landschaft noch Systeme mit Standardzugangsdaten oder gar Schwachstellen verstecken und

• welche Clients sich mit kritischen Benutzern auf das System aufschalten.

Fazit

Der sichere Betrieb von SAP-Systemen erfordert die individuelle Absicherung des Systems wie auch den sicheren Betrieb der gesamten Landschaft. Zur effektiven Bewältigung dieser Aufgabe ist ein tool-gestützter Ansatz notwendig, zumal sie in größeren Landschaften manuell gar nicht zu bewältigen ist. SAP-Systeme sind ganzheitlich zu schützen. Das gibt es nicht umsonst. Auf der anderen Seite gilt: Sicherheit wird immer dann teuer, wenn man keine hat!

Über den Autor: Thomas Werth ist Geschäftsführer der Werth IT.

(ID:49709554)