
Hacker nutzen vergessene oder falsch konfigurierte Cloud-Speicher-Buckets gezielt aus, um sensible Daten zu stehlen oder Schadsoftware zu verbreiten. Das Unternehmen hat daher neue Best Practices veröffentlicht, um sogenannte „Dangling-Bucket-Übernahmen“ zu verhindern und appelliert an Entwickler, ihre Cloud-Umgebungen besser abzusichern.
Das Problem entsteht, wenn Entwickler einen Cloud-Speicher-Bucket löschen, dieser jedoch in der Anwendungssoftware, mobilen Apps oder öffentlich zugänglichen Dokumentationen weiterhin referenziert wird. Cyberkriminelle können diese alten Bucket-Namen übernehmen, indem sie sie in ihren eigenen Projekten registrieren. So kapern sie effektiv die alte Speicheradresse und nutzen sie, um Malware zu verteilen oder Nutzerdaten abzugreifen – oft ohne das Wissen der Betroffenen.
Google empfiehlt deshalb einen sorgfältigen und strukturierten Stilllegungsprozess für Cloud-Buckets. In einer veröffentlichten Schritt-für-Schritt-Anleitung zeigt der Tech-Konzern auf, wie sich solche Sicherheitslücken vermeiden lassen und Entwickler ihre Cloud-Infrastruktur schützen können.
Speicher-Buckets sind der Ort, an dem Ihre Daten in der Cloud gespeichert werden. Ähnlich wie digitale Immobilien sind diese Buckets Ihr eigenes Grundstück im Internet. Wenn Sie umziehen und einen bestimmten Bucket nicht mehr benötigen, kann jemand anderes das Grundstück, auf das er verweist, wiederverwenden – sofern die alte Adresse noch öffentlich zugänglich ist.
Das ist die Kernidee hinter einem Dangling-Bucket-Angriff. Dieser tritt auf, wenn Sie einen Speicher-Bucket löschen, aber Verweise darauf noch in Ihrem Anwendungscode, in mobilen Apps und in öffentlichen Dokumentationen vorhanden sind. Ein Angreifer kann dann einfach denselben Bucket-Namen in seinem eigenen Projekt beanspruchen und so Ihre alte Adresse effektiv kapern, um möglicherweise Malware zu verbreiten und Daten von Benutzern zu stehlen, die unwissentlich noch auf einen Bucket vertrauen, der offiziell nicht mehr in Gebrauch ist.
Glücklicherweise können Sie Ihre Anwendungen und Benutzer mit den folgenden vier Schritten (Quelle zum Nachschlagen) vor dieser Bedrohung schützen.
Implementieren Sie zunächst einen sicheren Stilllegungsplan
Wenn Sie einen Bucket löschen, gehen Sie dabei sorgfältig vor. Ein bewusster Stilllegungsprozess ist von entscheidender Bedeutung. Bevor Sie gcloud storage rmeingeben, führen Sie die folgenden Schritte aus:
Schritt 1: Prüfen und informieren
Bevor Sie etwas löschen, nehmen Sie sich Zeit, um herauszufinden, wer und was noch auf den Bucket zugreift. Verwenden Sie Protokolle, um den aktuellen Datenverkehr zu überprüfen. Wenn Sie aktive Datenverkehrsanfragen von alten Versionen Ihrer App, Drittanbieterdiensten und Nutzern sehen, untersuchen Sie diese. Achten Sie besonders auf Anfragen, die versuchen, ausführbaren Code, Machine-Learning-Modelle, dynamische Webinhalte (z. B. Java Script) und sensible Konfigurationsdateien abzurufen.
Möglicherweise sehen Sie viele Anfragen von Bots, Daten-Crawlern und Scannern, wenn Sie den User-Agent des Anfragenden überprüfen. Diese Anfragen sind im Wesentlichen Hintergrundrauschen und bedeuten nicht, dass der Bucket für die ordnungsgemäße Funktion Ihrer Systeme aktiv benötigt wird. Sie sind nicht gefährlich und können ignoriert werden, da sie keinen legitimen Datenverkehr von Ihren Anwendungen und Nutzern darstellen.
Schritt 2: Mit Zuversicht löschen
Viele automatisierte Prozesse und Benutzeraktivitäten finden nicht täglich statt. Daher ist es wichtig, mindestens eine Woche zu warten, bevor Sie den Bucket löschen. Wenn Sie mindestens eine Woche warten, können Sie sicherer sein, dass Sie einen vollständigen Aktivitätszyklus beobachtet haben, darunter:
- Wöchentliche Berichte: Skripte, die wöchentlich Berichte erstellen und Datensicherungen durchführen.
- Batch-Jobs: Automatisierte Aufgaben, die möglicherweise nur am Wochenende oder an einem bestimmten Wochentag ausgeführt werden.
- Seltener Benutzerzugriff: Benutzer, die eine Funktion, die auf den Daten des Buckets basiert, möglicherweise nur einmal pro Woche verwenden.
Nachdem Sie überprüft haben, dass mindestens eine Woche lang kein legitimer Datenverkehr auf den Bucket zugegriffen hat, und Sie Ihren gesamten Legacy-Code aktualisiert haben, können Sie mit dem Löschen des Buckets fortfahren. Durch das Löschen eines Google Cloud-Projekts werden alle damit verbundenen Ressourcen, einschließlich aller Google Cloud Storage-Buckets, effektiv gelöscht.
Als Nächstes suchen und beheben Sie Code, der auf nicht vorhandene Buckets verweist
Die Vermeidung zukünftiger Probleme ist entscheidend, aber möglicherweise gibt es in Ihrer Umgebung bereits Verweise auf nicht vorhandene Buckets. Hier ist ein Plan, um diese zu finden und zu beheben.
Schritt 3: Proaktive Erkennung
Analysieren Sie Ihre Protokolle: Dies ist eines Ihrer leistungsstärksten Tools. Durchsuchen Sie Ihre Cloud Logging-Daten nach Server- und Anwendungsprotokollen, die wiederholt den Fehler 404 Not Found für Speicher-URLs anzeigen. Beispielsweise ist eine hohe Anzahl fehlgeschlagener Anfragen an denselben nicht vorhandenen Bucket-Namen ein wichtiges Warnsignal (um dieses Problem zu beheben, empfehlen wir Ihnen, mit Schritt 3 fortzufahren und dann mit Schritt 4 fortzufahren).
Scannen Sie Ihren Code und Ihre Dokumentation: Führen Sie einen umfassenden Scan aller privaten und Open-Source-Code-Repositorys (einschließlich alter und archivierter Repositorys), Konfigurationen und Dokumentationen durch, um alle Verweise auf Ihre Storage-Bucket-Namen zu finden, die möglicherweise nicht mehr verwendet werden.
Eine Möglichkeit, diese zu finden, besteht darin, nach den folgenden Mustern zu suchen:
gs://{bucket-name}
storage.googleapis.com/{bucket-name}
{bucket-name}.storage.googleapis.com
commondatastorage.googleapis.com/{bucket_name}
{bucket_name}.commondatastorage.googleapis.com
Sie können feststellen, ob ein Bucket noch vorhanden ist, indem Sie https://storage.googleapis.com/{Ihr-Bucket-Name}abfragen. Wenn Sie die Antwort NoSuchBucketerhalten, haben Sie eine veraltete Bucket-Referenz identifiziert.
<Error>
<Code>NoSuchBucket</Code>
<Message>The specified bucket does not exist.</Message>
</Error>
Wenn der Bucket vorhanden ist (und Sie keine NoSuchBucket-Fehlermeldung erhalten), sollten Sie überprüfen, ob er tatsächlich zu Ihrer Organisation gehört – möglicherweise hat ein Angreifer den Namen bereits beansprucht.
Am einfachsten können Sie die Eigentumsrechte überprüfen, indem Sie versuchen, die IAM-Berechtigungen (Identity and Access Management) des Buckets zu lesen.
Wenn Sie einen Befehl wie gcloud storage buckets get-iam-policy gs://{bucket-name} ausführen und die Access Denied oder 403 Forbidden Fehlermeldung erhalten, ist dies ein Zeichen dafür, dass der Bucket von jemand anderem beansprucht wurde. Dies beweist, dass der Bucket existiert, aber Ihr Konto keine Berechtigung hat, ihn zu verwalten – was darauf hindeutet, dass er übernommen wurde. Diese Referenz sollte als Risiko betrachtet und entfernt werden.
Zur Vereinfachung finden Sie unten ein Skript, mit dem Sie veraltete Verweise in einer bestimmten Datei finden können.
++++
import re
import sys
from typing import Optional, Set
import requests
from requests.exceptions import RequestException
def check_bucket(bucket_name: str) -> Optional[requests.Response]:
try:
with requests.Session() as session:
response = session.head(f“https://storage.googleapis.com/{bucket_name}“)
return response
except RequestException as e:
print(f“An error occurred while checking bucket {bucket_name}: {e}“)
return None
def sanitize_bucket_name(bucket_name: str) -> Optional[str]:
# Remove common prefixes and quotes
bucket_name = bucket_name.replace(„gs://“, „“)
bucket_name = bucket_name.replace(„\““, „“)
bucket_name = bucket_name.replace(„\'“, „“)
bucket_name = bucket_name.split(„/“)[0]
# Validate the bucket name format according to GCS naming conventions
if re.match(„^[a-z0-9-._]+$“, bucket_name) is None:
return None
return bucket_name
def extract_bucket_names(line: str) -> Set[str]:
all_buckets: Set[str] = set()
pattern = re.compile(
r’gs://([a-z0-9-._]+)|‘
r'([a-z0-9-._]+)\.storage\.googleapis\.com|‘
r’storage\.googleapis\.com/([a-z0-9-._]+)|‘
r'([a-z0-9-._]+)\.commondatastorage\.googleapis\.com|‘
r’commondatastorage\.googleapis\.com/([a-z0-9-._]+)‘,
re.IGNORECASE
)
for match in pattern.finditer(line):
# The first non-empty group is the bucket name
if raw_bucket := next((g for g in match.groups() if g is not None), None):
if sanitized_bucket := sanitize_bucket_name(raw_bucket):
all_buckets.add(sanitized_bucket)
return all_buckets
def main(filename: str) -> None:
with open(filename, ‚r‘) as f:
for i, line in enumerate(f, 1):
bucket_names = extract_bucket_names(line)
for bucket_name in bucket_names:
response = check_bucket(bucket_name)
if response.status_code == 404:
print(f“Dangling bucket found: {bucket_name} (line {i}), {line}“)
if __name__ == „__main__“:
if len(sys.argv) != 2:
print(„Usage: python find_dangling_buckets.py <filename>“)
sys.exit(1)
main(sys.argv[1])
++++
Bitte beachten Sie, dass dieses Skript und diese Empfehlungen nur fest codierte Verweise finden können, nicht jedoch solche, die während der Laufzeit dynamisch generiert werden. Außerdem kann die Codebasis fest codierte Bucket-Namen enthalten, die nicht dem Muster entsprechen, aber von Google Cloud Storage-Clients verwendet werden.
Schritt 4: Zurückgewinnen und sichern
Wenn Sie einen dangling Bucket-Namen finden, der ein Sicherheitsrisiko für Sie oder Ihre Kunden darstellen könnte, handeln Sie schnell.
Wenn Sie nicht Eigentümer des verwaisten Buckets sind:
Verwenden Sie alle verfügbaren Daten aus dem vorherigen Schritt, um verwaiste Buckets zu finden und alle fest codierten Verweise in Ihrem Code oder Ihrer Dokumentation zu entfernen. Stellen Sie die Korrektur für Ihre Nutzer bereit, um das Problem dauerhaft zu beheben.
Wenn Sie Eigentümer des dangling Bucket sind:
- Namen zurückfordern: Erstellen Sie einen neuen Storage-Bucket mit genau demselben Namen in einem sicheren Projekt, das Sie kontrollieren. Dadurch wird verhindert, dass ein Angreifer ihn beanspruchen kann.
- Sperren: Wenden Sie eine restriktive IAM-Richtlinie auf den zurückgeforderten Bucket an. Verweigern Sie allen Benutzern den Zugriff auf
allUsersundallAuthenticatedUsersund aktivieren Sie Uniform Bucket-Level Access. Aktivieren Sie die Kontrolle zum Verhindern des öffentlichen Zugriffs, um den Bucket in einen privaten „Sinkhole“ zu verwandeln.
Durch die Integration dieser Vorgehensweisen in Ihren Entwicklungslebenszyklus und Ihre Betriebsabläufe können Sie die Übernahme von dangling buckets wirksam verhindern. Die Sicherung Ihrer Cloud-Umgebung ist ein kontinuierlicher Prozess, und diese Schritte bieten Ihnen und Ihren Benutzern einen zusätzlichen Schutz.
Weitere Informationen zum Verwalten von Storage Buckets finden Sie in unserer Dokumentation hier.
Mehr zum Thema – Unsere Empfehlungen
Fachartikel

Industrielles Phishing gegen Italiens Infrastruktur: Group‑IB entdeckt automatisiertes Aruba‑Imitierendes Phishing‑Kit

Stärkung von Red Teams: Ein modulares Gerüst für Kontrollbewertungen

SAP Patch Day November 2025: Kritische Lücken in SQL Anywhere Monitor und SAP Solution Manager geschlossen

Nordkoreanische APT-Gruppe missbraucht Google Find Hub für Fernlösch-Angriffe auf Android-Geräte

DNS-Ausfallsicherheit entscheidet über die Unternehmenskontinuität
Studien

BSI-Lagebericht 2025: Fortschritte in der Cybersicherheit – Deutschland bleibt verwundbar

Forrester veröffentlicht Technologie- und Sicherheitsprognosen für 2026

Zunahme KI-gestützter Cyberbedrohungen im Fertigungssektor

KnowBe4-Studie: Personalisierte Phishing-E-Mails setzen auf die Verwendung von Firmennamen

Neue Studie: Mehrheit der US-Großunternehmen meldet KI-Risiken
Whitepaper

Vorbereitung auf künftige Cyberbedrohungen: Google veröffentlicht „Cybersecurity Forecast 2026“

Aktuelle Studie zeigt: Jeder Vierte in Deutschland bereits Opfer von digitalem Betrug

Cybersecurity in Deutschland: 200 Milliarden Euro Schaden trotz steigender IT-Ausgaben

Die EU bleibt weiterhin Ziel zahlreicher, sich überschneidender Bedrohungsgruppen

Verizon Business DBIR 2025: So können Gesundheitseinrichtungen Cyberangriffen begegnen
Hamsterrad-Rebell

Identity und Access Management (IAM) im Zeitalter der KI-Agenten: Sichere Integration von KI in Unternehmenssysteme

Infoblox zeigt praxisnahe IT-Security-Strategien auf it-sa 2025 und exklusivem Führungskräfte-Event in Frankfurt

IT-Security Konferenz in Nürnberg: qSkills Security Summit 2025 setzt auf Handeln statt Zögern

Von Palo Alto nach Paderborn: Wie eine Initiative US-Cyberfachkräfte für Deutschland gewinnen will







