패킷파일을 다루다 보면 보통은 우리가 패킷파일을 오픈하고 살펴볼 수 있는 크기의 파일이 많다.
너무 파일이 커 버리면 분석하는것 자체도 힘들기 때문에..

[관련글] 2010/01/27 Rigel 100 기가 가 넘는 패킷 파일이라고 ? 

그런데 때로는 패킷파일이 생각 이상으로 커지기도 한다. 필자가 이전에 쓴 포스팅에서는 100 기가가
넘는 패킷파일도 있었다고 이야기 하였다. 이번에는 그 정도까지는 아니지만, 대략 2기가가 넘는 파일을
읽어 들이려고 했을때 아래와 같은 에러 메시지를 얻을 수가 있다. (물론, 와이어샤크를 기준으로 했을때이다)

capinfos: Can't open /tmp/test.pcap: Value too large for defined data type

와이어샤크에서는 기본적으로 2기가 이상의 파일을 읽어들일 수가 없다. 이유는 int32 값을 사용하고 있기 때문인데, int32 의 값 범위는 아래와 같다.

−2,147,483,648 to 2,147,483,647

그래서 2기가 정도로 제한된 것이다. 일단 간단하게 나마 해결책은 64비트로 변경해 주는 것이다. 새롭게 다시 컴파일을 해 주면 되는데 아래와 같이 설정후에 컴파일을 다시 해 보자.

CFLAGS=-D_GNU_SOURCE\ -D_FILE_OFFSET_BITS=64 ./configure --enable-wireshark=no --without-zlib


            Build profile binaries : no
                   Use pcap library : yes
                   Use zlib library : no
                   Use pcre library : no
               Use kerberos library : no

./configure 다음의 옵션은 여러분들의 필요에 따라 맞게 사용하면 되고, 중요한 것이 앞쪽에서 CFLAGS 에 설정한 FILE_OFFSET_BITS 를 64로 설정한 것이다. 64 비트로 했을때의 값은 아래와 같다.

−9,223,372,036,854,775,808 to +9,223,372,036,854,775,807

큰 파일을 오픈하는데는 걱정하지 않을 수준이다.

컴파일을 하고, 파일을 읽어보자. (여기서는 tshark 를 사용하지 않고 기본 정보를 얻기 위해 capinfos 를 사용하였다.)

# ./capinfos  /tmp/test.pcap
File type:           Wireshark/tcpdump/... - libpcap
File encapsulation:  Ethernet
Number of packets:   2936376
File size:           3062134522 bytes
Data size:           3015152482 bytes
Capture duration:    310 seconds
Start time:          Tue Aug 31 05:10:43 2010
End time:            Tue Aug 31 05:15:53 2010
Data byte rate:      9737875.87 bytes/sec
Data bit rate:       77903006.99 bits/sec
Average packet size: 1026.83 bytes
Average packet rate: 9483.46 packets/sec

짜잔. 위 예와 같이 3기가 파일도 이제는 오픈이 된다.  이와 관련한 비공식 패치는 아래 참고의 2번을 참고하기 바란다.

[참고]
1. 2147483647
2. 와이어샤크 int32 패치
윈도우에서 사용 가능한 프로세스 네트워크 모니터 도구가 있어 소개한다. 여러가지 도구들이 있긴 한데, 오늘은 이 도구가 사용하기도 아주 쉽고, 유용할거 같다는 생각이 든다. 윈도우에서 악성코드에 감염되었다고 가정해보자.  그리고, 트래픽 확인을 위해 와이어샤크를 통해 네트워크 트래픽이 발생되고 있음을 확인한다. 그런데, 윈도우의 어떤 프로세스가 이 트래픽을 유발하고 있는지 알기가 어려운 것이다. 특정 프로세스에서 발생하면 쉬운데,
정상 서비스 프로세스에 인젝션 되어 발생되면 까다로워진다.

아래 프로그램은 각 프로세스별로 TCP, UDP, 연결 카운트를 보여주고 있다. 즉, 이 카운트가 크게 증가되었거나 하면 해당 프로세스를 의심해 볼 수 있다. 프로세스를 클릭하여 살펴보면, 어디로 연결되었는지 세부 정보를 확인해 볼 수가 있다. 이 도구의 사용방법을 설명할 것도 없이 워낙에 심플해서, 처음 이런류의 프로그램을 접하는 분들이라도 알 수 있을 정도이다.


Properties 를 누르면 프로세스에 대한 속성을 확인해 볼 수 있으며, Export 를 하면 프로세스 리스트를 HTML 파일로 저장할 수 있다.  다운로드는 다음의 경로에서 할 수 있다.


그리고, 이 프로그램이외에 분석에 유용하게 사용할 만한 도구들도 몇가지 있으므로, 한번 살펴보기 바란다.
패킷을 분석하는데는 그 목적이 있고, 그 목적을 달성하기 까지는 용도에 따라서 이러한 도구가 유용하게 사용될 것이다.

NMAP 에서 재미있는 리서치 결과를 내 놓았다. NMAP 시큐리티 스캐너와 스크립트 엔진을 이용해 뉴욕타임즈, 구글, 엔가젯 같은 수 많은 사이트를 스캐닝 하였다.
스캐닝은 HTML 링크의 아이콘 태그의 파일과 /favicon.ico 를 하였는데, Unique 하게 수집된 아이콘 파일이
328,427 개 였다고 한다. 이중 288,945 개가 적합한 형태의 이미지였는데, 이걸 종합적으로 합쳐 아이콘을
이용한 맵을 만들었다. 아이콘이 클수록 규모도 크다고 볼 수 있는 것이다.  아이콘을 보게되면 역시나
구글이 가장 큰 크기를 차지하고 있고, 그 다음으로는 페이스북, 유투브, 야후, MSN 등이 크다.

[이미지 출처 : NMAP 사이트 ]

우선 Favicon 을 이용해 지도를 만들었다는 사실이 참 재미있다. 그럼 여기서 사용한 스크립트는 무엇일까?
웹 페이지에서 Favicon 아이콘을 얻는 이 스크립트는 HTTP-Favicon.nse 이다. 이 스크립트는 다음 두가지
방법을 통해 아이콘을 확인한다.

- HTML 파일의 <link rel="icon"> 태그를 파싱
- /favicon.ico 확인

NMAP 에서의 스크립트 사용은 아래와 같다 :

nmap --script=http-favicon.nse --script-args favicon.root=<root>,favicon.uri=<uri>

스크립트를 만드는데 이용된 언어는 Lua 이다. 와이어샤크에서도 바로 이 Lua 가 이용된다.
시간이 주어지는대로 와이어샤크와 NMAP 에서의 스크립트 사용에 대해서 한번 소개할 예정이다.

아참, 그리고 Favicon 아이콘을 모르시는 분들을 위해:
이 아이콘은 브라우저 주소창에서 앞쪽에 표시는 작은 아이콘이다. 패킷인사이드에도 보면
주소창앞에 패킷인사이드 로고가 나오는데 바로 이것이다.

[1] WWW 아이콘 지도
[2] HTTP-Favicon NMAP 스크립트
[3] Favicon 이란?
6월초 와이어샤크 1.4.0rc1 버전이 공개된 후, 드디어 1.4.0 정식버전이 공개되었다.
정식버전과 함께 1.4.0rc2 버전도 공개되었으니, 이제 1.2.X 를 뒤로 하고,
1.4.0 의 새로운 기능들을 느껴보기 바랍니다.

몇가지 변경된 기능에 대해서는 저번 1.4.0rc1 에서 소개한적이 있고요,


다운로드는 다음의 경로에서 가능합니다.

세부적인 릴리즈 노트는 다음을 참고하세요.

[주요변화]
  • 와이어샤크의 메인 화면에서 컬럼을 쉽게 이동할 수 있거나, 오른쪽 클릭을 통해 조정이 가능
  • 파이썬 스크립트 지원
  • 많은 부분에서 메모리 누수 버그 Fix (그래서 그런가, 처리가 조금 자연스러운듯)
  • 와이어샤크 1.4 버전에서는 윈도우 2000을 지원하지 않음. 그러므로 윈도우 2000 에서는 1.2 나 1.0 버전을 이용해야 함
  • Manually Resolve Address 기능
  • 유용하게 이용할 수 있는 부분인데, IP 를 특정 이름으로 변경시켜 놓을 수 있다. 예를들어, 172.16.1.254 라는 것을 쓰고 있다면 이 기능을 통해 Internal Router 이런식으로 바꿀 수 있다.
  • 'Ignore Packet' 기능, 필요없는 패킷에서 오른쪽 클릭을 통해 무시해 버릴 수 있다.
  • 시간 표시가 이제는 시:분:초 형태로 출력된다.
  • 유닉스와 리눅스 환경의 와이어샤크에서 캡쳐 버퍼 사이즈를 설정할 수 있다.
  • 와이어샤크에서 바로 JPEG 파일을 오픈할 수 있음
    JPEG 파일을 와이어샤크로 던져보면 알 수 있다.
  • 새로운 프로토콜 지원
  • 이외 기타 등등
첫번째 CaseStudy 를 소개한다. 어떤 것을 소개할까 하다, 일반 기업에서 발생한 사례 하나를 소개해
보고자 한다. 흔히 요새는 알수없는 트래픽이 급격히 증가하면, 이거 악성코드에 의한 것이 아닐까 하고
생각하는 경우가 많다. 과거와는 달리 악성코드에 의한 트래픽 영향을 겪어 봐서 그런가 이런 의심부터
시작하고 분석을 거기에 초점을 맞추는 경우가 있다.

이번 Case도 누가 해킹하여 발생한 것이 아니냐, 악성코드를 심어 놓은 것이 아니냐 하는 의견이 있었다.
일단 분석대상인 이 패킷에는 다음과 같은 다양한 트래픽이 포함되어 있었다.

- ARP
- NetBIOS
- UDP
- 일반 사용 트래픽 (웹 과 같은)

그중에서도 가장 유독 눈에 띄게 관찰되는 부분이 UDP 였다. 그런데 증상은 항상 지속적으로 나타나지
않는다는 점이며, 일시적으로 나타났다 사라진다고 한다. 사실 지속적 증상없이 이렇게 일시적으로만
나타나는 경우가 분석에 제일 곤란한 부분이다.


패킷파일은 우선 와이어샤크로 분석을 진행했다. Protocol Hierarchy Statistics 로 발생한 트래픽을 살펴보니
UDP 의 사용이 가장 컸고, 그래프를 만들어 살펴봐도 위 그림과 같이 UDP 가 차지하는 비중이 꽤 높게 나타났다. 전체적인 관점에서 보다보면 이 외에도 다른것 까지도 다 의심의 범위에 속하긴 하였지만,
여기서는 일단 범위가 UDP 로 조금은 좁혀진 상태에서 이야기 하도록 한다.

UDP 를 살펴보니 두가지 종류 형태의 UDP가 관찰되었다.

- DATA 가 256 바이트인 UDP 이며 255.255.255.255 로 브로드 캐스트 주소 (목적지)
- Payload 를 1400 바이트로 채운 UDP

패킷파일 화면 일부를 보면 아래와 같이 이상하게 보일만큼 단시간내에 많은 내용이 있었다.

워낙에 많은 데이타 이다 보니 주욱 대충 살펴보면 DATA 상에서는 의심스러운 문자열 같은건 발견하지 못했다.
여러분도 아시겠지만, 데이터가 아주 큰 경우는 세밀하게 분석하자면 한도 끝도 없다. 전체적인 관점에서
먼저 살피는데, 알수없는 문자열들의 조합으로만 이루어져 있어 눈에 잘 들어오지가 않는다. 그런데 필자의
눈에 하나 잡힌 것이 있었다. 바로 아래와 같은 문자열이다.

헤더 첫 부분에서 JFIF 라는 문자열이다. 검색해 보았더니, JPEG File Interchange Format 이란다. 그럼 이미지 형태의 데이터가 아닐까 추측을 해 보았다.
왜 이렇게 더 생각할 수 있었던 이유는 이 패킷을 전달받은 곳이, 하드웨어적인 영상을 찍는 업체였기 때문이다. 그럼 느낌이 오지 않는가 ?
- 일시적으로 UDP 패킷이 크게 증가하는데,
- UDP 페이로드가 JFIF 관련한 것이고
- 패킷덤프를 뜬 곳이 이런 영상 관련 업체라는 점.

일단 UDP Follow Stream 을 통해 연결된 패킷을 모으고, 해당 데이터를 바이너리로 저장해 보았다. 물론, UDP 와 관련한 헤더는 수동으로 제거 시켜버렸다. 그리고 이미지 뷰어를 통해 살펴보니, 아래와 같은 이미지가 나타난다.
아니, 이건 무엇인가? 얼핏봐도 이미지 파일인걸로 추정해 볼 수 있으며, 사무실 형태의 윤곽이 잡힌다. 문제해결에 실마리가 될 결정적 단서가 될수도 있는 것이다. 전달된 UDP 데이터를 완벽하게 복원하지는 않았지만, 대략 복구해 낸 것으로도 이미지임을 알 수 있었다. 이렇게 분석해 낸 정보로 정리했는데, 확인 결과
개발자들의 테스트가 사무용 네트워크에서 일어나며 트래픽이 크게 발생된 것이었다.

즉, 발생된 내부에서는 내부 개발자들에 의한 일시적인 트래픽 증가로 의심하지 않았고,
다른 분석가들에 의해 내부 해킹되어 악성코드가 심어져 있어 통신에 의해 일시적으로 공격명령을 내린다는
형태의 가설이 설정되어 있었던 것이다. 처음 분석 의뢰를 받았을때, 그런 사전 정보를 기준으로 하다보니
혼란스러운 부분이 있었다.  결과의 원인을 해킹/악성코드 이슈로 정의해 놓고 분석을 하다 보니, 모든 관련된
것을 그쪽으로 맞춰 생각하기 쉬어질 수 있다.  

실제로 분석을 하다 보면 내부의 원인에 의해 발생되는 문제가 크다. 해당 담당자들이 내부에서 발생되는
트래픽을 정확히 이해하고 있다면 좀더 빠른 접근을 통해 해결될 수 있었을 텐데, 아쉬운 부분이기도 하다.
내부적으로 우선 발생한 것이 아닌지 면밀한 조사가 선행되어야 분석이 빨라지게 된다. 의뢰받아
분석을 하는 분석가 입장에서는 그곳의 네트워크 구성과, 어떤 형태의 트래픽이 발생되는지 등등의 형태를
모르기 때문이다. 그러므로 처음부터 분석해 나가며 하나씩 다 파악해야 하다보니 분석이 더디어 지게 된다.

물론, 특징적인 형태가 한눈에 보인다면 쉽게 해결될 수도 있겠지만, 엄청난 트래픽 데이터와 싸우려면
여간 지치는게 아니다. 하여튼 이번 CaseStudy 사례는 기업에서 급격히 발생한 UDP 트래픽이 있었고,
초기에 다른분석가들에 의해 악성코드에 의한 것으로 좁혀졌지만, 실제 패킷 포렌직을 통해서 확인해 보니
내부 개발자들에 의해 발생된 트래픽으로 확인이 된 것이다.

어떻게 첫번째 CaseStudy 가 여러분들에게 도움이 되었는지 모르겠다.

[참고]
1. JPEG File Interchange Format

이전 1 2 3 4 5 ... 27 다음