Korean - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - Storage Privesc

Support HackTricks

Storage

기본 정보:

GCP - Storage Enum

storage.objects.get

이 권한은 Cloud Storage에 저장된 파일을 다운로드할 수 있게 해줍니다. 이는 경우에 따라 민감한 정보가 저장되어 있기 때문에 권한 상승을 가능하게 할 수 있습니다. 게다가, 일부 GCP 서비스는 정보를 버킷에 저장합니다:

  • GCP Composer: Composer 환경을 생성할 때 모든 DAG의 코드가 버킷 안에 저장됩니다. 이 작업들은 코드 안에 흥미로운 정보를 포함할 수 있습니다.

  • GCR (Container Registry): 컨테이너의 이미지는 버킷 안에 저장되며, 이는 버킷을 읽을 수 있다면 이미지를 다운로드하고 정보 유출 및/또는 소스 코드를 검색할 수 있음을 의미합니다.

storage.objects.setIamPolicy

이 권한을 통해 이 섹션의 이전 시나리오를 악용할 수 있는 권한을 부여할 수 있습니다.

storage.buckets.setIamPolicy

이 권한으로 권한을 수정하는 방법에 대한 예시는 이 페이지를 확인하세요:

GCP - Public Buckets Privilege Escalation

storage.hmacKeys.create

Cloud Storage의 "상호 운용성" 기능은 AWS S3와 같은 크로스 클라우드 상호작용을 위해 설계되었으며, 서비스 계정 및 사용자에 대한 HMAC 키 생성을 포함합니다. 공격자는 상승된 권한을 가진 서비스 계정에 대한 HMAC 키를 생성하여 Cloud Storage 내에서 권한을 상승시킬 수 있습니다. 사용자와 관련된 HMAC 키는 웹 콘솔을 통해서만 검색할 수 있지만, 접근 키와 비밀 키는 영구적으로 접근 가능하여 잠재적인 백업 접근 저장소를 허용합니다. 반면, 서비스 계정에 연결된 HMAC 키는 API를 통해 접근할 수 있지만, 생성 후에는 접근 키와 비밀 키를 검색할 수 없어 지속적인 접근에 대한 복잡성을 더합니다.

# Create key
gsutil hmac create <sa-email> # You might need to execute this inside a VM instance

## If you have TROUBLES creating the HMAC key this was you can also do it contacting the API directly:
PROJECT_ID = '$PROJECT_ID'
TARGET_SERVICE_ACCOUNT = f"exam-storage-sa-read-flag-3@{PROJECT_ID}.iam.gserviceaccount.com"
ACCESS_TOKEN = "$CLOUDSDK_AUTH_ACCESS_TOKEN"
import requests
import json
key = requests.post(
f'https://www.googleapis.com/storage/v1/projects/{PROJECT_ID}/hmacKeys',
params={'access_token': ACCESS_TOKEN, 'serviceAccountEmail': TARGET_SERVICE_ACCOUNT}
).json()
#print(json.dumps(key, indent=4))
print(f'ID: {key["metadata"]["accessId"]}')
print(f'Secret: {key["secret"]}')


# Configure gsutil to use the HMAC key
gcloud config set pass_credentials_to_gsutil false
gsutil config -a

# Use it
gsutil ls gs://[BUCKET_NAME]

# Restore
gcloud config set pass_credentials_to_gsutil true

이 방법에 대한 또 다른 익스플로잇 스크립트는 여기에서 찾을 수 있습니다.

storage.objects.create, storage.objects.delete = 스토리지 쓰기 권한

버킷 내에 새 객체를 생성하려면 storage.objects.create가 필요하며, 문서에 따르면 존재하는 객체를 수정하려면 storage.objects.delete도 필요합니다.

클라우드에서 쓸 수 있는 버킷의 일반적인 익스플로잇은 버킷이 웹 서버 파일을 저장하는 경우로, 웹 애플리케이션에서 사용될 새 코드를 저장할 수 있습니다.

Composer

Composer는 GCP 내에서 관리되는 Apache Airflow입니다. 여러 흥미로운 기능이 있습니다:

  • GKE 클러스터 내에서 실행되므로 클러스터가 사용하는 SA는 Composer 내에서 실행되는 코드에 의해 접근 가능합니다.

  • Composer 환경의 모든 구성 요소(DAG의 코드, 플러그인 및 데이터)는 GCP 버킷 내에 저장됩니다. 공격자가 이에 대한 읽기 및 쓰기 권한을 가지고 있다면, 버킷을 모니터링하고 DAG가 생성되거나 업데이트될 때마다 백도어가 포함된 버전을 제출하여 Composer 환경이 저장소에서 백도어가 포함된 버전을 가져오게 할 수 있습니다.

이 공격의 PoC는 다음 리포지토리에서 찾을 수 있습니다: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

  • Cloud Functions 코드는 스토리지에 저장되며, 새 버전이 생성될 때마다 코드는 버킷에 푸시되고 새로운 컨테이너가 이 코드로부터 빌드됩니다. 따라서 새 버전이 빌드되기 전에 코드를 덮어쓰면 클라우드 함수가 임의의 코드를 실행하도록 만들 수 있습니다.

이 공격의 PoC는 다음 리포지토리에서 찾을 수 있습니다: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions

App Engine

AppEngine 버전은 staging.<project-id>.appspot.com 형식의 데이터를 버킷 내에 생성합니다. 이 버킷 내에는 AppEngine 앱의 각 버전별로 폴더가 포함된 ae라는 폴더를 찾을 수 있으며, 이 폴더 내에서 manifest.json 파일을 찾을 수 있습니다. 이 파일은 특정 버전을 생성하는 데 사용해야 하는 모든 파일을 포함하는 json을 포함합니다. 또한, 파일의 실제 이름, GCP 버킷 내의 URL(버킷 내의 파일은 sha1 해시로 이름이 변경됨) 및 각 파일의 sha1 해시를 찾을 수 있습니다.

이 버킷을 사전 점유하는 것은 불가능하다는 점에 유의하십시오. GCP 사용자는 appspot.com 도메인 이름을 사용하여 버킷을 생성할 수 있는 권한이 없습니다.

그러나 이 버킷에 대한 읽기 및 쓰기 접근 권한이 있으면, 버킷을 모니터링하고 변경이 수행될 때마다(새 버전) 가능한 한 빨리 새 버전을 수정하여 App Engine 버전에 연결된 SA의 권한을 상승시킬 수 있습니다. 이렇게 하면 이 코드로부터 생성된 컨테이너가 백도어가 포함된 코드를 실행하게 됩니다.

언급된 공격은 여러 가지 방법으로 수행될 수 있으며, 모두 staging.<project-id>.appspot.com 버킷을 모니터링하는 것으로 시작합니다:

  • AppEngine 버전의 전체 새 코드를 다른 사용 가능한 버킷에 업로드하고 새 버킷 이름과 sha1 해시가 포함된 manifest.json 파일을 준비합니다. 그런 다음, 버킷 내에서 새 버전이 생성될 때 manifest.json 파일을 수정하고 악성 파일을 업로드하기만 하면 됩니다.

  • 악성 종속성 코드를 사용할 수정된 requirements.txt 버전을 업로드하고, 새 파일 이름, URL 및 해시로 manifest.json 파일을 업데이트합니다.

  • 악성 코드를 실행할 수정된 main.py 또는 app.yaml 파일을 업로드하고, 새 파일 이름, URL 및 해시로 manifest.json 파일을 업데이트합니다.

이 공격의 PoC는 다음 리포지토리에서 찾을 수 있습니다: https://github.com/carlospolop/Monitor-Backdoor-AppEngine

GCR

  • Google Container Registry는 이미지를 버킷에 저장하며, 이 버킷에 쓸 수 있다면 나중에 이 버킷이 실행되는 위치로 측면 이동을 할 수 있습니다.

  • GCR에서 사용하는 버킷은 gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com와 유사한 URL을 가집니다(최상위 하위 도메인은 여기에서 지정됨).

이 서비스는 더 이상 사용되지 않으므로 이 공격은 더 이상 유용하지 않습니다. 또한, 이 서비스를 대체하는 Artifact Registry는 이미지를 버킷에 저장하지 않습니다.

참고문헌

HackTricks 지원하기
PreviousGCP - Sourcerepos PrivescNextGCP - Workflows Privesc

Last updated