patch

flag를 그리는 루틴을 분석하고 가려진 flag를 보이게 해주세요. Reference GDI+ - Win32 apps | Microsoft Docs Graphics Functions - Win32 apps | Microsoft Docs File — x64dbg documentation

dreamhack.io

 

이 문제는 실행하면 아래와 같이 딱 중요한 부분만을 가려놓은 윈도우 GUI 프로그램을 제공한다.

 

문제 설명을 토대로 유추하면.. Graphic 함수를 이용하여 flag를 그리는데, 이 루틴 중 flag를 가리는 부분을 패치하여 플래그를 얻어내는 문제인 것으로 추정된다.

IDA를 통해 문제 파일을 열어보면 Windows GUI 프로그램 국룰 시작 지점인 WinMain 함수를 확인할 수 있다. 그런데 내 IDA는 서버와의 오류 때문에 hex-ray가 되지 않으니 IDA가 찾아준 WinMain의 위치를 이용하여 Ghidra에서 WinMain의 hex-ray 결과를 볼 것이다.

 

아래는 Ghidra에서 분석해준 WinMain 함수의 hex-ray 결과이다.

 

MSDN의 API 문서에서 검색하면 알 수 있겠지만..

32줄의 CreateWindowExW 함수를 이용하여 윈도우 창을 실행하고,

이에 앞서 30줄의 RegisterClassExW 함수를 이용하여 CreateWindowEx 함수에서 사용할 창 클래스를 등록한다. 그렇기에 RegisterClassExW의 매개인자로 들어가는 WNDCLASSEXW 타입의 local_a8 변수의 속성을 18~29줄에서 정의하고 있는 것을 알 수 있다.

처음에는 이렇게 창 클래스 정의하는 부분은 단순 속성이라 생각하고 CreateWindowExW 함수를 이용하여 창을 생성하고 난 이후 if 문 안에서 이루어지는 작업이 그래픽 작업을 하는 부분인줄 알고 헤맸던 것 같다. 그런데 원하는 그래픽 작업 흔적이 명확하게 발견되지 않아 찾는 방식을 바꿨다.

Ghidra의 Symbol Tree 부분을 보면 GDIPLUS.DLL 이라고 그래픽 작업 관련 함수를 포함하는 DLL를 발견할 수 있다. 본 프로그램에서 사용되는 dll과 함수라고 생각하고 이 부분이 참조되고 있는 부분을 찾아나갔다.

 

다 사용되는 것 같긴 했지만, 이 중 GdipDrawLineI 함수에 대한 Reference 내역을 먼저 조회했다.

많은 결과가 나오지만 이 중 가장 첫 번째 항목을 따라갔다.

 

추적 결과 FUN_140001240 함수에서 사용되고 있었으며,

 

이 부분의 Call Tree를 따라가보면

 

다음과 같이 윈도우 창 클래스를 정의하던 부분의 lpfnWndProc 속성에 정의되는 FUN_1400032f0 함수를 통해 Pen 작업이 이루어지고 있음을 알 수 있다.

WNDCLASSEXW클래스의 lpfnWndProc 속성의 경우 창 클래스에 대한 프로시저 포인터를 가진다. 여기에 들어가는 함수는 콜백 함수 형태를 가지며, 윈도우 창에서 사용자에 의한 상호작용이 발생할 경우 이를 어떻게 처리할 것인지를 정의한다. 그렇기 때문에 이 부분에서 창에 보여질 행위 중 하나인 draw 작업이 이루어진 것으로 생각한다.

 

FUN_1400032f0 함수 내부를 살펴보면

BeginPaint 함수와 EndPaint 함수가 있으며, 이 사이에서 GdipAlloc 후 어떤 작업을 수행하고 GdipFree까지 하고 있다. 그 과정에서 FUN_140002c40 함수가 호출되는데, 이 함수의 내부를 살펴보면

 

다음과 같이 반복적으로 특정 함수가 호출하는 작업이 이루어짐을 확인할 수 있다.

아래 코드를 보면 초반에는 FUN_140002b80 함수가 반복적으로 사용되고 있고, 그 이후에 서로 다른 함수가 호출되고 있다.

 

우선 FUN_140002b80 함수의 역할에 대해 보기 위해 내부를 분석했다.

이 함수에서는 GdipCreatePen1 함수 호출 이후 GdipDrawLineI 함수를 이용하여 한번의 직선을 그리고 GdipDeletePen 함수를 이용하여 Pen 작업을 끝낸다.

즉, FUN_140002b80 함수가 한번 실행될 때마다 이 param으로 들어온 값에 따라 한 개의 직선을 그리고 있는 것으로 생각된다.

 

FUN_140002b80 함수 이후에 차례로 나타나는 여러 함수들의 경우는 조금 다른 코드 패턴을 가진다.

그 중 FUN_140002b80 함수 이후로 가장 처음 나타나는 FUN_1400017a0 함수는 다음과 같이 여러 차례의 GdipCreatePen1 - GdipDrawLineI - GdipDeletePen 과정을 가지며, 여러 선을 그리고 있는 것으로 추정된다.

FUN_1400017a0 함수 이후에 나타나는 여러 함수들도 FUN_1400017a0 함수와 같이 여러 개의 선을 그리는 코드를 가진다.

 

따라서 FUN_140002b80 함수와 그 이후에 위치하는 FUN_1400017a0 함수와 같은 함수들이 각각 어떤 선을 그리는지 보기 위해 다시 IDA를 이용하여 해당 위치를 동적 분석하였다.

FUN_140002b80 함수와 FUN_1400017a0 함수에 각각 bp를 걸고 실행시켰다.

 

먼저 처음 호출된 FUN_140002b80 함수의 경우 아래와 같은 선을 그린다.

그리고 그 다음에 호출된 FUN_140002b80 함수 역시 다음과 같은 선을 그린다.

여러 차례 진행되는 FUN_140002b80 함수를 모두 호출하고 나면 다음과 같은 선들이 그려진다.

이 선들이 그려진 곳은 분명 플래그를 가리는 위치이다. 따라서 FUN_140002b80 함수는 플래그를 가릴 때 사용하는 함수로 여길 수 있다.

그리고 그 이후에 bp를 걸었던 FUN_1400017a0 함수를 실행하면 다음과 같이 플래그의 첫글자가 그려진 것을 확인할 수 있다.

이후의 함수들을 모두 호출하면 다음과 같이 모든 플래그가 그려지게 되는 것을 알 수 있다. (비록 가려져 있긴 하지만…)

이를 통해 플래그를 가리는 함수인 FUN_140002b80 함수가 실행되지 않도록 막으면 정상적으로 플래그를 확인할 수 있을 것임을 알았다.

 

패치를 하기 위해 다음과 같은 방안을 생각해보았다.

  1. FUN_140002b80 함수 시작 위치 어셈을 ret로 패치
  2. FUN_140002b80 함수를 call 하는 위치 어셈을 nop으로 패치

IDA로 패치하려니 계속 권한 오류가 떠서 x64dbg로 패치했다.
x64dbg에서 패치하려고 하는 주소로 이동한 후 고안한 방법대로 패치를 진행한다.

 

1. FUN_140002b80 함수 시작 위치 어셈을 ret로 패치

→ 잘 된다.

 

2. FUN_140002b80 함수를 call 하는 위치 어셈을 nop으로 패치

→ 잘된다.

 

사실 두 방법 모두 FUN_140002b80 함수의 실행을 방해한다는 측면에서 같은 방식이긴 하다.

그러나 두번째 방법을 사용할 경우 FUN_140002b80 함수가 실행되는 모든 곳에 대해 패치를 해야하니 더 번거롭기 때문에 굳이 이렇게 할거면 첫 번째 방법이 좀 더 나은 선택지인 것 같다는 생각을 했다.

이렇게 패치를 해도 괜찮은 이유는 다음과 같다.

  1. 본 프로그램이 레지스터를 이용하여 인자를 전달하는 x64 프로그램이고, FUN_140002b80 함수 역시 함수 내에서 스택을 정리하는 fastcall 호출 규약을 사용한다. 그렇기 때문에 함수 실행과 관련하여 스택을 직접 손봐줘야할 필요가 없다.
    다만 함수 내에서 ret를 이용하여 함수를 종료할 경우 함수 내에서 스택을 사용하기 전에 ret를 넣어줘야 가장 최근에 스택에 넣었던 ret 값을 그대로 다시 가져와 원래 위치로 돌아갈 수 있을 것이다.
  2. FUN_140002b80 함수의 리턴값이 코드의 다른 부분에 사용되지 않기 때문에, 별도로 리턴값을 관리해줄 필요 없이 함수 실행만 막으면 된다.

 

1번과 관련하여 잘못 패치를 하는 상황을 재현해보았다.

여기에서는 FUN_140002b80 함수의 프롤로그 이후 사용할 스택 메모리를 확보한 상황에서 스택 정리 없이 곧바로 ret를 넣은 경우이다.

FUN_140002b80 함수의 프롤로그 실행 시 ret 값에 의하면 본 함수 종료 후 rip는 7FF63BC22C71 값을 가지며 함수를 call 했던 코드의 다음 코드로 돌아가야 한다.

그러나 지금과 같이 스택 프레임 확보를 위해 rsp값을 조정해주고 난 상황에서 ret를 이용하여 곧바로 pop rip를 수행하게 될 경우 dummy 값이 rip로 들어가 이후 정상적인 프로그램 실행에 문제를 일으키게 된다.

대게 사용 중인 저장 장치를 덤프 떠보게 되면 다음과 같은 이미지 파일을 획득할 수 있을 것이다.

 

그리고 이를 FTK Imager와 같은 이미지 분석 도구를 이용하여 확인할 경우 아래와 같은 광경을 보게 될 것이다.

이 중 실제 USB 내 데이터를 확인할 수 있는 위치는 Partition 1의 [root] 폴더이다. 그런데 이 이미지 파일에는 실제 저장된 데이터에 대한 정보 이외에 FAT32 파일 시스템과 관련된 것으로 추측되는 파일들도 있었고, 아래 사진과 같이 File List로는 확인되는 것이 없으나 이미지 파일 자체의 시작 오프셋 위치에서 별도의 hex값도 확인할 수 있었다.

 

여러 차례 이미지 파일 분석을 돌려보는 과정에서 대체 이 내부의 구조가 어떻게 되어 있길래 이러한 구성을 갖게 되는 것일지 궁금했다. 그리고 이러한 궁금증을 해결하기 위한 리서칭 중 답은 저장 장치의 구조와 관련이 있을 것으로 파악하고 이를 공부하고자 이번 포스트를 작성하게 되었다.


Storage Structure

저장 장치는 기본적으로 다음과 같은 형태를 가진다.

이 구조는 파티션 관리를 위해 MBR을 사용하는 경우에 해당하는 구조이지만, 후반부에 정리된 GPT를 사용하는 구조에서는 조금 다른 형태의 구조를 볼 수 있다. 그럼에도 크게 “저장장치 구조” 라는 범주로 보았을 때, 저장장치 부트 과정에 관여하면서 파티션에 대한 정보를 저장하는 파트와 각 파티션 별로 데이터를 저장하는 파트로 구성되는 점은 공통적으로 확인되었다.

 

MBR(Master Boot Record)

MBR은 저장장치 단위로 제일 앞에 한번 위치한다. MBR에서는 저장장치가 사용되기 위해 필요한 정보들이 저장되어 있는데, 크게 Boot Code와 Partition Table로 이루어져 있다.

MBR의 파티션 테이블의 경우 최대 4개의 primary partition만 생성 가능한 구조로 이루어져 있다는 점에서 MBR이 GPT로 대체된 이유를 알 수 있다.

MBR의 세부적인 구조는 글의 중반부에서 별도로 다루어진다.

MBR Slack

MBR과 파티션의 VBR이 존재하는 위치 사이에 있는 여유 공간을 가리킨다. 이 공간은 말그대로 여유 공간이기 때문에 악성 코드에 의해 악용되기도 하는 공간이다.

VBR(Volume Boot Record)

VBR은 각 볼륨이 시작될 때 한번씩 위치하는 부분이다. VBR은 해당 볼륨에 액세스 하기 위한 정보를 가지고 있는데, 여기에는 파일 시스템 타입, 부트 코드, 에러 메세지 등이 포함된다. MBR의 파티션 테이블을 통해 부팅 가능한 파티션에 접근하게 되고, 그 후 VBR이 실행된다.

Volume Data

각 볼륨의 데이터가 저장되는 부분이다. 각 볼륨 마다 지정된 파일 시스템 형태로 포맷되어 있으며, 이에 저장된 각 파일은 메타 데이터와 파일 데이터 정보를 가진다. 이러한 구조에 따라, directory 탐색 시에는 메타 데이터 정보를 사용하고, 파일 내용에 접근하면서 파일 데이터 정보가 사용된다.


MBR(Master Boot Record)

초기의 저장 장치에서는 정상적인 부팅을 위해 매 저장 장치의 맨 앞에 위치한 MBR을 사용하였다. 이를 이용하여 장치의 부팅 뿐만 아니라 실제 데이터가 저장되어 있는 볼륨에 접근하기 위한 정보도 관리한다.

 

MBR Structure Overview

MBR은 다음과 같은 구조로 이루어져 있다.

가장 처음에 부트 코드가 위치해있고, 그 후에는 장치 내 할당된 파티션의 정보를 가진 Partition Table이 위치한다. 이러한 구조를 이용하여 BIOS의 POST(Power On Self Test) 단계 이후 Bootstrap 실행 시 MBR 내 저장된 부트 코드를 읽어올 수 있다.

부트 코드를 위해 할당된 446 바이트 이후에는 곧바로 파티션 테이블이 위치한다. MBR에서 파티션 테이블이 차지하는 크기는 총 64바이트인데, 각 테이블에 대한 정보를 16바이트 크기로 저장한다. 이에 따라 MBR을 채용한 저장 장치의 경우에는 최대 4개의 테이블만을 가질 수 있게 된다.

부트 코드와 파티션 테이블에 이어 2바이트 크기의 Signature를 확인할 수 있다. 이 값은 16진수로 55 AA 값을 가지며 MBR의 끝을 가리킨다.

 

Partition Table entry

각 파티션을 가리키기 위해 사용되는 파티션 테이블의 entry는 다음과 같은 구조로 이루어져 있다.

Offset 0x0 에 위치하는 Boot Flag는 1바이트의 크기를 가지는 필드이며, 해당 파티션에 할당된 볼륨이 부팅 가능한 상태인지 불가능한 상태인지를 나타낸다. 이 값이 0x80일 경우에는 부팅 가능 상태, 0x00일 경우에는 부팅 불가능한 상태를 가리킨다.

Offset 0x1과 0x5에 위치하며 총 3바이트의 크기로 각각 시작 CHS 주소와 끝 CHS 주소를 가지는 필드가 있다. 이들은 파티션의 위치를 CHS 주소 지정 방식을 사용하여 나타낼 경우에 파티션이 위치하는 처음과 끝 주소를 나타낸다.

Offset 0x4 위치에는 1바이트의 크기를 사용하여 파티션의 유형을 나타내는 필드가 있다. 각 파티션 유형에 따른 값은 아래 링크를 참조하여 알 수 있다.

 

Partition type - Wikipedia

From Wikipedia, the free encyclopedia Table inside a master boot record The partition type (or partition ID) in a partition's entry in the partition table inside a master boot record (MBR) is a byte value intended to specify the file system the partition c

en.wikipedia.org

Offset 0x8 위치에는 4바이트의 크기로 시작 LBA 주소를 가지는 필드가 있다. 이 필드는 CHS 주소 지정 방식과는 다른 LBA 주소 지정 방식을 사용할 경우의 파티션 시작 위치 주소를 가진다.

이 필드를 사용하여 파티션의 위치를 참조할 경우 파티션의 끝 위치는 Offset 0xC에 있는 필드값을 사용하여 알 수 있다. 이 필드는 해당 파티션에 할당된 크기를 나타내는 필드로 활용될 수 있는데, 정확히는 해당 파티션 내에서 사용 가능한 sector의 개수를 의미하는 필드이다.

이 필드는 4바이트로 표현됨에 따라 한 파티션에서 사용 가능한 sector의 최대 개수가 2^32 개가 되며, 한 sector는 512바이트의 크기를 갖는 것에 따라 계산해보면… 한 파티션 당 최대 2TB의 크기만을 가질 수 있게 된다.


GPT(GUID Partition Table)

GPT는 MBR의 한계를 해결하고자 등장한 구조이다. 최근의 대부분 PC에서는 GPT를 지원하고 있고 BIOS의 개선된 펌웨어인 EFI에서도 GPT를 지원하고 있다. MBR의 한계는 MBR 파트를 통해서도 설명했지만 이를 다시 한번 정리하면 다음과 같다.

  • 최대 4개의 primary partition 생성 가능
  • 각 파티션 당 최대 2TB의 크기 할당 가능

 

이러한 한계를 GPT는 다음과 같이 개선하였다.

  • 최대 128개의 primary partition 생성 가능
  • 각 파티션 당 최대 8ZB의 크기 할당 가능

 

뿐만 아니라 GPT는 MBR과는 달리 파티션 정보 이외에 디스크에 대한 다양한 정보들도 함께 저장한다는 특징을 가진다.

 

GPT Structure Overview

GPT를 채용한 저장 장치의 경우 다음과 같은 구조를 가진다. 앞서 MBR 사용 시 구조에서 몇 가지 사항이 추가된 것을 확인할 수 있다.

https://en.wikipedia.org/wiki/GUID_Partition_Table

GPT는 각 부분을 sector(512바이트) 단위로 할당하여 사용한다.

GPT의 본격적인 구조는 Primary GPT Header 부터 이며, 그 전에 위치한 Protective MBR은 GPT를 지원하지 않는 장치에서 파티션을 접근할 수 있도록 하기 위해 사용된다. 뿐만 아니라 MBR 기반의 legacy 디스크에 의해 GPT 영역이 훼손되는 것을 막기 위한 기능으로도 활용된다. 이 Protective MBR의 경우 항상 LBA0의 위치에 존재한다.

GPT 구조의 하단에서 볼 수 있는 Secondary GPT는 Primary GPT에 문제가 생기는 등의 이슈로 Primary GPT를 사용할 수 없을 때 backup 용으로 사용하기 위한 부분이다.

 

Primary GPT Header

LBA1에 위치한 Primary GPT Header는 Signature 값을 시작으로 각 파티션의 정보만이 아닌 Disk GUID나 파티션 개수, entry 크기 등의 정보를 함께 관리한다.

Primary GPT Header의 세부 구조는 아래와 같다. Primary GPT Header의 크기는 0x5B에 불과하지만 이를 위해 할당된 크기는 0x200이기 때문에 나머지 부분은 0으로 채워져 있다.

 

Partition Table array

Primary GPT Header의 offset 0x48에 위치한 주소를 참조하면 partition table array의 시작 위치를 찾을 수 있다. 각 entry별로 일정한 크기를 가지고 있어 순차적으로 각 파티션의 정보를 조회할 수 있다.

Partition Table array의 각 entry의 세부 구조는 아래와 같다.

GPT의 이름이 가진 의미를 여기서 확인할 수 있다. GPT는 파티션 유형 별 GUID를 사전에 정해두고 각 파티션에 해당하는 GUID를 entry에 기입한다. 파티션 유형별로 구분짓기 때문에 같은 유형의 서로 다른 파티션이라고 하더라도 Partition Type GUID 필드는 같은 값을 가지게 된다.

물론 GPT에는 Partition Type GUID와는 별도로 각 Partition에 고유한 GUID도 부여한다. 이를 통해 같은 유형의 파티션이라고 하더라도 각각의 파티션을 구분할 수 있게 된다.

Partition type GUID에 기록될 수 있는 유형의 파티션과 이에 매칭되는 GUID는 아래 링크에서 확인할 수 있다.

 

GUID Partition Table - Wikipedia

From Wikipedia, the free encyclopedia Computer disk partitioning standard The layout of a disk with the GUID Partition Table. In this example, each logical block is 512 bytes in size and each entry has 128 bytes. The corresponding partition entries are ass

en.wikipedia.org

 

이외에 Partition Table의 entry 내에 존재하는 Attribute flags라는 필드의 경우, 파티션의 세부 속성을 비트 플래그 형태로 표현하고자 하는 필드이다. 이 필드에서 주로 쓰이는 비트 플래그는 다음과 같다.

Bits Name Description
0 Platform required 시스템에 의해 사용되는 파티션. 삭제 또는 수정 시 주의를 요함
1 No Block IO Protocol UEFI에서 이 파티션에 대한 파일 시스템 매핑 작업을 무시하도록 함. 
2 Legacy BIOS bootable  
3-47 Reserved 이후 UEFI specification 버전에서 사용될 수 있음을 고려하여 예약된 영역
48-63 Partition type에 따라 다르게 사용 PartitionTypeGUID의 소유자만이 사용할 수 있도록 할당해둔 영역

 

이 중 Bit 48-63이 일부 type에서 활용되는 예시는 다음과 같다.

Microsoft 사의 Basic Data Partition

Bits Name
60 Read-only
61 Shadow copy
62 Hidden
63 No drive letter (not automount)

 

ChromeOS kernel Partition

Bits Name
48-51 Priority
0: not bootable, 1~15(highest)
52-55 Tries remaining
56 Successful boot flag

 

 

Prefetch 개요

프리패치는 Windows 운영체제에서 소프트웨어 활동과 관련된 정보를 저장하기 위해 사용하는 메모리 관리 기법 중 하나이다. 이를 사용할 경우 자주 사용될 프로그램들을 미리 메모리에 로드해두기 때문에 더 빠른 실행이 가능하다.

프리패치는 파일 형태로 데이터를 저장하는데, 이렇게 저장된 파일은 다음의 용도로 활용될 수 있다.

  • Windows 및 응용 프로그램 시작 성능 향상
  • 응용 프로그램(바이러스)의 행위 연구, 포렌식 분석

 

물론 prefetch의 동작 방식 때문에 오히려 불필요하게 RAM을 사용하게 될 수 있어 이미 PC 성능이 좋거나 SSD를 사용하고 있는 경우에는 RAM 공간 확보를 위해 비활성화를 추천하기도 한다.

그렇기에 prefetch는 무조건 활성화되어 있지 않을 수 있으며 다음의 레지스트리 경로를 이용하여 prefetch 활성화 여부를 확인할 수 있다.

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters [EnablePrefetcher]

EnablePrefetcher의 값은 0~3 중 하나로 설정할 수 있으며, 각각의 값은 다음과 같은 의미를 가진다.

  • 0: Prefetch 사용 안함
  • 1: ALP만 사용
  • 2: BP만 사용
  • 3 (기본값): ALP와 BP 모두 사용

 

여기에서 확인할 수 있듯이 prefetch에는 다음의 두 가지 유형이 존재한다. 기본적으로 두 가지를 모두 사용하도록 설정되어 있으나, 필요에 따라 레지스트리의 값을 변경하여 원하는 옵션으로 사용할 수 있다.

  • ALP(Application-Launch Prefetching): 사용자가 자주 사용하는 응용프로그램의 정보를 prefetching 하는 것으로, 응용 프로그램의 실행 속도를 높일 수 있다.
  • BP(Boot Prefetching): 부팅 시 사용하는 파일이나 프로그램의 정보를 prefetching 하는 것으로, 부팅 속도를 높일 수 있다.

 

Prefetching된 데이터는 파일 형태로 저장되어 있다가, 부팅 시 저장해둔 prefetch 파일을 메모리에 로드해두고, 실제 프로그램 사용 시 메모리에서 해당 데이터를 불러와 사용할 수 있게 한다. 저장된 프리패치 파일은 %SystemRoot%\Prefetch 폴더에서 확인할 수 있다.

(Windows 10 기준) Prefetch 폴더 내 저장된 파일 및 폴더 유형은 다음과 같다.

  • ReadyBoot
  • Layout.ini
  • Prefetch Files (.pf)

 

ReadyBoot 폴더는 Boot Prefetch에 필요한 파일들을 저장하는데 사용된다. 매 부팅 시 Trace#.fx 이름으로 부팅에 필요한 파일 및 데이터 정보가 포함된 파일이 생성된다. 이 파일은 ReadyBoot 폴더 내에 생성되며 가장 최근에 생성된 파일을 기준으로 최대 5개까지 저장된다. 이외에도 1개의 rblayout.xin 파일이 ReadyBoot 폴더 내에 저장되는데, 이 파일을 이용하여 ReadyBoot 시 필요한 정보 및 캐시 파일을 관리한다.

 

Layout.ini 파일에서는 프리패치 버전과 프리패치 파일의 목록을 확인할 수 있다. Layout.ini 파일은 부팅이나 응용 프로그램 시 참조되는 순서대로 파일의 경로가 기록되며, 약 3일 마다 내용이 업데이트된다. 그렇기 때문에 실제 Prefetch 폴더에 저장된 prefetch 파일의 저장 여부와 일치하지 않을 수 있으며, 오래전에 실행된 적 있는 파일에 대한 항목도 존재할 수 있다.

 

Prefetch 파일은 한번 이상 실행된 적 있는 응용 프로그램에 대한 데이터가 저장된다. 이러한 점을 이용하여 PC에서 사용자의 응용 프로그램 사용 흔적 또는 악성 프로그램 실행 기록을 추적할 수 있다.

각 프리패치 파일에 포함되는 정보는 다음과 같다.

  • 프리패치 파일의 MAC 타임스탬프
  • 프리패치 파일의 크기
  • 프리패치 파일에 해당하는 프로세스
  • 파일이 실행된 volume 또는 논리 드라이브 경로
  • 프로그램 실행 횟수
  • 프로그램의 마지막 실행 시간에 대한 타임스탬프
  • 프리패치 파일에 의해 로드된 추가 파일

 

여기에서 파일의 생성 시각과 수정 시각 정보는 각각 다음과 같은 의미로 해석될 수 있다.

  • 파일의 생성 시각: exe 프로그램 최초 실행 시각
  • 파일의 수정 시각: exe 프로그램의 마지막 실행 시각

 

프리패치 파일은 Prefetch 폴더 내에 모두 존재하며, prefetch 파일의 개수가 운영체제 별 최대 제한 개수에 도달하면 가장 오래전에 실행된 순으로 파일을 삭제한다. 운영체제별로 유지하는 최대 prefetch 파일 개수는 다음과 같다.

  • Windows XP, 7: 128개
  • Windows 8, 10: 1024개

 

Prefetch File Format

Prefetch 파일의 file format은 파일의 압축 여부에 따라 두 가지 형태를 가진다.

먼저 압축되어 있는 prefetch 파일의 구조는 다음과 같다.

  • Offset 0x00 (4bytes): File Signature (4D 41 4D 04)
  • Offset 0x04 (4bytes): Uncompressed Data Size
  • Offset 0x08 ~: Compressed Data

Prefetch 파일의 자세한 정보를 얻기 위해서는 압축된 내용을 풀어야 한다. Windows prefetch 압축에는 LZXPRESS Huffman 압축 방식이 사용되며, 원본 내용을 보기 위해 Github에서 공유되고 있는 압축 해제 코드를 이용하여 해제하였다.

압축되지 않은 prefetch 파일의 형식은 크게 File Header와 File Body로 구분할 수 있다. File Header는 운영체제에 관계없이 공통된 구조를 가지지만 Body의 경우 운영체제 버전에 따라 서로 다른 형식을 가진다.

  • File Header: offset 0x00 (84bytes)
  • File Body: offset 0x54 ~

 

먼저, 버전에 관계없이 공통되는 부분인 File Header는 다음과 같은 구조를 가진다.

  • Offset 0x00 (4bytes): Format Version (Little-Endian)
  • Offset 0x04 (4bytes): File Signature (53 43 43 41)
  • Offset 0x0C (4bytes): File Size (Little-Endian)
  • Offset 0x10 (60bytes): File Name (실행 파일 이름)
  • Offset 0x4C (4bytes): Prefetch Hash (Prefetch 파일 이름에 기재된 해시값)
    • Prefetch Hash는 실행 파일 경로에 대한 해시값을 가지며 Windows 버전에 따라 서로 다른 해시 함수를 사용한다.
      • Windows XP, 2003: SCCA XP hash function
      • Windows Vista, 10: SCCA Vista hash function
      • Windows 2008, 7, 2012, 8: SCCA 2008 hash function

 

Format Version으로 사용되는 값의 종류는 총 4가지이며, 각각은 다음과 같은 정보를 가리킨다.

  • 0x11: Windows XP, Windows 2003
  • 0x17: Windows Vista, Windows 7
  • 0x1A: Windows 8.1
  • 0x1E: Windows 10

 

Prefetch 파일은 기재된 format version에 따라 서로 다른 구조를 가진다. Windows 11도 Windows 10 비슷한 부분이 많은 운영체제임에 따라 0x1E version을 사용한다. 다음은 각 버전에 따른 전체 Format 구조이다.

 

  • 0x11: Windows XP, Windows 2003

 

  • 0x17: Windows Vista, Windows 7

 

  • 0x1A: Windows 8.1

 

  • 0x1E: Windows 10

 

위 format을 통해 알 수 있는 것과 같이, Windows 10과 8.1의 경우는 최근 실행 시간을 가장 최근 시간을 기준으로 8개까지 저장한다는 특징을 가진다.

여기까지가 각 운영체제별로 가지는 기본적인 prefetch의 파일 포맷이었다. 이후의 내용은 포맷 내 각 필드가 가리키는 값을 추적하는 과정을 정리하였다.

 

File metrics array

각 프리패치 파일별로, 해당 파일을 실행시키기 위해 필요한 다른 파일들을 함께 기록해두는데 이에 대한 내용은 File metrics array로 관리된다. File metrics array 내에 있는 각 entry를 탐색하기 위해서는 File metrics array offset과 Filename strings offset을 필요로 한다.

File metrics array는 File metrics array offset 필드에 정의된 offset 위치에서 시작한다. File metrics array의 각 entry는 일정한 형식을 갖추고 있는데, 이 형식은 운영체제에 따라 약간의 차이를 가진다.

  • 0x11: Windows XP, Windows 2003

  • 0x17, 0x1A, 0x1E: Windows Vista, Windows 7, Windows 8.1, Windows 10

Unknown의 경우는 확실하지 않은 값이므로 그 쓰임을 명시해두지 못했지만
Windows 7, 8, 10에서의 Unknown 간에는 다음과 같은 규칙을 가지고 있음을 확인하였다.

  • Unknown1은 초기값 0에서 시작하여 다음 entry로 넘어갈 때마다 Unknown2 만큼 더해진 값을 갖는다.
  • 2번째 필드와 3번째 필드는 매 entry 내에서 서로 동일한 값을 갖는다.

 

이러한 필드를 제외한 채, Filename string offset과 Filename string number 필드값을 이용하면 각 entry에 해당하는 파일명을 찾을 수 있다. 다음은 Windows 10 환경의 프리패치 파일에서 직접 entry 내 파일명을 확인하기까지의 과정이다.

 

Volumes information

Prefetch 파일을 통해 이 실행 파일이 어느 볼륨에서 실행된 것인지 확인할 수 있으며, 파일에 할당된 file reference를 실행된 볼륨의 데이터와 매핑시켜볼 수 있다.

Volumes information 데이터 추적도 기본 file format의 필드로부터 시작한다. 파일의 시작 지점으로부터 offset 0x6C 위치에서 4바이트 크기의 volume information offset 정보를 확인할 수 있다. 이 offset을 따라가면 volume information entry를 찾을 수 있는데, 여기서의 entry 구조 역시 운영체제 버전에 따라 다르다.

  • 0x11: Windows XP, Windows 2003

 

  • 0x17, 0x1A: Windows Vista, Windows 7, Windows 8.1

 

  • 0x1E: Windows 10

 

다음은 Windows 10 환경의 프리패치 파일에서 직접 entry 내 볼륨 정보를 확인하기까지의 과정이다. 

 

요약

  1. Windows의 Prefetch는 자주 사용될 프로그램들을 미리 메모리에 로드해두어 빠른 실행을 가능하게 하는 메모리 관리 기법 중 하나
  2. 실행된 적 있는 프로그램은 프리패치 파일로 남기 때문에 응용 프로그램(바이러스)에 대한 행위 연구, 포렌식 분석 활용 가능
  3. Prefetch는 비활성화 설정도 가능하기 때문에 무조건 남는 아티팩트가 아니며, 안티 포렌식 목적으로 실행 후 프리패치 파일을 삭제할 수도 있음
  4. 최근 운영체제의 prefetch 파일의 경우 LZXPRESS Huffman 압축이 되어있는 경우가 많아 내용 확인 시 압축 해제 또는 전용 도구 필요

 


참고 자료

 

이번으로 2회차를 맞이하는 랜섬웨어 레질리언스 컨퍼런스에 다녀왔다.
과학기술정보통신부에서 주최하고 한국인터넷진흥원에서 주관하는 컨퍼런스였으며, 9월 12일 화요일 낮에 진행되었다.

 

보통 평일 낮시간은 교육이나 다른 활동을 하느라 바쁘기 마련인데, 갑자기 왜 다녀오겠다는 생각을 했을까?

이유는 생각보다 간단했다.

평소 랜섬웨어에 대한 사전 대응책으로는 데이터 백업을, 사후 대응책으로는 랜선 뽑기만을 알고 있었다. 그런데 이것으로 컨퍼런스를 개최한다는 부분에서 내가 모르는 다른 기막힌 대응책이 있는 것일지에 대한 궁금증이 생겼다.

이에 더해 프로그램 목록에서 발견한 랜섬웨어 무력화 부분과 데이터 복구 전략 파트가 호기심을 자극하였고, 결국 사전등록 첫날 바로 등록 신청을 하게 되었다.

 

 

후기라면..

호기심으로 참석한 컨퍼런스였기에 사전에 랜섬웨어에 대한 많은 정보를 가지고 있었던 상태가 아니었다.

그러나 이번 컨퍼런스를 통해 랜섬웨어의 동작 방식과 암호화 과정 같은 기본적인 내용부터,
랜섬웨어 공격에 의해 암호화된 파일을 랜섬 지불 없이 자체적으로 복구하기 위한 여러 흥미로운 관점들,
그리고 랜섬웨어에 대응하기 위한 정책까지 한 번에 알아갈 수 있었던 유익한 시간이었다.

또한 컨퍼런스에 참석하기 전에 가졌던 호기심과 같이, 결과적으로는 백업을 이중, 삼중으로 해두고 망분리까지 시키는 등... 이미 알고 있는 기본적인 방법부터 충실히 하는 것이 현재로서는 랜섬웨어로부터 자산을 보호할 수 있는 방법이라는 생각을 하게 되었다. 랜섬웨어에 감염되었을 때 이를 자체적으로 복구하기 위한 기술들은 연구가 활발히 이루어지고 있으나 아직 연구 초기 단계이고 한계를 가지는 부분들도 존재한다. 또한 공격자들은 항상 방어자들의 한발 앞에서 새로운 공격 기법, 암호화 기법 등을 시도하기 때문에 좋은 도구를 만들더라도 이것이 안정화되기까지는 사전 방어에 계속 힘쓰는 것이 중요할 것이라 느꼈다.

이번 컨퍼런스를 통해 랜섬웨어에 대한 관심도가 높아져, 향후에 리버싱 공부를 더 하고... 악성코드 분석을 학습하게 된다면 랜섬웨어도 분석해보고 싶다는 생각을 하게 되었다 :)

+ 덧붙이자면.. 랜섬웨어 공격자들의 행태를 보다 보니 단순히 랜섬웨어 공격만 하고 끝나는 게 아니라, 랜섬웨어 공격 이후 시스템에 백도어를 심어 피해자가 공격에 어떻게 대응하는지 지켜보는 경우도 있었다. 피해자가 만일 돈을 지불하려 하지 않고 복구를 하려고 하는 등의 조짐이 보이면 2차 공격을 하기도 한다는데... 이러한 경우도 있기 때문에 보다 더 은밀하고 안전한 방법으로 랜섬웨어에 대응하기 위한 방안이 필요해 보였다. 이렇게 생각하니 레질리언스에 관한 컨퍼런스를 열어 함께 논의하는 장을 만들만한 것 같다는 생각이 들었다!

 

이후 내용은 각 강연 마다 들으면서 메모해 둔 내용들이니, 진행된 내용이 궁금하다면 참고해도 좋을 것 같다. 현장에서는 발표자료를 책자형태로 제작하여 배부해 주었는데 이를 별도로 웹 상에도 게시해 줄지는 잘 모르겠다..


[세션A] 랜섬웨어 공격에 대한 국내외 대응 동향

랜섬웨어 공격 동향

  • RaaS형 랜섬웨어 생태계
  • 크로스 플랫폼 랜섬웨어 다수 발견
  • 주로 GoLang, Rust 언어로 개발
  • 사회 기반 시설, 일상 생활과 밀접한 서비스(콜택시)를 대상으로 공격 타겟 변화

 

랜섬웨어 대응 정책

  • 국외
    • 악의적으로 사용되는 가상회폐 거래소에 대한 제재
    • 랜섬웨어 공격 그룹 자체 무력화
    • 랜섬웨어 관련 범죄자 검거 및 제재

 

  • 국내
    • 국가중요시설-기업-국민 수요자별 선제적 예방
      : 백업 지원, 대응 역량 체크 서비스 지원 등
    • 정보공유-피해지원-수사 등 사고 대응 지원
    • 진화하는 랜섬웨어에 대한 대응 역량 제고
      : 랜섬웨어 공격 형태 분석, 대응 기술력 확보

 

랜섬웨어 복구 방안

랜섬웨어의 주된 특징이 암호 기술을 이용한다는 것에서 착안하여, 암호 기술의 암호학적 취약점에 기반한 분석 진행

  • Magniber, LooCipher, Immuni, Hive v1~v4에 대한 랜섬웨어 복구 분석 사례 소개
  • 이 중 Hive v1 ~ v4의 경우 KISA에서 최초로 복구 도구 개발
  • KISA에서 랜섬웨어 국제 협력 프로젝트인 노모어랜섬(NoMoreRansom, NMR)에 약 160여종의 랜섬웨어 복구 도구 배포 중
  • KISA에서 복구 도구 개발 여부에 대한 검색 서비스 지원 예정

 

앞으로의 방향

  • 매년 400개 이상의 신/변종 랜섬웨어가 발견되고 있어 분석량이 한계치에 도달함
    -> 기존 랜섬웨어와의 유사도 분석을 통해 복구, 분석 자동화 도구 개발
  • 사용자 중심의 피해 복구 지원
  • 랜섬웨어 복구 협력 체계 구축 (레질리언스 확보)

 


 

[세션A] 산업계 랜섬웨어 침해동향과 레질리언스 전략

디지털 환경의 경영 리스크 분석

  • 랜섬웨어 공격 시 문서 유실 문제 뿐만 아니라 문서 유출 문제도 함께 발생
  • 중요 문서가 유출될 경우 이로 인한 리스크가 심각함
  • 향후의 모든 악성코드가 랜섬웨어 형태로 변화할 것이라 전망

 

해킹형 랜섬웨어 공격대상 분석

  • 주공격 대상: 코스피 & 코스닥 상장사
  • 업종별 해킹형 랜섬웨어 공격 대상(2년간): 제조업, 병원, 제약사, 특허, 로펌
  • 해커의 최종 목적: 금전 취득, 사이버 테러

 

2023년 랜섬웨어 공격기법 분석

해킹형 랜섬웨어 공격 프로세스

  1. 악성 메일 / 특정 WEB
  2. 백도어 감염
  3. 내부 공격
  4. 데이터 탈취
  5. 백업 삭제 (RDP를 경유하고, 보안 SW를 제거하여 서버에 접근)
  6. 암호화
  7. 데이터 탈취
  8. 탈취한 데이터를 다크웹에 게시
  9. 탈취된 데이터 구매

 

해킹형 랜섬웨어 공격기법의 기술적 진화

  • RaaS 형태의 플랫폼을 통해 쉽게 랜섬웨어를 구매할 수 있어 일반 해커들도 랜섬웨어 공격을 수행할 수 있다.
  • 서비스 플랫폼을 제작하고 운영하기 위해 그룹형태로 조직을 운영한다. (ex. Conti, LockBit)

 

3단계 랜섬웨어 레질리언스 전략

1단계

  1. 보안 백업 체계 구축
  2. 랜섬웨어 전용백신 구축
  3. 개인사용자 보안수칙 및 주기적 교육

2단계

  1. 회사 정보시스템 보안 취약점 점검
  2. 해킹 시 회사 피해 범위와 법적 문제 시뮬레이션
    : 정보자산 보유현황 실사
  3. 전사 데이터 거버넌스 정책수립 및 시스템 도입
    : 데이터 자산 보유현황 실사

3단계

  1. 제로트러스트 보안전략 방어

 


 

[세션B] 랜섬웨어 무력화를 통한 신속한 감염파일 복구 기술

랜섬웨어의 파일 감염과 협상 과정

1단계: 파일 암호화

  • 대칭키 암호화 기법을 사용하여 파일 암호화

 

2단계: 파일 키 암호화

  • 비대칭키 암호화 기법을 사용하여 파일 암호화에 사용된 키 암호화
  • 복호화를 위한 키 획득을 위해 공격자의 개인키 확보 필요

 

3단계: 협상과 복구

  • 랜섬 지불
  • 공격자의 개인키 내장된 복호화 툴 확보
  • 공격자의 개인키를 이용하여 파일 키 복호화
  • 복호화된 파일 키를 이용하여 파일 복구

 

복제 키를 이용한 감염파일 복구 기술

Key Idea: 랜섬웨어의 파일 암호화 시 사용되는 파일 키를 가로채자

단계

  1. 시스템에 Nubeva Key Sensor 설치
    : 시스템에서 발생하는 신뢰할 수 없는 암호화 작업을 실시간으로 탐지
    - NUBEVA SKI (대칭키 복사 기술) 사용
  2. 파일 키를 식별하고 가로채기
    : 메모리 상에서 파일 암호화 시 사용되는 키 식별 및 가로챔
  3. 랜섬 비용 지불 없이 감염 파일 복구

 

-> 아직 기술적, 상황적 제약 상황이 있어 특허만 있는 상태라고 한다.

 


 

[세션B] 랜섬웨어와 딥/다크웹의 연관성 분석 및 추적

IAB(Initial Access Broker): RaaS 형태의 랜섬웨어 생태계에서 랜섬웨어 구매자 겸 미래의 공격자인 Affiliates가 공격의 첫발을 내딛을 수 있게 해주는 인물

접근 권한 획득 방법

  • 다크웹에서 구매
  • Stealer campaign
  • 취약점 이용(ex. Conti, Groove 유출 사이트)
  • Phishing campaign
  • 내부자 위협

 

RaaS(Ransomware-as-a-Service)

정의와 개념

  • 랜섬웨어를 개발하고 배포하기 위한 서비스 모델
  • 랜섬웨어 개발에 필요한 도구와 인프라 제공
  • 웹 플랫폼 형태로 제공되어, 쉽게 랜섬웨어 구매 및 사용 가능

 

제공 기능

  • RaaS 플랫폼
    • 랜섬웨어 개발 및 배포에 필요한 모든 도구와 기능 제공
    • 배포 시 스팸 메일, 악성 링크, exploit kit 등 다양한 공격벡터 사용
    • 결제 처리 및 금전 거래 관리, 해독 키 관리, 복호화 서비스 등의 기능 제공

 

  • 구독자
    • 랜섬웨어의 설정, 암호화 방법, 대상 시스템 및 암호 해독 키 관리 등 설정 가능

 


 

[세션B] 블록체인(가상자산)을 통해 바라본 랜섬웨어 생태계와 온체인 분석의 중요성

블록체인 데이터를 통한 랜섬웨어 동향

  • Big game hunting 형태로 변화, 랜섬웨어 지불액 증가
  • 랜섬웨어 종류의 증가, 수명 감소

 

블록체인 인텔리전스와 식별

  • 가상자산 주소 자체에는 대상을 특정할 수 있는 어떠한 정보도 없다.
  • 오로지 일련의 트랜잭션 단계를 이용하여 식별해야 한다.
  • 이러한 이유로 온체인과 오프체인 정보를 조합하여 온-오프체인 간의 공통 pivot을 추려내 활용해야 한다.
    (온체인 중간에 위치한 정보로는 공격자 식별이 어렵다. 이를 현금화 하는 과정에서 사용된 계정 정보 등을 이용하여 대상을 특정할 수 있다.)

 

블록체인과 사이버 킬체인

  • 암호화폐 중심의 사이버 범죄가 증가함에 따라 공격자들은 가상 자산을 이용하여 킬체인의 각 단계를 수행한다.
  • 온체인에서의 사이버 범죄 TTPs
  • 온체인에서 식별 가능한 랜섬웨어 리브랜딩
  • Initial Access Broker를 식별 가능하게 하는 트랜잭션 형태

 


 

[세션C] 매그니베르 랜섬웨어 분석 사례 및 동향

  • 매그니베르 랜섬웨어의 변종 발생 과정 (매그니베르 역사..?)

 

  • 매그니베르 랜섬웨어에서 백신 우회를 위해 사용하는 기술
    • NTFS 파일 시스템 내 데이터 스트림을 추가하는 방식으로 악성 파일 은폐
    • 파일리스 기법: 정상 프로세스 실행 및 기존 실행되고 있는 프로세스에 악성 DLL 삽입
      -> 취약점 자체에 대한 행위 기반 탐지로 효과적인 탐지 가능
    • 지속성 탐지 우회: 악성 행위 랜덤화 (행위 기반 탐지 우회)

 


 

[세션C] 손실에서 회복까지: 랜섬웨어 공격 이후 데이터 복구 전략

랜섬웨어 감염 후 데이터 특징

  • 전체 암호화 수행
    • 암호화된 파일의 엔트로피 측정 시 원본 파일과 불일치하는 경우가 많아 비교 및 분류 가능
  • 간헐적 암호화 수행
    • 암호화된 파일의 엔트로피 측정 시 원본 파일과 엔트로피가 유사
    • 전체 암호화를 진행한 것보다 데이터 암호화 속도가 빠름
    • 최근 랜섬웨어에서 자주 사용되는 암호화 방법 (ex. Black Basta, Hive)
    • 파일 내에서 암호화 영역과 비암호화 영역이 번갈아가며 존재한다. 비암호화 영역의 크기는 해당 파일의 전체 크기와 관계된다.

 

암호학적 데이터 복호화 방안

  • 개인키 획득
  • 고정된 암호키 사용
  • 메모리 내 잔여 데이터 이용
  • 잘못된 알고리즘 사용
  • 취약한 암호 알고리즘 사용

 

시스템적 데이터 복구 방안

  • 백업 기반 데이터 복구
    • 백업이 되어 있던 부분의 데이터만 복구 가능
    • 백업을 했다고 하더라도 공격자에 의해 볼륨 복사본 VSC가 파괴된 경우 복구 불가능

 

  • 파일 시스템 기반 데이터 복구
    • 원본 파일을 덮어씌우는 식으로 암호화하는 방식 -> 복구 불가능
    • 원본 파일을 유지한 채 이를 읽어 암호화한 새로운 파일을 생성하고 원본 파일을 삭제하는 경우 -> 경우에 따라 복구 가능
      : TRIM 또는 삭제 영역의 디스크가 사용되어 다른 데이터로 덮어씌워진 경우 복구 불가
    • 원본 파일을 읽고 암호화한 상태로 덮어씌운 후 원본 파일 삭제 -> 복구 불가능

 

  • 파일 구조 기반 데이터 복구
    • 간헐적 암호화 방식에서 일부 데이터는 암호화되지 않은 상태로 존재함. 이 부분만 추출하여 최대한.. 원본 파일 복구 시도
      : CyberArk 업체의 White Phoenix 도구
    • 복구 가능 범위: word, excel, ppt, zip, pdf
      -> 하나의 파일 내에 여러 파일 데이터가 담긴 형태
      • 온전히 복구되는 것은 아닐테고, 간헐적 암호화 방식 중 비암호화 영역에 운좋게 위치한 데이터에 한해 복구 가능하다.

 

PostgreSQL은 오픈소스 객체-관계형 데이터베이스 관리 시스템(RDBMS)이다. 다양한 기능과 확장성을 지원하여 다양한 응용 프로그램에서 데이터 관리를 위해 사용되는 서비스이다.

테스트 환경은 Ubuntu 20.04이며, 아래 명령어를 사용하여 PostgreSQL을 설치할 수 있다.

$ sudo apt update
$ sudo apt install postgresql postgresql-contrib

설치를 마친 postgreSQL은 기본적으로 localhost에서만 접근 가능하도록 설정되어 있다. 통신 테스트를 위해 외부로부터 들어오는 트래픽을 허용하도록 설정 파일을 수정해야 한다. 시스템 내에서 postgresql.conf 파일을 찾아 파일 내 listen_addresses 값을 아래와 같이 변경한다.

$ sudo nano /etc/postgresql/12/main/postgresql.conf

listen_addresses = "*"

그 후 5432 포트에 대한 방화벽을 설정하고 postgresql을 재시작 하면 서버 구축이 완료된다.

$ sudo ufw allow proto tcp from any to any port 5432
$ sudo systemctl restart postgresql

 

구축된 서버와의 통신을 위해 클라이언트 프로그램으로 python의 ‘psycopg2’ 라이브러리를 사용하였다. 이 라이브러리를 이용하여 postgreSQL 서버에 접속 요청을 보낸 후 응답 결과에 따라 5432 포트에서 서비스 실행 여부를 식별하였다. 테스트를 위해 작성한 코드는 아래와 같다.

코드 작성 시 Connection refused 오류를 반환할 경우 서비스되고 있지 않은 것으로 판단하였으며, 그 이외에 연결 성공하거나 인증 오류가 날 경우에는 서비스 중인 것으로 판단하였다.

import psycopg2

def test_PostgreSQL(server_ip):
	result = ""
    
    try:
    	db = psycopg2.connect(host=server_ip, dbname="testdb",
        					user="postgres", password="password", port=5432)
    except psycopg2.OperationalError as e:
    	message = e.args[0]
        
        if "FATAL:  no pg_hba.conf entry" in message:
        	result = "authentification error"
        elif "Connection refused" in message:
        	result = "no service"
        else:
        	result = "on service"
    return result

if __name__ == "__main__":
	server_ip = "ip address"
    print(test_PostgreSQL(server_ip))

'Penetration testing' 카테고리의 다른 글

서비스 식별: Submissions (587)  (0) 2023.09.01
서비스 식별: SMTPS (465)  (0) 2023.09.01
서비스 식별: HTTPS (443)  (0) 2023.09.01
서비스 식별: LDAP (389)  (0) 2023.09.01

Submissions 서비스에 사용되는 587번 포트는 인증 없이 메일을 전송할 수 있게 하는 SMTP로 인해 발생하는 문제를 해결하고자 사용되는 포트이다. 인증이 필요 없다는 특징을 악용하여 스팸 메일이 늘어나자 이를 막기 위한 정책인 OP25B가 사용되었는데, 이러한 정책으로 인해 오히려 정상적인 사용자의 가용성이 침해되는 경우가 발생하였다. 그리하여 이를 해결하기 위해 587번 포트를 사용해 SMTP를 사용하면서도 인증 과정을 거치도록 하였고 이것으로 보안성을 높이면서 가용성 문제를 해결할 수 있었다. 이러한 이유로 submission 포트 587번은 근본적으로는 SMTP 메일 서비스와 같으며 따라서 SMTP와 비슷한 방법으로 서비스 식별이 가능하다.

메일 서버 구축 방법은 ‘서비스 식별: SMTPS (465)’를 참고하여 진행할 수 있다. 

테스트를 위해 사용한 클라이언트 프로그램은 2.1.26 SMTPS에서 사용한 것과 같은 python의 ‘smtplib’ 라이브러리를 사용하였다. 587번 포트를 이용하여서도 SMTP 프로토콜을 이용해 통신할 수 있다. 테스트 시 사용한 코드는 아래와 같다. SMTP 메소드는 주어진 host, port와 SMTP 연결을 맺기 위한 요청을 보낸다. 따라서 587번 포트에 SMTP 서버가 서비스 중이 아닐 경우 연결을 맺는데 실패하여 에러가 발생한다. 이를 이용하여 SMTP 서버의 서비스 여부를 판단하였다.

import smtplib

def test_Submissions(mail_server):
	try:
    	smtp = smtplib.SMTP(host=mail_server, port=587)
        smtp.quit()
        print('on success')
    except:
    	print('no service')

if __name__ == "__main__":
	server_ip = 'ip address'
    test_Submissions(server_ip)

 

이 과정을 네트워크 패킷 레벨에서 확인하면 다음과 같다.

[그림 1]은 SMTP 서버가 동작 중일 경우에 해당하며, 정상적으로 TCP 3-way handshake를 맺은 후 SMTP 연결을 위한 메시지를 교환하는 것을 확인할 수 있다. [그림 2]는 SMTP 서버가 동작 중이지 않을 경우에 해당하며, TCP SYN 패킷에 대한 응답으로 TCP RST 패킷이 반환되는 것을 볼 수 있다.

그림 1
그림 2

 

'Penetration testing' 카테고리의 다른 글

서비스 식별: PostgreSQL (5432)  (0) 2023.09.01
서비스 식별: SMTPS (465)  (0) 2023.09.01
서비스 식별: HTTPS (443)  (0) 2023.09.01
서비스 식별: LDAP (389)  (0) 2023.09.01

+ Recent posts