Penetrationstests in der Cloud sind einzigartig und haben ihre eigenen Sicherheitsstandards. Obwohl die Sicherheitsmaßnahmen von Cloud-Anbietern einige Sicherheitslücken mindern können, sind viele Unternehmen aufgrund der Komplexität dieser Dienste immer noch gefährdet.
Die Unterschiede – Penetrationstests für Cloud-Infrastrukturen vs. traditionelle Infrastrukturen
Penetrationstests für Cloud-Infrastrukturen unterscheiden sich von Penetrationstest für traditionelle Infrastrukturen genauso deutlich wie sich Cloud-Infrastrukturen von traditionellen Hosting Infrastrukturen unterscheiden. Die Cloud-Penetrationstests von Redlings‘ zielen speziell auf diese Unterschiede ab und identifizieren die Konfigurations- und Implementierungsfehler, die häufig nicht überprüft werden. Cloud-Anbieter wie Amazon AWS, Google Cloud Platform (GCP) und Microsoft Azure bieten eine hohen Anzahl an Services, folgen jedoch im Allgemeinen einem Modell der geteilten Verantwortung, bei dem der Cloud-Anbieter für die Sicherheit der Cloud verantwortlich ist, z.B. für die Hardware- und Backend-Infrastruktur, und Sie sind für die Sicherheit in der Cloud verantwortlich, z. B. für die Konfiguration Ihrer Server, die in Ihrer Umgebung gewährten Berechtigungen und vieles mehr.
Wie Hacker normalerweise Zugriff auf Ihre Cloud Infrastruktur erlangen
Nachfolgend werden einige der gängigen Methoden beschrieben, mit denen böswillige Akteure Zugriff auf Ihre Cloud-Umgebung erhalten. Obwohl dies auf die Kompromittierung der Anmeldeinformationen von Amazon Web Services (AWS) abzielt, gelten diese Ideen für nahezu alle Cloud-Anbieter in größerem Maßstab. Einige dieser Methoden umfassen:
-
Ein Drittanbieters mit Zugriff auf Ihre Cloud-Infrastruktur verhält sich zweifelhaft oder bösartige und führt dabei Aktionen aus, welche Ihnen unbekannt sind.
-
Eine vertrauenswürdige Drittpartei mit Zugriff auf Ihre Cloud-Infrastruktur wird kompromittiert (Supply-Chain Szenarien).
-
Falsch konfigurierte Repositories führen zum Verlust von vertraulichen Daten.
-
Fehler während eines Commits führen zur Veröffentlichung vertraulicher Daten
-
Lokal gespeicherte Anmeldeinformationen, werden durch Local File Inclusion (LFI) oder Remote Code Execution (RCE) gestohlen wurden
-
Anmeldeinformationen werden durch Server-side request forgery (SSRF) entwendet
-
Eine bereits bekannte Datenbank eines Drittanbieters ist kompromittiert. Ihre Benutzer verwenden weiterhin ein kompromittiertes Kennwort.
-
Es erfolgt eine Wiederverwendung eines Kennworts für verschiedene Konten.
-
Phishing E-Mails oder Vishing (Voice-over-IP Phishing)
-
Physikalische Angriffsvektoren
-
Systeme von Mitarbeitern werden kompromittiert und bringen dies dann in Ihre Umgebung
-
Fehler von Mitarbeitern führen zu unbeabsichtigten Konsequenzen führen
Penetrationstests für Amazon Web Services (AWS)
Die AWS-Architektur besteht aus einer Reihe leistungsstarker APIs. Unsere Sicherheitsingenieure sind tief in das AWS-Ökosystem integriert und testen auf eine Reihe von AWS-spezifischen Fehlkonfigurationen, darunter die folgenden:
-
Analysieren Sie Berechtigungen auf Eskalationspfade für Berechtigungen (über Dienste wie Lambda, EC2 usw.).
-
Suchen Sie nach falsch konfigurierten Rollen und versuchen Sie, auf diese zuzugreifen
-
Stellen Sie die Persistenz durch Backdoor-Benutzer / -Rollen her
-
Auflisten von Instanzen, Sicherheitsgruppen und AMIs, um EC2-Angriffe durchzuführen
-
Missbrauch von Simple Systems Manager für den Remotezugriff auf Instanzen
-
Analysieren von EC2-Benutzerdaten auf Geheimnisse oder Systemanmeldeinformationen
-
Identifizieren von Routen zwischen VPCs für seitliche Bewegung und Eskalation
-
Überprüfen Sie, ob die Eimer falsch konfiguriert sind (nicht authentifiziert).
-
Überprüfen Sie nach der Authentifizierung den Zugriff auf S3-Buckets auf vertrauliche Dateien und Daten
-
Nutzen Sie vorhandene S3-Buckets, um Daten zu filtern oder weitere Angriffe durchzuführen
-
Analysieren Sie Code und Konfiguration, um vertrauliche Informationen preiszugeben
-
Eskalation von Berechtigungen durch Lambda IAM-Rollen und SDKs
-
Datenexfiltration durch Änderung der Datenverarbeitungsfunktionen
-
Erstellen Sie neue Lambda-Funktionen, um Angreifer auf Blue-Team-Aktivitäten aufmerksam zu machen (z. B. Entfernen früherer AWS-Hintertüren).
-
Ändern / Ausweichen von Sicherheitsgruppenregeln für den Zugriff auf RDS-Datenbanken
-
Umgehen der RDS-Authentifizierung durch Kopieren von Sicherungen und Ändern des RDS-Kennworts
-
Exfiltration von RDS-Daten über den kontenübergreifenden C2-Kanal
-
Verschiedene Methoden, um der Erkennung zu entgehen, Spuren zu verwischen und im Allgemeinen unter dem Radar zu bleiben
-
Herunterladen von Protokollen, um eine bessere Vorstellung von den allgemeinen Aktivitäten in der Umgebung
Microsoft Azure Penetrationstests
Penetrationstests in der Azure-Cloud sind einzigartig und bringen eigene Sicherheitsaspekte mit sich. Während einige Sicherheitslücken durch die Sicherheitsmaßnahmen von Azure gemindert werden, sind viele Unternehmen aufgrund der Komplexität dieser Dienste gefährdet. Eine der stärksten Funktionen von Azures ist die immense Flexibilität, die den Benutzern beim Einrichten der Umgebung geboten wird. Die Flexibilität ist zwar großartig, aber auch ein wichtiges Sicherheitsrisiko.
Die Penetrationstests von Redlings richten sich speziell an diese Anforderungen und identifizieren die Konfigurations- und Implementierungsfehler, die häufig nicht überprüft werden. Im Folgenden sind einige Beispiele für solche Cloud-Dienste aufgeführt, die getestet werden können:
-
Microsoft Azure
-
Office 365 / SharePoint Online / MS Teams
-
Microsoft Account
-
SharePoint Online
-
Visual Studio Team Services
-
Microsoft Dynamics 365
Google Cloud Platform (GCP) Penetrationstests
Bei unseren Bewertungen gehen wir über das automatisierte Scannen hinaus, um eine eingehende Bewertung Ihrer Umgebung zu ermöglichen. Wir prüfen auf verschiedene Schwachstellen und Fehlkonfigurationen, darunter:
-
Eskalationsprüfungen für Berechtigungen für alle IAM-Mitglieder (Benutzer / Dienstkonten), die auf Ihre Umgebung zugreifen
-
Überprüfen Sie, ob die geringsten Berechtigungen fehlen, und zeigen Sie, was ein Angreifer mit diesem zusätzlichen Zugriff tun würde
-
Analyse und Ausnutzung der Kubernetes Engine-Konfiguration
-
Testen von Sicherheitskontrollen (Können Sie erkennen, dass wir Daten von Ihren virtuellen Maschinen, Google Storage, Datenbanken oder anderen Stellen herausfiltern? Können wir uns Ihren technischen Kontrollen entziehen? Können Sie uns davon abhalten, böswillig zu handeln, oder uns erkennen, wenn wir dies tun?)
-
Best Practices: Stackdriver-Protokollierung / -Überwachung, Verschlüsselung, integrierte Sicherheitstools wie Cloud Security Scanner
-
Überprüfen Sie Ihren Außenumfang von innen: Was ist öffentlich sichtbar, was nicht sein sollte?
-
Eskalation / Missbrauch von Berechtigungen zwischen Benutzern, Projekten und Organisationen
-
Backdoor-/ Persistenzmethoden auf Accountbasis (Überleben des Angreifers trotz „erwischt werdens“)
-
Codeüberprüfung von Cloud-Funktionen, Ausnutzung durch Cloud-Funktionsauslöser, Konfiguration und Einrichtung
-
Wechseln zwischen Clouds / On-Premise-Umgebungen (Missbrauch von Cloud- / Umgebungsvertrauensstellungen durch Dienste / Funktionen wie Interconnect, gemeinsam genutzte VPCs und VPC-Peering)
