Translated ['src/pentesting-cloud/pentesting-cloud-methodology.md', 'src

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
+```
+<details>
+<summary>Приклад валідатора (обмеження безпечних полів)</summary>
+```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")
+```
+</details>
+
+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}}

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
 
 <summary>Перевірити всі проєкти</summary>
 
-Щоб перевірити всі проєкти, потрібно згенерувати файл `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
 ```
 </details>
 
-Щоб перевірити **інші 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 </path/to/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}}