AWS - Nitro Enum

Unterstütze HackTricks

Grundlegende Informationen

AWS Nitro ist eine Suite von innovativen Technologien, die die zugrunde liegende Plattform für AWS EC2-Instanzen bilden. Von Amazon eingeführt, um Sicherheit, Leistung und Zuverlässigkeit zu verbessern, nutzt Nitro benutzerdefinierte Hardwarekomponenten und einen leichten Hypervisor. Es abstrahiert viele der traditionellen Virtualisierungsfunktionen auf dedizierte Hardware und Software, minimiert die Angriffsfläche und verbessert die Ressourceneffizienz. Durch das Auslagern von Virtualisierungsfunktionen ermöglicht Nitro EC2-Instanzen eine nahezu native Bare-Metal-Leistung, was besonders für ressourcenintensive Anwendungen von Vorteil ist. Zusätzlich stellt der Nitro Security Chip speziell die Sicherheit der Hardware und Firmware sicher und festigt so seine robuste Architektur.

Nitro Enclaves

AWS Nitro Enclaves bietet eine sichere, isolierte Rechenumgebung innerhalb von Amazon EC2-Instanzen, die speziell für die Verarbeitung hochsensibler Daten entwickelt wurde. Durch die Nutzung des AWS Nitro Systems gewährleisten diese Enclaves eine robuste Isolation und Sicherheit, ideal für die Handhabung vertraulicher Informationen wie PII oder Finanzdaten. Sie bieten eine minimalistische Umgebung, die das Risiko einer Datenexposition erheblich reduziert. Darüber hinaus unterstützen Nitro Enclaves kryptografische Attestierung, die es den Benutzern ermöglicht zu überprüfen, dass nur autorisierter Code ausgeführt wird, was entscheidend für die Einhaltung strenger Compliance- und Datenschutzstandards ist.

Nitro Enclave-Bilder werden von innerhalb der EC2-Instanzen ausgeführt und Sie können in der AWS-Webkonsole nicht sehen, ob eine EC2-Instanz Bilder in Nitro Enclave ausführt oder nicht.

Installation der Nitro Enclave CLI

Folgen Sie allen Anweisungen aus der Dokumentation. Dies sind jedoch die wichtigsten:

# 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

Die Images, die Sie in Nitro Enclave ausführen können, basieren auf Docker-Images, sodass Sie Ihre Nitro Enclave-Images aus Docker-Images erstellen können wie:

# 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

Wie Sie sehen können, verwenden die Nitro Enclave-Bilder die Erweiterung eif (Enclave Image File).

Die Ausgabe wird ähnlich aussehen wie:

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

Ein Image ausführen

Laut der Dokumentation, um ein Enclave-Image auszuführen, müssen Sie ihm mindestens das 4-fache der Größe der eif-Datei an Speicher zuweisen. Es ist möglich, die Standardressourcen, die ihm zugewiesen werden sollen, in der Datei zu konfigurieren.

/etc/nitro_enclaves/allocator.yaml

Denken Sie immer daran, dass Sie auch einige Ressourcen für die übergeordnete EC2-Instanz reservieren müssen!

Nachdem Sie die Ressourcen für ein Image kennen und sogar die Konfigurationsdatei geändert haben, ist es möglich, ein Enclave-Image mit folgendem Befehl auszuführen:

# 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

Enklaven auflisten

Wenn Sie einen EC2-Host kompromittieren, ist es möglich, eine Liste der laufenden Enklaven-Images zu erhalten mit:

nitro-cli describe-enclaves

Es ist nicht möglich, eine Shell innerhalb eines laufenden Enclave-Images zu erhalten, da dies der Hauptzweck der Enclave ist. Wenn Sie jedoch den Parameter --debug-mode verwendet haben, ist es möglich, das stdout davon zu erhalten mit:

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

Enclaves Beenden

Wenn ein Angreifer eine EC2-Instanz kompromittiert, kann er standardmäßig keine Shell in ihnen erhalten, aber er wird in der Lage sein, sie mit folgendem Befehl zu beenden:

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

Vsocks

Der einzige Weg, mit einem laufenden Enclave-Image zu kommunizieren, ist die Verwendung von vsocks.

Virtual Socket (vsock) ist eine Socket-Familie in Linux, die speziell entwickelt wurde, um die Kommunikation zwischen virtuellen Maschinen (VMs) und ihren Hypervisoren oder zwischen VMs untereinander zu erleichtern. Vsock ermöglicht eine effiziente, bidirektionale Kommunikation, ohne auf den Netzwerk-Stack des Hosts angewiesen zu sein. Dies ermöglicht es VMs, auch ohne Netzwerkkonfigurationen zu kommunizieren, indem eine 32-Bit Context ID (CID) und Portnummern zur Identifizierung und Verwaltung von Verbindungen verwendet werden. Die vsock-API unterstützt sowohl Stream- als auch Datagram-Socket-Typen, ähnlich wie TCP und UDP, und bietet ein vielseitiges Werkzeug für Benutzeranwendungen in virtuellen Umgebungen.

Daher sieht eine vsock-Adresse so aus: <CID>:<Port>

Um die CIDs der laufenden Enclave-Images zu finden, können Sie einfach den folgenden Befehl ausführen und die EnclaveCID abrufen:

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"
}
}
]

Beachten Sie, dass es vom Host aus keine Möglichkeit gibt zu wissen, ob ein CID einen Port freigibt! Es sei denn, Sie verwenden einen vsock-Portscanner wie https://github.com/carlospolop/Vsock-scanner.

Vsock Server/Listener

Hier finden Sie ein paar Beispiele:

Einfacher Python Listener

```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!"

Vsock Client

Beispiele:

```bash # Using socat echo "Hello, vsock!" | socat - VSOCK-CONNECT:3:5000 ``` ### Vsock Proxy

Das Tool vsock-proxy ermöglicht es, einen vsock-Proxy mit einer anderen Adresse zu verbinden, zum Beispiel:

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

Dies wird den lokalen Port 8001 in vsock zu ip-ranges.amazonaws.com:443 weiterleiten und die Datei your-vsock-proxy.yaml könnte diesen Inhalt haben, der den Zugriff auf ip-ranges.amazonaws.com:443 ermöglicht:

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

Es ist möglich, die vsock-Adressen (<CID>:<Port>) zu sehen, die vom EC2-Host verwendet werden (beachten Sie 3:8001, 3 ist die CID und 8001 der 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 Attestation & KMS

Das Nitro Enclaves SDK ermöglicht es einem Enclave, ein kryptographisch signiertes Attestationsdokument vom Nitro Hypervisor anzufordern, das einzigartige Messungen enthält, die spezifisch für diese Enclave sind. Diese Messungen, die Hashes und Plattformkonfigurationsregister (PCRs) umfassen, werden während des Attestationsprozesses verwendet, um die Identität der Enclave zu beweisen und Vertrauen mit externen Diensten aufzubauen. Das Attestationsdokument enthält typischerweise Werte wie PCR0, PCR1 und PCR2, die Sie bereits beim Erstellen und Speichern einer Enclave EIF gesehen haben.

Aus den Dokumentationen sind dies die PCR-Werte:

Sie können kryptographische Attestationen in Ihre Anwendungen integrieren und vorgefertigte Integrationen mit Diensten wie AWS KMS nutzen. AWS KMS kann Enclave-Attestationen validieren und bietet attestationsbasierte Bedingungsschlüssel (kms:RecipientAttestation:ImageSha384 und kms:RecipientAttestation:PCR) in seinen Schlüsselrichtlinien. Diese Richtlinien stellen sicher, dass AWS KMS Operationen mit dem KMS-Schlüssel nur dann zulässt, wenn das Attestationsdokument der Enclave gültig ist und die festgelegten Bedingungen erfüllt.

Beachten Sie, dass Enclaves im Debug-Modus (--debug) Attestationsdokumente mit PCRs erzeugen, die aus Nullen bestehen (000000000000000000000000000000000000000000000000). Daher werden KMS-Richtlinien, die diese Werte überprüfen, fehlschlagen.

PCR-Umgehung

Aus der Perspektive eines Angreifers ist zu beachten, dass einige PCRs es erlauben würden, einige Teile oder das gesamte Enclave-Bild zu ändern und dennoch gültig zu bleiben (zum Beispiel überprüft PCR4 nur die ID der übergeordneten Instanz, sodass das Ausführen eines beliebigen Enclave-Bildes in dieser EC2-Instanz die Erfüllung dieser potenziellen PCR-Anforderung ermöglicht).

Daher könnte ein Angreifer, der die EC2-Instanz kompromittiert, in der Lage sein, andere Enclave-Bilder auszuführen, um diese Schutzmaßnahmen zu umgehen.

Die Forschung darüber, wie man neue Bilder modifiziert/erstellt, um jede Schutzmaßnahme zu umgehen (insbesondere die nicht so offensichtlichen), steht noch aus.

Referenzen

Last updated