Aanvalsoppervlak van de cloud

Het aanvalsoppervlak van de cloud is het geheel van punten waar een aanvaller kan proberen een cloudomgeving binnen te komen of er gegevens aan te onttrekken. In tegenstelling tot lokale netwerken wordt het cloudoppervlak vooral bepaald door configuratie en identiteit, niet door een fysieke perimeter.

• Publiek toegankelijke API's en beheerconsoles
• Identiteits- en toegangsbeheer (IAM)
• Opslagbuckets, databases en serverloze functies
• Netwerkblootstelling (beveiligingsgroepen, load balancers)

Eén verkeerd geconfigureerde instelling kan een volledig account blootleggen.

De meeste cloudpentests richten zich op een van de drie grote providers. Elke provider heeft een eigen identiteitsmodel en terminologie, maar de aanvalspatronen vertonen veel overeenkomsten.

• AWS — IAM-gebruikers/-rollen, S3, EC2, Lambda
• Azure — Entra ID (Azure AD), Blob Storage, VM's, Functions
• GCP — IAM-serviceaccounts, Cloud Storage, Compute Engine

Als je één provider grondig leert kennen, worden de andere eenvoudiger, omdat de kernconcepten (identiteit, rekenkracht, opslag, netwerk) bij alle providers overeenkomen.

Cloudproviders beveiligen de infrastructuur; de klant beveiligt wat deze erin zet. Dit is het model van gedeelde verantwoordelijkheid, en vrijwel elke cloudinbraak vindt plaats aan de kant van de klant.

• Provider: fysieke datacenters, hypervisor, patchen van beheerde diensten
• Klant: IAM-beleid, gegevens, patchen van het besturingssysteem (IaaS), netwerkconfiguratie

Als pentester richt je je op de verantwoordelijkheden van de klant, omdat daar de uit te buiten fouten zitten.

De eerste taak bij een cloudbeoordeling is vaststellen wie je bent en wat je kunt doen met de referenties waarover je beschikt. De AWS CLI maakt de identiteit van de aanroeper direct zichtbaar.

Als een sleutel te ruime rechten heeft, kan deze ene identiteit zich door het hele account verplaatsen.

Cloudresources kunnen bereikbaar zijn vanaf het openbare internet of alleen vanuit een virtueel netwerk. Verkeerd geconfigureerde blootstelling is een van de meest voorkomende bevindingen.

• Security groups / NSG's die openstaan voor 0.0.0.0/0
• Opslagbuckets die zijn ingesteld op openbaar lezen
• Databases waarvoor openbare eindpunten zijn ingeschakeld
• Beheerpoorten (22, 3389, 5432) die zijn blootgesteld

In kaart brengen welke resources publiek zijn, vormt de basis van cloudverkenning.

Zelfs zonder referenties brengen aanvallers de cloudvoetafdruk van een doelwit in kaart. Voorspelbare naamgeving en DNS lekken verrassend veel informatie.

Hulpprogramma's proberen bucket- en opslagnamen met brute force uit, gebaseerd op de bedrijfsnaam en veelvoorkomende patronen.

In elk cloudaccount bestaan twee afzonderlijke aanvalslagen:

• Beheer-/controlelaag — de API's waarmee resources worden gemaakt, aangepast en verwijderd (bijv. iam:CreateUser, ec2:RunInstances)
• Gegevenslaag — toegang tot de gegevens in resources (een S3-object lezen, een database bevragen)

Als de beheerlaag wordt gecompromitteerd, is het meestal afgelopen, omdat de aanvaller zichzelf elke gewenste toegang tot de gegevenslaag kan geven.

Cloudacties worden centraal vastgelegd. Als pentester moet je weten dat deze logging bestaat, omdat verdedigers deze gegevens bewaken. Het aantreffen van uitgeschakelde logging is op zichzelf al een bevinding.

• AWS CloudTrail — registreert alle API-aanroepen
• Azure Activity Log / Monitor
• GCP Cloud Audit Logs

Een account waarin logging is uitgeschakeld of niet wordt bewaakt, is al een bevinding met een hoog risico voordat er sprake is van enige exploitatie.

De meeste cloudinbreuken beginnen via een van een klein aantal toegangspunten:

• Gelekte toegangssleutels in Git-opslagplaatsen, CI-logs of mobiele apps
• Te ruim geconfigureerde IAM-rollen die aan gecompromitteerde servers zijn gekoppeld
• SSRF die de metadataservice van een instantie bereikt
• Publieke opslagcontainers die geheimen of back-ups blootleggen

Als je deze patronen herkent, kun je prioriteren waar je als eerste moet zoeken.

Een gestructureerde aanpak zorgt ervoor dat een cloudbeoordeling grondig blijft. Geautomatiseerde hulpmiddelen brengen het volledige account in kaart zodra je over inloggegevens beschikt.

Hulpmiddelen zoals ScoutSuite en Prowler controleren de configuratie van diensten en markeren automatisch risico's.

Cloudtests moeten binnen de autorisatie van de opdracht blijven. Providers hebben ook regels voor de uitvoering van opdrachten.

• Bevestig de exacte accounts, abonnementen of projecten die binnen het bereik vallen
• Vermijd acties die gevolgen hebben voor andere tenants of gedeelde infrastructuur
• Voer nooit tests in de stijl van een denial-of-service uit zonder expliciete schriftelijke goedkeuring

Cloudtests zonder autorisatie kunnen de voorwaarden van de provider en de lokale wetgeving schenden.

Je hebt geleerd wat het aanvalsoppervlak van de cloud bepaalt en hoe dit verschilt van traditionele netwerken.

• Het oppervlak wordt bepaald door identiteit en configuratie, niet door een fysieke perimeter
• AWS, Azure en GCP delen dezelfde kernconcepten: identiteit, rekenkracht, opslag en netwerk
• Het model van gedeelde verantwoordelijkheid legt de configuratie en gegevens bij de klant
• Maak onderscheid tussen het beheer vlak en het gegevensvlak
• Bevestig altijd het bereik en de autorisatie voordat je tests uitvoert

Vervolgens gaan we dieper in op IAM-configuratiefouten, de kern van cloudaanvallen.