Last updated
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
В AWS є кореневий обліковий запис, який є батьківським контейнером для всіх облікових записів вашої організації. Однак вам не потрібно використовувати цей обліковий запис для розгортання ресурсів, ви можете створити інші облікові записи, щоб розділити різні AWS інфраструктури між ними.
Це дуже цікаво з точки зору безпеки, оскільки один обліковий запис не зможе отримати доступ до ресурсів з іншого облікового запису (якщо не створені спеціальні мости), тому таким чином ви можете створити межі між розгортаннями.
Отже, в організації є два типи облікових записів (ми говоримо про облікові записи AWS, а не про облікові записи користувачів): один обліковий запис, який призначений як обліковий запис управління, і один або кілька облікових записів учасників.
Обліковий запис управління (кореневий обліковий запис) - це обліковий запис, який ви використовуєте для створення організації. З облікового запису управління організації ви можете зробити наступне:
Створювати облікові записи в організації
Запрошувати інші існуючі облікові записи до організації
Видаляти облікові записи з організації
Керувати запрошеннями
Застосовувати політики до сутностей (корені, ОУ або облікові записи) в межах організації
Увімкнути інтеграцію з підтримуваними AWS сервісами для надання функціональності сервісу для всіх облікових записів в організації.
Можливо увійти як кореневий користувач, використовуючи електронну пошту та пароль, які використовувалися для створення цього кореневого облікового запису/організації.
Обліковий запис управління має обов'язки облікового запису платника і відповідає за оплату всіх витрат, які накопичуються учасниками. Ви не можете змінити обліковий запис управління організації.
Облікові записи учасників складають всі інші облікові записи в організації. Обліковий запис може бути учасником лише однієї організації одночасно. Ви можете прикріпити політику до облікового запису, щоб застосувати контролі лише до цього одного облікового запису.
Облікові записи учасників повинні використовувати дійсну електронну адресу і можуть мати ім'я, загалом вони не зможуть керувати виставленням рахунків (але їм можуть надати доступ до цього).
Облікові записи можна групувати в Організаційні одиниці (OU). Таким чином, ви можете створювати політики для Організаційної одиниці, які будуть застосовані до всіх дочірніх облікових записів. Зверніть увагу, що OU може мати інші OU як дочірні.
Політика контролю послуг (SCP) - це політика, яка визначає послуги та дії, які користувачі та ролі можуть використовувати в облікових записах, на які впливає SCP. SCP є схожими на політики дозволів IAM, за винятком того, що вони не надають жодних дозволів. Натомість SCP визначають максимальні дозволи для організації, організаційної одиниці (OU) або облікового запису. Коли ви прикріплюєте SCP до кореня вашої організації або OU, SCP обмежує дозволи для суб'єктів у членських облікових записах.
Це є ЄДИНИМ способом, яким навіть кореневий користувач може бути зупинений від виконання певних дій. Наприклад, його можна використовувати, щоб зупинити користувачів від вимкнення CloudTrail або видалення резервних копій. Єдиний спосіб обійти це - також скомпрометувати майстер-обліковий запис, який налаштовує SCP (майстер-обліковий запис не може бути заблокований).
Зверніть увагу, що SCP лише обмежують суб'єктів у обліковому записі, тому інші облікові записи не підлягають впливу. Це означає, що наявність SCP, яка забороняє s3:GetObject, не зупинить людей від доступу до публічного S3 бакету у вашому обліковому записі.
Приклади SCP:
Повна заборона кореневого облікового запису
Дозволити лише конкретні регіони
Дозволити лише сервіси зі списку дозволених
Заборонити вимкнення GuardDuty, CloudTrail та S3 Public Block Access
Заборонити видалення або модифікацію ролей безпеки/реагування на інциденти.
Заборонити видалення резервних копій.
Заборонити створення користувачів IAM та ключів доступу
Знайдіть приклади JSON за адресою https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
Ідентифікатор ресурсу Amazon - це унікальна назва, яку має кожен ресурс всередині AWS, вона складається ось так:
Зверніть увагу, що в AWS є 4 розділи, але лише 3 способи їх виклику:
AWS Standard: aws
AWS China: aws-cn
AWS US public Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws
IAM - це сервіс, який дозволяє вам керувати Аутентифікацією, Авторизацією та Контролем доступу у вашому обліковому записі AWS.
Аутентифікація - Процес визначення особи та перевірки цієї особи. Цей процес можна поділити на: Ідентифікацію та перевірку.
Авторизація - Визначає, до чого може отримати доступ особа в системі після її аутентифікації.
Контроль доступу - Метод і процес надання доступу до захищеного ресурсу.
IAM можна визначити за його здатністю керувати, контролювати та регулювати механізми аутентифікації, авторизації та контролю доступу особистостей до ваших ресурсів у вашому обліковому записі AWS.
Коли ви вперше створюєте обліковий запис Amazon Web Services (AWS), ви починаєте з єдиної особи для входу, яка має повний доступ до всіх сервісів та ресурсів AWS в обліковому записі. Це кореневий користувач облікового запису AWS, до якого ви отримуєте доступ, увійшовши з електронною адресою та паролем, які ви використовували для створення облікового запису.
Зверніть увагу, що новий адміністратор матиме менше прав, ніж кореневий користувач.
З точки зору безпеки рекомендується створити інших користувачів і уникати використання цього.
Користувач IAM - це сутність, яку ви створюєте в AWS, щоб представити особу або додаток, який використовує його для взаємодії з AWS. Користувач в AWS складається з імені та облікових даних (пароль та до двох ключів доступу).
Коли ви створюєте користувача IAM, ви надаєте йому дозволи, роблячи його членом групи користувачів, до якої прикріплені відповідні політики дозволів (рекомендується), або безпосередньо прикріплюючи політики до користувача.
Користувачі можуть мати увімкнене MFA для входу через консоль. API токени користувачів з увімкненим MFA не захищені MFA. Якщо ви хочете обмежити доступ ключів API користувачів за допомогою MFA, вам потрібно вказати в політиці, що для виконання певних дій MFA має бути присутнім (приклад тут).
ID ключа доступу: 20 випадкових великих алфавітно-цифрових символів, таких як AKHDNAPO86BSHKDIRYT
ID секретного ключа доступу: 40 випадкових великих і малих символів: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (неможливо відновити втрачені ID секретного ключа доступу).
Коли вам потрібно змінити ключ доступу, це процес, який ви повинні виконати: Створіть новий ключ доступу -> Застосуйте новий ключ до системи/додатку -> позначте оригінальний як неактивний -> Тестуйте та перевірте, що новий ключ доступу працює -> Видаліть старий ключ доступу
Вона використовується для створення додаткового фактора для аутентифікації на додаток до ваших існуючих методів, таких як пароль, тим самим створюючи багатофакторний рівень аутентифікації. Ви можете використовувати безкоштовний віртуальний додаток або фізичний пристрій. Ви можете безкоштовно використовувати такі додатки, як Google Authenticator, щоб активувати MFA в AWS.
Політики з умовами MFA можуть бути прикріплені до наступного:
Користувача або групи IAM
Ресурсу, такому як кошик Amazon S3, черга Amazon SQS або тема Amazon SNS
Політики довіри ролі IAM, яку може прийняти користувач
Якщо ви хочете отримати доступ через CLI до ресурсу, який перевіряє MFA, вам потрібно викликати GetSessionToken. Це надасть вам токен з інформацією про MFA.
Зверніть увагу, що облікові дані AssumeRole не містять цю інформацію.
Як зазначено тут, існує багато різних випадків, коли MFA не може бути використано.
IAM група користувачів - це спосіб прикріплення політик до кількох користувачів одночасно, що може спростити управління дозволами для цих користувачів. Ролі та групи не можуть бути частиною групи.
Ви можете прикріпити політику на основі ідентичності до групи користувачів, щоб всі користувачі в групі користувачів отримали дозволи політики. Ви не можете ідентифікувати групу користувачів як Principal у політиці (такій як політика на основі ресурсів), оскільки групи стосуються дозволів, а не аутентифікації, а принципи є аутентифікованими сутностями IAM.
Ось деякі важливі характеристики груп користувачів:
Група користувачів може містити багато користувачів, а користувач може належати до кількох груп.
Групи користувачів не можуть бути вкладеними; вони можуть містити лише користувачів, а не інші групи користувачів.
Існує жодна група користувачів за замовчуванням, яка автоматично включає всіх користувачів в обліковому записі AWS. Якщо ви хочете мати таку групу користувачів, ви повинні створити її та призначити кожного нового користувача до неї.
Кількість і розмір ресурсів IAM в обліковому записі AWS, таких як кількість груп, і кількість груп, до яких може належати користувач, обмежені. Для отримання додаткової інформації дивіться квоти IAM та AWS STS.
IAM роль дуже схожа на користувача, оскільки це ідентифікація з політиками дозволів, які визначають, що вона може і не може робити в AWS. Однак роль не має жодних облікових даних (пароль або ключі доступу), пов'язаних з нею. Замість того, щоб бути унікально пов'язаною з однією особою, роль призначена для того, щоб її могли приймати будь-хто, хто її потребує (і має достатні дозволи). Користувач IAM може прийняти роль, щоб тимчасово отримати різні дозволи для конкретного завдання. Роль може бути призначена федеративному користувачу, який входить, використовуючи зовнішнього постачальника ідентичності замість IAM.
IAM роль складається з двох типів політик: політики довіри, яка не може бути порожньою, що визначає хто може прийняти роль, і політики дозволів, яка не може бути порожньою, що визначає до чого вона може отримати доступ.
AWS Служба безпечних токенів (STS) - це веб-сервіс, який полегшує видачу тимчасових, обмежених привілеїв облікових даних. Він спеціально розроблений для:
Тимчасові облікові дані в основному використовуються з IAM ролями, але є й інші використання. Ви можете запитати тимчасові облікові дані, які мають більш обмежений набір дозволів, ніж ваш стандартний користувач IAM. Це запобігає вам випадковому виконанню завдань, які не дозволені більш обмеженими обліковими даними. Перевагою тимчасових облікових даних є те, що вони автоматично закінчуються після встановленого періоду часу. Ви контролюєте тривалість, протягом якої облікові дані є дійсними.
Використовуються для призначення дозволів. Є 2 типи:
Політики, керовані AWS (попередньо налаштовані AWS)
Політики, керовані клієнтом: Налаштовані вами. Ви можете створювати політики на основі політик, керованих AWS (модифікуючи одну з них і створюючи свою), використовуючи генератор політик (GUI, що допомагає вам надавати та відмовляти в дозволах) або написавши свої власні.
За замовчуванням доступ є забороненим, доступ буде надано, якщо була вказана явна роль. Якщо існує єдине "Заперечення", воно переважатиме "Дозволити", за винятком запитів, які використовують кореневі облікові дані безпеки облікового запису AWS (які за замовчуванням дозволені).
The глобальні поля, які можна використовувати для умов у будь-якій службі, задокументовані тут. Специфічні поля, які можна використовувати для умов для кожної служби, задокументовані тут.
Цей вид політик безпосередньо призначається користувачу, групі або ролі. Тоді вони не з'являються у списку політик, оскільки інші не можуть їх використовувати. Вбудовані політики корисні, якщо ви хочете підтримувати строгі однозначні відносини між політикою та ідентичністю, до якої вона застосовується. Наприклад, ви хочете бути впевненими, що дозволи в політиці не призначені ненавмисно іншій ідентичності, окрім тієї, для якої вони призначені. Коли ви використовуєте вбудовану політику, дозволи в політиці не можуть бути ненавмисно прикріплені до неправильної ідентичності. Крім того, коли ви використовуєте AWS Management Console для видалення цієї ідентичності, політики, вбудовані в ідентичність, також видаляються. Це тому, що вони є частиною основної сутності.
Це політики, які можуть бути визначені в ресурсах. Не всі ресурси AWS підтримують їх.
Якщо у основної сутності немає явного заборони на них, і політика ресурсу надає їм доступ, тоді їм дозволено.
Межі IAM можна використовувати для обмеження дозволів, до яких користувач або роль повинні мати доступ. Таким чином, навіть якщо інший набір дозволів надається користувачу іншою політикою, операція не вдасться, якщо він спробує їх використати.
Межа - це просто політика, прикріплена до користувача, яка вказує максимальний рівень дозволів, які користувач або роль можуть мати. Отже, навіть якщо у користувача є доступ адміністратора, якщо межа вказує, що він може лише читати S· кошики, це максимальне, що він може зробити.
Це, SCP та дотримання принципу найменших привілеїв - це способи контролю, щоб користувачі не мали більше дозволів, ніж їм потрібно.
Політика сесії - це політика, встановлена, коли роль приймається якимось чином. Це буде як межа IAM для цієї сесії: Це означає, що політика сесії не надає дозволів, але обмежує їх до тих, що вказані в політиці (максимальні дозволи - це ті, які має роль).
Це корисно для заходів безпеки: Коли адміністратор збирається прийняти дуже привілейовану роль, він може обмежити дозволи лише тими, що вказані в політиці сесії, у разі, якщо сесія буде скомпрометована.
Note that by default AWS might add session policies to sessions that are going to be generated because of third reasons. For example, in unauthenticated cognito assumed roles by default (using enhanced authentication), AWS will generate session credentials with a session policy that limits the services that session can access to the following list.
Therefore, if at some point you face the error "... because no session policy allows the ...", and the role has access to perform the action, it's because there is a session policy preventing it.
Identity federation дозволяє користувачам з постачальників ідентичності, які є зовнішніми для AWS, безпечно отримувати доступ до ресурсів AWS без необхідності надавати облікові дані користувача AWS з дійсного облікового запису IAM. Прикладом постачальника ідентичності може бути ваш власний корпоративний Microsoft Active Directory (через SAML) або OpenID сервіси (як Google). Федеративний доступ дозволить користувачам всередині нього отримувати доступ до AWS.
To configure this trust, an IAM Identity Provider is generated (SAML or OAuth) that will trust the other platform. Then, at least one IAM role is assigned (trusting) to the Identity Provider. If a user from the trusted platform access AWS, he will be accessing as the mentioned role.
However, you will usually want to give a different role depending on the group of the user in the third party platform. Then, several IAM roles can trust the third party Identity Provider and the third party platform will be the one allowing users to assume one role or the other.
AWS IAM Identity Center (successor to AWS Single Sign-On) expands the capabilities of AWS Identity and Access Management (IAM) to provide a централізоване місце, яке об'єднує адміністрування користувачів та їх доступ до облікових записів AWS та хмарних додатків.
The login domain is going to be something like <user_input>.awsapps.com.
To login users, there are 3 identity sources that can be used:
Identity Center Directory: Regular AWS users
Active Directory: Supports different connectors
External Identity Provider: All users and groups come from an external Identity Provider (IdP)
In the simplest case of Identity Center directory, the Identity Center will have a list of users & groups and will be able to assign policies to them to any of the accounts of the organization.
In order to give access to a Identity Center user/group to an account a SAML Identity Provider trusting the Identity Center will be created, and a role trusting the Identity Provider with the indicated policies will be created in the destination account.
It's possible to give permissions via inline policies to roles created via IAM Identity Center. The roles created in the accounts being given inline policies in AWS Identity Center will have these permissions in an inline policy called AwsSSOInlinePolicy.
Therefore, even if you see 2 roles with an inline policy called AwsSSOInlinePolicy, it doesn't mean it has the same permissions.
Користувач (достовірний) може створити роль між обліковими записами з деякими політиками, а потім дозволити іншому користувачу (достовірному) отримати доступ до свого облікового запису, але лише маючи доступ, вказаний у нових політиках ролі. To create this, just create a new Role and select Cross Account Role. Roles for Cross-Account Access offers two options. Providing access between AWS accounts that you own, and providing access between an account that you own and a third party AWS account. It's recommended to вказати користувача, який є достовірним, а не ставити щось загальне, тому що в іншому випадку інші автентифіковані користувачі, такі як федеративні користувачі, також зможуть зловживати цією довірою.
Not supported:
Trust Relations
AD Admin Center
Full PS API support
AD Recycle Bin
Group Managed Service Accounts
Schema Extensions
No Direct access to OS or Instances
The app uses the AssumeRoleWithWebIdentity to create temporary credentials. However, this doesn't grant access to the AWS console, just access to resources within AWS.
You can set a password policy setting options like minimum length and password requirements.
You can download "Credential Report" with information about current credentials (like user creation time, is password enabled...). You can generate a credential report as often as once every four hours.
AWS Identity and Access Management (IAM) provides fine-grained access control across all of AWS. With IAM, you can specify who can access which services and resources, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to ensure least-privilege permissions.
In this page you can find the IAM ID prefixed of keys depending on their nature:
The following privileges grant various read access of metadata:
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
In order for a regular user authenticate to AWS via CLI you need to have local credentials. By default you can configure them manually in ~/.aws/credentials or by running aws configure.
In that file you can have more than one profile, if no profile is specified using the aws cli, the one called [default] in that file will be used.
Example of credentials file with more than 1 profile:
Якщо вам потрібно отримати доступ до різних облікових записів AWS і вашому профілю було надано доступ до прийняття ролі в цих облікових записах, вам не потрібно вручну викликати STS щоразу (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) і налаштовувати облікові дані.
Ви можете використовувати файл ~/.aws/config, щоб вказати, які ролі приймати, а потім використовувати параметр --profile як зазвичай (прийняття ролі буде виконано прозоро для користувача).
Приклад конфігураційного файлу:
З цим файлом конфігурації ви можете використовувати aws cli, як:
Якщо ви шукаєте щось схоже на це, але для браузера, ви можете перевірити розширення AWS Extend Switch Roles.
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
ABIA
ACCA
Context-specific credential
AGPA
User group
AIDA
IAM user
AIPA
Amazon EC2 instance profile
AKIA
Access key
ANPA
Managed policy
ANVA
Version in a managed policy
APKA
Public key
AROA
Role
ASCA
Certificate
ASIA
Temporary (AWS STS) access key IDs use this prefix, but are unique only in combination with the secret access key and the session token.
