AWS - IAM Post Exploitation
IAM
Kwa maelezo zaidi kuhusu upatikanaji wa IAM:
AWS - IAM, Identity Center & SSO EnumTatizo la Naibu Aliyechanganyikiwa
Ikiwa unaruhusu akaunti ya nje (A) kufikia jukumu katika akaunti yako, kuna uwezekano mkubwa wa kuwa na 0 mwonekano juu ya nani anaweza kufikia akaunti hiyo ya nje. Hili ni tatizo, kwa sababu ikiwa akaunti nyingine ya nje (B) inaweza kufikia akaunti ya nje (A) inawezekana kwamba B pia ataweza kufikia akaunti yako.
Kwa hiyo, wakati wa kuruhusu akaunti ya nje kufikia jukumu katika akaunti yako inawezekana kubainisha ExternalId
. Hii ni kamba ya "siri" ambayo akaunti ya nje (A) inahitaji kubainisha ili kuchukua jukumu katika shirika lako. Kwa kuwa akaunti ya nje B haitajua kamba hii, hata kama ana ufikiaji juu ya A hataweza kufikia jukumu lako.
Hata hivyo, kumbuka kwamba ExternalId
hii "siri" sio siri, yeyote anayeweza kusoma sera ya kuchukua jukumu la IAM ataweza kuiona. Lakini mradi akaunti ya nje A inajua, lakini akaunti ya nje B haijui, inazuia B kutumia vibaya A kufikia jukumu lako.
Mfano:
Kwa mshambulizi kutumia confused deputy atahitaji kugundua kwa namna fulani kama principals wa akaunti ya sasa wanaweza kuiga majukumu katika akaunti nyingine.
Uaminifu Usiyotarajiwa
Wildcard kama principal
Sera hii inaruhusu AWS zote kuchukua jukumu hilo.
Huduma kama mkuu
Sera hii inaruhusu akaunti yoyote kusanidi apigateway yao kupiga simu kwa Lambda hii.
S3 kama principal
Ikiwa ndoo ya S3 imetolewa kama mkuu, kwa sababu ndoo za S3 hazina Kitambulisho cha Akaunti, ikiwa ulifuta ndoo yako na mshambuliaji akaumba katika akaunti yao wenyewe, basi wangeweza kutumia hii vibaya.
Haijaungwa mkono
Njia ya kawaida ya kuepuka matatizo ya Confused Deputy ni kutumia hali na AWS:SourceArn
ili kuangalia asili ya ARN. Hata hivyo, huduma zingine zinaweza zisikubali hiyo (kama CloudTrail kulingana na vyanzo vingine).
Marejeleo
Last updated