Administration von SAP-Umgebungen, Teil 2 Patch-Prozess als Risikofaktor für SAP

SAP-Systeme sind unsicher, obwohl SAP, Entwickler und Berater aktiv gegensteuern. Patches gibt es zuhauf, doch selbst bei bekannten Sicherheitslücken kann es dauern, bis ein Patch wirklich implementiert wird. Die Gründe dafür sind vielfältig.

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

Arvato Systems

TXOne Networks

Etliche Faktoren haben Einfluss auf die Verwundbarkeit von SAP-Systemen: Die Komplexität der Implementierung, das historische Wachsen von Landschaften oder auch die relativ unkomplizierte, aber oft folgenreiche Konfiguration von Parametern durch Setzen von Tabellenwerten. Das Ergebnis ist bedenklich.

Fast alle Systeme halten einer strengen Sicherheitsprüfung nicht stand, obwohl in vielen Fällen Patches für Schwachstellen schon lange verfügbar sind. Der prominente Fall von Nvidia Anfang 2014 hat das Problem vor Augen geführt. Hier hatte ein Hacker eine Schritt-für-Schritt-Anleitung zur Ausnutzung einer bereits bekannten SAP-Sicherheitslücke ins Netz gestellt.

Nvidia reagierte schnell und schloss die Lücke. Die auf SAP Netweaver basierende Nvidia-Care-Webseite https://nvcare.nvidia.com musste aber vorübergehend vom Netz genommen werden. Nach Umfragen von IDC wären Angriffe bei korrektem Patching in 75 Prozent aller Fälle abzuwenden gewesen.

Die meisten Administratoren patchen selten

Das Problem sind dabei nicht die nicht vorhandenen Patches. Es gibt genug davon, ja, fast schon zu viele. Seit 2009 wurden 3.242 Security Notes veröffentlich. Ihren derzeitigen Höhepunkt erreichte diese Welle dabei in den Jahren 2011 mit 731 und im Folgejahr mit 835 Patches. Seitdem sinkt zwar die Zahl, aber auch 2014 wurden 391 Notes veröffentlicht, davon 46 Prozent High-Priority-Risiken.

Viele dieser Lücken betrafen auch Drittanbieter-Lösungen. Zudem ist jeder Patch für sich genommen bei der Implementierung keine kurze Security Note, sondern ein komplexes, zeit- und kostenintensives Problem. Denn Patches betreffen das Setzen von Parametern (rund 1.500 pro Server können betroffen sein), die Sicherung der Transportschicht, manchmal sogar Änderung des Codes.

Auf einer komplexen, historisch gewachsenen und individuell implementierten oder auch auf Kundenwünsche angepassten Plattform bedeutet das viel Arbeit und Zeit. Bei Fehlern entstehen vielleicht sogar neue Probleme. Der Rhythmus der Einspielung von Security Patches ist entsprechend darauf ausgerichtet. So dauert es im Schritt ein halbes Jahr, bis ein neuer Patch implementiert wird.

Uns liegen Aussagen von Verantwortlichen vor, die aus Zeitmangel gar nicht mehr patchen – oder mitunter nur einmal im Jahr. Vorbildliche Administratoren werden viermal im Jahr aktiv, also einmal pro Quartal. Selbst hier zeigt sich aber bereits ein gewisser Mut zur Lücke.

Patch-Retrospektive für das Jahr 2014

Der Blick auf 2014 zeigt, wie hochgefährliche Lücken die gesamte SAP-Plattform betrafen. Wer mit dem Patchen nicht nachkommt, verpasst auch Notes zu Bedrohungen, die mitunter die Nicht-SAP-Sicherheitsdiskussion berühren. So die Note 2005441 zum Thema Heartbleed, die 27 Produkte von Sybase, HP, Mobile Solutions oder die SAP Business Suite betrifft.

Eine ganze Serie von Patches mit den CVE-Nummern CVE-2014-6271,-7169, -7186, -7187, -6277, -6278 widmen sich der Shellshock-Familie. Diese Software-Sicherheitslücken in der Unix-Shell Bash ermöglichen es, ungeprüft Programmcode auszuführen. Betroffen waren hier SAP-Systeme, die auf Suse, einigen HP-UX-Versionen, AIX, Soraris, RedHat und Oracle Linux laufen.

Ein anderes prominentes Beispiel ist Poodle – die Sicherheitslücke, die es erlaubt, über verschlüsselte Verbindungen übermittelte private Daten von Clients und Servern auszulesen. Opfersysteme sind hier die Transaktionslayer, SAP HANA und SAP Netwaver sowie alle darauf basierenden Applikationen oder auch mobile SAP Lösungen von Sybase oder Afaria.

Analysiert man alle Patches, sind vor allem folgende Bereiche bedroht:

• die SAP Buisness Suite,

• SAP HANA,

• SAP Afaria Server - also auch die Verwaltung mobiler Geräte,

• Sybase Unwired Platform – zur Erstellen und Verwalten mehrerer mobiler Anwendungen, die eine sichere Verbindung aller wichtigen Gerätetypen mit verschiedensten Backend-Datenquellen herstellen,

• Sap Sybase Adaptive Server Enterprise – und damit eine zentrale Datenbank für Geschäftsdaten, und

• SAP SQL Anywhere.

Hauptangriffsziele auf Transaktionsebene sind SAP Netweaver und die SAP Business Suite (17 entdeckte Sicherheitslücken, 22 veröffentlichte Patches), SAP HANA (18 Lücken, sechs Patches) oder Business Objects (acht Lücken, fünf Patches).

Die Möglichkeiten nicht gefixter Sicherheitslücken sind beeindruckend. Security Note 2015446 ermöglicht die unautorisierte Injektion von XSJS Code in der SAP HANA Web-Based Development Workbench. Ausgenutzt wird diese Lücke durch das Erstellen einer HTTP POST Anfrage.

Die Security Note 2039905 führt einen CORBA Call aus und kann unter Ausnutzung einer lückenhaften Autorisierung Administrator-Sessions hijacken, Nutzerpasswörter lesen und so als Basis für weitere Angriffe dienen. Die Liste ließe sich noch lange fortsetzen. Eine Lücke in Business Objects ermöglicht sogar einen Shut-Down von kompletten SAP-Systemen.

Patching-Lücken schließen

Wie lässt sich das Problem beheben? Naheliegend wäre, einfach regelmäßig zu patchen – wenn man damit nachkommt. Wichtig dabei ist zuerst einmal eine Überprüfung der Patch-Lücken. Dazu bedarf es eines kontinuierlich durchgeführten Assessments von Verwundbarkeiten.

Manchen Unternehmen fehlen dafür aber einfach die personellen und zeitlichen Ressourcen. Lösungen scannen hier SAP-Server in kürzester Zeit. Solche Scans sind dann auch regelmäßig durchzuführen. Sie zeigen die Effekte einer Bedrohung, wenn sie böswillig ausgenützt würden.

Auditoren erhalten so einen Echtzeitstatus als augenfällige Diskussionsgrundlage für eine Durchführung und Priorisierung von Patches. Fortgeschrittene Technologien bieten mittlerweile die Analyse einer SAP-Instanz innerhalb von Minuten und eine genaue schrittweise Anleitung, welcher Patch wie zu installieren ist.

Manche Anwendungen bieten zusätzlich einen Echtzeitschutz, um die zeitliche Lücke zwischen dem Entdecken einer Lücke und dem Erscheinen eines Patches zu schließen. Aufgrund der Komplexität von SAP-Implementierungen im Schnitt 12 Monate, bis zur Implementierung im Schnitt dann aber noch mal ein halbes Jahr.

Zero-Day-Attacken lassen sich derweil mit Fingerprints blockieren, parallel werden auch interne Bedrohung oder eventuell bereits ausgebeutete Lücken durch das Erkennen von anomalem Nutzerverhalten identifiziert. Wenn ein Mitarbeiter aus der Entwicklung plötzlich auf den Server des SAP-HCM-Moduls oder FI-Moduls zugreift, dann scheint eine Lücke verletzt worden zu sein. Aber der Zugriff lässt sich belegen, lokalisieren und stoppen.

* Gerhard Unger ist Vice President EMEA bei Onapsis.

(ID:43182058)