Das SAP-System in der Cloud zu betreiben etabliert sich vermehrt als valide Option für den SAP-Betrieb. Es klingt alles so schön einfach und sicher soll es ja auch sein. Kann man das Blind glauben? Was macht eigentlich Sicherheit in der Cloud aus? Reicht es aus, wenn das System selbst sicher ist?
Mir drängt sich da noch eine weitere Frage auf, um überhaupt etwas zur Sicherheit sagen zu können:
Wie funktioniert eigentlich Cloud?
DevOps und Cloud gehen für mich Hand in Hand. Ohne DevOps wäre der Betrieb einer Cloud gar nicht möglich. Stark vereinfacht ist DevOps die Transformation der Serverlandschaft in „Software“. Man beschreibt seine Dienste und Server in Konfigurationsdateien und die DevOps Werkzeuge „generieren“ dann die dort beschriebenen Systeme. Schrauben ziehen in einem Rack, Betriebssystem installieren, passende Pakete suchen – all das gehört seit DevOps zur die „alten Zeit“.
Auf dieser Basis ist es möglich in der Cloud hunderte oder sogar zigtausende Systeme zu orchestrieren.
Wie genau funktioniert das denn jetzt wieder?
Nähern wir uns dem Thema mal in einer Vereinfachung ohne zu tiefe Details. Docker hat einen enormen Siegeszug hinter sich. Das nicht ohne Grund. Ist man mit Docker doch in der Lage quasi einen Dienst zu isolieren. Man braucht einen Webserver? Kein Problem „Nimm einen Docker Container“. Egal ob nginx oder Apache es gibt vorgefertigte aktuelle Container. Doch auch selbst einen passenden Docker zu erstellen ist nicht viel mehr als eine Konfigurationsdatei zu schreiben. Hier wählt man ein Basis-Image. Gibt Anweisungen zur Erstellung der Web-Server Konfiguration und verweist auf ein Verzeichnis in dem die Webseiten liegen (idealerweise als mount außerhalb des Dockers). Abgerundet wird die Konfiguration durch ein Init-Skript, das über ENVIROMENT Variablen die individuelle Konfiguration setzt (wie den Domain-Namen).
Kurzum mit Docker sind Dienste nicht mehr fest im System verankert, sondern isolierte „Container“-Baukästen, die individuell nach Bedarf zusammengesetzt werden können. Die Kombination aus einem Webserver Container und einem Datenbank Container ersetzt das klassische System auf dem alles direkt installiert wurde.
Dies ist ein wesentlicher Kern der Idee von Infrastruktur als Code. Es ist von der Idee her so „einfach“: Eine Beschreibung der Komponenten und wann diese „laufen“ sollen sowie den Namen der Maschine und welche Pakete zu installieren sind – fertig. Den Rest erledigen die Werkzeuge und erschaffen die Infrastruktur. Auf Basis der Beschreibung werden die Systeme in der definierten Anzahl erschaffen. Abweichungen (Systemausfälle, Zusätzliche Systeme oder wenige aufgrund der aktuellen Last,…) werden automatisch korrigiert. Firewall-Konfigurationen, Änderungen an IP-Adressen, mehr Speicherplatz – alles auf Knopfdruck. Das ist DevOps, die Magie hinter der Cloud.
Werkzeuge
Terraform ist eines der bekanntesten Werkzeuge für diese Aufgabe und wird von vielen Cloud-Providern wie AWS unterstützt. Es wird eingesetzt um letztlich die „Server“ in der Cloud zu erstellen und zu steuern. Dazu zählen ssh-keys, Firewall-Regeln, „Hardware-Ausstattung“, Anzahl der Systeme und mehr. Es kann auch die Docker-Container auf den Servern installieren. Doch möchte man tausende solcher Container verwalten, ist dieser spezielle Punkt bei Kubernetes besser gelöst als „nur“ Terraform zu nutzen.
Kubernetes ist Spezialist für Docker-Container. Egal ob die laufenden Container durch eine neue Version ersetzt werden sollen oder ein Load-Balancer die Zugriffe verteilen soll oder die Anzahl aufgrund hoher Last verdoppelt werden soll. Das alles macht Kubernetes mit „links“. Um dies zu ermöglichen, bündelt Kubernetes „Server“ in Kubernetes Cluster. Mehrere Container werden für den gemeinsamen Nutzungszweck in „Pods“ als eine Einheit zusammengefasst. Diese Pods leben virtuell auf einem „Node“. Früher war dies das „Blech“ auf dem Server letztlich lief. Mit einem „Deployment“ wird dann beschrieben wie viele Pods wann und wo laufen sollen und wie die Replikationsstrategie aussehen soll. Bei den Deployments ist das „Update“ ein herausragendes Feature. Man kann live seine Systeme updaten und Kubernetes sorgt dafür, dass während des Updates keine Downtime entsteht und am Ende alle Pods auf der neuen Version sind. Für Load-Balancing lassen sich verschiedene Pods mit demselben Dienst zu „Services“ zusammenfassen. Bisher spielt die Musik aber nur „in“ dem jeweiligen Kubernetes Cluster, für Zugriff von außen muss noch ein „NodePort“ erstellt werden, damit wird der Dienst dann nach außen geöffnet. Soweit doch schon ein wenig Komplex, trotz unserer sehr hohen Flughöhe. Die Zugriffsberechtigungen der Systeme untereinander werden über Rollen und Policies definiert. Dies variiert je nach Cloud-Anbieter und kommt als weitere Komplexitätsschicht oben drauf.
Dies alles ist der Kern hinter der Mammut-Aufgabe eine Cloud zu betreiben.
„Bereits ohne SAP-Systeme ist ein Cloud Betrieb komplex. Die Konfiguration aller Komponenten ist letztlich eine zusätzliche Ebene für die Systemsicherheit. Kann ein Angreifer Schwachstellen in der Konfiguration ausnutzen und Zugriffsrechte auf die Cloud erhalten und ausweiten, dann geraten auch die Systeme dort in Reichweite für den Angreifer. “
Thomas Werth – Geschäftsführer werth IT
Wie funktioniert SAP Hosting in der Cloud?
Sehen wir uns mal an wie Amazon das SAP Hosting umgesetzt hat. In einem Blog-Eintrag wird das SAP-Hosting vorgestellt. Terraform ist dabei ein wesentliches Element zur Erzeugung der Infrastruktur und auch Dev-Ops ist gern gesehen. Es stehen verschiedene Instanzen („virtuelle Hardware“ mit Maßgabe von Speicher und CPU) als Grundgerüst für ein SAP-System zur Auswahl. Individuelle Installations-Dateien sind über S3 Buckets (Key/Value Ablagesystem) verfügbar. Berechtigungen lassen sich über IAM Rollen für Systeme und Administratoren steuern.
Zusätzliche Werkzeuge wie Cloudwatch (Monitoring) oder auch Backup-Tools sind optional.
Der DevOps Ansatz „Infrastruktur als Code“ wird über eine AWS API unterstützt und damit lässt sich die SAP Infrastruktur in der Cloud automatisiert vom Kunden steuern. Für Terraform stellt Amazon sogar eigene Module bereit, die für die Verwendung mit SAP-Systemen (HANA, Netweaver) ausgelegt sind. Diese Module sind sogar in die Terraform Registry integriert und stehen allen Nutzern zur Verfügung.
Grundlegend entspricht dies dem allgemeinen Cloud-Ansatz, nur wird hier komplett auf den Einsatz von Docker und damit auch Kubernetes für den SAP-Anwendungsfall verzichtet. Das ist auch Nachvollziehbar, da ein SAP-System nicht in einen Docker-Container passt. Ebenso sind die Vorteile von Kubernetes nicht voll und ganz ausspielbar. Wer hat schon tausende SAP-Systeme oder fährt mal eben ein paar zusätzliche Systeme hoch, weil „zu viele“ User damit arbeiten?
Was bietet SAP zusätzlich?
SAP selbst bietet auch Hosting in der Cloud an und greift dabei auf die etablierten Anbieter wie Amazon, Microsoft und Google zurück. Als Mehrwert bietet SAP nach eigener Darstellung verschiedene Sicherheitsmaßnahmen.
(Quelle SAP)
Zugriffsschutz ist auf verschiedenen Ebenen vorhanden. Dennoch sieht man an dem Schaubild, dass SAP Mitarbeiter als Cloud Administratoren auf jede private Cloud zugreifen können. Das muss natürlich auch sein, da SAP letztlich die Systeme betreibt. Nennen wir es mal Wertungsneutral den SAP Master Zugriff.
Zudem betont SAP seinen Zero Trust Ansatz, in dem die unterschiedlichen Schichten keine Vertrauensstellung besitzen.
(Quelle SAP)
Alles sicher?
Dies ist ein sehr lobenswerter Ansatz, da gerade Vertrauensstellungen gerne mal ausgenutzt werden. Man denke nur an Social Engineering oder die RFC-Trust Destinations der SAP-Systeme. Der Boden auf dem alles steht ist der externe Cloud Anbieter. Von Amazon haben wir erfahren, dass Terraform alles für ein SAP-System aus dem Hut zaubern kann. Sogar beliebige Installationsdateien über S3 Buckets und die individuellen Berechtigungen über die IAM Rollen. Was passiert wohl, wenn jemand sich hier Zugriff verschaffen kann und beliebig Berechtigungen vergeben kann oder Skripte editiert? Was wenn er die AWS Policies anpasst und somit faktisch die Firewallregeln neu schreibt? Wie hoch bleibt der Schutz durch den Zero-Trust für die restlichen Komponenten? Das sieht jedenfalls nach dem ersten Ansatzpunkt für einen Angreifer aus.
SAP hat auch Verwendung für Docker und Kubernetes.
(Quelle SAP)
Da sind sicher einige Funktionen, die auch aus Security Sicht nützlich sind. Doch Docker und Kubernetes als Security Feature darzustellen ist sportlich. Natürlich nutzt man nicht den Default Namespace und auch keine privilegierten Container. Ein solcher Container kann im Handumdrehen als Root auf das „hostende“ System zugreifen. Doch auch nicht privilegierte Container sind nicht automatisch hoch sicher. Wesentlich wichtiger ist jedoch der Schutz von Kubernetes. Wird Kubernetes zum Angriffsziel, kann das gesamte Königreich fallen – mit allen SAP-Systemen darin. Auch wenn diese gar nicht von Kubernetes verwaltet werden. Sicherheitsfeatures kannte Kubernetes beim Relese gar nicht, nicht einmal Authentifizierung. Das wurde erst 2 Jahre nach dem ersten Release nachgereicht. Das macht ja Hoffnung… Die Frage ist nur wem?
Was passiert bei einem Cyberangriff auf die Cloud?
Begeben wir uns mal gedanklich in die Welt eines Angreifers, der unser Unternehmen attackieren möchte. Unser Unternehmen nutzt die Cloud umfänglich. Web-Server, File-Server, SAP-Systeme, Datenaustausch – für alles hat die Cloud eine Anwendung und die wird auch benutzt. Ist ja einfach.
Step 1: Ziel virtualisieren
Zunächst müssen wir unser Ziel „virtualisieren“ – also Angriffsziele im Cyberraum finden. Für einen schnellen Start nehmen wir die Domain und suchen Subdomains. Hier gibt es verschiedene Hilfsmittel SubList3r, Spiderfoot oder Fernmelder. Schnell haben wir mit diesen eine Liste mit DNS Namen zur Hand. Wir suchen jetzt Systeme, die in der Cloud laufen. Dies lässt sich am einfachsten mit der Webseite DNSCharts bewerkstelligen. Hier laden wir unsere Liste mit DNS Adressen und sortieren die Ausgabe nach den „Services“.
(Auszug Ergebnisse dnscharts)
Wir kennen somit ein paar Systeme, die in der Cloud betrieben werden. Dort sitzen auch die SAP-Systeme und zu denen möchten wir gelangen. Wie kommen wir jetzt also weiter?
Step 2: Die MetaAPI
AWS bietet eine MetaAPI auf der IP Adresse http://169.254.169.254/ . Die API bietet verschiedene Informationen an sowie die Möglichkeit temporäre Credentials auszustellen. Jedoch ist die API nur innerhalb der Cloud ansprechbar. Ein Sicherheitsfeature? Damit die API nicht von außen verwendet werden kann? Wir benötigen also einen „Helfer“, um mit der API sprechen zu können. Die gute alte SSRF Schwachstelle kommt hier wie gerufen. Diese Schwachstelle erlaubt es einen Server als „Proxy“ zu missbrauchen, um Anfragen an einen dritten Server im geschützten Netzwerk (Cloud) zu stellen.
(Quelle: https://miro.medium.com/max/700/1*7N6TAJwT2FhhPIHtjc-3mg.png)
Step 3: SSRF Vuln suchen
Wir suchen also einen Server der Verwundbar gegen diese Schwachstelle ist. Dieser Server muss in der Cloud stehen, damit er uns zur MetaAPI leiten kann. Der ZAP Proxy kann solche Schwachstellen erkennen. Für den nächsten Schritt prüfen wir also erneut unsere Liste der Domains und nehmen die ins Visier, die laut dnscharts bei AWS gehostet sind. Mit ZAP wird ein aktiver Scan gefahren und nach SSRF Schwachstellen gesucht.
Bingo! Wir sind fündig geworden. Dies ist übrigens oftmals bittere Realität, wie man am Beispiel des Capital One Hacks nachlesen kann. Im Folgenden wird die gefundene SSRF Schwachstelle ausgenutzt, um gezielt eine URL der API aufzurufen. Ich spare mir hier zur Übersicht den konkreten SSRF Angriff, zumal dieser je nach Webseite hoch individuell ausfällt. Stattdessen zeige ich nur die eigentliche „Ziel-Url“ und deren Auswirkung.
Step 4: Zugriff auf die API
Mit Zugriff auf die API lassen sich nun verschiedene Abfragen tätigen:
http://169.254.169.254/iam/security-credentials : liefert das zugeordnete Instanzprofil zu dem System. In diesem Fall ist die Antwort: „full-role.ec2“
http://169.254.169.254/latest/meta-data/iam/security-credentials/full-role.ec2 : Liefert ein Json Objekt, das zu dem Profil „full-role.ec2“ temporäre Zugangsdaten erzeugt: AWS access key ID, secret access key, und session token.
{
„Code“ : „Success“,
„LastUpdated“ : „2012-04-26T16:39:16Z“,
„Type“ : „AWS-HMAC“,
„AccessKeyId“ : „ASIAIOSFODNN7EXAMPLE“,
„SecretAccessKey“ : „wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY“,
„Token“ : „Agoh4h37fgHSDAF7“,
„Expiration“ : „2020-09-17T15:09:54Z“
}
Step 5: Zugriff auf die AWS
Mit diesen beiden Aufrufen erhalten wir sofort Zugangsdaten zur „privaten“ AWS Cloud unseres Unternehmens. Nur Aufgrund der SSRF Schwachstelle in dem Web-Server.
Damit hat man direkt Zugang zu dem AWS-Konto, in dem die ganzen Systeme laufen.
Damit wir die Zugangsdaten bequem nutzen können installieren wir die AWS CLI Tools:
$ apt install awscli
Und nutzen gleich die erhaltenen Zugangsdaten
$ aws configure
[Zugangsdaten]
Wir können nun die AWS Cloud API verwenden. Dem eigentlichen Ziel, das SAP System zu erreichen bringt uns das nur indirekt näher. Es fehlt uns noch die Adresse des Systems und ein User für das Login.
Step 6: Lateral Movement
Gehen wir noch mal einen Schritt zurück. Der Webserver mit der SSRF Schwachstelle bietet diverse Tarif-Rechner und ähnliches an. Je nach Standort und Kundenkreis werden andere Ergebnisse erzielt. Die Daten zur Berechnung wird nicht der Webserver in einem Docker Container halten. Er muss die Daten von einem weiteren System abfragen. Es ist gar nicht unwahrscheinlich, dass er diese Abfragen direkt an das SAP System stellt. Dazu muss er aber die Adresse kennen und Zugangsdaten besitzen. Docker Container kommen aber genau genommen „von der Stange“, solche individuellen Informationen können erst beim Start übergeben werden. Meist als ENVIROMENT Variablen zur Verwendung in Skripten. Wie kommen wir jetzt an die ENVIROMENT Variablen? Oder das Init-Skript beim Start, welches die Variablen setzt?
Die SSRF Schwachstelle! Bei DevOPs (AWS, Terraform) werden die individuelle Settings in den User-Daten der Systembeschreibung hinterlegt. Die lassen sich auch über die MetaAPI Abfragen:
http://169.254.169.254/iam/user-data
…
Write_files:
– content:
YXNkYXNkaGdod2Vxd2Vhc2Rz….
encoding: gzip+base64
…
Der Content ist jedoch selten im Klartext hinterlegt, aber das genutzte Encoding steht in den Daten.
Mit diesem Wissen lässt sich der Content doch wieder im Klartext darstellen:
$ echo YXNkYXNkaGdod2Vxd2Vhc2Rz…. | base64 –d | gunzip
…
SAP_RFC_USER=web_rfc
SAP_RFC_PASS=sadkh$%$§%dfjj6782
SAP_PUBLIC_IP=3.227.102.13
…
Als Ergebnis erhalten wir die gesuchten Zugangsdaten und die Public IP Adresse. Dies wird im Rahmen der Installation gesetzt, damit der Web-Server Anfragen an das SAP-System stellen kann.
Jetzt ist noch fraglich wer darf auf das System zugreifen?
Zugriffsrechte werden in AWS mit Policies deklariert. Mit unserem AWS Zugang können wir uns die Instanzen in der „private“ cloud auflisten lassen
$ aws ec2 describe-instances
In dieser Auflistung sind auch die Firewallregeln für den Zugriff enthalten. Wir suchen in der Liste das SAP-System und prüfen die Security Groups, welche die Zugriffsregeln enthalten:
…
„SecurityGroups“: [
{
„GroupName“: „SAPSecurityGroup“,
„GroupId“: „sg-0598c7d356eba48d7“
}
],
…
Sehen wir doch mal nach wer Zugriff auf die Systeme hat:
$ aws ec2 describe-secrity-groups –group-ids sg-0598c7d356eba48d7
…
„IpPermissions“: [
{
„ToPort“: 3302,
„IpProtocol“: „TCP“,
„IpRanges“: [
{
„Description“: „Access from NY office“,
„CidrIp“: „203.0.113.0/24“
„Description“: „Access from BERLIN office“,
„CidrIp“: „190.12.11.0/24“
„GO-Live Test“,
„CidrIp“: „0.0.0.0/0“
}
],
…
Man sieht hier, dass je eine Zweigstelle aus New York und Berlin Zugriff haben. Scheinbar ist jedoch auch eine Regel aus einem GO-Live Test noch aktiv: Die IPRange 0.0.0.0/0 ist für alle Zeiten meine Lieblingsrange, insbesondere in Firewall Allow Regeln. Damit darf jeder –wirklich JEDER- mit dem System auf Port 3302 kommunizieren. Vorausgesetzt natürlich man kennt seine Adresse (3.227.102.13) und hat valide Zugangsdaten (web_rfc). Beides kennen wir bereits.
Wir sind also jetzt in der Lage uns über RFC in das SAP-System von überall auf der Welt einzuloggen.
Als Proof of Concept soll uns das an dieser Stelle reichen.
Fazit
Die Cloud ist eine nicht zu unterschätzende neuer Sicherheitsebene für SAP-Systeme. Der Aufbau ist komplex und wurde hier nur angerissen. Die Anbieter bieten diverse Schutzmaßnahmen und Monitoring Instrumente, die gute Arbeit leisten. Der Lesbarkeit geschuldet, habe ich hier auf „Evasion“ Maßnahmen verzichtet, doch es gibt sie!
Diese neue Sicherheitsebene ermöglicht aber auch gänzlich neue Angriffswege, wie dieses Beispiel gezeigt hat. Von der Aufspürung der Systeme, über eine SSRF-Schwachstelle im Web-Server mit Zugriff auf die MetAPI haben wir Zugriff auf die AWS erhalten. Dort konnten wir die Zugriffskonfiguration zu dem SAP System einsehen und über die MetaAPI sogar Zugangsdaten finden. Damit war ein Zugriff auf das SAP-System möglich, was uns niemals ohne die „Cloud“ gelungen wäre. Dies bedeutet jetzt nicht, dass die Cloud unsicher ist. Es zeigt nur, wie ernst die neue Ebene zu nehmen ist. Denn es sind ganz neue Pfade zu den SAP-Systemen entstanden. Das Beispiel war bewusst einfach gewählt, doch auch die Ausweitung der Rechte in der Cloud, die Re-Konfiguration von Policies und Rollen ist ein gangbarer Weg, der „nur“ nicht in ein einfaches Bespiel passt. Letztlich haben wir gelernt, dass das „sicherste“ SAP-System dennoch angreifbar ist, wenn die Cloud-Umgebung nicht sicher ist.