안철수연구소에서 알려주는 실전 패킷 분석

2012.02.11

 

안녕하세요. 안랩인입니다. 패킷 분석 도구가 다양함에도 불구하고 한두 가지의 도구만으로 패킷을 분석하려는 경우가 많습니다. 하지만, 활용할 수 있는 도구는 매우 다양하고, 패킷 파일에서 찾고자 하는 정보를 빨리 얻을 수 있는 효율적인 방법도 있음을 지난호에서 설명했습니다.
그러나, 다양한 패킷 분석 도구가 있다고 해서 모든 분석을 쉽게 해낼 수 있는 것은 아니다. 그래서 이번 호에서는 몇 가지 사례를 살펴봄으로써 패킷 분석 경험을 함께 나눠보고자 합니다.

 

누군가 이미 경험했던 것을 공유하고 배우는 것은 소중합니다. 내가 경험해보지 못한 것을 간접적으로나마 접할 수 있기 때문입니다. 여러 관점에서 사례를 분석함으로써 새로운 경험을 해보고, 이러한 경우에 자신은 어떤 식으로 했을까 하고 생각해보는 시간을 가져보겠습니다.

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에 의해 발생돼 네트워크와도 연결되기는 했지만, 필자가 강조하고 싶은 것은, 문제의 원인을 파악하기 위해서는 직접적인 원인은 물론, 문제에 대한 거시적인 시각도 필요하다는 것입니다. <Ahn>

* 더 자세한 내용은 안랩홈페이지를 참고하세요