2011년 6월 27일 월요일

자동화된 패킷분석의 어려움을 이야기 해보자!

패킷분석을 주 업무로 하는 사람이라면, 그들만의 도구를 가지고 있거나 방법이 있을 것이다. 특히나 분석할 패킷파일 대상이 많다면, 더욱 더 자동화된 기능이 필요하다. 하지만, 자동화된 방법으로 개발하여 사용하다 보면 어려움이 많이 발생할 경우가 많다. 대표적인 것이, 주어진 프로토콜 형식에 맞지 않는 패킷파일이다.

이건 보안적인 관점에서 봐도 발생되는 같은 이치인데, 대표적인 SQL Injection 을 생각해 보자.
웹 개발을 할때, 개발자가 생각한 것 이외의 값이 들어오지 않을 것이라 가정하고, 개발하면서 보안적인 문제점이 생긴다. 프로그램 관점에서 정해진 폼에 따라 사용자가 데이터를 입력하면 아무런 문제가 없을 것이다. 하지만, 사용자가 인자값을 직접 수정할 수도 있다는 가정이 되어야 한다. 인자값을 임의로 수정해 전송해 버리면, 프로그램에서는 그 값에 대한 체크가 없는 이상 사용자가 정상적으로 입력한 값으로 인지해 버려 SQL Injection 과 같은 취약점이 발생되어 버린다.

패킷파일도 마찬가지이다. 나 또한 보안적 관점에서 패킷 파일 분석을 수행하다 보면,이 패킷파일들이 별에별 형태로 다양하다는 것이다. 악성코드가 생성한 패킷파일이면 더욱 그러하다. 예를 들어, DNS 는 UDP 53 번을 기본으로 사용한다. 그리고 Zone Transfer 와 같은 상황등에서는 TCP 53 번을 사용하기도 한다. 흔히, UDP 53 번을 사용하면 DNS 데이터라고 가정한다. 그런데, DNS 가 아닌 어뚱하게도 어떤 통신을 위해 사용되는 것이라면 어떨까? DNS 쿼리 데이터의 일정 값을 사용하는데 이상하게도 알수없는 페이로드로 채워져 있다면 말이다.

패킷분석을 수행하는 도구 입장에서는 DNS 로 판별했는데, 실제 데이터가 정확하지 않아 Exception 과 같은 오류가 발생할 수 있다. 이런류의 패킷파일 데이터 판단은 힘들어지는데, 실제 이 패킷 데이터를 알아내기 위해서는 직접 악성코드를 리버싱을 해야 정확한 데이터 의미를 파악할 수 있게된다.

비정상적인 DNS 데이터를 가지고 있는 패킷파일을 Scapy 를 통해서 확인해 보면 아래와 같다.

>>> a=rdpcap("test_dns.pcap")
WARNING: wrong value: DNS.ancount=38440
WARNING: wrong value: DNS.nscount=27668
WARNING: more wrong value: DNS.arcount=45458
WARNING: DNS RR prematured end (ofs=73, len=44)
WARNING: DNS RR prematured end (ofs=77, len=44)
WARNING: more DNS RR prematured end (ofs=81, len=44)

자 일단 읽어 들이는 과정에서도 경고 메시지가 나타난다. DNS 의 ancount 나 nscount 값이 지나치게 크게 나온다는 것이다.

>>> a
<test_dns.pcap: TCP:6 UDP:1115 ICMP:0 Other:28>

다음은 패킷파일 중 정상적인 DNS 패킷 데이터를 본 것이다.

>>> a[1145]
<Ether  dst=[삭제] src=[삭제] type=0x800 |<IP  version=4L ihl=5L tos=0x0 len=68 id=956 flags= frag=0L ttl=128 proto=udp chksum=0x52c9 src=[삭제] dst=[삭제] options=[] |<UDP  sport=1039 dport=domain len=48 chksum=0xfdec |<DNS  id=52467 qr=0L opcode=QUERY aa=0L tc=0L rd=1L ra=0L z=0L rcode=ok qdcount=1 ancount=0 nscount=0 arcount=0 qd=<DNSQR  qname='1.1.1.1.in-addr.arpa.' qtype=PTR qclass=IN |> an=None ns=None ar=None |>>>>

정상적인 형태는 각 필드정보가 정확히 확인이 된다. 그런데, 아래의 경우를 보면 다르다.
몇몇 필드의 데이터 값이 이상하고, Raw 페이로드 값이 존재한다.

>>> a[176]
<Ether  dst=[삭제] src=[삭제] type=0x800 |<IP  version=4L ihl=5L tos=0x0 len=84 id=16541 flags= frag=0L ttl=24 proto=udp chksum=0xfe73 src=[삭제] dst=[삭제] options=[] |<UDP  sport=domain dport=7783 len=64 chksum=0xf167 |<DNS  id=56 qr=0L opcode=QUERY aa=0L tc=1L rd=1L ra=0L z=1L rcode=server-failure qdcount=0 ancount=38440 nscount=27668 arcount=45458 qd=None an='' ns='' ar='' |<Raw  load='$\xabn\x00z\xb6\x0bl\x98Q\xff\x87\xf9\xe2\xd0\xaeu\xa2[삭제]0305rh\x02\xbe\x18\xc0\x00\x00' |>>>>>
>>>

HEX 값을 확인해 보면 아래와 같다.

>>> hexdump(a[176][Raw])
0000   24 AB 6E 00 7A B6 0B 6C  98 51 FF 87 F9 E2 D0 AE   $.n.z..l.Q......
0010   75 A2 [삭제] 3 37 37 42   u..[삭제]C77B
0020   30 33 30 35 72 68 02 BE  18 C0 00 00               0305rh......

ancount, nscount 가 이렇게 큰 데이터를 가질 수 있는가? 즉, 큰 데이터 값만 보고도 조작된 패킷 가능성이 크다고 볼 수 있다. 그러므로 Scapy 에서도 로드할때 경고 메시지가 나타난다. UDP/53 번에 패킷을 전송하니 이것을 DNS 패킷으로 인식하고 그 값 데이터를 필드 값으로 사용하면서 엉뚱하게 이상한 값으로 설정된 것이다.

이와 같은 경우에는 다양한 Exception 처리를 해 주어야 하는데, 어떤 형태가 들어오기 예측하기 쉽지 않다보니 특수한 환경의 패킷 분석에서는 상당한 어려움이 발생할 수 있다. 이러한 이유로 어떤 자동화된 형태로 패킷을 분석 처리하기에는 많은 경험도 필요하고, 각각의 상황에 따라 처리도 해주어야 하다 보니 안정화 되기까지는 시간도 필요하다. 물론, 안정화 후에도 계속 이런 가능성은 존재하게 된다.  사용하려는 목적은 다르겠지만, 완벽하게 패킷 데이터를 분석하여 사용한다는 관점보다는 좀더 쉽게 패킷 분석가를 도와준다는 관점에서 생각하고 사용하면 이런 작업을 진행하는 분들에게는 좀더 마음이 편해지지 않을까?

/Rigel

2011년 6월 23일 목요일

패킷인사이드 댓글이 불법.유해 사이트라고 ?

블로그 우측 하단에 코멘트 목록이 나오는 곳이 있다. 그런데, 이 부분에 아래와 같은 이미지가 출력된다. 이 것은 정부에서 운영하는 불법.유해 사이트인 경우 리다이렉트 시키는 홈페이지 이다.

아니, 지금까지 잘 나오다가 뜬금없이 불법 사이트라니? 패킷을 떠 보고 살펴보면 64.233.183.132 와 통신을 한다. 이 IP 를 조회해 보면 구글에 할당된 것이다. 아래 그림을 보면 알겠지만, 제일 하단에 Location 필드를 볼 수 있을 것이다. warning.or.kr 로 리다이렉션 시킨다.



요청하는 도메인 주소인 2ge1ffhdgsaom3padg8i2jd5pke1ajbt-a-fc-opensocial.googleusercontent.com 도메인을 입력하면 warning.or.kr 로 연결되는 것이다.  일전에도 구글 사이트가 차단이 된 경우가 있다. 다음 블로그 글을 참고하면 된다.

구글 사이트가 불법정보 사이트로 차단

이때의 경우는 통신사 마다 접속이 되고 안되고 차이가 있었는데, ISP에서 설정상 오류로 발생한 것으로 알고 있다. 이번의 경우도 그런 것으로 추정되는데,
패킷인사이드 전체가 불법 사이트로 차단되지 않은 것이 천만 다행이다.

지금 이 글을 썼던 시간(2011년6월23일 오전 02:15) 까지도 커멘트 영역은 불법 사이트 이미지로 그려져 있다. ㅜㅜ
차단에 의해서 그런지, 올린 이미지를 등록하는 과정에서도 제대로 되지 않았다. 아마 이 영향으로 인한것으로 추정된다. 지금은 정상적으로 뜨는 것을 확인하고야, 이미지도 제대로 올리고 포스팅을 할 수가 있게 된 것이다.

2011년 6월 22일 수요일

비행기 스크린 화면에서 보게된 IP 주소

최근 몇일동안 해외 컨퍼런스를 참석하느라, 포스팅을 하지 못했네요. 오늘은 너무 그동안 쓰지 못한것 같아, 비행기 내에서의 인프라를 간단히 좀 소개해볼까 합니다.

장거리 비행기에서 큼지막한 LCD 화면에서 영화를 보거나, 음악을 듣거나, 뉴스를 읽거나, 비행거리등을 보는것과 같이 다양한 정보를 얻을 수 있습니다. 그런데, 다른 스크린에서는 안 보이는데 유독 한 화면에서 아래와 같이 IP 정보가 보이네요. 주소를 보니 내부의 컴퓨터들이 172.17.X.X 망으로 연결되어 있나 봅니다. 비행기 그들만의 주소로 말이죠.


아래를 살짝 내려다 보면 랜케이블로 추정되는 선도 하나 보입니다.  랜 케이블을 꼽는 포트도 하나 있던데, 이것까지는 확인 못 해봤습니다. 꼽아볼 선이 있어야 말이죠.
연결되면 DHCP 로 IP 라도 하나 할당될까요? 그러면 다른 비행기내의 인프라도 접근이 될까요? 글쎄요. 보안을 생각하였다면 이러지는 않겠죠.  그냥, 각 자리의 단말기들이 하나의 컴퓨터 같이 앞으로 좀더 다양한 기능을 무장하여 선보이지 않을까 하는 생각만 듭니다.

아래 그림은, 예전에는 못 보던 기능인데 좌석에 USB 포트를 꼽는 곳이 있더군요. 즉, USB 를 연결하여 USB 내에 담겨 있는 사진을 보거나, 음악을 듣거나, PDF 문서파일을 볼 수 있다는 것입니다. 하지만, 테스트는 해 보지 못했습니다. 그러나 USB 포트를 통해서 충전은 해 봤답니다.


갈수록 진화되는 비행기 스크린 화면이네요. 
그냥 오랜만에 적어보는 글 이라서 가볍게 시작해 봅니다 : )

2011년 6월 9일 목요일

와이어샤크 1.6.0 버전 공개 - 1.4.X 사용자 분들은 업데이트를 ~

와이어샤크 1.6.0 이 릴리즈 되었다. 그간 보았던 1.5.X 버전은 사라지고, 1.4.X 의 Stable 버전에서 1.6.X Stable 버전이 릴리즈 된 것이다. 이번 버전은 1.6.X 버전대의 첫 번째 릴리즈 이며, 앞으로 Stable 버전인 1.4 버전대를 대체하게 될 것이다.

일단 이번 버전에서는 그간 알려진 버그들이 픽스 되었고, 1.4 와 달리 다음과 같은 새로운 기능 추가 및 변화가 있다.

- 큰 파일(2기가 이상) 지원 기능이 향상
- text2pcap 과 같이 와이어샤크와 Tshark 에서 텍스트 덤프파일 Import
- SSL 세션 키 Export
- 패킷 리스트에서 컬럼 숨기기
- SMB 오브젝트 Export
- dftest, randpkt 맨 페이지 추가 (randpkt 는 패킷 인사이드에 소개되었던 적이 있다)
- 패킷 길이 표시가 기본 컬럼으로 설정
- 그래프 기본 저장 포맷이 PNG 방식으로 변경
- 이외 기타 등등

프로토콜도 새롭게 몇가지 추가 지원하고 있다.

[윈도우 32비트]
http://wiresharkdownloads.riverbed.com/wireshark/win32/wireshark-win32-1.6.0.exe
[윈도우 64 비트]
http://wiresharkdownloads.riverbed.com/wireshark/win64/wireshark-win64-1.6.0.exe

릴리즈 된 세부 정보는 다음 문서를 참고한다.

http://www.wireshark.org/docs/relnotes/wireshark-1.6.0.html

현재 개발버전은 1.6.0rc2 버전이다.

앞으로 패킷인사이드에서도 와이어샤크 기능은 1.6.X 버전에 맞춰서 소개될 것이다. 지금 이 포스팅을 보고 있는 사용자라면, 지금 1.6.0 으로 업데이트 하여 안정된 새로운 버전의 기능을 느껴보기 바란다. : )

2011년 6월 8일 수요일

*NIX 에서 서브넷(Subnet) 계산을 쉽게 해 보자!

초기 네트워크 설정 과정중에 서브넷을 계산해 넣는경우가 있다. 네트워크 서브넷을 계산하는 가장 쉬운 방법은
- 인터넷에서 바로 제공하는 온라인 서브넷 계산기
- 윈도우용 서브넷 계산기 프로그램 등이 있다.

자주 계산이 필요한 경우라면 윈도우용과 같은 프로그램이 설치되어 있으면 편리하다. 이런 서브넷 계산기는 인터넷에서 조금만 검색해보면 너무나 많은 도구들이 있기 때문에 따로 언급은 안하겠다. 나의 경우는 가끔씩 필요한 경우라, 인터넷상의 온라인 계산기를 주로 이용했는데, 리눅스 상에서 계산해볼 생각은 하지 않았다. 그러나, 콘솔 기반으로 간단하면서도 쉽고 빠르게 계산할 수 있는 도구들이 있다.

여기서는 subnetcalc 라는 것을 이용하였는데, 다음의 경로에서 파일을 받을 수 있다.
http://www.iem.uni-due.de/~dreibh/subnetcalc

또는 apt-get install subnetcalc 로 쉽게 설치도 가능하다. 사용법도 간단해서 아래 화면과 같이 계산할 네트워크 주소와 넷 마스크 또는 Prefix 값을 넣어주면 된다.


그러면 사용가능한 호스트 갯수부터 하여 필요한 정보를 나열해 준다. 리눅스를 주로 사용하면서 서브넷 계산이 많은 분들한테는 유용하게 사용될 수 있을 것이다. MAN 페이지에 있는 몇 가지 예제를 써 보면 아래와 같다:

subnetcalc 132.252.250.0 255.255.255.0

subnetcalc 132.252.250.0/255.255.255.0

subnetcalc 132.252.250.0 24

subnetcalc 132.252.250.0/24

subnetcalc fec0:2345:6789:1111:221:6aff:fe0b:2674 56

subnetcalc 2a00:1450:8007::69 64

subnetcalc ff08::1:2:3

subnetcalc 131.220.6.5/24

2011년 6월 7일 화요일

밤사이 안드로이드폰에서 패킷 덤프를 해 보니

요새는 모바일폰에서 무제한 데이터 요금제를 사용하시는 분이 많다. 나 또한 무제한 데이터를 사용하지만 과거에는 한달에 500 메가 제한 요금제였다. 그런데 때로는, 분명 데이터를 사용하지 않은것 같은데 상당히 많은 트래픽을 사용한 경험이 있다. 그것도 100 메가 이상으로. 이걸 확인해 볼 가장 확실한 방법은 트래픽을 살펴보는 것이다. 과다 트래픽이 발생되는 시점에 맞춰서 트래픽을 살펴보기도 힘들고, 지금은 무제한 데이터라 큰 의미는 없지만 한번 주말에 트래픽을 덤프해 보았다.

루팅된 폰에서 tcpdump -i rmnet0 -s 1500 -w ttt.pcap & 으로 트래픽을 저장하고 다음날 확인해 보았다. 이 시간대에는 내가 의도적으로 접속을 시도해본 것은 없다. 


최종 트래픽이 덤프된 시간은 아래와 같다.

5월21일 23:17:59 - 5월22일 13:31:54

총 4004 개의 패킷이 기록되었고 초당 0.078 개의 패킷이 전송된 것이다. 내가 직접적으로 사용하지는 않았지만 기록된 트래픽양은 총 2,058,196 으로 약 2메가 이다. 사용하지 않더라도 동작되어 있는 여러가지 앱에 의해 충분히 트래픽이 발생할 수 있는 것이다. 트래픽을 좀더 세부적으로 살펴보니,

TCP 가 99.53% 로 대다수를 차지하였고 이중 대부분이 SSL 트래픽이다. UDP 는 단지 0.47% 로, DNS 쿼리와 관련된 것이다. 일단 데이터들은 SSL 로 이뤄졌으니 안전하게 데이터가 전송되고 있음을 확인하였고, 접속한 곳을 보면
- 구글 관련 사이트
- 아마존 앱 스토어 관련 트래픽
- 회사 관련 메일 서버 접속 트래픽

으로 크게 구분되었다. 즉 대부분 TCP/443 으로 데이터가 교환되었는데, TCP/443 이 아닌 TCP 트래픽이 눈에 띄었다. TCP/5228 을 사용하였고 접속지는 미국 IP 인 구글에 할당된 주소이다. 찾아보니 안드로이드 마켓에서 이용하는 포트가 바로 5228 이다.

어찌되었던 약 2메가의 트래픽이 사용되었는데, 결론은 이렇다.
사용하는 앱이 사용자가 직접적으로 접근하는 것 외에도 트래픽이 미미하게 발생될 수 있으므로, 무제한 요금제가 아니라면 가장 확실한 것은 사용하지 않을때 3G 데이터를 차단 하는 것이다. 하지만, 현실적으로 매번 끄는 것은 귀챦은 일이다. 다만 미미하게라도 트래픽이 사용자 원치 않게 발생될 수 있다는 점과, 너무 과다 트래픽이 나도 모르게 사용되는 경우라면 이와 같은 방법으로 직접적으로 트래픽을 덤프하여 검증해 볼 수 있다는 것이다.

2011년 6월 2일 목요일

안드로이드 3G 단말기에서 스캐닝을 해 본다면 ?

내가 사용하는 모바일 단말기에서 네트워크 환경을 보면, A 클래스로 크게 설정되어 있다.(필자가 사용한 단말기로만 기준한 것이다) 회사에서 사용하는 네트워크에 빗대어 보면 수 많은 사용자들이 한 클래스안에 소속되어 있는 것이다. 내부의 IP 는 비공인 IP 로 할당하여 인터넷과의 통신은 NAT 를 통해서 이루어질 것이다. 3G 단말기 사용자 모두에게 공인 IP 를 할당할 수는 없는 처지이기 때문에 이것은 현 시점에서 당연한 선택이다. 안드로이드 단말기에서 IP 주소 정보 확인은 다음 포스팅을 읽어보길 바란다.

안드로이드(Android)폰에서 tcpdump 를 이용한 패킷덤프!


자, 그렇다면 NAT 뒷단에 있는 IP 가 A 클래스인 255.0.0.0 으로 할당되어 있다는 것은, 수 많은 사용자들의 단말기와 같은 네트워크 영역에 있다는 뜻이 된다. 네트워크 관점으로만 보면야 다른 단말기에 접근하는 것이 가능해 진다. 다음은 'Network Discovery' 라는 앱을 이용해 스캔을 해 본것이다. 동작한 앱에서는 IP 주소가 /23 으로 정의되어 있는데, 아마도 스캔 대상 범위를 한정지어 놓은것이기 때문일 것이다. /23 은 512 개의 주소를 뜻한다.



위 이미지와 같이 스캐닝 하여 발견된 IP 목록이 나타난다. 지금 나타난 IP 대상 단말기에는 특별한 네트워크 서비스가 없기 때문에 접근상의 의미는 크게 없다. 그런데, 만약 단말기에서 원격접속을 허용하는 서비스를 동작시키고 있다든지 하면 이야기는 달라진다. 회사 내부에 있는 각 컴퓨터를 생각해 보자. 외부에서는 직접적으로 접근할 수 없지만, 내부에서는 접근이 가능하다. 바로, 이 안드로이드 단말기들이 앞으로 네트워크 적인 서비스를 가지거나, 또는 악의적으로 의도되어 어떤 서비스가 동작한다면 원격에서 접속이 가능해 질수도 있는 것이다. 다음은 발견된 호스트를 선택하여 포트 스캐닝을 하는 경우의 트래픽을 살펴본 것이다.


지금은 큰 위협이 되지는 않을지 모르겠지만, 통신사 입장에서는 앞으로 이에 대한 대책도 준비되어야 할 것이다. CPU 는 듀얼코어를 넘어서 쿼드코어로까지 확장되고, 단말기 자체가 생산해 낼 수 있는 트래픽의 양도 상당히 커질 수 있다. 네트워크 내에서 트래픽이 크게 폭주된다면 어떻게 될 것인가? 이 부분은 얘기하지 않아도 알 것이다.

P.S 다른 단말기에서의 네트워크 확인을 해 보니 255.255.255.248 의 넷마스크를 가지고 있었다. 그러므로 앞서 언급한 A 네트워크는 모두 해당되지 않을 것이다. 모두가 그렇다는 것이 아니라, 이런 상황이 있을수도 있고, 이에 대한 정보 수준에서만 보면 되겠다. 추후 좀더 넓은 범위에서 확인해 볼 수 있으면, 다시 한번 정리해 보도록 하겠다.