Je nach Art und gewählten Vorbedingungen sind gewisse Bedrohungen identifizierbar. In diesem Blogartikel soll es nun um die Vorstellung einer der am weitesten verbreiteten Methoden für Cloud Penetrationtests gehen, dem Assumed Breach Ansatz. Hierbei werden wir Ihnen aufzeigen aus, welcher Perspektive und mit welchen Vorbedingungen solch ein Test durchgeführt wird. Je nach Art und gewählten Vorbedingungen sind gewisse Bedrohungen identifizierbar.
Assumed Breach – Interne Bedrohungen in der Cloud
Interne und externe Bedrohungen
Zuerst wollen wir aber auf unterschiedliche Arten von Bedrohungen für ein Unternehmen eingehen, um so die Perspektive der Assumed Breach Methodik besser verstehen zu können. Generell lassen sich Bedrohungen im Bereich der Cyber-Sicherheit in zwei Kategorien einteilen.
- Externe Bedrohungen
- Interne Bedrohungen
Externe Bedrohungen stellen dabei die Bedrohung dar, welche von den meisten Verantwortlichen für die Sicherheit eines Unternehmens am ehesten war genommen wird. Hierbei kann es sich um klassische Angriffe durch Hacker, Phishing- oder Ransomeware-Kampagnen handeln. Die Perspektive des Angreifers ist die eines Außenstehenden und die interne Infrastruktur ist für ihn nur eine Blackbox. Sollte ein Penetrationstest aus dieser Perspektive durchgeführt werden, reden wir von einem klassischen Blackbox Penetrationstest. Bei einem Blackbox Cloud Penetrationstest interagieren die Security Consultants also nur mit wenigen ins Internet exponierten Systemen und versuchen über diese in das interne Netzwerk zu gelangen.
Bei internen Bedrohungen auf der anderen Seite wird bei einem Penetrationstest davon ausgegangen, dass ein Angreifer es geschafft hat bei einem Blackbox Angriff in die interne Infrastruktur einzudringen. Nun hat dieser Zugriff auf Zugangsdaten zu einem Benutzerkonto und kann mit diesen versuchen weitere interne Systeme anzugreifen. Oft wird diese Perspektive von Verantwortlichen für die IT-Sicherheit nur peripher betrachtet da ein Angreifer „erst mal rein kommen muss“. Dies stellt aber einen fatalen Fehler dar, da es viele unterschiedliche Wege gibt, wie ein Angreifer von einer externen Bedrohung zu einer internen werden kann.
Angriffswege für die initiale Kompromittierung
Im Folgenden wollen wir kurz auf ein paar der gängigsten Wege eingehen, wie aus einem externen ein interner Angreifer werden kann. In unserer Arbeit als Incidence Response Dienstleister ist es essenziel zu evaluieren wie die initiale Kompromittierung stattgefunden hat. Oft handelt es sich dabei um einen der folgenden Angriffswege:
- Leaks von Benutzernamen und Passwörtern: Wenn Benutzernamen und Passwörter aus früheren Datenlecks im Darknet veröffentlicht werden, können Angreifer diese Informationen nutzen, um sich mit bekannten Zugangsdaten in ein Unternehmensnetzwerk einzuloggen.
- Unsichere Benutzerpasswörter: Schwache oder leicht zu erratende Passwörter bieten eine einfache Angriffsfläche. Angreifer nutzen dabei oft einfach schwache Passwörter, wie „Sommer2024!“ aus und testen diese bei vielen Mitarbeitern eines Unternehmens. Solch ein Angriff nennt sich Password Spraying.
- Gezielte Phishing Kampagnen: Bei gezielten Phishing-Angriffen senden Angreifer betrügerische E-Mails an Mitarbeiter, die dazu verleiten sollen, vertrauliche Informationen preiszugeben oder schädliche Anhänge zu öffnen. Erfolgreiche Phishing-Angriffe können den Angreifern Zugangsdaten oder direkten Zugang zu einem Unternehmensnetzwerk verschaffen.
- Veraltete Software: Software, die nicht auf dem neuesten Stand gehalten wird, enthält oft bekannte Sicherheitslücken, die Angreifer leicht ausnutzen können. Durch die Ausnutzung dieser Schwachstellen können Angreifer schädlichen Code ausführen und so einen Fuß in die Tür des Unternehmensnetzwerks bekommen.
All solche Wege stellen oft keine Hürde für einen erfahrenen Angreifer dar und so wird aus einer externen Bedrohung eine interne.
Assumed Breach: Die Simulation einer internen Bedrohung
Bei der Assuemd Breach Methode wird generell davon ausgegangen, dass ein Angreifer es geschafft hat die ersten Schutzmaßnahmen eines Unternehmens zu überwinden und mit gültigen Benutzerdaten im internen Netzwerk ist. Bei einem Cloud Penetrationstest bedeutet dies der Security Consultant erhält Zugriff zu niedrig privilegierten Benutzerdaten mit welchen er mit der Cloud Infrastruktur des Kunden interagieren kann. Dies können unterschiedliche Arten von Benutzerkonten sein.
- Dedizierte Viewer/Reader-Only Rolle
- Normaler Benutzer-Account
- Service-Account einer Cloud-Ressource, wie einer VM
Aus dieser Perspektive beginnt der Cloud Penetrationstester nun die Infrastruktur zu enumerieren und Fehlkonfigurationen zu identifizieren. Aus der Kombination von unterschiedlichen Fehlkonfigurationen lassen sich dann Schwachstellen bauen, welche genutzt werden können, um sich in der Cloud Umgebung weiter vorzuarbeiten. Dabei kann sich ein Angreifer in unterschiedlichen Richtungen „bewegen". Vom sogenannten „Lateral Movement“ spricht man, wenn ein Angreifer es schafft weitere Systeme oder Accounts auf der gleichen ebene zu übernehmen. Gelingt es einem Angreifer höherer Rechte zu erlangen handelt es sich um eine „Privilege Escalation“. Bei einem Assumed Breach Cloud Penetrationstest wendet der Security Consultant nun unterschiedliche Varianten von „Lateral Movement“ und „Privilege Escalation“ an mit dem Ziel am Ende Global Administrator der Cloud Umgebung zu werden. Dabei interagiert und testet er am Ende alle vorhandenen Ressourcen einer Cloud Infrastruktur und erhält so eine vollständige Testabdeckung.
Abgrenzung zum externen Blackbox Test
Der gängigste Ansatz bei einem externen Penetrationstest in der Cloud ist, wie bereits beschrieben, der Blackbox Ansatz. Hierbei erhält ein Security Consultant wenig bis keinerlei Information über die zu testende Infrastruktur. Dies bedeutet er interagiert einen Großteil des Testzeitraums nur mit wenigen nach außen sichtbaren Ressourcen der Cloud Infrastruktur.
Dies kann dazu führen, sofern die externe Absicherung sehr sorgfältig durchgeführt worden ist, dass ein Security Consultant in dem kurzen Testzeitraum keinen erfolgreichen Angriffsweg in die restliche Cloud Infrastruktur findet. Wie in der unteren Grafik zu sehen ist kann dies dazu führen, dass ein Angreifer nur einen geringen Teil der Infrastruktur testen kann. So könnte es dazu kommen Schwachstellen in internen Cloud Infrastrukturen und Netzwerken nicht identifiziert werden können.
Bei dem Assumed Breach Ansatz auf der anderen Hand, wird wie bereits beschrieben, eine interne Bedrohung simuliert. Diese kann nun während des Testzeitraums mit allen internen Cloud Ressourcen und Netzen interagieren aber ebenso mit alle nach außen verfügbaren. So erhalten wir bei einem Cloud Penetrationstest nach dem Assumed Breach Ansatz immer eine deutlich höherer Testabdeckung in einer gegebenen Zeit. Es sollte dabei nie aus den Augen gelassen werden, dass ein wirklicher Angreifer keine zeitliche Beschränkung wie ein Cloud Penetrationstest hat. So kann dieser deutlich mehr Zeit und Ressourcen in die Identifikation von externen Angriffswegen stecken, als dies im Rahmen eines Blackbox Cloud Penetrationstest möglich ist. Daher empfehlen wir in den ersten Scoping Gesprächen jedem unserer Kunden auf die Durchführung eines Cloud Penetrationstest im Blackbox Format zu verzichten und stattdessen einen Assumed Breach Ansatz zu verfolgen.