Aus dem Alltag eines SAP Penetrationstesters: Kolumne

Unter dem Hashtag #ThingsWeFoundWhenPentestingSAP twittert SAP Security-Experte Andreas Wiegenstein alias @CodeProfiler über kuriose, manchmal haarsträubende Fundstücke, auf die er bei seiner Arbeit als SAP-Penetrationstester für Virtual Forge bei SAP Anwenderunternehmen stößt.

Für das IT-Onlinemagazin kommentiert er seine persönliche Hitparade:

VON ANDREAS WIEGENSTEIN

Ich möchte den Auftakt meiner Beiträge in dieser Kolumne einem Risikobereich widmen, der bei fast allen Unternehmen im Dunklen schlummert: den Hintertüren im eigenen Code.

Hintertüren sind von Natur aus schwer zu finden, da sie zumeist ja so konstruiert sind, dass man sie nicht finden soll. Da Unternehmen im Schnitt jedes ihrer SAP Systeme mit etwa 2 Millionen Zeilen selbst geschriebenem ABAP Code erweitert haben, sind Hintertüren auch extrem schwer zu finden und werden – wenn überhaupt – häufig nur per Zufall erkannt.

#1 Die „Testseite“

Bei der Analyse einer BSP-Anwendung (Business Server Pages) in einem Unternehmen aus dem Bereich Maschinenbau, habe ich eine Webseite entdeckt, die beim Aufruf nur einen leeren Bildschirm anzeigte. Auf den ersten Blick sah das aus wie eine Testseite, die aus Versehen mit produktiv geschaltet wurde. Entsprechend habe ich mir den Quellcode angesehen, um zu entscheiden, ob ich in meinem Bericht die Löschung der Seite empfehlen sollte. Im Quellcode stellte sich jedoch ein ganz anderes Bild dar.

Die Seite hatte eine ABAP-Logik, die prüfte, ob einer von drei hart codierten Benutzern am System angemeldet war. Falls ein anderer Benutzer die Seite aufrief (wie bei meinem Test der Fall), wurde ein leerer Bildschirm dargestellt. War es jedoch einer dieser drei „besonderen“ Benutzer (die wohl die Seite programmiert hatten), wurde auf dem Bildschirm eine selbst geschriebene SE16 dargestellt. Also ein Programm mit dem man sich den Inhalt von beliebigen Tabellen in der SAP-Datenbank ansehen konnte.

Mit dem „Vorteil“, dass in dieser BSP-Seite keine weitere Berechtigungsprüfung stattfand. Faktisch war dadurch eine Hintertür offen, die es komfortabel via Internet ermöglichte, jederzeit und von überall beliebige Geschäftsdaten auszulesen. Was in diesem Fall besonders bitter war: die Anwendung war bereits vier Jahre online, bevor das Unternehmen den Penetrationstest beauftragte.

#ThingsWeFoundWhenPentestingSAP Backdoor that gave 3 hard-coded developers access to all business data from the Internet

— CodeProfiler (@codeprofiler) March 7, 2014

#2 Das „Daten-Abo“

Bei einer großflächigen Quellcodeanalyse der ABAP-Anwendungen eines Finanzdienstleisters fiel unserem Team ein Programm auf, das eine hart codierte Google Mail-Adresse verwendete. Bei genauerer Untersuchung stellte sich heraus, dass dieses Programm als Hintergrunddienst lief und einmal pro Quartal ausgeführt wurde. Sein Zweck bestand darin, die Unternehmensbilanz zu ermitteln, und zwar kurz bevor das Unternehmen seine Zahlen veröffentlichte.

Dieser „Bilanzvorbote“ wurde dann automatisch – Quartal für Quartal – an die Google Mail-Adresse übermittelt. Vorbei an allen Schutzkonzepten, die das Unternehmen implementiert hatte. Wie sich im weiteren Verlauf herausstellte, gehörte diese Mail-Adresse zu einem Mitarbeiter, der schon seit mehr als einem Jahr nicht mehr für den Finanzdienstleister arbeitete.

#ThingsWeFoundWhenPentestingSAP Backdoor that sent financial data to an ex-employee by email

— CodeProfiler (@codeprofiler) March 10, 2014

#3 Das “Schweizer Daten-Taschenmesser”

Wieder ein Penetrationstest bei einem Maschinenbauer. Hier fand unser Team bei einer Quellcodeanalyse eine fortgeschrittene Variante des generischen Zugriffs auf SAP-Daten vor. Auf dem Produktivsystem existierte ein selbst entwickelter Report, der bei seiner Ausführung keinerlei Berechtigungsprüfungen durchführte. Dieser spezielle Report ermöglichte es dem Aufrufer, den Inhalt beliebiger Tabellen aus der SAP Datenbank komplett herunterzuladen.

Und das ging wegen der nicht vorhandenen Berechtigungsprüfungen bei Finanzdaten – genauso wie bei HR-Daten – genauso wie bei Materialdaten – und natürlich genauso wie bei allen sonstigen Daten. Doch dieser Bericht hatte noch ein Extra eingebaut: die Fähigkeit, die Daten auch wieder zurück ins SAP System hochzuladen. Damit wäre es möglich gewesen, beliebige Geschäftsdaten zu löschen oder zu manipulieren. Und das ohne jeglichen Änderungsbeleg.

Jeder Benutzer mit Zugriff auf die Transaktionen SE38 oder SA38 konnte diesen Bericht ganz einfach ausführen. Dies war im Produktivsystem tatsächlich mehr als 750 Benutzern möglich.

#ThingsWeFoundWhenPentestingSAP Custom ABAP report allowed users to upload arbitrary data to any #SAP table. Alas, farewell compliance.

— CodeProfiler (@codeprofiler) February 19, 2016

Fazit:

Ich möchte Ihnen mit den ausgewählten Beispielen folgende Empfehlungen mit auf den Weg geben:

1. Wenn Sie einen Penetrationstest beauftragen, geben Sie den Spezialisten Zugriff auf Ihren Code. Ohne Quellcode-Analysen hat man praktisch keine Chance, Hintertüren in den unternehmenseigenen Geschäftsanwendungen aufzuspüren.
2. Wenn Sie mit dem Gedanken spielen, Penetrationstests durchzuführen, dann tun Sie dies möglichst bevor Ihre Anwendungen produktiv geschaltet werden.

Weiterführende Informationen:

Informationen zu Virtual Forge SAP Penetrationstest

Andreas Wiegenstein arbeitet seit 2003 als professioneller Berater im Bereich SAP Sicherheit. Er hat zahllose SAP Code-Audits durchgeführt und erhielt Credits für mehr als 80 SAP Security Patches für Schwachstellen, die er in verschiedensten SAP Produkten entdeckt hat.

Er leitet als CTO bei Virtual Forge den Bereich Research & Innovation  – ein Team, das auf SAP spezifische Research und neue Sicherheitslösungen spezialisiert ist.