Cybersecurityonderzoekers hebben meerdere kritieke fouten ontdekt in de diensten van Amazon Web Services (AWS). Als deze fouten succesvol worden uitgebuit, kan dit ernstige gevolgen hebben.
“De impact van deze kwetsbaarheden varieert van remote code execution (RCE), volledige overname door gebruikers (wat krachtige administratieve toegang kan bieden), manipulatie van AI-modules, blootstellen van gevoelige gegevens, data-exfiltratie en denial-of-service”, aldus cloudbeveiligingsbedrijf Aqua in een gedetailleerd rapport dat is gedeeld met The Hacker News.
Na de responsible disclosure in februari 2024, heeft Amazon de tekortkomingen aangepakt gedurende meerdere maanden van maart tot juni. De bevindingen werden gepresenteerd op Black Hat USA 2024.
Centraal in het probleem, dat de naam Bucket Monopoly heeft gekregen, staat een aanvalsvector die Shadow Resource wordt genoemd. In dit geval verwijst dit naar de automatische creatie van een AWS S3-bucket bij het gebruik van services zoals CloudFormation, Glue, EMR, SageMaker, ServiceCatalog en CodeStar.
De op deze manier gecreëerde S3-bucketnaam is zowel uniek als volgt een vooraf gedefinieerde naamgevingsconventie (“cf-templates-{Hash}-{Region}”). Een aanvaller kan misbruik maken van dit gedrag om buckets in ongebruikte AWS-regio’s in te stellen en te wachten tot een legitieme AWS-klant een van de vatbare services gebruikt om heimelijke toegang te krijgen tot de inhoud van de S3-bucket.
Op basis van de machtigingen die zijn verleend aan de door de tegenstander beheerde S3-bucket, kan de aanpak worden gebruikt om een DoS-conditie te activeren, code uit te voeren, gegevens te manipuleren of te stelen en zelfs volledige controle over het account van het slachtoffer te krijgen zonder dat de gebruiker dit weet.
Om hun kansen op succes te maximaliseren, kunnen aanvallers met behulp van Bucket Monopoly vooraf niet-geclaimde buckets maken in alle beschikbare regio’s en schadelijke code in de bucket opslaan. Wanneer de beoogde organisatie voor het eerst een van de kwetsbare services in een nieuwe regio inschakelt, wordt de schadelijke code onbewust uitgevoerd, wat mogelijk resulteert in de creatie van een admin-gebruiker die de controle aan de aanvallers kan verlenen.
Het is echter belangrijk om te bedenken dat de aanvaller moet wachten tot het slachtoffer voor het eerst een nieuwe CloudFormation-stack in een nieuwe regio implementeert om de aanval succesvol te kunnen lanceren. Het wijzigen van het CloudFormation-sjabloonbestand in de S3-bucket om een malafide admin-gebruiker te maken, is ook afhankelijk van of het account van het slachtoffer toestemming heeft om IAM-rollen te beheren.
Aqua zei dat het vijf andere AWS-services heeft gevonden die vertrouwen op een vergelijkbare naamgevingsmethodologie voor de S3-buckets – {Service Prefix}-{AWS Account ID}-{Region} – waardoor ze worden blootgesteld aan Shadow Resource-aanvallen en een dreigingsactor uiteindelijk de mogelijkheid krijgt om privileges te verhogen en kwaadaardige acties uit te voeren, waaronder DoS, openbaarmaking van informatie, manipulatie van gegevens en willekeurige uitvoering van code.
- AWS Glue: aws-glue-assets-{Account-ID}-{Regio}
- AWS Elastic MapReduce (EMR): aws-emr-studio -{Account-ID}-{Regio}
- AWS SageMaker: sagemaker-{Regio}-{Account-ID}
- AWS CodeStar: aws-codestar-{Regio}-{Account-ID}
- AWS-servicecatalogus: cf-sjablonen-{Hash}-{Regio}
Het bedrijf merkte ook op dat AWS-account-ID’s als geheim moeten worden beschouwd, in tegenstelling tot wat Amazon in zijn documentatie beweert, omdat ze gebruikt kunnen worden om soortgelijke aanvallen uit te voeren.
“Deze aanvalsvector treft niet alleen AWS-services, maar ook veel open-sourceprojecten die door organisaties worden gebruikt om resources in hun AWS-omgevingen te implementeren”, aldus Aqua. “Veel open-sourceprojecten maken automatisch S3-buckets als onderdeel van hun functionaliteit of instrueren hun gebruikers om S3-buckets te implementeren.”
“In plaats van voorspelbare of statische id’s in de bucketnaam te gebruiken, is het raadzaam om een unieke hash of een willekeurige id te genereren voor elke regio en account, en deze waarde op te nemen in de S3-bucketnaam. Deze aanpak helpt beschermen tegen aanvallers die uw bucket voortijdig claimen.”
