US-Ministerium Homeland Security warnt vor Angriff auf alte SAP-Lücke

Das zum US-Heimatschutzministerium gehörende Computer Emergency Readiness Team (CERT) warnt vor Angriffen auf eine rund sechs Jahre alte Sicherheitslücke im Java Stack von SAP-Software. Der Fehler steckt in einer Invoker Servlet genannten Funktion des SAP NetWeaver Application Server Java System, die bereits 2010 gepatcht wurde. Laut CERT sind veraltete und falsch konfigurierte SAP-Systeme aber weiterhin angreifbar.

Das das CERT des amerikanischen Homeland-Security-Ministeriums vor dieser Lücke warnt, ist verständlich.

Eine ähnliche Lücke wurde schon früher beschrieben, auch als „Kiss of Death“ bekannt.

Das ganze hat dann das Ergebnis, das man jedes beliebige UNIX-Kommando ausführen kann:

Ich warne Kunden immer davor, solch alte Portalversionen zu verwenden und auch SAP sagt ja, das ab 2010 diese Verletzbarkeit nicht mehr existiert, bzw ab Portalversion 7.1 gefixt ist. Dieser Hack funktioniert OHNE Authentifizierung, so dass dieser eben besonders gefährlich ist.

Aber eine kurze Abfrage in shodan.io zeigt, das auch über das Internet noch genügend alte SAP Java Stacks erreichbar sind.

Sollte eine ältere Version, vor allem im Portalbereich existieren, sollte man durch ein Intrusion Prevention System, eine intelligente Firewall oder durch einen entsprechend konfigurierten SAP Web Dispatcher eine solcher Aufruf blockieren.

Der SAP Web Dispatcher hat eingebaute Funktionen zum Filtern und blockieren von URL-Mustern.

Über eine URL Permission Table mit einem dazugehörigen Profil kann man im Web Dispatcher eine entsprechende Liste anlegen und dort die Muster hinterlegen.

Die Einträge – ähnlich wie im SAPRouter – sind entweder ein permit (P) oder ein deny (D)

In dem man ein URL Muster auf S setzt erfordert es die Benutzung von HTTPS und damit ein Secure Socket Layer Protokoll für alle URLs, die in diesem Muster definiert wurden.

Die Einträge werden von oben nach unten abgearbeitet und die letzte Regel sollte dann greifen. Die letzte Regel sollte ja immer ein „Deny All“ sein. Hier ist eine Architektur-Skizze:

Wenn man folgende Liste sieht, kann man die Idee hinter der URL-Filterung erkennen:

P /public/catalog

P /shop/public

P /shop/start

D /public/*

D /shop/*

P /sap/bc/ping

D /sap/*

Der explizite Aufruf einzelner Services wird hier erlaubt. Alle anderen Dienste im selben Service-Bereich werden unterbunden. Zum Schluss wird kein Aufruf aus einem SAP-Service-Bereich erlaubt, es sei denn, er ist vorher ausdrücklich erlaubt worden.

Dies ist eine Sicherheit-Strategie, mit der man dringende Löcher in der Sicherheit auch über eine URL-Filterung beheben kann.

So etwas sollte aber nur eine temporäre Möglichkeit bleiben. Denn nur, wer über den Web Dispatcher geht, wird auch gefiltert. Sollte ein Angreifer die Möglichkeit habe, direkt einen solchen Angriff auszuführen unter Umgehung des Web Dispatchers, hätte er natürlich Erfolg. An einem Upgrade auf das nächste Support-Pack führt kein Weg daran vorbei

Betroffene Unternehmen sollten die SAP Security Note 1445998 umsetzen und das Invoker Servlet deaktivieren. Ein Hacker für ein öffentlich zugängliches Portal braucht lediglich einen Browser sowie Domain, Hostname und IP-Adresse des anzugreifenden SAP-Systems. Listen angreifbarer Firmen sollen auch schon seit 2013 Dark Web Internetforen kursieren oder auch über Google Hacks zu finden sein.

(Mit Materialien aus meinem Buch SAP Systeme schützen und ZDNet )