기본 콘텐츠로 건너뛰기

DLL Injection - 다른 프로세스에 침투하기

DLL Injection 구현 방법


몇 가지 구현 방법이 있습니다.

그 중에서 가장 유명한 방법이 CreateRemoteThread() API 를 이용하는 방법입니다.

이 방법은 윈도우즈 프로그래밍 서적의 바이블인 Jeffrey Richter 의 Programming Applications for Microsoft Windows 에 소개된 내용입니다.

일단 소스 코드를 보겠습니다. (엔지니어에게는 백 마디 설명 보다는 역시 소스 코드를 한번 보는게 낫죠.)

먼저 Injection 시킬 myhack.dll 소스 코드입니다.


// myhack.cpp

#include "stdio.h"
#include "windows.h"

#pragma comment(lib, "urlmon.lib")

#define DEF_NAVER_ADDR ("http://www.naver.com/index.html")
#define DEF_INDEX_PATH ("c:\\index.html")

DWORD WINAPI ThreadProc(LPVOID lParam)
{
    URLDownloadToFile(NULL, DEF_NAVER_ADDR, DEF_INDEX_PATH, 0, NULL);
    return 0;
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    HANDLE hThread = NULL;

    switch( fdwReason )
    {
        case DLL_PROCESS_ATTACH : 
            hThread = CreateThread(NULL, 0, ThreadProc, NULL, 0, NULL);
            CloseHandle(hThread);
            break;
    }
   
    return TRUE;
}

아주 간단한 코드입니다.

DllMain() 을 보시면 DLL 이 로딩(DLL_PROCESS_ATTACH)될 때 스레드(ThreadProc)를 실행합니다.

ThreadProc() 의 내용은 urlmon.dll 의 URLDownloadToFile() 함수를 실행시켜서 네이버 초기화면(index.html)을 다운받습니다.

프로세스에 DLL Injection 이 발생하면 해당 DLL 의 DllMain() 함수가 호출된다고 이전 포스트에서 설명드렸습니다. 따라서 notepad.exe 프로세스에 myhack.dll 이 Injection 되면 결국 URLDownloadToFile() 함수가 실행될 것입니다.

* DLLMain() 에서 직접 URLDownloadToFile() 을 호출하면 간혹 hang 이 걸리는 경우가 있어서, 별도의 스레드를 생성하여 호출하도록 프로그래밍 하였습니다.



이제 myhack.dll 을 notepad.exe 프로세스에 Injection 시켜줄 프로그램(InjectDll.exe)의 소스코드를 보시겠습니다.


// InjectDll.exe

#include "stdio.h"

#include "windows.h"
#include "tlhelp32.h"

#define DEF_PROC_NAME ("notepad.exe")
#define DEF_DLL_PATH ("c:\\myhack.dll")

DWORD FindProcessID(LPCTSTR szProcessName);
BOOL InjectDll(DWORD dwPID, LPCTSTR szDllName);

int main(int argc, char* argv[])
{
    DWORD dwPID = 0xFFFFFFFF;
 
    // find process
    dwPID = FindProcessID(DEF_PROC_NAME);
    if( dwPID == 0xFFFFFFFF )
    {
        printf("There is no <%s> process!\n", DEF_PROC_NAME);
        return 1;
    }

    // inject dll
    InjectDll(dwPID, DEF_DLL_PATH); 

    return 0;
}

DWORD FindProcessID(LPCTSTR szProcessName)
{
    DWORD dwPID = 0xFFFFFFFF;
    HANDLE hSnapShot = INVALID_HANDLE_VALUE;
    PROCESSENTRY32 pe;

    // Get the snapshot of the system
    pe.dwSize = sizeof( PROCESSENTRY32 );
    hSnapShot = CreateToolhelp32Snapshot( TH32CS_SNAPALL, NULL );

    // find process
    Process32First(hSnapShot, &pe);
    do
    {
        if(!_stricmp(szProcessName, pe.szExeFile))
        {
            dwPID = pe.th32ProcessID;
            break;
        }
    }
    while(Process32Next(hSnapShot, &pe));

    CloseHandle(hSnapShot);

    return dwPID;
}

BOOL InjectDll(DWORD dwPID, LPCTSTR szDllName)
{
    HANDLE hProcess, hThread;
    HMODULE hMod;
    LPVOID pRemoteBuf;    DWORD dwBufSize = lstrlen(szDllName) + 1;
    LPTHREAD_START_ROUTINE pThreadProc;

    // #1. dwPID 를 이용하여 대상 프로세스(notepad.exe)의 HANDLE을 구함
    if ( !(hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwPID)) )
        return FALSE;

    // #2. 대상 프로세스(notepad.exe) 메모리에 szDllName 크기만큼 메모리를 할당
    pRemoteBuf = VirtualAllocEx(hProcess, NULL, dwBufSize, MEM_COMMIT, PAGE_READWRITE);

    // #3. 할당 받은 메모리에 myhack.dll 경로("c:\\myhack.dll")를 씀
    WriteProcessMemory(hProcess, pRemoteBuf, (LPVOID)szDllName, dwBufSize, NULL);

    // #4. LoadLibraryA() API 주소를 구함    hMod = GetModuleHandle("kernel32.dll");    pThreadProc = (LPTHREAD_START_ROUTINE)GetProcAddress(hMod, "LoadLibraryA");
    // #5. notepad.exe 프로세스에 스레드를 실행
    hThread = CreateRemoteThread(hProcess, NULL, 0, pThreadProc, pRemoteBuf, 0, NULL);
    WaitForSingleObject(hThread, INFINITE); 

    CloseHandle(hThread);
    CloseHandle(hProcess);

    return TRUE;

역시 코드가 간결합니다. (편의상 예외처리, 리턴값 체크 등의 코드는 생략하였습니다.)

main() 함수에서는 2개의 서브 함수를 호출하고 있습니다.

FindProcessID(DEF_PROC_NAME) 함수는 프로세스 이름으로 PID(Process ID) 를 구해주는 함수입니다. (설명은 생략합니다.) 그리고 InjectDll(dwPID, DEF_DLL_PATH) 함수가 바로 DLL Injection 을 해주는 핵심 함수입니다.

InjectDll() 함수를 자세히 살펴보겠습니다.

InjectDll() 함수는 대상 프로세스(notepad.exe)로 하여금 스스로 LoadLibrary("myhack.dll") API 를 호출하도록 명령하는 기능을 가지고 있습니다.

#1. 대상 프로세스 핸들 구하기
hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwPID)) 

OpenProcess() API 를 이용해서 notepad.exe 의 프로세스 핸들을 구합니다. (이때 미리 구해놓은 PID 를 사용함)
이 프로세스 핸들(hProcess)을 이용해서 해당 프로세스(notepad.exe)를 제어할 수 있습니다.

#2-3. 대상 프로세스 메모리에 Injection 시킬 DLL 경로를 써주기
pRemoteBuf = VirtualAllocEx(hProcess, NULL, dwBufSize, MEM_COMMIT, PAGE_READWRITE);

대상 프로세스(notepad.exe)에게 로딩할 DLL 파일의 경로(문자열)를 알려줘야 합니다.
아무 메모리 공간에 쓸 수 없으므로 VirtualAllocEx() API 를 이용하여 대상 프로세스(notepad.exe) 메모리 공간에 버퍼를 할당합니다. 버퍼 크기는 DLL 경로 문자열 길이(NULL 포함)입니다.

* 주의!
VirtualAllocEx() 함수의 리턴값(pRemoteBuf)은 할당된 버퍼 주소입니다. 이 주소는 내 프로세스(Inject.exe)의 메모리 주소가 아니라 hProcess 핸들이 가리키는 대상 프로세스(notepad.exe)의 메모리 주소라는것을 꼭 기억하시기 바랍니다.


WriteProcessMemory(hProcess, pRemoteBuf, (LPVOID)szDllName, dwBufSize, NULL);

할당 받은 버퍼 주소(pRemoteBuf)에 WriteProcessMemory() API 를 이용하여 DLL 경로 문자열("C:\\myhack.dll")을 써줍니다.

이로써 대상 프로세스(notepad.exe) 메모리 공간에 Injection 시킬 DLL 파일의 경로가 생겼습니다.

* 참고
Win32 프로그래밍을 처음 배울 때 분명 다른 프로세스의 메모리에 읽고 쓰는 일이 어렵다고(혹은 불가능하다고) 배웠습니다. 하지만 실제로는 다른 프로세스의 메모리 공간에 접근을 못하면 운영체제도 답답해 집니다. (예를 들어 다른 프로세스 메모리에 접근 할 수 없다면 디버거 제작이 불가능해지지요.) 그래서 Windows 운영체제는 Debug API 를 제공하여 다른 프로세스 메모리 공간에 접근 할 수 있도록 하였습니다. 대표적인 Debug API 가 바로 위에서 소개해 드린 VirtualAllocEx(), VirtualFreeEx(), WriteProcessMemory(), ReadProcessMemory() 등이 있습니다.

#4. LoadLibraryA() API 주소를 구하기

hMod = GetModuleHandle("kernel32.dll");
pThreadProc = (LPTHREAD_START_ROUTINE)GetProcAddress(hMod, "LoadLibraryA");


LoadLibrary() API 를 호출시키기 위해 그 주소가 필요합니다.
(LoadLibraryA() 는 LoadLibrary() 의 ASCII 문자열 버전입니다.)

위 코드의 의미를 잘 생각해봐야 합니다.
우리는 분명 notepad.exe 에 로딩된 kernel32.dll 의 LoadLibraryA() API 의 시작 주소를 알아내야 합니다.
하지만 위 코드는 InjectDll.exe 에 로딩된 kernel32.dll 의 LoadLibraryA() API 의 시작 주소를 얻어내고 있습니다.

notepad.exe 에 로딩된 kernel32.dll 과 InjectDll.exe 에 로딩된 kernel32.dll 의 메모리 시작 위치(ImageBase)가 동일 하다면 위 코드는 문제가 없습니다.

일반적인 DLL 파일의 ImageBase 는 0x10000000 으로 설정되기 때문에 a.dll 과 b.dll 을 차례대로 로딩하면 a.dll 은 정상적으로 0x1000000 주소에 로딩이 되겠지만 b.dll 은 자신이 원하는 0x10000000 주소에 로딩되지 못하고 다른 비어 있는 주소 공간에 로딩됩니다. 즉, DLL Relocation 이 발생하는 것입니다. (a.dll 이 같은 주소에 이미 로딩되어 있기 때문입니다.)

만약 kernel32.dll 이 프로세스마다 다른 주소에 로딩된다면 위 코드는 잘못된 것입니다.
하지만 실제 Winodows 운영체제에서 kernel32.dll 은 프로세스마다 같은 주소에 로딩됩니다.

어째서 그런걸까요?

PE View 를 통해서 Windows 운영체제의 핵심 DLL 파일들의 ImageBase 값을 조사해 봤습니다.
(Windows XP SP3 KOR 버전입니다. Windows 업데이트 상태에 따라서 아래 값들은 달라질 수 있습니다.)

DLL file        ImageBase       SizeOfImage
--------------------------------------------
msvcrt.dll      77BC0000        00058000
user32.dll      77CF0000        00090000
gdi32.dll       77E20000        00049000
advapi32.dll    77F50000        000A8000
kernel32.dll    7C7D0000        00130000
shell32.dll     7D5A0000        007FD000
...

Microsoft 에서 친절하게 OS 핵심 DLL 파일들의 ImageBase 값을 이쁘게 정리해놨습니다.
즉, 자신들끼리 절대로 겹치지 않고 따라서 DLL Relocation 이 발생하지 않습니다.

Dll Injection 기법은 위와같이 OS 핵심 DLL 들은 자신만의 고유한 주소에 로딩된는 것을 보장해주는 Windows 특성을 이용한 것입니다. (이 특성이 Windows 보안 취약점으로 이용되기도 합니다.)
따라서 InjectDll.exe 프로세스에 import 된 LoadLibraryA() 주소와 notepad.exe 프로세스에 import 된 LoadLibraryA() 주소는 동일합니다.

* 참고!
모든 Windows 프로세스는 kernel32.dll 을 로딩합니다.
PE Header 를 조작하여 IAT 에서 kernel32.dll 항목을 제거해버려도 loader 가 강제로 kernel32.dll 을 로딩시켜버립니다. (XP 부터 해당됨. 2000 에서는 실행불가.)


#5. 대상 프로세스에 스레드를 실행 시킴

모든 준비는 끝났고 마지막으로 notepad.exe 로 하여금 LoadLibraryA() API 를 호출하도록 명령만 내리면 됩니다. 하지만 Windows 에서는 그런 API 를 제공하지 않습니다.

그래서 편법(?)으로 CreateRemoteThread() API 를 사용합니다.
(편법이라기 보다는 DLL Injection 의 정석이라고 말 할 수 있지요.)

CreateRemoteThread() API 는 다른 프로세스에게 스레드를 실행시켜주는 함수입니다.

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,
  __out  LPDWORD                  lpThreadId
);

첫번째 파라미터인 hProcess 만 빼면 일반적으로 사용되는 CreateThread() 함수와 다 똑같습니다.

hProcess 파라미터가 바로 스레드를 실행시킬 프로세스의 핸들입니다.
lpStartAddress 와 lpParameter 파라미터는 각각 스레드 함수 주소와 스레드 파라미터 주소입니다.
중요한건 이 주소들이 대상 프로세스의 가상 메모리 공간의 주소이어야 한다는 것입니다. (그래야 그 프로세스에서 인식을 할 수 있겠죠.)

좀 어리둥절 하시죠?
다른 프로세스에 DLL 을 injection 시키는데 스레드가 무슨 상관일까요?

스레드 함수 ThreadProc() 과 LoadLibrary() API 를 보시면 힌트를 얻을 수 있습니다.

DWORD WINAPI ThreadProc(
  __in  LPVOID           lpParameter
);

HMODULE WINAPI LoadLibrary(
  __in  LPCTSTR          lpFileName
);

두 함수 모두 4 byte 파라미터를 받고, 4 byte 값을 리턴하지요.
바로 여기서 아이디어를 얻은 것입니다.

CreateRemoteThread() 를 호출해서 4 번째 파라미터 lpStartAddress 에 "LoadLibrary() 주소"를 주고, 5 번째 파라미터 lpParameter 에 원하는 "DLL 의 경로" 문자열을 주면 됩니다. (반드시 대상 프로세스의 가상 메모리 공간에의 주소이여야 합니다.)

우린 이미 위에서 다 준비해놨지요. 편안하게 호출해주면 됩니다.

hThread = CreateRemoteThread(hProcess, NULL, 0, pThreadProc, pRemoteBuf, 0, NULL);

  pThreadProc = notepad.exe 의 LoadLibraryA() 주소
  pRemoteBuf = notepad.exe 의 "c:\\myhack.dll" 문자열 주소


CreateRemoteThread() 는 스레드를 생성하는 것이 아니라 실제로는 LoadLibraryA() 를 호출 시키는 것입니다.

댓글

이 블로그의 인기 게시물

SSH 크랙 , 보안 :: 메두사(Medusa) [소개, 사용법 ] [패스워드 크래킹]

외부에서 서버를 관리하기 위해서는 Telnet 과 같은 원격 쉘을 이용하게 됩니다. 이런 원격 쉘은 시스템에 직접 접근할수 있기 떄문에 특별한 관리와 보안이 필요합니다. 그래서 나온것이 SSH 바로 보안 쉘 입니다. 기본적으로 이동하는 패킷이 암호화 처리 되기 떄문에 TELNET보다는 매우 안전하다고 볼수 있습니다. 오늘은 이 SSH를 크랙하는 방법과 대책에 대해서 약간 알아보겠습니다. 이번에 소개할 툴은 메두사 입니다. 메두사는 Broute Force  공격에 사용되는 툴입니다. 설치 데비안계열 ( 데비안 , Ubuntu , 쿠분투 주분투 등등) 에서는 apt-get install medusa 로 간단하게 설치 할 수 있습니다. 메두사로 SSH서버를 크랙하는 방법에 대해 알아보겠습니다. 메두사의 메뉴얼입니다. 구조는 간단합니다. 상대 SSH서버를 확인한 후에 메두사로 무차별 대입공격을 시도합니다. 물론 상대 시스템에는 로그가 남을수 있겠지요.  일단 실험에 쓰일 노트북(공격자) 데스크탑(피해자) 입니다. 공격자 OS : Debian Net : wlan0 IP   : 192.168.0.26 피해자 OS : BackTrack4 Net : eth0 IP   : 192.168.0.3 ssh :  OpenSSh ( SSH1) 실험에 쓰일 피해자(backTrack)입니다.  현재 SSH서버를 가동하고 아무작업없이 대기중입니다. 공격자는 포트스캐너와 각종 툴들을 이용해 정보를 수집후  피해자가 SSH서버를 이용한다는것과 OpenSSH(SSH1)을 사용한다는 것을 알아냇다는 전제하에  시작하겠습니다. 공격자는 메두사 툴을 이용해 BruteForce공격을 시작합니다. medusa -h 192.168.0.3 -u root -P /home/noon/NOON/pass.txt -M ssh 사용된 옵션을 살펴 보자면 -h   :   호스트 주소입니다.  고로    타켓 주소 -u   :   크랙할 유저의 이름입니다.     유저 목록을 파일로 만들어서 사용할

OllyDbg 64bit 실행방법

OllyDbg 1.1 은 기본적으로 64bit 환경을 지원하지 못합니다. 책의 디버깅 실습은 거의 대부분 OllyDbg 를 이용해서 진행됩니다.  그러나 OllyDbg 1.1 은 64bit 환경을 지원하지 못합니다.  <그림 1. Windows 7 64bit 에서 OllyDbg 1.1 실행시 예외 발생> 64bit OS 에서 "2장 Hello World 리버싱" 실습 예제 파일 HelloWorld.exe 를 OllyDbg 1.1 로 실행시키면 <그림 1>과 같이 예외가 발생하면서 ntdll.dll 모듈 영역의 코드에서 멈춰버립니다. (이것은 OllyDbg 1.1 의 버그입니다.) 64bit 환경에서 OllyDbg 사용할 수 있는 2 가지 방법 #1. 64bit OS + OllyDbg 2.0 OllyDbg 2.0 버전에서는 64bit에서 정상 실행 되지 않는 버그가 수정되었습니다. 다운로드 링크 :  http://www.ollydbg.de/odbg200.zip * 참고 최신 버전 OllyDbg 2.01 beta 2 는 실행 과정에 약간의 문제가 있습니다. 문제가 해결될 때까지는 OllyDbg 2.0 을 사용해 주시기 바랍니다. 위 링크에서 파일을 다운받아 압축을 해제한 후 실행하면 <그림 2> 와 같은 화면이 나타납니다. <그림 2 - Windows 7 64bit 에서 OllyDbg 2.0 으로 HelloWorld.exe 를 띄운 화면> <그림 2>의 화면을 책의  <그림 2.3>  처럼 보이게 하려면 다음과 같이 작업해 주시면 됩니다. 1) 내부의 CPU 윈도우를 최대화 시킵니다. 2) Code/Register/Dump/Stack Window 의 폰트를 변경합니다.    (각각의 창에서 마우스 우측 메뉴 - Appearance - Font - System f

인터넷 웹페이지 디버깅 피들러(fiddler) 사용법

인터넷 디벌깅 툴 피들러 입니다. 개발자들은 인터넷 디버깅 툴을 많이 사용하고 있는데요 인터넷 익스플러워 , 사파리 구글크롬등 디버깅 툴은 내장되어 있습니다.  하지만 원하는 값을 얻기 어렵거나 사용하기 어려운 점도 있습니다. 그래서 사용하기도 간편하고 필요한 기능도 많도 원하는 값을 쉽게 확인 할수 있는 디버깅 툴을 소개 해드리려 합니다. 알고 계시는 분도 많겠지만 피들러 (fiddler) 라는 툴입니다.  피들러에 대하 알아보도록 하겠습니다.  피들러(Fiddler) 설치 피들러 설치를 하기 위해 아래 사이트에 접속합니다.   http://www.telerik.com/fiddler 사이트에 접속하시면 FreeDownload 버튼이 보입니다. 클릭을 해서 피들러 설치를 진행합니다. ▶ 피들러는 닷넷 프레임워크를 사용하는데요 window 7 이상 제품군이시면  Fiddler for NET4을 선택하시고 미만이면 .net2를 선택 하세요  이제 Download Fiddler를 선택합니다.  ▶ 피들러 설치 진행화면이 나옵니다. I Agree를 클릭합니다.    ▶ 설치할 폴더를 선택 후 Install을 클릭합니다.    ▶ 설치가 완료되면 Close 를 클릭합니다.    ▶ 설치가 완료되면 브라우저를 새로 실행 하시고 도구> Fiddler를 선택합니다. 도구메뉴가 안보이시면 Alt를 누르시면 보입니다.    ▶ 우측에도 피들러 메뉴가 있습니다.  도구를 클릭 후 피들러를 클릭합니다.   ▶ 실행이 되면 아래와 같은 화면이 나오는데요  좌측 하든을 보시면 Capturing 가 보입니다. 캡쳐를 진행하는 중이구요 키보드중 F12키를 누르면 캡쳐 중지 다시 F12키를 누르면 캡쳐가 진행됩니다.  원하는 부