Target SAP

Der unberechtigte Zugriff ermöglicht Sabotage, Spionage und Betrug – bis hin zur vollen Kontrolle über SAP-Infrastrukturen.

Durch unberechtigte Zugriffe sur Bases de données erhalten Spione Einblick auf alle kritischen Daten eines Unternehmens: USIS, ein Anbieter von Hintergrundrecherchen zu persönlichen Daten, musste 2015 den unerlaubten externen Zugriff auf mindestens 25.000 Daten von Mitarbeitern in US-Regierungsbehörden einräumen.

Für einen Betrug erweitert ein Angreifer seine Rechte in SAP-Systemen, legt sich als einen falschen Zulieferer an, schreibt sich eine Rechnung und veranlasst die Überweisung auf das eigene Konto.

Dies geschieht durch die Ausweitung der Privilegien eines Nutzer-Accounts – unter Aushebelung des SAP-spezifischen Sicherheitsansatzes der Segregation of Duties (SoD): Eine Trennung von Pflichten oder Kompetenzen kann zwar effektiv für Sécurité sorgen, indem Rechte von Mitarbeitern in der Entwicklung, Produktion, Planung und Buchhaltung fein säuberlich getrennt werden.

Die Trennung kann aber auch durch stark privilegierte Accounts ausgehebelt werden.

In einem Fall, vor dem im Mai 2016 die regierungsnahe US-CERT warnte, wird eine eigentlich seit 2010 mit Patch schließbare Sicherheitslücke bei SAP-Systemen mit aktivierten Invoker Servlet immer noch ausgenutzt.

Durch die Lücke können Angreifer per Fernzugriff neue SAP-Utilisateurs mit Verwaltungsprivilegien über den Webbrowser anlegen.

Die Lücke ließ sich bei 36 Unternehmen feststellen – 13 davon erwirtschafteten einen Jahresumsatz von mehr als zehn Milliarden Euro.

Der Angriff zielte auf nicht aktualisierte oder fehlkonfigurierte SAP-Java-Plattformen. Dramatisch ist auch die Sabotage durch Abschaltungen von SAP-Applikationen oder gar eines ganzen Systems.

Den Schaden, wenn eine Anwendung offline geschaltet werden muss, schätzten im Frühjahr 2016 die Befragten einer Ponemon-Institute-Studie auf 4,5 Millionen Dollar – einschließlich aller Kosten zur Behebung des Schadens und verloren gegangener Geschäftsmöglichkeiten.

Angriffe auf Profile und Privilegien

Ansatzflächen für Angriffe auf Zugriffsrechte und Anwenderprofile sind die Transaktionslayer – wie Hana oder NetWeaver –, die Geschäftsinformationen und Prozesse sowie den Zugriff darauf verwalten, die Kommunikation zwischen den Instanzen regeln und für deren Sécurité etwa durch Cryptage sorgen.

Auch Accounts und deren Berechtigungen werden im Transaktionslayer mit Parametern verwaltet und lassen sich wie bei einer Datenbank verändern. Angreifer versuchen mit diesen Zugriffen ferngesteuert den Datenverkehr zu steuern, Verzeichnisse jeden Inhalts einzulesen, zu kopieren, zu verschieben oder zu überschreiben.

Alle Parameter von SAP-Infrastrukturen lassen sich schnell durch die Eingabe von Zahlenwerten konfigurieren.

Account-Verwaltung und Fehlerquote

Die verschiedensten Möglichkeiten der Account–Verwaltung sorgen dabei schnell für Komplexität und erhöhen die Fehlerquote.

Risiken ergeben sich dabei durch das Customizing der SAP-Software, durch die Einstellungen der User Gestion Engine (UME) bei Java-Systemen, die für die Suche oder das Anlegen von neuen Usern zuständig ist, und durch die Access Control List (ACL), welche die Anmeldung bei Servern und die Zulassung von Programmen oder Verbindungen regelt (reginfo, sec­info, Webdispatcher, Management Console, Message Server, ICM).

Weitere Gefahren bestehen bei Konfiguration von Anwenderrollen und User-Parametern generell ( zum Beispiel durch den universell berechtigten Sap_All-User sowie User-Profile, die RFC-Verbindungen aufnehmen können) oder bei unsicheren Konfigurationen von Authentifizierungsverfahren.

Gestion de Risiko-Anwendern

Weitreichende Privilegien machen Nutzer gefährlich. Wenn Zugangsdaten geleakt oder Authentifizierungsverfahren umgangen wurden, kann aber die Verwendung von sicheren Usertypen noch eine zweite Schutzmauer bieten.

Eine Grundregel in der Rechteverwaltung lautet daher, einen Utilisateurs nur mit dem Minimum an Rechten zu versehen, die er für seine Aufgabe benötigt. Der sogenannte Restricted User, der in der Default-Einstellung über keine besonderen Privilegien verfügt, auf Bases de données nur über Client-Anwendungen zugreift und keinen vollen SQL-Zugang hat, sollte Sicherheitsstandard sein.

Standard User, welche per Default ihre eigenen Objekte anlegen sowie Daten in der System View auslesen können und eine Public Role innehaben, sollten nach Möglichkeit vermieden werden. Deren Log-in-, Datenabfrage- und Datenübertragungsaktivitäten sind besonders zu überwachen.

Dies gilt natürlich auch für besonders kritische Hana-User: Der <sid>adm user (wobei <sid> für die jeweilige Hana-System-SID steht), der während des Installationsprozesses auf Betriebssystem-Ebene angelegt wird, stellt ungeschützt ein Risiko dar. Er verfügt über Privilegien für alle Hana-Systemressourcen.

Viele Systemprovider legen das Passwort für diesen Utilisateurs während der Installation der Systeme bei Kunden an. Spätestens nach Übergabe der SAP-Infrastruktur sollte es geändert werden.

D'autres Utilisateurs auf Betriebssystem-Umgebung, wie der root user, der sapadm user oder individuell angelegte Anwenderprofile, müssen sicher konfiguriert und mit umfangreichen Privilegien umso engmaschiger überwacht werden.

Seiteneingänge

Eine weitere zu überwachende Hintertür, bei deren Betreten oft nicht nach Credentials nachgefragt wird, sind die Notfall-Mechanismen von SAP. Mit dem Profil Parameter login/no_automatic_user_sapstar steht ein Zugang für die unkomplizierte Problemlösung bereit, der zum gefährlichen Backdoor werden kann.

Wird dann der Super-User SAP* gelöscht, existiert dieser Zugang nicht mehr für die auditierbaren Bases de données. Er bleibt deswegen bei der Durchführung herkömmlicher Audits unentdeckt, hat aber eine Verbindung zum System mit allen Autorisierungen. Zudem kann das Standard-Passwort nicht geändert werden.

Das Ergebnis bei Missbrauch ist die Kompromittierung entweder eines oder mehrerer Clients, eines oder mehrerer Applikationsserver oder gar des ganzen SAP-Systems.

Die einfache Abhilfe ist, den Super-User niemals zu löschen, den User SAP* zusätzlich zu sichern und den Wert login/no_automatic_user_sapstar mit „1“ festzulegen.

Aber auch unsichere Konfigurationen von Authentifizierungsverfahren stellen ein hohes Risiko dar. Gefahr erzeugen Skripte zu automatischer Abspeicherung von Passwörtern in der SAP-GUI-Bedienungsoberfläche. Diese speichern bei entsprechender Einstellung die etwa im Log-in-Feld eingetragenen Werte und damit auch Passwörter – genauso aber auch Nutzerdaten von Kunden.

Begünstigt werden solche Angriffe durch eine zu schwache Cryptage bei der Abspeicherung der Daten. Zudem wird die Historie der Eintragungen in Benutzernamenfeldern für jeden Utilisateurs in einer einheitlich benannten Datei abgespeichert, sodass ein Hacker diese leicht findet. Für mehr Sécurité sorgt der Schutz von Eingaben in verdunkelten Eingabefeldern oder das Abstellen der Speicherung vergangener Einträge.

Eine andere Lücke sind die sogenannten SAP-Shortcuts. Hier definieren Utilisateurs nicht nur eine  Zieladresse zum Log-in auf eine SAP-Instanz, die dort auszulösende Transaktion und unter Umständen die Eintragung eines Default-Nutzernamens.

Ein von falschen Händen definierter oder kontrollierter Shortcut kann zum Einstiegstor auf Systeme werden. In früheren Transaktionslayern war die Gefahr sogar noch größer, weil in die Shortcuts auch die automatische Eingabe individueller Passworte eingebaut werden konnte.

SAP hat diese Optionen für neu anzulegende Passwörter deswegen mittlerweile geblockt. Für bereits bestehende Passwörter existiert diese Gefahr eventuell weiterhin.

Konfigurationscheck und Angriffsabwehr

Angesichts der Komplexität und Dimension der Konfigurationsproblematik können Fehler fast gar nicht vermieden werden. Es gilt aber, sie so schnell wie möglich zu finden und zu beheben.

Eine effektive SAP-Sicherheitslösung untersucht daher Konfigurationsfehler und bietet Fast-Echtzeitschutz gegen mögliche Angriffe.

Die Inventarisierung von Failles de sécurité kann dabei nur durch automatisierte Assessment-Lösungen erfolgen. Wichtig ist dabei eine kontinuierliche Überprüfung des Sicherheitsstatus in der SAP-Infrastruktur, um neu aufgekommene Fehleinstellungen unverzüglich zu bemerken.

Dabei müssen nicht nur Produktiv-Systeme, sondern auch Test-Systeme berücksichtigt werden, denn gerade hier befinden sich default konfigurierte und oft vergessene User-Accounts, die von ungewünschten Besuchern ausgenutzt werden.

Konfigurationen von Accounts oder Authentifizierungslösungen lassen sich dabei nach verschiedenen Richtlinien (SAP-Sicherheitsrichtlinie, PCI, SOX, NERC, Custom oder anderen) überprüfen.

Eine Lösung zu Erkennung und Abwehr von Bedrohungen gibt dann zum Ersten eine schrittweise und so schnell umsetzbare Anleitung zur Behebung der Lücken.

Gegen unbekannte Bedrohungen, die auch durch Konfigurationen-bedingte Risiken entstehen, bieten Lösungen einen Fast-Echtzeit-Schutz durch Blockieren von Angriffen, bis eine SAP Security Note dafür verfügbar ist.

An oberer Stelle steht auch eine Überwachung von anormalen Zugriffen interner Mitarbeiter.

Der Entwickler, der plötzlich oder zu ungewöhnlichen Zeiten auf Instanzen zur Buchhaltung zurückgreift, sollte nicht unentdeckt und seine Zugriffe gegebenenfalls geblockt werden.