GCP - Storage Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
기본 정보:
GCP - Storage Enumstorage.objects.get
이 권한은 Cloud Storage에 저장된 파일을 다운로드할 수 있게 해줍니다. 이는 경우에 따라 민감한 정보가 거기에 저장될 수 있기 때문에 권한 상승을 가능하게 할 수 있습니다. 게다가, 일부 GCP 서비스는 정보를 버킷에 저장합니다:
GCP Composer: Composer 환경을 생성할 때 모든 DAG의 코드가 버킷 안에 저장됩니다. 이 작업들은 코드 안에 흥미로운 정보를 포함할 수 있습니다.
GCR (Container Registry): 컨테이너의 이미지는 버킷 안에 저장되며, 이는 버킷을 읽을 수 있다면 이미지를 다운로드하고 정보 유출 및/또는 소스 코드를 검색할 수 있음을 의미합니다.
storage.objects.setIamPolicy
이 권한을 통해 이 섹션의 이전 시나리오를 남용할 수 있는 권한을 부여할 수 있습니다.
storage.buckets.setIamPolicy
이 권한으로 권한을 수정하는 방법에 대한 예시는 이 페이지를 확인하세요:
GCP - Public Buckets Privilege Escalationstorage.hmacKeys.create
Cloud Storage의 "상호 운용성" 기능은 AWS S3와 같은 크로스 클라우드 상호작용을 위해 설계되었으며, 서비스 계정 및 사용자에 대한 HMAC 키 생성을 포함합니다. 공격자는 상승된 권한을 가진 서비스 계정에 대한 HMAC 키를 생성하여 Cloud Storage 내에서 권한을 상승시킬 수 있습니다. 사용자와 관련된 HMAC 키는 웹 콘솔을 통해서만 검색할 수 있지만, 접근 및 비밀 키는 영구적으로 접근 가능하여 잠재적인 백업 접근 저장소를 허용합니다. 반면, 서비스 계정에 연결된 HMAC 키는 API를 통해 접근할 수 있지만, 생성 후에는 접근 및 비밀 키를 검색할 수 없어 지속적인 접근에 대한 복잡성을 더합니다.
이 방법에 대한 또 다른 익스플로잇 스크립트는 여기에서 찾을 수 있습니다.
storage.objects.create
, storage.objects.delete
= 스토리지 쓰기 권한버킷 내에 새 객체를 생성하려면 storage.objects.create
가 필요하며, 문서에 따르면 존재하는 객체를 수정하려면 storage.objects.delete
도 필요합니다.
클라우드에서 쓸 수 있는 버킷의 일반적인 익스플로잇은 버킷이 웹 서버 파일을 저장하는 경우로, 웹 애플리케이션에서 사용될 새 코드를 저장할 수 있습니다.
Composer는 GCP 내에서 관리되는 Apache Airflow입니다. 여러 흥미로운 기능이 있습니다:
GKE 클러스터 내에서 실행되므로 클러스터가 사용하는 SA에 접근할 수 있습니다.
Composer 환경의 모든 구성 요소(DAG의 코드, 플러그인 및 데이터)는 GCP 버킷 내에 저장됩니다. 공격자가 이에 대한 읽기 및 쓰기 권한을 가지면 버킷을 모니터링하고 DAG가 생성되거나 업데이트될 때마다 백도어가 포함된 버전을 제출하여 Composer 환경이 저장소에서 백도어가 포함된 버전을 가져오게 할 수 있습니다.
이 공격의 PoC를 레포에서 찾을 수 있습니다: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs
Cloud Functions 코드는 스토리지에 저장되며 새 버전이 생성될 때마다 코드는 버킷에 푸시되고 새로운 컨테이너가 이 코드로부터 빌드됩니다. 따라서 새 버전이 빌드되기 전에 코드를 덮어쓰면 클라우드 함수가 임의의 코드를 실행하도록 만들 수 있습니다.
이 공격의 PoC를 레포에서 찾을 수 있습니다: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions
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
버전을 업로드하고 manifest.json
파일을 새 파일 이름, URL 및 해시로 업데이트합니다.
악성 코드를 실행할 수정된 main.py
또는 app.yaml
파일을 업로드하고 manifest.json
파일을 새 파일 이름, URL 및 해시로 업데이트합니다.
이 공격의 PoC를 레포에서 찾을 수 있습니다: https://github.com/carlospolop/Monitor-Backdoor-AppEngine
Google Container Registry는 이미지를 버킷에 저장하며, 이 버킷에 쓸 수 있다면 이 버킷이 실행되는 곳으로 수평 이동할 수 있습니다.
GCR에서 사용하는 버킷은 gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com
와 유사한 URL을 가집니다(최상위 하위 도메인은 여기에서 지정됨).
이 서비스는 더 이상 사용되지 않으므로 이 공격은 더 이상 유용하지 않습니다. 또한, 이 서비스를 대체하는 Artifact Registry는 이미지를 버킷에 저장하지 않습니다.
AWS 해킹 배우고 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우고 연습하기: HackTricks Training GCP Red Team Expert (GRTE)