TL;DR
  • Cloud security assessment pentru infrastructură AWS multi-region
  • S3 bucket cu ACL public conținând fișiere de configurare cu credențiale interne
  • Credențialele permiteau accesul la baza de date de producție și la sistemul de facturare
  • Misconfigurarea exista de aproximativ 8 luni, nedetectată de monitorizarea internă

Contextul angajamentului

O companie SaaS cu infrastructură AWS ne-a solicitat un cloud security assessment înainte de un audit SOC 2. Perimetrul includea două conturi AWS, aproximativ 40 de bucket-uri S3, politici IAM, configurații VPC și serviciile Lambda și RDS asociate. Durata: 7 zile lucrătoare.

Vulnerabilitatea identificată

CVSS 9.8 — CRITICĂ

În prima zi a assessment-ului, în timpul enumerării resurselor S3, am identificat un bucket cu ACL public configurat pentru acces de citire anonim. Bucket-ul era folosit pentru distribuirea fișierelor statice ale aplicației, configurare aparent intenționată.

Problema era că în același bucket existau subdirectoare care conțineau fișiere de configurare cu credențiale hard-codate, adăugate probabil în urma unui deploy automatizat care nu trata diferit fișierele de configurare față de assets-urile statice.

Detalii tehnice

Resursa afectată

s3://[redacted]-assets/config/app.env — accesibil public fără autentificare

Conținut expus

Fișier .env conținând: string de conexiune RDS cu credențiale de producție, API key pentru serviciul de facturare, secret JWT pentru semnarea token-urilor de autentificare.

Impact potențial

Acces complet la baza de date de producție (citire/scriere), acces la sistemul de facturare (creare/anulare facturi), posibilitatea de a semna token-uri JWT arbitrare — compromiterea completă a platformei.

Durata expunerii

Analiza CloudTrail a evidențiat că bucket-ul a primit ACL public în urmă cu aproximativ 8 luni, în cadrul unui deployment automatizat. Nu existau alerte configurate pentru modificări de ACL pe bucket-uri S3.

Cum am identificat misconfigurarea

Enumerarea S3 este unul dintre primii pași într-un cloud assessment AWS. Utilizăm o combinație de verificări AWS Config, analiza politicilor de bucket și enumerare directă pentru a identifica bucket-urile cu acces public sau politici permisive. În acest caz, bucket-ul apărea în rezultatele publice ale unui crawler de bucket-uri S3 — informație disponibilă oricui pe internet.

# Verificare AWS CLI — identificare bucket-uri cu ACL public
aws s3api list-buckets --query 'Buckets[].Name'
aws s3api get-bucket-acl --bucket [bucket-name]
# Rezultat: Grant cu Grantee URI=AllUsers și Permission=READ

Raportare și remediere

Constatarea a fost raportată în aceeași zi, cu recomandări concrete: eliminarea ACL-ului public, rotația tuturor credențialelor expuse, configurarea AWS Config Rules pentru detectarea bucket-urilor publice și implementarea alertelor CloudWatch pentru modificări de ACL. Toate măsurile au fost implementate în 72 de ore.

Lecție de reținut

Misconfigurările S3 rămân unul dintre cei mai frecvenți vectori de breșă în mediile cloud. Principiul de bază — niciun bucket S3 nu ar trebui să fie public dacă nu există o nevoie explicită și documentată — trebuie aplicat și monitorizat continuu, nu doar la momentul creării. AWS Config și Security Hub oferă reguli predefinite pentru detectarea acestor misconfigurări, dar trebuie activate și configurate cu alerte adecvate.