Da sind wir wieder bei unserem Nebenjob in der „Mittelstand & Co GmbH“. Wir haben Budget erkämpft und der SAP-Sicherheitscheck steht an. Es ist unser erster „SAP-Pentest“, was uns da wohl erwartet? Aus meiner persönlichen Erfahrung kann ich sagen, dass ein Pentest immer eine spannende Angelegenheit ist. Jeder Auftrag ist individuell mit seinen eigenen Herausforderungen.

„SAP-Penetrationstest sollten durch erfahrene Experten durchgeführt werden. Dies natürlich vor dem Hintergrund der Bedeutung der Systeme, ebenso sind gerade deshalb zuverlässige und ganzheitliche Aussagen durch einen Experten zu bewerkstelligen. Zur Durchfürung eines SAP-Pentest müssen dem Tester die typischen SAP Umgebungen und deren Schwachstellen sowie die Systemarchitektur und deren Security Architektur gut bekannt sein.  Er muss zudem fähig sein den idealen Scope für den jeweiligen Kunden zu erkennen.“

Thomas Werth – Geschäftsführer werth IT

Im Vorfeld wurde bereits viel über das Thema SAP-Sicherheit diskutiert bis endlich die Roadmap stand und das Budget genehmigt wurde. Das große Ziel ist der sichere Betrieb der SAP-Systeme. Doch bevor man zu diesem Ziel aufbrechen kann, gilt es herauszufinden wo man aktuell steht. Dazu soll der Sicherheitscheck dienen. Welche Ergebnisse dieser bringt, kann niemand seriös keiner vorhersagen. In all den Jahren des SAP-Betriebs bei der Mittelstand & Co GmbH ist bisher nichts vorgefallen. Darf man Schlussfolgern, dass es maximal ein paar Schrammen, aber keinen Knock-Out im Pentest gibt?

Ziele des Sicherheitschecks

Unser klar formuliertes Ziel für die Vergabe eines Pentests ist die Identifizierung von Schwachstellen im System. Dies soll zur Transparenz von Risiken für das Unternehmen führen. Die Risikominderung soll durch die Systemhärtung erzielt werden, was langfristig durch die Maßnahmen für den sicheren Betrieb dauerhaft gewährleistet werden soll.

Wichtig ist insbesondere, dass die Ergebnisse verständlich und detailliert dargestellt werden, da für uns in der Rolle als IT-Leiter das Gebiet SAP-Sicherheit Neuland (ob wir dort Frau Merkel treffen?) ist und kaum Expertise im Unternehmen existiert.

Hilfreich wären für uns zu jeder ermittelten Schwachstelle eine Schritt für Schritt Anleitungen zur Behebung.

Ein kurzfristiges Ziel wird dann sein die Daten (Business, Kunden, Mitarbeiter) im System zu schützen, um auch regulatorischen Anforderungen (z.B. DSGVO) gerecht zu werden.

Vorbereitung durch Auftraggeber

Was ist eigentlich für einen „Security-Check“ vorzubereiten, damit der Auditor „arbeiten“ kann? Braucht der Tester einen Arbeitsplatz oder bewerfen wir ihn besser mit der Firewall-Hardware aus dem ersten Stock? Er muss diese ja „überwinden“ können.

Der Tester hat unsere Gedanken wohl erahnt und uns eine Checkliste zur Vorbereitung ausgehändigt. Kurzer Check: Firewall Weitwurf steht nicht drin. Schade!

Die Liste ist gut strukturiert und auf einen authentifizierten Scan ausgerichtet, damit der Tester fundierte Aussagen kann:

• Auf jedem SAP-System im Scope ist ein Audit-Benutzer mit einer mitgelieferten Berechtigungsrolle einzurichten.
• Zugänge mit spezifizierten Berechtigungen für Whitebox-Checks auf Betriebssystem- und Datenbankebene sind vorzubereiten.
• Einige Informationen zu den Zielsystemen und Administratoren werden benötigt
• Für eine Remote-Prüfung wird ein sicherer VPN-Zugang benötigt und ein kurzer Testlauf vor Projektbeginn.

Das klingt machbar, trotz der alltäglichen Arbeitspflichten. Schön, dass nicht mehr Aufwand nötig ist.

Der Benutzeradministrator übernimmt den Punkt Anlegen des Audit-User mitsamt einspielen der Berechtigungsrolle. Die IT-Administration erstellt die Zugangsdaten für OS- und DB-Zugriff. Das SAP-Team stellt die angeforderten Informationen (SID, IP, Mandant, Stack, OS- und DB-Typ) zusammen. Nur das VPN muss der Firewall-Dienstleister einrichten. Das dauert wieder: Ticket beantragen, Rückfragen, Zuständigkeiten, … Da planen wir besser gleich etwas mehr Zeit für diesen Punkt ein.

Am Ende zittern wir ein wenig ob der Dienstleister bis zum angesetzten Termin endlich das VPN aufbaut, doch intern hat die Vorbereitung keinen Stress verursacht. Es ist ganz angenehm, wenn keine aufwendigen Änderungen (wie Custom Code) in den SAP-Systemen durchgeführt werden müssen. So lief auch der produktive Betrieb ungestört fort.

Der Security Check

Es ist soweit, die Vorbereitungen sind abgeschlossen: Heute wird getestet und geprüft. Als IT-Leiter ist uns ein reibungsloser Betrieb wichtig. Der Tester hat versprochen „wir werden nichts merken“. Warum hat er dabei nur so komisch gegrinst? Zur Sicherheit beobachten wir den Workload des Systems mit der ST03N. Der Tester hat sich vor ein paar Stunden gemeldet und den Start des Tests bekannt gegeben. In den Statistiken ist bisher nichts Auffälliges und bisher hat noch kein Mitarbeiter etwas von einem laufenden Pentest bemerkt. Ob wir das als gutes Zeichen werten können? Jedenfalls haben wir uns die Berechtigungsrolle für den Tester genau angesehen. Dabei haben wir Festgestellt, dass auch höhere Privilegien angefordert wurden. Doch der Tester hat uns beruhigt. Das ist alles nur zur Erhebung des Ist-Status. Die erhaltenen Zugriffsrechte werden bei der Verifizierung potentieller Risiken komplett außer Acht gelassen. „Schummeln habe ich nicht nötig!“ hat er lachend gesagt. Was kommt da auf uns zu?

Was macht der Pentester?

Ich bin ja von Natur aus Neugierig und frage mich: „Was macht denn so ein Pentester in seinem stillen Kämmerlein?“ Wollen wir mal gemeinsam ein wenig zuschauen?

Der Tester startet mit dem authentifizierten Whiteboxscan. Der Vorgang dauert seine Zeit, doch parallel kann er schon die ersten Ergebnisse sichten. Der Tester hat viel Routine und arbeitet seine geistige Checkliste anhand der eintreffenden Test-Ergebnisse ab:

• Unsicheres SAP Gateway *OK*
• SAP Standard Zugangsdaten *OK*
• Patchstatus *OK*
• Ablauf Initialkennwörter *NIE*
• User mit Initialkennwort *MSCHULZ*
• Default Initialkennwort im Unternehmen *init,1234*
• FUN MODE *STARTING*

Bingo! Damit kann ein Pentester arbeiten. Der Zugang zum System steht. Welche Berechtigungen besitzt der übernommene Account? Die Antwort liefert eine schnelle Berechtigungssimulation mit seinem Audit-Werkzeug. Oh, schön! Debug mit Wertänderung ist in den Rollen des Users enthalten. Der Tester versteht sein Handwerk und 3,7 Sekunden später besitzt MSCHULZ das Profil SAP_ALL.

Es stehen jedoch noch weitere Prüfungen an, denn letztlich geht es bei einem Security Check nicht darum EINEN Weg in das System zu finden, sondern ALLE Risiken zu ermitteln. Lassen wir den Tester mit seiner Arbeit in Ruhe fortfahren.

Ende des Scans

Der Whiteboxscan lief ohne Auswirkungen auf den SAP-Betrieb durch. Der Tester sichtet die ermittelten Schwachstellen und bereitet den Abschlussbericht vor.  

Damit wissen wir nun zumindest, es gibt etwas zu berichten. Welche Risiken hat der Tester wohl gefunden?

Gibt es Sicherheitsrisiken in dem Custom ABAP-Code?

Sind die RFC-Destinations zu dem BW-System sicher?

Welche Berechtigungen sind noch mal in unseren Standard-Rollen vergeben?

Ergebnisse

Endlich bekommen wir die Ergebnisse präsentiert.

Der Tester berichtet er hat SAP_ALL Zugriff erreicht. Der SAP_ALL Zugriff auf das System wurde Mehrstufig erreicht. Der Einstieg war möglich, da die Generierung der Initial-Kennwörter nicht sicher ist. Weil diese jedoch niemals ablaufen, konnte der Tester einen verwaisten User übernehmen. Als dritter Aspekt kamen dann zu weitreichende Berechtigungen in dessen Standard-Rollen zum Tragen und der Tester konnte so die Berechtigungsprüfungen in dem SAP-System umgehen und SAP_ALL erhalten.

Doch das ist nicht alles, es gibt da noch einen weiteren Punkt der zu untersuchen ist: Im ABAP Code wurde eine 8 Monate alte Backdoor gefunden. Diese erlaubt das Ausführen von Systembefehlen als <SID>Adm – ohne Protokollierung.

Insgesamt war die Abschlusspräsentation auf den Punkt gebracht. Die zusätzliche Dokumentation bestehend aus verschiedenen Zielgruppen orientierten Berichten enthält wertvolle Details und Anleitungen zur der Härtung der Systeme.

Insgesamt lief die Präsentation sehr anschaulich und die passenden Handlungsempfehlungen nehmen direkt den Schrecken.

Konzentrieren wir uns auf das Positive: Die Handlungsempfehlungen. Die Punkte „Ablauf Initialkennwörter“ und „Generierung Initialkennwörter“ lassen sich schnell abstellen. Die Anpassung der Berechtigungen wird eine größere Baustelle, da dort noch weitere Aspekte im Rahmen der Testergebnisse aufgefallen sind.

Die Backdoor im System ist da schon ein anderes Kaliber. Glückicherweise hat der Tester den Benutzernamen des Erstellers identifiziert und nach Rücksprache mit dem externen Berater ließ sich Sinn und Zweck dieser Pseudo-Shell zumindest Nachvollziehen. Der Report mit der Backdoor ist zwar schnell gelöscht, doch was, wenn das nicht so glimpflich ausgegangen wäre, wie läuft denn eine „Spurensuche“ im SAP-System“?

Ich finde das ist eine sehr gute Frage und denke der sollten wir im nächsten Beitrag nachgehen. Ob ich zur nächsten Kolumne meine Forensik-Lupe finden werde?

Ich würde gerne einen meiner Lieblingsangriffe mit Ihnen teilen:

Wie wäre es mit einem Angriff, bei dem Sie sich einen Benutzer Ihrer Wahl, ein System Ihrer Wahl und einen Client Ihrer Wahl aussuchen können und wie von Zauberhand sofortigen Zugriff erhalten?

OK, da ist ein Haken: Sie brauchen Zugriff auf das Dateisystem!
Ist das ein großer Haken? Nun, ich sehe eine Menge Möglichkeiten: Zugriff auf OS-Ebene (wie in fast jedem Breach/Pentest), niedrig privilegierter Benutzerzugriff mit Download-Option und natürlich Schwachstellen mit OS-/Dateizugriff. In den meisten Fällen wird man einen passenden Einstiegspunkt finden.

OK, der Rest ist schnell erledigt:

1. Beschaffen der SAPSYS.PSE-Datei
2. Erzeugen Sie damit ein MySAPSSO2-Anmeldeticket für einen Benutzer (DDIC?) Ihrer Wahl in einem Mandanten Ihrer Wahl (000/produktiv).
3. Verwenden Sie das generierte Ticket zur Anmeldung. Der Einfachheit halber erstellt der werthAUDITOR eine SAP GUI Verknüpfung on the fly.
   Also nur ein Doppelklick und das System ist im Besitz.

Dies funktioniert sogar mit den neuesten S4/HANA Systemen.
Der Screenshot zeigt die Ticket-Erstellungsnachricht in dem werthAUDITOR. Die letzte Zeile enthält den Pfad zur Sap-Gui-Verknüpfung.

Da dieser wirklich oft übersehen wird und eine kritische Auswirkung hat. Ein paar Hinweise zum Schutz:

1. Zugriff auf Dateisystem / SAPSYS.pse beschränken
2. Setzen Sie eine Passphrase (standardmäßig keine) für die Schlüssel in der PSE-Datei!
3. SSO-Ticket deaktivieren (login/accept_sso2_ticket = 0) – nur wenn möglich und wirklich unbenutzt!

Einen Ticketgenerator gibt es auch Open Source bei github: Procter & Gamble Tech · GitHub

Ist der DDIC gesperrt wie es die SAPNote 1998382 empfiehlt, gibt es eine weitere Quelle für Power-User: Die pfl-Dateien im System. Schauen Sie sich die automatisch generierten Änderungskommentare an. Dort finden Sie Benutzernamen mit starken Berechtigungen anstatt „blind“ den DDIC für ein Ticket zu nutzen .

Es wäre doch nur zu schön, wenn es eine Formel geben würde mit der jedes Unternehmen seine individuellen Folgerisiken von „SAP-Sicherheit einfach ignorieren“ berechnen könnte. Diesen Schaden oder die resultierende Summe X könnte man ignorieren (wenn die Kosten für SAP-Sicherheit höher liegen) oder als Motivation verwenden.

In der Realität sind die Folgerisiken jedoch immer nur „optional“ und kein „muss“ . Fehlende SAP-Sicherheit kann gar keine Auswirkungen auf ein Unternehmen haben (zumindest für einen Zeitraum X). An dem Tag X kann es jedoch das ganze Unternehmen durchschütteln. Schadensersatzklagen können die Folge sein, der Markenwert kann sinken oder Aktionäre können das Unternehmen verlassen.

Oft sind diese Risiken dem Unternehmen gar nicht bewusst, sie existieren einfach, weil SAP-Sicherheit ignoriert wird.

Daher ist es wichtig zu verstehen, dass in einem Unternehmen das Personal und die Geschäftsprozesse von SAP-Systemen abhängig sind. Egal ob es die kritischen Geschäftsprozesse, Gehaltsbuchungen oder die Logistik sind. Kommt es zu einem Ausfall das SAP-Systems stehen diese Prozesse und Einnahmen können verloren gehen.

Was kostet … ?

Dies und die abstrakten Angriffsfläche SAP wirklich zu sehen gelingt nicht jeder Unternehmensführung. Gerade weil das Ignorieren des Themas doch die letzten Jahre so gut funktioniert hat. Somit bricht das Management in der Regel SAP-Security auf 2 Punkte herunter:

1. Was kostet die Einrichtung und der Betrieb von SAP-Sicherheit dem Unternehmen?
2. Was kostet ein Sicherheitsvorfall -wegen fehlendem Security-Invest- das Unternehmen?

Punkt 1 haben wir in meiner vorherigen Kolumne ermittelt. Punkt 2 wirft zunächst weitere individuelle Fragen auf:

• Was kostet eine Unterbrechung des Geschäftsbetriebs?
• Welche Folgen hat ein Ausfall, sowohl monetär als auch bezogen auf die Reputation?
• Was passiert, wenn der gesamte Betrieb ausfällt?
• Wieviel Verlust entsteht, wenn die Systeme für die Geschäftsprozesse ausfallen?
• Was könnte ein Datendiebstahl das Unternehmen kosten?

Diese Fragen müssen mit dem Management besprochen werden und helfen zugleich deren Sichtweise auf das Thema SAP-Sicherheit zu verändern. Die abstrakten Kosten eines erfolgreichen Angriffs sind nur schwer vorzustellen, aber diese Fragen regen zum Nachdenken an.

Angriffsszenarien gibt es viele und letztlich wirkt dies alles wie Angst schüren. Effektiver ist es die Kosten für SAP-Sicherheit (Punkt 1) mit den Vorteilen daraus zu verbinden. Abstrakt kann man darstellen in welchem Maß es schwieriger wird erfolgreich das System anzugreifen. So versteht das Management wofür es Geld genehmigt.

Im Folgenden sind einige Ideen skizziert, die zur Verbesserung von Budget-Gesprächen beitragen.

Die Sprache des Geldes sprechen

Auf Basis der obigen Fragen lassen sich die Folgen eines erfolgreichen Angriffs auf das SAP-System monetisieren.  Damit kann man die Kosten „fehlender“ Sicherheit beziffern. Dem stellt man die Ausgaben zur Absicherung dieser Geschäftsprozesse entgegen. Zusätzlich sollte hierbei noch der Automatisierungsaspekt der verwendeten Lösung dargelegt werden, um zu zeigen wie zusätzlich die erforderlichen Ressourcen für einen sicheren Betrieb gesenkt werden. Dies ist ein zusätzliches Einsparungspotential, da die gewonnenen Ressourcen anderweitig eingesetzt werden können.

Ein konkretes Risiko verwenden

Sicherheitslücken und Vorfälle finden regelmäßig ihren Weg in die Schlagzeilen. Ist hier ein Thema aktuell, dass auch auf das eigene Unternehmen zutrifft, so sollte dies zum Anlass genommen werden das Thema Security-Budget zu besprechen. Das Management wird bereits sensibilisiert sein.

Anlässe ergeben sich jedoch auch aus Schwachstellen im eigenen Unternehmen – entweder extern gemeldet oder durch einen Security-Check erkannt. In Kombination mit dem „vermutlichen“ Alter der Sicherheitslücke, lässt sich hier der Handlungsbedarf erörtern. Gegenargumente wie dann ist ja seit Zeitraum X nichts passiert, sind als Steilvorlage zu verwenden: Gleich mal Aufzeigen, dass man ein unzureichendes Auditing besitzt und gar keine Aussage zu potentiellem Missbrauch treffen kann – geschweige denn diesen Erkennen würde.

Ebenso sind Gesetzesanforderungen wie das ITSiG2 oder die DSGVO mit den Strafzahlungen führen zu mehr Gehör im Management.

Roadmap darlegen

Zukunftssichere Investitionen sind hier das Schlagwort. Legt man eine verständliche Roadmap für die nächsten drei Jahre vor, fällt es dem Management leichter eine gute Investition zu sehen. Die Glaubwürdigkeit in die Security-Investition erhöht sich drastisch, wenn sichtbar wird welche tatsächlichen Auswirkungen auf den sicheren Betrieb einhergehen. Risikominimierung und frühzeitige Risikoerkennung lassen sich hier gut darstellen.

Vergleiche ziehen

Die DSAG liefert mit dem DSAG Prüfleitfaden einen einfachen Benchmark zur Systemsicherheit. Dies kann als Minimum der zu erreichenden SAP-Sicherheit angesehen werden. Durch den Anteil der „bestandenen“ Tests aus dem Prüfleitfaden wird das eigene Sicherheitsniveau vergleichbar. Erreicht man die Vorgaben kann man darauf aufbauen und ambitionierte Maßnahmen ergreifen, um „vorne“ zu bleiben. Wird der Benchmark verfehlt, ist dies allein bereits ein Maßgebliches Argument für mehr Budget.

Vermeiden Sie Fachjargon

Bei dem Thema Security Budget treffen häufig Welten aufeinander. Die kryptische Welt der Technik (selbst nicht alle ITler verstehen „Security“) und Business-Welt. In jedem Fall muss das Management abgeholt werden und es darf kein Vorwissen erwartet werden. Vermeiden Sie Begriffe ohne Erklärung zu verwenden: Die Sicherheit von RFC und ABAP, wirft möglicherweise sogar bei einem Security-Experten für Web-Anwendungen Fragen auf. Achten Sie auf Ihre „Flughöhe“ und erklären Sie wenn unvermeidbar die verwenden Fachbegriffe bereits in der Einleitung.

Konzentrieren Sie sich auf den Nutzen und das Können statt auf die Funktionsweise. Bleiben Sie im Kontext von RoI, Risikominderung oder Datenverlust. Enden Sie immer mit den Resultaten und Nutzen für die Geschäftsprozesse des Unternehmens.

Präsentation – das Auge isst mit

Der Mensch lernt visuell am effektivsten. Nutzen Sie dies und verwenden Sie Grafiken oder Modelle, um Ihre Botschaft zu transportieren statt sich auf den Charme von Excel zu verlassen. Bauen Sie ihrem Management so eine Brücke auf der es Ihnen zu neuen Ufern folgen kann.

Entscheidung

Das Gespräch um das Security Budget muss mit einer Entscheidung enden. Entweder trägt das Management das Risiko beziehungsweise ignoriert es weiter (schriftlich geben lassen) oder es wird investiert. Mit der richtigen Roadmap und Präsentation sitzen dann alle in einem Boot.

Denken wir an unsere Rolle als IT-Leiter bei der „Mittelstand & Co GmbH“ zurück. Mit den hier vorgestellten Ideen, schaffen wir es der Geschäftsführung die Notwendigkeit zum Handeln aufzuzeigen. Doch den Igel in der Tasche des CEO konnten wir nicht ganz vertreiben. Der CEO hat es so formuliert: „Ich benötigte einen Vertrauensbeweis in die vorgeschlagenen Sicherheitsmaßnahmen und Transparenz für diese „Sicherheitsrisiken. Wie verwundbar sind wir denn wirklich?“  Entsprechend wurde die erste Etappe der Reise genehmigt und eine Standortbestimmung der SAP-Sicherheit kann in Angriff genommen werden. Auf Basis deren Ergebnisse wird dann entschieden ob weiteres Budget freigegeben wird. Wie der Sicherheitscheck abläuft verfolgen wir in meiner nächsten Kolumne.

Aktuell beobachte ich eine Stille vor dem Sturm.

Corona mitsamt seinen Schutzmaßnahmen sorgt an vielen Stellen für einen Slow-Down oder Stillstand. Arbeitsplätze und Systemzugriffe werden mobiler (Homeoffice, Mobile Endgeräte). Zeit für Security ist da oftmals nicht eingeplant. Passend kommt da ein schwerer Zero-Day für iPhones in der Mail App zur Unzeit und ein Patch lässt aktuell auf sich warten.

Dabei kann man doch mit dem iPhone so schön auf die neuen Fiori Apps von SAP zugreifen – wer weiß wer einem jetzt dabei über die Schultern sieht.

Doch man merkt deutlich, dass an vielen Stellen damit gekämpft wird überhaupt arbeiten zu können. Security Projekte werden da hinten angestellt.

Heißt das Däumchen drehen für Security Consultants? Vielleicht – persönlich habe ich jedoch andere Erfahrungen. Ohne Details zu nennen ist jetzt endlich mal Zeit für die harten Nüsse. Die ein oder andere ist bereits geknackt, andere Schalen haben schwere Risse. Mein Umfeld hat bei den ersten Ergebnissen von einer Erschütterung der Macht gesprochen. Ein bissen Spass muss ja erlaubt sein in diesen Zeiten.

Leider liegt der Mantel des Schweigens über all dem, dafür ist es alles andere als Langweilig aktuell!

Gesund bleiben und Schwachstellen brechen ist die Divise der Stunde.

Euer

Thomas Werth

10KBLAZE bietet neue Angriffsvektoren

Die CISA hat am 2.Mai 19 eine Warnmeldung „New Exploits for Unsecure SAP Systems“ herausgegeben.

Die dort beschriebenen Angriffe zielen im Kern auf bereits bekannte Angriffe gegen das SAP-Gateway. Zum Schutz vor diesen Angriffen kann eine Zugriffsrichtlinie für das SAP-Gateway definiert werden. Diese erlaubt im Default nur Zugriff von dem Localhost und den zum „Internen“ Verbund zählenden SAP-Systemen.

Außenstehende erhalten damit keinen Zugriff auf das Gateway und können keine Angriffe ausführen. Als Ergebnis der neuen Angriffe gilt dies jedoch nicht mehr uneingeschränkt.

10KBLAZE

Zur Ausführung dieses Angriffes haben Sicherheitsforscher neue Wege identifiziert, um die ACLs auszutricksen.

Dazu nutzen Sie entweder einen vorgeschalteten SAP-Router oder im zweiten Weg den Zugriff auf den MS-Monitor Port.

Im ersten Fall bei einem Angriff über den SAP-Router wird eine Konfigurationslücke genutzt, die es erlaubt den SAP-Router als Proxy für Zugriffe auf das SAP-System zu nutzen. Diese entsteht, wenn der SAP-Router auf dem SAP-System oder einem zum „internen“ Verbund der SAP-Systeme zählenden System betrieben wird. Dann gewährt die Standard-ACL dem SAP-Router Zugriff auf das Gateway. Unter diesen Vorrausetzungen kann ein Angreifer den SAP-Router sodann als Proxy nutzen. Daraufhin erscheinen für das Gateway die Anfragen des Angreifers als kämen diese von dem SAP-Router und werden zugelassen. Damit kann ein Angreifer die ACLs umgehen.

Beim zweiten Weg benötigt ein Angreifer Zugriff auf einen ungeschützten SAP-Monitor Port (39NN). Dann kann er dort -ohne die Notwendigkeit eines Logins- sein eigenes System zur Liste des „Internen“ SAP-Verbundes hinzufügen. Damit ist es ihm im im Anschluss möglich von seinem System aus die Gateway ACL zu passieren und auf das Gateway zuzugreifen.

Beide Wege erlauben dann die bekannten Angriffe gegen das SAP-Gateway auszuführen.

Risikoeinschätzung

Wie hoch ist jetzt das tatsächliche Risiko?

Grundlegend sollte ein SAP-Gateway mit ACLs abgesichert sein. Weiterhin sollten die SAP-Systeme durch eine Firewall geschützt sein. Bei der Nutzung eines SAP-Router für den Zugriff sollte dieser nicht auf dem SAP-System oder einem System, welches zu dem Verbund der „Internen“ SAP-Systeme gehört, betrieben werden.

Die Sicherheitsforscher konnten in Deutschland 733 „verwundbare“ SAP-Router aufspüren. Wie zuverlässig die Verwundbarkeit geprüft wurde, ist nicht beschrieben. Es ist jedoch zu erwarten, dass hier und dort ein SAP-Router zu finden ist, der als Proxy missbraucht werden kann.

Der SAP Monitor Port (39NN) für interne Kommunikation sollte definitiv nicht von außen erreichbar sein. Zusätzlich empfhielt sich der Schutz mit einer Firewall.

Laut Aussage der Sicherheitsforscher konnten 92 Systeme mit Zugriff auf den Monitoring Port in Deutschland identifiziert werden. Wie exakt die Ermittlung der Anzahl ist, kann nicht validiert werden. Dennoch ist zu erwarten, dass ein exponierter MS Monitor Dienst doch eher ein seltener Fund ist.

Schutzmaßnahmen

Was bleibt jetzt zu tun?

Die SAP-Router Installationen sind zu prüfen. Diese sollten nicht auf den SAP-Systemen oder Systemen des „Internen“ Verbund betrieben werden.

Für den Schutz des Gateways ist die SAP Note 1408081 Basic settings for reg_info and sec_info zu beachten.

SAP Monitor Dienste für die interne Kommunikation (39NN) dürfen nicht von Außen erreichbar sein. Zusätzlich kann eine Firewall schützen. Hier sind zwei Hinweise zu befolgen:

SAP Note 821875 Security settings in the message server

SAP Note 1421005 Secure configuration of the message server

Im vierten Teil der  Serie „Howto SAP Security“ (Gateway , Netzwerk, Datenbank ) ist das Thema ABAP RFC.

Sicherheitsrisiken bei ABAP RFC

Die Remote Function Calls (RFC) finden breite Anwendung in SAP ABAP Systemen. Ein Benutzer kann ABAP Funktionen, die Remote aufrufbar sind, von anderen Systemen aus aufrufen.

Dazu muss er jedoch die System ID, den Mandanten, sowie die Zugangsdaten des Benutzers kennen.

Es gibt weit über 30.000 RFC Funktionen im ABAP Standard. Diese sind in unterschiedlichen Gruppen gebündelt. „Howto: SAP Security #4 – RFC“ weiterlesen

Im dritten Teil der  Serie „Howto SAP Security“ (Teil 1 , Teil 2) steht die Datenbanksicherheit im Fokus.

Datenbanksicherheit bei SAP-Systemen

Obwohl HANA immer stärkere Verbreitung findet, ist weiterhin Oracle die meist genutzte SAP-Datenbank. Entsprechend liegt hier der Fokus auf Oracle Datenbanken . Dem Thema HANA widmen wir uns in einem späteren Post. „Howto: SAP Security #3 – SAP Datenbanksicherheit“ weiterlesen