※ 이 포스팅은 아직 조금 더 업데이트 될 내용이 있습니다.

오랜만에 포스팅이다. 작년에는 Heartblead 취약점과 Bash 취약점이 큰 이슈였다. 올해에도 역시 그에 견줄만한 큰 취약점이 나왔다. HTTP.sys 취약점이다. .sys 파일은 .exe, .dll 파일처럼 PE파일의 일종이다. 이 PE파일에서 Integer Buffer Overflow 취약점이 존재한다는 내용이며 이는 메모리 영역의 알정부분 노출(Heartblead 취약점과 비슷함) 더 나아가 Remote Execution까지 가능케 할수도 있다는 것이 이 취약점의 핵심이다. 아래의 링크는 공식적으로 공개된 해당 취약점에 대한 개괄이다.

CVE-2015-1635 : http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1635

MS15-034 : https://technet.microsoft.com/en-us/library/security/ms15-034

위의 개괄을 보면 아래의 윈도우즈 버전에서 취약하다는 것을 알 수 있다.

취약한 Windows 버전 : 

Microsoft Windows 7 SP1

Windows Server 2008 R2 SP1

Windows 8

Windows 8.1

Windows Server 2012 Gold and R2

그렇다면 HTTP.sys 파일이 언제 사용되는 파일이며 그것을 분석하기 위해서는 어떤 환경이 필요한지를 알아보자. 그것을 알기 위해 우리는 Internet Information Service (IIS) - Windows에서 제공되는 웹서버 -가 어떤 식으로 동작하는지 살펴봐야 한다.

IIS는 Windows에서 제공하는 웹서버이다. 웹서버는 기본적으로 Client의 요청을 처리하여 응답을 돌려주는 것이 가장 중요한 역할이다. 이 때 IIS와 Client 사이에 존재하는 것이 HTTP.sys라는 HTTP Listener이다. 아래의 그림을 보자.

Client가 웹서버에 HTTP Request를 보내면, 웹서버에서 HTTP Listener인 HTTP.sys가 그 요청을 먼저 받아서 처리를 한다. 처리한 내용을 w3wp.exe라는 IIS worker process에게 전달을 한다. 그 요청을 w3wp.exe가 처리를 하여 HTTP Response를 HTTP.sys에게 주면 그것을 Client에게 전달하는 방식이다. 좀 더 자세한 설명은 link를 참고하기 바란다.

여기서 중요한 사실은 HTTP.sys는 Kernel 모드에서 동작한다는 것이다. w3wp.exe는 User 모드 프로세스이다. 즉, Kernel 모드에서 User 모드 프로세스로 Context Switching이 일어난다는 것을 알고 분석을 시작해야 한다. 위의 그림에서 취약점이 일어나는 과정은 HTTP.sys가 Client의 HTTP Request를 w3wp.exe로 전달할 때 그것을 처리하는 부분에 있다.

이것을 분석하기 위해서는 HTTP.sys를 디버깅하는 과정이 필요하다. 그러기 위해서는 당연히 Debugger가 필요한데, 여기서 Windbg라는 Debugger를 이용해보려고 한다. Windbg는 Microsoft 사에서 제공하는 Tool로 User 모드와 Kernel 모드 프로세스를 모두 디버깅할 수 있는 Tool이며(Kernel 모드 디버깅을 지원한다) Microsoft 홈페이지에서 무료로 다운받을 수 있다. 사실 Kernel 모드 디버깅은 한번도 해보지 않은 사람에게는 환경 구성하는데도 조금 시간이 걸릴 수도 있다. 인터넷에 관련된 무수히 많은 정보가 있으니 잘 찾아서 구성해보시길 바란다.

Kernel 모드 디버깅을 하는 준비과정은 전부 마친 상태에서, 취약점을 다시 한번 되세긴 후 자세한 분석에 들어가보자. HTTP.sys 취약점은 Client로부터의 HTTP Request를 HTTP.sys가 처리하는 과정에서 발생하는 Integer Overflow 취약점으로 DoS(Blue Screen)나 RCE(Remote Command Execution) 등을 야기시킬 수 있다.

취약점을 분석할 때 가장 먼저 할 일은 정상 패킷을 통해 정도(定道)를 분석하는 것이다. 정상적인 GET Method를 요청할 경우 HTTP.sys는 어떤 작업을 하는지 대략 중요한 포인트를 집어서 설명해보자. Windbg를 통해 아래의 함수에 Breakpoint를 걸어보자. 아래의 함수들은 HTTP.sys내에 존재하는 함수들이다.

# Breakpoint List

UlpParseRange

UlPrepareCacheMissRangeResponse

UlAdjustRangesToContentSize

UlpBuildCacheEntry

UlBuildFastRangeCacheMdlChain

UlBuildFastRangeCacheMdlChain+0x311

# Normal Request

GET /welcome.png HTTP/1.1

Host: 192.168.0.100

Range: 18-1365

# welcome.png FileSize : 184946

처음에 아래와 같이 정상적인 요청을 할 경우 아래와 같은 순서로 Break가 걸린다.

1. UlpParseRange

2. UlPrepareCacheMissRangeResponse

3. UlAdjustRangesToContentSize

그런데 동일한 요청을 두번째 요청할 경우에는 아래와 같은 순서로 Break가 걸린다.

1. UlpParseRange

2. UlpBuildCacheEntry

3. UlAdjustRangesToContentSize

UlpBuildCacheEntry를 호출하는 이유는 웹서버의 성능을 높이기 위함이다. 동일한 요청에 대해서는 웹서버에서 보통 Cache된 Content를 사용하여 속도를 높이곤 한다. HTTP Cache에 대한 자세한 설명은 link를 참고하길 바란다. 이번 취약점에서 또 중요한 점 중에 하나가 HTTP Cache를 이용할 때 발생한다는 점이다. 따라서 두번째 요청할 경우에 (UlpParseRange → UlpBuildCacheEntry → UlAdjustRangesToContentSize) 초점을 맞추어서 분석해보자.

중요한 곳은 UlAdjustRangesToContentSize이다. 이 함수는 Range-Low + (Range-High - Range-Low  + 1) 즉, Range-High + 1을 계산하여 그것이 실제 파일 사이즈보다 작은지를 검증하는 Security Check 함수이다. (상식적으로 생각해봤을 때 Range-High + 1이 실제 파일사이즈보다 크다면 뭔가 이상한 일이 발생하겠지?)

Range: 18-1365로 요청을 했을 때, Range-High + 1 = 1366(0x556)이다. 1366 < 184946이므로 Security Check OK이다. 그리고 이 함수의 Return 값은 범위의 길이이다. 즉, Return 값은 1365 - 18 + 1 = 1348이다.

이후에 UlBuildFastRangeCacheMdlChain함수를 호출하게 되는데 이 함수 내에서 _imp__IoBuildPartialMdl 함수를 호출한다. 이 때 1348를 파라미터로 사용하여 1348 byte만 메모리를 할당하게 된다. 그렇게 만들어진 메모리 영역에 Contents를 넣고 Response로 보내는 것이다.

위의 그림은 _imp__IoBuildPartialMdl 함수에 들어가기 바로 직전에 esp 스택 값을 프린트해본 것이다. 0x544(1348)이 파라미터로 쓰인다는 것을 알 수 있다. 이 함수는 요청한 파일에 대하여 메모리를 할당하는 역할을 한다. (1348 만큼의 메모리를 할당할 것이다.)

정도(定道)를 이해했으면 취약점이 발생하는 요청을 분석해보자.

# Exploit

GET /welcome.png HTTP/1.1

Host: 192.168.0.100

Range: 18-18446744073709551615

Range에서 18은 임의의 0보다 큰 값을 택한 것이다. 18446744073709551615는 16진수로 0xFFFFFFFFFFFFFFFF이다. 우선 처음 요청을 하고, 그 다음 같은 요청을 또 해서 UlpBuildCacheEntry함수를 호출해보도록 하자. 이 함수에서의 Security Check를 해보면 0xFFFFFFFFFFFFFFFF + 1 = 0x10000000000000000 이어야 하는데, 64bit 이상 표현할 수 없는 한계 때문에 0x0000000000000000이 되버린다. 0x0은 실제 FileSize보다는 작을 것이다. 반면에 Return 값은 0xFFFFFFFFFFFFFFFF - 0x18 + 1 = 0xFFFFFFFFFFFFFFEE가 된다. 이 값을 Unsigned Integer로 취급하므로 이 값은 어마어마하게 큰 값이 된다. 이 다음 UlBuildFastRangeCacheMdlChain 함수를 호출하면 어떻게 될까? 

UlBuildFastRangeCacheMdlChain 함수 내에 있는 _imp__IoBuildPartialMdl 함수에서 0xFFFFFFFFFFFFFFEE만큼의 메모리를 할당하게 된다. 그런데 실제로 FileSize는 이 값보다는 훨씬 적을 것이다. 이때 FileSize 이상의 메모리를 긁어오는 과정에서 Blue Screen Of Death(BSOD)가 발생하게 된다.

조금 복잡한 내용이므로 간단하게 요약을 아래의 그림과 같이 해봤다.

핵심은 두번째 패킷을 보내는 과정에서 Integer Overflow로 인해 BSOD취약점이 발생한다는 것에 있다. 그런데 이 취약점을 잘 보면 2014년에 발표된 HeartBleed 취약점과 굉장히 비슷하다. 이 취약점은 임의의 Memory Contents를 노출시킨다는 취약점을 가지고 있었던 반면, 이번 HTTP.sys취약점은 BSOD를 야기시킨다. 결과는 다르나 취약점이 발생하는 원인은 비슷하다는 것이다. HeartBleed는 link에 자세하게 설명되어있다.

일반적으로 취약점이 발표될 때 보안 전문가가 확인해야 될 Check List는 아래와 같다.

1. 취약점의 원인과 탐지 규칙 생성

2. 관제 대상 서버에 대하여 취약점 점검 (PoC코드 사용 등등)

3. 조치 방법

이번 취약점 같은 경우, 취약점의 영향력이 BSOD이기 때문에 함부로 PoC코드를 실행했다가 서버가 다운되면 어떻하는지 걱정에 앞서서 PoC코드를 돌리지 않는 경우도 있다. BSOD가 발생하는 취약한 시스템에서 아래의 PoC코드를 무수히 많이 실행시켜 보았으나 한번도 Blue Screen이 발생하지 않았다. 그 이유는 위에 설명한 것을 바탕으로 생각해보면 자연스럽게 이해될 수 있다.

PoC 코드 : https://www.exploit-db.com/exploits/36773/

그 이유를 설명해보면 이렇다. Range: 0-18446744073709551615과 같이 요청을 한번 하고 두번째 했을 때, UlAdjustRangesToContentSize는 Range가 0xFFFFFFFFFFFFFFFF + 1 = 0이므로 FileSize보다 작다고 인식할 것이며, 0xFFFFFFFFFFFFFFFF - 0 + 1 = 0을 Return할 것이다. 아래의 그림은 Range: 0-18446744073709551615과 같이 요청했을 때의 UlAdjustRangesToContentSize의 Return값이다. 

실제 FileSize는 184946인데 할당한 메모리는 0밖에 안 된다. 이럴 경우 당연히 BSOD는 발생하지 않을 것이며 웹서버는 Requested Range not satisfiable를 의미하는 416에러를 응답값으로 준다.

416에러를 받았다는 것은 결국 정상적으로 에러를 처리했다는 뜻이 된다. 에러를 정상적으로 처리했을 때 BSOD는 당연히 일어나지 않는다. 따라서, Range를 0부터 0xFFFFFFFFFFFFFFFF로 했을 경우에는 BSOD가 일어나지 않는다.

이 취약점은 WIndows 최신 업데이트를 통해 간단히 해결가능하다. Patch 된 버전의 UlpParseRange 함수 내부를 들여다보면 RtlULongLongAdd 함수를 호출하여 Overflow 여부를 확인하는 부분이 있다. Integer Overflow가 발생할 경우 RtlULongLongAdd 함수는 STATUS_INTEGER_OVERFLOW 에러를 리턴하고, BSOD를 야기시켰던 함수인 UlAdjustRangesToContentSize, UlBuildFastRangeCacheMdlChain, _imp__IoBuildPartialMdl 함수에 접근하지 않게 된다. 즉, 직접적으로 취약점을 고쳤다기 보다는 취약점이 존재하는 코드를 우회시키는 방식으로 패치를 한 것이다.

Reference : 

https://technet.microsoft.com/en-us/library/cc735084(v=ws.10).aspx

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1635

http://www.iis.net/learn/get-started/introduction-to-iis/introduction-to-iis-architecture#Protocol

http://www.securitysift.com/an-analysis-of-ms15-034/

https://community.qualys.com/blogs/securitylabs/2015/04/20/ms15-034-analyze-and-remote-detection

https://www.exploit-db.com/exploits/36773/ 

아.. 이 중요한 취약점을 여기에다는 포스팅을 안 해뒀구나.. 지금 써둬야겠다. 무려, 작년에 있었던 Bash와 더불어 엄청난 영향을 주었던 취약점이다. OpenSSL에 존재하는 취약점으로 HeartBleed 취약점이라고 불리는 취약점이다. 우선 해당 취약점을 이해하기 위한 기본 지식을 살펴보려고 한다.

What is A heartbeat protocol?(https://tools.ietf.org/html/rfc6520)
우선, DTLS와 TLS가 무엇인지 알아보자. DTLS는 UDP와 같이 unreliable traffic이며, DTLS는 연결되어 있는 peer가 여전히 살아있는지 확인하기 위해서 SSL connection을 재수립한다. TLS는 TCP와 같은 reliable traffic으로, peer가 살아있는지 확인하기 위해서 data를 지속적으로 전송해주는 방법 밖에 없다. 이러한 제한을 해결하기 위한 것이 Heartbeat Hello Exxtention이다. heartbeat protocol은 TLS와 DTLS에 계층에서 트래픽을 암호화하기 위해 사용되며 TCP와 UDP 모두 쓰일 수 있다.

What kind of vulnerability was found?
OpenSSL에서 TLS와 DTLS 계층에 대한 구현 부분에서, 즉 Heartbeat Hello Extention 소스코드에서, 취약점이 발견된 것이다. 취약점의 영향으로 공격자는 서버 메모리에 올라와 있는 값을 일부 확인할 수 있다.

What does cause this vulnerability?
취약점이 어떻게 야기되는지 알아보자. 우선, Python으로 작성한 heatbleed 테스트 스크립트를 돌려보자. (http://www.exploit-db.com/exploits/32745/)
코드를 보면, 단순히 Heartbeat 요청을 보내고 응답을 받는 단순한 스크립트이다. 해당 스크립트는 응답의 길이로 해당 서버가 취약한지 취약하지 않은지를 결정한다. 스크립트가 사용하는 취약한 heartbeat 메세지를 한번 봐보자.

hb(0) Record Layer content Type 0x18
hb(1)hb(2) Record Layer Version TLS 1.1
hb(3)hb(4) Record Layer Length 3
hb(5)hb(6)hb(7) Heartbeat Message 01 40 00

Record Layer Length 길이는 최소한 이상이 되어야 한다. Record Layer Length 이전에 최소 3비트는 있기 때문이다. Heartbeat Message 0x014000을 자세히 봐보자.

위에 보이는 malformed packet에 대해서 모두들 쉽게 이해하기를 바란다. "Malformed Packet : SSL" 부분이 빨간색으로 하이라이트되어 있는데, 이는 malformed packet이라는 것을 의미하는 표시이다. 자세히 보면, payload length가 16384로 설정되어 있음에도 불구하고, 실제 payload 값은 없다. 따라서 이 malformed packet이 서버에 보내졌을 때 서버는 단순히 "Payload Length"만을 계산하고 16384만큼의 값을 Client에게 던저준다. 서버의 메모리에 올라와있는 응답값 길이는 16384보다 훨씬 작을 것이다. 그럼에도 불구하고 서버는 16384만큼 보내줄 예정인데, 그렇다면 어떤 값이 Client에게 갈까? 메모리의 일부가 가는 것이다. 그 메모리에 어떤 값이 포함되어 있을까? 아무도 모른다. 서버 내의 민감한 정보(가령, private key 값) 등이 포함되어 있을 수 있다.

Detail of the exploit
openssl의 어떤 부분이 취약하게 작성되었는지 알아보자. openssl 소스코드에서 ssl/d1_both.c 파일 안에 선언되어 있는 dtls1_process_heartbeat 함수에서 취약점이 존재한다. 

1487 줄에 보면, memcpy(bp, pl, payload)라고 되어있는 이 부분이 malformed packet에서 메모리 일부를 유출하게 작성되어있다. memcpy는 pl에서 시작하는 메모리 contents를 bp로 복사하도록 한다. 이 포인터 변수 pl은 heartbeat 메세지의 세번째 바이트를 가리킨다. (*p++와 n2s(p, payload)함수가 pl이 세팅되기 전에 실행된다는 것을 참고하자.) malformed heartbeat message에서 payload는 0x4000 즉, 16384 바이트이다. 따라서 pl이 가리키는 곳부터 16384바이트가 bp로 복사된다. 그런데 우리가 위에서 본 malformed packet에서는 16384만큼의 packet이 없다. 따라서 packet 다음에 따라오는 메모리의 일부를 복사한다. 공격자는 아마도 자기가 원하는 어떤 값들이 있기를 희망하며 공격을 수행할 것이다.(즉, 공격이 성공해도 공격자 입장에서 항상 원하는 정보를 얻는 것은 아니라는 뜻이다.) 참고로 n2s는 메크로로 아래와 같이 정의되어 있다.

Which version of openssl is vulnerable?

아래의 openssl 버전이 취약하다.

# 취약한 버전
1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1

위의 버전들은 1.0.1g 혹은 그 이상 버전으로 업그레이드 되어야 한다. 1.0.1g에서 소스코드는 아래와 같이 데이터 길이를 체크하는 방식으로 수정되어 있다.

지금까지 CVE-2014-0160에 대해서 알아봤다. 아래의 링크를 참고하고 다른 종류의 openssl 취약점이 존재하는지도 한번 살펴봐도 좋다.
http://www.openssl.org/news/vulnerabilities.html

지금까지 포스팅한 내용들을 잘 보면 리버싱에 기초되는 내용들이 많다. Function procedure call 부분부터 Assembly Language에 대한부분도 있고, OS에 대한 내용, Virtual Memory에 대한 내용도 있다. 이 많은 내용을 종합적으로 하여 Reversing을 어떤 식으로 하는지 예시를 통해 포스팅해보려고 한다.

단순 Assembly Language만으로는 불가능하다. 가령, mov %ebp, %esp라는 instruction을 봤을 때 %esp값을 %ebp에 복사하라는 것은 모두가 알지만, 왜 그런 일을 하는지 "분석"하는 것은 쉽지 않다. 이번 포스팅에서 예시로 분석할 함수는 NTDLL.dll의 함수 중 하나이다. RtlInitializeGenericTable이라는 함수를 분석해볼 생각이다. 왜 이것을 분석하냐? 이 함수의 이름으로 보아 GenericTable을 초기화한다는 것 같은데, 분명 GenericTable은 구조체로 되어있을 것인데, 이 GenericTable structure의 구조체가 어떻게 생겼는지 알아야 하기 때문이다. 그 구조체를 알기 위해서 어떤 함수가 젤 효율적일까? 이름으로 보아 "RtlInitializeGenericTable 함수가 그것일 것이다" 라고 추측한 것이다. 그래!! 추측으로부터 시작해보자. 

NTDLL.dll의 export function list를 보면 Rtl로 시작하는 함수들을 많이 볼 수 있다. 앞으로 Rtl 그룹함수라고 편하게 이야기하겠다.

이 Rtl 그룹함수들은 Undocumented API이다. 즉, 설명이 안 되어있다. 이것을 알 수 있는 방법.. Reversing이다. 그 중에서 어떤 함수부터 시작할까? RtlInitializeGenericTable이다. 왜냐? 이것이 GenericTable API에서 사용하는 여러 구조체 중에서 가장 Root 구조체를 잘 설명해줄 것이라고 추측하기 때문이다. 이름으로부터 그런 추측을 한 것이다.

우선 이 함수의 Disassembled Code를 봐볼까?

뭔가 짧은 것이 기분이 좋다. 우선 가장 위의 3줄을 보자.

mov edi, edi
push ebp
mov ebp, esp

두번째 세번째 줄은 일반적으로 함수가 시작할 때 Function Procedure Call을 이해한 사람이라면 이해할 수 있는 내용이다. 아래의 링크를 확인해보라.

http://operatingsystems.tistory.com/entry/SP-Procedure-Call

그런데 가장 첫번째 줄, mov edi, edi 이거는 왜 할까? edi를 edi에 복사한다. 의미가 없다. 어짜피 같은 값이다. 이것을 하는 이유는 hot-patch point를 만들기 위해서 이다. 아래의 링크를 참고 하자.

http://blogs.msdn.com/b/oldnewthing/archive/2011/09/21/10214405.aspx

즉, Run-Time Library와 같이 실행 시간 중에 무언가 함수 흐름을 변경하려면 jmp instruction을 어딘가 껴넣어야 하는데, 그것을 가장 처음 부분에 끼워넣을 것이고 그것을 넣기 위한 공간을 확보해둔 것이다. 일반적으로 jmp instruction은 최대 2 바이트 차지하는데 그 2 바이트를 위한 NOP함수인 것이다. 즉, 바뀌어도 상관없는 공간 2 바이트를 만들어둔 것이다. 

pop ebp

retn 0014h

이 라인은 함수를 종료하고 caller function으로 돌아갈 때 사용한다. retn 0014h를 조금 더 자세히 보면 RtlInitializeGenericTable 함수에서 몇 개의 파라미터를 사용하는지 추측할 수 있다. 5개 일 것이다. 0x14는 10진수로 20이고 포인터는 4바이트이기 때문이다. 물론 character형이 parameter로 올 수도 있고, 4바이트가 아닌 다른 형이 올 수도 있다. (아래 내용을 더 읽어보면 알겠지만 5개가 맞다.)

이제 나머지 라인들을 살펴보자.아, 본격적으로 살펴보기 전에 한 가지 또 가정을 해보자. RtlInitializeGenericTable 이 함수가 뭘 하는 함수일까? GenericTable을 초기화하는 함수일 것이다. 그렇다면 이 함수의 parameter 중 첫번째 parameter는 무엇일까? GenericTable의 root data structure일 것이다. 그리고 이 함수의 Return Address 또한 GenericTable의 root data structure일 것이다.