Nazaj na blog

Testiranje varnosti AWS: IAM, S3 in naprej

September 29, 2024 6 min branja
Testiranje varnosti AWS: IAM, S3 in naprej
Nazadnje posodobljeno:

Testiranje varnosti AWS zahteva bistveno drugačen pristop kot tradicionalno penetracijsko testiranje infrastrukture. Oblak uvaja povsem novo napadalno površino, zgrajeno okoli API-jev, politik identitete in integracij storitev. Kot penetracijski tester, ki redno ocenjuje okolja AWS, želim predstaviti ključna področja, na katera se osredotočam, in metodologijo, ki dosledno odkriva kritične ugotovitve.

Začasne poverilnice in načelo najmanjših pravic obravnavajo uradna priporočila AWS: Security best practices in IAM.

Model deljene odgovornosti in kaj testiramo

AWS deluje po modelu deljene odgovornosti: Amazon varuje infrastrukturo (hipervizorje, fizične podatkovne centre, omrežno ogrodje), medtem ko stranka varuje vse, kar je zgrajeno na njej. To pomeni, da se penetracijski testerji osredotočamo skoraj izključno na konfiguracijo stranke, upravljanje identitet, omrežno arhitekturo in aplikacijski sloj. Najpogostejše ugotovitve niso eksotični zero-day napadi, temveč napačne konfiguracije politik IAM, dovoljenj za shranjevanje in omrežne izpostavljenosti. Razumevanje te meje je bistveno za pravilno določitev obsega preverjanja AWS.

Napačne konfiguracije IAM v podrobnostih

Upravljanje identitet in dostopa (IAM) je najpomembnejša napadalna površina v vsakem okolju AWS. Politike IAM določajo, kdo lahko kaj počne, in majhne napake ustvarjajo ogromno izpostavljenost.

  • Preohlapne politike - Politike, ki dodeljujejo široka dejanja, kot so s3:* ali ec2:*, namesto minimalnih zahtevanih dovoljenj. Pogosto naletim na upravljane politike, kot sta AdministratorAccess ali PowerUserAccess, pripete storitvenim računom, ki potrebujejo le ozka dovoljenja.
  • Nadomestni znaki v specifikacijah virov - Politike, ki uporabljajo "Resource": "*", ko bi morale določiti specifične ARN-je. To je še posebej nevarno pri dejanjih podatkovne ravni, kot sta s3:GetObject ali dynamodb:Scan.
  • Uporabniki IAM namesto vlog - Dolgoživi dostopni ključi za uporabnike IAM so pogost vir uhajanja poverilnic. Vloge z začasnimi poverilnicami prek STS so vedno boljša izbira. Preverjam dostopne ključe, starejše od 90 dni, in ključe, ki niso bili nikoli zamenjani.
  • Manjkajoče uveljavljanje MFA - Korenski računi brez MFA, uporabniki IAM z dostopom do konzole brez zahteve MFA in manjkajoči pogoji aws:MultiFactorAuthPresent pri občutljivih klicih API.
  • Simulacija politik - Uporabljam IAM Policy Simulator in enumerate-iam za določanje dejanskih dovoljenj za dane poverilnice. Razlika med tem, kar administratorji mislijo, da vloga zmore, in tem, kar dejansko zmore, je pogosto precejšnja.

Varnost S3

S3 ostaja ena najpogosteje napačno konfiguriranih storitev AWS, kljub letom pozornosti in dodajanju več plasti zaščite, vključno z S3 Block Public Access.

  • Popis javnih vsebnikov S3 - Preverim imena vsebnikov S3 na podlagi konvencij poimenovanja (podjetje-backup, podjetje-logs, podjetje-dev) in testiram javni bralni/pisalni dostop. Orodja kot bucket_finder in prilagojeni seznami besed so tu učinkoviti.
  • Napačne konfiguracije ACL - Starejši ACL-ji lahko dodelijo dostop skupini AuthenticatedUsers (kateri koli račun AWS) ali AllUsers (internet). Tudi če so politike vsebnika S3 na mestu, lahko dovolilni ACL preglasi predvidene omejitve.
  • Težave s politikami vsebnikov S3 - Politike z "Principal": "*" ali pogoji, ki se sklicujejo na vrednosti, ki jih napadalec nadzoruje. Preverjam tudi politike, ki dovoljujejo s3:PutBucketPolicy, kar napadalcu omogoča popoln prepis politike.
  • Manjkajoča šifriranje - Vsebniki S3 brez privzete strežniške šifriranja (SSE-S3 ali SSE-KMS) in objekti, naloženi brez glav šifriranja. Preverjam, da politike vsebnikov S3 uveljavljajo s3:x-amz-server-side-encryption pri klicih PutObject.
  • Zloraba vnaprej podpisanih URL-jev - Aplikacije, ki generirajo vnaprej podpisane URL-je s pretirano dolgimi časi poteka ali ki razkrijejo vnaprej podpisane URL-je prek kode na strani odjemalca. Razkriti vnaprej podpisani URL zagotavlja neoverjen dostop do objekta.

Poti stopnjevanja pravic

Stopnjevanje pravic v AWS je eno najzanimivejših področij za penetracijskega testerja. Za razliko od tradicionalnih okolij, kjer eskaliramo od uporabnika do root, v AWS eskaliramo dovoljenja prek interakcij med storitvami. Raziskava Rhino Security Labs, ki dokumentira več kot 20 poti stopnjevanja pravic, ostaja bistveno branje.

  • iam:PassRole z Lambda - Če napadalec lahko ustvari funkcijo Lambda in ji dodeli vlogo z visokimi privilegiji, lahko izvaja kodo z dovoljenji te vloge. Za to so potrebna dovoljenja iam:PassRole, lambda:CreateFunction in lambda:InvokeFunction.
  • iam:PassRole z EC2 - Ustvarjanje primerka EC2 s profilom primerka, ki ima višja dovoljenja, nato dostop do storitve metapodatkov iz primerka za pridobitev začasnih poverilnic.
  • Vbrizgavanje kode funkcij Lambda - Če napadalec lahko posodobi kodo obstoječe funkcije Lambda (lambda:UpdateFunctionCode), podeduje katero koli vlogo, ki je že pripeta tej funkciji.
  • Manipulacija skladov CloudFormation - Ustvarjanje ali posodabljanje skladov CloudFormation z iam:PassRole za storitev CloudFormation, kar skladu omogoča ustvarjanje virov IAM ali drugih visoko privilegiranih virov v napadalcevem imenu.
  • SSM RunCommand - Z dovoljenjem ssm:SendCommand lahko napadalec izvaja poljubne ukaze na primerkih EC2, ki poganjajo agenta SSM, in podeduje vloge IAM teh primerkov.
  • Zloraba profila primerka EC2 - Kompromitiranje primerka EC2 in poizvedovanje storitve metapodatkov na 169.254.169.254 za pridobitev začasnih poverilnic pripetega profila primerka.

Druge napadalne površine AWS

  • Napačne konfiguracije SQS/SNS - Čakalne vrste in teme s preohlapnimi politikami virov, ki omogočajo medračunski dostop ali vbrizgavanje sporočil.
  • Skrivnosti v Parameter Store in Secrets Manager - Aplikacije pogosto shranjujejo poverilnice podatkovnih baz in ključe API v teh storitvah. Preverjam, ali kompromitirane poverilnice IAM omogočajo pridobitev shranjenih skrivnosti.
  • Javni dostop do RDS - Primerki podatkovnih baz z omogočeno zastavico PubliclyAccessible in varnostnimi skupinami, ki dovoljujejo vhodni dostop z 0.0.0.0/0.
  • Deljenje posnetkov EBS - Posnetki EBS, deljeni javno ali z nenameravanimi računi AWS. Ti lahko vsebujejo občutljive podatke, poverilnice ali zasebne ključe.

Dejavnosti po pridobitvi dostopa

Ko je začetni dostop pridobljen, se pozornost preusmeri na širjenje dostopa in dokazovanje vpliva:

  • Pridobivanje poverilnic iz storitve metapodatkov - Storitev metapodatkov primerka EC2 (IMDS) zagotavlja začasne poverilnice. IMDSv1 je ranljiv za napade na osnovi SSRF, medtem ko IMDSv2 zahteva žeton seje, vendar je še vedno dostopen iz samega primerka.
  • Lateralno premikanje prek SSM - Systems Manager Session Manager zagotavlja dostop do lupine na primerkih EC2 brez potrebe po ključih SSH ali odprtih vratih. Kompromitirane poverilnice z dovoljenji SSM omogočajo lateralno premikanje po celotni floti.
  • Ekstrakcija podatkov - S3 je pogosta pot za ekstrakcijo. Preverjam tudi ekstrakcijo na osnovi DNS prek resolverjev Route 53 in končnih točk VPC, ki omogočajo pretok podatkov do ciljev pod nadzorom napadalca.

Zaznava, obramba in spremljanje

  • CloudTrail - Zagotovite, da je CloudTrail omogočen v vseh regijah z validacijo dnevniških datotek. Spremljajte visoko tvegane klice API, kot so CreateAccessKey, PutRolePolicy in CreateLoginProfile.
  • GuardDuty - Storitev AWS za zaznavo groženj, ki prepozna anomalne klice API, rudarjenje kriptovalut in kompromitirane poverilnice. Je ena najvrednejših varnostnih storitev za vklop.
  • Pravila AWS Config - Uveljavljajte pravila skladnosti, kot so zahteva šifriranja za vsebnike S3, zahteva MFA za uporabnike IAM in prepoved vhodnega prometa z 0.0.0.0/0 v varnostnih skupinah.
  • Politike nadzora storitev (SCP) - Politike na ravni organizacije, ki omejujejo, kaj članski računi lahko počnejo, ne glede na njihove politike IAM. SCP-ji so najmočnejši varovalni mehanizem v AWS Organizations.

Orodja in metodologija

Dobro zastavljen penetracijski test AWS se običajno začne s pregledom v načinu samo za branje, nadaljuje z ugotavljanjem poti stopnjevanja pravic in zaključi z dokazovanjem vpliva prek nadzorovanega izkoriščanja.

  • Pacu - Okvir za izkoriščanje AWS podjetja Rhino Security Labs. Avtomatizira popis, stopnjevanje pravic in naloge po pridobitvi dostopa.
  • ScoutSuite - Orodje za varnostno revizijo več oblakov, ki generira obsežna poročila HTML o napačnih konfiguracijah v vseh storitvah AWS.
  • Prowler - Orodje za ocenjevanje najboljših praks varnosti AWS, usklajeno z merili CIS in drugimi okviri skladnosti.
  • enumerate-iam - Z grobo silo določa dovoljenja IAM za dane poverilnice s poskusom klicev API v vseh storitvah AWS.
  • aws_consoler - Pretvori dostopne ključe AWS v URL seje brskalniške konzole, kar je uporabno za vizualno raziskovanje okolja med ocenjevanjem.

Vedno zagotovite, da je vaše testiranje pravilno zamejeno s podpisanim dokumentom o pravilih delovanja. AWS zahteva obvestilo za določene vrste testiranja, vsa dejavnost pa mora ostati znotraj meja lastniških računov in izrecno pooblaščenih storitev.

Sorodno branje: Pregled pravic v oblaku: storitveni računi in najmanjše potrebne pravice in Napadi SSRF: Ko se strežniki napadejo sami.

Vid Grosek

Vid Grosek

Etični heker & Penetracijski tester

Pomagam slovenskim podjetjem odkriti varnostne ranljivosti, preden jih odkrijejo napadalci. Z več kot 18 leti izkušenj v kibernetski varnosti.

Vse objave

Komentarji

Ni še komentarjev. Bodite prvi!

Dodaj komentar

Vam je bil članek všeč?

Prijavite se na newsletter za mesečne varnostne vpoglede.

Prijavite se