Translated ['src/pentesting-cloud/azure-security/az-services/az-cosmosDB

This commit is contained in:
Translator
2025-01-22 23:09:54 +00:00
parent e3528e9430
commit b07168476e
5 changed files with 53 additions and 88 deletions
+2 -1
View File
@@ -398,7 +398,8 @@
- [Az - Enumeration Tools](pentesting-cloud/azure-security/az-enumeration-tools.md)
- [Az - Unauthenticated Enum & Initial Entry](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/README.md)
- [Az - OAuth Apps Phishing](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md)
- [Az - VMs Unath](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unath.md)
- [Az - Storage Unath](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-storage-unauth.md)
- [Az - VMs Unath](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unauth.md)
- [Az - Device Code Authentication Phishing](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md)
- [Az - Password Spraying](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying.md)
- [Az - Services](pentesting-cloud/azure-security/az-services/README.md)
@@ -17,11 +17,11 @@ Learn & practice GCP Hacking: <img src="../../../.gitbook/assets/image (2) (1).p
## Azure CosmosDB
**Azure Cosmos DB**는 단일 밀리초 응답 시간, 자동 확장성 및 기업 수준의 보안이 보장된 SLA 기반 가용성을 제공하는 완전 관리형 **NoSQL, 관계형 및 벡터 데이터베이스**입니다. 이는 다중 지역 데이터 배, 오픈 소스 API, 인기 있는 언어를 위한 SDK 및 통합 벡터 지원과 원활한 Azure AI 통합과 같은 AI 데이터베이스 기능을 통해 더 빠른 앱 개발을 가능하게 합니다.
**Azure Cosmos DB**는 단일 밀리초 응답 시간, 자동 확장성 및 기업 수준의 보안이 보장된 SLA 기반 가용성을 제공하는 완전 관리형 **NoSQL, 관계형 및 벡터 데이터베이스**입니다. 이는 다중 지역 데이터 배, 오픈 소스 API, 인기 있는 언어를 위한 SDK 및 통합 벡터 지원과 원활한 Azure AI 통합과 같은 AI 데이터베이스 기능을 통해 더 빠른 앱 개발을 가능하게 합니다.
Azure Cosmos DB는 문서, 관계형, 키-값, 그래프 및 열 패밀리 데이터 모델을 사용하여 실제 데이터를 모델링하기 위한 여러 데이터베이스 API를 제공합니다. 이 API는 NoSQL, MongoDB, PostgreSQL, Cassandra, Gremlin 및 Table입니다.
CosmosDB의 주요 측면 중 하나는 Azure Cosmos Account입니다. **Azure Cosmos Account**는 데이터베이스에 대한 진입점 역할을 합니다. 계정은 글로벌 배, 일관성 수준 및 사용할 특정 API(예: NoSQL)와 같은 주요 설정을 결정합니다. 계정을 통해 여러 지역에서 데이터에 대한 저지연 액세스를 보장하기 위해 글로벌 복제를 구성할 수 있습니다. 또한 성능과 데이터 정확성 간의 균형을 맞추는 일관성 수준을 선택할 수 있으며, 강력한 일관성에서 최종 일관성까지의 옵션이 있습니다.
CosmosDB의 주요 측면 중 하나는 Azure Cosmos Account입니다. **Azure Cosmos Account**는 데이터베이스에 대한 진입점 역할을 합니다. 계정은 글로벌 배, 일관성 수준 및 사용할 특정 API(예: NoSQL)와 같은 주요 설정을 결정합니다. 계정을 통해 여러 지역에서 데이터에 대한 저지연 액세스를 보장하기 위해 글로벌 복제를 구성할 수 있습니다. 또한 성능과 데이터 정확성 간의 균형을 맞추는 일관성 수준을 선택할 수 있으며, 강력한 일관성에서 최종 일관성까지의 옵션이 제공됩니다.
### NoSQL (sql)
Azure Cosmos DB NoSQL API는 JSON을 데이터 형식으로 사용하는 문서 기반 API입니다. JSON 객체를 쿼리하기 위한 SQL 유사 쿼리 구문을 제공하여 구조화된 데이터 및 반구조화된 데이터 작업에 적합합니다. 서비스의 엔드포인트는 다음과 같습니다:
@@ -36,7 +36,7 @@ https://<Account-Name>.documents.azure.com:443/
계정 내에서 하나 이상의 데이터베이스를 생성할 수 있으며, 이는 컨테이너의 논리적 그룹으로 작용합니다. 데이터베이스는 리소스 관리 및 사용자 권한의 경계 역할을 합니다. 데이터베이스는 컨테이너 간에 프로비저닝된 처리량을 공유하거나 개별 컨테이너에 전용 처리량을 할당할 수 있습니다.
#### 컨테이너
데이터 저장의 핵심 단위는 컨테이너로, JSON 문서를 보유하고 있으며 효율적인 쿼리를 위해 자동으로 인덱싱됩니다. 컨테이너는 탄력적으로 확장 가능하며, 사용자 정의 파티션 키에 의해 결정된 파티션에 분산됩니다. 파티션 키는 최적의 성능과 고른 데이터 분포를 보장하는 데 중요합니다. 예를 들어, 컨테이너는 고객 데이터를 저장할 수 있으며, "customerId" 파티션 키로 사용될 수 있습니다.
데이터 저장의 핵심 단위는 컨테이너로, JSON 문서를 보유하고 있으며 효율적인 쿼리를 위해 자동으로 인덱싱됩니다. 컨테이너는 탄력적으로 확장 가능하며, 사용자 정의 파티션 키에 의해 결정된 파티션에 분산됩니다. 파티션 키는 최적의 성능과 고른 데이터 분포를 보장하는 데 중요합니다. 예를 들어, 컨테이너는 "customerId" 파티션 키로 하여 고객 데이터를 저장할 수 있습니다.
#### 열거
@@ -348,7 +348,7 @@ print(f"Inserted document with ID: {result.inserted_id}")
## ToDo
* 여기 DB의 나머지, 테이블, 카산드라, 그렘린...
* 여기 DB의 나머지 부분, 테이블, 카산드라, 그렘린...
* 포스트 익스플로잇 "Microsoft.DocumentDB/databaseAccounts/mongodbUserDefinitions/write" && "Microsoft.DocumentDB/databaseAccounts/mongodbUserDefinitions/read" 및 역할 정의를 살펴보세요. 여기서 권한 상승이 있을 수 있습니다.
* 복원 사항을 살펴보세요.
@@ -363,7 +363,7 @@ GCP 해킹 배우고 연습하기: <img src="../../../.gitbook/assets/image (2)
<summary>HackTricks 지원하기</summary>
* [**구독 계획**](https://github.com/sponsors/carlospolop) 확인하기!
* **💬 [**디스코드 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 참여하거나 **트위터** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**를 팔로우하세요.**
* **💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 참여하거나 **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**를 팔로우하세요.**
* **[**HackTricks**](https://github.com/carlospolop/hacktricks) 및 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) 깃허브 리포지토리에 PR을 제출하여 해킹 팁을 공유하세요.**
</details>
@@ -1,37 +0,0 @@
# Az - VMs Unath
{{#include ../../../banners/hacktricks-training.md}}
## 가상 머신
Azure 가상 머신에 대한 자세한 정보는 다음을 확인하세요:
{{#ref}}
../az-services/vms/
{{#endref}}
### 노출된 취약 서비스
RCE에 취약한 네트워크 서비스입니다.
### 공개 갤러리 이미지
공개 이미지에는 내부에 비밀이 있을 수 있습니다:
```bash
# List all community galleries
az sig list-community --output table
# Search by publisherUri
az sig list-community --output json --query "[?communityMetadata.publisherUri=='https://3nets.io']"
```
### Public Extensions
이것은 더 이상하게 들릴 수 있지만 불가능하지는 않습니다. 큰 회사가 그 안에 민감한 데이터를 포함한 확장을 넣을 수 있습니다:
```bash
# It takes some mins to run
az vm extension image list --output table
# Get extensions by publisher
az vm extension image list --publisher "Site24x7" --output table
```
{{#include ../../../banners/hacktricks-training.md}}
@@ -3,21 +3,21 @@
{{#include ../../../banners/hacktricks-training.md}}
여기에서 잠재적으로 위험한 Roles 및 ClusterRoles 구성을 찾을 수 있습니다.\
`kubectl api-resources`를 사용하여 지원되는 모든 리소스를 가져올 수 있습니다.
`kubectl api-resources`를 사용하여 지원되는 모든 리소스를 얻을 수 있다는 점을 기억하세요.
## **권한 상승**
클러스터 내에서 **다른 권한**을 가진 **다른 주체에 대한 접근을 얻는 기술**을 의미하며 (kubernetes 클러스터 내 또는 외부 클라우드에 대해), Kubernetes에서는 기본적으로 **권한을 상승시키기 위한 4가지 주요 기술**이 있습니다:
클러스터 내에서 **다른 권한**을 가진 **다른 주체에 대한 접근을 얻는 기술**을 의미하며 (kubernetes 클러스터 내 또는 외부 클라우드에 대해) Kubernetes에서는 기본적으로 **권한을 상승시키기 위한 4가지 주요 기술**이 있습니다:
- Kubernetes 클러스터 내에서 또는 외부 클라우드에 대해 더 나은 권한을 가진 다른 사용자/그룹/SA를 **가장할 수 있는 능력**
- Kubernetes 클러스터 내에서 또는 외부 클라우드에 대해 더 나은 권한을 가진 SA를 **찾거나 연결할 수 있는** **pod를 생성/패치/실행할 수 있는 능력**
- SA의 토큰이 비밀로 저장되므로 **비밀을 읽을 수 있는 능력**
- 컨테이너에서 노드로 **탈출할 수 있는 능력**, 여기서 노드에서 실행 중인 컨테이너의 모든 비밀, 노드의 자격 증명 및 클라우드 내에서 실행 중인 노드의 권한을 훔칠 수 있습니다 (있는 경우)
- 언급할 가치가 있는 다섯 번째 기술은 pod에서 **포트 포워드**를 실행할 수 있는 능력으로, 해당 pod 내의 흥미로운 리소스에 접근할 수 있을 수 있습니다.
- 언급할 가치가 있는 다섯 번째 기술은 pod에서 **포트 포워드를 실행할 수 있는 능력**으로, 해당 pod 내의 흥미로운 리소스에 접근할 수 있을 수 있습니다.
### 모든 리소스 또는 동사에 접근하기 (와일드카드)
**와일드카드 (\*)는 모든 동사에 대해 모든 리소스에 대한 권한을 부여합니다**. 이는 관리자에 의해 사용됩니다. ClusterRole 내에서 이는 공격자가 클러스터의 anynamespace를 악용할 수 있음을 의미합니다.
**와일드카드 (\*)는 모든 동사 모든 리소스에 대한 권한을 부여합니다**. 이는 관리자에 의해 사용됩니다. ClusterRole 내에서 이는 공격자가 클러스터의 anynamespace를 악용할 수 있음을 의미합니다.
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
@@ -49,9 +49,9 @@ verbs: ["create", "list", "get"]
```
### Pod Create - Steal Token
권한이 있는 공격자는 포드를 생성할 수 있으며, 포드에 특권 서비스 계정을 연결하고 토큰을 훔쳐 서비스 계정을 가장할 수 있습니다. 효과적으로 권한을 상승시키는 것입니다.
권한이 있는 공격자가 pod를 생성할 수 있는 경우, 특권이 있는 서비스 계정을 pod에 연결하고 토큰을 훔쳐 서비스 계정을 가장할 수 있습니다. 효과적으로 권한을 상승시키는 것입니다.
`bootstrap-signer` 서비스 계정의 토큰을 훔쳐 공격자에게 전송하는 포드의 예:
`bootstrap-signer` 서비스 계정의 토큰을 훔쳐 공격자에게 전송하는 pod의 예:
```yaml
apiVersion: v1
kind: Pod
@@ -127,7 +127,7 @@ kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hos
#### Stealth
아마도 당신은 **더 은밀하게** 행동하고 싶을 것입니다. 다음 페이지에서는 이전 템플릿에서 언급된 일부 권한만 활성화하여 **pod**를 생성할 경우 접근할 수 있는 내용을 확인할 수 있습니다:
아마도 **은밀함**을 원할 것입니다. 다음 페이지에서는 이전 템플릿에서 언급된 일부 권한만 활성화하여 **pod**를 생성할 경우 접근할 수 있는 내용을 확인할 수 있습니다:
- **Privileged + hostPID**
- **Privileged only**
@@ -136,11 +136,11 @@ kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hos
- **hostNetwork**
- **hostIPC**
_이전 권한이 있는 pods 구성 생성/악용하는 방법의 예는_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods)에서 확인할 수 있습니다.
_이전의 특권 있는 pod 구성 생성/악용 방법의 예는_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) _에서 확인할 수 있습니다._
### Pod Create - Move to cloud
**pod**(선택적으로 **service account**)를 **생성**할 수 있다면, **pod 또는 service account에 클라우드 역할을 할당**하여 **클라우드 환경에서 권한을 얻을 수** 있습니다.\
**pod**(선택적으로 **service account**)를 **생성**할 수 있다면, **pod 또는 service account에 클라우드 역할을 할당**하여 **클라우드 환경에서 권한을 얻을 수** 있습니다.\
또한, **호스트 네트워크 네임스페이스**로 **pod**를 생성할 수 있다면, **노드** 인스턴스의 **IAM** 역할을 **탈취**할 수 있습니다.
자세한 정보는 다음을 확인하세요:
@@ -191,25 +191,25 @@ path: /
```
### **Pods Exec**
**`pods/exec`**는 **포드 내에서 셸에서 명령을 실행하는 데 사용되는 kubernetes의 리소스**입니다. 이를 통해 **컨테이너 내에서 명령을 실행하거나 셸에 들어갈 수 있습니다**.
**`pods/exec`**는 **포드 내에서 셸에서 명령을 실행하는 데 사용되는 kubernetes의 리소스**입니다. 이를 통해 **컨테이너 내에서 명령을 실행하거나 셸에 들어갈 수 있습니다**.
따라서 **포드 내부로 들어가 SA의 토큰을 훔치거나, 특권 포드에 들어가 노드로 탈출하여 노드의 모든 포드 토큰을 훔치고 노드를 (악용)할 수 있습니다**:
따라서 **포드 들어가 SA의 토큰을 훔치거나, 특권 포드에 들어가 노드로 탈출하여 노드의 모든 포드 토큰을 훔치고 노드를 (악용)할 수 있습니다**:
```bash
kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
```
### port-forward
이 권한은 **지정된 포드의 하나의 포트에 하나의 로컬 포트를 포워딩할 수 있게 해줍니다**. 이는 포드 내에서 실행 중인 애플리케이션을 쉽게 디버깅할 수 있도록 하기 위한 것이지만, 공격자는 이를 악용하여 포드 내의 흥미로운 (예: DB) 또는 취약한 애플리케이션 (웹?)에 접근할 수 있습니다:
이 권한은 **하나의 로컬 포트를 지정된 포드의 하나의 포트 포워딩할 수 있게 해줍니다**. 이는 포드 내에서 실행 중인 애플리케이션을 쉽게 디버깅할 수 있도록 하기 위한 것이지만, 공격자는 이를 악용하여 포드 내의 흥미로운 (예: DB) 또는 취약한 애플리케이션 (웹?)에 접근할 수 있습니다:
```
kubectl port-forward pod/mypod 5000:5000
```
### 호스트 쓰기 가능한 /var/log/ 탈출
[**이 연구에서 언급된 바와 같이**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), **호스트의 `/var/log/` 디렉토리가 마운트된** 포드에 접근하거나 생성할 수 있다면, **컨테이너에서 탈출할 수 있습니다**.\
이는 기본적으로 **Kube-API가 컨테이너의 로그를 가져오려고 할 때** (`kubectl logs <pod>` 사용) **포드의 `0.log`** 파일을 **Kubelet** 서비스의 `/logs/` 엔드포인트를 사용하여 요청하기 때문입니다.\
이는 기본적으로 **Kube-API가 컨테이너의 로그를 가져오려고 할 때** ( `kubectl logs <pod>` 사용) **포드의 `0.log`** 파일을 **Kubelet** 서비스의 `/logs/` 엔드포인트를 사용하여 요청하기 때문입니다.\
Kubelet 서비스는 기본적으로 **컨테이너의 `/var/log` 파일 시스템을 노출하는** `/logs/` 엔드포인트를 노출합니다.
따라서 **컨테이너의 /var/log/ 폴더에 쓰기 접근 권한이 있는** 공격자는 이 행동을 가지 방법으로 악용할 수 있습니다:
따라서 **컨테이너의 /var/log/ 폴더에 쓰기 접근 권한이 있는** 공격자는 이 행동을 2가지 방법으로 악용할 수 있습니다:
- 컨테이너의 `0.log` 파일을 수정하여 (보통 `/var/logs/pods/namespace_pod_uid/container/0.log`에 위치) **예를 들어 `/etc/shadow`를 가리키는 심볼릭 링크**로 만들 수 있습니다. 그러면 다음과 같이 호스트의 shadow 파일을 유출할 수 있습니다:
```bash
@@ -219,7 +219,7 @@ kubectl logs escaper --tail=2
failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n"
# Keep incrementing tail to exfiltrate the whole file
```
- 공격자가 **`nodes/log`를 읽을 수 있는 권한을 가진 주체**를 제어하는 경우, 그는 단순히 `/host-mounted/var/log/sym`에 `/`에 대한 **symlink**를 생성할 수 있으며, **`https://<gateway>:10250/logs/sym/`에 접근할 때 호스트의 루트** 파일 시스템을 나열할 수 있습니다 (symlink를 변경하면 파일에 대한 접근을 제공할 수 있습니다).
- 공격자가 **`nodes/log`를 읽을 수 있는 권한**을 가진 주체를 제어하는 경우, 그는 `/host-mounted/var/log/sym`에 `/`에 대한 **symlink**를 생성할 수 있으며, **`https://<gateway>:10250/logs/sym/`에 접근할 때 호스트의 루트** 파일 시스템을 나열할 수 있습니다 (symlink를 변경하면 파일에 대한 접근이 가능할 수 있습니다).
```bash
curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
<a href="bin">bin</a>
@@ -231,11 +231,11 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
<a href="lib">lib</a>
[...]
```
**실험실 자동화된 익스플로잇은** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)에서 찾을 수 있습니다.
**실험실 자동화된 익스플로잇은** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)에서 찾을 수 있습니다.
#### readOnly 보호 우회 <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
운이 좋다면, 고급 권한을 가진 `CAP_SYS_ADMIN` 기능이 사용 가능할 , 폴더를 rw로 다시 마운트할 수 있습니다:
운이 좋다면, 고급 권한을 가진 `CAP_SYS_ADMIN` 기능이 사용 가능할 경우, 폴더를 rw로 다시 마운트할 수 있습니다:
```bash
mount -o rw,remount /hostlogs/
```
@@ -312,13 +312,14 @@ https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
```
### Listing Secrets
**비밀을 나열할 수 있는 권한은 공격자가 실제로 비밀을 읽을 수 있게 할 수 있습니다** REST API 엔드포인트에 접근하여:
**비밀 목록을 나열할 수 있는 권한은 공격자가 실제로 비밀을 읽을 수 있게 할 수 있습니다** REST API 엔드포인트에 접근하여:
```bash
curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
```
### Creating and Reading Secrets
Kubernetes의 **kubernetes.io/service-account-token** 유형의 비밀은 serviceaccount 토큰을 저장하는 특별한 종류의 비밀입니다. 비밀을 생성하고 읽을 수 있는 권한이 있고 serviceaccount의 이름을 알고 있다면, 다음과 같이 비밀을 생성한 후 피해자의 serviceaccount 토큰을 훔칠 수 있습니다:
Kubernetes의 **kubernetes.io/service-account-token** 유형의 비밀은 serviceaccount 토큰을 저장하는 특별한 종류의 비밀입니다.
비밀을 생성하고 읽을 수 있는 권한이 있고 serviceaccount의 이름을 알고 있다면, 다음과 같이 비밀을 생성한 후 피해자의 serviceaccount 토큰을 훔칠 수 있습니다:
```yaml
apiVersion: v1
kind: Secret
@@ -381,7 +382,7 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
### 비밀 읽기 – 토큰 ID 무작위 대입
읽기 권한이 있는 토큰을 소유한 공격자는 이를 사용하기 위해 비밀의 정확한 이름이 필요하지만, 더 넓은 _**비밀 나열**_ 권한과는 달리 여전히 취약점이 존재합니다. 시스템의 기본 서비스 계정은 나열할 수 있으며, 각 계정은 비밀과 연결되어 있습니다. 이러한 비밀은 이름 구조가 있으며: 정적 접두사 뒤에 무작위의 다섯 자리 알파벳 숫자 토큰(특정 문자를 제외하고)이 옵니다. [소스 코드](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83)에 따르면.
읽기 권한이 있는 토큰을 소유한 공격자는 이를 사용하기 위해 비밀의 정확한 이름이 필요하지만, 더 넓은 _**비밀 나열**_ 권한과는 달리 여전히 취약점이 존재합니다. 시스템의 기본 서비스 계정은 나열할 수 있으며, 각 계정은 비밀과 연결되어 있습니다. 이러한 비밀은 이름 구조가 있으며: 정적 접두사 뒤에 특정 문자를 제외한 무작위 5자리 알파벳 숫자 토큰이 옵니다. 이는 [소스 코드](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83)에 따라 결정됩니다.
토큰은 전체 알파벳 숫자 범위가 아닌 제한된 27자 집합(`bcdfghjklmnpqrstvwxz2456789`)에서 생성됩니다. 이 제한으로 인해 가능한 조합의 총 수는 14,348,907(27^5)로 줄어듭니다. 따라서 공격자는 몇 시간 내에 토큰을 추론하기 위해 무작위 대입 공격을 실행할 수 있으며, 이는 민감한 서비스 계정에 접근하여 권한 상승으로 이어질 수 있습니다.
@@ -389,7 +390,7 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
`certificatesigningrequests` 리소스에서 **`create`** 동사를 가지고 있다면 (또는 최소한 `certificatesigningrequests/nodeClient`에서). **새 노드의** 새로운 CeSR을 **생성**할 수 있습니다.
[문서에 따르면 이 요청을 자동으로 승인하는 것이 가능합니다](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), 따라서 이 경우 **추가 권한이 필요하지 않습니다**. 그렇지 않다면 요청을 승인할 수 있어야 하며, 이는 `certificatesigningrequests/approval`에서 업데이트하고 `signers`에서 리소스 이름 `<signerNameDomain>/<signerNamePath>` 또는 `<signerNameDomain>/*`로 `approve`해야 함을 의미합니다.
[문서에 따르면 이 요청을 자동으로 승인하는 것이 가능합니다](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), 따라서 이 경우 **추가 권한이 필요하지 않습니다**. 그렇지 않다면 요청을 승인할 수 있어야 하며, 이는 `certificatesigningrequests/approval`에서 업데이트하고 `signers`에서 `<signerNameDomain>/<signerNamePath>` 또는 `<signerNameDomain>/*`로 `approve`해야 함을 의미합니다.
모든 필요한 권한이 포함된 **역할의 예**는:
```yaml
@@ -422,7 +423,7 @@ resourceNames:
verbs:
- approve
```
새로운 노드 CSR이 승인되었으므로, 노드의 특별 권한을 **악용**하여 **비밀을 훔치고** **권한을 상승**시킬 수 있습니다.
새로운 노드 CSR이 승인되었으므로, 노드의 특별 권한을 **악용**하여 **비밀을 훔치고** **권한을 상승**시킬 수 있습니다.
[**이 게시물**](https://www.4armed.com/blog/hacking-kubelet-on-gke/)과 [**이 게시물**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/)에서 GKE K8s TLS 부트스트랩 구성은 **자동 서명**으로 설정되어 있으며, 이를 악용하여 새로운 K8s 노드의 자격 증명을 생성한 다음 이를 사용하여 비밀을 훔쳐 권한을 상승시킵니다.\
**언급된 권한이 있다면 같은 작업을 수행할 수 있습니다.** 첫 번째 예제는 새로운 노드가 컨테이너 내부의 비밀에 접근하는 것을 방지하는 오류를 우회합니다. 왜냐하면 **노드는 자신에게 마운트된 컨테이너의 비밀만 접근할 수 있기 때문입니다.**
@@ -481,11 +482,11 @@ groups:
### GKE에서의 권한 상승
**GCP 주체에 K8s 권한을 부여하는 방법은 2가지** 있습니다. 어떤 경우든 주체는 클러스터에 접근하기 위한 자격 증명을 수집할 수 있도록 **`container.clusters.get`** 권한이 필요하며, 그렇지 않으면 **자신의 kubectl 구성 파일을 생성해야** 합니다 (다음 링크를 따르세요).
GCP 주체에 K8s 권한을 부여하는 **2가지 방법** 있습니다. 어떤 경우든 주체는 클러스터에 접근하기 위한 자격 증명을 수집할 수 있도록 **`container.clusters.get`** 권한이 필요하며, 그렇지 않으면 **자신의 kubectl 구성 파일을 생성해야** 합니다 (다음 링크를 따르세요).
> [!WARNING]
> K8s API 엔드포인트와 통신할 때 **GCP 인증 토큰이 전송됩니다**. 그러면 GCP는 K8s API 엔드포인트를 통해 먼저 **주체**(이메일로)가 클러스터 내에 **접근 권한이 있는지** 확인한 다음, **GCP IAM을 통해 접근 권한이 있는지** 확인합니다.\
> 이 중 **하나라도** **참이면**, 응답을 받게 됩니다. **아니면** **GCP IAM을 통해 권한을 부여하라는** 오류가 발생합니다.
> 만약 **어떤** 것이 **참**이라면, 응답을 받을 것입니다. 그렇지 않으면 **GCP IAM을 통해 권한을 부여하라는** 오류가 발생합니다.
그런 다음 첫 번째 방법은 **GCP IAM**을 사용하는 것이며, K8s 권한은 **상응하는 GCP IAM 권한**이 있으며, 주체가 이를 가지고 있다면 사용할 수 있습니다.
@@ -493,7 +494,7 @@ groups:
../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
{{#endref}}
두 번째 방법은 **클러스터 내에서 K8s 권한을 부여하는 것**으로, 사용자를 **이메일**로 식별합니다 (GCP 서비스 계정 포함).
두 번째 방법은 **클러스터 내에서 K8s 권한을 부여하는** 것으로, 사용자를 **이메일**로 식별합니다 (GCP 서비스 계정 포함).
### 서비스 계정 토큰 생성
@@ -505,13 +506,13 @@ groups:
### ValidatingWebhookConfigurations 또는 MutatingWebhookConfigurations
`validatingwebhookconfigurations` 또는 `mutatingwebhookconfigurations`에 대해 `create`, `update` 또는 `patch`의 동사를 가진 주체는 **이러한 webhookconfigurations 중 하나를 생성**하여 **권한을 상승**시킬 수 있습니다.
`validatingwebhookconfigurations` 또는 `mutatingwebhookconfigurations`에 대해 `create`, `update` 또는 `patch`의 동사를 가진 주체는 **권한 상승**을 위해 **이러한 webhookconfigurations 중 하나를 생성할 수** 있습니다.
[`mutatingwebhookconfigurations` 예제는 이 게시물의 이 섹션을 확인하세요](#malicious-admission-controller).
### 권한 상승
다음 섹션에서 읽을 수 있듯이: [**내장된 권한 상승 방지**](#built-in-privileged-escalation-prevention), 주체는 자신이 새로운 권한을 가지지 않고는 역할이나 클러스터 역할을 업데이트하거나 생성할 수 없습니다. 단, **`roles`** 또는 **`clusterroles`**에 대해 **동사 `escalate`**를 가진 경우는 예외입니다.\
다음 섹션에서 읽을 수 있듯이: [**내장된 권한 상승 방지**](#built-in-privileged-escalation-prevention), 주체는 자신이 새로운 권한을 가지지 않고는 역할이나 클러스터 역할을 업데이트하거나 생성할 수 없습니다. 단, **`roles`** 또는 **`clusterroles`**에 대해 **`escalate`** 동사를 가진 경우는 예외입니다.\
그렇다면 그는 더 나은 권한을 가진 새로운 역할, 클러스터 역할을 업데이트/생성할 수 있습니다.
### 노드 프록시
@@ -522,11 +523,11 @@ groups:
../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
{{#endref}}
[**Kubelet API에 인증된 상태로 RCE를 얻는 방법은 여기에서 확인하세요**](../pentesting-kubernetes-services/index.html#kubelet-rce).
[**Kubelet API에 인증된 상태로 RCE를 얻는 방법은 여기**](../pentesting-kubernetes-services/index.html#kubelet-rce)에서 확인할 수 있습니다.
### pods 삭제 + 스케줄링 불가능한 노드
**pods를 삭제**할 수 있는 주체(`pods` 리소스에 대한 `delete` 동사) 또는 **pods를 퇴거**할 수 있는 주체(`pods/eviction` 리소스에 대한 `create` 동사) 또는 **pod 상태를 변경**할 수 있는 주체(`pods/status`에 대한 접근)와 **다른 노드를 스케줄링 불가능하게 만들 수 있는 주체**(`nodes/status`에 대한 접근) 또는 **노드를 삭제**할 수 있는 주체(`nodes` 리소스에 대한 `delete` 동사)와 pod에 대한 제어권을 가진 주체는 **다른 노드에서 pods를 훔쳐** **손상된** **노드**에서 **실행**되도록 할 수 있으며, 공격자는 이러한 pods에서 **토큰을 훔칠** 수 있습니다.
**pods를 삭제**할 수 있는 주체(`pods` 리소스에 대한 `delete` 동사), 또는 **pods를 퇴거**할 수 있는 주체(`pods/eviction` 리소스에 대한 `create` 동사), 또는 **pod 상태를 변경**할 수 있는 주체(`pods/status`에 대한 접근)와 **다른 노드를 스케줄링 불가능하게 만들 수 있는** 주체(`nodes/status`에 대한 접근) 또는 **노드를 삭제**할 수 있는 주체(`nodes` 리소스에 대한 `delete` 동사)와 pod에 대한 제어권을 가진 주체는 **다른 노드에서 pods를 훔쳐** **손상된** **노드**에서 **실행**되도록 할 수 있으며, 공격자는 이러한 pods에서 **토큰을 훔칠** 수 있습니다.
```bash
patch_node_capacity(){
curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
@@ -549,9 +550,9 @@ kubectl delete pods -n kube-system <privileged_pod_name>
Kubernetes는 권한 상승을 방지하기 위한 [내장 메커니즘](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)을 가지고 있습니다.
이 시스템은 **사용자가 역할이나 역할 바인딩을 수정하여 권한을 상승시킬 수 없도록 보장합니다**. 이 규칙의 시행은 API 수준에서 이루어지며, RBAC 인자가 비활성화되어 있을 때도 보호 장치를 제공합니다.
이 시스템은 **사용자가 역할이나 역할 바인딩을 수정하여 권한을 상승시킬 수 없도록 보장합니다**. 이 규칙의 시행은 API 수준에서 이루어지며, RBAC 인자가 비활성화되어 있을 때도 안전 장치를 제공합니다.
규칙은 **사용자가 역할을 생성하거나 업데이트할 수 있는 것은 그 역할이 포함하는 모든 권한을 보유하고 있을 때만 가능하다고 명시합니다**. 또한, 사용자의 기존 권한 범위는 생성하거나 수정하려는 역할의 범위와 일치해야 합니다: ClusterRoles의 경우 클러스터 전체에 대해, Roles의 경우 동일한 네임스페이스(또는 클러스터 전체)에 대해 제한됩니다.
규칙은 **사용자가 역할을 생성하거나 업데이트할 수 있는 것은 그 역할이 포함하는 모든 권한을 보유하고 있을 때만 가능하다고 명시합니다**. 또한 사용자의 기존 권한 범위는 생성하거나 수정하려는 역할의 범위와 일치해야 합니다: ClusterRoles의 경우 클러스터 전체에 대해, Roles의 경우 동일한 네임스페이스(또는 클러스터 전체)에 대해 제한됩니다.
> [!WARNING]
> 이전 규칙에 대한 예외가 있습니다. 주체가 **`roles`** 또는 **`clusterroles`**에 대해 **`escalate`** 동사를 가지고 있다면, 자신이 권한을 가지고 있지 않더라도 역할과 클러스터 역할의 권한을 증가시킬 수 있습니다.
@@ -567,9 +568,9 @@ Rolebindings를 생성할 수 있는 권한은 사용자가 **서비스 계정
### 사이드카 프록시 앱
기본적으로 파드 간의 통신에는 암호화가 없습니다. 상호 인증, 양방향, 파드 .
기본적으로 파드 간의 통신에는 암호화가 없습니다. 상호 인증, 양방향, 파드 대 파드.
#### 사이드카 프록시 앱 생성 <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>
#### 사이드카 프록시 앱 만들기 <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>
.yam 파일을 생성하세요.
```bash
@@ -12,7 +12,7 @@ Kubernetes 환경 내에서 포드를 손상시킨 경우, 현재 K8 환경에
### Service Account Tokens
계속하기 전에 Kubernetes에서 서비스가 무엇인지 모른다면 **이 링크를 따라가 Kubernetes 아키텍처에 대한 정보를 최소한 읽어보는 것을 권장합니다.**
계속하기 전에 Kubernetes에서 서비스가 무엇인지 모른다면 **이 링크를 따라가 Kubernetes 아키텍처에 대한 정보를 최소한 읽어보는 것을 권장합니다.**
Kubernetes [문서](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)에서 인용:
@@ -68,7 +68,7 @@ K8s 환경을 열거하기 위해 필요한 몇 가지 사항은 다음과 같
이 세부 정보를 통해 **Kubernetes를 열거할 수 있습니다**. **API**가 어떤 이유로 **인터넷을 통해 접근 가능**하다면, 해당 정보를 다운로드하고 호스트에서 플랫폼을 열거할 수 있습니다.
그러나 일반적으로 **API 서버는 내부 네트워크에 있습니다**, 따라서 손상된 기계를 통해 **터널을 생성**하여 에서 접근해야 하며, 또는 **`kubectl`** 바이너리를 **업로드**하거나 **`curl/wget/anything`**을 사용하여 API 서버에 대한 원시 HTTP 요청을 수행할 수 있습니다.
그러나 일반적으로 **API 서버는 내부 네트워크에** 있으므로, 손상된 기계를 통해 **터널을 생성**하여 자신의에서 접근해야 하며, 또는 **`kubectl`** 바이너리를 **업로드**하거나 **`curl/wget/anything`**을 사용하여 API 서버에 대한 원시 HTTP 요청을 수행할 수 있습니다.
### Differences between `list` and `get` verbs
@@ -91,7 +91,7 @@ GET /apis/apps/v1/watch/namespaces/{namespace}/deployments/{name} [DEPRECATED]
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments [DEPRECATED]
GET /apis/apps/v1/watch/deployments [DEPRECATED]
```
그들은 스트리밍 연결을 열어 Deployment의 전체 매니페스트를 반환합니다. 매니페스트가 변경되거나 새로 생성될 때마다 반환됩니다.
그들은 변경될 때마다(또는 새로 생성될 때마다) 배포의 전체 매니페스트를 반환하는 스트리밍 연결을 엽니다.
> [!CAUTION]
> 다음 `kubectl` 명령은 객체를 나열하는 방법을 나타냅니다. 데이터를 액세스하려면 `get` 대신 `describe`를 사용해야 합니다.
@@ -109,7 +109,7 @@ alias kurl="curl --cacert ${CACERT} --header \"Authorization: Bearer ${TOKEN}\""
# if kurl is still got cert Error, using -k option to solve this.
```
> [!WARNING]
> 기본적으로 pod는 **`kubernetes.default.svc`** 도메인 이름에서 **kube-api 서버**에 **접근**할 수 있으며, **`/etc/resolv.config`**에서 kube 네트워크를 수 있습니다. 여기에서 kubernetes DNS 서버의 주소를 찾을 수 있습니다 (같은 범위의 ".1" kube-api 엔드포인트입니다).
> 기본적으로 pod는 **kube-api 서버**에 **`kubernetes.default.svc`** 도메인 이름으로 **접근**할 수 있으며, **`/etc/resolv.config`**에서 kube 네트워크를 확인할 수 있습니다. 여기에서 kubernetes DNS 서버의 주소를 찾을 수 있습니다(같은 범위의 ".1" kube-api 엔드포인트입니다).
### Using kubectl
@@ -150,7 +150,7 @@ kubectl config set-context --current --namespace=<namespace>
{{#endtab }}
{{#endtabs }}
사용자 자격 증명을 훔쳤다면 **로컬에서 구성할 수** 있습니다:
사용자 자격 증명을 훔쳤다면 **로컬에서 구성할 수** 있습니다. 다음과 같은 방법을 사용하세요:
```bash
kubectl config set-credentials USER_NAME \
--auth-provider=oidc \
@@ -231,7 +231,7 @@ kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/clu
### 네임스페이스 가져오기
Kubernetes는 동일한 물리적 클러스터에 의해 지원되는 **다수의 가상 클러스터**를 지원합니다. 이러한 가상 클러스터를 **네임스페이스**라고 합니다.
Kubernetes는 동일한 물리적 클러스터를 기반으로 하는 **다수의 가상 클러스터**를 지원합니다. 이러한 가상 클러스터를 **네임스페이스**라고 합니다.
{{#tabs }}
{{#tab name="kubectl" }}
@@ -309,7 +309,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/deployments/
### Get Pods
Pods는 실제 **컨테이너**로, **실행**될 것입니다.
Pods는 실제 **실행**될 **컨테이너**입니다.
{{#tabs }}
{{#tab name="kubectl" }}
@@ -347,7 +347,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/default/services/
### 노드 가져오기
클러스터 내에 구성된 모든 **노드**를 가져옵니다.
클러스터 내에 **구성된 모든 노드**를 가져옵니다.
{{#tabs }}
{{#tab name="kubectl" }}
@@ -449,7 +449,7 @@ k get all --all-namespaces -l='app.kubernetes.io/managed-by=Helm'
{{#endtab }}
{{#endtabs }}
### **Pod 소비 확인하기**
### **Pod 소비량 가져오기**
{{#tabs }}
{{#tab name="kubectl" }}
@@ -461,11 +461,11 @@ k top pod --all-namespaces
## kubectl을 사용하지 않고 클러스터와 상호작용하기
Kubernetes 제어 평면이 REST-ful API를 노출하므로, HTTP 요청을 수동으로 작성하고 **curl** 또는 **wget**과 같은 다른 도구를 사용하여 보낼 수 있습니다.
Kubernetes 제어 평면이 REST-ful API를 노출하므로, HTTP 요청을 수동으로 작성하고 **curl** 또는 **wget**과 같은 다른 도구를 사용하여 전송할 수 있습니다.
### 포드에서 탈출하기
새 포드를 생성할 수 있다면, 이를 통해 노드로 탈출할 수 있습니다. 이를 위해서는 yaml 파일을 사용하여 새 포드를 생성하고, 생성된 포드로 전환한 다음 노드의 시스템으로 chroot해야 합니다. 기존 포드를 yaml 파일의 참조로 사용할 수 있으며, 이들은 기존 이미지와 경로를 표시합니다.
새 포드를 생성할 수 있다면, 이를 통해 노드로 탈출할 수 있습니다. 이를 위해서는 yaml 파일을 사용하여 새 포드를 생성하고, 생성된 포드로 전환한 다음 노드의 시스템으로 chroot해야 합니다. 이미 존재하는 포드를 yaml 파일의 참조로 사용할 수 있으며, 이들은 기존 이미지와 경로를 표시합니다.
```bash
kubectl get pod <name> [-n <namespace>] -o yaml
```
@@ -549,7 +549,7 @@ volumes:
hostPath:
path: /
```
curl 포드 생성:
curl을 사용하여 포드 생성합니다:
```bash
CONTROL_PLANE_HOST=""
TOKEN=""