2011년 11월 24일 목요일
패킷파일에서 카빙기법을 통한 데이터 추출
패킷파일에서 빠르게 파일을 추출하기 위한 방법중에 하나로 포렌식 도구중에 하나인 Foremost 를 이용해 보고자 한다. 이미 Tcpxtract 와 와이어샤크를 통해서 파일을 추출하는 방법도 언급하였으나, 이 방법은 또 나름대로 필요한 경우가 있기 때문에 도움이 될 것이다. 기존에 파일 추출관련한 포스팅은 다음과 같으니 참고하길 바란다.
1) 네트워크 패킷 캡쳐 파일에서 파일 추출하기 (using Tcpxtract)
2) 와이어샤크를 이용한 패킷파일에서 바이너리 파일 추출하기
이번에 파일 추출 방법으로 사용할 것은 Foremost 라는 도구를 이용한 것이다. Foremost 는 패킷파일을 위해 만들어진 것은 아니고 파일에서 데이터를 추출하기 위한 포렌식 용도로 제작된 것이다. 콘솔기반의 프로그램으로 파일에서 헤더, 내부 데이터 구조를 기반으로 파일을 복구해 내는 것이다. 흔히 이런 방법은 데이터 카빙이라고도 불린다. Foremost 는 dd, Encase 등에 의해 만들어진 파일에서도 복구를 할 수 있으며, 우리는 이것을 패킷파일 대상으로 이용할 것이다.
우선 파일다운로드는 아래 경로에서 할 수 있으며, 리눅스 패키지를 이용한다면 foremost 로 검색하여 설치할 수 있을 것이다.
http://foremost.sourceforge.net/
-h 옵션을 주면 도움말을 볼 수 있다.
# foremost -h
foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus.
$ foremost [-v|-V|-h|-T|-Q|-q|-a|-w-d] [-t <type>] [-s <blocks>] [-k <size>]
[-b <size>] [-c <file>] [-o <dir>] [-i <file]
-V - display copyright information and exit
-t - specify file type. (-t jpeg,pdf ...)
-d - turn on indirect block detection (for UNIX file-systems)
-i - specify input file (default is stdin)
-a - Write all headers, perform no error detection (corrupted files)
-w - Only write the audit file, do not write any detected files to the disk
-o - set output directory (defaults to output)
-c - set configuration file to use (defaults to foremost.conf)
-q - enables quick mode. Search are performed on 512 byte boundaries.
-Q - enables quiet mode. Suppress output messages.
-v - verbose mode. Logs all messages to screen
사용방법은 간단하다. -i 로 입력될 파일을 지정해 주면 된다. -v 는 좀더 세부정보를 보여주고 -o 로 출력될 디렉토리 경로를 정할 수 있다. 기본은 output 이라는 폴더 아래에 추출된 파일이 저장된다. 아래 그림은
# foremost -i ex.pcap -v
로 실행한 결과이다.
추출된 파일 정보들이 출력이 된다. output 폴더를 보면 추출된 파일이 확장자별로 해서 존재함을 확인 할 수 있다.
# ls -l output
total 20
-rw-r--r-- 1 root root 1808 2011-11-23 23:51 audit.txt
drwxr-xr-- 2 root root 4096 2011-11-23 23:51 gif
drwxr-xr-- 2 root root 4096 2011-11-23 23:51 htm
drwxr-xr-- 2 root root 4096 2011-11-23 23:51 jpg
drwxr-xr-- 2 root root 4096 2011-11-23 23:51 png
# ls -l output/jpg
total 64
-rw-r--r-- 1 root root 60610 2011-11-23 23:51 00000857.jpg
# file output/jpg/00000857.jpg
output/jpg/00000857.jpg: JPEG image data, JFIF standard 1.02
그런데 필자가 가지고 있었던 또 다른 패킷파일에서는 바로 PCAP 에서 추출해 내지 못했다. UDP 데이터 인데, 그 안에 JPG 관련 Payload 가 포함되어 있었다. 이런 경우에는 패킷파일에서 추출하기 원하는 부분에서 'Follow UDP(or TCP) Stream' 을 선택하고 그 후, 데이터를 받은 방향으로 해서 선택하고 Raw 로 저장을 하면 된다.
저장된 Raw 파일에서는 Foremost 로 추출해 낼 수 있었다. 즉, 기록되어 있는 데이터 구조에 따라서 달라지므로 기본적으로 Raw 데이터에서 추출해 내는 것이 맞다.
TCP 뿐만 아니라 UDP 에서도 원하는 데이터를 추출해 낼 수 있다. 단 조건은 어떤 파일형태의 구조를 제대로 갖추고 있어야 한다는 것이다. 무작정 임의의 페이로드에서 데이터가 뽑혀질 수 있는 것은 아니기 때문이다.
와이어샤크의 기능을 통한 추출은 제한적이므로, 분석 대상의 패킷파일에 따라 적절한 방법을 선택해 사용하면 될 것이다.
라벨:
네트워크 포렌직,
패킷분석,
Forensic,
Network Forensic
2011년 11월 21일 월요일
다수의 IP에 대해 Alive 유/무 쉽게 확인해 보기
패킷분석을 하다보면, 분석목적에 따라 다르겠지만 추출한 IP 주소에 대해서 추가적인 정보를 얻어야 하는 경우가 있다. WHOIS 정보가 될 수도 있고, 해당 IP 에 대한 포트 정보 또는 OS Fingerprint 를 통해 운영체제 추정등 다양한 정보를 얻기위해 시도해 볼 수 있다. 그중 대표적으로 한번쯤은 해보는 것이 해당 IP 에 대한 Alive 유무 체크일 것이다. 보통은 Ping 을 통해 확인을 한다. 그런데 한 두개의 IP 가 아니라 대량으로 테스트 해 보아야 한다면, 간단한 쉘 스크립트를 이용해서 쉽게 확인해보자.
여러 도구들이 있을텐데, 가장 기본적인 도구를 가지고 빠르게 확인하기 위해 테스트 해보았다. (필자도 필요에 의해)
일단, 아래와 같은 IP 주소를 라인별로 가지고 있다고 치자. tshark 등을 통해 IP 를 추출해 내었을 수도 있고, 어떤 방법이든지 확인해 보아야 할 IP 리스트를 라인별로 기록한 것이다.
# more ip.txt
[삭제].130.50
[삭제].10.99
[삭제].25.121
[삭제].56.99
[삭제].209.197
[삭제].85.76
[삭제].217.32
.
.
그리고 ping 에 의한 결과는 아래와 같다.
# ping [삭제].10.99
PING [삭제].10.99 ([삭제].10.99): 56 data bytes
64 bytes from [삭제].10.99: icmp_seq=0 ttl=114 time=13.271 ms
64 bytes from [삭제].10.99: icmp_seq=1 ttl=114 time=13.693 ms
64 bytes from [삭제].10.99: icmp_seq=2 ttl=114 time=13.790 ms
--- [삭제].10.99 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 13.271/13.584/13.790/0.262 ms
이렇게 Ping 에 의해 출력되는 정보를 가지고 간단하게 아래와 같이 구현해 보았다.
#./ip_chk.sh
Checking [삭제].130.50: is dead
Checking [삭제].10.99: is alive
Checking [삭제].25.121: is alive
Checking [삭제].56.99: is alive
Checking [삭제].209.197: is alive
Checking [삭제].85.76: is alive
Checking [삭제].217.32: is dead
Checking [삭제].89.169: is dead
Checking [삭제].77.102: is alive
Checking [삭제].216.69: is dead
Checking [삭제].109.240: is dead
Checking [삭제].65.226: is dead
.
해당 스크립트 내용을 살펴보면 아래와 같다.
ip.txt 에서 IP를 한 개씩 읽어 들이면서 $host 변수에 저장하고, ping 을 이용해 그 결과에 따라 Alive 또는 Dead 를 표시한다. ping -c1 은 한번만 카운트를 한다는 것이고, -w1 은 최대 Max Timeout 을 1초로 지정한 것이다. 즉, 1초 안에 Ping 에 대한 결과를 지정하는 것이다. 이후 출력되는 정보를 콤마(,) 로 구분하고 두번째 내용에 해당하는 1 packets received 가 패턴 매칭되면 Alive 라고 지정하는 것이다. Ping 을 성공하였다면, 1 packets received 가 출력될 것이기 때문이다.
이상, 간단히 기본 명령어를 조합해서 다수의 IP 에 대해 Alive 유무를 체크해 보았다. 방법은 다양하게 있지만, 가급적 기본 도구를 이용하는 것이 분석 입장에서는 편할 수 있다. 분석을 수행할 컴퓨터가 바뀌더라도 어디서든 쉽게 적용해서 사용할 수 있기 때문이다.
간단하게 어떻게 하면 이용할 수 있을까 하고 고민해 보면,
쉽게 문제가 해결되기도 한다.
From Rigel
여러 도구들이 있을텐데, 가장 기본적인 도구를 가지고 빠르게 확인하기 위해 테스트 해보았다. (필자도 필요에 의해)
일단, 아래와 같은 IP 주소를 라인별로 가지고 있다고 치자. tshark 등을 통해 IP 를 추출해 내었을 수도 있고, 어떤 방법이든지 확인해 보아야 할 IP 리스트를 라인별로 기록한 것이다.
# more ip.txt
[삭제].130.50
[삭제].10.99
[삭제].25.121
[삭제].56.99
[삭제].209.197
[삭제].85.76
[삭제].217.32
.
.
그리고 ping 에 의한 결과는 아래와 같다.
# ping [삭제].10.99
PING [삭제].10.99 ([삭제].10.99): 56 data bytes
64 bytes from [삭제].10.99: icmp_seq=0 ttl=114 time=13.271 ms
64 bytes from [삭제].10.99: icmp_seq=1 ttl=114 time=13.693 ms
64 bytes from [삭제].10.99: icmp_seq=2 ttl=114 time=13.790 ms
--- [삭제].10.99 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 13.271/13.584/13.790/0.262 ms
이렇게 Ping 에 의해 출력되는 정보를 가지고 간단하게 아래와 같이 구현해 보았다.
#./ip_chk.sh
Checking [삭제].130.50: is dead
Checking [삭제].10.99: is alive
Checking [삭제].25.121: is alive
Checking [삭제].56.99: is alive
Checking [삭제].209.197: is alive
Checking [삭제].85.76: is alive
Checking [삭제].217.32: is dead
Checking [삭제].89.169: is dead
Checking [삭제].77.102: is alive
Checking [삭제].216.69: is dead
Checking [삭제].109.240: is dead
Checking [삭제].65.226: is dead
.
해당 스크립트 내용을 살펴보면 아래와 같다.
$ more ip_chk.sh
# PacketInside.com
for host in `cat ip.txt`
do
echo -n "Checking $host: "
ping -q -c1 -w1 $host | grep transmitted |
awk -F, '{if ($2 ~ /1 packets received/) print "is alive"; else print "is dead"; }'
done
# PacketInside.com
for host in `cat ip.txt`
do
echo -n "Checking $host: "
ping -q -c1 -w1 $host | grep transmitted |
awk -F, '{if ($2 ~ /1 packets received/) print "is alive"; else print "is dead"; }'
done
ip.txt 에서 IP를 한 개씩 읽어 들이면서 $host 변수에 저장하고, ping 을 이용해 그 결과에 따라 Alive 또는 Dead 를 표시한다. ping -c1 은 한번만 카운트를 한다는 것이고, -w1 은 최대 Max Timeout 을 1초로 지정한 것이다. 즉, 1초 안에 Ping 에 대한 결과를 지정하는 것이다. 이후 출력되는 정보를 콤마(,) 로 구분하고 두번째 내용에 해당하는 1 packets received 가 패턴 매칭되면 Alive 라고 지정하는 것이다. Ping 을 성공하였다면, 1 packets received 가 출력될 것이기 때문이다.
이상, 간단히 기본 명령어를 조합해서 다수의 IP 에 대해 Alive 유무를 체크해 보았다. 방법은 다양하게 있지만, 가급적 기본 도구를 이용하는 것이 분석 입장에서는 편할 수 있다. 분석을 수행할 컴퓨터가 바뀌더라도 어디서든 쉽게 적용해서 사용할 수 있기 때문이다.
간단하게 어떻게 하면 이용할 수 있을까 하고 고민해 보면,
쉽게 문제가 해결되기도 한다.
From Rigel
2011년 11월 19일 토요일
DNS가 위험하다, BIND 제로데이(0-day) 취약점 발견
11월16일 DNS 서비스에 많이 사용되는 소프트웨어 중에 하나인 BIND 에 이유없는 서비스 Crash 가 발생하였다. 다음과 같은 로그를 발생시키면서 말이다.
general: critical: query.c:1895: INSIST(! dns_rdataset_isassociated(sigrdataset)) failed, back trace
general: critical: exiting (due to assertion failure)
여러 곳에서 이런 이슈가 제기되었고, BIND 의 제로데이 취약점으로 밝혀졌다.
실제 피해 사례가 보고되면서 ISC 에서는 발빠르게 보안패치를 제공하였다. 일단, 무엇보다도
원격지에서 조작된 패킷데이터를 통해 인터넷 인프라운영에 중요한 요소인 DNS 서비스를
이렇게 무력화 시킬 수 있다는 점에서 중대한 이슈이다.
해당 취약점의 영향은 서비스거부 이며,
BIND 9.4-ESV, 9.6-ESV, 9.7.x, 9.8.x 모든 버전이 해당된다. 하지만,
현재 이 버전외에도 영향을 받고 있다는 보고가 있으나 확실히 확인되지는 않고 있다.
패치는 2가지 부분을 업데이트 하는데,
필자가 9.5 버전대를 확인해 본 결과 두군데 파일 중 한 파일은 취약한 부분을 안고 있다.
캐쉬에서 불일치된 데이터 구성을 돌려주는 부분인데, 과연 두 부분 중
한군데 이슈만으로 데몬이 Crash 되는 현상이 발생되는지는 확인되지 않았다.
중요한 것은, BIND 를 운영하는 곳에서는 필히 확인해 보아야 하며,
취약점을 안고 있다면 반드시 업데이트를 해야 한다.
패킷인사이드를 방문하는 분들중에는
이와 관련된 분들이 많을것으로 생각되어 공유한다.
좀더 자세한 내용은 아래 권고문을 참고하기 바란다.
[ASEC 권고문] BIND의 불안전한 레코드 구성에 의한 제로데이 서비스거부 공격
http://www.ahnlab.com/kr/site/securitycenter/asec/asecView.do?seq=18679
* 만약 이와 관련한 패킷 데이터 또는 피해사례가 있다면 공유를 부탁드립니다. (댓글)
2011년 11월 16일 수요일
윈도우에서 사용하는 기본 포트 정보
패킷을 분석하는 과정에서 다양한 포트번호를 접한다. 그 중 윈도우 시스템과 연관된 것을 볼 때 참고할 만한 포트 정보이다. 윈도우 2000 기준에서 정리된 것이지만, 일반적인 윈도우 환경에서 이용되는 포트정보를 확인하는데는 충분하다.
필요할 때 찾아보려고 하면 왜 이리 잘 안 보이는지..
그리하여 이곳에 기록을 남겨둔다.
[출처] 윈도우 테크넷 라이브러리
[참고]
1. Port Assignments for Commonly-Used Services
http://technet.microsoft.com/en-us/library/cc959833.aspx
필요할 때 찾아보려고 하면 왜 이리 잘 안 보이는지..
그리하여 이곳에 기록을 남겨둔다.
Service Name
|
UDP
|
TCP
|
---|---|---|
Browsing datagram responses of NetBIOS over TCP/IP
|
138
| |
Browsing requests of NetBIOS over TCP/IP
|
137
| |
Client/Server Communication
|
135
| |
Common Internet File System (CIFS)
|
445
|
139, 445
|
Content Replication Service
|
560
| |
Cybercash Administration
|
8001
| |
Cybercash Coin Gateway
|
8002
| |
Cybercash Credit Gateway
|
8000
| |
DCOM (SCM uses udp/tcp to dynamically assign ports for DCOM)
|
135
|
135
|
DHCP client
|
67
| |
DHCP server
|
68
| |
DHCP Manager
|
135
| |
DNS Administration
|
139
| |
DNS client to server lookup (varies)
|
53
|
53
|
Exchange Server 5.0
| ||
Client Server Communication
|
135
| |
Exchange Administrator
|
135
| |
IMAP
|
143
| |
IMAP (SSL)
|
993
| |
LDAP
|
389
| |
LDAP (SSL)
|
636
| |
MTA - X.400 over TCP/IP
|
102
| |
POP3
|
110
| |
POP3 (SSL)
|
995
| |
RPC
|
135
| |
SMTP
|
25
| |
NNTP
|
119
| |
NNTP (SSL)
|
563
| |
File shares name lookup
|
137
| |
File shares session
|
139
| |
FTP
|
21
| |
FTP-data
|
20
| |
HTTP
|
80
| |
HTTP-Secure Sockets Layer (SSL)
|
443
| |
Internet Information Services (IIS)
|
80
| |
IMAP
|
143
| |
IMAP (SSL)
|
993
| |
IKE (For more information, see Table C.4)
|
500
| |
IPSec Authentication Header (AH) (For more information, see Table C.4)
| ||
IPSec Encapsulation Security Payload (ESP) (For more information, see Table C.4)
| ||
IRC
|
531
| |
ISPMOD (SBS 2nd tier DNS registration wizard)
|
1234
| |
Kerberos de-multiplexer
|
2053
| |
Kerberos klogin
|
543
| |
Kerberos kpasswd (v5)
|
464
|
464
|
Kerberos krb5
|
88
|
88
|
Kerberos kshell
|
544
| |
L2TP
|
1701
| |
LDAP
|
389
| |
LDAP (SSL)
|
636
| |
Login Sequence
|
137, 138
|
139
|
Macintosh, File Services (AFP/IP)
|
548
| |
Membership DPA
|
568
| |
Membership MSN
|
569
| |
Microsoft Chat client to server
|
6667
| |
Microsoft Chat server to server
|
6665
| |
Microsoft Message Queue Server
|
1801
|
1801
|
Microsoft Message Queue Server
|
3527
|
135, 2101
|
Microsoft Message Queue Server
|
2103, 2105
| |
MTA - X.400 over TCP/IP
|
102
| |
NetBT datagrams
|
138
| |
NetBT name lookups
|
137
| |
NetBT service sessions
|
139
| |
NetLogon
|
138
| |
NetMeeting Audio Call Control
|
1731
| |
NetMeeting H.323 call setup
|
1720
| |
NetMeeting H.323 streaming RTP over UDP
|
Dynamic
| |
NetMeeting Internet Locator Server ILS
|
389
| |
NetMeeting RTP audio stream
|
Dynamic
| |
NetMeeting T.120
|
1503
| |
NetMeeting User Location Service
|
522
| |
NetMeeting user location service ULS
|
522
| |
Network Load Balancing
|
2504
| |
NNTP
|
119
| |
NNTP (SSL)
|
563
| |
Outlook (see for ports)
| ||
Pass Through Verification
|
137, 138
|
139
|
POP3
|
110
| |
POP3 (SSL)
|
995
| |
PPTP control
|
1723
| |
PPTP data (see Table C.4)
| ||
Printer sharing name lookup
|
137
| |
Printer sharing session
|
139
| |
Radius accounting (Routing and Remote Access)
|
1646 or 1813
| |
Radius authentication (Routing and Remote Access)
|
1645 or 1812
| |
Remote Install TFTP
|
69
| |
RPC client fixed port session queries
|
1500
| |
RPC client using a fixed port session replication
|
2500
| |
RPC session ports
|
Dynamic
| |
RPC user manager, service manager, port mapper
|
135
| |
SCM used by DCOM
|
135
|
135
|
SMTP
|
25
| |
SNMP
|
161
| |
SNMP Trap
|
162
| |
SQL Named Pipes encryption over other protocols name lookup
|
137
| |
SQL RPC encryption over other protocols name lookup
|
137
| |
SQL session
|
139
| |
SQL session
|
1433
| |
SQL session
|
1024 - 5000
| |
SQL session mapper
|
135
| |
SQL TCP client name lookup
|
53
|
53
|
Telnet
|
23
| |
Terminal Server
|
3389
| |
UNIX Printing
|
515
| |
WINS Manager
|
135
| |
WINS NetBios over TCP/IP name service
|
137
| |
WINS Proxy
|
137
| |
WINS Registration
|
137
| |
WINS Replication
|
42
| |
X400
|
102
|
[참고]
1. Port Assignments for Commonly-Used Services
http://technet.microsoft.com/en-us/library/cc959833.aspx
피드 구독하기:
글 (Atom)