diff --git a/src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md b/src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md new file mode 100644 index 000000000..b81c08b25 --- /dev/null +++ b/src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md @@ -0,0 +1,141 @@ +# LUKS2 Header Malleability and Null-Cipher Abuse in Confidential VMs + +{{#include ../../banners/hacktricks-training.md}} + +## TL;DR + +- Багато Linux-based Confidential VMs (CVMs) на AMD SEV-SNP або Intel TDX використовують LUKS2 для постійного зберігання. LUKS2 header на диску є змінним і не має захисту цілісності проти атакуючих з доступом до сусіднього сховища. +- Якщо шифрування сегмента даних у header встановлене як null cipher (наприклад, "cipher_null-ecb"), cryptsetup приймає його і гість прозоро читає/записує plaintext, вважаючи диск зашифрованим. +- До та включно з cryptsetup 2.8.0 null ciphers могли використовуватися для keyslots; починаючи з 2.8.1 вони відхиляються для keyslots з непорожніми паролями, але null ciphers залишаються дозволеними для volume segments. +- Remote attestation зазвичай вимірює код/конфігурацію VM, а не змінні зовнішні LUKS headers; без явної валідації/вимірювання атакуючий з правом запису на диск може примусити plaintext I/O. + +## Background: LUKS2 on-disk format (what matters for attackers) + +- Пристрій LUKS2 починається з header, за яким ідуть зашифровані дані. +- Header містить дві ідентичні копії бінарної секції і секцію JSON metadata, плюс один або декілька keyslots. +- JSON metadata визначає: + - які keyslots увімкнені та їх wrapping KDF/cipher + - segments, які описують область даних (cipher/mode) + - digests (наприклад, хеш volume key для перевірки passphrases) +- Типові безпечні значення: keyslot KDF argon2id; шифрування keyslot і data segment — aes-xts-plain64. + +Quickly inspect the segment cipher directly from JSON: +```bash +# Read JSON metadata and print the configured data segment cipher +cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \ +| jq -r '.segments["0"].encryption' +``` +## Корінна причина + +- LUKS2 headers are not authenticated against storage tampering. Атакуючий на рівні хоста/сховища може переписати JSON-метадані, які приймає cryptsetup. +- Починаючи з cryptsetup 2.8.0, заголовки, що встановлюють шифрування сегмента як cipher_null-ecb, приймаються. null cipher ігнорує ключі і повертає plaintext. +- До 2.8.0 null ciphers також могли використовуватися для keyslots (keyslot відкривається з будь-якою passphrase). Починаючи з 2.8.1, null ciphers відхиляються для keyslots з непорожніми паролями, але залишаються дозволеними для сегментів. Заміна лише segment cipher все ще дає plaintext I/O після 2.8.1. + +## Модель загрози: чому атестація не врятувала вас за замовчуванням + +- CVMs прагнуть забезпечити конфіденційність, цілісність і автентичність на ненадійному хості. +- Віддалена атестація зазвичай вимірює образ VM і конфігурацію запуску, а не змінний LUKS header, що знаходиться на ненадійному сховищі. +- Якщо ваш CVM довіряє on-disk header без надійної валідації/вимірювання, атакуючий на сховище може змінити його на null cipher, і ваша гостьова система змонтує plaintext том без помилок. + +## Експлуатація (потрібен доступ на запис до сховища) + +Передумови: +- Доступ на запис до LUKS2-зашифрованого блочного пристрою CVM. +- Гість використовує on-disk LUKS2 header без надійної валідації/атестації. + +Кроки (на високому рівні): +1) Зчитайте header JSON і визначте визначення data segment. Приклад цільового поля: segments["0"].encryption. +2) Встановіть шифрування data segment на null cipher, наприклад cipher_null-ecb. Залиште параметри keyslot і структуру digest незмінними, щоб звичайна passphrase гостя все ще “працювала.” +3) Оновіть обидві копії header та пов'язані header digests так, щоб заголовок був узгодженим. +4) При наступному завантаженні гість запускає cryptsetup, успішно розблоковує існуючий keyslot своєю passphrase і монтує том. Оскільки segment cipher — null cipher, усі операції читання/запису будуть plaintext. + +Варіант (pre-2.8.1 keyslot abuse): якщо area.encryption keyslot встановлено як null cipher, він відкривається з будь-якою passphrase. Поєднайте це з null segment cipher для безперервного доступу до plaintext без знання секрету гостя. + +## Надійні пом'якшення (уникайте TOCTOU за допомогою detached headers) + +Завжди розглядайте on-disk LUKS headers як недовірений вхід. Використовуйте detached-header mode, щоб валідація та відкриття використовували ті самі довірені байти з protected RAM: +```bash +# Copy header into protected memory (e.g., tmpfs) and open from there +cryptsetup luksHeaderBackup --header-backup-file /tmp/luks_header /dev/VDISK +cryptsetup open --type luks2 --header /tmp/luks_header /dev/VDISK --key-file=key.txt +``` +Потім застосуйте одне (або декілька) з наступного: + +1) Накласти MAC на весь заголовок +- Обчислювати/перевіряти MAC над усім заголовком перед використанням. +- Відкривати том лише коли MAC підтверджено. +- Приклади на практиці: Flashbots tdx-init та Fortanix Salmiac впровадили перевірку на основі MAC. + +2) Строга валідація JSON (зворотно сумісна) +- Зробити дамп JSON-метаданих і перевірити сувору allowlist параметрів (KDF, ciphers, segment count/type, flags). +```bash +#!/bin/bash +set -e +# Store header in confidential RAM fs +cryptsetup luksHeaderBackup --header-backup-file /tmp/luks_header $BLOCK_DEVICE +# Dump JSON metadata header to a file +cryptsetup luksDump --type luks2 --dump-json-metadata /tmp/luks_header > header.json +# Validate the header +python validate.py header.json +# Open the cryptfs using key.txt +cryptsetup open --type luks2 --header /tmp/luks_header $BLOCK_DEVICE --key-file=key.txt +``` +
+Приклад валідатора (обмеження безпечних полів) +```python +from json import load +import sys +with open(sys.argv[1], "r") as f: +header = load(f) +if len(header["keyslots"]) != 1: +raise ValueError("Expected 1 keyslot") +if header["keyslots"]["0"]["type"] != "luks2": +raise ValueError("Expected luks2 keyslot") +if header["keyslots"]["0"]["area"]["encryption"] != "aes-xts-plain64": +raise ValueError("Expected aes-xts-plain64 encryption") +if header["keyslots"]["0"]["kdf"]["type"] != "argon2id": +raise ValueError("Expected argon2id kdf") +if len(header["tokens"]) != 0: +raise ValueError("Expected 0 tokens") +if len(header["segments"]) != 1: +raise ValueError("Expected 1 segment") +if header["segments"]["0"]["type"] != "crypt": +raise ValueError("Expected crypt segment") +if header["segments"]["0"]["encryption"] != "aes-xts-plain64": +raise ValueError("Expected aes-xts-plain64 encryption") +if "flags" in header["segments"]["0"] and header["segments"]["0"]["flags"]: +raise ValueError("Segment contains unexpected flags") +``` +
+ +3) Виміряйте/атестуйте заголовок +- Видаліть випадкові salts/digests і виміряйте очищений заголовок у PCRs TPM/TDX/SEV або у стан політики KMS. +- Видавайте ключі розшифрування лише коли виміряний заголовок відповідає затвердженому, безпечному профілю. + +Оперативні рекомендації: +- Примусово використовуйте detached header + MAC або сувору валідацію; ніколи не довіряйте заголовкам на диску безпосередньо. +- Споживачі атестації повинні відхиляти версії фреймворку до застосування патчів у allow-list'ах. + +## Примітки щодо версій та позиції мейнтейнера + +- Розробники cryptsetup уточнили, що LUKS2 не призначався для забезпечення цілісності проти підміни даних на носії в цьому сценарії; null ciphers збережено для зворотної сумісності. +- cryptsetup 2.8.1 (Oct 19, 2025) відкидає null ciphers для keyslots з непустими паролями, але все ще дозволяє null ciphers для сегментів. + +## Швидкі перевірки та тріаж + +- Перевірте, чи для шифрування будь-якого сегмента встановлено null cipher: +```bash +cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \ +| jq -r '.segments | to_entries[] | "segment=" + .key + ", enc=" + .value.encryption' +``` +- Перевірте keyslot та segment algorithms перед відкриттям volume. Якщо ви не можете виконати MAC, застосуйте сувору валідацію JSON і відкривайте, використовуючи detached header із protected memory. + +## Посилання + +- [Vulnerabilities in LUKS2 disk encryption for confidential VMs (Trail of Bits)](https://blog.trailofbits.com/2025/10/30/vulnerabilities-in-luks2-disk-encryption-for-confidential-vms/) +- [cryptsetup issue #954 (null cipher acceptance and integrity considerations)](https://gitlab.com/cryptsetup/cryptsetup/-/issues/954) +- [CVE-2025-59054](https://nvd.nist.gov/vuln/detail/CVE-2025-59054) +- [CVE-2025-58356](https://nvd.nist.gov/vuln/detail/CVE-2025-58356) +- [Related context: CVE-2021-4122 (auto-recovery path silently decrypting disks)](https://www.cve.org/CVERecord?id=CVE-2021-4122) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index 51a8b0146..878bc283d 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -1,4 +1,4 @@ -# Pentesting Cloud Методологія +# Методологія Pentesting Cloud {{#include ../banners/hacktricks-training.md}} @@ -6,39 +6,39 @@ ## Базова методологія -Кожна cloud має свої особливості, але загалом є кілька **спільних речей, які повинен перевірити pentester** під час тестування cloud-середовища: +Кожна хмара має свої особливості, але загалом є кілька **спільних речей, які pentester має перевірити** під час тестування хмарного середовища: - **Перевірки бенчмарку** - Це допоможе вам **зрозуміти розмір** середовища та **використовувані сервіси** -- Це також дозволить знайти деякі **швидкі misconfigurations**, оскільки більшість цих тестів можна виконати за допомогою **automated tools** -- **Services Enumeration** -- Якщо ви правильно провели перевірки бенчмарку, ймовірно, тут ви не знайдете значно більше misconfigurations, але можете знайти ті, які не шукали під час бенчмарку. -- Це дозволить вам зрозуміти **що саме використовується** в cloud-середовищі -- Це дуже допоможе в наступних кроках -- **Check exposed assets** -- Це можна зробити під час попереднього розділу, вам потрібно **знайти все, що потенційно якось доступне з Інтернету**, і як до цього можна отримати доступ. -- Тут я маю на увазі **мануально експоновану інфраструктуру** — наприклад інстанси з веб-сторінками або іншими відкритими портами, а також інші **cloud managed services, які можуть бути налаштовані** як експоновані (наприклад DBs або buckets) -- Потім потрібно перевірити **чи може цей ресурс бути експонований чи ні** (конфіденційна інформація? вразливості? misconfigurations в експонованому сервісі?) -- **Check permissions** -- Тут потрібно **виявити всі права кожної ролі/користувача** в хмарі та як вони використовуються -- Занадто багато **високопривілейованих** (контролюють все) облікових записів? Згенеровані ключі не використовуються?… Більшість цих перевірок вже повинні були бути виконані під час бенчмарку -- Якщо клієнт використовує OpenID або SAML або іншу **федерацію**, вам можливо доведеться попросити у них додаткову **інформацію** про **те, як призначається кожна роль** (не одне й те саме, коли роль admin призначена 1 користувачу або 100) -- Недостатньо просто знайти, які користувачі мають права **admin** "\*:\*". Є багато **інших прав**, які в залежності від використаних сервісів можуть бути дуже **чутливими**. -- Більше того, існують **потенційні privesc** шляхи для аб’юзу прав. Усі ці речі слід враховувати і слід повідомити **якомога більше privesc paths**. -- **Check Integrations** -- Дуже ймовірно, що всередині cloud-середовища використовуються **integrations з іншими clouds або SaaS**. -- Для **інтеграцій cloud, який ви аудитуєте**, з іншими платформами слід вказати **хто має доступ для (зловживання) цією інтеграцією** і запитати **наскільки чутливою** є дія, що виконується.\ -Наприклад, хто може записувати в AWS bucket, звідки GCP отримує дані (запитайте, наскільки чутлива дія в GCP при обробці цих даних). -- Для **інтеграцій всередині cloud, який ви аудитуєте**, з зовнішніх платформ слід запитати **хто має зовнішній доступ для (зловживання) цією інтеграцією** і перевірити, як ці дані використовуються.\ -Наприклад, якщо сервіс використовує Docker image, розміщений в GCR, потрібно дізнатися, хто має доступ модифікувати його і які чутливі дані та доступи отримає цей образ при виконанні всередині AWS cloud. +- Це також дозволить знайти деякі **швидкі неправильні конфігурації**, оскільки більшість цих тестів можна виконати за допомогою **автоматизованих інструментів** +- **Перерахування сервісів** +- Ймовірно ви не знайдете набагато більше неправильних конфігурацій тут, якщо правильно виконали бенчмарк-перевірки, але може трапитись щось, що не шукали під час бенчмарку. +- Це дозволить вам знати **що саме використовується** в хмарному середовищі +- Це дуже допоможе на наступних кроках +- **Перевірка експонованих ресурсів** +- Це можна робити під час попереднього розділу, потрібно **з’ясувати все, що потенційно експоновано** в Internet якимось чином і як до цього можна отримати доступ. +- Тут я маю на увазі **мануально експоновану інфраструктуру** — наприклад інстанси з веб-сторінками або іншими відкритими портами, а також інші **керовані хмарні сервіси, які можуть бути налаштовані** як експоновані (наприклад DBs або buckets) +- Потім слід перевірити **чи можна отримати доступ до цього ресурсу** (конфіденційна інформація? вразливості? неправильні конфігурації в експонованому сервісі?) +- **Перевірка дозволів** +- Тут ви повинні **виявити всі дозволи кожної ролі/кожного користувача** всередині хмари і як вони використовуються +- Забагато **високо привілейованих** (control everything) акаунтів? Згенеровані ключі, якими не користуються? ... Більшість цих перевірок вже має бути виконана під час бенчмарку +- Якщо клієнт використовує OpenID або SAML або іншу federation, можливо вам потрібно попросити додаткову **інформацію** про **те, як призначається кожна роль** (не те саме, коли роль admin призначена 1 користувачу або 100) +- Недостатньо лише знайти, які користувачі мають права **admin** "\*:\*". Є багато інших **дозволів**, які залежно від використовуваних сервісів можуть бути дуже **чутливими**. +- Більше того, існують **потенційні privesc** шляхи, які можна використати зловживаючи дозволами. Усі ці речі потрібно врахувати і **по можливості задокументувати якомога більше privesc шляхів**. +- **Перевірка інтеграцій** +- Дуже ймовірно, що **інтеграції з іншими хмарами або SaaS** використовуються в межах хмарного середовища. +- Для **інтеграцій хмари, яку ви аудитуєте,** з іншими платформами слід повідомити **хто має доступ (щоб (злов)використати цю інтеграцію)** і запитати, **наскільки чутлива** дія, що виконується.\ +Наприклад, хто може записувати в AWS bucket, звідки GCP отримує дані (запитайте, наскільки чутлива ця дія в GCP при обробці тих даних). +- Для **інтеграцій всередині хмари, яку ви аудитуєте,** з зовнішніх платформ, слід запитати **хто зовні має доступ (щоб (злов)використати цю інтеграцію)** і перевірити, як ці дані використовуються.\ +Наприклад, якщо сервіс використовує Docker image, розміщений в GCR, запитайте, хто має доступ змінювати його та яку чутливу інформацію і доступ отримає цей образ при виконанні всередині AWS cloud. ## Інструменти Multi-Cloud -Є кілька інструментів, які можна використовувати для тестування різних cloud-середовищ. Кроки встановлення та посилання будуть вказані в цьому розділі. +Існує кілька інструментів, які можна використовувати для тестування різних хмарних середовищ. Кроки інсталяції та посилання будуть вказані в цьому розділі. ### [PurplePanda](https://github.com/carlospolop/purplepanda) -Інструмент для **виявлення неправильних конфігурацій та privesc path у clouds та між clouds/SaaS.** +Інструмент для **виявлення неправильних конфігурацій та privesc path у хмарах та між хмарами/SaaS.** {{#tabs }} {{#tab name="Install" }} @@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env ### [Prowler](https://github.com/prowler-cloud/prowler) -Підтримує **AWS, GCP & Azure**. Перегляньте, як налаштувати кожного провайдера в [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) +Підтримує **AWS, GCP & Azure**. Перегляньте, як налаштувати кожного провайдера на [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) ```bash # Install pip install prowler @@ -170,7 +170,7 @@ steampipe check all Перевірити всі проєкти -Щоб перевірити всі проєкти, потрібно згенерувати файл `gcp.spc`, який вказує всі проєкти для тестування. Ви можете просто слідувати вказівкам зі скрипта нижче +Щоб перевірити всі проєкти, потрібно згенерувати файл `gcp.spc`, що вказує всі проєкти для тестування. Ви можете просто слідувати вказівкам у наведеному нижче скрипті ```bash FILEPATH="/tmp/gcp.spc" rm -rf "$FILEPATH" 2>/dev/null @@ -194,9 +194,9 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate ``` -Щоб перевірити **інші GCP інсайти** (корисно для перерахування сервісів) використовуйте: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) +Щоб переглянути **інші GCP insights** (корисні для перерахування сервісів), використовуйте: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) -Щоб перевірити Terraform GCP код: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) +Щоб переглянути код Terraform для GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) Більше GCP плагінів для Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) {{#endtab }} @@ -225,16 +225,16 @@ cd steampipe-mod-aws-compliance steampipe dashboard # To see results in browser steampipe check all --export=/tmp/output4.json ``` -To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) +Щоб перевірити код Terraform для AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) -More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws) +Більше AWS плагінів для Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws) {{#endtab }} {{#endtabs }} ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite) AWS, GCP, Azure, DigitalOcean.\ -Потребує python2.7 і не підтримується. +Вимагає python2.7 і виглядає непідтримуваним. ### Nessus @@ -242,7 +242,7 @@ Nessus має скан _**Audit Cloud Infrastructure**_, який підтрим ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist) -Cloudlist — це **multi-cloud інструмент для отримання Assets** (Hostnames, IP Addresses) з хмарних провайдерів. +Cloudlist — це **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) з Cloud Providers. {{#tabs }} {{#tab name="Cloudlist" }} @@ -265,7 +265,7 @@ cloudlist -config ### [**cartography**](https://github.com/lyft/cartography) -Cartography — це інструмент на Python, який консолідує інфраструктурні активи та зв'язки між ними в інтуїтивному графовому поданні на базі Neo4j. +Cartography — інструмент на Python, який консолідує інфраструктурні активи та зв'язки між ними в інтуїтивному графовому поданні, що працює на базі Neo4j. {{#tabs }} {{#tab name="Install" }} @@ -302,7 +302,7 @@ ghcr.io/lyft/cartography \ ### [**starbase**](https://github.com/JupiterOne/starbase) -Starbase збирає активи та зв'язки з сервісів і систем, включно з cloud infrastructure, SaaS applications, security controls та ін., у зручне графове подання на базі Neo4j. +Starbase збирає активи та взаємозв'язки з сервісів і систем, включно з cloud infrastructure, SaaS applications, security controls та іншими, у зручне графове подання на базі Neo4j database. {{#tabs }} {{#tab name="Install" }} @@ -361,7 +361,7 @@ uri: bolt://localhost:7687 ### [**SkyArk**](https://github.com/cyberark/SkyArk) -Виявляє найбільш привілейованих користувачів у просканованому середовищі AWS або Azure, включаючи AWS Shadow Admins. Використовує powershell. +Виявляє користувачів із найвищими привілеями у просканованому середовищі AWS або Azure, включно з AWS Shadow Admins. Використовує powershell. ```bash Import-Module .\SkyArk.ps1 -force Start-AzureStealth @@ -372,15 +372,15 @@ Scan-AzureAdmins ``` ### [Cloud Brute](https://github.com/0xsha/CloudBrute) -Інструмент для пошуку інфраструктури компанії (target), файлів та додатків у провідних хмарних провайдерів (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). +Інструмент для пошуку інфраструктури компанії (цілі), файлів та додатків у провідних хмарних провайдерів (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). ### [CloudFox](https://github.com/BishopFox/cloudfox) -- CloudFox — інструмент для пошуку exploitable attack paths у хмарній інфраструктурі (поки що підтримуються тільки AWS & Azure, GCP незабаром). -- Це enumeration tool, призначений доповнювати manual pentesting. -- Він не створює і не змінює жодні дані в cloud environment. +- CloudFox — інструмент для пошуку шляхів атаки, які можна експлуатувати в хмарній інфраструктурі (наразі підтримуються тільки AWS і Azure; GCP буде додано). +- Це інструмент енумерації, призначений для доповнення ручного pentesting. +- Він не створює й не змінює жодних даних у хмарному середовищі. -### More lists of cloud security tools +### Додаткові списки інструментів для безпеки хмар - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec) @@ -410,13 +410,12 @@ aws-security/ azure-security/ {{#endref}} -### Attack Graph +## Загальні функції безпеки хмар -[**Stormspotter** ](https://github.com/Azure/Stormspotter) створює “attack graph” ресурсів в Azure subscription. Воно дозволяє red teams і pentesters візуалізувати attack surface і pivot opportunities в межах tenant, а також посилює ваших defenders, дозволяючи їм швидко зорієнтуватися та пріоритезувати incident response роботу. - -### Office365 - -Для цього потрібен **Global Admin** або принаймні **Global Admin Reader** (зверніть увагу, що Global Admin Reader дещо обмежений). Однак ці обмеження з'являються в деяких PS modules і їх можна обійти, отримуючи доступ до функцій **via the web application**. +### Конфіденційні обчислення +{{#ref}} +confidential-computing/luks2-header-malleability-null-cipher-abuse.md +{{#endref}} {{#include ../banners/hacktricks-training.md}}