Translated ['src/pentesting-ci-cd/pentesting-ci-cd-methodology.md', 'src

2026-07-28 22:51:09 -07:00 · 2025-08-31 08:22:31 +00:00
parent d2a80e707f
commit d4610bc3d0
3 changed files with 176 additions and 45 deletions
@@ -0,0 +1,21 @@
+# Gitblit 보안
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Gitblit 소개
+
+Gitblit은 Java로 작성된 자체 호스팅 Git 서버입니다. 독립 실행형 JAR로 실행되거나 servlet containers에서 동작할 수 있으며, Git over SSH를 위해 Apache MINA SSHD를 사용하는 내장 SSH 서비스를 제공합니다.
+
+## 주제
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## References
+
+- [Gitblit project](https://gitblit.com/)
+
+{{#include ../../banners/hacktricks-training.md}}
@@ -0,0 +1,107 @@
+# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## 요약
+
+CVE-2024-28080은 Apache MINA SSHD와 통합할 때 세션 상태 처리가 잘못되어 Gitblit의 embedded SSH 서비스에서 발생하는 authentication bypass입니다. 사용자 계정에 적어도 하나의 SSH public key가 등록되어 있으면, 공격자는 사용자 이름과 해당 사용자의 public key 중 하나를 알고 있는 경우 private key나 비밀번호 없이 인증할 수 있습니다.
+
+- 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/<username>.keys)
+
+## Root cause (state leaks between SSH methods)
+
+RFC 4252에 따르면 public‑key authentication은 두 단계로 진행됩니다: 서버는 먼저 제공된 public key가 사용자 이름에 대해 허용되는지 확인하고, 클라이언트가 서명으로 응답한 이후에야 사용자를 인증합니다. MINA SSHD에서는 PublickeyAuthenticator가 두 번 호출됩니다: key 허용 시(아직 서명 없음)와 나중에 클라이언트가 서명을 반환한 후입니다.
+
+Gitblit의 PublickeyAuthenticator는 첫 번째, 서명 이전 호출에서 세션 컨텍스트를 변경하여 인증된 UserModel을 세션에 바인딩하고 true를 반환("key acceptable")했습니다. 이후 인증이 password로 폴백될 때 PasswordAuthenticator는 변경된 세션 상태를 신뢰하고 단축 경로로 성공을 반환하여 비밀번호를 검증하지 않았습니다. 결과적으로 동일 사용자에 대해 이전에 public‑key "acceptance"가 있었던 경우, 어떤 비밀번호(비어 있는 값 포함)도 허용되었습니다.
+
+높은 수준의 결함 흐름:
+
+1) 클라이언트가 사용자 이름 + public key를 제시 (아직 서명 없음)  
+2) 서버는 해당 키가 사용자에 속하는 것으로 인식하고 조기에 사용자를 세션에 연결하여 true 반환("acceptable")  
+3) 클라이언트는 서명할 수 없음(비공개 키 없음), 그래서 인증이 password로 폴백  
+4) Password auth는 세션에 이미 사용자 정보가 있는 것을 보고 무조건 성공 반환
+
+## 단계별 익스플로잇
+
+- 피해자의 사용자 이름과 그들의 public key 중 하나를 수집:
+  - GitHub는 공개 키를 https://github.com/<username>.keys 에 노출함
+  - 공개 서버는 종종 authorized_keys를 노출함
+- OpenSSH를 구성하여 public half만 제시하도록 하여 서명 생성에 실패하게 하고, 서버에서 public‑key acceptance 경로를 여전히 트리거하면서 password 폴백을 강제함.
+
+Example SSH client config (no private key available):
+```sshconfig
+# ~/.ssh/config
+Host gitblit-target
+HostName <host-or-ip>
+User <victim-username>
+PubkeyAuthentication yes
+PreferredAuthentications publickey,password
+IdentitiesOnly yes
+IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
+```
+연결한 후 비밀번호 프롬프트에서 Enter 키를 누르세요(또는 아무 문자열을 입력하세요):
+```bash
+ssh gitblit-target
+# or Git over SSH
+GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
+```
+Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.
+
+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
+
+## 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
+
+## 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
+
+## General: 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를 제시 (private key 불필요)
+- 클라이언트가 서명에 실패하게 강제하여 서버가 password로 폴백하게 함
+- password authenticator가 leaked state에서 단축 판단(short‑circuit)하는 동안 임의의 password를 제출
+
+실용 팁:
+
+- Public key harvesting at scale: https://github.com/<username>.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
+
+Related protocol/design notes and literature:
+- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
+- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
+
+## References
+
+- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
+- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
+- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/)
+- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html)
+- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252)
+
+
+{{#include ../../banners/hacktricks-training.md}}
@@ -6,99 +6,102 @@

 ## VCS

-VCS는 **버전 관리 시스템**을 의미하며, 이 시스템은 개발자가 **소스 코드를 관리**할 수 있도록 합니다. 가장 일반적인 것은 **git**이며, 기업들은 보통 다음 **플랫폼** 중 하나에서 이를 사용합니다:
+VCS는 **Version Control System**의 약자로, 개발자가 **소스 코드를 관리**할 수 있게 해줍니다. 가장 일반적인 것은 **git**이며 보통 다음과 같은 **플랫폼** 중 하나에서 사용됩니다:

 - Github
 - Gitlab
 - Bitbucket
 - Gitea
- 클라우드 제공업체 (자체 VCS 플랫폼 제공)
+- Gitblit
+- Cloud providers (they offer their own VCS platforms)
+

 ## CI/CD Pipelines

-CI/CD 파이프라인은 개발자가 **코드 실행을 자동화**할 수 있도록 하여, 애플리케이션을 빌드, 테스트 및 배포하는 다양한 목적을 수행합니다. 이러한 자동화된 워크플로우는 **특정 작업**(예: 코드 푸시, 풀 리퀘스트 또는 예약된 작업)에 의해 **트리거**됩니다. 이는 개발에서 프로덕션으로의 과정을 간소화하는 데 유용합니다.
+CI/CD pipelines는 개발자가 애플리케이션을 빌드, 테스트, 배포하는 등 다양한 목적을 위해 **코드 실행을 자동화**할 수 있게 합니다. 이러한 자동화된 워크플로우는 코드 푸시, 풀 리퀘스트 또는 예약 작업과 같은 **특정 동작에 의해 트리거**됩니다. 이는 개발에서 운영까지의 과정을 간소화하는 데 유용합니다.

-그러나 이러한 시스템은 **어딘가에서 실행**되어야 하며, 보통 **코드를 배포하거나 민감한 정보에 접근하기 위해 권한이 있는 자격 증명**이 필요합니다.
+하지만 이러한 시스템은 **어디선가 실행되어야 하며**, 일반적으로 **코드를 배포하거나 민감한 정보에 접근하기 위한 권한이 있는 자격증명으로 실행**됩니다.

 ## VCS Pentesting Methodology

 > [!NOTE]
-> 일부 VCS 플랫폼이 이 섹션을 위한 파이프라인 생성을 허용하더라도, 우리는 소스 코드 제어에 대한 잠재적 공격만 분석할 것입니다.
+> 일부 VCS 플랫폼이 이 섹션을 위해 파이프라인을 생성하도록 허용하더라도, 여기서는 소스 코드의 제어에 대한 잠재적 공격만 분석합니다.

-프로젝트의 소스 코드를 포함하는 플랫폼은 민감한 정보를 포함하고 있으며, 사람들은 이 플랫폼 내에서 부여된 권한에 대해 매우 조심해야 합니다. 공격자가 악용할 수 있는 VCS 플랫폼의 일반적인 문제는 다음과 같습니다:
+프로젝트의 소스 코드를 포함하는 플랫폼에는 민감한 정보가 포함되어 있으므로 플랫폼 내 권한 관리를 매우 신중하게 해야 합니다. 공격자가 악용할 수 있는 VCS 플랫폼 전반의 일반적인 문제는 다음과 같습니다:

- **리크**: 코드에 커밋에서 리크가 포함되어 있고 공격자가 레포에 접근할 수 있다면(공개이거나 접근 권한이 있는 경우), 그는 리크를 발견할 수 있습니다.
- **접근**: 공격자가 **VCS 플랫폼 내 계정에 접근할 수 있다면**, 그는 **더 많은 가시성과 권한**을 얻을 수 있습니다.
- **등록**: 일부 플랫폼은 외부 사용자가 계정을 생성하는 것을 허용합니다.
- **SSO**: 일부 플랫폼은 사용자가 등록하는 것을 허용하지 않지만, 유효한 SSO로 접근하는 것은 허용합니다(예: 공격자가 자신의 github 계정을 사용하여 접근할 수 있습니다).
- **자격 증명**: 사용자 이름+비밀번호, 개인 토큰, ssh 키, Oauth 토큰, 쿠키... 사용자가 어떤 방식으로든 레포에 접근하기 위해 훔칠 수 있는 여러 종류의 토큰이 있습니다.
- **웹훅**: VCS 플랫폼은 웹훅 생성을 허용합니다. 만약 이들이 **보이지 않는 비밀**로 **보호되지 않는다면**, **공격자가 이를 악용할 수 있습니다**.
- 비밀이 없다면, 공격자는 제3자 플랫폼의 웹훅을 악용할 수 있습니다.
- 비밀이 URL에 있다면, 동일한 일이 발생하며 공격자는 비밀을 가집니다.
- **코드 손상:** 악의적인 행위자가 레포에 대해 어떤 종류의 **쓰기** 접근 권한을 가지고 있다면, 그는 **악성 코드를 주입**하려고 시도할 수 있습니다. 성공하기 위해 그는 **브랜치 보호를 우회**해야 할 수도 있습니다. 이러한 행동은 다양한 목표를 가지고 수행될 수 있습니다:
-  - 메인 브랜치를 손상시켜 **프로덕션을 손상**시키기.
-  - 메인(또는 다른 브랜치)을 손상시켜 **개발자 머신을 손상**시키기(개발자들이 보통 테스트, 테라폼 또는 다른 작업을 자신의 머신에서 실행하기 때문).
-  - **파이프라인 손상**(다음 섹션 참조)
+- **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를 우회**해야 할 수 있습니다. 이러한 동작은 다양한 목적을 위해 수행될 수 있습니다:
+  - 메인 브랜치를 손상시켜 **production을 침해**.
+  - 메인(또는 다른) 브랜치를 손상시켜 **개발자 머신을 침해**(개발자들이 테스트, terraform 또는 다른 작업을 저장소 내에서 실행하는 경우).
+- **Compromise the pipeline** (check next section)

 ## Pipelines Pentesting Methodology

-파이프라인을 정의하는 가장 일반적인 방법은 **레포지토리에 호스팅된 CI 구성 파일**을 사용하는 것입니다. 이 파일은 실행되는 작업의 순서, 흐름에 영향을 미치는 조건 및 빌드 환경 설정을 설명합니다.\
-이 파일들은 일반적으로 일관된 이름과 형식을 가지며, 예를 들어 — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), 및 .github/workflows 아래에 위치한 GitHub Actions YAML 파일이 있습니다. 트리거되면, 파이프라인 작업은 선택된 소스(예: 커밋 / 브랜치)에서 **코드를 가져오고**, **CI 구성 파일에 지정된 명령을 해당 코드에 대해 실행**합니다.
+파이프라인을 정의하는 가장 일반적인 방법은 **저장소에 호스팅된 CI 구성 파일**을 사용하는 것입니다. 이 파일은 실행되는 작업의 순서, 흐름에 영향을 미치는 조건 및 빌드 환경 설정을 설명합니다.\
+이 파일들은 일반적으로 일관된 이름과 형식을 가지며 예를 들어 — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), 그리고 .github/workflows 아래의 GitHub Actions YAML 파일들이 있습니다. 트리거되면 파이프라인 작업은 선택된 소스(예: 커밋/브랜치)에서 **코드를 pull**하고, CI 구성 파일에 명시된 **명령을 해당 코드에 대해 실행**합니다.

-따라서 공격자의 궁극적인 목표는 어떤 식으로든 **이 구성 파일을 손상시키거나** **그들이 실행하는 명령을 손상시키는 것**입니다.
+따라서 공격자의 궁극적 목표는 어떻게든 이러한 구성 파일이나 **실행되는 명령**을 **손상시키는 것**입니다.

 ### PPE - Poisoned Pipeline Execution

-Poisoned Pipeline Execution (PPE) 경로는 SCM 레포지토리의 권한을 악용하여 CI 파이프라인을 조작하고 해로운 명령을 실행합니다. 필요한 권한을 가진 사용자는 CI 구성 파일이나 파이프라인 작업에서 사용하는 다른 파일을 수정하여 악성 명령을 포함할 수 있습니다. 이는 CI 파이프라인을 "오염"시켜 이러한 악성 명령의 실행으로 이어집니다.
+The Poisoned Pipeline Execution (PPE) 경로는 SCM 저장소의 권한을 악용하여 CI 파이프라인을 조작하고 해로운 명령을 실행하게 합니다. 필요한 권한을 가진 사용자는 CI 구성 파일이나 파이프라인 작업에서 사용하는 다른 파일을 수정해 악성 명령을 포함시킬 수 있습니다. 이렇게 CI 파이프라인이 "poison"되면 이 악성 명령들이 실행됩니다.

-악의적인 행위자가 PPE 공격을 성공적으로 수행하기 위해서는 다음을 할 수 있어야 합니다:
+악의적 행위자가 PPE 공격을 성공적으로 수행하려면 다음이 필요합니다:

- **VCS 플랫폼에 대한 쓰기 접근 권한**을 가져야 하며, 보통 파이프라인은 푸시 또는 풀 리퀘스트가 수행될 때 트리거됩니다. (접근 권한을 얻는 방법에 대한 요약은 VCS 펜테스팅 방법론을 참조하십시오).
- 때때로 **외부 PR이 "쓰기 접근"으로 간주**된다는 점에 유의해야 합니다.
- 쓰기 권한이 있더라도, 그는 **CI 구성 파일이나 구성에 의존하는 다른 파일을 수정할 수 있는지 확인해야 합니다**.
- 이를 위해 그는 **브랜치 보호를 우회**할 수 있어야 할 수도 있습니다.
+- 일반적으로 파이프라인은 push나 pull request 시 트리거되므로 **VCS 플랫폼에 대한 write access**가 있어야 합니다. (VCS pentesting methodology에서 접근 방법 요약을 확인하세요).
+- 때때로 **외부 PR도 "write access"로 간주될 수 있습니다**.
+- 쓰기 권한이 있더라도 CI 구성 파일 또는 구성에서 의존하는 다른 파일을 **수정할 수 있어야** 합니다.
+- 이를 위해서는 **branch protections를 우회할 수 있어야** 할 수 있습니다.

 PPE에는 3가지 변형이 있습니다:

- **D-PPE**: **직접 PPE** 공격은 행위자가 **실행될 CI 구성** 파일을 **수정**할 때 발생합니다.
- **I-DDE**: **간접 PPE** 공격은 행위자가 **실행될 CI 구성 파일이 의존하는** **파일**을 **수정**할 때 발생합니다(예: 메이크 파일 또는 테라폼 구성).
- **공개 PPE 또는 3PE**: 경우에 따라 파이프라인은 **레포에 쓰기 접근 권한이 없는 사용자**에 의해 **트리거될 수 있습니다**(그들이 PR을 보낼 수 있기 때문).
- **3PE 명령 주입**: 일반적으로 CI/CD 파이프라인은 **PR에 대한 정보로** **환경 변수를 설정**합니다. 만약 그 값이 공격자에 의해 제어될 수 있고(예: PR의 제목) **위험한 장소에서 사용**된다면(예: **sh 명령 실행**), 공격자는 **거기에 명령을 주입할 수 있습니다**.
+- **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 명령 실행**)에서 **사용**된다면 공격자는 그 안에 **명령을 주입**할 수 있습니다.

 ### Exploitation Benefits

-파이프라인을 오염시키는 3가지 변형을 알고 나면, 공격자가 성공적인 악용 후 얻을 수 있는 것들을 살펴보겠습니다:
+PPE의 3가지 변형을 알았으니, 성공적인 악용 후 공격자가 얻을 수 있는 것을 살펴봅시다:

- **비밀**: 앞서 언급했듯이, 파이프라인은 작업을 수행하기 위해 **권한**이 필요하며(코드를 검색하고, 빌드하고, 배포하는 등), 이러한 권한은 보통 **비밀로 부여됩니다**. 이러한 비밀은 일반적으로 **환경 변수나 시스템 내 파일을 통해 접근할 수 있습니다**. 따라서 공격자는 항상 가능한 한 많은 비밀을 유출하려고 할 것입니다.
- 파이프라인 플랫폼에 따라 공격자는 **구성에서 비밀을 지정해야 할 수도 있습니다**. 이는 공격자가 CI 구성 파이프라인을 수정할 수 없다면(**I-PPE** 예를 들어), 그는 **그 파이프라인이 가진 비밀만 유출할 수 있다는 것을 의미합니다**.
- **계산**: 코드는 어딘가에서 실행되며, 실행되는 위치에 따라 공격자는 더 나아가서 피벗할 수 있습니다.
- **온프레미스**: 파이프라인이 온프레미스에서 실행된다면, 공격자는 **더 많은 리소스에 접근할 수 있는 내부 네트워크에 도달할 수 있습니다**.
- **클라우드**: 공격자는 **클라우드의 다른 머신에 접근할 수 있지만**, 또한 **IAM 역할/서비스 계정의 토큰을 유출**하여 **클라우드 내에서 추가 접근을 얻을 수 있습니다**.
- **플랫폼 머신**: 때때로 작업은 **파이프라인 플랫폼 머신 내에서 실행**되며, 이는 보통 **더 이상의 접근이 없는 클라우드 내에 있습니다**.
- **선택**: 때때로 **파이프라인 플랫폼은 여러 머신을 구성**하고 있으며, 만약 CI 구성 파일을 **수정할 수 있다면**, 악성 코드를 실행할 위치를 **지정할 수 있습니다**. 이 경우, 공격자는 아마도 각 가능한 머신에서 리버스 쉘을 실행하여 더 나아가서 악용하려고 할 것입니다.
- **프로덕션 손상**: 만약 당신이 파이프라인 내에 있고 최종 버전이 그로부터 빌드되고 배포된다면, 당신은 **프로덕션에서 실행될 코드를 손상시킬 수 있습니다**.
+- **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**: 파이프라인 내부에 침투해 최종 버전이 거기서 빌드되어 배포된다면, 운영 환경에서 실행될 코드를 **침해할 수 있습니다**.

 ## More relevant info

 ### Tools & CIS Benchmark

- [**Chain-bench**](https://github.com/aquasecurity/chain-bench)는 새로운 [**CIS 소프트웨어 공급망 벤치마크**](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)를 기반으로 소프트웨어 공급망 스택의 보안 준수를 감 audit하는 오픈소스 도구입니다. 이 감사는 전체 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에 따르면 상위 10개의 CI/CD 리스크에 관한 흥미로운 기사: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)

 ### Labs

- 로컬에서 실행할 수 있는 각 플랫폼에서 로컬로 실행하는 방법을 찾아서 원하는 대로 구성하여 테스트할 수 있습니다.
- Gitea + Jenkins 실험실: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- 로컬에서 실행할 수 있는 각 플랫폼에 대해 로컬로 실행하는 방법이 제공되어 원하는 대로 구성하여 테스트할 수 있습니다.
+- 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**는 인프라스트럭처-코드에 대한 정적 코드 분석 도구입니다.
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov**는 infrastructure-as-code에 대한 정적 코드 분석 도구입니다.

 ## References

 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)

+
 {{#include ../banners/hacktricks-training.md}}