SAP-Systeme im Visier
Die sieben wichtigsten SAP-Angriffsvektoren Perimeter-Schutz und Endpoint-Security helfen nur wenig, wenn geschäftskritische Anwendungen selbst ein Sicherheitsrisiko darstellen. Ein Blick auf SAP sowie sechs kritische Schwachstellen zeigt, dass das Vulnerability-Management für viele Unternehmen noch immer eine Herkules-Aufgabe ist, warnt unser Autor und mahnt dringend zum zeitnahen Patchen. Im Zentrum der Aufmerksamkeit sollten dabei sieben konkrete Angriffsvektoren stehen, die in den letzten Jahren verbreitet genutzt wurden.
Von Marcus Müller, Heidelberg
SAP-Systeme gelten unter Cyberkriminellen als die Kronjuwelen im IT-Netzwerk von Unternehmen. Schließlich nutzen rund 92 % der Forbes Global 2000er SAP, um ihre Geschäftsabläufe zu optimieren, Transaktionen abzuwickeln und Daten zu verwalten. Gelingt es einem Angreifer, auf ein ungenügend geschütztes SAP-System zuzugreifen und beispielsweise ein Konto mit maximalen Rechten (Administrator/ SAP_ALL) zu infiltrieren, kann er nach Belieben Zugriffs- und Berechtigungskontrollen (z. B. Aufgabentrennung, Identitätsmanagement, GRC Lösungen) umgehen und sich die vollständige Kontrolle über das betroffene SAP-System verschaffen. Eine erfolgreiche SAP-Attacke verspricht fette Beute – egal ob es sich um den Diebstahl hochsensibler oder personenbeziehbarer Informationen (PII), die Umleitung von Geldern oder das Erpressen von Lösegeld handelt.
Für Unternehmen sind solche Angriffe gleich doppelt fatal: Schon durch die Kompromittierung geschäftskritischer Anwendungen entsteht ein hoher Schaden. Doch darüber hinaus unterliegen SAP Anwendungen zudem in den meisten Fällen strengen Datenschutz-Anforderungen (z. B. nach DSGVO) sowie branchenspezifischen Compliance-Vorgaben (z. B. gem. Sarbanes-Oxley-Act [1] oder PCI-DSS für den Zahlungsverkehr). Verstöße und Versäumnisse im Zusammenhang mit fehlendem Cyberschutz können so zusätzliche Bußgelder und juristische Konsequenzen nach sich ziehen.
Angriffswelle auf SAP
Dabei sind entsprechende Angriffe keine bloße Drohkulisse: Von Mitte 2020 bis April 2022 haben allein Analysten von Onapsis mehr als 300 erfolgreiche Exploits ungeschützter SAP-Anwendungen verzeichnet. Diese Angriffswelle zielte auf fehlerhafte und dadurch unsichere Konfiguration sowie insgesamt sechs bekannte Schwachstellen (CVEs). Die Mehrheit der beobachteten Aktivitäten stand dabei im Zusammenhang mit Exploits, die erst nach der Bereitstellung von Patches durch SAP veröffentlicht wurden – allerdings waren auch benutzerdefinierte und „private“ Exploits zu beobachten, die von 50 verschiedenen IP-Adressen und 10 verschiedenen Ländern ausgingen (Details siehe unten).
Gefahr erkannt heißt nicht, Gefahr gebannt!
Grundsätzlich sind SAP-Systeme gut gesichert und abgeschirmt. Der Softwarekonzern veröffentlicht monatlich Patches und stellt Best Practices für die System-Konfiguration zur Verfügung. Darüber hinaus arbeitet SAP eng mit Cybersicherheits- und Compliance-Experten von Security-Anbietern zusammen, um kritische Sicherheitslücken in der SAP-Software frühzeitig aufdecken und schließen zu können. Regelmäßig durchgeführte Bedrohungsanalysen helfen Unternehmen sowie Anwendern, Gefährdungen innerhalb des SAP Environments zu verstehen, Risiken zu priorisieren und Geschäftsprozesse sowie Datengezielt vor Angriffen zu schützen.
In letzter Konsequenz liegt die Verantwortung jedoch bei Unternehmen und Service-Providern – auch wenn das nicht jeder Anwender einsehen mag (vgl. [5]). Dennoch: Obwohl SAP sicherheitskritische Schwachstellen in der Regel umgehend entschärft und seinen Kunden entsprechende Patches zur Verfügung stellt, bleiben in vielen Unternehmen selbst hochkritische Vulnerabilities teilweise monate- oder sogar jahrelang ungepatcht.
Die Gründe dafür sind bekannt: IT-Sicherheits-Teams stoßen angesichts der Masse täglich neuer Cyberbedrohungen nicht selten an ihre Grenzen – selbst kritische Alerts können im Lärm der Threat-Intelligence (TI) schnell einmal untergehen. Und die Bewertung der Kritikalität von Schwachstellen sowie die Priorisierung im Patchmanagement lässt sich trotz hohem Automatisierungsgrad nicht einfach per Knopfdruck erledigen (siehe auch [3]). Cyberkriminelle nutzen diesen Umstand gezielt aus und haben ihre Techniken, Tools und Prozesse entsprechend angepasst – dazu gehört auch ein hochspezifischer Ansatz zum Exploit von SAP Schwachstellen.
Detaillierter Angriffsablauf
Nach erfolgreicher Anmeldung in den SAP-Systemen führten die Angreifer der beobachteten Angriffswelle eine ganze Reihe von Aktionen aus: Während manche lediglich auf das System selbst zugriffen, machten sich andere daran, die technischen Konfigurationen innerhalb der SAP-Anwendungen zu manipulieren und über neu erteilte Zugriffsrechte sicherheitskritische Daten herunterzuladen. Onapsis identifizierte zudem technisch versierte Angreifer, die nach Ende ihrer kriminellen Aktivitäten die zuvor ausgenutzte SAP-Schwachstelle auf eigene Initiative hin gepatcht haben, um so ihre Spuren zu verwischen und dabei gleich noch eine Hintertür für zukünftige Angriffe einzurichten.
Die Nachverfolgung der Attacken offenbarte komplexe Strukturen, bei denen Angriffe zunächst von einem Quellsystem in einem Land starteten und anschließend von einem anderen System mit einer anderen Geo-IP fortgeführt wurden. Diese Aufteilung deutet auf ein orchestriertes System und eine koordinierte Gruppe an Akteuren hin (siehe Tab. 1).
Die Angriffe selbst liefen dabei teils erschreckend schnell an: In einigen Fällen dauertes es keine 24 Stunden zwischen dem Bekanntwerden einer Schwachstelle und dem erkennbaren Scan-Versuch durch einen potenziellen Angreifer. Im Schnitt standen bereits nach 72 Stunden erste funktionsfähige Exploits zur Verfügung – so etwa bei der als Recon bekanntgewordenen Schwachstelle CVE-2020-6287 (siehe Timeline in Abb. 1). Neue ungeschützte SAP-Anwendungen, die in Infrastructure-as-a-Service-Umgebungen (IaaS) von AWS, Microsoft Azure, der Google Cloud Platform und anderen liefen und dort vom Unternehmen selbst und/oder von einem Dienstleister verwaltet wurden, fanden sich innerhalb von nur drei Stunden im Visier von Cyberkriminellen.
Maximierte Effektivität durch verkettete Schwachstellen
Im Rahmen ihrer Analyse stießen die Sicherheitsexperten von Onapsis auf System-Kompromittierungen, für die unterschiedliche SAP-Schwachstellen miteiander verkettet wurden. Ziel dieses „Vulnerability-Chaining“ ist es, die initiale Kompromittierung eines Systems auszuweiten und sich möglichst auch lateral im IT-Netzwerk weiterzubewegen. Grundsätzlich lassen sich dabei vier Gruppen von Schwachstellen kombinieren:
Ebene 1 – Zugriff auf Anwendungs-Level: Die Schwachstellen dieser Gruppe ermöglichen eine erste Kompromittierung der Zielanwendung über ein auf dem System bereitgestelltes Benutzerkonto. Dazu zählen etwa die Vulnerabilities CVE-2020-6287, CVE-2016-3976 sowie Brute-Force-Angriffe, die über fehlerhafte Konfigurationen von Benutzerkonten mit maximalen Zugriffsrechten erfolgen.
Ebene 2 – Ausweitung der Zugriffsrechte auf das Betriebssystem (OS): Diese Gruppe von Schwachstellen
ermöglicht einem Angreifer die uneingeschränkte Ausführung von Betriebssystembefehlen – ausgehend von einem bestehenden Benutzerkonto einer SAP-Anwendung. Berechtigungen lassen sich so vom Anwendungs-Level auf das Zielsystem ausweiten. In diese Kategorien fallen die Schwachstellen CVE-2018-2380 und CVE-2016-9563.
Ebene 3 – direkter Zugriff auf das Betriebssystem: Die Vulnerability CVE-2020-5326 ermöglicht den uneingeschränkten Zugriff auf OS-Ebene und damit das direkte Ausführen von Befehlen innerhalb des Betriebssystems der SAP-Zielanwendung.
Ebene 4 – systemübergreifende Kompromittierung: Die letzte Kategorie umfasst Schwachstellen, die eine laterale Bewegung vom Eintrittspunkt zum Rest des Netzwerks ermöglichen – so können Angreifer weitere Systeme infiltrieren. Schwachstellen in dieser Gruppe sind etwa CVE-2016-3976 und CVE-2020-6207.
Onapsis konnte eine Reihe von Aktivitäten beobachten, bei denen die Akteure Schwachstellen der Ebenen 1 und 2 kombiniert haben, um sich Zugang zu SAP-Anwendungen und zum Betriebssystem zu verschaffen. Schwachstellen der Ebenen 1 und 3 dienten zudem als Ausgangsbasis, um im weiteren Verlauf Schwachstellen der Ebene 4 auszunutzen und den Angriff auf andere Systeme und Geschäftsbereiche auszuweiten (vgl. Abb. 2 auf S. 14).
In einem Fall gelang es einem Angreifer, sich über die Recon-Schwachstelle in ein Admin-Benutzerkonto zu hacken und anschließend über ein Exploit der CVE-2018-2380 einen Shell-Upload auszuführen. Einmal auf der OS-Level angekommen, nutzte der Akteur eine weitere Schwachstelle aus (CVE-2016-3976), um Anmeldedaten für hochprivilegierte Konten und Datenbanken herunterzuladen. Der komplette Angriff dauerte dabei gerade einmal 90 Minuten.
Top-7 SAP-Schwachstellen
Letztlich erfassten die Analysten vor allem Aktivitäten rund um sechs CVEs. Es ist daher dringend zu empfehlen, alle Systeme in der SAP-Landschaft umgehend auf diese Schwachstellen sowie ihren Patch-Status zu prüfen, um der Bedrohung durch möglichst viele cyberkriminelle Angriffe einen Riegel vorzuschieben.
CVE-2020-6287 – Recon – SAP-Security-Note #2934135
Bereits am 14. Juli 2020 hat SAP den Patch für eine kritische Sicherheitslücke mit der Bezeichnung CVE 2020-6287 (auch bekannt als Recon) veröffentlicht. Diese Schwachstelle ist hoch kritisch (CVS 10.0) und lässt sich sowohl remote als auch über HTTP(s)-Protokolle ausnutzen. Für ein Exploit der Sicherheitslücke sind keine Berechtigungen erforderlich (Pre-Auth). Sie ermöglicht es Angreifern, hoch privilegierte SAP-Benutzer auf Anwendungsebene zu erstellen.
Aufgrund dieser Merkmale gab die Cybersecurity and Infrastructure Security Agency (CISA) der USA noch am Tag der Veröffentlichung des Patches eine Warnmeldung heraus (www.cisa.gov/uscert/ncas/alerts/aa20-195a). Onapsis konnte seit Veröffentlichung des Recon-Patches und -Exploits fortwährend aktive Scans und Exploits beobachten – insgesamt 333 Vorfälle ausgehend von 74 verschiedenen IP-Adressen. Diese Aktivität hat im Laufe der Zeit zugenommen und hält bis heute an!
CVE-2020-6207 – SAP-Security-Note #2890213
Ein Patch für diese kritische Sicherheitslücke (CVS 10) wurde von SAP sogar schon am 10. März 2020
veröffentlicht. Die Schwachstelle betrifft den SAP Solution Manager (SolMan), eine zentrale Komponente jeder SAP-Installation und quasi das Äquivalent zu Microsofts Active Directory (AD) für Windows-basierte Plattformen: Ist der Solution Manager eines Unternehmens kompromittiert, hat ein Angreifer die vollständige administrative Kontrolle über alle miteinander verbundenen SAP-Anwendungen in der Umgebung.
Monate nach der Veröffentlichung des Patches entdeckte Onapsis Scanversuche, die auf die verwundbare Komponente abzielten. Was das Angriffsvolumen betrifft, so wurden 756 Zugriffs-Versuche von 34 verschiedenen IP-Adressen aufgezeichnet. Am 14. Januar 2021 wurde ein voll funktionsfähiger Exploit auf GitHub der Öffentlichkeit zugänglich gemacht. Seit dieser Veröffentlichung beobachten die Forscher eine erhebliche Zunahme der auf diese CVE abzielenden Exploit-Aktivitäten.
CVE-2018-2380 – SAP-Security-Note #2547431
Seit dem 1. März 2018 gibt es einen Patch für diese Schwachstelle, die sich in CRM-Lösungen finden lässt, die auf SAP NetWeaver basieren. Bleibt die Sicherheitslücke ungepatcht, können Angreifer sie verwenden, um Privilegien zu erweitern und Betriebssystembefehle auszuführen – im nächsten Schritt erfolgt der Zugriff auf die zugrunde liegende Datenbank der SAP-Anwendung sowie eine laterale Ausbreitung auf andere Server. Die Analysten des Onapsis Research Labs haben hierzu 34 Angriffsversuche identifiziert, die von 10 verschiedenen IPs ausgingen und darauf abzielten, Betriebssystembefehle auf dem zugrunde liegenden OS auszuführen.
CVE-2016-9563 – SAP-Security-Note #2296909
Die von SAP im August 2016 gepatchte Schwachstelle hat einen CVSSv3-Wert von 6,4/10 und betrifft die Komponente BC-BMT-BPM-DSK von SAP NetWeaver AS JAVA 7.5. Sie lässt sich remote beziehungsweise mit (wenig privilegierten) authentifizierten Angreifern ausnutzen. Ein erfolgreicher Exploit ermöglicht es Akteuren, unter anderem Denial-of-Service-(DoS)-Angriffe mittels XML-Entitätserweiterung durchzuführen und sich unerlaubten Zugriff auf Daten zu verschaffen.
CVE-2016-3976 – SAP-Security-Note #2234971
Den Patch für eine weitere Sicherheitslücke in SAP NetWeaver AS Java hat SAP am 8. März 2016 veröffentlicht. Ein erfolgreicher Exploit dieser Schwachstelle ermöglicht es Angreifern, beliebige Dateien über Directory-Traversal-Sequenzen zu lesen – darüber hinaus ist ein Zugriff auf Betriebssystemressourcen möglich, wodurch sich Privilegien erweitern lassen.
Bereits 2016 wurden Exploits öffentlich, mit denen man auf die Secure-Store-Datei im SAP-NetWeaverJAVA-System zugreifen kann, was zu einer potenziell vollständigen Kompromittierung des Systems führt.
CVE-2010-5326 – SAP-Security-Note #1445998
Am 11. Mai 2016 veröffentlichte das U.S. Department of Homeland Security (DHS) einen US-CERT Alert (TA16-132A): Die Meldung beruhte auf Hinweisen auf eine aktive Ausnutzung und Kompromittierung ungesicherter SAP-Anwendungen im Internet. Die in der Warnung hervorgehobene kritische Schwachstelle betrifft eine Vielzahl ungesicherter SAP-Anwendungen. Ein Exploit ermöglicht es Angreifern, Betriebssystembefehle ohne Authentifizierung auszuführen und auf die Anwendung sowie die Datenbank der Anwendung zuzugreifen. Theoretisch lässt sich so die vollständige und ungeprüfte Kontrolle über SAP-Geschäftsinformationen und -prozesse erlangen. Onapsis identifizierte hierzu 206 Ausnutzungsversuche von 10 eindeutigen IP-Adressen.
Konfigurations-Fehler
Neben den Exploits ungepatchter SAP-Schwachstellen, haben die Analysten noch einen weiteren verbreitet genutzten SAP-Angriffsvektor beobachtet: Brute-Force-Attacken auf fehlerhaft konfigurierte SAP Benutzerkonten mit hohen Privilegien. Zu den dabei verwendeten Benutzernamen gehören SAP*, SAPCPIC, TMSADM und CTB_ADMIN. Obwohl SAP bereits vor Jahren umfassende Dokumente für die sichere Konfiguration von Konten sowie Best Practices für das Einrichten von Berechtigungen sowie das Passwortmanagement veröffentlicht hat [7], scheint bei vielen Unternehmen noch Nachholbedarf zu bestehen.
Fehlende Sicherheitsmaßnahmen bei der Konfiguration zeigen deutlich, wie wichtig regelmäßige Kontrollen und die Durchsetzung klar definierter Prozesse im Management von geschäftskritischen Anwendungen wie SAP ist.
Mahnung
Ein kontinuierliches und schnelles Vulnerability-Management ist weiterhin bedeutsam, kann aber mittlerweile nur einen Teilbereich der Application-Security darstellen: Es geht nicht mehr allein darum, Schwachstellen in laufenden Anwendungen möglichst schnell nach Veröffentlichung einer „Common Vulnerability and Exposure“ (CVE) zu patchen. Im Rahmen von DevSecOp und „Shift Left“ gilt es vielmehr, Prozesse rund um das Static Application-Security-Testing (SAST) bereits im Laufe von Eigenentwicklungen zu etablieren und damit Risiken proaktiv zu entschärfen – bevor sie für Unternehmen zu echten Bedrohungen werden. Das gilt insbesondere im SAP-Umfeld, das ein erhöhtes Maß an Aufmerksamkeit erfordert und spezifische, maßgeschneiderte Lösungen und Prozesse voraussetzt.
Marcus Müller ist Senior Vice President Sales International EMEA & APAC bei der Onapsis Inc.
Literatur
[1] Hans-Joachim Gaebert, SOX für SAP, Realisierung von Sarbanes-Oxley-Anforderungen im SAP-Berechtigungskonzept, 2006# 3, S. 51
[2] Jochen Konrad-Klein, Prüftools für SAP-Systeme, 2009# 1, S. 80
[3] Georg Hohnhorst, Erst prüfen, dann patchen – Die Security-Notes der SAP richtig umsetzen, 2013# 4, S. 6
[4] Gerhard Unger, Vertraute Muster, Ein Statusbericht zur SAP-Sicherheitslage, 2015# 1, S. 10
[5] SAP-Security: Über die Hälfte sieht Verantwortung beim Hersteller, Kurzmeldung, 2016# 1, S. 100
[6] SAP-Security: Trügerisches Sicherheitsgefühl?, Kurzmeldung, 2018# 2, S. 86
[7] SAP, Administration Guide: User Management and Security, SAP IQ 16.1 SP 01, Dezember 2018, https://help.sap.com/doc/a8a1c2f484f21015b7138d64cfc4e7ce/16.1.1.0/ en -US/SAP_IQ_Administration_User_Management_and_ Security.pdf