Für mehr Sicherheit in SAPtown

Ein Secutorial von Senior IT Consultant Torsten Lutz

Die Welt von SAP (Systeme, Anwendungen, Produkte) wird oft als komplex und undurchsichtig dargestellt. Dementsprechend hat auch die (IT-)Sicherheit von SAP den Ruf, aufwändig und kompliziert zu sein. Dieser Artikel möchte die potenziellen Schwachstellen sowie deren Behebung auf eine anschauliche und verständliche Weise erklären.

Zur Veranschaulichung verwendet dieser Artikel als Metapher für ein SAP-System eine Firma, die wie ein Gebäudekomplex oder eine kleine Stadt aufgebaut ist: SAPtown. Die verschiedenen Gebäude und Räume in SAPtown stellen jeweils Dienste und Module innerhalb eines typischen SAP-Systems dar. Die Gebäude und Dienste werden von normalen Benutzern (Anwendern) und Hausmeistern (Administratoren) genutzt bzw. verwaltet. Für die Logistik (Datenaustausch) zwischen dem Benutzer und SAPtown sorgt ein Transporter (SAP GUI).

ZUGANG ZU SAPTOWN: Wer darf rein?

Um Sicherheit in SAPtown zu gewährleisten, sollten wir als Erstes einen Zaun um unseren Gebäudekomplex ziehen (Netzseparierung, Firewall) und dabei zwischen zwei Eingängen unterscheiden: einem Eingang für normale Benutzer und einem für Hausmeister. Für beide schaffen wir getrennte Zufahrtswege. Selbst ein legitimer normaler Benutzer kann also den Zugang in Richtung Facility Management (Administration) mit seinem Transporter idealerweise gar nicht erst erreichen. Auch wenn die Türen innerhalb von SAPtown von den Transportern beziehungsweise Benutzern einen Ausweis verlangen (Benutzername + Passwort), wollen wir doch verhindern, dass ein potenzieller Angreifer überhaupt dorthin gelangt. Denn wenn er bereits vor der Tür steht, könnte er beispielsweise direkt versuchen, das Schloss zu knacken (Brute-Force-Angriff) -- falls er hierfür aber erst einmal einen mit Stacheldraht gesicherten Zaun (Firewall) überwinden muss, sieht die Sache anders aus.

Aber auch beim Vorzeigen des Ausweises (Authentifizierung) haben wir mit zwei potenziellen Sicherheitsproblemen zu kämpfen:

1. Ein Angreifer könnte sich mit einer Kamera unbemerkt postieren und Fotos von den Ausweisinformationen der Benutzer machen (Passwort-Sniffing). Damit könnte er sich in Zukunft direkt als dieser Benutzer ausgeben und sich mit dessen Rechten Zugang zu SAPtown verschaffen.

2. Ein Angreifer könnte eine eigene Ausweiskontrolle vor der eigentlichen Kontrollstation aufsetzen und selbst die Ausweise kontrollieren (Man-in-the-Middle-Angriff). Dabei würde er ebenfalls in den Besitz aller notwendigen Informationen kommen, um sich als ein legitimer Benutzer auszugeben. Ein schlauer Angreifer würde die Informationen dann sogar so weiterleiten, dass keine ersichtliche zusätzliche Kontrolle stattfindet. D. h. der getäuschte Benutzer beziehungsweise Transporter würde den Vorgang gar nicht bemerken.

Die Frage ist also: Wie schützen wir uns vor diesen Gefahren? Ganz einfach: Unsere Transporter benötigen die Möglichkeit zu erkennen, ob sie gerade von einem legitimen Kontrollpunkt kontrolliert werden oder nicht. Dabei sollte kein Dritter in der Lage sein, diese Überprüfung zu beobachten oder zu belauschen. Eine einfache Idee wäre natürlich, den Benutzer zu fragen, ob er denn diese Kontrollstation kennt (Zertifikatprüfung). Allerdings hat die Praxis gezeigt, dass dieser Ansatz nicht funktioniert. Meistens bestätigen die Benutzer einfach jede Art von Rückfrage ohne darüber nachzudenken. Also müssen wir ein eindeutiges und fälschungssicheres Merkmal der Kontrollstation (Zertifikat, Public Key) an alle Transporter verteilen. Zudem baut sich jeder unserer Benutzer einen eigenen kleinen "Tunnel" (Verschlüsselung) auf unserer Zufahrt auf, der ihn vor neugierigen Blicken schützt (der Auf- und Abbau eines solchen Tunnels funktioniert innerhalb eines Netzwerks natürlich erheblich schneller als im Straßenbau). Innerhalb dieses Tunnels bewegt sich der Transporter nun also bis zur Kontrollstation und prüft anhand des eindeutigen Merkmals, ob es sich auch wirklich um die echte Kontrollstation handelt. Erst dann zeigt er seine vom Benutzer mitgegebene Legitimation und darf SAPtown betreten.

Wer diesen Schritt wirklich professionell machen möchte, kann hier natürlich noch weiter gehen und auch jedem Benutzer ein zusätzliches eindeutiges Merkmal geben. Dieses muss dann entweder alternativ oder ergänzend zum Passwort an der Kontrollstation vorgezeigt werden (zertifikatbasierte Authentisierung). Das macht die Verwaltung dieser Daten natürlich aufwändiger, erhöht die Sicherheit aber erheblich. Einen Wachmann, der alle Mitarbeiter persönlich kennt, würde ein gültiger Ausweis alleine nicht überzeugen.

AUSKÜNFTE ÜBER SAPTOWN: Was dringt nach außen?

Stellen Sie sich vor, der Transporter fährt zum ersten Mal nach SAPtown und es gibt zwei Zufahrtswege, die er nehmen kann. Sein Navigationsgerät kennt jedoch nur die allgemeine Adresse und hat keine Informationen darüber, auf welcher der beiden Zufahrten gerade weniger Verkehr ist und an welcher Kontrollstation er sich melden soll. Also fährt er erst einmal zur Auskunft bzw. Registrierung (Message Server), um die fehlenden Informationen einzuholen. Leider hat auch unsere Auskunft zwei potenzielle Probleme:

1. Es gibt eine öffentliche und eine interne Auskunft. Die öffentliche Auskunft muss für alle verfügbar sein, die interne soll jedoch ausschließlich Anfragen von innerhalb des Gebäudekomplexes beantworten.

2. Auch Anfragen von innerhalb des Gebäudekomplexes können potenziell von einer Abteilung kommen, die eigentlich keine Berechtigung hat, diese Informationen abzufragen.

Und um sich gegen ungewollten Abfluss von Informationen abzusichern, muss die interne Auskunft zusätzlich Listen (Access Control Lists) führen, die alle berechtigten Abteilungen aufführt. Denn falls eine derartige Liste nicht hinterlegt ist, beantwortet die Auskunft grundsätzlich jegliche Anfragen ohne sie zu prüfen. Falls wir also versäumt haben, unsere interne Auskunft hinter dem Zaun zu platzieren, werden interne Informationen plötzlich öffentlich verfügbar. Und falls es ein Angreifer hinter den Zaun schaffen sollte, natürlich auch!

Die Registrierung hat ein ähnliches Problem: Hier melden sich in der Regel alle Abteilungen an, die in der Lage sind, unsere Anweisungen auszuführen (Application Server). Und natürlich können diese Abteilungen auch direkt weitere Aufgaben in Auftrag geben. Leider sitzt unsere Registrierung quasi direkt neben der öffentlichen Auskunft und somit haben wir keine Möglichkeit, diese durch den Zaun zu schützen. Deshalb benötigt die Registrierung zwei Listen: Eine, die definiert, welche Abteilungen sich grundsätzlich anmelden dürfen, und eine weitere Liste darüber, welche Sicherheitsfreigaben diese besitzen. In der Vergangenheit von SAPtown haben diese Listen oft jedem gestattet, beliebige Aufträge zu erteilen oder sich zumindest als ausführende Abteilung anzumelden. Ein Angreifer konnte also theoretisch die Registrierungsabteilung betreten und behaupten: "Ich bin der Geschäftsführer und weise hiermit an, dass mir alle Daten erst vorgezeigt und danach gelöscht werden." Und das ohne jegliche Legitimation!

RECHTE UND ZUFAHRTSWEGE IN SAPTOWN: Wer darf was? Oder: autonome Transporter in SAPtown

Natürlich nützt uns all der betriebene Aufwand nur wenig, wenn wir unseren Benutzern unnötig hohe Rechte erteilen (Berechtigungsobjekte). Wenn jeder Benutzer seinen Transporter anweisen kann, beliebige Daten abzuholen, zu verändern oder zu löschen, droht Chaos in SAPtown. Des Weiteren hat SAPtown die Eigenschaft, dass das Verbot, die Daten einer bestimmten Abteilung einzusehen, nicht zwangsweise bedeutet, dass es nicht noch einen anderen Weg gibt, an diese Daten zu gelangen. Es bringt also wenig bis nichts, die eine Tür abzuschließen, wenn der Benutzer einfach einen längeren Weg durch andere Abteilungen nehmen kann und letzten Endes doch ans Ziel kommt. Deshalb sollten wir sichergehen, dass die Verwaltung unsere Benutzer und deren Privilegien möglichst restriktiv gestaltet und ihnen keine unnötigen Rechte einräumt (Principle of Least Privilege).

Außerdem besitzt SAPtown noch eine weitere Zufahrt (RFC), die jedoch primär für automatisierte Vorgänge, also quasi autonom fahrende Transporter, gedacht ist. Dieser Umstand wird in Kombination mit den Berechtigungen eines Benutzers interessant. Denn wer seinen Transporter über den normalen Zufahrtsweg nach SAPtown schickt, hat unter Umständen andere Möglichkeiten, als wenn er die Zufahrt für autonom fahrende Transporter nimmt. Deshalb ist es wichtig sicherzustellen, dass unsere Benutzer nur das Recht besitzen, die vorgesehene Zufahrt zu nehmen. Umgekehrt sollte es für unsere autonomen Transporter nicht möglich sein, die Zufahrt für normale Benutzer zu verwenden.

Apropos autonome Transporter: Natürlich hat SAPtown selbst auch automatisierte Bereiche und setzt hierfür ebenfalls auf autonome Transporter. Manche davon erledigen selbst Aufgaben in regelmäßigen Abständen, andere müssen erst manuell dazu aufgefordert werden. Oft werden dabei Informationen von oder zu anderen Städten und Gebäuden, darunter auch anderen SAPtowns, transportiert. Jetzt hat unser autonomer Transporter also erstmal ein ähnliches Problem wie unsere normalen Transporter: Woran erkennt er eine legitime Kontrollstation auf dem Weg in eine andere SAPtown? Die Lösung funktioniert analog zu der unserer Benutzer: Wir vergeben sowohl an die Kontrollstation als auch an den Transporter eindeutige Merkmale und bauen uns jeweils einen Tunnel auf.

Allerdings gibt es noch weitere sicherheitsrelevante Aspekte zu beachten, um unsere autonomen Transporter zu legitimieren:

Zum einen lässt sich abermals über Listen definieren, welchen anderen SAPtowns unsere SAPtown vertraut und umgekehrt. Damit können wir gewisse Vertrauensstellungen schaffen, was unsere Sicherheit verbessert. Natürlich ist diese Lösung nicht ideal, schließlich könnte ein Angreifer auch einen gelben Transporter kaufen, bekleben und anschließend behaupten, dass er von einem namhaften Transportunternehmen geschickt wurde und gerne Zutritt zum Gelände hätte, um ein (Daten)Paket zuzustellen. Doch auch wenn das Erstellen von Vertrauenslisten ein solches Szenario nicht ausschließt, erschwert es potenziellen Angreifern durchaus die Arbeit.

Zum anderen können wir natürlich auch Zugangsdaten hinterlegen, die unsere autonomen Transporter dann für ihre jeweilige Aufgabe automatisch verwenden. Allerdings können gespeicherte Passwörter immer ein Sicherheitsproblem darstellen. Denn wenn wir einen Schlüssel irgendwo hinlegen, dann kann er grundsätzlich auch entwendet werden. Und so ist es natürlich auch in SAPtown: Gelangt ein Benutzer oder ein Angreifer an diese Informationen, kann er alles tun, was für die Erfüllung der Aufgabe des autonomen Transporters vorgesehen war -- und hierbei kann es sich durchaus um weitreichende Berechtigungen handeln. Je nach Aufgabe betrifft dies also entweder unsere lokale SAPtown oder eine andere. Dies kann ebenfalls problematisch sein, da ein Angreifer auf diesem Wege gegebenenfalls von unserer unkritischen Test-SAPtown auf eine kritische Produktiv-SAPtown springen kann!

Damit enden die Möglichkeiten jedoch noch nicht, denn SAPtown hat noch eine weitere Funktion in petto. Die Konstrukteure haben nicht nur vorgesehen, dass der autonome Transporter Aufgaben an seinem Ziel ausführt. Zusätzlich kann das Ziel nämlich den Transporter anweisen, auf dem Rückweg an seinem Ursprung ebenfalls eine Aktion auszuführen. Das können wir uns zum Beispiel so vorstellen, dass uns der Paketbote ein (Daten)Paket bringt und wir ihn dann beauftragen können, in seiner Firma zu veranlassen, uns künftig Zugang zu seinem Firmengebäude zu gewähren (einen neuen Benutzer mit einem von uns festgelegten Passwort anzulegen). Auch hier besteht die Lösung wieder darin, eine entsprechende Liste zu befüllen, was jedoch glücklicherweise nicht manuell geschehen muss. Wir können die Verwaltung der internen autonomen Transporter von SAPtown anweisen, in eine Art Lernmodus zu gehen. In dieser Phase lernt und protokolliert die Verwaltung dann jegliche Anweisungen, die bei der Rückkehr eines autonomen Transporters ausgeführt werden. Die so generierte Liste müssen wir dann zwar eigens sichten, aber immerhin nicht manuell pflegen. Und nach ein paar Wochen lässt sich diese Sammlung dann "scharf schalten". Das bedeutet, dass in Zukunft keine Anweisung mehr ausgeführt wird, die wir nicht vorher durch unsere Liste freigegeben haben.

Letzten Endes müssen wir also bei der Konfiguration von Aufgaben für unsere autonomen Transporter abwägen, ob wir lieber eine Vertrauensstellung mit dem Ziel eingehen oder Zugangsdaten hinterlegen wollen. Je nachdem, auf welche Art ein Angreifer Einfluss auf diese Aufgaben nehmen kann, ist also die eine oder die andere Variante geeigneter. Erbeutete Zugangsdaten lassen sich in der Regel jedoch flexibler einsetzen.

 

Und was geschieht, wenn jemand Zugriff auf das zentrale Datenarchiv (Datenbank), Schlüssel oder Informationen zu Hintertüren von SAPtown erlangt? Game Over für ganz SAPtown? – Im nächsten Newsletter erfahren Sie mehr!


Termine

02.07.2019 - 04.07.2019
Secu2: Incident Response
09.07.2019 - 10.07.2019
Hack5: Exploit Development
11.07.2019
Secu5: Planung und Durchführung von Penetrationstests
16.07.2019 - 17.07.2019
Hack7: Sicherheit und Einfallstore bei Webapplikationen