Translated ['src/pentesting-cloud/confidential-computing/luks2-header-ma

2026-07-28 22:51:09 -07:00 · 2025-11-15 16:37:20 +00:00
parent bd4b61e6c7
commit 9fa6587c8b
2 changed files with 191 additions and 51 deletions
@@ -0,0 +1,141 @@
+# LUKS2 헤더 변경 가능성 및 Null-Cipher 악용 (Confidential VMs)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## 요약
+
+- 많은 Linux 기반 Confidential VMs (CVMs)이 AMD SEV-SNP 또는 Intel TDX에서 실행되며 영구 스토리지에 LUKS2를 사용한다. 디스크 상의 LUKS2 헤더는 변경 가능하며 스토리지 인접 공격자에 대해 무결성 보호가 되어 있지 않다.
+- 헤더의 데이터 세그먼트 암호가 null cipher(e.g., "cipher_null-ecb")로 설정되어 있으면 cryptsetup은 이를 허용하고 게스트는 디스크가 암호화되어 있다고 믿는 동안 평문을 투명하게 읽고/쓴다.
+- cryptsetup 2.8.0 이전 및 해당 버전까지는 null ciphers를 keyslots에 사용할 수 있었고, 2.8.1 이후에는 비어 있지 않은 비밀번호가 있는 keyslots에 대해 거부되지만 null ciphers는 볼륨 세그먼트에는 여전히 허용된다.
+- Remote attestation은 일반적으로 VM 코드/구성만 측정하며 변경 가능한 외부 LUKS 헤더를 측정하지 않는다; 명시적 검증/측정이 없으면 디스크 쓰기 권한이 있는 공격자가 평문 I/O를 강제할 수 있다.
+
+## 배경: LUKS2 온디스크 포맷 (공격자에게 중요한 부분)
+
+- LUKS2 장치는 헤더로 시작하고 그 뒤에 암호화된 데이터가 온다.
+- 헤더는 바이너리 섹션의 동일한 복사본 두 개와 JSON 메타데이터 섹션, 그리고 하나 이상의 keyslots를 포함한다.
+- JSON 메타데이터는 다음을 정의한다:
+  - 활성화된 keyslots와 그들을 감싸는 KDF/cipher
+  - 데이터 영역을 설명하는 segments (cipher/mode)
+  - digests (예: 암호문 확인을 위한 볼륨 키의 해시)
+- 일반적인 안전 설정: keyslot KDF는 argon2id; keyslot 및 데이터 세그먼트 암호화는 aes-xts-plain64.
+
+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 헤더는 스토리지 변조에 대해 인증되지 않습니다. 호스트/스토리지 공격자는 cryptsetup이 수용하는 JSON 메타데이터를 재작성할 수 있습니다.
+- cryptsetup 2.8.0부터, 세그먼트의 암호화를 cipher_null-ecb로 설정한 헤더가 허용됩니다. The null cipher는 키를 무시하고 평문을 반환합니다.
+- 2.8.0까지는 null ciphers를 keyslots에도 사용할 수 있었고 (keyslot은 어떤 패스프레이즈로든 열림). 2.8.1부터는 비어있지 않은 비밀번호가 있는 keyslots에 대해 null ciphers가 거부되지만, segments에 대해서는 여전히 허용됩니다. segment cipher만 변경해도 2.8.1 이후에도 평문 I/O가 발생합니다.
+
+## 위협 모델: 왜 attestation이 기본적으로 보호하지 못했는가
+
+- CVMs는 신뢰할 수 없는 호스트에서 기밀성, 무결성, 및 진위성을 보장하는 것을 목표로 합니다.
+- Remote attestation은 보통 VM 이미지와 런치 구성(launch configuration)을 측정하며, 신뢰할 수 없는 스토리지에 있는 변경 가능한 LUKS 헤더는 측정하지 않습니다.
+- 만약 CVM이 충분한 검증/측정 없이 온디스크 헤더를 신뢰한다면, 스토리지 공격자는 이를 null cipher로 변경할 수 있고 guest는 오류 없이 평문 볼륨을 마운트하게 됩니다.
+
+## 악용 (스토리지 쓰기 접근 필요)
+
+Preconditions:
+- CVM의 LUKS2로 암호화된 블록 디바이스에 대한 쓰기 접근.
+- guest가 온디스크 LUKS2 헤더를 강력한 검증/attestation 없이 사용함.
+
+Steps (high level):
+1) 헤더 JSON을 읽고 data segment 정의를 식별합니다. 예시 대상 필드: segments["0"].encryption.
+2) 데이터 세그먼트의 암호화를 null cipher로 설정합니다(예: cipher_null-ecb). guest의 일반적인 패스프레이즈가 여전히 "작동"하도록 keyslot 파라미터와 digest 구조는 그대로 유지합니다.
+3) 두 헤더 복사본과 연관된 header digests를 업데이트하여 헤더가 자체적으로 일관되게 만듭니다.
+4) 다음 부팅 시 guest는 cryptsetup을 실행하고 기존 keyslot을 패스프레이즈로 성공적으로 언락한 뒤 볼륨을 마운트합니다. 세그먼트 cipher가 null cipher이므로 모든 읽기/쓰기 동작은 평문입니다.
+
+Variant (pre-2.8.1 keyslot abuse): keyslot의 area.encryption이 null cipher라면 어떤 패스프레이즈로도 열립니다. 이를 null segment cipher와 결합하면 guest의 비밀을 알지 못해도 원활하게 평문에 접근할 수 있습니다.
+
+## 강력한 완화책 (detached headers로 TOCTOU 회피)
+
+온디스크 LUKS 헤더는 항상 신뢰할 수 없는 입력으로 취급하십시오. detached-header 모드를 사용해 검증과 오픈이 보호된 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 메타데이터를 덤프하고 파라미터의 엄격한 허용 목록을 검증합니다 (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>예시 validator (안전한 필드 강제)</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를 제거하고 정제된 헤더를 TPM/TDX/SEV PCRs 또는 KMS policy state에 측정(measure)하십시오.
+- 측정된 헤더가 승인된 안전 프로파일과 일치할 때만 복호화 키를 해제하십시오.
+
+운영 지침:
+- detached header + MAC을 강제하거나 엄격한 검증을 적용하십시오; 디스크 상의(on-disk) 헤더를 직접 신뢰하지 마십시오.
+- attestation의 소비자는 허용 목록에서 패치 이전(pre-patch) 프레임워크 버전을 거부해야 합니다.
+
+## 버전 및 유지관리자 입장
+
+- cryptsetup maintainers는 LUKS2가 이 환경에서 스토리지 변조에 대한 무결성을 제공하도록 설계되지 않았음을 명확히 했으며; null ciphers는 하위 호환성을 위해 유지됩니다.
+- cryptsetup 2.8.1 (Oct 19, 2025)은 비어있지 않은 비밀번호가 설정된 keyslots에 대해 null ciphers를 거부하지만 여전히 segments에 대해서는 null ciphers를 허용합니다.
+
+## 빠른 점검 및 분류
+
+- 세그먼트(segment) 암호화가 null cipher로 설정되어 있는지 확인:
+```bash
+cryptsetup luksDump --type luks2 --dump-json-metadata /dev/VDISK \
+| jq -r '.segments | to_entries[] | "segment=" + .key + ", enc=" + .value.encryption'
+```
+- 볼륨을 열기 전에 keyslot 및 segment 알고리즘을 검증하세요. MAC을 적용할 수 없다면 엄격한 JSON 유효성 검사를 강제하고 보호된 메모리에서 분리된 헤더(detached header)를 사용해 여세요.
+
+## References
+
+- [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}}
@@ -1,4 +1,4 @@
-# Pentesting 클라우드 방법론
+# Pentesting Cloud 방법론

 {{#include ../banners/hacktricks-training.md}}

@@ -6,39 +6,39 @@

 ## 기본 방법론

-각 클라우드마다 고유한 특성이 있지만 일반적으로 클라우드 환경을 테스트할 때 확인해야 할 몇 가지 **common things a pentester should check**가 있습니다:
+각 클라우드마다 고유한 특성이 있지만, 일반적으로 클라우드 환경을 테스트할 때 **pentester가 확인해야 할 몇 가지 공통 항목**이 있습니다:

- **Benchmark checks**
- 이는 환경의 **규모를 이해하는 것**과 **사용되는 서비스**를 파악하는 데 도움이 됩니다.
- 대부분의 테스트를 **자동화 도구**로 수행할 수 있기 때문에 빠른 **잘못된 구성(misconfigurations)**을 찾는 데도 도움이 됩니다.
- **Services Enumeration**
- 벤치마크 테스트를 올바르게 수행했다면 여기서 더 많은 잘못된 구성을 찾기 어려울 수 있지만, 벤치마크에서 찾지 못한 항목을 발견할 수도 있습니다.
- 이는 클라우드 환경에서 **정확히 무엇이 사용되고 있는지** 알 수 있게 해줍니다.
- 다음 단계에서 많은 도움이 됩니다.
- **Check exposed assets**
- 이전 섹션 동안 수행할 수 있으며, 인터넷에 **잠재적으로 노출된 모든 것**과 그것이 어떻게 접근되는지를 찾아야 합니다.
- 여기서는 웹 페이지나 다른 포트가 노출된 인스턴스와 같은 **수동으로 노출된 인프라**뿐만 아니라 DBs나 buckets처럼 **노출되도록 구성될 수 있는 클라우드 관리형 서비스**도 포함합니다.
- 그런 다음 해당 리소스가 **노출될 수 있는지 여부**(기밀 정보인가? 취약점인가? 노출된 서비스의 설정 오류인가?)를 확인해야 합니다.
- **Check permissions**
- 여기서는 클라우드 내 각 역할/사용자의 **모든 권한을 찾아내고** 그것들이 어떻게 사용되는지를 확인해야 합니다.
- 너무 **많은 고권한**(모든 것을 제어) 계정이 있는가? 생성된 키가 사용되지 않고 있는가?… 대부분의 이러한 점검은 이미 벤치마크 테스트에서 수행되었어야 합니다.
- 클라이언트가 OpenID나 SAML 또는 다른 **federation**을 사용 중이라면 각 역할이 **어떻게 할당되는지**에 대해 추가 **정보**를 요청해야 할 수도 있습니다(관리자 역할이 1명에게 할당되는 것과 100명에게 할당되는 것은 같지 않습니다).
- 단순히 어떤 사용자가 **admin** 권한 "*:*"을 가지고 있는지를 찾는 것만으로는 충분하지 않습니다. 사용되는 서비스에 따라 매우 **민감한 다른 많은 권한들**이 있습니다.
- 또한 권한을 남용하여 따를 수 있는 **잠재적 privesc** 경로들이 있습니다. 이 모든 것을 고려하고 가능한 많은 privesc 경로를 보고해야 합니다.
- **Check Integrations**
- 클라우드 환경 내에서 다른 클라우드나 SaaS와의 **통합(integrations)**이 사용되고 있을 가능성이 매우 높습니다.
- 감사를 하는 클라우드와 다른 플랫폼 간의 **통합**에 대해서는 누가 그 통합을 (남용)할 수 있는지 **알려야** 하며, 수행되는 작업이 **어느 정도 민감한지** 물어보아야 합니다.\
-예를 들어, GCP가 데이터를 가져오는 AWS 버킷에 누가 쓰기 권한이 있는지(그 작업이 GCP에서 해당 데이터를 처리할 때 얼마나 민감한지 물어보세요).
- 감사를 하는 클라우드 내부로 외부 플랫폼에서의 **통합**에 대해서는 외부에서 누가 그 통합을 (남용)할 수 있는지 물어보고 해당 데이터가 어떻게 사용되는지 확인해야 합니다.\
-예를 들어, 어떤 서비스가 GCR에 호스팅된 Docker 이미지를 사용한다면 누가 그 이미지를 수정할 수 있는지, 그리고 그 이미지가 AWS 클라우드 내부에서 실행될 때 어떤 민감한 정보와 접근 권한을 얻게 되는지 물어보아야 합니다.
+- **벤치마크 점검**
+- 이는 환경의 **규모를 이해**하고 **사용되는 서비스**를 파악하는 데 도움이 됩니다
+- 대부분의 테스트를 **자동화 도구**로 수행할 수 있기 때문에 일부 **빠른 misconfigurations**를 찾는 데에도 유용합니다
+- **서비스 열거**
+- 벤치마크 테스트를 제대로 수행했다면 여기서 더 많은 misconfigurations를 찾기 어렵지만, 벤치마크에서 찾아보지 않았던 항목을 발견할 수 있습니다.
+- 이를 통해 클라우드 환경에서 **정확히 무엇이 사용되는지** 알 수 있습니다
+- 다음 단계에서 큰 도움이 됩니다
+- **노출된 자산 확인**
+- 이는 이전 섹션에서 수행할 수 있으며, 인터넷에 어떤 방식으로든 **잠재적으로 노출되어 있는 모든 것**과 그것에 어떻게 접근할 수 있는지를 찾아야 합니다.
+- 여기서는 웹 페이지가 올라가 있는 인스턴스나 다른 포트가 노출된 수동으로 노출된 인프라와, DB나 버킷과 같이 **노출되도록 설정될 수 있는 다른 클라우드 관리형 서비스**에 대해 다루고 있습니다.
+- 그런 다음 해당 리소스가 **노출될 수 있는지 아닌지**(기밀 정보? 취약점? 노출된 서비스의 misconfigurations?)를 확인해야 합니다.
+- **권한 확인**
+- 여기서는 클라우드 내 각 role/user의 **모든 권한을 파악**하고 그것들이 어떻게 사용되는지 확인해야 합니다
+- 너무 **많은 고권한(모든 것을 제어하는)** 계정이 있는가? 생성된 키가 사용되지 않고 있는가?... 대부분의 이러한 검사는 이미 벤치마크 테스트에서 수행되었어야 합니다
+- 클라이언트가 OpenID나 SAML 또는 다른 **federation**을 사용하고 있다면 각 role이 **어떻게 할당되는지**에 대해 추가 **정보**를 요청해야 할 수도 있습니다(예: admin 역할이 1명에게 할당되는 것과 100명에게 할당되는 것은 같지 않습니다)
+- 단순히 어떤 사용자가 **admin** 권한 "\*:\*"을 가지고 있는지 찾는 것만으로는 **충분하지 않습니다**. 사용되는 서비스에 따라 매우 **민감한** 많은 **다른 권한들**이 있습니다.
+- 또한 권한을 남용하여 따를 수 있는 **잠재적 privesc** 경로들이 있습니다. 이 모든 것을 고려하여 가능한 한 **많은 privesc 경로**를 보고해야 합니다.
+- **통합(Integrations) 확인**
+- 클라우드 환경 내에서 다른 클라우드나 SaaS와의 **통합이 사용되고 있을 가능성**이 높습니다.
+- **감사 대상인 클라우드가 다른 플랫폼과 통합된 경우**, 그 통합을 누가 (오용)할 수 있는지 알리고 해당 동작이 얼마나 **민감한지** 물어봐야 합니다.\
+예를 들어, GCP가 데이터를 가져오는 AWS 버킷에 누가 쓸 수 있는지(그 데이터를 처리하는 GCP에서 해당 동작이 얼마나 민감한지 물어보세요).
+- **감사 대상인 클라우드로부터 외부 플랫폼이 통합하는 경우**, 외부에서 그 통합을 누가 (오용)할 수 있는지 물어보고 그 데이터가 어떻게 사용되는지 확인해야 합니다.\
+예를 들어, 어떤 서비스가 GCR에 호스팅된 Docker 이미지를 사용한다면, 누가 그 이미지를 수정할 수 있는지, 그리고 그 이미지가 AWS 클라우드 내부에서 실행될 때 어떤 민감한 정보와 접근 권한을 얻을지를 물어봐야 합니다.

-## Multi-Cloud 도구
+## 멀티 클라우드 도구

-여러 클라우드 환경을 테스트하는 데 사용할 수 있는 도구들이 있습니다. 이 섹션에서는 설치 단계와 링크를 안내합니다.
+다양한 클라우드 환경을 테스트하는 데 사용할 수 있는 여러 도구가 있습니다. 이 섹션에서 설치 단계와 링크를 안내합니다.

 ### [PurplePanda](https://github.com/carlospolop/purplepanda)

-클라우드 및 클라우드/SaaS 간의 **잘못된 구성과 privesc 경로를 식별**하는 도구입니다.
+클라우드 및 클라우드/SaaS 전반에서 잘못된 구성과 privesc 경로를 **식별하는 도구**입니다.

 {{#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,11 +194,11 @@ 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 인사이트**를 확인하려면 다음을 사용하세요: [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)

-Steampipe의 추가 GCP 플러그인을 보려면: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Steampipe의 더 많은 GCP 플러그인: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}

 {{#tab name="AWS" }}
@@ -225,24 +225,24 @@ 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)
+Steampipe의 더 많은 AWS 플러그인: [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이 필요하며 유지보수되지 않는 것으로 보임.
+AWS, GCP, Azure, DigitalOcean.\
+python2.7이 필요하며 유지보수가 되지 않는 것으로 보입니다.

 ### Nessus

-Nessus는 _**Audit Cloud Infrastructure**_ 스캔을 제공하며 지원 대상: AWS, Azure, Office 365, Rackspace, Salesforce. **Azure**에서 **Client Id**를 얻기 위해 일부 추가 구성이 필요함.
+Nessus에는 _**Audit Cloud Infrastructure**_ 스캔이 있어 다음을 지원합니다: AWS, Azure, Office 365, Rackspace, Salesforce. **Azure**에서 **Client Id**를 얻으려면 몇 가지 추가 구성이 필요합니다.

 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)

-Cloudlist는 Cloud Providers로부터 Assets (Hostnames, IP Addresses)를 가져오는 **multi-cloud tool for getting Assets**입니다.
+Cloudlist는 클라우드 제공업체로부터 Assets (Hostnames, IP Addresses)을 수집하기 위한 **multi-cloud tool**입니다.

 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>

 ### [**cartography**](https://github.com/lyft/cartography)

-Cartography는 Neo4j 데이터베이스로 구동되는 직관적인 그래프 뷰에서 인프라 자산과 자산 간의 관계를 통합하는 Python 도구입니다.
+Cartography는 Neo4j database 기반의 직관적인 그래프 뷰에서 인프라 자산과 이들 간의 관계를 통합하는 Python 도구입니다.

 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \

 ### [**starbase**](https://github.com/JupiterOne/starbase)

-Starbase는 클라우드 인프라, SaaS 애플리케이션, 보안 통제 등 서비스를 포함한 시스템에서 자산과 관계를 수집하여 Neo4j 데이터베이스 기반의 직관적인 그래프 뷰로 제공합니다.
+Starbase는 클라우드 인프라, SaaS 애플리케이션, 보안 통제 등 서비스와 시스템의 자산 및 관계를 수집하여 Neo4j 데이터베이스 기반의 직관적인 그래프 뷰로 제공합니다.

 {{#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,13 +372,13 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)

-회사(대상)의 인프라, 파일 및 앱을 주요 클라우드 제공업체(Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode)에서 찾아주는 도구입니다.
+회사 (target)의 인프라, 파일 및 앱을 상위 클라우드 제공업체(Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode)에서 찾아주는 도구입니다.

 ### [CloudFox](https://github.com/BishopFox/cloudfox)

- CloudFox는 cloud infrastructure에서 exploitable attack paths를 찾는 도구입니다(현재는 AWS & Azure만 지원하며 GCP는 추후 지원 예정입니다).
- 수동 pentesting을 보완하도록 설계된 enumeration 도구입니다.
- cloud environment 내의 데이터를 생성하거나 수정하지 않습니다.
+- CloudFox는 클라우드 인프라에서 exploitable attack paths를 찾아주는 도구입니다 (현재는 AWS & Azure만 지원하며 GCP는 곧 지원될 예정입니다).
+- 수동 pentesting을 보완하기 위한 enumeration 도구입니다.
+- 클라우드 환경 내의 데이터를 생성하거나 수정하지 않습니다.

 ### More lists of cloud security tools

@@ -410,13 +410,12 @@ aws-security/
 azure-security/
 {{#endref}}

-### Attack Graph
+## 공통 클라우드 보안 기능

-[**Stormspotter** ](https://github.com/Azure/Stormspotter)creates an “attack graph” of the resources in an Azure subscription. 이를 통해 red teams와 pentesters가 attack surface 및 pivot 기회를 시각화할 수 있으며, defenders가 incident response 작업의 우선순위를 빠르게 파악하고 정하는 데 큰 도움을 줍니다.
-
-### Office365
-
-Global Admin 또는 최소한 Global Admin Reader 권한이 필요합니다(단, Global Admin Reader는 약간 제한적입니다). 그러나 이러한 제한은 일부 PS modules에서 나타나며, 웹 애플리케이션을 통해 기능에 접근하면 우회할 수 있습니다.
+### 기밀 컴퓨팅

+{{#ref}}
+confidential-computing/luks2-header-malleability-null-cipher-abuse.md
+{{#endref}}

 {{#include ../banners/hacktricks-training.md}}