gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-12 15:50:19 -08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Translator
2025-11-15 16:36:33 +00:00
parent b482d5ad2a
commit 7d7ec7316f
2 changed files with 185 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

141
src/pentesting-cloud/confidential-computing/luks2-header-malleability-null-cipher-abuse.md Normal file
View File

@@ -0,0 +1,141 @@
# Maleabilidade do Cabeçalho LUKS2 e Abuso de Null-Cipher em Confidential VMs
{{#include ../../banners/hacktricks-training.md}}
## TL;DR
- Muitos Confidential VMs (CVMs) baseados em Linux rodando em AMD SEV-SNP ou Intel TDX usam LUKS2 para armazenamento persistente. O cabeçalho LUKS2 no disco é maleável e não tem proteção de integridade contra atacantes adjacentes ao armazenamento.
- Se a encriptação do segmento de dados no cabeçalho for configurada para um null cipher (e.g., "cipher_null-ecb"), o cryptsetup aceita isso e o guest lê/escreve plaintext de forma transparente enquanto acredita que o disco está encriptado.
- Antes e inclusive o cryptsetup 2.8.0, null ciphers podiam ser usados para keyslots; desde 2.8.1 eles são rejeitados para keyslots com passwords não vazias, mas null ciphers continuam permitidos para volume segments.
- Remote attestation geralmente mede código/config da VM, não cabeçalhos LUKS externos mutáveis; sem validação/medição explícita, um atacante com acesso de escrita ao disco pode forçar I/O em plaintext.
## Contexto: formato on-disk do LUKS2 (o que importa para atacantes)
- Um dispositivo LUKS2 começa com um cabeçalho seguido pelos dados encriptados.
- O cabeçalho contém duas cópias idênticas de uma seção binária e uma seção de metadata em JSON, além de um ou mais keyslots.
- A metadata JSON define:
- keyslots habilitados e seu KDF/cipher de wrapping
- segments que descrevem a área de dados (cipher/mode)
- digests (e.g., hash do volume key para verificar passphrases)
- Valores típicos seguros: keyslot KDF argon2id; keyslot e encriptação do data segment aes-xts-plain64.
Inspecione rapidamente o cipher do segmento diretamente no 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'
```
## Causa raiz
- Os cabeçalhos LUKS2 não são autenticados contra adulteração do armazenamento. Um atacante do host/armazenamento pode reescrever os metadados JSON aceitos pelo cryptsetup.
- A partir do cryptsetup 2.8.0, cabeçalhos que definem a encriptação de um segmento para cipher_null-ecb são aceitos. O null cipher ignora chaves e retorna plaintext.
- Até 2.8.0, null ciphers também podiam ser usados para keyslots (o keyslot abria com qualquer passphrase). Desde 2.8.1, null ciphers são rejeitados para keyslots com senhas não vazias, mas continuam permitidos para segmentos. Alterar apenas o cipher do segmento ainda resulta em I/O em plaintext após 2.8.1.
## Modelo de ameaça: por que attestation não te salvou por padrão
- CVMs visam garantir confidencialidade, integridade e autenticidade em um host não confiável.
- Remote attestation normalmente mede a imagem da VM e a configuração de inicialização, não o header LUKS mutável que vive em armazenamento não confiável.
- Se sua CVM confia em um header on-disk sem validação/attestation robusta, um atacante de armazenamento pode alterá-lo para um null cipher e seu guest montará um volume em plaintext sem erro.
## Exploração (acesso de escrita ao armazenamento exigido)
Pré-condições:
- Acesso de escrita ao dispositivo de bloco encriptado LUKS2 do CVM.
- O guest usa o header LUKS2 em disco sem validação/attestation robusta.
Passos (visão geral):
1) Leia o JSON do header e identifique a definição do segmento de dados. Campo de exemplo: segments["0"].encryption.
2) Defina a encriptação do segmento de dados para um null cipher, p.ex., cipher_null-ecb. Mantenha os parâmetros do keyslot e a estrutura de digest intactos para que a passphrase usual do guest ainda “funcione.”
3) Atualize ambas as cópias do header e os digests associados para que o header seja autoconsistente.
4) No próximo boot, o guest executa o cryptsetup, desbloqueia com sucesso o keyslot existente com sua passphrase e monta o volume. Como o cipher do segmento é um null cipher, todas as leituras/escritas são em plaintext.
Variante (abuso de keyslot pré-2.8.1): se a area.encryption do keyslot for um null cipher, ele abre com qualquer passphrase. Combine com um null cipher no segmento para acesso em plaintext sem saber o segredo do guest.
## Mitigações robustas (evite TOCTOU com detached headers)
Sempre trate os LUKS headers em disco como entrada não confiável. Use detached-header mode para que a validação e a abertura usem os mesmos bytes confiáveis vindos de RAM protegida:
```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
```
Então aplique uma (ou mais) das seguintes:
1) Aplicar MAC ao cabeçalho completo
- Calcular/verificar um MAC sobre todo o cabeçalho antes do uso.
- Abrir o volume apenas quando o MAC for verificado.
- Exemplos no mundo real: Flashbots tdx-init e Fortanix Salmiac adotaram verificação baseada em MAC.
2) Validação estrita de JSON (compatível com versões anteriores)
- Extrair os metadados JSON e validar uma allowlist estrita de parâmetros (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>Exemplo de validador (garantir campos seguros)</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) Medir/atestar o cabeçalho
- Remova salts/digests aleatórios e meça o cabeçalho sanitizado nos PCRs do TPM/TDX/SEV ou no estado da política do KMS.
- Libere as chaves de decriptação apenas quando o cabeçalho medido corresponder a um perfil aprovado e seguro.
Orientação operacional:
- Imponha detached header + MAC ou validação estrita; nunca confie diretamente nos cabeçalhos em disco.
- Consumidores de attestation devem negar versões de framework pré-patch nas allow-lists.
## Notas sobre versões e posição do mantenedor
- Os mantenedores do cryptsetup esclareceram que o LUKS2 não foi projetado para fornecer integridade contra adulteração do armazenamento neste contexto; null ciphers são mantidos por compatibilidade com versões anteriores.
- cryptsetup 2.8.1 (Oct 19, 2025) rejeita null ciphers para keyslots com senhas não vazias, mas ainda permite null ciphers para segmentos.
## Verificações rápidas e triagem
- Inspecione se alguma criptografia de segmento está configurada para um null cipher:
```bash
cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \
| jq -r '.segments | to_entries[] | "segment=" + .key + ", enc=" + .value.encryption'
```
- Verifique os algoritmos de keyslot e de segmento antes de abrir o volume. Se não puder aplicar MAC, exija validação JSON rigorosa e abra usando o detached header da memória protegida.
## Referências
- [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}}

88
src/pentesting-cloud/pentesting-cloud-methodology.md
View File

@@ -1,4 +1,4 @@
# Metodologia de Pentesting Cloud
# Pentesting Cloud Methodology
{{#include ../banners/hacktricks-training.md}}
@@ -6,35 +6,35 @@
## Metodologia Básica
Cada cloud tem as suas peculiaridades, mas em geral há algumas **coisas comuns que um pentester deve verificar** ao testar um ambiente cloud:
Cada cloud tem suas peculiaridades, mas em geral há algumas **coisas comuns que um pentester deve verificar** ao testar um ambiente cloud:
- **Verificações de benchmark**
- Isso ajudará você a **entender o tamanho** do ambiente e os **serviços usados**
- Também permitirá encontrar algumas **misconfigurações rápidas**, já que a maioria desses testes pode ser executada com **ferramentas automatizadas**
- **Enumeração de serviços**
- Provavelmente você não encontrará muitas mais misconfigurações aqui se executou corretamente os testes de benchmark, mas pode encontrar algumas que não foram procuradas no teste de benchmark.
- Isso vai te ajudar a **entender o tamanho** do ambiente e **os serviços utilizados**
- Também permitirá encontrar algumas **misconfigurações rápidas**, já que você pode realizar a maioria desses testes com **ferramentas automatizadas**
- **Services Enumeration**
- Você provavelmente não encontrará muitas mais misconfigurações aqui se realizou corretamente os testes de benchmark, mas pode encontrar algumas que não foram buscadas no teste de benchmark.
- Isso permitirá saber **o que exatamente está sendo usado** no ambiente cloud
- Isso ajudará bastante nas próximas etapas
- **Verificar ativos expostos**
- Isso pode ser feito durante a seção anterior, você precisa **identificar tudo que está potencialmente exposto** à Internet de alguma forma e como pode ser acessado.
- Aqui estou considerando **infraestrutura manualmente exposta** como instâncias com páginas web ou outras portas expostas, e também outros **serviços gerenciados na cloud que podem ser configurados** para ficarem expostos (como DBs ou buckets)
- Depois você deve verificar **se esse recurso pode ser exposto ou não** (informação confidencial? vulnerabilidades? misconfigurações no serviço exposto?)
- **Verificar permissões**
- Aqui você deve **identificar todas as permissões de cada role/user** dentro da cloud e como são usadas
- Contas com **privilégios excessivos** (controlam tudo)? Chaves geradas não usadas?... A maioria dessas verificações já deveria ter sido feita nos testes de benchmark
- Se o cliente estiver usando OpenID ou SAML ou outra **federation**, você pode precisar pedir mais **informações** sobre **como cada role é atribuído** (não é o mesmo se o role admin é atribuído a 1 usuário ou a 100)
- Não basta **identificar** quais usuários têm permissões **admin** "*:*". Existem muitas **outras permissões** que, dependendo dos serviços usados, podem ser muito **sensíveis**.
- Além disso, existem formas de **privesc** potenciais a seguir abusando de permissões. Todas essas coisas devem ser levadas em conta e **o maior número possível de caminhos de privesc** deve ser relatado.
- **Verificar integrações**
- É bem provável que **integrações com outras clouds ou SaaS** estejam sendo usadas dentro do ambiente cloud.
- Para **integrações da cloud que você está auditando** com outra plataforma, você deve notificar **quem tem acesso para (ab)usar essa integração** e deve perguntar **quão sensível** é a ação realizada.\
Por exemplo, quem pode gravar em um bucket AWS de onde o GCP está obtendo dados (pergunte quão sensível é a ação no GCP ao tratar esses dados).
- Para **integrações dentro da cloud que você está auditando** originadas de plataformas externas, você deve perguntar **quem tem acesso externamente para (ab)usar essa integração** e verificar como esses dados estão sendo usados.\
Por exemplo, se um serviço está usando uma imagem Docker hospedada no GCR, você deve perguntar quem tem acesso para modificar essa imagem e quais informações sensíveis e acessos essa imagem terá quando executada dentro de uma cloud AWS.
- Isso vai ajudar bastante nos próximos passos
- **Check exposed assets**
- Isso pode ser feito durante a seção anterior; você precisa **identificar tudo que potencialmente está exposto** à Internet de alguma forma e como isso pode ser acessado.
- Aqui estou considerando **infraestrutura manualmente exposta** como instâncias com páginas web ou outras portas expostas, e também outros **serviços gerenciados pela cloud que podem ser configurados** para ficarem expostos (como DBs ou buckets)
- Depois você deve verificar **se esse recurso pode ser explorado ou não** (informação confidencial? vulnerabilidades? misconfigurações no serviço exposto?)
- **Check permissions**
- Aqui você deve **identificar todas as permissões de cada role/user** dentro da cloud e como elas são utilizadas
- Muitas **contas altamente privilegiadas** (controlam tudo)? Chaves geradas não usadas?... A maioria dessas checagens já deveria ter sido feita nos testes de benchmark
- Se o cliente estiver usando OpenID ou SAML ou outra **federation** você pode precisar pedir mais **informação** sobre **como cada role está sendo atribuída** (não é a mesma coisa que a role admin seja atribuída a 1 usuário ou a 100)
- Não basta apenas descobrir quais usuários têm permissões "admin" "\*:\*". Existem muitas **outras permissões** que dependendo dos serviços usados podem ser muito **sensíveis**.
- Além disso, existem **potenciais privesc** a seguir abusando permissões. Todas essas coisas devem ser levadas em conta e **o maior número possível de caminhos de privesc** deve ser reportado.
- **Check Integrations**
- É altamente provável que **integrações com outras clouds ou SaaS** estejam sendo usadas dentro do ambiente cloud.
- Para **integrações da cloud que você está auditando** com outra plataforma, você deve notificar **quem tem acesso para (ab)usar essa integração** e deve perguntar **quão sensível** é a ação que está sendo realizada.\
Por exemplo, quem pode escrever em um bucket AWS de onde a GCP está obtendo dados (pergunte quão sensível é a ação na GCP ao tratar esses dados).
- Para **integrações dentro da cloud que você está auditando** vindas de plataformas externas, você deve perguntar **quem tem acesso externo para (ab)usar essa integração** e verificar como esses dados estão sendo usados.\
Por exemplo, se um serviço está usando uma imagem Docker hospedada no GCR, você deve perguntar quem tem acesso para modificar isso e quais informações sensíveis e acessos essa imagem terá quando executada dentro de uma cloud AWS.
## Ferramentas Multi-Cloud
## Multi-Cloud tools
Existem várias ferramentas que podem ser usadas para testar diferentes ambientes cloud. As etapas de instalação e os links serão indicados nesta seção.
Existem várias ferramentas que podem ser usadas para testar diferentes ambientes cloud. Os passos de instalação e links serão indicados nesta seção.
### [PurplePanda](https://github.com/carlospolop/purplepanda)
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env
### [Prowler](https://github.com/prowler-cloud/prowler)
Suporta **AWS, GCP & Azure**. Consulte como configurar cada provedor em [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
Suporta **AWS, GCP & Azure**. Veja como configurar cada provedor em [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
```bash
# Install
pip install prowler
@@ -146,7 +146,7 @@ done
{{#tabs }}
{{#tab name="Install" }}
Faça o download e instale o Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Ou use Brew:
Baixe e instale o Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Ou use Brew:
```
brew tap turbot/tap
brew install steampipe
@@ -170,7 +170,7 @@ steampipe check all
<summary>Verificar todos os projetos</summary>
Para verificar todos os projetos, você precisa gerar o arquivo `gcp.spc` indicando todos os projetos a serem testados. Você pode seguir as instruções do script a seguir
Para verificar todos os projetos você precisa gerar o arquivo `gcp.spc` indicando todos os projetos a serem testados. Você pode seguir as indicações do script a seguir
```bash
FILEPATH="/tmp/gcp.spc"
rm -rf "$FILEPATH" 2>/dev/null
@@ -234,15 +234,15 @@ Mais plugins AWS do Steampipe: [https://github.com/orgs/turbot/repositories?q=aw
### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
AWS, GCP, Azure, DigitalOcean.\
Requer python2.7 e parece não mantido.
Requer python2.7 e parece não estar mantido.
### Nessus
Nessus possui uma varredura _**Audit Cloud Infrastructure**_ que suporta: AWS, Azure, Office 365, Rackspace, Salesforce. Algumas configurações adicionais em **Azure** são necessárias para obter um **Client Id**.
Nessus possui um scan _**Audit Cloud Infrastructure**_ que suporta: AWS, Azure, Office 365, Rackspace, Salesforce. Algumas configurações extras no **Azure** são necessárias para obter um **Client Id**.
### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
Cloudlist é uma **ferramenta multi-cloud para obter Assets** (Hostnames, IP Addresses) de Cloud Providers.
Cloudlist é uma **ferramenta multi-cloud para obter Assets** (Hostnames, IP Addresses) de provedores de nuvem.
{{#tabs }}
{{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
### [**cartography**](https://github.com/lyft/cartography)
Cartography é uma ferramenta Python que consolida ativos de infraestrutura e os relacionamentos entre eles em uma visualização de grafo intuitiva alimentada por um banco de dados Neo4j.
Cartography é uma ferramenta Python que consolida os ativos de infraestrutura e as relações entre eles em uma visualização gráfica intuitiva alimentada por um banco de dados Neo4j.
{{#tabs }}
{{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography \
### [**starbase**](https://github.com/JupiterOne/starbase)
Starbase coleta ativos e relacionamentos de serviços e sistemas, incluindo infraestrutura cloud, aplicações SaaS, controles de segurança e mais, em uma visão de grafo intuitiva suportada pelo banco de dados Neo4j.
Starbase coleta ativos e relações de serviços e sistemas, incluindo infraestrutura em nuvem, aplicações SaaS, controles de segurança e mais, em uma visualização de grafo intuitiva suportada pelo banco de dados Neo4j.
{{#tabs }}
{{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
### [**SkyArk**](https://github.com/cyberark/SkyArk)
Identifica os usuários mais privilegiados no ambiente AWS ou Azure escaneado, incluindo os AWS Shadow Admins. Usa powershell.
Descobre os utilizadores mais privilegiados no ambiente AWS ou Azure escaneado, incluindo os AWS Shadow Admins. Usa powershell.
```bash
Import-Module .\SkyArk.ps1 -force
Start-AzureStealth
@@ -372,15 +372,15 @@ Scan-AzureAdmins
```
### [Cloud Brute](https://github.com/0xsha/CloudBrute)
Uma ferramenta para encontrar a infraestrutura de uma empresa (alvo), arquivos e apps nos principais provedores de cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
Uma ferramenta para localizar a infraestrutura, arquivos e apps de uma empresa (target) nos principais provedores de cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
### [CloudFox](https://github.com/BishopFox/cloudfox)
- CloudFox é uma ferramenta para encontrar caminhos de ataque exploráveis na infraestrutura cloud (atualmente suporta apenas AWS & Azure, com GCP em breve).
- É uma ferramenta de enumeração destinada a complementar o pentesting manual.
- Não cria nem modifica quaisquer dados dentro do ambiente cloud.
- CloudFox é uma ferramenta para encontrar caminhos de ataque exploráveis na infraestrutura de cloud (atualmente apenas AWS & Azure suportados, com GCP em breve).
- É uma ferramenta de enumeration que tem como objetivo complementar pentesting manual.
- Não cria nem modifica quaisquer dados dentro do ambiente de cloud.
### Mais listas de ferramentas de segurança cloud
### More lists of cloud security tools
- [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
@@ -410,12 +410,12 @@ aws-security/
azure-security/
{{#endref}}
### Attack Graph
## Recursos comuns de segurança em cloud
[**Stormspotter** ](https://github.com/Azure/Stormspotter) cria um “attack graph” dos recursos numa subscription do Azure. Permite que red teams e pentesters visualizem a superfície de ataque e oportunidades de pivot dentro de um tenant, e potencializa os seus defenders para rapidamente orientar e priorizar o trabalho de incident response.
### Computação Confidencial
### Office365
É necessário **Global Admin** ou pelo menos **Global Admin Reader** (mas note que Global Admin Reader é um pouco limitado). No entanto, essas limitações aparecem em alguns PS modules e podem ser contornadas acessando as funcionalidades **via the web application**.
{{#ref}}
confidential-computing/luks2-header-malleability-null-cipher-abuse.md
{{#endref}}
{{#include ../banners/hacktricks-training.md}}