Wir freuen uns, die bahnbrechende Force Vision Threat Detection Enhancement für die werthAUDITOR Plattform ankündigen zu können!
Unser Force Vision-Modul ist als einzige SAP-Security Lösung in der Lage, unerwünschte privilegierte Anmeldungen in Echtzeit zu erkennen ohne sich dabei auf die übliche und anfällige Mustererkennung zu verlassen. Sicherheitsadministratoren können jetzt zuverlässig Anmeldungen erkennen, die eine Rechteausweitung missbrauchen oder gestohlene Administratoranmeldeinformationen verwenden. Denn Force Vision bewertet automatisch, ob es sich bei der Anmeldung um eine legitime Administratoranmeldung oder die Verwendung gestohlener Anmeldeinformationen handelt. Die integrierte Echtzeit-Erkennung erhöhter Berechtigungen zeigt jede Rechteausweitung bei normalen Benutzern an.
Somit ist eine unmittelbare Reaktion auf unerwünschte Systemzugriffe möglich.
Ab Sofort ist die Zukunft der Threat Detection auch für unsere Kunden verfügbar!
Beim Anzeigen von Webseiten in SAP Business Client mittels dieses Open-Source-Browser-Controls können sich verschiedene Schwachstellen, wie Speicherschäden, Offenlegung von Informationen usw. manifestieren. Diese Schwachstellen können sich wie folgt auswirken:
Offenlegung von Systeminformationen oder Systemabsturz
Auswirkung auf die Vertraulichkeit, Integrität und Verfügbarkeit eines Systems.
Ausnutzung der Informationen zur Durchführung von gezielten Angriffen mit ernsthaften Folgen.
Über offene Schnittstellen können von nicht authentifizierter Angreifern Vorgänge ausgeführt werden, die Benutzer und Daten im gesamten System beeinträchtigen. Der Angreifer erhält vollen Lesezugriff auf Benutzerdaten und kann eingeschränkte Änderungen an Benutzerdaten vornehmen. Zudem kann die Performance des Systems negativ beeinflusst werden.
Dies kann der Vertraulichkeit großen Schaden zufügen und hat begrenzte Auswirkungen auf die Verfügbarkeit und Integrität der Anwendung.
Ein authentifizierten Angreifer kann mit Hilfe der Schwachstelle vertrauliche Informationen lesen, die normalerweise eingeschränkt sind. Vollumfänglich Gefährdung der Anwendung möglich. Starke Beeinträchtigung der Vertraulichkeit, Integrität und Verfügbarkeit möglich.
Mögliche Ausnutzung einer Code-Injection-Schwachstelle, die einem Angreifer Zugriff auf Ressourcen ermöglicht, für die zusätzliche Berechtigungen erforderlich sind.
Starke Beeinträchtigung der Vertraulichkeit, Integrität und Verfügbarkeit des Systems
Die Schwachstelle führt nicht die erforderlichen Authentifizierungsprüfungen durch, was zu fehlenden oder falschen Berechtigungsprüfungen für einen authentifizierten Benutzer führen kann. Dadurch ist eine Rechteausweitung möglich. Abhängig von der Anwendung und der jeweiligen Berechtigungsebene kann ein Angreifer Funktionen missbrauchen, die auf eine bestimmte Benutzergruppe beschränkt sind, und eingeschränkte Daten lesen, ändern oder löschen.
Die Schwachstelle ermöglicht es einem Berichtsersteller, Dateien aus dem lokalen System über das Netzwerk in den Bericht hochzuladen. Nach Ausnutzung der Schwachstelle kann der Angreifer sensible Daten lesen und ändern, was große Auswirkungen auf die Vertraulichkeit und Integrität der Anwendung hat.
Ein authentifizierten Angreifer kann durch eine Aufforderung an einen offenen Port einen Speicherbeschädigungsfehler in einer Bibliothek verursachen, der zu einem Absturz der Zielkomponente führt. Dadurch ist sie nicht mehr verfügbar.
Die Code-Injection-Schwachstelle ermöglicht es einem Angreifer ohne Berechtigungen, unbemerkt VBScript-Code in ein Dokument hineinzubringen. Durch das Öffnen des Dokumentes führt die Anwendung den Code im Namen des unwissenden Benutzers aus.
Durch die Aktivierung von Sicherheitsoptionen in der Anwendung, die nicht als Standard festgelegt sind, werden nicht vertrauenswürdige Skripte deaktiviert oder der Benutzer wird zu einer Bestätigung der Ausführung aufgefordert.
Die Schwachstelle ermöglicht es dem Angreifer bei erfolgreicher Ausnutzung alle Betriebssystemdateien zu löschen. Dies hat eine eingeschränkte Auswirkung auf die Integrität und vollständig beeinträchtigt der Verfügbarkeit des Systems zur Folge.
Ein Angreifer kann einen JavaScript-Code einschleusen, der in der Web-Anwendung ausgeführt werden kann und somit das Systemverhalten der Anwendung steuern.
Durch die App werden nicht die erforderlichen Berechtigungsprüfungen für einen authentifizierten Benutzer durchgeführt. Ein Angreifer hat somit die Möglichkeit, unbeabsichtigte Aktionen ausführen. Dies führt zu einer Rechteausweitung, mit geringen Auswirkungen auf die Vertraulichkeit und Integrität ohne Auswirkungen auf die Verfügbarkeit des Systems.
Ein nicht authentifizierten Benutzer kann durch die Schwachstelle Code-Snippets über die UI lesen, was geringe Auswirkungen auf die Vertraulichkeit und keine Auswirkungen auf die Verfügbarkeit oder die Integrität der Anwendung hat.
Ein nicht autorisierter Benutzer kann anonym auf die Administratorsicht einer bestimmten Funktion zugreifen. Bei erfolgreicher Ausnutzung der Schwachstelle kann der Angreifer die E-Mail-Adresse des Benutzers anzeigen. Keine Auswirkungen auf die Integrität/Verfügbarkeit.
Durch die Anwendung kann ein authentifizierten Angreifer die XML-Datei als Anlage hochladen. Durch Anklicken der XML-Datei im Anlagenabschnitt wird die Datei im Browser geöffnet, sodass die Entitätsschleifen den Browser verlangsamen.
In a recent penetration test i had the pleasure to battle with a well known EDR system. The result was so surprising that I would like to report about it here.
Pattern based detection
The first lesson to learn was that EDR relies heavily on pattern based detection of malware. I had some evidence to support this thesis: known malware and attack patterns were detected and reported immediately.
The sticking point at this time, however, was that I already had a remote shell with NT system rights in which I tested the detection of the „known“ malware.
Bypassing EDR
So how did i manage to get so far without triggering EDR? This was so easy that i myself didn’t even noticed what i already did.
I’ve just been using self created remote shells, so no kind of pattern machting was able to detect them.
System access was possible with gathered credentials and abusing a service running as system.
Both kept undetected by EDR.
Pattern evasion
With a reliable shell i deceided to start powershell. The strong focus on pattern recognition should help me to bypass AMSI. So i just used a heavy obfuscation and a manual approach to disable AMSI. That worked like charm on the first try.
Loading additional powershell scripts didn’t raise any alarms.
Muting EDR
For completeness I have tried to silence the EDR. This was a task of minutes! I had several options. The core idea was to stop communication to the cloud. As i had enough rights to configure Firewall or DNS Resolution i was able to block that communication. From there no more alrams even for well known tools like mimikatz have been raised. Even abusing dumped credentials from lsass for lateral moving didnt trigger any alert.
Lessons learned
Within minutes using trivial methods EDR can bei bypassed! I won’t share any details here, but you know pattern evasion has a thousand possibilities. Blocking traffic is quite simple, too.
So what can a defender do? First, really evaluate your product of choice before implementation!
Second, listen also to the quiet sounds.
Even low suspicious events may be the tip of the iceberg. Be sensible and investigate – early!
Ask yourself, how could this happen? Why don’t I see more messages?
Ein durchdachtes und gepflegtes SAP-Berechtigungskonzept ist ein wichtiger Baustein für das Sicherheits- und Compliance-Rahmenwerk eines Unternehmens. Mangelndes Verständnis über die Bedeutung für Sicherheit- und Compliance oder historisch gewachsener Wildwuchs kann jedoch zu vielfältigen Risiken, wie Compliance-Verstößen, Diebstahl, Betrug oder Sabotage führen und erheblichen Schaden verursachen.
Hier sind die häufigsten Berechtigungsfehler, die uns in unserer Praxis begegnen:
Fehler # 1: Berechtigungen mit der
Gießkanne verteilen
Die inflationäre Vergabe von Zugriffsrechten ist einer der häufigsten Fehler in Unternehmen.
Wird nicht von Beginn an auf eine saubere Vergabe von Rechten geachtet, entsteht im Laufe der Jahre historisch gewachsener Wildwuchs. Durch geerbte Rollen oder Vertrauen in die Person erlangen Benutzer Zugriff auf sensible Daten oder Funktionen, die sie für ihre Arbeit nicht benötigen. Dadurch können folgende Szenarien entstehen:
• Ein Angreifer kann einen Account übernehmen und in Namen des Benutzers Schaden anrichten
• Ein böswilliger Benutzer kann weitreichende Zugriffsrechte ausnutzen, um eigene Interessen zu verfolgen
Die Vergabe von System- und Benutzerberechtigungen und sogar Notfallberechtigungen ist in der Praxis kein Einzelfall und kann verheerende Folgen für das Unternehmen haben. Dies gilt auch für Standard Benutzerkonten wie z.B. SAP * und DDIC.
Die restriktive Vergabe von kritischen Berechtigungen und die Vermeidung kritischer Rechtekombinationen ist für ein robustes Berechtigungsmanagement von zentraler Bedeutung.
Fehler #2: Schlecht konzipiertes
Rollendesign
Die SAP-Benutzerrollen sind als Schnittstelle zu den Berechtigungen ein wichtiger Bestandteil des SAP-Berechtigungsmanagements. Ein schlecht durchdachtes Rollendesign, in dem z.B. Rollen immer weitervererbt und mit zusätzlichen Transaktionen „bereichert“ werden, kann Sicherheitsrisiken, Compliance-Probleme und Ineffizienz zur Folge haben.
Daher sollten Unternehmen einen robusten Designprozess zur Entwicklung von Rollen etablieren, der auf Basis von Jobfunktionen, der Zuordnung der Rollen zu konkreten Funktionen und Daten sowie das Testen der Rollen einbezieht.
Auch das regelmäßige Kontrollieren der Rollen auf Aktualität, Relevanz und Effizienz ist für einen reibungslosen Prozess unabdingbar.
Fehler #3: Ignorieren
der Funktionstrennung (SoD)
Bei der Einrichtung von Berechtigungen und Benutzerrollen muss sichergestellt werden, dass kein einzelner User-Funktionen ausführen kann, die zu Missbrauch oder Fehlern führen können. Mit Hilfe der Funktionstrennung (SoD) soll innerhalb einer Organisation der Missbrauch kritischer Kombinationen von Tätigkeiten innerhalb eines Prozesses verhindert werden. Die Praxis jedoch zeigt, dass viele Unternehmen SoD ignorieren. Dadurch können erheblichen Sicherheits- und Compliance-Risiken entstehen.
Die regelmäßige Kontrolle der Benutzerzugriffe ist ebenso von großer Bedeutung und hilft dabei Konflikte in der Funktionstrennung sowie Verstöße gegen SoD-Richtlinien zu identifizieren und fehlerhafte Vergaben von Berechtigungen zu beheben.
Im Rahmen der SAP-Security ist ein gepflegtes Berechtigungsmanagement ein wichtiger Baustein und als permanenter Prozess zu sehen. Daher ist die regelmäßige Kontrolle der Berechtigungen, Benutzerrollen und Zugriffsrechte von großer Bedeutung. Um ein wirksames Berechtigungskonzept zu etablieren, ist es ebenfalls von großer Bedeutung, bei Administratoren und Benutzern das Bewusstsein für den Stellenwert von Sicherheitsmaßnahmen zu schärfen und Wissen in Form von Aus-und Weiterbildungen zu vermitteln.
Berechtigungsmanagement mit werthAUDITOR
werthAUDITOR bietet eine komfortable und einfache Lösung, um kritische Berechtigungen und – Rechtekombinationen zu identifizieren und in einer übersichtlichen Berechtigungsmatrix abzubilden. Mit Hilfe des integrierten Berechtigungssimulators lassen sich Rollen und Profile auswählen und on the fly analysieren, editieren und exportieren. Somit lässt sich der Prozess erheblich vereinfachen und typische Fehler können vermieden werden.
werthAUDITOR - Erfolgreicher Security Prozess durch Veredelung mit automatisiertem Task Management
Für einen wirkungsvollen Security Prozess ist es wichtig, dass die ermittelten Problemstellungen strukturiert und nachverfolgbar abgearbeitet werden können. Unsere Lösung unterstützt den Prozess, indem sie automatisierte Tickets mit allen Informationen erzeugt und aktualisiert. Aktuell unterstützt werthAUDITOR Jira, TheHive und ServiceNow.
• Kombination von SAP SQLA für PowerDesigner 17 mit SAP PowerDesigner 16.7 SP06 PL03ermöglicht Steuerung des Systemverhaltens durch Platzieren einer schädlichen Bibliothek, die von der Anwendung ausgeführt werden
• Cross-Site-Scripting (XSS) ermöglicht das Einfügen schädlichen Code in den Inhalt einer Webseite / Anwendung und an den Clienten zu senden >> Beeinträchtigung der Vertraulichkeit, Integrität und Verfügbarkeit der Anwendung
• Überschreibung einer ausführbaren Datei durch authentifizierten Angreifer im Netzwerk während Installationsprozesses möglich >> Gefährdung der Vertraulichkeit, Integrität und Verfügbarkeit des Systems
• Möglicher Zugang in den Netzwerkverbund der SAP-Systeme , die vom angegriffenen SAP-Message-Server gesteuert werden. >> unberechtigter Lese- und Schreibzugriffen auf Daten sowie zu einer Nichtverfügbakeit des Systems
• Absenden gezielter Abfragen über das Netzwerk möglich. SQL-Daten kann gelesen oder geändert werden >> Beeinträchtigung der Vertraulichkeit , der Integrität und Verfügbarkeit der Anwendung
• Cross-Site-Scripting-Schwachstelle (XSS) durch unzureichend kodierte benutzergesteuerte Eingaben (Einige Widgets auf der jQuery-UI vor Version 1.13.0)
Werth IT, Hersteller der prämierten SAP-Security-Lösung WerthAuditor bietet das, wonach viele SAP-Kunden seit langem suchen: ein tiefgreifendes und manipulationssicheres System zur Angriffserkennung und Sicherheitsbewertung ihrer SAP-Landschaft. Brandneu ist das Security Dashboard 2.0, das alle durch den WerthAuditor erkannten Sicherheitsrisiken in den Systemen visualisiert und eine Bewertung der zugehörenden Sicherheitsprozesse ermöglicht. Das interaktive und editierbare Dashboard bereitet übersichtlich alle Sicherheitsinformationen in Echtzeit auf.
Das neue Security Dashboard 2.0 der WerthAuditor-Plattform für SAP-Systeme ermöglicht wertvolle Analysen und Zugriff auf Sicherheitsdaten in Echtzeit
Der diesjährige 1. Mai war für viele IT-Experten nicht nur ein Feiertag, sondern vor allem ein Tag, der SAP-Kunden vor neue Herausforderungen stellt: Denn ab dem 1. Mai 2023 greift das IT-Sicherheitsgesetz 2.0 (kurz IT-SIG 2.0), das die deutsche KRITIS-Regulierung von 2015 deutlich erweitert. Das bedeutet: mehr Pflichten für Unternehmen und IT-Verantwortliche, höhere Cyber-Security-Anforderungen und erweiterte Befugnisse für Staat und Regulierungsbehörden. Eine anspruchsvolle Aufgabe für Unternehmen, die für ihre kritischen Infrastrukturen SAP einsetzen und somit im Fokus des IT-SIG 2.0 stehen, denn die meisten Lösungen erfüllen die steigenden Security-Anforderungen nicht im gewünschten Umfang.
Security Dashboard 2.0 – Angriffserkennung und Risiken auf einen Blick
Die neueste Innovation der Werth IT – ein übersichtliches Dashboard, das alle Sicherheitsrisiken sowie die dazu gehörenden Sicherheitsprozesse in den Systemen innerhalb einer Oberfläche in Echtzeit aufzeigt – kommt daher genau zur richtigen Zeit. Die Visualisierung sämtlicher Sicherheitsinformationen aller miteinander kommunizierenden Systeme der kompletten SAP-Landschaft zentral in nur einem Dashboard ist eine echte Innovation und ein Alleinstellungsmerkmal der Lösung. Zudem können Security-Fachkräfte aus dem Haupt-Dashboard heraus die für ihren Verantwortungsbereich relevanten detaillierteren Einzel-Dashboards ansteuern und tiefgreifende Informationen zu einzelnen Bereichen abrufen. Ebenfalls äußerst wertvoll: Das Dashboard zeigt in Echtzeit und en Detail, wie sicher die SAP-Landschaft aufgestellt ist, welche Rubriken zu verbessern sind und wo unmittelbares Handeln erforderlich ist.
Die wichtigsten Features des WerthAuditor in Überblick
Der WerthAuditor bietet SAP-Kunden eine umfassende Angriffserkennung: Er enttarnt Angriffe, deckt Sicherheitsrisiken auf und visualisiert die zugehörigen Sicherheitsinformationen – in allen miteinander kommunizierenden Systemen der IT-Landschaft. Jederzeit und in Echtzeit analysiert die Security-Lösung die Sicherheitskonfiguration, weist auf fehlende SAP-Security-Notes und Patches hin und überprüft den gesamten ABAP-Quellcode – und zwar nicht nur den für Kunden zugängigen Bereich, der lediglich einen kleinen Teil das ABAP-Codes ausmacht. Ferner prüft die Lösung das Betriebssystem, die Datenbanken, Schnittstellen sowie die Berechtigungen. Zusätzlich lässt sich an der Entwicklung des Security-Reifegerades sowie der Lebensdauer von Schwachstellen die Wirksamkeit der internen Security-Prozesse ablesen und analysieren.
Modernste, intelligente Security-Analyse mit mehr als 2.000 Prüfungen
Während herkömmliche Prüfsysteme die erhobenen Daten häufig in Tabellen darstellen, verwendet Werth IT die SIEM(Security Information and Event Management)-Technologie, mit deren Hilfe alle gesammelten Sicherheitsdaten vollständig über Schlagworte und beliebige Zeiträume filterbar sind und ganzheitliche, tiefgreifende Sicherheitsanalysen aller Systeme ermöglichen. Dies bedeutet zugleich maximale Effizienz für Threat Detection, Vulnerability Management und Patch Management.
Weitere wichtige Aspekte: Die Werth-IT-Lösung arbeitet mit Zero Footprint und erfordert keine Softwareinstallation beziehungsweise Agenten auf dem lokalen System. Ebenfalls wichtig: Die Lösung benötigt keine stehende Internetverbindung. Dadurch sind alle Sicherheitsdaten manipulationssicher, denn Angreifer der überwachten SAP-Systeme können nicht auf die Prüflogik, das Dashboard oder dessen Daten zugreifen.
Für die Sicherheits-Teams und die Verantwortlichen stehen mehrere vollständig anpassbare Dashboards zur Verfügung. „Das Management und die IT nutzen unser Security Dashboard für den Zugriff auf unverfälschte Echtzeitdaten, um auf dieser Basis kompetente und richtungsweisende Beschlüsse zu fassen. Mit über 2.000 Prüfungen und einem kontinuierlichen Monitoring liefert der WerthAuditor optimale Voraussetzungen, um alle Anforderungen des IT-SIG 2.0 zuverlässig zu erfüllen“, erklärt Thomas Werth, Geschäftsführer der Werth IT.
Das Security Dashboard 2.0 für SAP ist ab sofort verfügbar und als Webanwendung von jedem Device aus aufrufbar.
Das IT Sicherheitsgesetz Version 2.0 verpflichtet in §8 Unternehmen und Behörden, die zu den kritischen Infrastrukturen zählen, ein Angriffserkennungsystem für alle IT-Systeme zu etablieren, die Geschäftsprozesse der eigenen kritischen Dienstleistungen verarbeiten.
Aus meiner Sicht (keine Rechtsberatung!) könnte §8 wie folgt interpretiert werden:
Muss Vorgaben
Ein System zur Angriffserkennung für (kritische) IT-Systeme.
Kontinuierliche automatische Erfassung und Auswertung geeignerter Parameter und Merkmale (Logs, Konfigurationsparameter,..)
Sollte Umgesetzt werden
Fortwährende Identifizierung von Bedrohungen
Ausführen und Anzeigen von Maßnahmen zur Vermeidung und Beseitigung für (eingetretene) Störungen
Was ist zu tun?
Laut Gesetz sind die Anforderungen zum 01.05.2023 zu erfüllen. Entsprechend sollten betroffene Unternehmen prüfen, welche Systeme gemäß IT-SiG 2.0 betroffen sind. Dies in einer für einen Auditor nachvollziehbaren Form.
Es folgt die GAP Analyse bei der Angriffserkennung. Sind diese Systeme mit einer wirksamen Lösung abgedeckt?
Falls nicht besteht Handlungsbedarf und der Support des Management ist einzuholen, um eine wirksame Lösung (beispielsweise den werthAUDITOR für SAP-Systeme) zu beschaffen und in Betrieb zu nehmen.
In diesem Beitrag stelle ich ausschließlich meine persönliche Meinung als Elternteil dar. Es handelt sich hierbei um ein Privatposting und keine Veröffentlichung der Werth IT GMBH.
Elternfinanzierte 1:1-iPad- Ausstattungen an deutschen Schulen
Viele Schulen sind dabei den digitalen Unterricht voranzutreiben. Dazu setzen sie auf die privaten iPads der Schüler. Dies vornehmlich aus dem Grund, dass Schulen und Schulträger ganz überwiegend nicht über die erforderlichen Mittel verfügen, um die gesamte Schülerschaft, bzw. alle Klassen mehrerer Jahrgänge mit digitalen Endgeräten auszustatten.
Gemeinsam mit den Kollegen von Chaos macht Schule des CCC habe ich zu diesem Thema den ausführlichen Artikel „Bring your own devices an Schulen“ in der „datenschleuder Nr. 106“ veröffentlichen dürfen. Der kritische Blick auf die elternfinanzierten Geräte macht den Artikel zur Pflichtlektüre für Schulen, Schulträger, Eltern und Elternräte. In dem Artikel wird schonungslos angesprochen welche bürokratischen Hürden die Institutionen nehmen müssen und Eltern & Schüler erhalten einen ungeschönten Einblick worauf sie sich einlassen, wenn eine elternfinanzierte 1:1 iPad Ausstattung an ihrer Schule eingeführt wird.
Wie bewerten Landesdatenschutzbehörden den Einsatz von BYOD an Schulen?
Oftmals können die Schulen keine umfassende Aufklärung der Eltern leisten. Umso erfreulicher, dass sich die Landesdatenschutzbehörden bereits (eingeschränkt) zu dem Einsatz privater Geräte an Schulen geäußert haben.
Die LDI NRW hat mit Stellungnahme vom 31.10.2022 nur schulischen Geräten eine datenschutzkonforme Anwendung bescheinigt. Hingegen „sieht die LDI NRW den Einsatz privater Endgeräte nicht nur bei Lehrkräften, sondern auch bei Schülerinnen generell kritisch. … Daher kann der Einsatz privater Endgeräte – auch im Interesse der Schulen, die für die Wahrnehmung ihres Bildungsauftrags auf digitale Lösungen setzen – nur übergangsweise in Betracht kommen. … Um die hiermit verbundenen rechtlichen Unsicherheiten zu vermeiden, empfehlen wir Ihnen, alle Schülerinnen möglichst kurzfristig mit schulischen Endgeräten auszustatten und damit die dauerhafte Gewährleistung von Datenschutz und –sicherheit zu ermöglichen.“
LDI Vorgaben für eine übergangsweise Nutzung von BYOD
Den Einsatz von elternfinanzierten iPads knüpft die LDI an einige Bedingungen:
Umsetzung von technischen und oragnisatorischen Maßnahmen zur Gewährleistung des Datenschutzes der Schüler. Hier ist ein umfassendes Paket zu implementieren, um das Missbrauchspotential der totalen Kontrolle über die private iPads abzumindern.
Echte freiwillige und nachteilsfreie Wahl, so dass eine Elternfinanzierung weder direkt noch indirekt zur Sicherung der Teilhabe an der digitalen Ausbildung ist. Somit muss die Schule jedem Schüler ein Leihgerät stellen, der nicht sein privates Gerät in das MDM einbinden lassen möchte.
Aufklärung und Information der Eltern über die Einbindung der BYOD Geräte in ein schulisches MDM inklusive supervised Mode.
Jederzeitiges Widerrufsrecht.
Durch die private Nutzung der durch die Schule voll kontrollierten, gesteuerten und überwachten BYOD Geräte ergeben sich weitere zu prüfende Aspekte.
Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO
Grundlegend muss jede Schule gewährleisten, dass die Anforderungen bezüglich Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO erfüllt werden. Aufgrund der unklaren Aussagen(AGBs, Handbuch) über die Erhebung und Nutzung der Daten (u.a. Telemetrie) der nutzenden Schüler*innen, erscheint es unmöglich für den Auftraggeber (Schule) hier eine den Anforderungen entsprechende Auskunft an die Nutzenden (Schüler*innen) geben zu können.
Teacher Tools und Teacher App
Ein wesentlicher Grund warum die Schulen sich für Apple und dem MDM entscheiden sind die Apple Teacher Tools in Kombination mit der MDM Teacher App.
Die Apple Classroom App aus den Teacher Tools erlaubt es einer Lehrkraft jederzeit auf den Bildschirm eines Schülers in seiner Klasse zuzugreifen.
Die Funktion „Klassenzusammenfassung“ liefert ein Aktivitäts- und Leistungsprotokoll über die Schüler in der Klasse.
Die Teacher App (https://relution.io/insights/relution-teacher) erlaubt es einer Lehrkraft Richtlinien (Ad-Hoc) für die Schüler Geräte festzulegen (https://www.youtube.com/watch?v=_r5Mxzfvy0s) . Damit kann eingeschränkt werden (optional) welche Apps, System Apps oder Webseiten zugelassen sind. Diese Profile lassen sich sogar mit der Option „Persönliches Unterrichtsprofil“ vor anderen Lehrkräften verbergen.
Apple Classroom
Die App Classroom erlaubt es einer Lehrkraft jederzeit auf den Bildschirm einer Schülerin oder eines Schülers in ihrer Klasse zuzugreifen. Dies ermöglicht eine umfangreiche und anlasslose Datenerhebung/ Überwachung der Schülerinnen und Schüler. Diese sehen nur anhand der Anzeige eines blauen Punktes am Bildschirmrand, ob die Lehrkraft gerade die Funktion „Screens der Schüler ansehen“ aktiviert hat oder nicht. Der Einzelne kann nicht erkennen, ob die Lehrkraft gerade auf seinen Bildschirm schaut oder nicht. Auch im Nachhinein werden die Schülerinnen und Schüler darüber nicht regelmäßig informiert. Diese Funktion / Vorgehensweise unterscheidet sich ganz erheblich vom analogen Unterricht, bei dem Schülerinnen und Schülern bekannt ist, wann jemand auf die eigenen Unterlagen schaut.
Dauerhafte und anlasslose Überwachungsmöglichkeit vs Art. 7 DSGVO, Erwägungsgrund 39
Es entsteht ein permanenter Überwachungsdruck und Mangel an Privatsphäre während der Bearbeitung (z.B. falls nicht abgabereife Notizen/Aufgaben der Schülerinnen und Schüler von der Lehrkraft angeschaut werden oder persönliche Daten geöffnet sind). Der bloße Verdacht, dass Schülerinnen und Schüler in der Schule digital Angelegenheiten erledigen, die als privat zu klassifizieren sind oder nicht angemessen, sollte nicht deren lückenlose Überwachung legitimieren. Die Durchführung einer dauerhaften und anlasslosen Überwachung -ohne dass es von den Schülerinnen und Schülern bemerkt wird- erscheint nicht legitim. Eine Beobachtung der Schülerleistungen per Videokamera im Klassenraum wäre ja auch nicht zulässig. Personenbezogene Daten sollten nur dann verarbeitet werden, wenn sich der Zweck (hier: sich einen Eindruck verschaffen und pädagogisch begleiten) der Verarbeitung nicht auf andere zumutbare Weise erreichen lässt (Art. 7 DSGVO, Erwägungsgrund 39).
Gefahr der Verhaltensänderung bei Schüler*innen
Die Tatsache, dass über den gesamten Schultag jederzeit unangekündigt der Bildschirm überwacht werden kann, könnte zu einem angepassten und veränderten Verhalten führen. Es besteht die Gefahr, dass die Entwicklung der Schüler nachhaltig durch die Angst vor Überwachung beeinträchtigt wird. „Die freie Selbstbestimmung bei der Entfaltung der Persönlichkeit werde gefährdet durch die Bedingungen der modernen Datenverarbeitung. Wer nicht wisse oder beeinflussen könne, welche Informationen bezüglich seines Verhaltens gespeichert und vorrätig gehalten werden, werde aus Vorsicht sein Verhalten anpassen (siehe auch Panoptismus). Dies beeinträchtige nicht nur die individuelle Handlungsfreiheit sondern auch das Gemeinwohl, da ein freiheitlich demokratisches Gemeinwesen der selbstbestimmten Mitwirkung seiner Bürger bedürfe.“ (Wikipedia). Es besteht durch die Schulpflicht für Schülerinnen und Schüler faktisch Zwang zur Nutzung von Tablets und Lernplattformen, sie müssen sich durch die Tabletnutzung der umfassenden Beobachtung ergeben und können sich ihr nicht entziehen. Das Sammeln von Daten über die Lernenden fügt negativ auswirkende Facetten hinzu. Die Lehrkräfte bekommen weitere Kontrollinstrumente an die Hand, mit denen sich umfassende Kontrolle manifestiert.
„Es muss sichergestellt sein, dass die Lehrkräfte nicht nachverfolgen können, wie lange die Schülerinnen und Schüler an den jeweiligen Dokumenten gearbeitet haben. Denn dies würde im Vergleich zum analogen Schulalltag, in dem solche Auswertungsmöglichkeiten nicht bestehen, einen unverhältnismäßigen Eingriff in das Recht auf informationelle Selbstbestimmung der Schülerinnen und Schüler darstellen.“
Eckpunkte für den datenschutzkonformen Einsatz von digitalen Lernplattformen in den niedersächsischen Schulen (Stand: Juni 2022)
Datenschutzfragen / DSGVO Art. 15
Wie können die Nutzer in Erfahrung bringen und nachvollziehen, welche Daten wann mit der „Klassenzusammenfassung“ oder der Bildschirmeinsicht über sie erhoben wurden? Wie kann das Recht auf Auskunft (z.B. wann eine Lehrkraft Bildschirmeinsicht genommen hat) umgesetzt werden? Welche Vorkehrungen sind hierfür für das Auskunftsrecht nach Art. 15 DSGVO getroffen?
Die Teacher App erlaubt es einem Einzelnen -ohne 4 Augen Prinzip oder technischen Einschränkungen- jederzeit Richtlinien für die Geräte “seiner” Klasse zu erzeugen und diese sogar vor anderen Lehrkräften zu verstecken. Zusätzlich kann über die App jederzeit ein Unterricht gestartet werden. Jemand könnte jederzeit auf diesem Weg eine Richtlinie (ohne Einschränkungen für die SuS Geräte, um „unbemerkt“ zu bleiben) erzeugen und vor anderen Lehrkräften verbergen. Dann könnte er damit zu einem beliebigen Zeitpunkt einen Unterricht für (gezielt ausgewählte) SuS starten und direkt im Anschluss mit Apple Classroom sich Zugriff auf dessen Bildschirm verschaffen. Ob Schüler und Schülerinnen (SuS) diesen Zugriff bemerken und “verstehen” bleibt fraglich, da auf dem IPAD der SuS kein Hinweis oder eine Informationsmeldung erscheint (https://youtu.be/ZG3mmnxUW-E?t=349) .
Fragenkatalog Datenschutz BYOD iPads an Schulen
Die hier ausgewählten Beispiele zeigen den weiteren Prüfbedarf auf. Mein Paper Digitaler Unterricht – Chaosfrei? – Eine technische Risikobetrachtung gewährt einen tieferen Einblick in die Welt des Datenschutzes und der Datensicherheit inklusive Betrachtung rechtlicher und organisatorischer Fragen. Aus diesem Paper stammt die folgende Auflistung der zu betrachtenden Aspekte bei dem Einsatz von elternfinanzierten iPads an Schulen.
Gewährleistung eines freiwilligen und nachteilsfreien Angebotes (z.B. Leihgeräte) inklusive Widerrufsrecht und Aufklärung bei BYOD Geräten. Festlegung eines angemessenen Zeitraumes für eine möglichst kurzfristige übergangsweise Nutzung privater IPADs. (Kapitel 10 Punkt Bewertung LDI NRW (Auskunftsverfahren, Teilaspekte)
Ist die Gewährleistung der Anforderungen bezüglich der Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO durch die Schule sichergestellt? ( Kapitel 10 Datenschutz Problematiken Punkt 1)
Es ist zu prüfen, ob die Funktionen der Apple Teacher Apps wie die Classroom Funktion „Viewing Students Device Screen“ datenschutzkonform auf privaten und Leihgeräten genutzt werden können. Insbesondere in Kombination mit den Möglichkeiten der Relution Teacher App ist der Datenschutz für SuS zu gewährleisten. Zudem ist zu prüfen, ob die Erhebung der Aktivitäts- und Leistungsdaten durch Apple Schoolwork/Classroom zulässig ist. (Kapitel 5 Apple Teaching Tools )
Existieren Regelungen und Dienstanweisungen wann und wie Lehrkräfte die Möglichkeiten der Tools nutzen dürfen/können? Beispielsweise: ● Darf eine Lehrkraft Screenshots von dem Bildschirm eines Schülers anfertigen? Falls ja, unter welchen Voraussetzungen? ● Wann darf eine Lehrkraft den Bildschirminhalt eines Schüler IPADs auf die Tafel / Bildschirm spiegeln? Muss/Kann der Schüler zuvor zustimmen? Welche Voraussetzungen sind zu erfüllen, damit keine Inhalte angezeigt werden, die der Schüler nicht teilen möchte? (Kapitel 5 Apple Teaching Tools )
Wie können die Nutzer in Erfahrung bringen und nachvollziehen, welche Daten wann mit der„Klassenzusammenfassung“ oder der Bildschirmeinsicht über sie erhoben wurden? Wie kann das Recht auf Auskunft (z.B. wann eine Lehrkraft Bildschirmeinsicht genommen hat) umgesetzt werden? Welche Vorkehrungen sind hierfür für das Auskunftsrecht nach Art. 15 DSGVO getroffen? (Kapitel 5 Apple Teaching Tools )
Gewährleistung, dass bei ein Auftragsverarbeiter einer öffentlichen Einrichtung (Schule) keinerlei persönlichen Daten der Nutzenden für eigene Zwecke verwendet wird – wie jedoch in den Apple AGBs angegeben. ( Kapitel 10 Datenschutz Problematiken Punkt 2)
Vor dem Hintergrund der Datenkommunikation mit Servern eines US-Herstellers ist der Schutz aller Daten der Kinder vor unberechtigtem Zugriff durch Dritte sicherzustellen. „Dabei ist der entscheidende Aspekt, ob die Schule als öffentliche Einrichtung personenbezogene Daten (von Kindern) in einer (europäischen) Cloud speichern kann, die z.B. einem möglichen Zugriff US-amerikanischer Behörden ausgesetzt ist. Öffentliche Einrichtungen in Deutschland haben eine besondere Verantwortung hinsichtlich der Zulässigkeit und Nachvollziehbarkeit der Verarbeitung personenbezogener Daten.“. (ITMediaLaw) ( Kapitel 10 Datenschutz Problematiken Punkt 2)
Existiert ein (unabhängiger) Nachweis, dass die notwendigen TOMs (Change Management vorhanden? ; Teacher App & Classroom Zugriff) wirkungsvoll für die tatsächliche Infrastruktur (shared Server?) implementiert sind? (Mehrere Kapitel verweisen auf notwendige TOMs)
Es ist zu prüfen, ob der Einsatz der Plattform Office 365 und deren Apps datenschutzkonform ist, da diese Plattform in der Schule verwendet wird und deren Apps automatisch durch die Schule aufgespielt werden. (Kapitel 9 Risiko von durch die Einrichtung installierten Apps )
Was kann man als Betroffene tun?
Oftmals ist die Aufklärung durch die Institution unzureichend und die Angst vor Nachteilen, wenn man nicht „mitzieht“, ist groß. Der Druck auf die Schüler ist ebenfalls nicht zu leugnen, da ja „alle“ mitmachen und weder Eltern noch Schüler verstehen was da genau auf einen zu kommt und welche Optionen einem eigentlich zustehen. Nicht immer ist die Kommunikation mit der Schule zu diesem Punkt einfach und man kann schnell eine gemeinsame Lösung finden.
Ob diese Art der Kommunikation strategisch ist, lässt sich nicht mit Sicherheit beantworten. Allerdings spricht die Empfehlung des Medienzentrums Cloppenburg für sich.
FAQ des Medienzentrums Cloppenburg wie Schulen Tablets einführen sollen
In solchen Fällen findet jeder Betroffene (Eltern oder Schüler) Hilfe bei seiner zuständigen LDI. Dort kann man mit eine formlosen E-Mail eine Anfrage/Beschwerde einreichen. Dies ist jederzeit möglich – sowohl VOR der Einführung als auch DANACH. Wie hier dargestellt existieren Auflagen für einen BYOD Einsatz und mehrere kritische Punkte sind zum jetzigen Zeitpunkt noch ungeklärt.
Eine Inspiration für eine solch formlose Anfrage stelle ich in meiner Vorlage bereit. Diese Vorlage stellt keine juristische Beratung oder Dienstleistung dar und ist meine rein private und subjektive Sicht der Dinge.
In der Vorlage ist der Kontakt zu der LDI NRW enthalten, andere LDI sind eigenständig im Internet zu suchen (postestelle@xyz ist ausreichend). Die Vorlage ist auf die persönliche Situation anzupassen und stellt nur eine Inspiration dar.
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. “
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.
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/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.
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:
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:
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.
