Codetronik

본 포스팅을 따라하시면 손쉽게 VS2010에서 64비트 WDK를 개발하실 수 있습니다.

시스템 변수를 추가하는데 1,2,3 순서대로 클릭한 후 그림과 같이 새 시스템 변수를 입력합니다. (자신의 경로명에 맞게)

지금부터 프로젝트를 생성하여 빌드를 할건데 귀찮으신 분은 아래 프로젝트 파일로 테스트 해 보시길 바랍니다. 

sample 프로젝트 다운로드  

sample.zip

Visual Studio 2010을 실행하여 메이크파일 프로젝트를 생성합니다.

빌드 명령줄을 화면과 같이 입력합니다.

속성 페이지에서 포함 디렉토리에 그림과 같은 경로를 추가합니다. (자신의 경로에 맞게)

라이브러리 디렉토리도 추가해야 하는데 c:\WinDDK\7600.16385.1\lib\win7\i386 한 줄 추가합니다.

이제 빌드를 위해 필수 3가지 파일을 준비합니다.

ddkbuild.cmd

MAKEFILE

SOURCES

파일들을 자신의 프로젝트의 sample.vcxproj가 있는 디렉토리에 복사 후 SOURCES 파일을 열어 TARGETNAME과 SOURCES를 자신의 환경에 맞게 설정합니다.

빌드가 잘 되는지 테스트 합니다.

이제 asm을 추가할 차례입니다.

프로젝트 디렉토리에 AMD64 디렉토리를 생성합니다.

(필자의 경로 : D:\source\sample\sample\amd64)

SOURCES 파일에 아래 한 줄을 추가합니다.

AMD64_SOURCES=func.asm

프로젝트에서 func.asm을 생성 후 다음과 같이 입력합니다.

.code AsmFunc PROC ret AsmFunc ENDP END

작성한 asm을 C에서 연동해봅니다.

#include "ntddk.h" extern void AsmFunc(void); NTSTATUS DriverEntry(IN PDRIVER_OBJECT theDriverObject, IN PUNICODE_STRING theRegistryPath) { AsmFunc(); DbgPrintEx(DPFLTR_DEFAULT_ID, DPFLTR_ERROR_LEVEL, "Hello World!\n"); return STATUS_SUCCESS; }

빌드가 잘 되는지 테스트 합니다. 

이제 실제 머신에서 잘 동작하는지 테스트합니다.

드라이버 서명

원칙적으로는 64비트에서는 서명되지 않은 드라이버를 서비스에 등록할 수 없습니다.

하지만 OSR Loader + Driver Signature Enforcement Overrider (이하 DSEO) 툴 조합으로 이를 해결할 수 있습니다.

OSR Loader (AMD64 용) 다운로드OSRLOADER.exe

DSEO 다운로드dseo13b.exe

DSEO의 Sign a System File을 이용하여 sys를 서명합니다.

서명한 파일을 OSRLOADER로 실행하면 됩니다.

(만약 동작하지 않는다면 DSEO에서 Enable Test Mode로 설정하시기 바랍니다.)

EMET 5.0이 얼마 전에 출시 되었습니다.

새로운 기능이 추가되었는데 ASR이라고 하는 기능입니다.

EMET 공식 가이드 문서를 참조하자면,

Attack Surface Reduction (ASR)
The Attack Surface Reduction (ASR) helps reduce the exposure of applications at risk for attacks by blocking the usage of specific modules or plugins within the target application. For example, EMET can be configured to prevent Microsoft Word from loading the Adobe Flash plugin, or, with the support of Security Zones, can be configured to prevent Internet Explorer from loading the Oracle Java plugin on a website in the Internet Zone while continuing to allow Java on Intranet Zone websites. The mechanism simply prevents DLL loading on a per-process base, and it essentially adds the benefit to “killbit” specific modules in specific applications.

쉽게 설명하면 공격을 사전에 방지하기 위해 DLL을 안 올라가게 한다, 그런 내용 같습니다.

<iexplore.exe에서 차단하는 DLL - 제품마다 다르게 적용됩니다>

자바 취약점의 경우도 우선 애플릿을 호출하기 위해 JRE 모듈을 브라우저에 끌어다 씁니다.

위 그림은 자바 애플릿을 호출하기 위한 DLL 목록입니다.

ASR기능을 사용하면,

위에서 설정한 jp2iexp.dll 이 로드되지 않습니다. 즉, 애플릿이 동작하지 않게 됩니다. 

악성 페이지에서 효과가 있는 것을 확인 하였습니다.

혹 정상 페이지의 경우 어떻게 되는지 궁금해서 확인을 해보았습니다.

http://www.javakode.com/applets/03-color/

오진이 발생하면서 애플릿이 동작하지 않습니다. 위의 사이트에서 정상적으로 애플릿이 동작하는 것을 확인할 수 있습니다.

MS에서 자바 애플릿은 필요가 없다고 생각한 것인지, 아니면 확인하지 못한 오진인지 문득 궁금해집니다.

ARM에서 버퍼 오퍼플로우가 어떻게 동작하는지 알아보기 위해 라즈베리파이에서 테스트 해보았습니다.

아래 소스를 gcc 로 옵션 없이 컴파일 합니다.

#include <stdio.h> void bof() { char a[5]; scanf("%s", a); } void main() { bof(); printf("done\n"); }

두 개의 함수를 gdb로 디스어셈블링 하였습니다.

Dump of assembler code for function main: 0x0000844c <+0>: push {r11, lr} 0x00008450 <+4>: add r11, sp, #4 0x00008454 <+8>: bl 0x8420 <bof> 0x00008458 <+12>: ldr r0, [pc, #4] ; 0x8464 <main+24> 0x0000845c <+16>: bl 0x8338 <puts> 0x00008460 <+20>: pop {r11, pc} Dump of assembler code for function bof: => 0x00008420 <+0>: push {r11, lr} 0x00008424 <+4>: add r11, sp, #4 0x00008428 <+8>: sub sp, sp, #8 0x0000842c <+12>: ldr r2, [pc, #20] ; 0x8448 <bof+40> 0x00008430 <+16>: sub r3, r11, #12 0x00008434 <+20>: mov r0, r2 0x00008438 <+24>: mov r1, r3 0x0000843c <+28>: bl 0x835c <__isoc99_scanf> 0x00008440 <+32>: sub sp, r11, #4 0x00008444 <+36>: pop {r11, pc}

scanf 후의 스택입니다. 0x8440에 Breakpoint 가 걸렸습니다.

(gdb) x/10w $sp 0xbefff700: 0x41414141 0x00008300 0xbefff714 0x00008458 0xbefff710: 0x00000000 0xb6eab81c 0xb6fc0000 0xbefff864 0xbefff720: 0x00000001 0x0000844c

sp+0xc 지점이 복귀 주소입니다. ARM은 x86과는 다르게 retn 명령어가 없고 pop을 하면서 pc 레지스터에 바로 주소를 씁니다.
pc는 eip와 같다고 보시면 됩니다.

그러면 이번에는 AAAABBBBCCCCDDDD 를 입력합니다.

덮어 씌워졌습니다.

0x8440 실행 후의 스택입니다. 0x43434343은 r11에, 0x44444444는 pc에 들어갑니다.

(gdb) x/10xw $sp 0xbefff708: 0x43434343 0x44444444 0x00000000 0xb6eab81c 0xbefff718: 0xb6fc0000 0xbefff864 0x00000001 0x0000844c 0xbefff728: 0x00000000 0x00000000

crash 직후의 레지스터입니다.

(gdb) r Starting program: /home/pi/hack/hack AAAABBBBCCCCDDDD Program received signal SIGSEGV, Segmentation fault. 0x44444444 in ?? () (gdb) info register r0 0x1 1 r1 0x1 1 r2 0x0 0 r3 0x1 1 r4 0x0 0 r5 0x0 0 r6 0x8374 33652 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0xb6fff000 3070226432 r11 0x43434343 1128481603 r12 0x1 1 sp 0xbefff710 0xbefff710 lr 0x8440 33856 pc 0x44444444 0x44444444 cpsr 0x60000010 1610612752