(Un-)Sicherheit in der SAP-Landschaft
Die Antwort findet sich in der SAP-Landschaft oder vielmehr in den Q- und Dev-Systemen, Solution-Managern und Legacy-Systemen sowie den Clients der Anwender, die die Prüfer nicht im Blick hatten. Unvollständige oder Fehlkonfigurationen innerhalb der SAP-Landschaft können letztlich zur Kompromittierung von als sicher eingestuften Systemen führen.
Zwei beispielhafte Szenarien veranschaulichen typische „Seitenangriffe“ auf scheinbar hochsichere und produktive Systeme. Über diese kann ein Angreifer umfassenden Zugriff erhalten, ohne eine Schwachstelle oder Fehlkonfiguration im Zielsystem zu nutzen.
Angriffe über den Arbeitsplatz
Das erste Szenario beschreibt den Weg über den PC eines Anwenders in das produktive und hochsichere SAP-System: Egal, ob Phishing, Ransomware, APT-Kampagnen oder die nächste Welle an Schadprogrammen wie WannaCry, in Unternehmen passiert es leider immer wieder, dass Client-PCs trotz aller Schutzmaßnahmen wie Antivirus-Programmen oder Firewall gekapert und ferngesteuert werden.
Haben Angreifer erst mal 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. Denn über Angriffe auf Windows-Systeme und auf den User ist es wesentlich einfacher, Zugriff zu bekommen, als direkt das SAP-System anzugreifen.
Zudem nutzen viele Unternehmen Single-Sign-on (SSO) zur Authentifizierung, um Passwörter zu eliminieren. Solange keine 2-Faktor-Authentifizierung im Einsatz ist, eignet sich SSO für Angreifer sehr gut als Türöffner in das SAP-System – und das ganz ohne ein einziges Passwort! Denn 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 Admin-Users auf das SAP-System zugreifen. Für den Zugriff genügen dem Angreifer schon ein paar Powershell-Skripte und eine RFC-Verbindung zum SAP-System.
2-Faktor-Authentifizierung
Um sich gegen solche Angriffe wirksam zu schützen, ist unbedingt eine 2-Faktor Authentifizierung notwendig. Im zweiten Szenario spielen die RFC-Destinationen zwischen den SAP-Systemen eine entscheidende Rolle. Wann immer neue Features oder Releases zu testen sind, ist ein Sandbox-System nicht weit. Gerne wird hier das komplette Produktivsystem kopiert, um einen realitätsnahen Test zu ermöglichen.
Die Entwickler oder Tester erhalten im Sandbox-System erhöhte Rechte, um Probleme schnell zu identifizieren und zu lösen. Doch dieses Sandbox-System kann schnell zum Sturz des als hochsicher bewerteten Produktivsystems führen. Dies kann passieren, sobald sich ein Remote-Funktionsbaustein zum Passwort-Reset und eine RFC-Destination zu einem produktiven System 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.
Auch sehr sichere Systeme mit wenig Aufwand lassen sich kompromittieren. Zur Einschätzung der Systemsicherheit muss die gesamte SAP-Landschaft geprüft werden. Lediglich die produktiven Systeme oder nur die ERP-Linie zu checken, führt zu einer lückenhaften Bewertung. Wichtig ist eine Prüfsoftware, die diese ganzheitliche Arbeit leistet. Nur wer den Überblick über seine SAP-Landschaft besitzt, kann effektiv Seitenangriffe auf kritische Systeme identifizieren und unterbinden!
DE
EN
ES
