코드 인젝션과 사용자 모드 후킹 [ 윈도우 및 리눅스 ]

0. 개요

1. 윈도우 사용자 모드 후킹

.... 1.1 인젝션

........ 1.1.1 DLL 인젝션

................ 1.1.1.1 CreateRemoteThread()

................ 1.1.1.2 NtCreateThreadEx() / RtlCreateUserThread()

................ 1.1.1.3 QueueUserAPC()

................ 1.1.1.4 레지스트리 이용 ( AppInit_DLLs, AppCertDlls )

................ 1.1.1.5 SetThreadContext()

................ 1.1.1.6 Reflective DLL Injection

................ 1.1.1.7 Shims

........ 1.1.2 코드 인젝션

................ 1.1.2.1 기본적인 코드 인젝션

................ 1.1.2.2 Atom Bombing

................ 1.1.2.3 EWMI (Extra Window Memory Injection) / Powerloader Injection

................ 1.1.2.4 PROPagate

........ 1.1.3 취약점

........ 1.1.4 윈도우 비스타 이후의 변화

.... 1.2 후킹

........ 1.2.1 IAT 후킹

........ 1.2.2 Inline 후킹

.... 1.3 윈도우에서 제공되는 메시지 후킹

.... 1.4 기타

2. 리눅스 사용자 모드 후킹

.... 2.1 인젝션

........ 2.1.1 Ptrace()

.... 2.2 후킹

........ 2.2.1 PLT / GOT redirection

........ 2.2.2 Inline 후킹

.... 2.3 LD_PRELOAD

0. 개요

  프로그램의 흐름을 빼앗아서 본인이 원하는 코드를 실행시키는 기술을 후킹이라고 한다. 이를 위해서는 먼저 특정한 행위를 수행하는 코드가 존재해야 하기 때문에 이러한 코드를 프로그램에 삽입하는 방법(인젝션)이 필요할 것이며 삽입된 코드에서 실질적으로 프로그램의 흐름을 빼앗는 방법(후킹)이 있을 것이다. 여기서는 크게 윈도우와 리눅스 플랫폼에서의 후킹 및 인젝션 메커니즘을 설명할 것이고 이것은 사용자 모드에 한정한다.

1. 윈도우 사용자 모드 후킹

1.1 인젝션

  위에서 언급하였듯이 전제 조건으로서 먼저 원본 함수를 대체하거나 추가적인 기능을 가진 코드가 프로세스 내에 존재해야 할 것이며 이것 뿐 아니라 이 코드로 흐름이 넘어가도록 후킹을 설치하는 코드도 프로세스 내에 삽입되어 있어야 한다. 이렇게 두 종류의 코드가 존재하면 이후 이 설치 코드를 실행시킴으로써 후킹을 설치하여 궁극적으로 프로그램의 흐름을 빼앗고 원하는 행위를 수행할 수 있다.

  앞의 설명으로 알 수 있듯이 우리가 필요한 것은 저 코드를 삽입하는 것과 삽입된 코드를 실행하는 메커니즘이다. 일반적으로 인젝션은 코드 페이로드를 삽입시키는 코드 인젝션, 그리고 원하는 기능들을 모두 포함하는 DLL을 개발하고 이 파일을 삽입하는 방식인 DLL 인젝션 이렇게 두 가지가 존재한다. 이처럼 해당 프로세스의 가상 주소 공간에서 실행되는 코드들은 프로세스 자체의 권한을 가짐으로써 현 프로세스가 할 수 있는 모든 것을 할 수 있게 된다.

  참고로 지금까지 한 설명은 인젝션을 후킹의 목적으로 여기고 그것과 관련된 부분만 설명하였지만 후킹과 관련 없이 인젝션 자체적으로도 특별한 일을 할 수 있다. 꼭 후킹 함수와 후킹 함수를 설치하는 코드 이외에도 자신이 원하는 코드를 삽입하고 그 코드를 실행시킬 수 있다면 다양한 일을 할 수 있을 것이다. 이 부분은 뒤에서 알아본다.

  코드를 삽입하는 방법들은 뒤에서 차례대로 살펴볼 것이고, 여기서는 상대적으로 설명하기 간단한 코드를 실행시키는 메커니즘을 살펴보겠다. 먼저 DLL 인젝션의 경우 DLL Main에 수행하고자 하는 코드가 추가되어 있다면 DLL 인젝션만으로도 원하는 행위를 수행할 수 있다. DLL Main 부분은 DLL이 로드될 때 자동으로 실행되기 대문이다. DLL이 대상 프로세스 공간에 로드되면 대상 프로세스와 동일한 권한을 가지고 코드가 실행되므로 그 프로세스가 할 수 있는 모든 일을 할 수 있다. 그리고 당연히 가장 대표적인 행위가 후킹이다. 참고로 일반적인 API 후킹에서는 API를 후킹하는 함수를 설치하는 부분이 DLL Main에 존재해서 DLL 인젝션이 되자마자 바로 후킹 함수를 설치한다. 물론 후킹당한 원본 함수를 대체하거나 추가적인 기능은 DLL 내부의 다른 부분에 함수 형태로 존재할 것이다. 

  코드 인젝션인 경우에는 이렇게 자동으로 실행되는 부분은 없지만 WriteProcessMemory()로 페이로드를 써 넣은 후 이 부분을 CreateRemoteThread()를 통해 실행시킬 수 있다.

1.1.1 DLL 인젝션

  여기서는 코드를 삽입하는 방법 중에서 DLL 인젝션 기법을 살펴본다. 궁극적으로 DLL 인젝션은 대상 프로세스가 스스로 LoadLibrary()를 호출하게 만들어서 원하는 DLL을 로드하게 하는 것이다. 이렇게 원격 프로세스에 LoadLibrary()를 호출하게 하는 방식은 당연히 윈도우에서 기본적으로 제공되지는 않을 것이며 아래에서 설명할 여러 종류의 트릭들을 통해 수행된다.

1.1.1.1 CreateRemoteThread()

HANDLE WINAPI CreateRemoteThread (

    __in    HANDLE     hProcess,
    __in    LPSECURITY_ATTRIBUTES   lpThreadAttributes, 
    __in    SIZE_T      dwStackSize, 
    __in    LPTHREAD_START_ROUTINE  lpStartAddress, 
    __in    LPVOID      lpParameter, 
    __in    DWORD       dwCreationFlags, 
    __in    LPDWORD     lpThreadId
);

  이 함수는 임의의 프로세스의 가상 주소 공간에 스레드를 실행시키는 역할을 한다. hProcess는 대상 프로세스의 핸들이고, lpStartAddress는 스레드 함수의 주소이며 lpParameter는 스레드 함수의 파라미터이다. DLL 인젝션을 위해서는 이 함수가 원래 목표처럼 스레드를 생성하는 것이 아니라 실질적으로 LoadLibraryA() 함수를 호출시키게 만들어야 한다. 즉 스레드가 아닌 LoadLibraryA() 함수를 실행 시키는 것이고 이 함수의 인자에 자신이 작성한 DLL의 경로를 적어주는 것이다. 이에 따라 임의의 프로세스가 스스로 LoadLibraryA()를 호출하여 악의적인 DLL을 가상 주소 공간에 로드할 것이다. 

  먼저 OpenProcess()를 통해 대상 프로세스의 핸들을 구해야 할 것이고, 대상 프로세스의 메모리에 삽입할 DLL의 경로를 대상 프로세스에 써야 한다. 이것은 VirtualAllocEx() API를 이용해서 대상 프로세스의 메모리 공간에 버퍼를 할당한 후에 WriteProcessMemory() API를 통해 경로가 적힌 문자열을 써준다. 그리고 LoadLibraryA() API의 주소를 구해야 하는데 이것은 GetModuleHandle() API에 kernel32.dll을 인자로 넣어서 핸들을 구하고 GetProcAddress() API에 이 핸들과 LoadLibraryA 문자열을 넣음으로써 LoadLibraryA() 함수의 주소를 구하게 된다. 이제 처음에 설명했듯이 CreateRemoteThread() 함수를 실행하여 원하는 DLL을 로드한다.

  CreateRemoteThread()를 통해 어떻게 LoadLibraryA()가 호출될 수 있는지 조금 더 설명해 보자면 CreateRemoteThread()의 인자이자 원격에서 실행되는 스레드는 ThreadProc 콜백 함수이다. 이 스레드 프로시저는 인자가 4바이트 하나이며 반환값도 4바이트를 반환하는데 이 형태가 LoadLibraryA()와 같아서 이러한 트릭이 통하는 것이다.

1.1.1.2 NtCreateThreadEx() / RtlCreateUserThread()

  윈도우 7부터는 CreateRemoteThread()를 이용한 기법에 제한이 생겼지만 내부 함수인 NtCreateThreadEx() API를 사용하면 된다. 하지만 NtCreateThreadEx()가 윈도우 버전에 따라 수정될 수 있기 때문에 이것의 래퍼 함수인 RtlCreateUserThread()의 사용이 추천된다.

1.1.1.3 QueueUserAPC()

DWORD WINAPI QueueUserAPC(
  _In_ PAPCFUNC  pfnAPC,
  _In_ HANDLE    hThread,
  _In_ ULONG_PTR dwData
);

  APC(asynchronous procedure call)는 비동기 함수 호출 메커니즘으로써 일반적인 함수 호출인 SPC(synchronous procedure call)와 구별된다. 모든 스레드는 APC Queue를 가지고 있는데 이 Queue에는 APC 함수 및 파라미터를 저장할 수 있다. QueueUserAPC()는 사용자 모드 APC 객체를 APC Queue에 추가해주는 함수이다. 만약 APC Queue에 APC 함수가 추가되어 있고 동시에 해당 스레드가 Alertable State에 놓이면 이 APC 함수가 호출된다.

  이것을 이용하여 DLL 인젝션을 수행하는 방법을 알아보겠다. 먼저 첫 번째 인자인 pfnAPC에는 LoadLibrary()의 주소를 지정한다. 즉 호출함 함수로 LoadLibrary()를 설정하는 것이다. 이것은 CreateRemoteThread()를 이용한 방식과 비슷하다. 그리고 세 번째 인자 dwData도 비슷하게 VirtualAllocEx() 및 WriteProcessMemory()를 이용해 대상 프로세스에 써넣은 DLL 경로를 지정한다. 마지막으로 두 번째 인자인 hThread 즉 대상 쓰레드를 지정하면 된다. 이것은 인젝션할 프로세스의 PID를 이용해 GetMainThreadId로 스레드 ID를 구하고 OpenThread()로 해당 스레드의 핸들을 구한 후 지정하면 된다.

  이후 QueueUserAPC()를 호출하면 APC Queue에 APC 함수로서 LoadLibrary()가 그리고 인자로서 DLL의 경로가 Queue에 추가된다. 마지막으로 WiatForSingleObject()를 통해 대상 스레드를 Alertable State로 놓으면 LoadLibrary()가 호출된다.

  참고로 스레드를 Alertable State로 만들어주는 API로는 SleepEx(), SignalObjectAndWait(), WaitForSingleObjectEx(), WaitForMultipleObjectsEx(), 그리고 MsgWaitForMultipleObjectsEx()가 있다. Alertable State에 대해 조금 더 설명해 보기 전에 일반적으로 스레드들은 Ready, Running, Waiting State가 존재한다는 것을 기억해보자. 실제로는 이 3가지 State 외에도 Alertable State가 존재하는데 이것은 사용자가 조정할 수 있는 유일한 스레드의 상태이다.

1.1.1.4 레지스트리 이용 ( AppInit_DLLs, AppCertDlls )

[ HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs ]

  이 레지스트리 값은 디폴트로 비어있다. 하지만 여기에 원하는 DLL들의 경로를 써주면 USER32.dll을 로드하는 모든 프로세스에서 원하는 DLL들이 강제로 로드된다. 약간의 설명을 덧붙이자면 USER32.dll은 GUI 환경인 윈도우에서 기본적으로 사용하는 DLL로서, 이 DLL의 DLL_PROCESS_ATTACH 과정에서 AppInit DLL들을 LoadLibrary() 함수를 이용해 로드하는 것이다.

[ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCertDLLs ]

  이 외에도 AppCertDlls 레지스트리도 존재한다. 위와의 차이점은 CreateProcess(), CreateProcessAsUser(), CreateProcessWithLogonW(), CreateProcessWithTokenW(), WinExec()를 호출하는 프로세스에만 로드된다는 것이다.

1.1.1.5 SetThreadContext()

  먼저 DLL 삽입 후 다시 복귀하는 역할을 하는 인라인 어셈블리 루틴이 필요하다. 이 루틴은 LoadLibraryA()를 통해 악의적인 DLL을 삽입할 것이고 다시 실행을 재개 즉 복귀해야 한다. 참고로 복귀 주소는 현재 알 수 없기 때문에 뒤에서 추가해야 한다. 인젝션 프로그램은 대상 프로세스에 VirtualAllocEx()로 메모리를 할당하고 이 루틴을 써 넣는다. 이후 SuspendThread()로 대상 프로세스의 스레드를 정지시키고 GetThreadContext()로 Context를 얻는다. 그리고 Context의 EIP를 앞에서 설명한 루틴의 복귀 주소로 설정한다. 이후 EIP를 어셈블리 루틴의 시작 주소로 변경하고 SetThreadContext()로 Context를 저장한 후에 ResumeThread()로 실행을 재개한다. 결론적으로 변경된 EIP를 통해 어셈블리 루틴이 실행될 것이고 이것은 주어진 DLL을 삽입하고 아까 저장했던 원본 EIP의 주소로 ret한다.

1.1.1.6 Reflective DLL Injection

  대상 프로세스를 RWX 권한으로 오픈하고 VirtualAllocEx() 함수를 이용해 DLL이 들어갈 만한 메모리를 할당한다. 일반적으로 DLL은 드로퍼 형태로 리소스 섹션에 저장되어 있는데 이 DLL을 읽어와 할당한 곳에 복사한다. 중요한 것은 이 DLL은 현재 파일 형태로 존재한다는 점이다. 그래서 로더를 통해 로드된 것처럼 현재 파일 오프셋으로 존재하는 각 섹션을 가상 메모리에 올라온 형태로 재배치해야 한다. 이것은 블로그의 SimplePacker 문서에서도 패커를 개발하면서 다루었다. 이 뿐만 아니라 DLL에서 사용하는 함수들의 IAT도 수정해야 한다. 이 함수들의 주소는 LoadLibrary()와 GetProcAddress()를 이용해서 얻어올 수 있다. 참고로 이 함수들은 당연히 대상 프로세스 내에서 호출되기 때문이 이 함수들의 주소는 또 어떻게 얻어야 하냐는 문제가 발생한다. 이것은 대상 프로세스의 PEB를 찾고 이것을 통해 kernel32.dll의 메모리 주소를 찾은 후에 Export Table을 이용해 얻어내는 방식을 사용한다.

  지금까지의 과정을 보면 알겠지만 이 과정들은 모두 DLL을 직접 로드하는 방식이다. PE에 존재하여 실행 시 자동으로 로드된 경우나 도중에 LoadLibrary()를 호출한 경우에는 로더가 모든 과정을 알아서 해주지만 이 방식은 순수하게 로더의 역할을 수행해야 한다. 마지막으로 CreateRemoteThread()를 통해 그 주소를 엔트리 포인트로 하여 실행시킨다. 참고로 일반적인 코드 인젝션에서는 CreateRemoteThread()를 이용해 LoadLibrary()로 DLL을 로드함과 동시에 실행시키지만 여기서는 직접 로더의 역할을 통해 DLL을 로드하고 CreateRemoteThread()로는 직접 주소를 넣어 실행시키는 것이다.

  이것을 응용한 내용을 알게되어 먼저 정리부터 한 후에 추가하도록 하겠다. Reflective DLL Injection 방식은 먼저 대상 프로세스에 메모리를 할당하게 한다. 참고로 VirtualAllocEx() 대신 내부의 NtAllocateVirtualMemory()를 사용할 수도 있다. 이렇게 대신 사용할 수 있는 ntdll 함수들은 많이 존재하므로 단지 저 함수들만 사용해야 한다는 생각은 버리자. 전체는 아니지만 다음 링크에 간략하게 정리된 함수들이 있다.

[ http://sanseolab.tistory.com/57 ]

[ http://sanseolab.tistory.com/58 ]

  참고로 CreateRemoteThread()의 경우는 다음과 같다.

[ CreateRemoteThread() -> CreateRemoteThreadEx() -> NtCreateThreadEx() ]

  어쨌든 할당한 후 로더처럼 섹션에 맞게 써줄 것이고 (WriteProcessMemory / NtWriteVirtualMemory) 이후 CreateRemoteThread()를 이용해 쓰레드를 실행시킨다. 원래 존재하던 쓰레드들은 처음부터 상관 없이 잘 실행되고 있을 것이며 이후 이 인젝션된 DLL의 DllMain() 부분이 새로운 스레드로서 추가되어 실행되는 것이다.

  이것을 응용할 수 있는 방식으로 여러가지가 있을 것이며 개인적으로 정리된 문서를 보게되어 여기에 간략하게 추가하려고 한다. 링크는 다음과 같다.

[ https://zerosum0x0.blogspot.kr/2017/07/threadcontinue-reflective-injection.html ]

  사실 코드나 DLL 인젝션 방식들은 모두 탐지를 회피하기 위해 발전되고 있다. Reflective DLL 인젝션의 경우도 그러한데 문제는 눈치챘겠지만 코드를 실행시킬 때 CreateRemoteThread()를 이용한다는 것 자체가 조금 문제가 있다. 그래서 이것의 내부 함수 즉 앞에서 간략하게 쓴 ntdll 함수를 이용하던지 아니면 APC Queue를 이용한 방식으로서 코드를 실행시키는 방식으로 응용할 것이다. 이 문서에서 나온 방식은 이러한 함수들 대신 ResumeThread()와 NtContinue()를 이용해 실행시키는 방식이다.

  먼저 SuspendThread()로 대상 프로세스의 쓰레드를 Suspend 시킨다. 그리고 프로세스에 인젝션할 DLL의 공간 뿐만 아니라 Context가 저장될 부분도 메모리를 할당한다. 이 Context는 인젝션하는 프로그램 뿐만 아니라 대상 프로세스 내부에서도 추후에 사용될 것이다. 이후 섹션별로 DLL의 내용을 써준 후에 SetThreadContext()로 DllMain()의 위치를 지정한다. 또한 스택을 위해 스택 포인터를 더 낮은 주소로 맞추어 준다. 스택을 맞추는 것이 필요한 이유는 일반적인 경우와 이 방식이 다르기 때문이다. 새로 쓰레드로서 실행되는 경우에야 각 쓰레드 별로 스택이 할당되기 때문에 상관이 없지만 이 경우는 잘 실행되던 쓰레드를 멈추고 제어를 삽입한 DllMain() 부분으로 옮긴 것이기 때문이다.

  이후 ResumeThread()를 실행하면 DllMain() 부분이 실행되며 여기서 추가적인 작업을 수행할 수 있다. 당연히 현재 부분을 새로운 쓰레드로서 실행하기 위해서 CreateThread()를 이용해 작업을 수행한다. 중요한 점은 삽입된 코드는 이제 새로운 쓰레드로서 실행되지만 원본 프로그램의 경우 제어가 강제로 여기까지 (DllMain) 와버렸다. 하지만 우리는 아까 Context를 대상 프로세스의 메모리 공간에 복사해 놓았으며 동시에 스택도 오염되지 않게 스택 포인터를 바꾸어 놓았었다. 이제 DllMain()의 남은 부분에서는 저장된 Context를 인자로 넣고 NtContinue()를 실행하면 원래 진행하던 코드에서 그대로 진행할 수 있게 된다. 혹시 DllMain() 부분을 진행하다 오염되지 않게 스택 포인터를 저 멀리로 설정해 놓았었으므로 스택 메모리도 오염되지 않은 상태로 남아 있을 것이다.

1.1.1.7 Shims

  MS에서는 하위 호환을 위해 "Shim"이라는 개념을 도입했다. 이를 통해 개발자가 해당 애플리케이션을 직접 수정하지 않도록 해주는 편의성이 있지만 보안 문제가 생기게 된다. 이것은 후킹을 이용한 방식으로서 운영체제에게 이 애플리케이션을 어떻게 다루어야 하는지를 설정해줄 수 있다. 예를들면 인자 처리라던지 특정한 동작에 대한 처리 방식이라던지. 

  이러한 설정은 Shim database (sdb) 파일에 저장된다. 즉 소스 코드를 수정하여 다시 만들거나 패치를 적용하는 것 대신 이 파일을 통해 수정 사항을 적용시킬 수 있다. 해당 파일에서 사용할 수 있는 기능들을 보면 충분히 위험하게 사용될 수 있는 것들이 많이 보인다. "InjectDll"부터 시작하여 "DisableNX", "DisableSeh", "ForceAdminAccess", "ShellExecuteXP" 등이 있다.

  어떤 공격에서는 파워셸을 이용하여 sdbinst.exe 유틸리티를 실행시켜 악성 sdb를 등록시켰다. 이 sdb는 시스템 프로세스나 다른 애플리케이션에 대한 패치 또는 DLL 인젝션을 수행하여 공격하는 방식을 사용하였다.

1.1.2 코드 인젝션

1.1.2.1 기본적인 코드 인젝션

  지금까지 DLL 인젝션 방식을 설명했고 이제 코드 인젝션을 알아보겠다. 코드 인젝션은 설명하기는 더 간단하지만 실제로 구현하기는 상당히 까다롭다. 위에서 DLL의 경로를 담은 문자열을 대상 프로세스에 쓸 때 VirtualAllocEx() API를 이용해서 대상 프로세스의 메모리 공간에 버퍼를 할당한 후에 WriteProcessMemory() API를 통해 원격 프로세스에 메모리를 써 넣었다. 코드 인젝션은 문자열이 아니라 페이로드 전체를 VirtualAllocEx()와 WriteProcessMemory()를 통해 써 넣는다. 참고로 페이로드는 Thread Procedure 형태(ThreadProc 콜백 함수)로 만들 수도 있고 직접 어셈블리 루틴의 바이너리를 바이트 배열로 만들 수도 있으며 inline 어셈블리 루틴으로 만들 수도 있다.

  하지만 까다로운 부분이 존재하는데 DLL로 만든 경우에는 자동으로 컴파일되어 세세한 부분을 다룰 일이 없겠지만 이렇게 직접 코드 인젝션으로 페이로드를 삽입하는 경우에는 고려해야할 사항이 존재한다. 먼저 페이로드에서 API 호출이 사용되는 경우에는 그 주소를 호출하는 대상 프로세스에서의 주소가 다를 수 있기 때문에 (DLL 재배치나 ASLR 등으로 인하여) 정확한 주소를 알아낸 후에 추가하여야 한다. 또한 페이로드에서 함수 호출에 사용되는 인자 값 같이 데이터가 필요한 경우도 있는데 이 때에도 데이터 부분 또한 코드 페이로드 처럼 따로 삽입하고 코드 페이로드에서는 주소를 설정해 주어야 한다.

  어쨌든 DLL이 아니어서 자동으로 호출되는 메커니즘이 없기 때문에 위에서 설명했듯이 CreateRemoteThread() 함수를 사용하여 써 넣은 페이로드를 실행시킨다. 참고로 DLL 인젝션에서는 LoadLibrary() 함수를 실행시켰었다.

1.1.2.2 Atom Bombing

  이 방식은 일반적으로 사용되는 VirtualAllocEx(), WriteProcessMemory(), CreateRemoteThread() 등의 함수를 사용하지 않고 Atom Table이라는 메커니즘을 악용하여 코드를 삽입하고 실행시키는 메커니즘이다.

  공격자는 먼저 GlobalAddAtom()을 통해 인젝션할 코드를 Global Atom Table에 추가한다. 이후 ntdll!RtlDispatchAPC() [ QueueUseApc() -> NtQueueApcThread() -> ntdll!RtlDispatchAPC() ]를 통해 공격 대상 프로세스가 GlobalGetAtomName()을 호출하게 함으로써 추가한 코드를 읽게 한다. 이 메커니즘을 통해 WriteProcessMemory() 없이도 코드를 인젝션하게 된다.

  문제는 VirtualAllocEx()로 RWE 메모리를 할당하고 여기에 WriteProcessMemory()로 인젝션할 코드를 삽입한 위의 방식과는 달리 현재 코드는 인젝션되어 있지만 이 영역에는 실행 권한이 없다. 이 코드를 실행시키기 위해 ROP 체인을 이용하는데 사용되는 ROP 체인은 결과적으로 ZwAllocateVirtualMemory()를 호출하여 RWE 메모리를 할당하고 memcpy()로 인젝션한 코드를 복사하는 역할을 한다.

  마지막으로 실행 흐름을 다시 복구해주는 것도 가능하다.

[ http://www.reversenote.info/atombombing-stage1/ ]

[ http://www.reversenote.info/atombombing-stage2/ ]

[ http://www.reversenote.info/atombombing-stage3/ ]

* 서브클래싱

  EWMI와 PROPagate 인젝션을 정리하면서 윈도우의 서브클래싱과 관련된 이해 없이는 완벽히 파악할 수 없을 것 같다는 생각이 들었다.

[ https://docs.microsoft.com/en-us/windows/desktop/controls/subclassing-overview ]

  해당 링크를 보면 과거의 서브클래싱 방식과 현재의 서브클래싱 방식이 정리되어 있다. SetWindowLong() 및 SetWindowLongPtr()을 이용하는 방식은 과거 버전으로 보이며, Win32 GUI 프로그래밍 등에서 흔히 보던 방식은 최신 방식으로서 SetWindowSubclass() 방식이 사용되는 것 같다. 물론 아직도 정확한 이해는 하지 못했다. 추가적으로 SetProp() 함수는 개개의 윈도우에 대해 사용자 데이터를 저장하는데 사용된다.

  어쨌든 정리하자면 서브클래싱은 윈도우 메시지를 가로채는 일종의 후킹이며 분석하는 입장에서는 메시지 후킹 시의 SetWindowsHookEx() 메커니즘을 생각하면 될 것 같다.

1.1.2.3 EWMI (Extra Window Memory Injection) / Powerloader Injection

  이것은 Explorer Tray Winow (Shell_TrayWnd)의 추가적인 윈도우 메모리에 코드를 인젝션하는 방식이다. 윈도우 클래스를 등록할 때 애플리케이션은 메모리의 추가적인 바이트들을 설정할 수 있으며 이것이 Extra Window Memory라고 불린다. 물론 여기에는 충분한 공간이 없기 때문에 악성코드는 explorer.exe의 공유 섹션에 셸코드를 삽입하며 SendNotifyMessage()와 SetWindowLong()을 이용해 해당 셸코드를 가리키는 함수 포인터를 갖고 이것을 실행시킨다.

  GetWindowLong()은 윈도우 클래스 오브젝트의 EWM에 대한 주소 값을 얻어오는 역할을 하며 SetWindowLong()은 여기에 대한 주소 값을 변경해주는 역할을 한다. 이를 통해 악성코드는 윈도우 클래스에서 함수 포인터의 오프셋을 셸코드의 주소로 변경할 수 있다. 셸코드는 OpenSection()을 통해 공유 섹션을 오픈한 후에 직접 써 넣는다. 참고로 공유 섹션에는 RW 권한 밖에 없기 때문에 ROP 방식이 사용된다.

  마지막으로 해당 코드를 실행하기 위해서는 SendNotifyMessage()를 이용한다. 이 함수는 주어진 메시지를 해당 윈도우의 프로시저로 전달하여 다루게 한다. 즉 악성코드가 이것을 호출할 경우 explorer.exe 내부의 윈도우 프로시저가 트리거되는 것이다.

  참고로 Ensilo에서는 PowerLoaderEx라는 추가적인 방식을 소개하기도 했다.

1.1.2.4 PROPagate

[ https://modexp.wordpress.com/2018/08/23/process-injection-propagate/ ]

  위의 링크에 잘 정리되어 있어서 해당 링크를 참고하여 정리한다. 마지막 전체 소스 코드 부분을 보면 먼저 FindWinowEx() 류의 함수를 통해 특정 윈도우에 대한 핸들을 얻고, 이 핸들을 가지고 GetProp()으로 서브클래스 헤더에 대한 핸들을 얻는다. 참고로 이 예제에서는 윈도우7과 윈도우10 모두에 해당하는 "Progam"이라는 부모 윈도우 및 "SHELLDLL_DefView"라는 자식 윈도우를 대상으로 하며, 서브클래스 헤더는 "UxSubclassInfo"를 대상으로 한다.

  이후 explorer.exe를 대상으로 새로운 서브클래스 헤더 및 셸코드를 위한 공간을 할당하고 쓴다. 그리고 서브클래스 헤더의 pfnSubclass 필드를 셸코드의 주소로 변경하고 쓴다. 마지막으로 SetProp()을 이용해 explorer의 "UxSubclassInfo" 서브클래스의 프로시저가 셸코드 주소로 "업데이트"된다. 이제 PostMessage() 함수를 이용해 explorer에 WM_CLOSE 메시지를 보내면 셸코드가 실행된다.

1.1.3 취약점

  인젝션 기법은 아니지만 DLL Hijacking 취약점의 경우 악성 DLL을 로드하게 되며 DllMain()을 통해 로드 시에 코드가 실행되기 때문에 여기에 포함하기로 하였다.

1.1.4 윈도우 비스타 이후의 변화

  간단했던 윈도우 XP와 달리 비스타 부터는 변화가 많이 생겼다. 이를 설명하기 위해 바뀐 부분들을 위주로 더 자세히 설명해 나가도록 하겠다. DLL 인젝션을 수행하기 위해 가장 먼저 필요한 것이 대상 프로세스의 핸들이다. 우리는 인자로 우리가 필요한 접근 권한을 넣고 OpenProcess()를 호출하여 핸들을 얻는다. 이 접근 권한이 중요한데 예를들면 뒤에서 사용될 ReadProcessMemory() 함수를 사용하기 위해서는 프로세스에 대한 PROCESS_VM_READ 접근 권한이 있어야 한다. WriteProcessMemory() 함수는 PROCESS_VM_WRITE, PROCESS_VM_OPERATION 접근 권한이 필요하다. CreateRemoteThread()의 경우에는 PROCESS_CREATE_THREAD, PROCESS_QUERY_INFORMATION, PROCESS_VM_OPERATION, PROCESS_VM_WRITE, PROCESS_VM_READ 권한이 필요하다. 마지막으로 VirtualAllocEx()와 VirtualFreeEx()는 PROCESS_VM_OPERATION 권한이 필요하다. 일반적으로는 이것들을 모두 쓰기 보다는 PROCESS_ALL_ACCESS를 사용해서 OpenProcess()를 호출한다.

  중요한 점은 윈도우 비스타부터는 OpenProcess() 호출 시 호출하는 프로세스와 같거나 더 낮은 Integrity Level을 가진 프로세스에 대해서만 이러한 접근 권한을 얻어올 수 있다는 것이다. 만약 더 높은 Integrity Level을 가진 프로세스에 대해서 PROCESS_ALL_ACCESS 접근 권한을 얻어오려고 한다면 OpenProcess()는 에러를 반환한다. 권한과 관련한 내용은 이 블로그의 다른 글을 참고한다. 

  주제를 바꿔서 이제 원하는 권한을 가진 핸들을 받았다고 치고 위에서 언급한 함수들을 이용해 DLL 인젝션을 수행할 수 있다. 하지만 한가지 더 추가된 것이 있는데 Session Isolation 정책이 그것이다. 이 정책으로 인해 이제 CreateRemoteThread()는 같은 세션에 해당하는 프로세스들에만 DLL 인젝션을 수행할 수 있게 되었다. 참고로 리버싱 핵심원리에 따르면 ReadProcessMemory, WriteProcessMemory, VirtualAllocEx() 같은 함수들은 세션과 관련 없다고 한다.

  참고로 시스템 서비스들은 세션 0을 갖고 각 사용자들은 다른 숫자들을 부여받게 된다. 이에 따라 주로 DLL 인젝션의 대상이 되왔던 시스템 서비스들에게는 더이상 DLL 인젝션이 통하지 않는 것이다. 물론 이것도 우회하는 방법이 있는데 NtCreateThreadEx(), RtlCreateUserThread() 등의 네이티브 api를 사용하면 된다. 이 함수들을 통해 다른 세션의 프로세스에 DLL 인젝션을 수행할 수 있게 되었다.

  비록 이제 세션의 장벽을 넘었다고 해도 위에서 언급하였듯이 Integrity Level이라는 한계가 존재한다. 현재 프로세스가 관리자 권한을 가지고 있다고 해도 시스템 서비스들은 High Integrity Level보다 높은 System Integrity Level을 가지고 있다. 이것을 우회하는 방법은 프로세스에 SeDebugPrivilege 권한을 주는 것이다. 이 디버그 권한을 갖는다면 접근 통제 정책을 우회할 수 있기 때문에 System Integrity Level에 대해 DLL 인젝션을 수행할 수 있다. 하지만 이것도 한계가 있는데 SeDebugPrivilege 권한은 관리자 계정에 주어지기 때문이다. 그래서 관리자 권한 즉 High Integrity Level이어야 이 디버그 권한을 활성화시킬 수 있다. AdjustTokenPrivileges() 호출 시 인자로 상수 SE_DEBUG_NAME 즉 텍스트로 SeDebugPrivilege를 넣는 부분이 이 내용이다.

  예를들어 흔한 상황을 가정해 본다면 현재 프로세스는 관리자 권한이 아니라 표준 사용자 권한으로 실행 중일 것이며 우리는 DLL 인젝션을 수행하기 위해 세션이 같은 것을 찾아야 한다. explorer.exe는 항상 실행 중인 프로세스이며 이 두가지 즉 같은 세션에 같은 Medium 권한을 갖는다. 이에 따라 explorer.exe는 DLL 인젝션의 대상이 되는 경우가 많다. 관리자 권한 없이도 손쉽게 DLL 인젝션의 대상이 될 수 있기 때문이다. 만약 관리자 권한을 갖게 된다면 디버그 권한을 활성화시켜 이제 어디든 DLL 인젝션을 수행할 수 있게 된다.

1.2 후킹

  지금까지 원하는 코드를 DLL의 형태로든 코드 자체로든 삽입하였으며 실행시키는 메커니즘까지 알아보았다. 이제는 프로그램의 흐름을 가로채서 이 코드를 실행시키기는 후킹 방식을 알아보겠다. 후킹의 대상으로는 대표적으로 함수 호출이 있을 것이고 이 외에도 메시지나 이벤트 등이 있을 수 있다. 여기서는 가장 많이 사용되는 API 함수 호출 후킹을 대상으로 하겠다.

  후킹 기법도 여러 종류가 있겠지만 여기서는 가장 많이 사용되는 방식들인 IAT 후킹과 Inline 후킹에 대해서 다룰 것이다. 후킹은 간단하지만 목적에 따라 수많은 다양한 방식들이 나올 수 있으므로 간단하게만 정리한다.

  참고로 보안 솔루션들도 당연히 후킹을 통해 구현되는데 일반적으로 인라인 후킹이 많이 사용된다고 한다. 물론 IAT 후킹을 사용하는 제품들도 존재한다. 또한 DLL 내부에 구현되는데 (즉 대부분 DLL 인젝션을 사용한다) 후킹되어 실행할 루틴들이 각 함수로 구현되어 있으며 dllmain()에 후킹을 설치하는 루틴이 존재하여 DLL 인젝션 시에 dllmain()이 자동으로 실행되어 후킹을 설치한다. 이 DLL을 다른 말로 후킹 엔진이라고도 부른다. 후킹 엔진에는 오픈 소스인 EasyHook, Deviare2 외에도 마이크로소프트의 detours 그리고 상용 제품인 Madcodehook 등이 존재한다. 

1.2.1 IAT 후킹

  리버싱을 하다 보면 API 함수를 호출할 때 call 명령어에 의해 호출되는 주소가 직접적으로 해당 라이브러리에 위치한 API 함수의 시작 주소인 것이 아니라 간접 호출 방식을 사용함으로 인해 IAT 영역을 가리키는 것을 볼 수 있다. 이 IAT 영역의 주소에 그 API의 실제 주소가 들어 있으며 이를 통해 API가 호출되는 것이다. IAT 후킹은 IAT 영역에 위치한 후킹 대상 API 함수의 주소를 후킹 함수 주소로 변경하는 방식이다. 이에 따라 코드 영역에서는 똑같은 IAT 영역을 가리키지만 이 IAT에 들어있는 주소가 후킹 함수로 변경되어 있으므로 설치된 후킹 함수가 호출된다.

1.2.2 Inline 후킹

  기본적으로 Inline 후킹의 특징 상 여러 방식을 통해 코드를 수정하여 후킹 함수를 설치할 수 있다. 가장 대표적으로는 처음 5 바이트( mov edi, edi  /  push ebp  /  mov ebp, esp )를 jmp 문으로 수정하여 후킹 함수로 분기시키는 방식이다. 물론 우리가 수정함으로써 실행되지 못한 위의 명령어는 내부에서 따로 실행시켜 주어야 한다. 따로 실행시켜 주어야 할 5 바이트는 위와 같이 항상 ( mov edi, edi  /  push ebp  /  mov ebp, esp )이다. 또는 다른 방식을 사용할 수도 있다. "mov edi, edi" 명령어가 시작하는 주소의 바로 앞 5바이트를 jmp 문으로 수정한다. 이 부분은 항상 비어있는 공간이므로 안전하게 수정할 수 있다. 그리고 2바이트의 "mov edi, edi"를 해당 jmp 문 즉 jmp $-5로 변경한다. 이것은 short jmp이기 때문에 2바이트 밖에 차지하지 않는다. 

  지금까지는 x86에서의 설명이었고 x64에서는 다른 방식이 필요하다. 주소 공간이 커서 5바이트 jmp 명령어로는 부족할 수 있기 때문이다. x86 뿐만 아니라 x64에서의 인라인 후킹은 다음 문서를 참고한다. [ https://www.blackhat.com/docs/us-16/materials/us-16-Yavo-Captain-Hook-Pirating-AVs-To-Bypass-Exploit-Mitigations.pdf ]

1.3 윈도우에서 제공되는 메시지 후킹

HHOOK SetWindowsHookEx (
   int idHook,
   HOOKPROC lpfn,
   HINSTANCE hMod,
   DWORD dwThreadId
);

  SetWindowsHookEx() 함수는 메시지 후킹을 위해 지원되는 함수이다. Windows는 Event 구동 방식으로 동작하는데 이런 이벤트가 발생할 때 메시지를 통해 해당 어플리케이션에 통보되며 어플리케이션은 메시지를 받아서 분석한 후 해당하는 작업을 수행한다. 메시지 후킹은 중간에서 메시지를 가로채는 것이다. 예를들면 운영체제가 키보드에서 신호를 받아서 처리한 것이 메시지가 되고 이것이 메시지 큐에 있다가 거기에 맞는 응용 프로그램에 메시지를 넘겨준다.

  SetWindowsHookEx()는 인자로 dwThreadId를 받아서 대상 스레드(프로세스보다 더 구체적인)를 정하고 idHook을 통해 후킹할 메시지를 선택하며, lpfn은 그 스레드가 받는 특정 메시지를 후킹하여 대신 받아서 처리할 프로시저를 의미하고 마지막으로 그 프로시저가 들어 있는 DLL을 hMod로 받는다. 즉 특정한 스레드가 받는 특정한 메시지를 처리할 프로시저를 DLL 형태로 개발하고 이 함수를 이용하여 메시지 후킹을 설치하는 것이다.

1.4 기타

  이 항목에서는 여러가지 참고 사항들을 정리하기로 하겠다. 첫 번째 주제는 보안 프로그램 개발 시 사용자 모드 후킹을 어떻게 탐지할 것인가이다. 일반적으로 API 후킹의 경우 후킹 대상이 될만한 함수의 엔트리 포인트를 모니터링하여 방지한다고 한다. 이러한 모니터링도 결국은 미리 후킹을 해서 감시하는 것이다. 또한 코드 섹션의 해시 검사 또는 CRC 검사를 수행하여 변경되었는지를 검사할 수도 있다. 

2. 리눅스 사용자 모드 후킹

2.1 인젝션

2.1.1 Ptrace()

  ptrace()를 이용해 코드 인젝션 또는 .so 인젝션을 수행하는 방식이다. 요약해서 PTRACE_ATTACH를 이용해 대상 프로세스를 어태치하고 PTRACE_POKETEXT를 통해 메모리에 쓴 후 PTRACE_SETREGS로 EIP를 삽입한 코드로 변경한 후에 PTRACE_CONT로 실행을 재개한다. 물론 PTRACE_GETREGS와 PTRACE_SETREGS를 통해 문맥을 다시 복구하는 등의 절차도 필요하다.

2.2 후킹

2.2.1 PLT / GOT redirection

  윈도우에서는 API를 호출할 때 IAT에 있는 주소를 참조하여 간적 호출 방식을 사용하였다. 리눅스에서는 PLT와 GOT를 이용한 메커니즘이 사용된다. PLT/GOT redirection은 GOT에 존재하는 주소를 후킹 함수의 주소로 변경한다.

2.2.2 Inline 후킹

  인라인 후킹의 특징이 그렇듯, 윈도우에서처럼 라이브러리에 있는 함수의 시작 부분을 후킹 함수의 주소로 변경할 수도 있고 앞에서 설명했던 PLT 부분을 수정할 수도 있고 아니면 코드 섹션의 함수 호출 명령어의 주소를 직접 변경할 수도 있을 것이다.

2.3 LD_PRELOAD

  리눅스에서 프로그램을 실행하면, 즉 프로세스 생성 과정에서 로더가 라이브러리를 로딩하는데 이 때 만약 LD_PRELOAD 환경 변수가 설정되어 있다면 로더는 여기에 지정된 라이브러리를 먼저 로딩한다. 중요한 점은 이 중에서 libc 함수와 동일한 이름의 함수가 있다면 이 라이브러리의 함수가 호출된다는 것이다. 그러므로 후킹을 위해서는 후킹할 함수의 이름과 동일한 함수를 구현하여 공유 라이브러리를 개발하고 LD_PRELOAD 환경 변수에 이 파일의 경로를 써주면 이후 프로그램 실행 시 마다 원하는 함수가 후킹된다. 참고로 후킹 함수 내에서 원본 함수로 실행을 리다이렉트시키고 싶다면 dlsym() 함수를 통해 주소를 얻어서 사용할 수 있다. 이 방식은 일반적인 의미의 후킹과 인젝션이라고 불리기 힘들 수 있으나 (일종의 라이브러리 치환의 개념) 실질적으로 후킹과 인젝션 모두의 기능이 가능하다.