Exploit-Gefahr: Gehackt wegen gelöschter Cloud-Assets

Foto: Yuriy Mazur | shutterstock.com

Im Zeitalter der Cloud werden Ressourcen wie virtuelle Server und Storage oft über Deployment-Skripte nach Bedarf bereitgestellt. Solche Ressourcen einzurichten, ist meist in wenigen Sekunden erledigt. Sie wieder zu entfernen, wenn sie nicht mehr benötigt werden, ist hingegen kniffliger. Wenn Sie sich dabei nämlich nicht vergewissern, dass auch alle verweisenden Datensätze – sowohl in der DNS-Umgebung als auch in der Codebasis – gelöscht sind, kann das zu schwerwiegenden Sicherheitslücken führen.

Das Cloud-Squatting-Szenario

Stellen Sie sich folgendes Szenario vor: Sie möchten zu Weihnachten eine spezielle Kampagne für Ihre Kunden fahren und beschließen, dafür eine Microsite zu erstellen. Dort sollen alle Werbematerialien, Anmeldeformulare et cetera gehostet werden. Also machen sich Ihre Entwickler an die Arbeit, entwerfen die Site und stellen einen neuen virtuellen Server über Amazon Web Services (oder jeden anderen Cloud-Service) bereit, um die Seite und einen zugehörigen Storage Bucket zu hosten. Anschließend weist der Provider Ihrer (EC2-)Instanz eine öffentlich erreichbare IP-Adresse zu und vergibt einen Hostnamen dafür, damit Sie per API darauf zugreifen können.

Der nächste Schritt besteht darin, eine Subdomain für den Storage Bucket auf Ihrer Hauptdomain zu erstellen. Die muss auf die zugewiesene IP-Adresse verweisen, damit der Webserver von Ihrer Subdomain aus erreichbar ist. Dann erstellen Sie eine Subdomain für den Bucket und einen DNS-CNAME-Eintrag, der auf den AWS-Hostnamen des Buckets verweist. Wenn Sie zum Beispiel auch eine mobile Anwendung betreiben, die Daten an die Microsite sendet, werden die Hostnamen auch in den Code dieser Applikation übernommen. Dazu kommen weitere Apps und Tools, die mit der Seite integriert werden müssen, etwa um die Datenbank abzusichern oder Website-Statistiken zu erheben.

Das Ergebnis: Sie haben eine Vielzahl von Datensätzen an unterschiedlichen Orten erstellt, die im Wesentlichen auf temporäre Cloud-Ressourcen verweisen. Wenn Sie diese Ressourcen nun löschen, ohne dabei an diese Datensätze zu denken, erzeugen Sie für Ihr Unternehmen ein enormes Sicherheitsrisiko. Denn die IP-Adresse, die nun frei geworden ist, können sich auch Angreifer sichern – und ihre immer noch vorhandenen Subdomains nutzen, um auf neu erstellte Phishing- oder Malware-Webseiten zu verweisen. Da die Angreifer auch den Verweis auf den Storage Bucket im Code ihrer mobilen App gefunden haben, können sie zudem ein gleichnamiges Storage Bucket registrieren – an das Ihre Anwendung fleißig sensible Daten sendet.

Dieses Szenario hat Abdullah Al-Sultani, Security Engineer bei TikTok, kürzlich auf einer Security-Konferenz präsentiert. Die Angriffsform taufte er “Cloud Squatting”. Sie betrifft weit mehr als nur DNS-Einträge, weil die Art und Anzahl der Cloud-Services, die Ressourcen und Namen neu zuweisen, sobald ein Account geschlossen wird, sehr breit gefächert ist. Demnach gilt: Je größer das Unternehmen, desto größer das Problem.

Al-Sultani stieß auf Cloud Squatting, nachdem TikTok im Rahmen seines Bug-Bounty-Programms Kenntnis von der Technik erlangte. Auch Tiktok-Subdomains waren für diese Angriffsform anfällig. Al-Sultani und sein Team erkannten relativ schnell, dass es ein komplexes Unterfangen darstellen würde, alle problembehafteten Datensätze im Unternehmen zu finden. Schließlich beschäftigt der Tiktok-Mutterkonzern ByteDance mehr als 100.000 Mitarbeiter und diverse Dev- und Infrastruktur-Teams in vielen Ländern weltweit. Dass das Unternehmen auch Tausende von Domains für die verschiedenen Anwendungen in den unterschiedlichen Regionen nutzt, machte die Angelegenheit nicht einfacher.

Um sich dem Problem anzunähern, entwickelte das Security-Team von Tiktok ein Tool für die interne Nutzung. Der Zweck:

• Alle Unternehmens-Domains und CNAME-Einträge mit Hilfe von HTTP- oder DNS-Requests automatisiert zu testen,

• diejenigen zu identifizieren, die auf IP-Ranges von Cloud-Providern und anderen Drittanbietern verweisen, und

• dann zu überprüfen, ob diese IP-Einträge noch gültig sind.

Dabei kam dem Team zugute, dass die IP-Adressen, die den Assets von den Cloud-Anbietern zugewiesen wurden, bereits in einer internen Datenbank erfasst waren. Das dürften in der Praxis allerdings nicht viele Firmen von sich behaupten können.

Kein neues Security-Problem

Security Engineer Al-Sultani ist allerdings nicht der Erste, der auf die mit Cloud Quatting verbundenen Gefahren hinweist. Bereits 2022 analysierten Wissenschaftler der Pennsylvania State University, welche Risiken damit verbunden sind, IP-Adressen in Public-Cloud-Umgebungen wiederzuverwenden. Dazu setzten sie drei Millionen EC2-Serverinstanzen in der AWS-Region US East ein, die 1,5 Millionen eindeutige IP-Adressen (oder rund 56 Prozent des für die Region verfügbaren Pools) erhielten. Bei der Analyse des Traffics, der über diese IP-Adressen abgewickelt wurde, konnten die Forscher anschließend Finanztransaktionen, GPS-Standortdaten und persönlich Informationen identifizieren.

“Wir haben festgestellt, dass ausnutzbare Konfigurationen in vielen Fällen an der Tagesordnung und wirklich gefährlich waren […] Innerhalb der sieben Klassen von Drittanbieterdiensten haben wir Dutzende von ausnutzbaren Softwaresystemen identifiziert, die Hunderte von Servern umfassen – beispielsweise Datenbanken, Caches, mobile Anwendungen und Web Services. Schließlich haben wir 5.446 ausnutzbare Domains in 231 eTLDs identifiziert – darunter 105 in den Top 10.000 und 23 in den Top 1.000 der populärsten Domains”, heißt es im Forschungspapier.

Das Cloud-Squatting-Risiko kann dabei auch auf Softwarekomponenten von Drittanbietern übertragen werden; So warnen Forscher des Sicherheitsanbieters Checkmarx in einem aktuellen Blogeintrag, dass Cyberkriminelle gezielt nach npm-Packages suchen, die Verweise auf S3-Storage-Buckets enthalten. Finden Sie dabei einen, der nicht mehr existiert, registrieren sie ihn. In vielen Fällen haben sich die Entwickler der Pakete dafür entschieden, einen S3-Bucket zu verwenden, um vorkompilierte Binärdateien zu speichern, die während der Installation des Pakets heruntergeladen und ausgeführt werden. Wird der Bucket durch die Angreifer neu registriert, ermöglicht ihnen das, Remote Code Exceution auf den Systemen der User, die dem Package vertraut haben – und damit die Möglichkeit, eigene, maliziöse Binärdateien zu hosten.

In einem ähnlichen Beispiel haben Security-Experten von Aqua Security demonstriert, dass auch gelöschte oder umbenannte GitHub-Repositories, von Angreifern neu registriert werden können (“Repojacking“). Anwendungen oder Dokumentationen die noch auf diese Repos verweisen, werden dann als Malware-Distributionsplattformen genutzt werden.

Cloud-Squatting-Risiken minimieren

Die Angriffsfläche beim Cloud Squatting ist je nach Unternehmen enorm groß. Je früher Unternehmen sich mit dem Thema befassen, desto besser. Das IP-Wiederverwendungs- und DNS-Szenario scheint am relevantesten zu sein und lässt sich zum Beispiel entschärfen, indem Sie:

• reservierte IP-Adressen von Cloud-Anbietern nutzen, die explizit freigegeben werden müssen,

• eigene IP-Adressen in die Cloud übertragen,

• private (interne) IP-Adressen zwischen Services nutzen (insofern die Benutzer nicht direkt auf diese Server zugreifen müssen)

• IPv6-Adressen verwenden. Deren Anzahl macht es unwahrscheinlich, dass sie wiederverwendet werden.

Unternehmen tun darüber hinaus gut daran, eine Richtlinie durchzusetzen, die verhindert, dass IP-Adressen in Anwendungen festkodiert werden und stattdessen DNS-Namen für alle Dienste vorsieht. (fm)

Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox.

Jetzt CSO-Newsletter sichern

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.