AWS - Nitro Enum

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Podstawowe informacje

AWS Nitro to zestaw innowacyjnych technologii, które stanowią podstawową platformę dla instancji AWS EC2. Wprowadzony przez Amazon w celu zwiększenia bezpieczeństwa, wydajności i niezawodności, Nitro wykorzystuje niestandardowe komponenty sprzętowe i lekki hipernadzorcę. Abstrakcyjnie przenosi wiele tradycyjnych funkcji wirtualizacji na dedykowany sprzęt i oprogramowanie, minimalizując powierzchnię ataku i poprawiając efektywność zasobów. Przez odciążenie funkcji wirtualizacji, Nitro pozwala instancjom EC2 na dostarczanie wydajności bliskiej wydajności sprzętowej, co jest szczególnie korzystne dla aplikacji wymagających dużych zasobów. Dodatkowo, Nitro Security Chip zapewnia bezpieczeństwo sprzętu i oprogramowania układowego, co dodatkowo wzmacnia jego solidną architekturę.

Nitro Enclaves

AWS Nitro Enclaves zapewniają bezpieczne, izolowane środowisko obliczeniowe w instancjach Amazon EC2, zaprojektowane specjalnie do przetwarzania wysoce wrażliwych danych. Wykorzystując system AWS Nitro, te enklawy zapewniają solidną izolację i bezpieczeństwo, idealne do obsługi poufnych informacji, takich jak PII czy dane finansowe. Oferują minimalistyczne środowisko, znacznie redukując ryzyko ujawnienia danych. Dodatkowo, Nitro Enclaves wspierają kryptograficzną attestację, umożliwiając użytkownikom weryfikację, że tylko autoryzowany kod jest uruchamiany, co jest kluczowe dla utrzymania ścisłej zgodności i standardów ochrony danych.

[!OSTRZEŻENIE] Obrazy Nitro Enclave są uruchamiane z wnętrza instancji EC2 i nie możesz zobaczyć w konsoli internetowej AWS, czy instancja EC2 uruchamia obrazy w Nitro Enclave, czy nie.

Instalacja CLI Nitro Enclave

Postępuj zgodnie ze wszystkimi instrukcjami z dokumentacji. Jednak oto najważniejsze z nich:

# Install tools
sudo amazon-linux-extras install aws-nitro-enclaves-cli -y
sudo yum install aws-nitro-enclaves-cli-devel -y

# Config perms
sudo usermod -aG ne $USER
sudo usermod -aG docker $USER

# Check installation
nitro-cli --version

# Start and enable the Nitro Enclaves allocator service.
sudo systemctl start nitro-enclaves-allocator.service && sudo systemctl enable nitro-enclaves-allocator.service

Nitro Enclave Images

Obrazy, które możesz uruchomić w Nitro Enclave, są oparte na obrazach docker, więc możesz tworzyć swoje obrazy Nitro Enclave z obrazów docker, takich jak:

# You need to have the docker image accesible in your running local registry
# Or indicate the full docker image URL to access the image
nitro-cli build-enclave --docker-uri <docker-img>:<tag> --output-file nitro-img.eif

Jak widać, obrazy Nitro Enclave używają rozszerzenia eif (Enclave Image File).

Wynik będzie wyglądać podobnie do:

Using the locally available Docker image...
Enclave Image successfully created.
{
"Measurements": {
"HashAlgorithm": "Sha384 { ... }",
"PCR0": "e199261541a944a93129a52a8909d29435dd89e31299b59c371158fc9ab3017d9c450b0a580a487e330b4ac691943284",
"PCR1": "bcdf05fefccaa8e55bf2c8d6dee9e79bbff31e34bf28a99aa19e6b29c37ee80b214a414b7607236edf26fcb78654e63f",
"PCR2": "2e1fca1dbb84622ec141557dfa971b4f8ea2127031b264136a20278c43d1bba6c75fea286cd4de9f00450b6a8db0e6d3"
}
}

Uruchom obraz

Zgodnie z dokumentacją, aby uruchomić obraz enklawy, musisz przypisać mu pamięć o wielkości co najmniej 4 razy większej niż rozmiar pliku eif. Możliwe jest skonfigurowanie domyślnych zasobów, które mu przydzielisz w pliku.

/etc/nitro_enclaves/allocator.yaml

Caution

Zawsze pamiętaj, że musisz zarezerwować pewne zasoby dla rodzica EC2!

Po poznaniu zasobów, które należy przydzielić obrazowi i nawet po modyfikacji pliku konfiguracyjnego, możliwe jest uruchomienie obrazu enklawy za pomocą:

# Restart the service so the new default values apply
sudo systemctl start nitro-enclaves-allocator.service && sudo systemctl enable nitro-enclaves-allocator.service

# Indicate the CPUs and memory to give
nitro-cli run-enclave --cpu-count 2 --memory 3072 --eif-path hello.eif --debug-mode --enclave-cid 16

Enumerate Enclaves

Jeśli skompromitujesz hosta EC2, możliwe jest uzyskanie listy działających obrazów enklaw za pomocą:

nitro-cli describe-enclaves

Nie jest możliwe uzyskanie powłoki wewnątrz działającego obrazu enclave, ponieważ to jest główny cel enclave, jednak jeśli użyjesz parametru --debug-mode, możliwe jest uzyskanie stdout z niego za pomocą:

ENCLAVE_ID=$(nitro-cli describe-enclaves | jq -r ".[0].EnclaveID")
nitro-cli console --enclave-id ${ENCLAVE_ID}

Zakończ Enklawy

Jeśli atakujący skompromituje instancję EC2, domyślnie nie będzie w stanie uzyskać powłoki wewnątrz nich, ale będzie mógł je zakończyć za pomocą:

nitro-cli terminate-enclave --enclave-id ${ENCLAVE_ID}

Vsocks

Jedynym sposobem na komunikację z obrazem enklawy jest użycie vsocks.

Virtual Socket (vsock) to rodzina gniazd w systemie Linux, zaprojektowana specjalnie w celu ułatwienia komunikacji między maszynami wirtualnymi (VMs) a ich hypervisorami, lub między VM sami. Vsock umożliwia efektywną, dwukierunkową komunikację bez polegania na stosie sieciowym hosta. Umożliwia to VM komunikację nawet bez konfiguracji sieci, używając 32-bitowego identyfikatora kontekstu (CID) i numerów portów do identyfikacji i zarządzania połączeniami. API vsock obsługuje zarówno typy gniazd strumieniowych, jak i datagramowych, podobnie jak TCP i UDP, co zapewnia wszechstronne narzędzie dla aplikacji na poziomie użytkownika w wirtualnych środowiskach.

Tip

Dlatego adres vsock wygląda tak: <CID>:<Port>

Aby znaleźć CIDs obrazów działających w enklawie, możesz po prostu wykonać następujące polecenie i uzyskać EnclaveCID:

nitro-cli describe-enclaves

[
{
"EnclaveName": "secure-channel-example",
"EnclaveID": "i-0bc274f83ade02a62-enc18ef3d09c886748",
"ProcessID": 10131,
    "EnclaveCID": 16,
    "NumberOfCPUs": 2,
"CPUIDs": [
1,
3
],
"MemoryMiB": 1024,
"State": "RUNNING",
"Flags": "DEBUG_MODE",
"Measurements": {
"HashAlgorithm": "Sha384 { ... }",
"PCR0": "e199261541a944a93129a52a8909d29435dd89e31299b59c371158fc9ab3017d9c450b0a580a487e330b4ac691943284",
"PCR1": "bcdf05fefccaa8e55bf2c8d6dee9e79bbff31e34bf28a99aa19e6b29c37ee80b214a414b7607236edf26fcb78654e63f",
"PCR2": "2e1fca1dbb84622ec141557dfa971b4f8ea2127031b264136a20278c43d1bba6c75fea286cd4de9f00450b6a8db0e6d3"
}
}
]

Warning

Zauważ, że z hosta nie ma sposobu, aby wiedzieć, czy CID eksponuje jakiś port! Chyba że używasz jakiegoś skanera portów vsock, takiego jak https://github.com/carlospolop/Vsock-scanner.

Vsock Server/Listener

Znajdź tutaj kilka przykładów:

Prosty nasłuchiwacz w Pythonie ```python #!/usr/bin/env python3

From

https://medium.com/@F.DL/understanding-vsock-684016cf0eb0

import socket

CID = socket.VMADDR_CID_HOST PORT = 9999

s = socket.socket(socket.AF_VSOCK, socket.SOCK_STREAM) s.bind((CID, PORT)) s.listen() (conn, (remote_cid, remote_port)) = s.accept()

print(f“Connection opened by cid={remote_cid} port={remote_port}“)

while True: buf = conn.recv(64) if not buf: break

print(f“Received bytes: {buf}“)

</details>
```bash
# Using socat
socat VSOCK-LISTEN:<port>,fork EXEC:"echo Hello from server!"

Klient Vsock

Przykłady:

Prosty klient Python ```python #!/usr/bin/env python3

#From https://medium.com/@F.DL/understanding-vsock-684016cf0eb0

import socket

CID = socket.VMADDR_CID_HOST PORT = 9999

s = socket.socket(socket.AF_VSOCK, socket.SOCK_STREAM) s.connect((CID, PORT)) s.sendall(b“Hello, world!“) s.close()

</details>
```bash
# Using socat
echo "Hello, vsock!" | socat - VSOCK-CONNECT:3:5000

Vsock Proxy

Narzędzie vsock-proxy pozwala na proxy vsock proxy z innym adresem, na przykład:

vsock-proxy 8001 ip-ranges.amazonaws.com 443 --config your-vsock-proxy.yaml

To będzie przekierowywać lokalny port 8001 w vsock do ip-ranges.amazonaws.com:443, a plik your-vsock-proxy.yaml może mieć tę zawartość, umożliwiając dostęp do ip-ranges.amazonaws.com:443:

allowlist:
- { address: ip-ranges.amazonaws.com, port: 443 }

Można zobaczyć adresy vsock (<CID>:<Port>) używane przez hosta EC2 za pomocą (zauważ 3:8001, 3 to CID, a 8001 to port):

sudo ss -l -p -n | grep v_str
v_str LISTEN 0      0                                                                              3:8001                   *:*     users:(("vsock-proxy",pid=9458,fd=3))

Nitro Enclave Atestacja & KMS

SDK Nitro Enclaves pozwala na żądanie podpisanego kryptograficznie dokumentu atestacyjnego od Nitro Hypervisora, który zawiera unikalne pomiary specyficzne dla tej enklawy. Te pomiary, które obejmują hashe i rejestry konfiguracji platformy (PCR), są używane podczas procesu atestacji do udowodnienia tożsamości enklawy i budowania zaufania z zewnętrznymi usługami. Dokument atestacyjny zazwyczaj zawiera wartości takie jak PCR0, PCR1 i PCR2, które spotkałeś wcześniej podczas budowania i zapisywania pliku EIF enklawy.

Z dokumentacji, oto wartości PCR:

PCRHash of ...Opis
PCR0Plik obrazu enklawyCiagły pomiar zawartości pliku obrazu, bez danych sekcji.
PCR1Jądro Linux i bootstrapCiagły pomiar danych jądra i boot ramfs.
PCR2AplikacjaCiagły, uporządkowany pomiar aplikacji użytkownika, bez boot ramfs.
PCR3Rola IAM przypisana do instancji nadrzędnejCiagły pomiar roli IAM przypisanej do instancji nadrzędnej. Zapewnia, że proces atestacji kończy się sukcesem tylko wtedy, gdy instancja nadrzędna ma odpowiednią rolę IAM.
PCR4ID instancji nadrzędnejCiagły pomiar ID instancji nadrzędnej. Zapewnia, że proces atestacji kończy się sukcesem tylko wtedy, gdy instancja nadrzędna ma konkretne ID instancji.
PCR8Certyfikat podpisu pliku obrazu enklawyPomiar certyfikatu podpisu określonego dla pliku obrazu enklawy. Zapewnia, że proces atestacji kończy się sukcesem tylko wtedy, gdy enklawa została uruchomiona z pliku obrazu enklawy podpisanego przez konkretny certyfikat.

Możesz zintegrować atestację kryptograficzną w swoich aplikacjach i wykorzystać wstępnie zbudowane integracje z usługami takimi jak AWS KMS. AWS KMS może walidować atestacje enklaw i oferuje klucze warunkowe oparte na atestacji (kms:RecipientAttestation:ImageSha384 i kms:RecipientAttestation:PCR) w swoich politykach kluczy. Polityki te zapewniają, że AWS KMS zezwala na operacje z użyciem klucza KMS tylko wtedy, gdy dokument atestacyjny enklawy jest ważny i spełnia określone warunki.

Tip

Zauważ, że Enklawy w trybie debug (–debug) generują dokumenty atestacyjne z PCR, które składają się z zer (000000000000000000000000000000000000000000000000). Dlatego polityki KMS sprawdzające te wartości będą nieudane.

Ominięcie PCR

Z perspektywy atakującego, zauważ, że niektóre PCR pozwoliłyby na modyfikację niektórych części lub całego obrazu enklawy i nadal byłyby ważne (na przykład PCR4 sprawdza tylko ID instancji nadrzędnej, więc uruchomienie dowolnego obrazu enklawy w tej EC2 pozwoli na spełnienie tego potencjalnego wymogu PCR).

Dlatego atakujący, który skompromituje instancję EC2, może być w stanie uruchomić inne obrazy enklaw w celu ominięcia tych zabezpieczeń.

Badania nad tym, jak modyfikować/tworzyć nowe obrazy, aby obejść każde zabezpieczenie (szczególnie te nie tak oczywiste) są nadal w planach.

Referencje

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks