Strokovno področje

Oblačna varnost

Oblak ni bolj varen - samo drugačen. Napačne konfiguracije so pravilo, ne izjema.

Podjetja selijo na oblak z mislijo "ponudnik poskrbi za varnost". Ne poskrbi. Shared responsibility model pomeni, da ste vi odgovorni za svoje konfiguracije. In napačne konfiguracije v oblaku so pogostejše kot kadarkoli.

Te oblačne varnostne preglede izvaja Vid Grosek, prvi OSCE3 certificirani penetracijski tester v Sloveniji, prek podjetja Telprom d.o.o. v Ljubljani.

Večina vdorov v oblaku izvira iz napačnih konfiguracij strank, ne iz ranljivosti ponudnika.

Shared Responsibility Model

Razumevanje odgovornosti je ključno:

  • Ponudnik: Fizična varnost, infrastruktura, hypervisor
  • Vi: Podatki, aplikacije, IAM, konfiguracije, šifriranje

AWS/Azure/GCP vam zagotavlja varno infrastrukturo. Kar naredite z njo, je vaša odgovornost.


IAM (Identity and Access Management) napadi

IAM je najpogostejši vektor za popolno kompromitacijo oblačnega okolja. Veriženje vlog in eskalacija identitet sledita podobni logiki napadalnih poti kot pri varnosti Active Directory.

Preširoke pravice

  • Wildcard policies: "Action": "*", "Resource": "*" - dostop do vsega
  • AdministratorAccess: Na večini računov, ki ga ne potrebujejo
  • PassRole abuse: Ustvarjanje novih vlog z višjimi privilegiji

Privilege Escalation tehnike

  • iam:CreateAccessKey: Kreiranje ključev za druge uporabnike
  • iam:CreateLoginProfile: Nastavitev gesla za IAM uporabnika
  • iam:UpdateLoginProfile: Sprememba gesla drugega uporabnika
  • iam:AttachUserPolicy: Dodelitev politik drugim uporabnikom
  • sts:AssumeRole: Prevzem vloge z višjimi pravicami
  • lambda:CreateFunction + iam:PassRole: Lambda z administratorsko vlogo
  • ec2:RunInstances + iam:PassRole: EC2 z instance profile

Orodja za IAM analizo

  • Cloudsplaining: AWS IAM Security Assessment
  • PACU: AWS Exploitation Framework
  • ScoutSuite: Multi-cloud security auditing
  • Prowler: AWS security best practices assessment

Metadata Service napadi

Vsak cloud VM ima dostop do metadata service na 169.254.169.254. SSRF ranljivost = cloud credentials.

AWS Instance Metadata Service (IMDS)

  • IMDSv1: GET http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]
  • IMDSv2: Zahteva token - vendar še vedno ranljivo če aplikacija naredi več HTTP requestov

Azure Instance Metadata Service

  • Endpoint: http://169.254.169.254/metadata/identity/oauth2/token
  • Header: Metadata: true

GCP Metadata Server

  • Endpoint: http://metadata.google.internal/computeMetadata/v1/
  • Header: Metadata-Flavor: Google

Eksploatacija

  1. Najdemo SSRF ranljivost v aplikaciji
  2. Zahteva na metadata endpoint
  3. Pridobimo temporary credentials (access key, secret key, token)
  4. Uporabimo credentials izven okolja (brez logiranja na instance)

S3/Blob Storage izpostavljenost

Javno dostopni bucketi z občutljivimi podatki so še vedno pogosta težava.

Vrste izpostavljenosti

  • Public bucket: Vsakdo lahko bere/piše
  • Public objects: Bucket ni javen, a posamezni objekti so
  • Misconfigured ACL: Authenticated users (vsi AWS uporabniki) imajo dostop
  • Bucket policy: Principal: "*" z dovoljenjem s3:GetObject

Kaj najdem v javnih bucketih

  • Backup baze podatkov
  • Izvorna koda
  • Log datoteke s poverilnicami
  • Konfiguracijske datoteke
  • Uporabniški podatki (GDPR kršitev)

Zaščita

  • S3 Block Public Access na nivoju računa
  • Bucket policies namesto ACL
  • Šifriranje at rest in in transit
  • Access logging omogočen
  • Versioning za recovery

Kubernetes varnost

Kubernetes v oblaku prinaša dodatne napadalne vektorje.

Pogosti problemi

  • Privileged containers: Dostop do host sistema
  • hostPID/hostNetwork: Deljenje namespace z gostiteljem
  • Mounted service accounts: Dostop do Kubernetes API
  • RBAC napačne konfiguracije: Preširoke pravice za service accounte
  • Secrets v ConfigMaps: Nešifrirani secrets

Kubernetes privilege escalation

  • Pod escape: Iz vsebnika na gostitelja
  • Service account token: Dostop do API strežnika
  • RBAC abuse: Kreiranje privilegiranih podov
  • etcd access: Direktni dostop do podatkov klastra

Serverless varnost (Lambda, Functions)

Serverless ne pomeni brez ranljivosti.

Napadalni vektorji

  • Event injection: Manipulacija event payloada
  • Excessive permissions: Lambda z admin pravicami
  • Environment variables: Secrets v env vars (vidni v konzoli)
  • Cold start secrets: Poverilnice v /tmp med hladnim zagonom
  • Dependency vulnerabilities: Ranljive knjižnice

Multi-cloud in hybrid napadi

Podjetja z več cloud ponudniki ali hybrid okolji imajo dodatne izzive. Takšne celovite napadalne poti najbolje preverim s Red Team operacijo.

  • Cross-cloud credential sharing: AWS ključi v Azure VM
  • VPN/Direct Connect: Premostitev v on-premise omrežje
  • Azure AD Connect: Sinhronizacija z AD = pot do on-prem DC
  • Inconsistent policies: Različne varnostne politike med okolji

Moj pristop k cloud penetracijskemu testiranju

  1. Reconnaissance: Odkrivanje cloud resursov (subdomains, S3 buckets, Azure blobs)
  2. IAM analiza: Mapiranje uporabnikov, vlog, politik, potencialne privilege escalation poti
  3. Network assessment: Security groups, NACLs, VPC peering, transit gateways
  4. Service configuration: S3, RDS, Lambda, API Gateway, EKS/AKS/GKE
  5. Data exposure: Javno dostopni podatki, šifriranje, backup politike
  6. Logging & monitoring: CloudTrail, CloudWatch, GuardDuty konfiguracija

Pogosta vprašanja

Katere so najpogostejše napačne konfiguracije v oblaku?

Najpogostejše napačne konfiguracije v oblaku, ki jih izkoriščam, vključujejo: preširoke IAM politike, javne S3/storage buckete, SSRF do cloud metadata endpointov, napačno konfigurirane varnostne skupine in eskalacijo identitet preko veriženja vlog.

Ali je oblačna infrastruktura bolj varna kot lokalna?

Ponudniki oblačnih storitev zagotovijo varnost infrastrukture, vendar ste vi odgovorni za konfiguracijo. Večina vdorov v oblaku izvira iz napačnih konfiguracij strank. Model deljene odgovornosti pomeni, da so vaše IAM politike, omrežna pravila in zaščita podatkov vaša odgovornost.

Kako SSRF ranljivost vodi do kraje oblačnih poverilnic?

SSRF ranljivost napadalcu omogoči, da pošlje zahtevo na cloud metadata endpoint na 169.254.169.254 in pridobi začasne poverilnice (access key, secret key, token) IAM vloge, ki je dodeljena instanci, ter jih uporabi izven okolja.

Potrebujete cloud varnostni pregled?

Odkrijte napačne konfiguracije v vašem AWS, Azure ali GCP okolju preden jih odkrijejo napadalci.