[Tech Report] 사례를 통해 알아가는 실전 패킷 분석
|
<연재 목차>
2. 개발자를 위한 유용한 분석 도구 소개와 패킷 분석(2012년 1월호)
3. 사례를 통해 알아가는 실전 패킷 분석(이번 호) |
패킷 분석 도구가 다양함에도 불구하고 한두 가지의 도구만으로 패킷을 분석하려는 경우가 많다. 하지만, 활용할 수 있는 도구는 매우 다양하고, 패킷 파일에서 찾고자 하는 정보를 빨리 얻을 수 있는 효율적인 방법도 있음을 지난호에서 설명했다.
그러나, 다양한 패킷 분석 도구가 있다고 해서 모든 분석을 쉽게 해낼 수 있는 것은 아니다. 그래서 이번 호에서는 몇 가지 사례를 살펴봄으로써 패킷 분석 경험을 함께 나눠보고자 한다.
누군가 이미 경험했던 것을 공유하고 배우는 것은 소중하다. 내가 경험해보지 못한 것을 간접적으로나마 접할 수 있기 때문이다. 여러 관점에서 사례를 분석함으로써 새로운 경험을 해보고, 이러한 경우에 자신은 어떤 식으로 했을까 하고 생각해보는 시간을 가져보자.
1. A 기업의 UDP 트래픽 급증의 원인은 바로 이것!
A 기업은 최근 한 달 동안 간헐적으로 트래픽이 급격하게 증가해 내부에서 인터넷 사용이 힘들다고 호소했다.
문제 발생 시점의 패킷을 확인해보니 UDP 트래픽이 많이 나타나고 있었고, 이러한 패킷 형태 때문에 해킹에 의한 공격 명령을 받아 발생되는 것 아니냐 또는 악성코드에 감염된 것이 아니냐 하는 의견이 제기됐다. 과거와는 달리 요즈음은 알 수 없는 트래픽이 급격히 증가하면 악성코드를 의심하는 경우가 많다. 특히나 서비스 거부 공격을 당한 전력이 있다면 더더욱 악성코드로 간주하기 쉽다. 필자도 얼핏 훑어보니 공격 트래픽과 유사해 보였다. 하지만, 지난호에서 언급한 것과 같이 악성코드로 간주해 엉뚱한 곳에 분석의 초점을 맞추다보면 잘못된 결과를 가져올 수 있다.
일단, 분석 대상의 패킷에는 다음과 같은 트래픽이 포함돼 있었다.
- ARP
- NetBIOS
- UDP
- 웹(Web)과 같은 일반적인 트래픽 형태
그 중에서도 가장 눈에 띄는 것이 UDP 트래픽이었다. 그렇다고 증상이 지속적으로 나타나는 것이 아니라 일시적으로 나타났다가 사라지곤 했다. 분석가 입장에서는 이런 부분이 가장 곤란하다. 트래픽이 계속 발생하면 추적이 비교적 용이하지만, 간헐적으로 발생하는 트래픽은 분석가를 지치게 한다.
[그림 1] 와이어샤크의 그래프를 통해 본 트래픽 흐름
우선 와이어샤크로 패킷의 전체적인 흐름을 살펴보았다. ’Protocol Hierarchy Statistics‘로 살펴보니 UDP 프로토콜의 비중이 가장 높았고, 그래프를 통해 살펴보아도 전체 흐름 중에서 UDP(빨간색 막대 그래프)가 차지하는 비중이 꽤 높게 나타났다. 전체적으로는 UDP 외에 다른 프로토콜도 의심 범위에 속하긴 하지만, 트래픽의 급격한 증가가 가장 큰 원인으로 지목됐고, 트래픽을 가장 많이 차지하는 UDP가 우선 분석 대상이라고 할 수 있다.
UDP를 살펴보니 다음과 같은 특징이 있었다.
- UDP 목적지가 255.255.255.255이며 포트번호 5432가 많이 나타남
- Payload는 256바이트인 경우가 많다.
- Payload가 1400바이트로 채운 경우도 적지 않게 보인다.
[그림 2]는 실제 패킷 화면의 일부다. 이상하리만큼 단시간 내에 많은 전송이 나타난 것을 볼 수 있다.
[그림 2] 브로드캐스팅 주소로 전송되는 UDP 트래픽
패킷 데이터가 워낙 많다 보니 일일이 다 확인하기는 어렵지만, 전반적으로 살펴봤을 때 Payload는 랜덤 스타일의 데이터로 채워져 있었으며 의심할 만한 문자열은 발견되지 않았다. 전달받은 패킷 파일만 하더라도 수백 Mbps이므로 분석가가 이것을 다 살피는 데는 한계가 있다. 게다가 기본적으로 알 수 없는 문자열들의 조합으로만 이루어져 있어서 분석이 쉽지 않았다. 그런데, 필자의 눈을 사로잡은 것이 있었으니 그것은 JFIF라는 문자열이었다.
[그림 3] UDP 패킷 중 JFIF를 포함하고 있는 Payload
헤더 첫 부분에서 JFIF라는 문자열이 발견됐는데, 다른 몇몇 패킷에서도 이러한 문자열이 보였고 이것은 1400바이트로 Payload가 꽉 채워져 있었다. ‘JFIF’의 의미를 찾아보았더니 ‘JPEG File Interchange Format’였다. 이를 확인한 순간, 여러 가지 가능성이 머릿속에 떠올랐다. 자, 현재까지의 현황(fact)을 점검해 보자.
- UDP 트래픽이 항상 발생하는 것은 아니며 일시적으로 증가한다.
- Payload 중 JFIF 문자열이 포함돼 있고, 1400바이트를 채우고 있다.
- JFIF는 이미지 관련한 포맷이고, 해당 업체는 영상 관련 업체다.
- JFIF가 전달된 목적지 주소가 멀티캐스트 주소인 224.16.17.1이다.
이 사실을 기초로 추가 확인을 위해 JFIF가 발견된 패킷에서 ‘UDP Follow Stream’을 이용해 흩어져 있던 패킷을 하나로 모으고 바이너리 파일로 저장했다. 그리고 UDP 헤더는 파일에서 제거하고 이미지 파일 뷰어로 열어보니 [그림 4]와 같은 이미지가 나타났다.
[그림 4] JFIF가 포함된 패킷 파일 안에서 추출한 이미지 파일
이 때에는 직접 패킷을 조합해서 바이너리를 확인했지만, 지난호를 읽은 독자라면 Foremost 도구를 이용해서 쉽게 데이터를 추출할 수도 있다.
자, 여기서 중요한 것은 이미지 화면이 나타났으며 사무실 형태의 윤곽이 보인다는 것이다. 문제 해결의 실마리가 될 수 있는 결정적 단서이다. 이 결과를 가지고 업체에 확인해 보니, 장비 개발 시 테스트를 사무용 네트워크에서 같이 진행해 트래픽이 일시적으로 크게 증가한 것이었다. 즉, 문제의 원인은 보안 이슈가 아니라 전혀 엉뚱한 곳에 있었던 것이다.
이 사례는 내부 개발자들에 의한 일시적인 트래픽 증가를 전혀 의심하지 않고, 해킹을 당해 악성코드가 설치되고 통신에 의해 일시적으로 공격 명령을 내린다는 형태의 가설이 미리 설정돼 있었다. 처음 분석을 의뢰받았을 때, 그런 사전 정보를 기준으로 하다 보니 선입견이 생기고 혼선을 초래한 것이다. 문제의 원인을 미리 결론지어 놓고 분석을 진행하면 모든 과정을 정해진 결론에 끼워맞추는 오류를 범할 수 있다. 실제로 문제는 내부 요인에 의해 발생하는 경우가 많다. 패킷 분석 시에는 모든 가능성을 열어놓고 범위를 좁히면서 문제를 찾아나가야 한다.
2. 한 가지 원인으로 단정짓고 시작하지 말자
어떤 문제가 발생했을 때, 개발자는 소프트웨어를 더 유심히 들여다보게 되고 네트워크 관리자는 네트워크 관점에서 문제를 살펴보게 된다. 전체 관점에서 문제를 보지 못하고, 각 분석가의 관점에서만 바라본다면 문제의 근원을 찾아내기 어렵다. 잘못된 첫 단추는 분석을 어렵게 만든다. 단계적으로 차근차근 문제를 찾아나가야 한다.
다음의 사례는 필자가 운영하는 시스템의 예를 든 것이다. 자동으로 FTP를 연결해 파일을 전송하는 과정이 있는데, 언젠가부터 그 전송 과정이 눈에 보일 만큼 느려졌다. 네트워크든 FTP 소프트웨어든, 원인 발생지점에 해결책도 같이 존재하기 마련이다. 전체적인 관점에서 문제의 원인을 찾기 위해 다음과 같이 진행했다.
1) FTP 클라이언트와 서버 간 트래픽 확인
tcpdump를 이용해 트래픽 덤프를 시작한 후 수동으로 FTP 전송 프로그램을 실행했다. 아래와 같은 트래픽을 관찰할 수 있었으며 NBT UDP 패킷 쿼리를 발견했다. 이 쿼리는 14:21:18에 시작돼 14:21:21까지 지속됐다. 여기서 3초간의 지연이 발생했는데, 그 원인을 찾아야 했다.
2) nslookup으로 DNS 쿼리 확인
클라이언트에서 DNS resolving이 관련이 있을까 해서 nslookup을 실행해 보았으나 정상적으로 빠르게 응답했다.
3) NetBIOS와 관련한 것 찾아 제거해보기
일단 넷바이오스와 관련한 것이다 보니 시스템상에서 이와 관련한 것을 Disable한 후 같은 증상이 계속 일어나는지 확인하기로 했다. TCP/IP 설정의 고급에서 Wins → Disable TCP/IP Over Netbios를 선택하자 UDP 패킷이 발생하지 않았다. 하지만 NetBIOS 쿼리만 발생하지 않았을 뿐이지 FTP를 다시 연결해봐도 Delay는 또 발생했다. 이전에 나타났던 트래픽은 나타나지 않았지만 지연은 계속되고 있는 것이다.
시스템 관점에서 몇 가지를 확인해 보아도 증상은 해결되지 않았다.
4) 마지막으로, 응용 프로그램을 직접 디버깅
호출되는 FTP 응용 프로그램을 직접 디버깅해서 무엇이 원인인지 세부적으로 접근해보고자 하였다. 사용한 디버거는 Ollydbg이며, 실행하면서 각 코드별로 Delay되는 부분은 없는지 찾아나갔다. 이를 통해 0x0040A5E3 지점에서 Delay가 발생하는 것을 알 수 있었다.
[그림 5] Ollydbg에서 확인한 접속 지연
gethostbyaddr를 Call하면서 발생된 문제였던 것이다. 여기서 5~10 초 정도의 지연이 발생했던 것인데, 이후 사용하는 DNS에서 Reverse DNS 레코드를 추가했더니 문제가 깔끔히 해결됐다.
물론, Delay가 발생해도 시스템 동작에는 큰 이슈가 없었다. 그러나 이런 지연 요소는 향후 시스템 전체 과정에 영향을 줄 수 있기 때문에 확실히 해결하고 넘어가는 것이 좋다.
여기서 짚고 넘어가야 하는 것은, 직접적인 한 가지 원인으로만 단정짓고 분석을 시작하지 말라는 점이다. 문제 해결을 위해 전체를 들여다보고 분석하는 과정에서, 트래픽에서 발견된 특정 패턴을 문제의 원인이라고 가정해 버리면 접근 관점이 한정돼 문제 해결에 시간이 걸리게 된다. 위에서 발생한 UDP 쿼리 패킷만 보고 시스템과 네트워크 관점에서 문제의 원인을 찾다보면 해결이 어려워진다는 것이다. 결국은 gethostbyaddr에 의해 발생돼 네트워크와도 연결되기는 했지만, 필자가 강조하고 싶은 것은, 문제의 원인을 파악하기 위해서는 직접적인 원인은 물론, 문제에 대한 거시적인 시각도 필요하다는 것이다.
3. TCP SYN 패킷의 급격한 증가, 무엇이 원인인가?
서비스 거부 공격(DoS : Denial of Service)의 대표적인 것 중 하나가 SYN Flooding이다. TCP 통신 연결 과정의 3-Way HandShake 중 SYN을 대량으로 생산해내는 것이다. 흔히, 속도 지연의 주 요인은 이러한 트래픽의 일시적인 증가에서 찾을 수 있다. 다음과 같은 사례도 공격 명령을 전달받아 SYN 공격을 수행한 경우이다.
트래픽이 과도하게 증가해 분석해보니 SYN Flooding 발생의 사전 단계가 존재함을 확인할 수 있었다. SYN 패킷이 연속적으로 발생하기 전 단계를 보면 attackSchedule.php 접속 후에 발생하는 것으로 추정할 수 있다. 파일 이름에 공격 정보가 담겨 있는 것으로 볼 수 있으며, 이 파일 정보에 의해 공격이 정해진다.
[그림 6] TCP SYN Flooding 공격 화면
attackSchedule.php가 어떤 내용인지 살펴보기 위해 wget을 이용해 [그림 7]과 같이 내려받아 보았다.
[그림 7] wget를 통해 확인해 본 attackSchedule.php
콤마(,)로 구분된 6개의 인자가 보이는데, 1255446000은 타임스탬프 형식인 것으로 추정된다. 이런 타임스탬프에 익숙하다면 문자열을 보고서도 이것이 시간을 나타내는 것임을 생각해 볼 수 있을 것이다. 실제 이 타임스탬프를 변환해 보면 다음과 같다:
1255446000 : 2009년 10월 14일 12:00:00 AM
1256828400 : 2009년 10월 30일 12:00:00 AM
즉, 공격의 시작과 종료 시간임을 추정해 볼 수 있다. 다음에 이어지는 것은 공격 대상지의 URL과 포트 번호다.
네트워크에서 덤프한 이 패킷 정보만 가지고 만들어 볼 수 있는 시나리오는 다음과 같다.
1) AttackSchedule.php 후에 SYN Flooding 공격이 시작됐다.
2) 공격은 2009년 10월 14일 12:00부터 2009년 10월 30일 12:00까지이다.
3) SYN 공격은 출발지가 Spoofing된 랜덤 주소를 가지고 있고, 공격 대상은 한 곳이다.
4) AttackSchedule.php에서 공격 시작/종료 시간과 대상을 전달받는다.
5) 공격이 시작된 클라이언트는 111.2.0.35이며, 이곳은 악성코드에 감염됐을 것으로 추정된다.
이와 같은 시나리오에 근거하여 관리자는 문제를 해결하기 위해 클라이언트인 111.2.0.35를 네트워크에서 일시적으로 분리하고, 내부 네트워크에서 또 다른 공격 명령을 받아올 수 있으므로 118.159.239.125를 차단한다. 그리고 111.2.0.35 IP의 컴퓨터를 조사해 악성코드를 제거하게 될 것이다. 마지막으로, 어떻게 감염되었는지 역추적하여 재감염을 막을 수 있도록 검토해야 한다. 단순히 현재의 문제 해결에만 집중하고 문제의 근본 원인을 조사하지 않는다면 재발 가능성이 높으므로 주의해야 한다.
이 사례에서 배울 점은, 패킷 발생 전후 관계를 살펴 문제 발생의 원인을 찾아볼 수 있다는 것이다. 문제가 시작된 시점을 파악하고 그 때부터 거꾸로 찾아나가야 한다.
4. 의심스러운 파일 다운로드, 확장자를 너무 믿지 말자!
흔히 파일의 확장자를 보면 그 유형을 알 수 있다. DOC 파일은 워드 파일이고, HWP는 아래아한글, HTML은 웹 파일임을 알 수 있다. 또 JPG, GIF, PNG는 대표적인 이미지 파일들이다. [그림 8]은 특정 도메인에 대한 DNS 쿼리가 발생하고 그 후에 HTTP 프로토콜을 통해 bit.gif를 내려받은 예다.
[그림 8] 확장자를 이미지 파일로 위장해 내려받는 악성코드 트래픽
패킷 자체만 보면 정상적인 웹 트래픽으로 의심할 여지가 없다. 정상 트래픽으로 간주하고 넘어가기 쉽지만, bif.gif를 조금 더 들여다보면 이것이 이미지 파일이 아님을 알 수 있다. [그림 9]와 같이 이미지 파일을 내려받아 파일의 유형을 살펴보니 이미지가 아니라 ASCII 텍스트 형태로 판단된다. 해당 파일에서 임의의 문자열들을 발견할 수 있다.
[그림 9] 내려받은 bit.gif 파일의 유형과 내용을 살펴본 화면
위와 같은 문자열 스타일만 보고서도 ‘아, 이것은 인코딩 되어있구나’ 하고 알아챌 수도 있을 것이다. ‘아니, 이걸 어떻게 알지?’ 하고 반문한다면, 필자가 앞서 패킷 분석에는 경험 또한 중요하다고 이야기한 것을 상기하기 바란다. 이 문자열들은 BASE64로 인코딩돼 있는데, 이것은 이메일 전송 시에 많이 이용되는 인코딩 중의 하나이다. 만약 이러한 것을 모른다면, 이것을 알아내고 해독하기까지 적지 않은 시간이 필요했을지도 모른다. 다양한 경험이 그만큼 중요한 것이다.
BASE64로 인코딩돼 있는 것을 확인했으니 [그림 10]과 같이 해독하면 된다. 디코딩을 수행하니 임의의 문자열에서 정형화된 문자열이 나타났다. 설정 파일 형태로 추정되는 내용으로 악성코드가 이것을 이용해서 동작하는 것으로 추정할 수 있다.
[그림 10] base64로 인코딩된 bit.gif 파일을 디코딩한 화면
bit.gif가 실제로는 이미지 파일이 아니고, 문자열 내용도 인코딩돼 있는 것으로 보아서는 정상적인 형태로 간주하기 힘들다. 네트워크 내에서 이와 같은 형태가 관찰되는지 확인하기 위해 ngrep을 통해 추가 확인할 수 있다.
# ngrep “GET /bit.gif”
패턴 확인을 통해 추가로 또 다른 클라이언트를 찾아볼 수 있다. 또한, 다운로드되는 곳의 IP를 방화벽에서 차단해 확산을 예방할 수도 있다. 문제를 파악한 후 패킷을 분석해 이와 같은 식으로 사후 처리는 할 수 있다. 하지만, 앞서 bit.gif가 악의적인 것은 어떻게 알아냈을까?
사실 bit.gif뿐만 아니라 이 예제에서는 실제 패킷 분석을 통해 얻은 정보를 가지고 활용하는 방법을 설명하고 있다. 그러나 처음 문제를 인지하고 이러한 과정을 순차적으로 적용해 원인을 찾아내기까지가 쉽지 않다.
모든 상황이 경우에 따라 다르므로 정형화하기는 힘들지만, 증상이 나타나고 나서야 조사에 착수하는 것이 일반적이다. 물론, 주기적인 모니터링으로 사전에 문제를 발견하고 원인을 해결하는 것이 가장 좋다. 증상을 발견하고 나면 해당 증상을 기준으로 패킷을 살펴보거나 의심스러운 패턴들을 걸러내야 하는데, 이 작업에 많은 시간이 걸린다. bit.gif로 보면 해당 파일을 다운로드하기 전 발생한 도메인 요청에서 힌트를 얻을 수 있다.
수집된 패킷 파일에서 여러 가지 형태를 파악하는 중에 도메인을 확인하는 과정이 있었다고 가정해보자. 해당 도메인 이름에서 일반적이지 않은 도메인 이름을 대상으로 그 앞뒤 패킷을 확인한다. 도메인 요청 후에 나타나는 행동과 다운로드되는 bit.gif 파일의 패킷 데이터가 이미지가 아니라 인코딩된 문자열이었다면 더욱 의심스럽다.
5. 패킷 분석을 통해 대응 능력을 갖출 수 있다
웰치아(Win32/Welchia.worm) 웜은 윈도우의 RPC DCOM 취약점을 이용해 전파되는 것으로, 감염되면 ICMP 패킷을 전송하면서 살아있는 시스템을 찾는다. 2003년에 보고된 것이지만, 이 당시의 네트워크 증상을 경험 삼아 공유하면 도움이 될 것 같다.
대표적인 트래픽 증상은 ICMP를 발생시키고 스캐닝으로 인하여 ARP 트래픽도 함께 증가한다는 점이다. [그림 11]과 같이 ICMP 유형이 8번인 ‘Echo Request’를 발생시켰다. 하지만 ICMP, ARP는 일반적인 네트워크 상황에서도 발생되는 것인데, 무엇이 다르다는 것일까?
[그림 11] 웰치아 웜에 감염된 패킷
다른 부분이 무엇인지 찾아내야 하는 것이 바로 여러분의 몫이다. [그림 11]의 패킷을 보면 ARP 패킷 요청 IP 주소가 연속적으로 이어진다. 같은 시간대에 연속적인 주소로 이렇게 발생시킨다는 것은 스캐닝과 같은 형태일 가능성이 크다. 또, ICMP 패킷을 세부적으로 들여다보면 [그림 12], [그림 13]과 같이 볼 수 있다.
[그림 12] 웰치아 웜이 발생시킨 ICMP 패킷의 Payload
[그림 13] 웰치아 웜이 발생시킨 ICMP 패킷의 헤더 정보
Identifier 값이 0x0200으로 고정돼 있고, Payload 크기가 64바이트로 동일하다. 거기다가 데이터 값이 0xaa로만 채워져 있다. 만일 윈도우 시스템을 사용한다면 ping을 실행해보고 패킷 데이터를 살펴보라. abcdefg와 같은 값을 볼 수 있을 것이다. 윈도우에서 사용하는 경우는 이와 같은 유형을 가지고 있지만, 0xaa로 64바이트가 다 채워져 있다는 것이 이상하다.
[그림 14] 윈도우 ICMP 패킷
이런 정보를 기준으로 내부에서 발생한 악의적 행동들에 대해서 판단할 수 있고, 자체적으로 방화벽이나 IPS 등의 패턴을 만들어 빠르게 대응할 수 있다. 더불어 네트워크상에서 이런 형태의 패킷이 나타났다면 웰치아 웜에 감염됐다고 판단할 수 있다.
트래픽의 양도 파악해 네트워크 장비들에 어떤 영향을 끼칠 수 있는가 예측해 볼 수 있다. 가령 웰치아 웜의 경우 크기가 92바이트다. C 클래스 대역에 패킷을 보내는 데에는 4초 정도의 시간이 소요됐고, 대략 초당 5.9K, 분당 353K 정도의 트래픽을 유발했다. 서비스 거부 공격에 이용되는 트래픽에 비하면 적은 양으로, 과도하게 네트워크 장비에 영향을 줄 수치는 아니다.
악성코드 트래픽 분석만으로도 여러분 스스로 초도 대응을 할 수 있다는 점을 잊지 말라.
6. ARP 스푸핑, 응답을 무조건 신뢰하지 마라
ARP(Address Resolution Protocol)는 IP 주소와 맥(MAC) 주소를 연결해 주는 역할을 한다. 이로 인해 우리는 통신을 할 수 있는 것이다. 하지만, ARP 패킷은 인증 과정이 포함돼 있지 않고 무조건적으로 ARP 패킷을 수용한다는 데에 문제가 있다. 이는 내부 네트워크 장애를 유발할 수 있으며, 데이터 스니핑에 의한 정보 유출, 악성코드 유포와 같은 문제를 안고 있다. 실제로 악성코드에서 ARP 스푸핑을 이용해 문제가 발생되는 사례를 살펴보자.
111.2.0.1이 게이트웨이이며, 111.2.0.37은 공격자 PC로 조작된 ARP 스푸핑 패킷을 전송해 111.2.0.35 클라이언트의 게이트웨이 주소를 111.2.0.37로 변경했다. 게이트웨이가 변경됨에 따라 111.2.0.35에서 발생되는 모든 트래픽은 111.2.0.37을 경유하게 되며, 공격자는 중간에서 트래픽을 위•변조할 수 있게 된다.
[그림 15] 게이트웨이 주소인 111.2.0.1의 주소가 변조된 패킷 화면
정상 클라이언트의 컴퓨터에서 ARP 주소를 살펴보면 공격자의 맥 주소인 00-11-d8-c3-33-63으로 기본 게이트웨이 주소가 변조된 것을 [그림 16]과 같이 확인할 수 있다.
[그림 16] 윈도우 도스 창에서 확인한 ARP 테이블 변조
7. 알 수 없는 데이터 값, 이것의 의미는 무엇일까?
실질적인 패킷 데이터는 Payload에 많이 담겨있는데, 문자열만으로도 의미를 파악할 수 있는 것이 있지만 암호화된 데이터나 공격 코드 등은 눈으로만 보고 판단하기가 어렵다. 더욱 깊게 패킷을 분석한다면 이런 이진 바이너리 데이터에서도 의미 있는 정보를 추출할 수 있어야 한다. [그림 17]은 WMF(Windows Metafile) 포맷에서 발견된, 취약점이 전송되는 패킷 화면을 잡아본 것이다.
[그림 17] WMF 취약점을 이용한 파일 전송 패킷 화면
이 바이너리 코드만 보고서는 어떤 내용인지 알기 힘들다. 만약 이런 형태의 분석에 익숙하다면 HEX 코드의 흐름만 보아도 의심스러워질 것이다. 90 90 90과 같은 NOP 코드와 그 아래 이어지는 반복되는 어떤 유형들이 공격 유형과 비슷하기 때문이다.
이 데이터를 디버그 같은 곳에서 분석하기 위해서는 코드 형태로 바꿔주어야 하는데, 가장 쉬운 방법은 해당 코드를 실행 파일 형태로 만들어주는 것이다. 와이어샤크에서 해당 데이터가 있는 패킷에서 Follow TCP Stream을 선택하고 C Arrays 옵션을 선택해 보자. 그러면 C 어레이 형태로 [그림 18]과 같이 만들어진다.
[그림 18] 와이어샤크에서 TCP Stream 데이터를 C Array로 변환
그 코드를 가지고서 다음과 같이 컴파일해주면 된다.
제일 상단의 wmf_bin 부분은 와이어샤크에서 만들어주는 데이터이고, main 부분만 가져다 사용하면 된다. 컴파일하여 만들어진 실행 파일을 Ollydbg와 같은 프로그램에서 로딩하여 90 90 90이 있는 위치부터 분석을 시작하면 된다. [그림 19]는 Ollydbg에서 로드하여 의심스러운 Payload 데이터부터 코드를 살펴본 것이다. NOP 코드가 보이고 00402091 번지까지는 정상적인 기계어 코드로 보이지만 이후는 조금 달라 보인다. 코드 자체가 0x1C9만큼 XOR되어 있기 때문이다.
[그림 19] XOR되어 있는 코드를 해독하는 루틴의 셸 코드
그 값을 풀어내면 [그림 20]과 같이 원래의 코드와는 다른 정상적인 코드가 나타난다.
[그림 20] XOR 88로 해독되어 나온 정상 기계어 코드
이 Payload 데이터는 셸 코드이며 특정 포트로 바인딩하여 백도어를 생성한다. 패킷 데이터 분석을 통해 이것이 어떤 의미의 데이터인지 알아낼 수 있게 된 것이다. 이 예제는 필자가 특정 데이터를 기준으로 해서 실질적으로 Payload를 해독하는 과정을 보여준 것이지만 수많은 패킷 데이터에서 의심스러운 Payload를 찾아내고 그것을 분석하는 것은 쉽지 않은 과정이다. 여기서는 Payload를 그냥 바이너리 데이터로만 보지 않고, 정보를 추출해 낼 수도 있다는 방법에 의미를 두면 되겠다.
패킷 분석, 많은 경험이 필요한 이유는?
3부로 나누어 네트워크 포렌식 분석에 대한 방법과 경험을 공유해보았다.
필자가 생각하는 패킷 분석의 범위는 넓다. 수만 개의 프로토콜이 존재하고, 기업마다 각기 다른 네트워크 환경과 구성, 그리고 그 위에서 돌아가는 수없이 많은 애플리케이션들이 고속화된 네트워크 인프라 위에서 동작하고 있다. 그러므로 모든 것을 다 알 수는 없다. 그러기에 패킷 분석에는 폭넓은 경험이 필요한 것이다.
몇 가지 사례만으로 패킷 분석 방법을 설명하기에는 너무나 부족하다. 고객의 네트워크 환경과 내부 구성, 그리고 다양한 응응 프로그램들은 복잡함을 더해주고 있기 때문에 여기서 소개한 사례는 아주 일부분에 불과할 것이다. 비록 작은 경험이지만, 이 경험들이 여러분의 패킷 분석 과정의 길잡이가 되었으면 한다.
앞서 언급한 것과 같이 끈기와 의지로 패킷 분석의 다양한 경험을 쌓는다면 여러분은 전문가가 될 수 있을 것이다.
더 많은 정보를 원한다면, 필자가 운영하는 블로그인 ‘패킷인사이드(PacketInside.com)’를 방문해보길 추천한다.@
- 안철수연구소A-FIRST 정관진 책임 연구원
