Sicher konfigurierte SAP-Systeme indirekt angreifen

Obwohl SAP-Systeme offensichtlich korrekt konfiguriert, vom Wirtschaftsprüfer auditiert wurden und auch Penetrationstest bestanden haben, lassen sie sich möglicherweise über Umwege und Seiteneingänge erfolgreich angreifen.

Thomas Werth zeigt in seinem neuen Gastbeitrag drei Beispiele, wie man im Zielsystem umfassenden Zugriff erhalten kann – und wie man sich gegen raffinierte (indirekte) Angriffe „über die Bande“ schützen kann.

 

 

Spiel über Bande: Potenzielle Sicherheitslücken in der SAP-Landschaft

Einmal im Jahr steht die Jahresabschlussprüfung durch die Wirtschaftsprüfer an. Die Vorfreude mag verhalten sein, doch spätestens mit dem Bestehen der Prüfung sehen viele ihr SAP-System nicht nur als ordnungsgemäß, sondern auch als sicher an. Hat man gar ein Security-Audit oder einen Penetrationstest der produktiven SAP-Systeme bestanden, kann jetzt doch eigentlich nichts mehr schiefgehen. Oder?

Folgen wir einfach dem hypothetischen Gedanken, die produktiven SAP-Systeme hätten nicht nur die Prüfungen der Wirtschaftsprüfer tadellos überstanden, sondern auch die Penetrationstester zur Verzweiflung getrieben und ohne Fehl und Tadel das goldene Security-Einhorn verliehen bekommen. Wieso hat dann trotzdem ein Angreifer einen Fuß in das hochsichere System bekommen … und das Security-Monitoring schlägt (hoffentlich) Alarm?!

Die Antwort liegt in den Q- und Dev-Systemen, Solution Managern oder den Legacy-Systemen sowie den Clients der Anwender, die alle bei den Prüfungen nicht im „Scope“ waren. Fehlkonfigurationen innerhalb der SAP-Landschaft können zur Kompromittierung von als sicher eingestuften Systemen führen.

 

„Was passiert in meiner SAP-Landschaft? Wie kommunizieren die Systeme untereinander? Welcher User darf auf welche Systeme zugreifen? Welche Clients sprechen mit welchen Servern? – Nur wer den Überblick über seine Landschaft besitzt, kann effektiv Seitenangriffe auf kritische Systeme identifizieren und unterbinden!“
Thomas Werth – Geschäftsführer werth IT

 

Drei Beispiele für „indirekte“ SAP-Angriffe

Drei beispielhafte Szenarien dienen zur Veranschaulichung typischer „Seitenangriffe“ auf diese fiktiv hochsicheren und kritischen produktiven Systeme. Diese Seitenangriffe zeigen dabei verschiedene Wege, wie es einem Angreifer gelingen kann — ohne eine Schwachstelle oder Fehlkonfiguration im Zielsystem — dennoch umfassenden Zugriff zu erhalten.

 

Angriffe über den Arbeitsplatz der SAP-Anwender

Im ersten Szenario betrachten wir den Weg über den PC eines Anwenders in das produktive und hochsichere SAP-System. Ob (Spear-) Phishing, Ransomware, APT-Kampagnen oder die nächste Welle an Schadprogrammen wie WannaCry. In Unternehmen passiert es leider immer mal wieder, dass Client-PCs trotz aller Schutzmaßnahmen, wie einem Antivirus-Programmen oder einer 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-Systeme (und auf den Menschen davor), ist es wesentlich leichter hier Zugriff zu bekommen als direkt das SAP-System anzugreifen.

Viele Unternehmen gehen inzwischen den Schritt und nutzen Single Sign On zur Authentifizierung, um Passwörter zu eliminieren. Getreu dem Motto ein Passwort, das nicht da ist, kann auch kein Hacker klauen!

In unserem Szenario weiß der Angreifer jedoch gut mit der Situation umzugehen: Solange keine Zwei-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 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 Admins auch auf das SAP-System zugreifen. It’s not a bug, it’s a feature! Für den SAP-Zugriff genügen dem gewieften Angreifer schon ein paar Powershell-Skripte und eine RFC-Verbindung zum SAP-System.

Der Ablauf eines solchen Angriffs zeigt, wie erschreckend einfach ein hochsicheres P-System einem Angriff zum Opfer fallen kann:

 

 

1. Infektion des Clients (Phising, schadhafte Webseite oder Dokument, Malicious Download, …)
2. SSO-Zugriff mit Powershell über RFC auf das produktive SAP-System im Kontext des Users (Antivirus erkennt dies nicht).

Der Angreifer muss nicht einmal versuchen an ein Passwort zu gelangen, den Hashwert eines Passworts zu knacken oder eins zu raten!

Abwehrmöglichkeit: Um sich gegen solche Angriffe wirksam zu schützen, sollte unbedingt eine 2-Faktor Authentifizierung verwendet werden.

 

Die Verbindungen zwischen den Systemen als „path to the kingdom“ nutzen

Im zweiten Szenario spielen die RFC-Destinationen zwischen den SAP-Systemen eine entscheidende Rolle. Wann immer neue Features oder Release zu testen sind, ist ein Sandbox-System nicht weit. Gerne wird hier das P-System kopiert, um realitätsnahe Tests zu ermöglichen. Entwickler oder Tester erhalten erhöhte Rechte im System, um Probleme schnell zu identifizieren und zu lösen – es ist ja nur ein Sandbox-System.

Doch dieses Sandbox-System fungiert in diesem Szenario als Ausgangspunkt für den Sturz des als hochsicher bewerteten Produktivsystems.

 

 

Auf folgendem Weg erhält der Angreifer Zugriff auf das produktive System:

• Das Sandbox-System enthält alle RFC-Destinationen aus dem P-System, diese wurden bei der Systemkopie mitkopiert.
• Der Entwickler verfügt über genügend Berechtigungen, um über die SM59 solche Destinationen für ein Remote-Login zu nutzen. In der Liste der RFC-Verbindungen wird er fündig und findet eine Verbindung zum produktiven Solution Manager.
• In dieser Verbindung ist ein „Stored User“ hinterlegt. Mit diesem erfolgt der Remote-Login im Solution Manager, ohne dass ein Passwort anzugeben ist.
• Im Solution Manager fehlen allerdings die Berechtigungen, um erneut über die SM59 weiter zu springen. Dafür existiert in den RFC-Verbindungen eine Trusted Verbindung zum produktiven System.
• Allerdings existiert der aktuelle Benutzer im Solution Manager nicht auf dem produktiven System und damit kann die Trusted Verbindung nicht verwendet werden.
• Glücklicherweise ist der aktuelle Benutzer des Angreifers jedoch ein User für die Benutzerverwaltung, der unter anderem initiale Passwörter vergeben darf. Dies nutzt der Angreifer, um einem privilegierten Benutzer auf dem Solution Manager ein neues Passwort zu verpassen. Wichtig ist hierbei, dass dieser Benutzer auch einen Account auf dem produktiven System besitzt.
• Mit dem neuen Passwort erfolgt erneut der Login auf dem Solution Manager mit dem frisch gekaperten Benutzer.
• Die Rechte für die SM59 fehlen weiterhin. Dafür ist die SE37 erlaubt. Dort wird nun ein Remote Funktionsbaustein zum Passwort-Reset gewählt und als Destination die RFC-Destination vom Solution Manager zum produktiven System gewählt.
• Dazu wird ein Ziel-User mit neuem Passwort auf dem produktiven System angegeben. Damit ist der Weg in das produktive System frei. Unter Verwendung des ausgewählten Ziel-Users und mit dem frisch gesetzten Passwort kann der Angreifer jetzt auf das P-System zugreifen.

Abwehrmöglichkeit: Solche Angriffe lassen sich unterbinden, wenn man konsequent keine privilegierten Verbindungen von „niedrigen“ zu „höherklassigen“ Systemen zulässt. In diesem Fall hätten alle kritischen RFC-Destinations nach der Systemkopie aus der Sandbox entfernt werden müssen.

 

Der lange Arm von Legacy-Systemen in der Landschaft

Inzwischen ist es selbstverständlich, dass eigene Mitarbeiter wie auch externe Berater über eine VPN-Verbindung auf die SAP-Systeme zugreifen können. Im Laufe der Zeit verändert sich die Landschaft und ein System kann dabei schon mal in Vergessenheit geraten. Im dritten Szenario ist es einem BW-System so ergangen, das ursprünglich mit viel Euphorie angeschafft wurde, um die Kennzahlenauswertung im Unternehmen auf ein neues Niveau zu bringen.

Mit der Zeit allerdings konnten diese Versprechungen nicht in die Realität umgesetzt werden. Das alte Kennzahlenprogramm hatte sich letztlich gegen das BW-System durchgesetzt. Seitdem dümpelt das BW-System ohne Patches und weitere Beachtung vor sich hin, es könnte ja noch gebraucht werden.

 

 

• Zufällig entdeckt jemand mit externem Zugriff via VPN dieses System. Ein rascher Blick auf das System offenbart einen sehr alten Release-Stand. Das System ist also in keinem guten Pflegezustand.
• Da kann man auch mal Standard-Zugangsdaten probieren. Möglicherweise ist ja automatic_sap_star aktiv und der SAP* Benutzer „zur Sicherheit“ im System gelöscht? Bingo!
• Das „legacy“ BW-System öffnet für den SAP* User seine Pforten.
• Als SAP_ALL User lassen sich schnell die Hashes aus der USR02 auslesen. Sogar BCODEs sind enthalten. Da reicht die benötigte Zeit zum Knacken der Hashes nicht mal zum Kaffee kochen.
• Was macht man nun mit einem Stapel an Benutzern und Passwörtern aus grauer Vorzeit? Mal sehen, ob sich ein User findet, 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 einprogrammiert und werden eher selten bis nie geändert. Ob damit der Zugriff in das produktive System über die RFC-Schnittstelle funktioniert?
• Natürlich! Never change a running System oder Programm oder Passwort – darauf ist Verlass.

Abwehrmöglichkeit: Dieser Seitenangriff wäre zu verhindern gewesen, wenn die Sicherheitsanalyse auch das legacy BW System geprüft hätte. In der SAP-Landschaft gilt eben auch die Regel vom schwächsten Glied in der Kette.

 

Schutzmaßnahmen für SAP-Landschaften

Diese drei Beispiele aus der Erfahrung vieler Security-Audits haben gezeigt, dass auch sehr sichere Systeme mit wenig Aufwand kompromittiert werden können. Als Lektion lässt sich mitnehmen, dass zur Einschätzung der Sicherheit einzelner Systeme die Prüfung der Sicherheit der gesamten Landschaft notwendig ist. Der Ansatz, nur die produktiven Systeme oder nur die ERP-Linie zu prüfen, wird immer blinde Flecken in seiner Bewertung enthalten. Es stellt sich somit die Frage: Wie bewerte ich die Sicherheit meiner Systeme und Landschaft richtig?

Natürlich sind weiterhin die Systeme individuell zu prüfen. Der Scope sollte dabei aber nicht zu klein gewählt werden – alle Systeme, die das eigentliche Zielsystem umgeben, sollten mit in die Prüfungen rücken. Denn wie an den Beispielen vermittelt, ist die den Kern umgebende Landschaft ein sehr bedeutender Faktor.

Man muss eine Übersicht der Verbindungen zwischen den Systemen erhalten. 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 Verbindungsanalyse 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.

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

 

 

Ebenso sollte bei einem kritischen Blick auf die Landschaft nachgesehen werden, welche Systeme „zu lange“ nicht mehr mit Updates und Patches versorgt worden sind. Die Prüfung, ob in der Landschaft noch Systeme mit Standardzugangsdaten oder gar Schwachstellenversteckt sind, sollte ebenso nicht vergessen werden. Welche Clients sich mit kritischen Benutzern auf das System aufschalten ist auch eine spannende Frage, da hilft unter anderem User wie den CAD_RFC_CLIENT aufzuspüren.

In einem Satz zusammengefasst gilt demnach: 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 toolgestützter Ansatz notwendig. Zumal in größeren Landschaften die Aufgabe manuell gar nicht zu bewältigen ist. SAP-Systeme sind ganzheitlich zu schützen. Gerne zitiere ich zum Schluss einen geschätzten Kollegen, der so treffend formuliert hat: „Sicherheit wird immer dann teuer, wenn man keine hat.“ Das gilt sowohl für einzelne Systeme als auch für gesamte Landschaften.