Whitelisting reicht nicht aus: Warum Cloud-Workloads umfassendere Sicherheitsstrategien benötigen

Cloud-Umgebungen entwickeln sich rasant weiter – mit ihnen steigen auch die Anforderungen an deren Absicherung. Wie ein aktueller Blogbeitrag von Infoblox erläutert, reicht es längst nicht mehr aus, ausschließlich auf Whitelisting als Sicherheitsmaßnahme zu setzen. Insbesondere in dynamischen Cloud-Umgebungen, in denen Workloads regelmäßig mit Drittanbieterdiensten, APIs und Plattformen interagieren, stößt das Whitelisting schnell an seine Grenzen. Zwar gehört es zu den etablierten Methoden, um ausgehende Verbindungen zu kontrollieren, doch die Realität sieht oft komplexer aus: Die Vielzahl an sich ständig ändernden Abhängigkeiten und Endpunkten macht es nahezu unmöglich, Whitelists aktuell und vollständig zu halten.

Hinzu kommt: Selbst als vertrauenswürdig eingestufte Domains können kompromittiert werden – etwa durch Domain-Hijacking oder gezielte Angriffe auf Lieferketten. In solchen Fällen schützt Whitelisting kaum noch vor Datenabfluss oder Schadsoftware.

Infoblox zieht einen passenden Vergleich: Sich ausschließlich auf Whitelisting zu verlassen, sei wie „die Haustür abzuschließen, aber die Fenster offen zu lassen“. Der Beitrag beleuchtet nicht nur die operativen Herausforderungen dieser Methode, sondern zeigt anhand konkreter Sicherheitsvorfälle auf, welche Lücken durch eine einseitige Strategie entstehen können – und warum ein mehrschichtiger, dynamischer Ansatz zur Absicherung von Cloud-Workloads heute unverzichtbar ist.

Einschränkungen der Sicherheit durch Whitelisting

Whitelist-Ziele können kompromittiert werden

Selbst vertrauenswürdige, auf der Whitelist stehende Dienste wie GitHub, Dropbox oder Slack können von Angreifern für Datenexfiltration oder Command-and-Control (C2) missbraucht werden.

Beispiel: Angreifer nutzen GitHub-Repositorys oder Gist als C2-Kanal. Wenn GitHub auf der Whitelist steht, können bösartige Workloads weiterhin „nach Hause telefonieren“.

Abhängigkeiten von Drittanbietern oder SaaS-Integrationen können gekapert werden

Cloud-Workloads kommunizieren häufig mit APIs oder Diensten (z. B. NPM, PyPI, S3-Buckets), die manipuliert werden können.

Beispiel: Der SolarWinds Orion-Hack umfasste ein Update von einer vertrauenswürdigen, signierten Quelle, das für böswillige Zwecke missbraucht wurde. Wenn der Update-Server von SolarWinds auf der Whitelist stand, konnte das bösartige Update dennoch durchgeführt werden.

DNS-Tunneling oder Domain-Fronting innerhalb zugelassener Domänen

DNS-Anfragen an zugelassene Domänen (wie *.google.com) können zum Tunneln von Daten verwendet werden.

Beispiel: Der Cobalt Strike-Beacon kann DNS-Tunneling verwenden. Selbst wenn die Domäne zugelassen ist, sind die darüber übertragenen Daten bösartig.

IP-Whitelisting in der Cloud ist anfällig

Viele SaaS- und Cloud-Dienste verwenden gemeinsam genutzte IP-Pools oder Content Delivery Networks (CDNs) wie Cloudflare. Ein bösartiger Dienst, der im selben IP-Bereich gehostet wird, kann Filter umgehen.

Beispiel: Ein Angreifer verwendet dasselbe CDN wie ein auf der Whitelist stehender SaaS-Dienst, um Daten zu exfiltrieren.

Zero-Day-Exploits oder Supply-Chain-Angriffe

Workloads können aufgrund von Schwachstellen in Bibliotheken, Containern oder APIs kompromittiert werden, und diese Workloads können dann bösartige ausgehende Anrufe an Dienste auf der Whitelist tätigen.

Beispiel: Bei der Log4Shell-Sicherheitslücke (Log4j) konnten kompromittierte Systeme ausgehende JNDI-Lookups (Java Naming and Directory Interface) an LDAP-Server (Lightweight Directory Access Protocol) auf der Whitelist senden, die bösartige Payloads hosteten.

Fehlkonfigurationen in Whitelists

Wenn eine Domain wie *.amazonaws.com auf einer Whitelist steht, kann eine kompromittierte Workload auf vom Angreifer kontrollierte Amazon S3-Buckets oder Elastic Compute Cloud (EC2)-Instanzen zugreifen.

Beispiel: Der Angreifer richtet bösartige Inhalte in einem regionsspezifischen S3-Bucket (malicious-bucket.s3.us-west-2.amazonaws.com) ein, der von einer umfassenden Whitelist abgedeckt ist.

Beispiele für Sicherheitsverletzungen aus der Praxis

Versierte Angreifer haben Techniken entwickelt, um Whitelisting zu umgehen. Damit zeigen sie, dass selbst Datenverkehr, der auf „genehmigte“ Ziele beschränkt ist, böswillige Kommunikation über legitime Kanäle ermöglichen kann.

Domain Fronting: Ausnutzung von CDNs

Domain Fronting ist eine wirksame Methode, um Whitelisting zu umgehen, indem böswilliger Datenverkehr als legitime Kommunikation über CDNs getarnt wird. Mithilfe von HTTPS-Verschlüsselung tarnen Angreifer Datenverkehr zu böswilligen Zielen als Interaktionen mit Domains, die auf der Whitelist stehen. Wenn beispielsweise eine Workload eine Verbindung zu einem legitimen, von Akamai gehosteten Dienst wie www.disney[.]com herstellen darf, kann sie mit jeder Domain auf derselben IP-Adresse (z. B. 23.214.98.69) kommunizieren, da Firewalls während der DNS- und TLS-Verhandlungen nur die Whitelisting-CDN-Domain sehen.Tools wie Psiphon haben Domain Fronting ausgenutzt, um Netzwerkbeschränkungen zu umgehen, sodass Malware in Cloud-Workloads C2-Kanäle einrichten konnte, während sie scheinbar mit zugelassenen Diensten interagierte.¹

Kompromittierte SaaS-Dienste: Die VEILDrive-Kampagne

Die VEILDrive-Kampagne von 2024 zeigt, wie Angreifer vertrauenswürdige, auf der Whitelist stehende SaaS-Plattformen für eine dauerhafte Kontrolle nutzen. Bei diesem Angriff wurden Microsoft-Dienste wie Teams, SharePoint, Quick Assist und OneDrive als C2-Kanäle verwendet, wobei eine einzigartige OneDrive-basierte Methode zum Verwalten von Malware zum Einsatz kam. Da Microsoft-Dienste häufig auf Whitelists stehen, sind solche Angriffe schwer zu erkennen.

Cloud-Speicher kompromittiert: AWS S3-Bucket-Angriffe

Amazon S3-Buckets, die häufig aus geschäftlichen Gründen auf Whitelists gesetzt werden, können bei falscher Konfiguration oder Kompromittierung zu Angriffsvektoren werden. Angreifer können sie zum Hosten bösartiger Inhalte oder zum Betreiben von C2-Servern nutzen. Untersuchungen zeigen, dass 46 Prozent der S3 Buckets möglicherweise falsch konfiguriert sind und somit erhebliche Risiken bergen. Zu den bekanntesten Sicherheitsverletzungen zählen der Twilio-Vorfall aus dem Jahr 2020, bei dem Angreifer auf einen ungeschützten S3 Bucket zugreifen konnten, um ein potenziell schädliches Software Development Kit (SDK) hochzuladen, und der Premier Diagnostics-Vorfall aus dem Jahr 2021, bei dem über 50.000 Patientenakten aufgrund öffentlich zugänglicher Buckets offengelegt wurden.

Best Practices zur Stärkung der Sicherheit

• Verwenden Sie DNS-Schutzlösungen wie Infoblox Threat Defense™, um Anomalien im DNS-Verkehr zu erkennen.
• Ergänzen Sie Richtlinien mit Bedrohungsinformationen, um bekannte bösartige Ziele innerhalb von Whitelisting-Kategorien zu blockieren.
• Wenden Sie Deep Packet Inspection und Verhaltensanalysen zur Erkennung verdächtiger Aktivitäten an.
• Implementieren Sie Zero Trust-Segmentierung und Zugriff mit minimalen Berechtigungen, um Netzwerkberechtigungen zu beschränken.
• Überwachen Sie Cloud-native Protokolle und Telemetriedaten mit SIEM/SOAR-Tools.

Fazit

Whitelisting ist eine wichtige Sicherheitsebene für Cloud-Workloads, reicht jedoch allein nicht aus. Versierte Angreifer können legitime Kanäle mithilfe von Domain Fronting, kompromittierten SaaS-Diensten, falsch konfiguriertem Cloud-Speicher und Implementierungsfehlern ausnutzen. Um Ihre Cloud-Workloads zu schützen, benötigen Sie eine mehrschichtige Verteidigung, die Protective DNS, Bedrohungsinformationen, Verhaltensüberwachung und Zero-Trust-Prinzipien umfasst. Unternehmen müssen über einfache Zulassungs-/Ablehnungsregeln hinausgehen, um sowohl externen Bedrohungen als auch dem internen Missbrauch genehmigter Pfade entgegenzuwirken.

Quelle: Infoblox-Blog