Information Security

Debug 방식의 API 후킹

leeeeye321 — Thu, 4 Jul 2019 17:56:34 +0900

[ Debug 방식의 API 후킹 ]

디버거(Debugger): 디버깅/후킹 프로그램(hookdbg.exe)

디버기(Debuggee): 디버깅 당하는 프로그램(notepad.exe)

이번에는 디버그 방식으로 API 후킹을 할 것이다. 위의 두 프로세스로 실습을 진행한다.

디버거는 디버깅을 당하는 디버기에 대한 모든 권한을 가지므로 후킹 함수를 쉽게 설치할 수 있다.

notepad는 파일에 내용을 입력하고 저장할 때 WriteFile() API를 사용한다. 이 API를 후킹하여 저장되는 문자열 중 소문자를 대문자로 덮어쓸 것이다.

먼저 notepad의 WriteFile() 시작 주소에 Break Point를 설치하고 메모장에서 문자열을 저장한다.

그리고 스택에서 파라미터를 확인한다. 두 번째 파라미터(ESP+8 : AEE18)가 버퍼의 주소이고, 그 버퍼에는 메모장에서 저장한 문자열이 있다.

이 버퍼를 덮어쓰면 원하는 대로 내용을 변경할 수 있다.

* 버퍼의 주소, PID는 반복된 실습으로 인해 변경됩니다.

디버거(hookdbg.exe)의 코드이다. 메인 함수에서 DebugLoop()를 호출하고 있다.

디버깅을 하면서 후킹의 과정을 확인할 것이다.

[ DebugLoop()의 작업 단계 ]

1) WriteFile() API의 시작에 BP(INT3 명령어, 0xCC)를 설치 == Hook 설치

2) 디버깅 중 INT3 명령어를 만나면 CPU는 디버기 실행을 멈추고 EXCEPTION_BREAKPOINT 예외를 디버거에게 전달

3) 디버거에게 제어를 넘김

4) 작업 수행(여기서는 소문자를 대문자로 바꾸기)

5) WriteFile() API의 시작 첫 번째 바이트 원상 복구 == Unhook

6) 수행한 작업 저장을 위해 한 번 더 WriteFile() 실행

7) 다음의 후킹을 위해 다시 Hook 설치

8) 디버기에게 제어 돌려줌

Ollydbg에서 [F3]을 누르면 파라미터를 주면서 실행할 수 있다.

디버거의 실행 파라미터는 후킹할 프로세스의 PID이므로, notepad를 실행하고 [Process Explorer]에서 PID를 확인한다.

실행 후 메인 함수부터 찾고, 그로부터 DebugLoop()의 시작(4011D0)을 알아냈다.

WaitForDebugEvent(): 디버기에서 디버그 이벤트가 발생할 때까지 대기하는 API

[4011EE]까지 진행하면 스택에서 WaitForDebugEvent()의 파라미터를 확인할 수 있다.

[코드 84] 이벤트가 발생하면 첫번째 파라미터 DEBUG_EVENT 구조체 변수 de(pDebugEvent)에 이벤트 정보를 설정한 후 1을 리턴한다. 이로 인해 while 문에 참이 되어 안으로 들어간다.

DEBUG_EVENT 구조체는 이렇게 생겼고, 발생한 이벤트의 종류에 맞춰서 유니온 멤버(u)가 설정된다.

유니온 멤버는 9개의 구조체로 구성된다.

[88-91] WaitForDebugEvent()를 호출한 후 EVENT_DEBUG 구조체 de 변수(12FF00)에 가보면

dwDebugEventCode의 값이 3으로 설정되어 있다.

결과적으로 첫 번째 if 문은 참이 되어

CREATE_PROCESS_DEBUG_EVENT 이벤트 핸들러 OnCreateProcessDebugEvent()를 호출한다.

OnCreateProcessDebugEvent() 함수이다.

디버기의 프로세스가 시작될 때 호출되는 함수이다. 파라미터로 DEBUG_EVENT 구조체 변수 de를 pde로 전달한다.

[10] GetModuleHandleA(), GetProcAddress()를 호출하여 결과적으로 WriteFile()의 주소를 리턴한다.

[11] memcpy() 함수로 ESI를 EDI에 복사한다.

ESI(Source)는 12FF0C를 가리킨다. u.CreateProcessInfo 구조체 변수이다.

EDI(Destination)은 5라인에서 정의한 CREATE_PROCESS_DEBUG_INFO 구조체 변수 g_cpdi이다.

이 구조체에는 디버기 프로세스 핸들 hProcess 멤버가 존재한다. 이를 통해 디버기의 메모리에 읽기/쓰기 작업을 수행할 수 있다.

[13-14] 일단 ReadProcessMemory() API로 WriteFile()의 첫 번째 바이트(0x6A)를 g_ch0rgByte에 저장한다. BP 설치 후 원상 복구할 때를 위한 것이다.

g_ch0rgByte(40DA64)에 0x6A가 저장되었다.

[16-17] WriteProcessMemory() API를 이용하여 notepad의 WriteFile() 첫 번째 바이트를 0xCC(g_chINT3)로 덮어쓴다.

[19] 여기까지 하면 이제 TRUE를 리턴하고

[108] ContiueDebugEvent() 함수를 만난다. 이 함수는 디버기의 실행을 재개한다.

WriteFile()의 호출을 위해 메모장에 ReverseCore이라고 쓰고 저장했다.

while 문에 의해 다시 WaitForDebugEvent()를 만나게 되고, BP가 설치된 WriteFile()이 호출되었으니 dwDebugEventCode의 값이 1(EXCEPTION_DEBUG_INFO)로 설정된다.

else if 문에 참이 되어 EXCEPTION_DEBUG_EVENT 이벤트 핸들러OnExceptionDebugEvent() 함수가 호출된다.

OnExceptionDebugEvent() 함수이다.

★ WriteFile()의 INT 3 명령어를 만나면 EIP는 WriteFile() 주소 + 1(0xCC, 1바이트)이 되고 제어권이 디버거에게 넘어간다.

원하는 대로 내용을 덮어쓰고 저장하기 위해 EIP를 정상적인 WriteFile() 주소로 변경해야 한다.

그리고 정상적인 WriteFile() 시작 주소로 가서 다시 BP를 만나 버리면 안되므로 BP도 제거해 준다.

[27-30] 발생한 이벤트가 BP인지, WriteFile()에서 발생한 것이 맞는지 if 문 두 개로 확인한다.

[31-32] WriteProcessMemory()를 이용하여 미리 저장해 놓은 0x6A로 첫 번째 바이트를 원상 복구(Unhook)한다.

[36-37] GetThreadContext() API는 ctx에 스레드(g_cpdi.hThread: 디버기의 메인 스레드 핸들)의 CONTEXT를 저장한다.

Windows OS는 멀티 스레드 기반이다. CPU가 모든 스레드를 일정시간 실행하고 넘어가고를 반복하기 때문에 작업의 내용을 백업하는 것이 중요하다. CPU 레지스터 값이 유지되어야 다음 실행이 제대로 이루어지는데, 스레드의 CPU 레지스터 정보를 저장하는 구조체가 CONTEXT 구조체이다. 스레드 하나 당 CONTEXT 구조체 하나를 가진다.

[39-42] 덮어 쓸 버퍼의 주소와 크기가 필요하므로 Context.Esp 멤버를 이용해서 디버기 스택의 파라미터 값을 각각 dwAddrOfBuffer[12FC10], dwNumOfBytesToWrite[12FC14]에 저장한다.

[44] malloc() 함수로 임시 버퍼를 할당한다. 버퍼의 주소를 리턴하여 EAX에 저장(393F18)한다.

[45] 임시 버퍼(393F18~393F23)를 memset() 함수로 0으로 초기화한다.

[47-48] ReadProcessMemory() API로 WriteFile() 버퍼를 임시 버퍼에 읽어온다. 이전에 저장했던 ReverseCore 문자열이 임시 버퍼에 복사되었다.

[52-56] 버퍼의 문자열이 소문자이면 대문자로 변환(-0x20)하여 저장한다. 임시 버퍼를 보면 for 문을 통하여 한 글자씩 변환해가는 과정을 확인할 수 있다.

hookdbg.exe에서 다음과 같이 출력된다.

[60-61] 대문자로 변경된 문자열을 WriteFile() 버퍼에 복사

[63] 임시 버퍼 해제

[65-66] CONTEXT.Eip 멤버를 WriteFile() 시작 주소(7C810E17)로 변경하고 SetThreadContext()를 호출하여 이를 셋팅한다.

[68] ContinueDebugEvent() API를 호출하여 멈췄던 디버기의 실행을 재개한다. WriteFile()이 정상적으로 호출되어 변환한 내용을 저장한다.

[72] 마지막으로 다음의 후킹을 위해 다시 BP(g_chINT3) WriteFile()의 첫 바이트에 써준다(훅 설치).

대문자로 변환되어 저장된 것을 확인한다. 이렇게 디버그 기법으로 API 후킹이 성공했다.

Code Injection

leeeeye321 — Wed, 26 Jun 2019 15:47:39 +0900

[ Code Injection ]

-프로세스에 독립 실행 코드를 삽입한 후 실행하는 기법

-CreateRemoteThread() API를 이용하여 원격 스레드 형태로 실행하므로 Thread 인젝션이라고도 한다.

Windows 메시지 박스를 출력하는 간단한 코드이다.

Ollydbg에서 ThreadProc()를 확인한다.

PUSH 명령어로 MessageBox() API의 문자열 주소를 스택에 저장하고 있다.

1000781C, 10007828 주소는 DLL의 데이터(.rdata) 섹션 영역에 정의된 문자열을 가리킨다.

CALL 명령어의 100060E4 주소는 MessageBox() API의 IAT이다.

DLL 코드에서 사용되는 모든 데이터(파라미터, IAT 등)는 DLL의 데이터(.rdata) 섹션에 위치한다.

이 코드를 DLL로 만들고 다른 프로세스에 삽입하면 코드와 데이터가 같이 메모리에 존재하여 정상적으로 실행이 된다.

하지만 DLL이 아닌 코드(10001000~10001016)만 다른 프로세스에 삽입한다면, 정상적으로 실행되지 않을 것이다.

다른 프로세스에는 1000781C, 10007828, 100060E4에 참조할 데이터가 없기 때문이다.

그래서 Code injection을 위해서는 참조할 데이터까지 인젝션해야 한다.

실습은 간단하다. notepad를 실행시키고, CodeInjection.exe를 실행시키면 notepad에 코드가 인젝션되어 메시지 박스가 출력된다.

이제 Code 인젝션을 위해 구현된 CodeInjection.exe를 봅시다.

위의 코드는 메인 함수에서 호출되는 InjectCode() 함수의 일부분이다. ThreadProc() 스레드 함수에 파라미터로 전달될 값들을 THREAD_PARAM 구조체를 이용하여 셋팅하고 있다.

그리고 API를 호출하여 상대방 프로세스에 메모리를 할당(VirtualAllocExec)하고 데이터(THREAD_PARAM)와 코드(ThreadProc)를 각각 인젝션(WriteProcessMemory)한다. 그리고 원격 스레드를 실행(CreateRemoteThread)시킨다.

이 코드가 인젝션할 코드 ThreadProc()이다.

모든 데이터를 직접 API를 호출하거나 문자열을 정의하지 않고(하드코딩된 주소의 데이터를 참조하지 않고) THREAD_PARM 구조체에 접근해서 사용하고 있다.

코드가 인젝션된 상태의 notepad를 Ollydbg로 보면, ThreadProc()을 확인할 수 있다.

[EBP+8]는 ThreadProc()의 파라미터 lParam으로, InjectCode()에서 열심히 셋팅했던 THREAD_PARAM 구조체를 가리킨다.

이를 ESI에 옮겨 놓고 함수들을 호출할 때 ESI를 기준으로 값에 접근하여 사용한다.

[ESP+8]의 값 960000으로 찾아가보면, THREAD_PARAM 구조체가 나온다.

이렇게 Code 인젝션이 어떻게 구현되는지 살펴 보았다.

Code 인젝션을 사용하는 이유는 DLL로 만들지 않고 코드만 인젝션하기 때문에 메모리를 조금만 차지하고, 흔적을 찾기도 어렵고, 쉽고 편리하게 구현할 수 있기 때문이다.

PE 패치를 이용한 DLL 로딩

leeeeye321 — Fri, 21 Jun 2019 18:16:31 +0900

[ PE 패치를 이용한 DLL 로딩 ]

실행 파일을 직접 수정하여 DLL을 로딩시켜 봅시다.

TextView.exe 파일을 직접 수정하여 실행 시에 myhack3.dll을 로딩하도록 실습을 진행한다.

myhack3.dll은 www.google.com에서 index.html을 다운 받아서 프로세스에 드롭(drop)시키는 기능을 가진다.

PE 파일에서 어떤 DLL을 import한다는 것은 그 DLL이 코드 내에서 제공하는 export 함수를 호출한다는 의미이다.

myhack.dll도 이를 따라 아무런 기능이 없는 dummy라는 export 함수를 정의한다.

TextView.exe는 읽고 쓰는 기능을 가진 단순한 텍스트 뷰어이다.

PEview에서 이 프로세스의 IDT(IMPORT Directory Table)를 확인한다.

import하는 DLL이 각각 IID(IMAGE_IMPORT_DESCRIPTOR) 구조체로 정의되어 있다.

이를 HxD에서 확인하면 14바이트씩 4개의 IID 구조체, 마지막으로 NULL 구조체까지 총 64바이트를 차지하며 myhack3.dll의 구조체를 추가시킬 자리가 없다는 것을 알 수 있다.

IDT 전체를 더 크고 비어있는 영역으로 이동시키고 DLL을 추가해야 한다.

.rdata 섹션의 끝 부분에 Null padding 영역이 있다. 이 부분을 사용하기 전, 메모리에 로딩되는 부분인지 확인해야 한다.

메모리에 로딩되었을 때 섹션의 크기(VirtualSize)는 2C56이다. 파일 크기(Size of Raw Data)는 2E00이고 사용되지 않는 크기는 2E00-2C56=1AA로 기존의 IDT가 위치하기에 문제가 없다.

이제 TextView.exe를 직접 수정해 봅시다.

IMAGE_OPTIONAL_HEADER에서 IMPORT Table 구조체 멤버는 IDT의 위치와 크기를 알려준다.

HxD로 이 값(Offset:160)을 찾아가서 이제부터 IDT의 위치는 .rdata 섹션의 Null padding 영역 8C80이고, 사이즈는 78(64+14)라고 수정한다.

DLL 로딩 속도를 향상시키는 기법인 BOUND IMPORT Table은 옵션이므로 편의상 값을 0으로 만든다.

기존 IDT를 모두 복사한 후 새로 정의한 IDT에 [Paste Write]로 덮어쓰기한다.

IDT가 7E80~7EE3로 인식되었고, 이제 7ED0~7EE0에 myhack.dll의 IID를 구성하면 된다.

IID는 이렇게 생겼다.

7ED0(OriginalFirstThunk)	INT의 RVA(8D00)
7F00	INT(8D30) INT의 각 원소가 가리키는 값은 IMAGE_IMPORT_BY_NAME 구조체 포인터이다.
7F30	IMAGE_IMPORT_BY_NAME 구조체 Ordinal(0000) + function name string(dummy:임포트하려는 함수)
7EDC(Name)	DLL Name의 RVA(8D10)
7F10	DLL Name(myhack3.dll)
7EE0(FirstThunk)	IAT의 RVA(8D20) 실행 시에 PE 로더에 의해 실제 함수의 주소로 덮어쓴다.
7F20	IAT(8D30)

실행 시 IAT는 PE 로더에 의해서 실제 함수로 덮어쓰기 때문에 .rdata 섹션은 WRITE 속성을 가져야 한다.

Characteristics 값에 IMAGE_SCN_MEM_WRITE(80000000) 속성 값을 추가해 준다. 40000040 | 80000000 = C0000040

★ .rdata 섹션에 쓰기 속성 없이 정상적으로 실행하려면?

IAT 영역(6000~6154)에 IAT가 존재하면 된다. 위에서는 임의로 정한 부분에 dummy()의 IAT를 정의했는데,

쓰기 속성을 원래대로 없애고 IAT 영역에 정의해 보겠다.

IAT 영역으로 가서 끝 부분(5354)에 dummy()의 IAT(8D30)를 추가한다.

myhack3.dll의 IID에 가서 IAT의 RVA를 6154(Offset:5354)으로 변경한다. 이렇게 dummy()의 IAT가 IAT 영역에 위치하므로, 쓰기 속성이 없어도 정상적으로 실행될 것이다.

myhack.dll의 IID 구조체 멤버의 값이 설정되었다.

INT를 확인하면 dummy() 함수가 추가되어 있다.

이제 수정을 완료한 TextView.exe을 실행해 본다.

로딩되어 있는 myhack3.dll은 구글의 index.html을 다운받아서 TextView.exe에 드롭시킨다.

구글 사이트인 것을 확인한다. 이렇게 IDT를 수정하여 DLL 인젝션에 성공했다.

DLL Ejection

leeeeye321 — Fri, 21 Jun 2019 16:27:33 +0900

[ DLL Ejection ]

프로세스에 강제로 삽입한 DLL을 빼내는 것

notepad.exe에 myhack.dll을 강제로 인젝션했다가 다시 이젝션해봅시다.

이젝션을 하기 위해서는 CreateRemoteThread()를 사용하여 대상 프로세스가 FreeLibrary() API를 스스로 호출하도록 만들어야 한다.

pThreadProc은 FreeLibrary()의 주소이고, me.modBaseAddr은 이젝션할 myhack.dll의 로딩 주소이다.

일단 인젝션을 하고

확인을 한다.

EjectDll.exe로 이젝션을 시도한다. success.

notepad.exe에서 myhack.dll이 빠져 나갔다. 이젝션은 우리가 강제로 삽입한 dll만 가능하고 일반적으로 로딩되어 있는 dll은 불가능하다.

DLL Injection - Remote Thread 생성 & 레지스트리 이용

leeeeye321 — Thu, 20 Jun 2019 14:17:23 +0900

[ DLL Injection ]

-실행 중인 프로세스에 LoadLibrary() API를 스스로 호출하도록 명령하여 원하는 DLL을 로딩시키는 것

-삽입된 DLL은 이미 프로세스에 로딩되어 있는 다른 DLL과 마찬가지로 프로세스 메모리에 대한 권한을 가지게 된다.

DLL이 로딩되면 DLLMain() 함수가 실행되는데, 이 switch 문에 기능을 개선하거나 버그를 패치하는 등의 사용자가 원하는 코드를 넣을 수 있다.

1. 원격 스레드 생성하여 DLL 인젝션 구현하기 - CreateRemoteThread()

(리버싱 핵심 원리 https://reversecore.com/104)

notepad.exe에 myhack.dll을 인젝션하는 실습을 할 것이다.

myhack.dll이 로딩되면 OutputDebugString()에 의해 해당 문자열을 출력되어 dll이 인젝션되었음을 확인할 수 있고, CreateThread() 함수 호출로 TreadProc 스레드를 실행된다.

ThreadProc의 내용은, URLDownloadToFile() API를 이용하여 DEF_URL(http://www.naver.com/index.html)을 다운받는 것이다.

InjectDll.exe는 DLL 인젝션 유틸리티이다. 코드가 생소하므로 자세히 공부합시다.

OpenProcess()를 이용하여 PROCESS_ALL_ACCESS 권한을 가진 notepad.exe 프로세스 핸들을 얻는다. 이제 이 핸들(hProcess)를 이용하여 해당 프로세스를 제어할 수 있다.

우리는 notepad.exe에게 인젝션 할 dll의 경로를 알려줘야 한다. 일단 VirtualAllocEx()로 해당 프로세스 메모리에 경로 길이만큼의 버퍼를 할당한다. 리턴 값(pRemoteBuf)은 notepad.exe에 할당된 버퍼 주소이다.

그리고 WriteProcessMemory()로 할당한 버퍼에 경로(szDllPath)를 써준다.

우리는 LoadLibraryW를 호출하기 위해 주소를 얻어야 한다.

kernel32.dll(그 외 Windows 핵심 DLL도)은 프로세스마다 같은 주소에 로딩되기 때문에 굳이 notepad.exe에 로딩된 임포트 주소를 구하지 않아도 된다. DLL Injection이 바로 이 취약점을 이용한 것이다.

InejctDll.exe에 로딩되어 있는 kernel32.dll가 소유한 LoadLibraryW()의 주소를 얻는다.

이제 notepad.exe에 LoadLibrary() API를 스스로 호출하도록 명령해야 한다.

우리는 이를 위해 다른 프로세스에게 스레드를 실행시켜주는 함수 CreateRemoteThread()를 사용할 것이다.

* LoadLibrary() API를 호출하도록 해야 하는데 스레드를 실행시키는 함수를 사용하는 이유는,

이렇게 ThreadProc()과 LoadLibrary()가 함수 형태가 똑같기 때문이라고 한다.

CreateRemoteThread() API의 파라미터는 어떻게 설정할까?

lpStartAddress에는 스레드 함수 주소 -> LoadLibrary()의 주소 pThreadProc,

lpParameter에는 스레드 파라미터 주소 -> 인젝션할 DLL 경로의 주소 pRemoteBuf을 넣고 호출하면 된다.

이렇게 소스 코드들을 살펴 보았으니 실습을 해봅시다.

* DebugView - 시스템에서 실행되는 프로세스들이 출력하는 모든 디버그 문자열을 가로채서 보여주는 유틸리티이다.

이것으로 인젝션의 성공을 확인할 수 있다.

1900은 notepad.exe의 PID이다. Dbgview를 실행시켜 놓고, InjectDll.exe를 실행하여 notepad.exe로 DLL 인젝션을 시도한다.

DebugView을 확인해보면, 문자열이 출력되어 있다. 이는 myhack.dll 인젝션이 성공하여 DllMain() 함수의 OutputDebugString() API가 호출된 것이다.

Process Explorer에서 notepad.exe에 로딩된 dll 목록을 확인했다. 역시 myhack.dll을 확인할 수 있다.

notepad.exe에 인젝션된 myhack.dll이 제 기능을 수행하여 index.html이 다운로드되었다.

Naver 페이지 확인

2. 레지스트리 이용하여 DLL 인젝션 구현하기 - AppInit-DLLs

User32.dll은 프로세스에 로딩될 때 레지스트리 항목 AppInt_DLLs를 읽어서 값이 존재하면 LoadLibrary()를 이용하여 사용자 DLL을 로딩한다. 이를 이용하여 AppInt_DLLs에 인젝션을 원하는 DLL의 경로를 입력하고 재부팅을 하면, User32.dll이 로딩된 모든 프로세스에 해당 DLL이 인젝션된다. 그럼 이제 실습을 해봅시다.

myhack2.dll은 자신을 로딩한 프로세스가 notepad.exe이면 IE를 숨김 모드(SW_HIDE)로 실행한다.

실습 파일을 준비하고, cmd에서 레지스트리 에디터 regedit.exe를 실행한다.

AppInit_DLLs가 있는 곳으로 찾아간다. 아래에 나온 긴 경로를 따라 가세요.

값을 인젝션할 dll의 경로로 변경하고 변경 사항을 적용하기 위해서 시스템을 재부팅한다.

재부팅이 되었으면 Process Explorer에서 모든 프로세스에 myhackk2.dll이 인젝션된 것을 확인한다.

notepad를 실행하면 notepad에도 인젝션된다. iexplore.exe가 숨김 속성으로 실행된 것도 확인한다.

이렇게 DLL INJECTION을 두 가지 방법으로 구현해 보았다. 다음에는 DLL EJECTION을 알아 봅시다.

Windows Message Hooking

leeeeye321 — Mon, 17 Jun 2019 20:02:44 +0900

[ DLL Injection - Windows Message Hooking ]

Windows는 Event Driven 방식으로 동작한다. 이벤트가 발생하면 OS는 응용프로그램에게 메시지를 보낸다.

이 메시지가 이동하는 중간에 엿보거나 가로채가는 것을 Message Hook이라고 한다.

메시지 후킹은 DLL 인젝션 기법의 하나로 사용된다.

아래의 파일을 이용하여 후킹 실습을 진행한다.

(리버싱 핵심 원리 https://reversecore.com/104)

HookMain.exe은 KeyHook.dll을 최초로 로딩한 후, SetWindowsHookEx()을 이용하여 훅을 설치하는 프로그램이다.

SetWindowsHookEX()는 훅을 설치하는 API이고, 정의는 위와 같다.

KeyHook.dll에서 확인한 SetWindowsHookEx() API의 호출이다. 첫 번째 파라미터 idHook(훅 타입)의 값은 WH_KEYBOARD로, 키 입력 메시지를 모니터하여 훅을 설치한다.

KeyHook.dll은 내부에 훅 프로시저가 존재한다. 이 dll의 프로시저는, notepad.exe의 메시지를 가로채도록 프로그래밍되어 있다. 키보드 입력이 발생하면 프로세스 이름을 확인하고, notepad.exe(DEF_PROCESS_NAME)과 같다면 1을 리턴하여 KeyboardProc() 함수를 종료시킨다. 결과적으로 키보드 메시지는 notepad 프로세스에게 전달되지 못하여 화면에 아무것도 출력되지 않을 것이다.

이제 이 파일들로 실습을 해봅시다.

HookMain.exe를 실행하면, 시스템에 훅이 설치된다.

설치 후 메모장(notepad.exe)를 실행하고, 키보드를 입력해본다. 인터넷 익스플로러(iexplore.exe)도 실행하고 입력을 발생시켰다. 이제 OS가 이 프로세스들에게 Keyhook.dll을 강제로 로딩했을 것이다.

Process Explorer에서 해당 프로세스에게 KeyHook.dll이 인젝션된 것을 확인할 수 있다.

notepad.exe를 열어서 입력해보면, 메시지가 출력되지 않는다.

q를 눌러 후킹을 종료시킨다.

후킹이 종료되며 dll이 언로딩된 것을 확인했다.

EAT(Export Address Table)

leeeeye321 — Wed, 12 Jun 2019 15:33:48 +0900

EAT(Export Address Table)

라이브러리 파일에서 제공하는 함수를 다른 프로그램에서 가져다 사용할 수 있게 해주는 핵심 메커니즘이다.

IMAGE_EXPORT_DIRECTORY 구조체에 Export 정보가 저장되어 있다.

NumberOfFunctions	실제 Export 함수 개수
NumberOfNames	Export 함수 중에서 이름을 가지는 함수 개수
AddressOfFunctions	Export 함수 주소 배열
AddressOfNames	함수 이름 주소 배열
AddressOfNameOrdinals	Ordinal 배열

EAT를 통해서만 해당 라이브러리에서 Export하는 함수의 시작 주소를 정확히 구할 수 있다.

라이브러리에서 함수 주소를 얻는 API는 GetProcAddress()이다. 이 API가 EAT를 참조하여 원하는 API의 주소를 구한다.

* GetProcAddress()가 함수 이름으로 함수 주소를 얻는 과정

1. AddressOfNames를 이용하여 함수 이름 주소 배열로 간다.

2. 문자열 비교(strcmp)를 통하여 원하는 함수의 이름을 찾는다.

3. AddressOfNameOrdinals 배열을 이용하여 Ordinal 배열로 간다.

4. 2번 배열의 인덱스로 해당 ordinal 값을 찾는다.

5. AddressOfFunctions를 통해 함수 주소 배열(EAT)로 간다.

6. 4번에서 찾은 ordinal을 배열 인덱스로 하여 원하는 함수의 시작 주소를 얻는다.

kernel32.dll(C:\WINDOWS\system32\kernel32.dll)을 이용하여 GetProcAddress()가 EAT를 참조해서 AddConsoleAliasW의 실제 함수 주소를 찾는 과정을 실습할 것이다.

EXPORT 구조체의 시작 주소는 IMAGE_OPTIONAL_HEADER32.DataDirectory[0].VirtualAddress에 나와 있다.

PEview를 통해 확인해보면 값은 262C(RVA)이고, 이를 RAW로 변환하면 262C-1000+400=1A2C이다.

Offset	Member	Value	RAW
1A38	Name	00004B98	4B98 - 1000 + 400 = 3F98
1A3C	Base	00000001
1A40	NumberOfFunctions	000003BA
1A44	NumberOfNames	000003BA
1A48	AddressOfFunctions	00002654	2654 - 1000 + 400 = 1A54
1A4C	AddressOfNames	0000353C	353C - 1000 + 400 = 293C
1A50	AddressOfNameOrdinals	00004424	4424 - 1000 + 400 = 3824

EXPORT 구조체의 멤버들 정보를 정리했다.

다음은 AddConsoleAliasW 함수의 주소를 찾는 과정이다.

1. AddressOfNames (함수 이름 배열) : 293C

함수 이름 배열은 3BA(NumberOfNames)개의 원소가 있는 배열이고, 원소는 모두 문자열 주소(RVA)로 이루어져 있다.

첫번째 원소 4BA5를 RAW 3FA5로 변환하여 찾아가 본다.

2. 함수 이름 찾기 : 3F455

엄청나게 많은 문자열들이 보인다. 우리가 찾아야 할 함수의 이름은 AddConsoleAliasW이다.

ActivateActCtx가 제일 앞에 있어 인덱스의 값이 0이다. 그러므로 AddConsoleAliasW의 인덱스는 4이다.

3. AddressOfNameOrdinals (Ordinal 배열) : 3824

Ordinal 배열로 가서 위에서 알아낸 인덱스 4로 해당 ordinal을 찾는다. 똑같이 4이다.

4. AddressOfFunctions (함수 주소 배열 - EAT) : 1A54

EAT로 가서 ordinal 4를 인덱스로 하여 함수 주소를 찾으면 00072B29 값을 얻는다.

kernel32.dll의 ImageBase는 7C800000이므로 00072B29(RVA) + 7C800000(ImageBase) = 7C872B29(VA)이다.

Ollydbg에서 직접 찾아가 보면

AddConsoleAliasW 함수를 만날 수 있다..

이렇게 IAT / EAT에 대해서 정리를 마칩니다.

IAT(Import Address Table)

leeeeye321 — Wed, 12 Jun 2019 15:31:43 +0900

IAT(Import Address Table)

프로그램이 어떤 라이브러리에서 어떤 함수를 사용하는지를 기술한 테이블이다.

DLL(Dynamic Linked Library, 동적 연결 라이브러리)이란 여러 프로그램에서 동시에 사용할 수 있는 코드와 데이터를 포함한 라이브러리이다.

DLL의 로딩 방식은 두 가지인데, 그 중 하나가 프로그램 시작할 때 같이 로딩되어 종료 시 메모리에서 해제되는 Implicit Linking 방식이다. IAT는 Implicit Linking에 대한 메커니즘을 제공한다.

CALL [1001104]

notepad.exe에서 kernel32.dll의 CreateFileW를 호출하는 명령어이다.

이 CALL 명령에서 호출하는 주소는 CreateFileW의 주소가 아니라 IAT 메모리 영역이다.

1001104 주소에는 7C810CD9라는 값이 저장되어 있는데, 이 값이 CreateFileW의 주소이다.

이렇게 CALL 7C810CD9 명령을 사용하지 않고, IAT 영역을 사용하는 이유는 두 가지가 있다.

1. 환경에 따라 kernel32.dll의 버전이 달라지고, 함수의 주소가 달라지기 때문이다.

모든 환경에서 함수 호출을 보장하기 위하여 컴파일러는 실제 주소가 저장될 위치와 CALL [위치] 명령어를 준비한다. 파일이 실행되는 순간 PE 로더가 그 위치에 실제 함수의 주소를 입력한다.

2. DLL Relocation

DLL이 ImageBase 값에 로딩되고, 또 다른 DLL도 같은 곳에 로딩을 시도하면 PE 로더는 다른 비어있는 공간에 로딩시켜 준다. 이렇게 재배치가 일어나기 때문에, 함수 주소로 하드코딩을 할 수가 없다.

이어서 PE로더가 어떤 방법으로 IAT에 함수 주소를 입력하는지 알아봐야 겠다.

IMAGE_IMPORT_DESCRIPTOR(=Import Directory Table)

PE 파일은 자신이 어떤 라이브러리를 Import하고 있는지를 IID 구조체에 명시한다.

일반적 프로그램은 여러 라이브러리를 임포트하므로 라이브러리의 개수만큼 구조체 배열이 존재한다. (구조체 배열은 NULL 구조체로 끝난다.)

OriginalFirstThunk	INT(Import Name Table)의 주소(RVA)
Name	라이브러리 이름 문자열의 주소(RVA)
FirstThunk	IAT의 주소(RVA)

* INT와 IAT는 long type(4바이트) 배열이고 NULL로 끝난다.

* INT에서 각 원소의 값은 IMAGE_IMPORT_BY_NAME 구조체 포인터이다.

* INT와 IAT의 크기는 같아야 한다.

PE 로더가 임포트 함수 주소를 IAT에 입력하는 순서는 다음과 같다.

1. IID의 Name 멤버를 읽어들여서 라이브러리의 이름 문자열을 얻는다.

2. 해당 라이브러리를 로딩한다.

3. 이번에는 OriginalFirstThunk에서 INT의 주소를 얻는다.

4. IMAGE_IMPORT_BT_NAME 구조체의 Hint 또는 Name 멤버를 이용하여 함수의 시작 주소를 얻는다.

5. IID의 FirstThunk에서 IAT의 주소를 얻는다.

6. IAT의 배열 값으로 INT에서 얻은 함수 주소를 입력한다.

7. INT가 NULL을 만날 때까지 4~7번을 반복한다.

PEview로 IID를 직접 확인해 볼 것이다. IID 구조체의 위치는 OPTIONAL 헤더의 DataDirectory[1].VirtualAddress(RVA)에 저장되어 있다. PEview로 확인한 결과 위치가 7604인 것을 알 수 있다.

7604를 RAW로 변환하면 7604 - 1000 + 400 = 6A04이다. HxD로 이 위치를 찾아가면 IID 구조체를 확인할 수 있다.

사이즈는 C8이기 때문에 6A04 ~ 6ACD까지 IID이다.

화살표로 표시한 부분이 IID 구조체 배열의 첫 번째 원소이다.

Offset	Member	RVA	RAW
6A04	OriginalFirstThunk (INT)	00007990	7990 - 1000 + 400 = 6D90
6A10	Name	00007AAC	7AAC - 1000 + 400 = 6EAC
6A14	FirstThunk (IAT)	000012C4	12C4 - 1000 + 400 = 6C4

멤버들의 정보를 정리한 것이다. RAW를 보고 각각 멤버들을 찾아간다.

1. Name (라이브러리 이름)

IID 구조체 배열 첫 번째 원소의 라이브러리 이름은 comdlg32.dll으로 확인

2. OriginalFirstThunk - INT(Import Name Table)

INT는 임포트하는 함수의 정보가 담긴 구조체 포인터 배열이다. 이를 통해서 함수의 시작 주소를 정확히 구할 수 있다.

주소 값이 각각 IMAGE_IMPROT_BY_NAME 구조체를 가리킨다.

3. IMAGE_IMPROT_BY_NAME

배열의 첫 번째 값 7A7A(RAW: 6E70)으로 가면 임포트하는 API 함수 이름 문자열이 있다.

Ordinal: 000F / Name: PageSetupDlgW

4. FirstThunk - IAT(Import Address Table)

comdlg32.dll 라이브러리에 해당하는 IAT 배열 영역이다. 파일이 로딩될 때 이 영역들이 정확한 함수 주소로 대체되는 것이다.

OllyDbg에서 IAT를 확인하기 위해 주소를 변환한다.

12C4(RVA) + 1000000(ImageBase) = 10012C4

주소를 찾아가보니 763D4906을 가리키고 있다.

이는 comdlg32 라이브러리의 PageSetupDlgW 함수의 정확한 주소이다.

여기까지, IAT가 무엇인지 알아보고 직접 값을 확인도 해보았다. 다음에는 EAT에 대해서 알아보겠다.

PE File Format

leeeeye321 — Wed, 12 Jun 2019 15:29:31 +0900

PE File Format

PE(Portable Executable) 파일이란 Windows OS에서 사용하는 실행 파일 형식이다. 우리는 메모장(notepad.exe)으로 PE 파일의 기본 구조를 알아볼 것이다.

PE 파일은 PE 헤더(DOS 헤더 ~ 섹션 헤더)와 PE 바디(섹션)로 이루어진다.

PE 헤더에는 파일이 실행되기 위해 필요한 정보들이 구조체 형식으로 저장되어 있다.

IMAGE_DOS_HEADER

HxD로 확인한 DOS Header이다.

e_magic DOS signature MZ(4D5A)

e_lfanew NT_header의 offset(000000E0)

e_lfanew 멤버의 값을 따라서 000000E0에는 IMAGE_NT_HEADERS 구조체가 위치한다.

이 구조체는 signature와 두 개의 구조체 멤버로 구성된다.

Signature: PE signature PE(50450000)

File Header

Machine	CPU별 고유한 값(14C: 32비트 Intel x86 호환 칩)
NumberOfSections	섹션의 개수
TimeDateStamp	해당 파일의 빌드 시간(파일의 실행에 영향을 미치지 않는 값)
SizeOfOptionalHeader	NT 구조체의 마지막 멤버 OPTIONAL 구조체의 크기
Characteristic	파일의 속성들이 bit OR 형식으로 조합(0002h: File is executable. / 2000h: File is a DLL.)

Optional header

Magic	IMAGE_OPTIONAL_HEADER32 구조체: 10B / IMAGE_OPTIONAL_HEADER64 구조체: 20B
AddressOfEntryPoint	EP(Entry Point)의 RVA 값으로, 프로그램의 최초 실행 코드의 시작 주소(VERY IMPORTANT)
ImageBase	메모리에서 PE 파일이 로딩되는 시작 주소 * PE 로더는 PE 파일을 실행시키기 위해 프로세스를 생성하고, 파일을 메모리에 로딩한 후 EIP의 값을 AddressOfEntryPoint + ImageBase의 결과로 세팅한다.
File/SectionAlignment	파일에서/메모리에서 섹션의 최소단위. 섹션크기는 각각 이 값의 배수여야 한다.
SizeOfImage	파일이 메모리에 로딩되었을 때 가상 메모리에서 PE Image가 차지하는 크기
SizeOfHeader	PE 헤더의 전체 크기로 FileAlignment의 배수여야 한다.
Subsystem	이 값(Driver: 1/ GUI: 2/ CUI: 3)을 보고 파일 구분
NumberOfRvaAndSizes	DataDirectory 배열의 개수
DataDirectory	IMAGE_DATA_DIRECTORY 구조체의 배열

* VA(Virtual Address): 프로세스 가상 메모리의 절대주소

* RVA(Relative Virtual Address): 어느 기준 위치(ImageBase)에서부터의 상대주소
=> VA와 RVA의 관계식: RVA + ImageBase = VA

* Image: PE 파일은 섹션 헤더에 정의된 대로 맞춰서 메모리에 로딩된다. 메모리에 로딩된 상태를 이미지라고 한다.

NT 헤더 다음에 등장하는 섹션 헤더는 각 섹션별 IMAGE_SECTION_HEADER 구조체의 배열로 되어 있다.

VirtualSize	메모리에서 섹션이 차지하는 크기
VirtualAddress	메모리에서 섹션의 시작 주소(RVA)
SizeOfRawData	파일에서 섹션이 차지하는 크기
PointerToRawData	파일에서 섹션의 시작 위치
Characteristic	섹션의 속성(bit OR)

★ RVA to RAW

PE 파일이 메모리에 로딩되었을 때, 각 섹션에서 메모리 주소와 파일 옵셋을 잘 매핑할 수 있어야 한다.

섹션 헤더를 참고하여 메모장 파일이 메모리에 적재되는 모습과 위치를 그림으로 표현한 것이다.

그러면 이제, 어떤 메모리 주소가 주어졌을 때 그에 매핑되는 오프셋을 구하는 방법을 알아보겠다.

Q. RVA가 7A60일 때, RAW(File offset)의 값은 무엇일까요??

RVA(7A60) + ImageBase(1000000) = VA(1007A60)

VA의 공식을 통해, RVA 7A60 값이 첫번째 text 섹션에 속해있다는 것을 알 수 있다.

그리고 RAW = RVA - VirtualAddress(RVA) + PointerToRawData 비례식을 이용하면 끝!

7A60 - 메모리에서 text 섹션의 시작 주소(RVA: 1000) + 파일에서 text 섹션의 시작 위치(400) = 6E60

A. RVA가 7A60일 때 RAW의 값은 6E60이다.

스택 버퍼 오버플로우 공격 실습

leeeeye321 — Thu, 1 Feb 2018 11:16:25 +0900

Shell Code

-버퍼 오버플로우 공격의 핵심은 오버플로우가 발생하는 버퍼에 저장되는 공격자의 코드로 실행 제어를 이동시키는 것이다.

-사용자 명령어 라인의 해석기 Shell로 제어를 넘기고 공격당한 프로그램의 권한으로 시스템의 다른 프로그램에 접근하기 때문에 Shell code라고 부른다.

일단 /bin/sh 명령어를 실행하는 소스 코드를 작성했다.

메모리에 실행할 명령어만 올려야 하므로 data 세그먼트는 사용하지 않고 기계어로 변환해야 한다.

text 세그먼트만 사용해서 어셈블리어로 작성했다.

실행 파일을 disassemble해서 기계어를 획득했다.

그런데 여기서 보이는 null 값(00)은 입력할 수 없는 값(bad character)이다.

1. 4바이트 레지스터 eax에 1바이트 값을 넣으면 나머지 3바이트에 0이 들어간다.

-> eax 레지스터 대신에 al 레지스터를 사용한다.

2. push 0

-> 0을 push 하지말고 xor 연산으로 초기화한 레지스터를 사용한다.

31 d2 31 c0 52 68 2f 2f 73 68 68 2f 62 69 6e b0 0b 89 e3 52 53 8d 0c 24 52 cd 80

다시 작성하여 기계어를 확인한 결과 null 문자는 하나도 없다.

이제 이 숫자들 앞에 \x를 붙여서 입력 가능한 문자열 형태로 만들어 주면 된다.

\x31\xd2\x31\xc0\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\xb0\x0b\x89\xe3\x52\x53\x8d\x0c\x24\x52\xcd\x80

여기까지 하면 쉘 코드가 완성된다.

함수 포인터를 이용해서 검증해 본 결과 쉘 코드가 정상적으로 동작한다.

이제 진짜 버퍼 오버플로우 공격을 해볼 것이다.

Stack Buffer Overflow Attack1 !!

공격 시나리오

① 공격 쉘 코드를 버퍼에 저장한다.

② root 권한으로 실행되는 프로그램의 버퍼를 오버플로우 시켜서 공격 쉘 코드가 저장되어 있는 버퍼의 주소로 덮어씌운다.

③ 특정 함수의 호출이 완료되면 조작된 반환 주소로 쉘 코드의 주소가 반환되어 쉘 코드가 실행되고, root 권한을 획득하게 된다.

타겟 프로세스를 생성한다.

타겟 프로세스는

버퍼 오버플로우 취약점이 존재하고,

SetUID 권한이 설정되어 있다.

target1 프로세스에 SetUID를 설정하고 /tmp 디렉터리에 위치시킨다.

공격을 시도할 attacker 계정을 생성한 후 접속한다.

gdb로 메모리를 분석해야 한다. root 권한의 프로세스로는 할 수 없기 때문에 복사본을 만들고 gdb를 실행한다.

버퍼 오버플로우 취약점은 strcpy 함수에서 발생한다.

함수 호출 후 지점을 breakpoint로 설정해주고 쉘 코드를 인자로 전달하여 메모리를 확인한다.

인자로 전달한 쉘 코드는 버퍼에 저장된다.

버퍼 100 바이트 중 쉘 코드는 27 바이트를 차지한다.

나머지 73 바이트는 0으로 초기화되어 있다.

$(python -c 'print "\x31\xd2\x31\xc0\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\xb0\x0b\x89\xe3\x52\x53\x8d\x0c\x24\x52\xcd\x80" + "a" * 77 + "\x44\xfa\xff\xbf"')

EIP의 값을 쉘 코드가 위치한 버퍼의 주소로 덮어 씌워야 한다.

버퍼는 총 100 바이트이므로 100 - 27 = 73 바이트, 버퍼를 넘어서서 EBP까지 총 77 바이트를 A로 채우고

쉘 코드가 위치하는 버퍼의 주소(0xbffffa44)를 입력한다.

EIP 값이 해당 주소로 덮어졌다.

16 바이트 단위로 실제 주소를 추측하다 보면 쉘 코드가 실행이 된다.

오버플로우 공격으로 인해 프로그램의 실행 흐름이 변경된 결과이다.

우리가 원하던 대로 target1 프로세스의 SetUID에 의해 root 권한으로 실행된다. 권한 탈취(상승)에 성공했다.

Stack Buffer Overflow Attack2 !!

이번에는 gets 함수로 인해 버퍼 오버플로우 취약점이 발생한다.

gets(char *str)

표준 입력으로부터 str로 한 줄을 읽어들인다.

표준 입력은 모든 입력을 문자열로 인식하여 숫자를 입력할 수 없다.

쉘 코드를 입력하기 위해서는 파이프를 사용해야 한다.

-> 파이프(|)는 한 명령어의 출력을 두 번째 명령어의 입력으로 사용하고 싶을 때 사용할 수 있다.

gdb에서 파이썬 명령어를 사용할 수 없다.

버퍼 100바이트 + EBP 4바이트 -> A * 104

EIP 4바이트 -> BBBB

메모리에 값이 어떻게 들어가는지 확인하기 위해서 문자를 미리 출력해서 그대로 복사할 것이다.

EIP에 BBBB가 들어간 것을 확인할 수 있다.

쉘 코드가 위치할 주소는 bffffa64이다.

(python -c 'print "\x31\xd2\x31\xc0\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\xb0\x0b\x89\xe3\x52\x53\x8d\x0c\x24\x52\xcd\x80" + "A" * 77 + "\x64\xfa\xff\xbf"';cat) | ./target2

파이썬 명령과 cat 명령을 같이 실행하기 위해 묶고 이를 표준 입력으로 전달한다.

오버플로우 공격에 의해 실행의 흐름이 공격 코드로 변경되었다.

target2 프로세스의 SetUID에 의해 권한 상승도 성공했다.