Reverse engineering techniques to find security bugs: Alex Sotirov

재미있는 역공학 강좌입니다.

출처: http://joseph2625.tistory.com/2

첫부분엔 이사람이 만든 ANI Exploit 에대해 보여주네요 
간단한 HTML페이지에 자신이 만든 .ANI(Animated Cursor)파일을 올려놓고 
이거로 쉘 권한 따는거에요..

지금은 패치로 막혔지만 비스타도 픽스 적용안된 컴퓨터들은 취약하다고 나오네요
참고로 User32.dll이 취약하기때문에 파이어폭스도 픽스 설치안하면 먹히는듯..

그다음 슬라이드엔 Microsoft 보안패치관련 통계가 나오네요

1998년부터 500개 넘는 보안공지(패치) 띄웠는데 패치 거의 대부분이 한꺼번에
취약점을 몇개씩 보완해서 올리는듯

매달 둘쨋주 화요일에 배포한다고 함

하지만 많은 취약점들은 공지하지도 않고 패치된다고 하네요

만약에 보안전문가가 취약점 한개를 리포팅하면 Microsoft에선 그부분도 고치고 
그 주변 코드들도 다 체크해서 버그를 한번에 5-6개씩 고친다고 함
그리고 프로그램 에러날때마다 보내는Crash Report보고도 많이 고쳐진다고 함
Service Pack에도 많이 공개되지 취약점들이 패치된다네요..
공개가 된다해도 전혀 취약점에대해 자세히 설명하지 않고 대충대충 설명..

There is a privilege elevation vulnerability in Windows 2000 caused by improper validation of system inputs....

Security Bulletin가보면 이렇게 대충대충 설명하기때문에 자세히 알길이 없음.. 이사람 말로는 패치가 릴리즈 된 후 패치되지 않는 파일과 RE로 비교해서 찾아 낸다고 함.

이사람이 쓰는툴:

IDA Pro(전 Olly가 더좋다고 생각했는데 동영상보고 솔직히 조곰 놀랐음-_-)
BinDiff(IDA Pro Plugin)
PaiMei(디버거)
VMware(최고 乃)

취약점 찾는방법 설명부분 요약

Microsoft에서 제공하는 Debugging Symbol이 있기때문에 RE만으로도 충분히 찾을수 있다고 함
동영상 보시면 아시겠지만 플러그인 써서 프로그램의 실행 Flow비교를 해서 찾는거 같네요

커서파일 헤더부분 체크를 보여줌

ANI파일은 RIFF파일 포맷을 사용하며 헤더엔

헤더에 섹션들이 되있는데 ANI파일의 경우엔

"ANIH"태그가 파일의 첫부분에 나온다네요..

이 문자열을 비교한 후, 헤더의 사이즈를 (36바이트)체크 한후 커서 헤더를 정적으로 Allocate된 Stack에로드 하게 됩니다....

하지만!! 여기중요한게 있음... 패치 된 버전엔 이 체크하는 루틴이 포함되어있지만 패치 전버전엔 이 체크 루틴이 없다고 합니다..

로드할 메모리가 정적 메모리니 만약에 36바이트 이상 읽게되면 Stack Over Flow가 일어나겠죠..

패치되기전엔 읽어야 할 사이즈를 체크하지 않으니 이 방법을 사용할수 있다고 하네요

아이콘 관련 취약점도 동일한 원리라고 함..

이걸 이제 어떻케 Exploit을 만들때 사용할건지 설명하면서(? 설명하는 척하더니ㅡㅡ) 비스타관련 보안기능들을 설명합니다..

보시면 알겠지만 Vista에는 보안기능들이 뭐뭐 있냐면
/GS stack cookies
Address Space Layout Randomization
Data Execution Prevention
이 있는데 하나하나 설명 해 드릴게요

1. /GS stack cookies
VS에 새로 추가된 기능이라고 합니다
컴파일시 /GS를 사용하면

코드에 스택 체크 루틴이 추가되는데요 예를 들어봅시다
먼저 /GS를 사용하지 않은경우:
void foo(char *input)
{
   char buf[256];
   strcpy(buf, input);
}
보시면 알겠지만 strcpy함수는 Null Terminated String을 복사하는 함수 입니다.
그렇게 때문에 버퍼사이즈가 256바이트인 상태에서 그거 보다 더 큰 문자열을 집어넣을경우 스택 오버플로가 일어나게됩니다

하지만 Strcpy엔 이 오버플로를 체크하지 않기때문에(strcpy_s가 있긴함 근데 솔직히 쓰기 무지 귀찮-_-zz)
오버플로에 취약하죠.. 하지만 /GS를 사용할경우 컴파일러가 자동으로 아래 빨간글자로 된 코드를 추가로 넣습니다
static_cookie = rand();
void foo(char *input)
{
   int cookie = random_cookie;
   char buf[256];
   strcpy(buf, input);
   if (cookie != random_cookie)
      abort();
}

자세히 봅시다.. 스택상으론 cookie변수가 buf변수 다음 위치하게 됩니다( buf [a] [b] [c] [] [] cookie [0x23] [0x53] [0x13] [0x88] retaddr [0x77] [0x94] [0x28] [0x82]) 이렇게 되고 스택 오버플로가 일어날 경우 cookie정보를 바꾸지 않는이상 retaddr를 변경할 방법이 없어집니다. 만약에 쿠키 정보가 변경이 되면 Abort()해서 스택오버플로를 방지하게 되는 것이죠.

이 ANI Exploit경우엔 이런 루틴이 없었다고 합니다. /GS를 넣었다고 해도 Array변수만 체크하고
성능 이슈때문에 헤더 (struct)는 체크하지 않는다고 하네요.. 이경우엔 /GS를 써도 무용지물..

2.ASLR (Address Space Layout Randomization)
이게 뭐냐면...

XP보시면 프로세스의 라이브러리(DLL)파일이 실행할때마다 거의 동일한 자리에 로드되어있다는걸 아시게 될것입니다.. 예를들어 Olly에서 Call CreateProcessA을 Assemble시킬경우 IAT에서 그 함수의 포인터 정보를 사용해서 함수를 호출하는것이 아니라 대충 call 74938392형식으로 어셈블 됩니다. 딱보시면 "만약 라이브러리가 로딩되는 Base Address가 변경되면 이상한데로 호출될텐데"라고 생각하시겠지만 신기하게도 계속 먹힙니다!! 이 이유는 XP에서는 메인 executable과 ntdll,kernel32.dll라이브러리 파일들은 계속 같은곳에 로딩이 되기 때문이라고 하네요.

하지만 Vista에서 써본경우(경험임) 저렇게 어셈블 할 경우 바로 다음번 실행할때 바로 Exception뜹니다 CreateProcessA가 아닌 전혀 딴데로 호출이 되있더라구요..

이 이유는 비스타에선 저 파일들 베이스 어드레스가 항상 바뀌기 때문 이라는데요 이게 왜 중요하냐면
스택 오버플로우 취약점을 이용할땐 현재 함수가 어디로 리턴되는지 정보가 담겨있는 스택을 변경해서 자기가 가고싶은곳으로 가게 하는건데(jmp esp trampolines라고 함)이렇게 프로그램이 로딩될때마다 리턴 주소가 틀려버리니(그 해당 라이브러리 Base Address가변경) 도저히 공격할 ANI파일을 만들때 돌아갈 주소를 알지 못하게 됩니다. XP에도 있었지만 Main Executable,kernel32.dll,ntdll은 안바뀌고 Vista에서야 완전히 바뀐다고 함

그러나!!
이걸 비스타에서도 피해가는 방법이 있으니..
Heap Spraying이라는 방법이 있는데 이 방법은 엄청나게 많은양의 메모리를(200MB -0-) 다 nop처리 하고 맨 아래 부분에 jmp부분을 넣어서 리다이렉팅 하게 하는건데 이경우 Randomize가 된다 하더라도 nop부분을 호출하기 때문에 Exception이 뜨지 않는다고 함.

3.DEP(Data Execution Prevention)
다 아는 부분일꺼라 짧게 설명함..xp때는 CPU선에서 DEP자체를 지원하지 않았고(2001년이져.. 인텔이랑 AMD가2004년에 처음 도입했다니까 그 사이엔..전혀 안됐었음) Software base에선 디폴트로 꺼져 있어서 DEP가 전혀 적용이 되지 않는다고 하네요..

Vista에선 이것이 다 완화 되었지만... 그래도 문제가 있음-_-! IE는 예외래요... 하도 Third Party Plugin들이 막무가내로 코딩을 해서 DEP가 켜졌을경우 저런 플러그인에 문제가 생겨서 Default로는 꺼져 있다는군요...

DEP Bypassing:
DEP가 켜져 있다고 해도 피해갈수 있다는 방법이 있다고 합니다

ntdll어딘가에 DEP를 끄는 함수가 있는데 거기를 호출할경우 무용지물이 된다고 하네요

또 VirtualProtect함수를 사용해서 Heap에서도 Execute가 되도록 할수 있데요..

이사람은 ASLR이랑 DEP를 피해 갈수 있었던 이유는 DEP는 기본적으로 꺼져있기때문에 상관없고 ASLR경우엔 ExceptionHandler가 있기때문에 Access Violations생기더라도 전혀 문제가 없었다고 하네요..