Serbian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Basic Information

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Organizaciona hijerarhija

Nalozi

U AWS-u postoji root nalog, koji je roditeljski kontejner za sve naloge vaše organizacije. Međutim, nije potrebno koristiti taj nalog za implementaciju resursa, možete kreirati druge naloge da biste razdvojili različite AWS infrastrukture među njima.

Ovo je veoma interesantno sa bezbednosnog aspekta, jer jedan nalog neće moći pristupiti resursima iz drugog naloga (osim ako su mostovi specifično kreirani), na ovaj način možete kreirati granice između implementacija.

Stoga, postoje dva tipa naloga u organizaciji (govorimo o AWS nalozima, a ne korisničkim nalozima): jedan nalog koji je određen kao nalog za upravljanje, i jedan ili više članskih naloga.

  • Nalog za upravljanje (root nalog) je nalog koji koristite za kreiranje organizacije. Iz upravljačkog naloga organizacije, možete uraditi sledeće:

  • Kreirati naloge u organizaciji

  • Pozvati druge postojeće naloge u organizaciju

  • Ukloniti naloge iz organizacije

  • Upravljati pozivima

  • Primeniti politike na entitete (root, OU ili nalozi) unutar organizacije

  • Omogućiti integraciju sa podržanim AWS uslugama kako bi se obezbedila funkcionalnost usluge širom svih naloga u organizaciji.

  • Moguće je prijaviti se kao root korisnik koristeći email i lozinku korištene za kreiranje ovog root naloga/organizacije.

Nalog za upravljanje ima odgovornosti platnog naloga i odgovoran je za plaćanje svih troškova koji se akumuliraju od strane članskih naloga. Ne možete promeniti nalog za upravljanje organizacijom.

  • Članski nalozi čine sve ostale naloge u organizaciji. Nalog može biti član samo jedne organizacije u isto vreme. Možete priložiti politiku na nalog da biste primenili kontrole samo na taj nalog.

  • Članski nalozi moraće koristiti validnu email adresu i mogu imati ime, generalno neće moći upravljati fakturisanjem (ali im može biti omogućen pristup).

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Organizacione jedinice

Nalozi mogu biti grupisani u Organizacione jedinice (OU). Na ovaj način, možete kreirati polise za Organizacionu jedinicu koje će biti primenjene na sve podračune. Imajte na umu da OU može imati druge OU kao podračune.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Politika kontrole usluga (SCP)

Politika kontrole usluga (SCP) je politika koja specificira usluge i akcije koje korisnici i uloge mogu koristiti u računima na koje SCP utiče. SCP-ovi su slični IAM politikama dozvola osim što ne dodeljuju nikakve dozvole. Umesto toga, SCP-ovi specificiraju maksimalne dozvole za organizaciju, organizacionu jedinicu (OU) ili račun. Kada priložite SCP organizacionom korenu ili OU, SCP ograničava dozvole za entitete u članovskim računima.

Ovo je JEDINI način da čak i korisnik korena bude zaustavljen u obavljanju određenih radnji. Na primer, može se koristiti za sprečavanje korisnika da onemoguće CloudTrail ili brišu rezervne kopije. Jedini način zaobići ovo je kompromitovati glavni račun koji konfiguriše SCP-ove (glavni račun ne može biti blokiran).

Imajte na umu da SCP-ovi samo ograničavaju principe u računu, tako da drugi računi nisu pogođeni. To znači da zabrana SCP-a za s3:GetObject neće zaustaviti ljude da pristupaju javnom S3 spremištu u vašem računu.

Primeri SCP-a:

  • Potpuna zabrana korenskog računa

  • Dozvoljene samo određene regione

  • Dozvoljene samo bele-listirane usluge

  • Zabrana onemogućavanja GuardDuty, CloudTrail-a i pristupa javnom S3 spremištu

  • Zabrana brisanja sigurnosnih/odgovornih uloga

ili njihovog menjanja.

  • Zabrana brisanja rezervnih kopija.

  • Zabrana kreiranja IAM korisnika i pristupnih ključeva

Pronađite JSON primere na https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

ARN

Amazon Resource Name je jedinstveno ime koje svaki resurs unutar AWS-a ima, sastavljen je na sledeći način:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

Napomena da postoje 4 particije u AWS-u, ali samo 3 načina da ih nazovete:

  • AWS Standard: aws

  • AWS Kina: aws-cn

  • AWS US javni internet (GovCloud): aws-us-gov

  • AWS Tajno (US Klasifikovano): aws

IAM - Identitet i Upravljanje pristupom

IAM je usluga koja će vam omogućiti da upravljate Autentifikacijom, Autorizacijom i Kontrolom pristupa unutar vašeg AWS naloga.

  • Autentifikacija - Proces definisanja identiteta i verifikacije tog identiteta. Ovaj proces može biti podijeljen na: Identifikaciju i verifikaciju.

  • Autorizacija - Određuje na šta identitet može pristupiti unutar sistema nakon što je autentifikovan.

  • Kontrola pristupa - Metod i proces kako se pristup odobrava sigurnom resursu.

IAM se može definisati po svojoj sposobnosti da upravlja, kontroliše i vlada autentifikacijom, autorizacijom i mehanizmima kontrole pristupa identiteta vašim resursima unutar vašeg AWS naloga.

Korisnik korenskog naloga AWS-a

Kada prvi put kreirate Amazon Web Services (AWS) nalog, počinjete sa jednim identitetom za prijavljivanje koji ima potpuni pristup svim AWS uslugama i resursima u nalogu. Ovo je AWS nalog korenskog korisnika i pristupa mu se prijavljivanjem sa email adresom i lozinkom koju ste koristili prilikom kreiranja naloga.

Napomena da će novi admin korisnik imati manje dozvola od korenskog korisnika.

Sa aspekta bezbednosti, preporučljivo je kreirati druge korisnike i izbegavati korišćenje ovog.

IAM korisnici

IAM korisnik je entitet koji kreirate u AWS-u da predstavlja osobu ili aplikaciju koja ga koristi za interakciju sa AWS-om. Korisnik u AWS-u se sastoji od imena i akreditacija (lozinke i do dva pristupna ključa).

Kada kreirate IAM korisnika, dodeljujete mu dozvole tako što ga činite članom grupe korisnika koja ima odgovarajuće politike dozvola pridružene (preporučljivo), ili direktnim pridruživanjem politika korisniku.

Korisnici mogu imati omogućen MFA za prijavljivanje putem konzole. API tokeni korisnika sa omogućenim MFA nisu zaštićeni MFA-om. Ako želite ograničiti pristup API ključevima korisnika korišćenjem MFA morate naznačiti u politici da je potrebno prisustvo MFA za obavljanje određenih akcija (primer ovde).

CLI

  • ID pristupnog ključa: 20 nasumičnih velikih alfanumeričkih karaktera poput AKHDNAPO86BSHKDIRYT

  • Tajni ID pristupnog ključa: 40 nasumičnih velikih i malih karaktera: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Nije moguće povratiti izgubljene tajne ID pristupne ključeve).

Kada god trebate promeniti pristupni ključ ovo je proces koji trebate pratiti: Kreirajte novi pristupni ključ -> Primijenite novi ključ na sistem/aplikaciju -> označite originalni kao neaktivan -> Testirajte i verifikujte da novi pristupni ključ radi -> Obrišite stari pristupni ključ

MFA - Višefaktorska autentifikacija

Koristi se da kreira dodatni faktor za autentifikaciju pored vaših postojećih metoda, poput lozinke, stvarajući tako višefaktorski nivo autentifikacije. Možete koristiti besplatnu virtuelnu aplikaciju ili fizički uređaj. Možete koristiti aplikacije poput google autentifikacije besplatno da aktivirate MFA u AWS-u.

Politike sa MFA uslovima mogu biti pridružene sledećem:

  • IAM korisniku ili grupi

  • Resursu poput Amazon S3 kante, Amazon SQS reda ili Amazon SNS teme

  • Povereničkoj politici IAM uloge koju može preuzeti korisnik

Ako želite pristupiti putem CLI-ja resursu koji proverava MFA morate pozvati GetSessionToken. To će vam dati token sa informacijama o MFA. Napomena da poverenički podaci AssumeRole ne sadrže ove informacije.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

Kako je navedeno ovde, postoji mnogo različitih slučajeva gde se MFA ne može koristiti.

IAM grupe korisnika

IAM grupa korisnika je način da se pridruže politike više korisnika istovremeno, što može olakšati upravljanje dozvolama za te korisnike. Uloge i grupe ne mogu biti deo grupe.

Možete pridružiti politiku zasnovanu na identitetu grupi korisnika tako da svi korisnici u grupi korisnika dobiju dozvole politike. Ne možete identifikovati grupu korisnika kao Principal u politici (kao što je politika zasnovana na resursima) jer grupe se odnose na dozvole, a ne na autentifikaciju, a principali su autentifikovani IAM entiteti.

Evo nekih važnih karakteristika grupa korisnika:

  • Jedna grupa može sadržavati mnogo korisnika, a korisnik može pripadati više grupa.

  • Grupe korisnika ne mogu biti ugnježdene; mogu sadržavati samo korisnike, a ne druge grupe korisnika.

  • Ne postoji podrazumevana grupa korisnika koja automatski uključuje sve korisnike u AWS nalogu. Ako želite da imate takvu grupu korisnika, morate je kreirati i dodeliti svakom novom korisniku.

  • Broj i veličina IAM resursa u AWS nalogu, kao što su broj grupa i broj grupa kojima korisnik može pripadati, su ograničeni. Za više informacija, pogledajte IAM i AWS STS kvote.

IAM uloge

IAM uloga je veoma slična korisniku, jer je to identitet sa politikama dozvola koje određuju šta može i ne može raditi u AWS. Međutim, uloga nema nikakve akreditive (šifru ili pristupne ključeve) povezane sa njom. Umesto što je jedinstveno povezana sa jednom osobom, uloga je namenjena da bude preuzimljiva od strane bilo koga ko je potreban (i ima dovoljno dozvola). IAM korisnik može preuzeti ulogu da privremeno preuzme različite dozvole za određeni zadatak. Uloga može biti dodeljena federativnom korisniku koji se prijavljuje koristeći spoljni provajder identiteta umesto IAM-a.

IAM uloga se sastoji od dva tipa politika: poverenička politika, koja ne može biti prazna, definiše ko može preuzeti ulogu, i dozvole politike, koje ne mogu biti prazne, definišu na šta može pristupiti.

AWS Security Token Service (STS)

AWS Security Token Service (STS) je web servis koji olakšava izdavanje privremenih, ograničenih privilegovanih akreditiva. Specifično je prilagođen za:

Privremeni akreditivi u IAM-u

Privremeni akreditivi se koriste pretežno sa IAM ulogama, ali postoje i drugi slučajevi. Možete zatražiti privremene akreditive koji imaju set dozvola sa strožijim ograničenjima od vašeg standardnog IAM korisnika. Ovo sprečava vas da slučajno obavljate zadatke koji nisu dozvoljeni sa strožijim akreditivima. Prednost privremenih akreditiva je što automatski ističu nakon određenog vremenskog perioda. Imate kontrolu nad trajanjem važenja akreditiva.

Politike

Dozvole politika

Koriste se za dodelu dozvola. Postoje 2 tipa:

  • AWS upravljane politike (unapred konfigurisane od strane AWS-a)

  • Korisnički upravljane politike: Konfigurisane od strane vas. Možete kreirati politike zasnovane na AWS upravljanim politikama (modifikujući jednu od njih i kreirajući svoju), koristeći generator politika (GUI prikaz koji vam pomaže da dodeljujete i odbijate dozvole) ili pišući svoje vlastite..

Po podrazumevanom pristupu je odbijen, pristup će biti odobren ako je eksplicitno navedena uloga. Ako postoji jedno "Odbij" pravilo, ono će prebrisati "Dozvoli", osim za zahteve koji koriste osnovne bezbednosne akreditive AWS naloga (koji su podrazumevano dozvoljeni).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

Globalna polja koja se mogu koristiti za uslove u bilo kojoj usluzi dokumentovana su ovde. Specifična polja koja se mogu koristiti za uslove po usluzi dokumentovana su ovde.

Inline Politike

Ova vrsta politika se direktno dodeljuje korisniku, grupi ili ulozi. Zatim, ne pojavljuju se u listi politika kao što se mogu koristiti druge. Inline politike su korisne ako želite da održavate strogu jedan-na-jedan vezu između politike i identiteta na koji se primenjuje. Na primer, želite da budete sigurni da dozvole u politici nisu nenamerno dodeljene identitetu za koji nisu namenjene. Kada koristite inline politiku, dozvole u politici ne mogu biti nenamerno pridodate pogrešnom identitetu. Pored toga, kada koristite AWS Management konzolu za brisanje tog identiteta, politike ugrađene u identitet takođe se brišu. To je zato što su deo glavne entiteta.

Politike za resurse

Ovo su politike koje se mogu definisati u resursima. Nisu svi resursi AWS-a podržani.

Ako glavni subjekt nema eksplicitno odbijanje na njima, i politika resursa im dodeljuje pristup, tada su dozvoljeni.

IAM Granice

IAM granice se mogu koristiti da ograniče dozvole koje korisnik ili uloga treba da ima pristup. Na ovaj način, čak i ako korisniku bude dodeljen različit set dozvola putem različite politike, operacija će neuspeti ako pokuša da ih koristi.

Granica je samo politika pridružena korisniku koja ukazuje na maksimalni nivo dozvola koje korisnik ili uloga mogu imati. Dakle, čak i ako korisnik ima administratorski pristup, ako granica ukazuje da može samo čitati S3 kante, to je maksimum koji može uraditi.

Ovo, SCPs i princip najmanjih privilegija su načini da se kontroliše da korisnici nemaju više dozvola nego što im je potrebno.

Politike sesije

Politika sesije je politika postavljena kada se uloga pretpostavi na neki način. To će biti kao IAM granica za tu sesiju: To znači da politika sesije ne dodeljuje dozvole već ih ograničava na one navedene u politici (pri čemu su maksimalne dozvole one koje uloga ima).

Ovo je korisno za mere bezbednosti: Kada administrator preuzima veoma privilegovanu ulogu, može ograničiti dozvole samo na one navedene u politici sesije u slučaju da sesija bude kompromitovana.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

Napomena da AWS po defaultu može dodati sesijske politike sesijama koje će biti generisane zbog trećih razloga. Na primer, u neautentifikovanim kognito pretpostavljenim ulogama po defaultu (koristeći poboljšanu autentifikaciju), AWS će generisati sesijske akreditive sa sesijskom politikom koja ograničava usluge kojima sesija može pristupiti na sledećoj listi.

Stoga, ako u nekom trenutku naiđete na grešku "... jer nijedna sesijska politika ne dozvoljava ...", a uloga ima pristup za obavljanje radnje, to je zato što postoji sesijska politika koja to sprečava.

Identitetska federacija

Identitetska federacija omogućava korisnicima iz spoljnih provajdera identiteta da pristupe AWS resursima bezbedno, bez potrebe za snabdevanjem AWS korisničkim akreditivima iz validnog IAM korisničkog naloga. Primer identitetskog provajdera može biti vaš sopstveni korporativni Microsoft Active Directory(putem SAML) ili OpenID servisi (kao što je Google). Federisani pristup će zatim omogućiti korisnicima unutar njega pristup AWS-u.

Za konfigurisanje ovog poverenja, generiše se IAM provajder identiteta (SAML ili OAuth) koji će poveriti drugu platformu. Zatim, bar jedna IAM uloga je dodeljena (poverava se) provajderu identiteta. Ako korisnik sa poverene platforme pristupi AWS-u, pristupiće kao pomenuta uloga.

Međutim, obično ćete želeti da dodelite različitu ulogu u zavisnosti od grupe korisnika u platformi trećeg lica. Zatim, nekoliko IAM uloga može poveriti provajderu identiteta trećeg lica i treća platforma će omogućiti korisnicima da pretpostave jednu ili drugu ulogu.

IAM Centar identiteta

AWS IAM Centar identiteta (naslednik AWS Single Sign-On) proširuje mogućnosti AWS Identity and Access Management (IAM) pružajući centralno mesto koje objedinjuje administraciju korisnika i njihov pristup AWS nalozima i cloud aplikacijama.

Domen za prijavu će biti nešto poput <user_input>.awsapps.com.

Za prijavu korisnika, mogu se koristiti 3 izvora identiteta:

  • Direktorijum Centra identiteta: Redovni AWS korisnici

  • Active Directory: Podržava različite konektore

  • Spoljni provajder identiteta: Svi korisnici i grupe dolaze iz spoljnog provajdera identiteta (IdP)

U najjednostavnijem slučaju direktorijuma Centra identiteta, Centar identiteta će imati listu korisnika i grupa i moći će im dodeliti politike za bilo koji od naloga organizacije.

Da bi se omogućio pristup korisniku/grupi Centra identiteta na nalog, SAML provajder identiteta koji poverava Centar identiteta će biti kreiran, i uloga koja poverava provajdera identiteta sa naznačenim politikama će biti kreirana u odredišnom nalogu.

AwsSSOInlinePolicy

Moguće je dodeliti dozvole putem ugrađenih politika ulogama kreiranim putem IAM Centra identiteta. Uloge kreirane u nalozima kojima su dodeljene ugrađene politike u AWS Centru identiteta će imati ove dozvole u ugrađenoj politici nazvanoj AwsSSOInlinePolicy.

Stoga, čak i ako vidite 2 uloge sa ugrađenom politikom nazvanom AwsSSOInlinePolicy, to ne znači da imaju iste dozvole.

Poverenja i uloge između naloga

Korisnik (poverava) može kreirati ulogu između naloga sa određenim politikama i zatim, dozvoliti drugom korisniku (poverenom) da pristupi njegovom nalogu ali samo sa pristupom naznačenim u politikama nove uloge. Da biste to kreirali, jednostavno kreirajte novu ulogu i izaberite Ulogu između naloga. Uloge za pristup između naloga nude dve opcije. Pružanje pristupa između AWS naloga koje posedujete, i pružanje pristupa između naloga koje posedujete i AWS naloga trećeg lica. Preporučuje se da specifikujete korisnika koji je poveren i ne stavljate nešto generičko jer u suprotnom, drugi autentifikovani korisnici poput federisanih korisnika takođe će moći zloupotrebiti ovo poverenje.

AWS Jednostavni AD

Nije podržano:

  • Poverenja

  • AD Admin Centar

  • Potpuna podrška za PS API

  • AD Korpa za otpatke

  • Grupisani upravljani servisni nalozi

  • Proširenja šeme

  • Nema direktnog pristupa OS-u ili instancama

Web federacija ili OpenID autentifikacija

Aplikacija koristi AssumeRoleWithWebIdentity za kreiranje privremenih akreditiva. Međutim, ovo ne daje pristup AWS konzoli, već pristup resursima unutar AWS-a.

Druge IAM opcije

  • Možete postaviti politiku lozinke sa opcijama kao što su minimalna dužina i zahtevi za lozinku.

  • Možete preuzeti "Izveštaj o akreditivima" sa informacijama o trenutnim akreditivima (kao što su vreme kreiranja korisnika, da li je lozinka omogućena...). Možete generisati izveštaj o akreditivima najčešće jednom svakih četiri sata.

AWS Identity and Access Management (IAM) pruža detaljnu kontrolu pristupa širom AWS-a. Sa IAM-om, možete odrediti ko može pristupiti kojim uslugama i resursima, i pod kojim uslovima. Sa IAM politikama, upravljate dozvolama vašem radnom osoblju i sistemima kako biste osigurali dozvole sa najmanje privilegija.

IAM ID Prefiksi

Na ovoj stranici možete pronaći IAM ID prefikse ključeva u zavisnosti od njihove prirode:

ABIA

AWS STS servisni nosilac tokena

ACCA

Kontekstualni specifični akreditiv

AGPA

Korisnička grupa

AIDA

IAM korisnik

AIPA

Amazon EC2 profil instance

AKIA

Pristupni ključ

ANPA

Upravljana politika

ANVA

Verzija u upravljanoj politici

APKA

Javni ključ

AROA

Uloga

ASCA

Sertifikat

ASIA

Privremeni (AWS STS) ID ključevi pristupa koriste ovaj prefiks, ali su jedinstveni samo u kombinaciji sa tajnim pristupnim ključem i tokenom sesije.

Preporučene dozvole za proveru naloga

Sledeće privilegije omogućavaju različit pristup metapodacima:

  • arn:aws:iam::aws:policy/SecurityAudit

  • arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

  • codebuild:ListProjects

  • config:Describe*

  • cloudformation:ListStacks

  • logs:DescribeMetricFilters

  • directconnect:DescribeConnections

  • dynamodb:ListTables

Razno

CLI Autentifikacija

Da bi običan korisnik autentifikovao se na AWS putem CLI-a, potrebno je imati lokalne akreditive. Po defaultu ih možete konfigurisati ručno u ~/.aws/credentials ili pokretanjem aws configure. U tom fajlu možete imati više od jednog profila, ako nije specificiran profil koristeći aws cli, biće korišćen onaj nazvan [default] u tom fajlu. Primer fajla sa akreditivima sa više od 1 profila:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

Ako treba da pristupite različitim AWS nalozima i vašem profilu je data dozvola da pretpostavi ulogu unutar tih naloga, ne morate ručno pozivati STS svaki put (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) i konfigurisati akreditive.

Možete koristiti datoteku ~/.aws/config da naznačite koje uloge pretpostaviti, a zatim koristiti --profile parametar kao i obično (pretpostavljanje uloge će se obaviti na transparentan način za korisnika). Primer konfiguracione datoteke:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Sa ovom konfiguracionom datotekom možete koristiti aws cli na sledeći način:

aws --profile acc2 ...

Ako tražite nešto slično ovome ali za pregledač možete proveriti dodatak AWS Extend Switch Roles.

Reference

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

PreviousAWS PentestingNextAWS - Federation Abuse

Last updated