Unit 42, het onderzoeksteam van Palo Alto Networks, waarschuwt voor bucket hijacking. Bij deze techniek registreren aanvallers verwijderde cloud-opslaglocaties opnieuw en onderscheppen zo gevoelige data die via bestaande koppelingen nog naar de oude naam wordt gestuurd.
Veel organisaties gebruiken cloudopslag voor het automatisch bewaren van logs, back-ups, API-sleutels en configuratiebestanden. Wordt zo’n bucket verwijderd terwijl applicaties of automatische scripts er nog data naartoe sturen, dan kan een kwaadwillende de vrijgekomen naam direct opnieuw claimen. Vanaf dat moment stroomt de vertrouwelijke informatie rechtstreeks richting de ‘kaper’, zonder dat er een ingewikkelde inbraak op het netwerk voor nodig is.
Naast het passief opvangen van gevoelige data vormt ook de supply chain een groot risico. Wanneer applicaties verwachten een script, installatiebestand of update uit de bucket te downloaden, kan een kwaadwillende de legitieme bestanden vervangen door schadelijke software.
Het probleem zit volgens Unit 42 in een fundamentele ontwerpkeuze. Bucketnamen zijn wereldwijd uniek binnen een provider, maar de identiteit van een bestemming hangt uitsluitend aan die naam en niet aan een vast account-ID. Verwijder je de bucket, dan overleeft de naam in de globale naamruimte terwijl de rechtmatige eigenaar verdwijnt. Precies die combinatie maakt de aanval mogelijk.
De onderzoekers deelden hun bevindingen met Google Cloud, Amazon Web Services en Microsoft Azure. Toch verwachten ze dat misbruik in de praktijk erg lastig te detecteren is, omdat het gegevensverkeer voor de verzendende applicatie gewoon succesvol blijft verlopen.
Dilemma voor cloudproviders
De Cloud Security Alliance bestempelt het als een systemisch ontwerpprobleem dat meerdere providers raakt. Voor de providers is een snelle oplossing echter een lastige spagaat. Koppelingen en bucketnamen bestaan vaak al tientallen jaren. Het geforceerd wijzigen van de naamstructuur of het op slot zetten van verwijderde namen kan ertoe leiden dat bestaande applicaties en workflows bij duizenden klanten zomaar stoppen met werken.
AWS introduceerde weliswaar account-regionale namespaces, waarbij alleen het eigen account een bucketnaam met het bijbehorende account-ID kan aanmaken. Die maatregel is echter opt-in en beschermt reeds bestaande buckets niet. Voor onder andere Google Cloud Storage en Azure Blob Storage is geen vergelijkbare, breed uitgerolde oplossing gedocumenteerd die het hergebruik van namen automatisch blokkeert. Daardoor blijft het risico in de praktijk grotendeels bij de gebruiker liggen.
Dat de dreiging verder gaat dan theorie, liet een incident van jaren geleden al zien. Volgens Checkmarx kaapten aanvallers toen de S3-bucket achter het populaire NPM-pakket ‘bignum’. Ze vingen niet alleen data op, maar vervingen de verwachte installatiebestanden ook door malware die inloggegevens van ontwikkelaars stal.
Lees ook: Palo Alto Networks waarschuwt voor risicovolle AI-uitbreidingen van AI-agents
Advies van Unit 42
Om het risico te verkleinen adviseert Unit 42 om verwijderrechten te beperken tot een kleine groep beheerders. Ook raadt het team aan om voor het verwijderen van een bucket alle afhankelijkheden, applicaties en datastromen in kaart te brengen en te controleren of systemen nog naar de locatie verwijzen.
Daarnaast moeten organisaties monitoring en waarschuwingen inrichten voor het verwijderen en opnieuw aanmaken van kritieke opslaglocaties. Tot slot adviseert Unit 42 om cloudomgevingen regelmatig te controleren op verouderde configuraties en achtergebleven verwijzingen naar resources die niet meer worden gebruikt. Een echte dreigingsactor die de bucket hijacking-techniek gebruikt, heeft Unit 42 vooralsnog niet aangetroffen.