AWS - IAM & STS Unauthenticated Enum
Enumerate Roles & Gebruikersname in 'n rekening
Neem Rol Brute-Force aan
Hierdie tegniek werk nie meer nie, aangesien jy altyd hierdie fout kry, of die rol bestaan of nie:
'n Fout het voorgekom (AccessDenied) tydens die aanroep van die AssumeRole-operasie: Gebruiker: arn:aws:iam::947247140022:user/testenv is nie gemagtig om uit te voer: sts:AssumeRole op hulpbron: arn:aws:iam::429217632764:role/account-balanceasdas
Jy kan dit toets deur te hardloop:
aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example
Pogings om 'n rol aan te neem sonder die nodige toestemmings veroorsaak 'n AWS-foutboodskap. Byvoorbeeld, as ongemagtig, kan AWS teruggee:
Hierdie boodskap bevestig die rol se bestaan, maar dui aan dat sy aanvaar rol beleid nie jou aanname toelaat nie. Daarenteen, as jy probeer om 'n nie-bestaande rol aan te neem, lei dit tot 'n ander fout:
Interessant genoeg is hierdie metode van onderskeiding tussen bestaande en nie-bestaande rolle selfs toepaslik oor verskillende AWS-rekeninge. Met 'n geldige AWS-rekening-ID en 'n geteikende woordelys, kan 'n persoon die rolle wat in die rekening teenwoordig is, opnoem sonder om enige inherente beperkings te ervaar.
Jy kan hierdie skripsie gebruik om potensiële beginsels op te som deur hierdie probleem te misbruik.
Vertrouensbeleide: Brute-Force Cross Account rolle en gebruikers
Die konfigurasie of opdatering van 'n IAM-rol se vertrouensbeleid behels die definisie van watter AWS-hulpbronne of dienste mag daardie rol aanneem en tydelike geloofsbriewe verkry. As die gespesifiseerde hulpbron in die beleid bestaan, stoor die vertrouensbeleid suksesvol. Indien die hulpbron egter nie bestaan nie, word 'n fout gegenereer, wat aandui dat 'n ongeldige beginsel voorsien is.
Let daarop dat jy in daardie hulpbron 'n kruisrekeningrol of -gebruiker kan spesifiseer:
arn:aws:iam::acc_id:role/role_name
arn:aws:iam::acc_id:user/user_name
Hierdie is 'n beleidsvoorbeeld:
GUI
Dit is die fout wat jy sal vind as jy 'n rol gebruik wat nie bestaan nie. As die rol bestaan, sal die beleid gestoor word sonder enige foute. (Die fout is vir opdatering, maar werk ook wanneer dit geskep word)
CLI
Jy kan hierdie proses outomatiseer met https://github.com/carlospolop/aws_tools
bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt
Ons gebruik Pacu:
run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt
Die
admin
rol wat in die voorbeeld gebruik word, is 'n rol in jou rekening wat deur pacu geïmpersoneer moet word om die beleide te skep wat dit vir die opname nodig het
Privesc
In die geval dat die rol sleg opgestel is en enigeen toegelaat word om dit aan te neem:
Die aanvaller kan dit net aanneem.
Derde Party OIDC Federasie
Stel jou voor dat jy daarin slaag om 'n Github-handelinge werkstroom te lees wat 'n rol binne AWS toegang gee. Hierdie vertroue mag toegang gee tot 'n rol met die volgende vertrouensbeleid:
Hierdie vertrouensbeleid mag korrek wees, maar die gebrek aan meer voorwaardes behoort jou wantrouig te maak. Dit is omdat die vorige rol aangeneem kan word deur ENIGEEN van Github Aksies! Jy behoort ook ander dinge soos organisasienaam, reponaam, omgewing, tak in die voorwaardes te spesifiseer...
'n Ander potensiële konfigurasiefout is om 'n voorwaarde by te voeg soos die volgende:
Merk op dat wildcard (*) voor die kolon (:). Jy kan 'n org soos org_name1 skep en die rol aanvaar vanaf 'n Github Aksie.
Verwysings
Last updated