정보 기술이 발달함에 따라 뉴스의 매체가 종이에서 텔레비전, 그리고 인터넷으로 바뀌고 있다. 이에 더해, 최근에는 종이 신문을 디지털화한 형태인 뉴스레터라는 구독 서비스도 생기고 있는 추세이다.
많은 뉴스레터 서비스가 생기고 있는 와중에, 정보보안을 주제로 하여 꾸준히 뉴스레터를 발행하고 있는 곳이 있다.
바로 해킹짹짹이라고 하는 서비스인데, 이 서비스를 제공하고 있는 해키보이즈라는 팀에서 잠깐 같이 공부하며 뉴스레터를 써볼 수 있는 기회가 있었다. 그리고 그렇게 해서 쓴 글이 위 이미지에서 볼 수 있는 Digital Forensics Challenge ... (바로 지난주 금요일에 발행된 뉴스레터이다!)
디지털 포렌식에 관심을 가져왔기 때문에 관련 글을 써보고자 하는 마음에 정하게 된 주제였다.
주제를 정하고 글을 작성하던 와중에 한 팀원분의 인맥 덕분에 실제 DFC에서 우승하신 분까지 인터뷰 할 수 있는 기회를 얻었고, 그 결과 처음 주제를 정하면서 생각했던 것보다 훨씬 유익한 글을 쓸 수 있게 되어 기쁜 마음으로 발행했던 것 같다.
문제를 읽어보면 포트 스캔 방식의 종류로 6가지가 있음을 알 수 있는데, 각각의 유형이 가리키는 스캔 방식은 다음과 같다.
1. TCP SYN scan (half-open scan) 로그가 남지 않도록 할 때 쓰는 스텔스 스캔 방식 중 하나이다. TCP 핸드셰이킹 과정의 첫번째 단계인 SYN 패킷만 보낸 다음 이에 대한 ACK 패킷을 받는다. 대신 TCP connection이 확립되면 안되기 때문에 포트가 열려있다고 판단될 경우 RST 패킷을 보내고, 닫혀있다고 판단될 경우 응답하지 않고 멈춘다.
2. TCP ACK scan ACK 패킷만 먼저 보내고 이에 대한 응답 패킷을 검사하는 방식이다. 포트 스캔을 위한 것이 아닌 방화벽에 대한 검사를 진행하기 위한 방식이다. ACK 패킷에 대한 응답으로 RST 패킷을 받는 경우 방화벽에 의한 필터링이 되지 않고 있는 것을 판단할 수 있고, 응답이 없거나 ICMP 메세지를 받게 될 경우 방화벽에 의한 필터링이 수행되고 있다고 판단할 수 있다.
3. UDP scan UDP 프로토콜의 전송 방식과 같이 핸드셰이킹 과정을 사용하지 않는다. 대신 닫힌 포트로 UDP 패킷을 보냈을 때 서버로부터 ICMP 메세지를 받고, 열린 포트로 보냈을 경우에는 응답이 없다는 것을 이용한다. 결론적으로 UDP 패킷을 보내고 서버로부터 응답이 없을 경우 열린 포트, ICMP 메세지를 받을 경우에는 닫힌 포트라고 인식한다.
4. TCP Connect scan 일반적으로 TCP Connection을 확립할 때 일어나는 3-Way 핸드셰이킹 과정을 거친다. 그 후 정상적으로 핸드셰이킹이 완료되었다면 포트가 열려있는 것으로 판단하고, 그렇지 않으면 닫혀있는 것으로 판단한다.
5. TCP Xmas scan TCP SYN scan 방식과 함께, 로그가 남지 않도록 할 때 쓰는 스텔스 스캔 방식 중 하나이다. 동시에 여러 플래그가 설정된 패킷을 보내서 응답이 없을 경우 열려있다고 판단하고, RST 패킷이 올 경우 닫혀있다고 판단한다. 물론 응답이 없을 경우 무조건 포트가 열려있는 것이 아닌 방화벽에 의해 필터링되어졌을 수 있다.
6. TCP RST scan 이건 뭔지 모르겠다...
이 내용을 바탕으로 문제 파일을 살펴보면.. 첫 번째로 수행한 포트 스캔 방식을 찾기 위해 맨 처음에 등장한 TCP 핸드셰이킹 과정을 살펴봤다.
호스트 IP가 10.42.42.253이라는 것을 참고하면, 여기서 제일 처음으로 포트 스캔을 한 곳의 목적지 IP는 10.42.42.50이고, 80번 포트에 대한 포트 스캔이 진행됐다.
이 패킷의 tcp stream을 따라가보면 SYN - RST/ACK, 이렇게 두 개의 패킷이 송수신되고 있는 것을 볼 수 있는데, 이는 TCP Connect 스캔 방식을 사용했을 때 닫힌 포트임을 판단할 수 있는 모습이다.
Ann이 클릭한 첫 영화의 제목을 구해야 한다. pcap 파일로 주어진 문제 파일을 확인하기 위해 Wireshark를 실행시켰다.
우선 주어진 패킷 파일 중 Ann이 사용한 IP주소에 해당하는 패킷만 보기 위해 필터 조건을 설정했다. 글자가 작아서 잘 안보이겠지만 ip.addr==192.168.1.10 이라고 입력한 상태이다.
필터링을 했지만 여전히 패킷이 많아서 쉽게 찾기에는 어려움이 있어 보인다.
힌트를 얻기 위해 문제를 다시 읽어보면, 구해야 하는 것은 Ann이 클릭한첫영화의 제목이다.
Ann이 클릭 이벤트를 발생시킨 것에 의해 서버에 request 패킷이 보내졌을 것임을 짐작하고, [Statistics] - [HTTP] - [Requests] 메뉴에 들어가서 관련 패킷이 있는지 확인한다. 물론 여기서 관련 패킷이라는 것은 영화와 관련된 패킷을 말한다.
해당 메뉴에 들어가면 아래와 같이 현재 패킷 목록에서 사용된 request 주소들을 확인할 수 있는데, 영화를 클릭했다는 것은 클릭을 통해서 그 영화를 볼려고 했을 것이라고 자연스레..? 생각할 수 있다. 사실 너무 자연스럽게 viewMovie 라는 키워드가 눈에 띄어서 여기에서 사용된 id값을 wireshark packet 목록에서 검색했다. 이 id값이 사용된 위치와 인접한 곳에 해당 id값을 가지는 영화의 정보도 함께 있으리라 생각했기 때문이다.
이 Requests 목록에서는 viewMoview 키워드를 가지는 url이 두 개다. 어느 것이 먼저인지 알아보기 위해서 두 개의 id값을 모두 검색해서 packet list 상에서 먼저 나온 패킷이 어느 것인지 확인했다.
확인한 결과 id 283963264 가 있는 packet number는 883이고,
id 333441649 가 있는 packet number는 56이다.
더 빨리 발생한 request가 56번 패킷이므로 이 패킷의 데이터를 확인했다.
그리고 예상대로 이 id값이 위치한 곳에서 인접한 위치에 title이라고 적힌 key값과 함께 Hackers라는 영화 제목을 확인할 수 있었다.
주어진 pcap 파일을 Wireshark를 이용해서 열어보면 가장 먼저 보이는 packet list에서 눈에 띄는 프로토콜을 발견할 수 있다.
RTP 프로토콜... Real-time Transfer Protocol의 앞글자를 딴 이름을 가지는 프로토콜로, 말 그대로 실시간 전송(스트리밍 미디어, 시스템 등)에 쓰이는 프로토콜이다.
UDP 프로토콜을 기반으로 동작하는 프로토콜이며, 그렇기 때문에 오류 검사와 수정보다는 실시간으로 데이터를 전송하는 데에 초점이 맞춰져 있다. (포트도 UDP 포트를 사용한다.)
RTP 프로토콜은 RTCP 프로토콜과 함께 쓰인다. RTCP 프로토콜이라는 이름은 Real-time Transfer Control Protocol 의 앞글자를 딴 것이며, 여기서도 짐작할 수 있듯이 RTP 프로토콜의 control을 위해 쓰이는 프로토콜이다. 이 문제에서 주어진 pcap 파일에서도 볼 수 있다시피, RTP 프로토콜을 이용하여 실시간으로 데이터를 전송할 때 중간중간 RTCP 프로토콜이 보내지고 있는 것을 볼 수 있다.
RTCP 프로토콜을 사용하는 이유로는 RTP 프로토콜의 전송 통계나 QoS(Quality of Service) 모니터링, 다중 스트림 동기화 등이 있다. 쉽게 생각하면 RTP 프로토콜의 제어 정보 및 QoS 정보, 통계 등을 전송하기 위함이라고 볼 수 있다.
hex dump를 보는게 습관이 되어서 그런지 이 문제를 본 뒤에도 RTP Header format부터 찾은 뒤에 packet hex를 들여다보았던것 같다. RTP 패킷 파일을 선택한 후 해당 패킷의 detail 페이지를 확인해보면 Payload type으로부터 전송된 데이터가 G.711 PCMA으로 된 것임을 알 수 있었다. 여기서 G.711는 주로 전화에서 사용되는 Audio 코덱인데, 이러한 정보를 참고한다면 음성 전화 내용에서 Gregory를 죽인 사람에 대한 힌트를 얻을 수 있지 않을까..
그럼 이 Audio 데이터를 어떻게 해야 들어볼 수 있을까,,
Wireshark에 내장된 기능인 RTP Player를 이용하면 된다. 이 기능을 이용하면 RTP 프로토콜의 stream만 똑 떼어내서 그 스트림으로 전송된 음성본을 들을 수 있다.
물론.. 지원되는 음성 코덱만 가능하다. 현재 내 wireshark 버전에서 지원하는 코덱이 어떤게 있는지 확인하기 위해 [About Wireshark] - [Plugins] 메뉴에 들어간다. 그리고 우측 상단부에 위치한 Filter by type에서 codec을 선택하면 아래 리스트에서 지원되는 코덱의 이름을 확인할 수 있다.
리스트를 확인해보면 제일 위에 G.711 코덱이 지원된다고 있음을 알 수 있다. 이렇게 RTP Player가 지원되는 코덱의 데이터가 전송된 것을 확인했으므로 RTP Player를 사용하여 데이터의 내용을 확인하면 될 것 같다. 이를 위해 RTP 패킷 하나를 선택한 후 [Telephony] - [RTP] - [Stream Analysis] 메뉴를 선택하여 해당 스트림을 타고 간다.
RTP Streams를 선택하면 정말 여기에 있는 RTP stream만을 리스트 형태로 보여주는데, Stream Analysis를 선택하면 stream내의 패킷들을 analysis까지 해주기 때문에 이 스트림에서 전송된 데이터를 음성 재생하여 들을 수 있게 해 준다.
[Stream Analysis] 메뉴를 선택하면 나오는 화면이다. 그리고 여기에서 아래 Play Stream 버튼을 누르면 RTP Player가 나오고, 이를 이용하여 RTP 프로토콜로 전송된 음성 데이터를 들어볼 수 있다.
Player 창을 열고 재생시키면 Jack와 Victoria가 전화를 하는 내용을 들을 수 있다. 음성이 깨끗하지는 않지만.. Jack이 Victoria에게 너가 죽였냐고 하는 것만은 분명히 들을 수 있어서 Victoria가 범인임을 유추할 수 있다.
key값을 찾기 위해 문제에서 제공한 정보는 오로지 pcapng 형식의 파일 하나뿐이었다.
Wireshark를 이용하여 열어보니 USB protocol로 통신한 흔적뿐이었다.
USB protocol에서 사용되는 통신의 유형은 총 4가지가 있는데 각 통신이 주로 사용되는 상황은 다음과 같다. 1. Control Transfer : 호스트가 장치에 명령을 전송하거나, 장치 설정 정보 등을 요청할 때 사용된다. ex) 장치 초기 설정, 관리 2. Interrupt Transfer : 소량의 데이터를 자주 보내야 할 때 사용된다. ex) 마우스, 키보드 3. Bulk Transfer : 대용량 데이터 전송에 사용된다. ex) 프린트, 대용량 데이터 4. Isochronous Transfer : 데이터의 실시간 전송에 사용된다. ex) 음악, 동영상 스트리밍
위 Wireshark 패킷 목록을 보면 알 수 있겠지만 장치가 호스트에게 interrupt 통신으로 데이터들을 계속 보내고 있다. 그리고 여기서 장치가 호스트에게 보내는 패킷들을 확인해보면, 아래와 같이 Leftover Capture Data라는 이름으로 어떤 데이터가 함께 전송되고 있는 것을 확인할 수 있다.
같은 USB protocol을 사용한다고 해도 데이터를 전송하는 형식이 다르기 때문에 어떤 장치가 보낸 데이터인지 확인할 필요가 있다.
USB 장치가 연결되면 호스트는 가장 먼저 연결된 장치에게 설정 정보를 보내라는 요청을 보낸다. (Control transfer - 1번 패킷) 이 요청을 받은 장치는 자신의 descriptor를 호스트에게 보낸다. (Control transfer - 2번 패킷) 이 과정을 통해 장치와 호스트가 데이터를 송수신할 준비를 하게 되고 그 후 통신이 시작된다. 그러므로 장치에 대한 정보는 2번 패킷인, 장치가 보낸 패킷 안에 있을 것임을 유추해볼 수 있다.
2번 패킷을 들여다보면 정말 DEVICE DESCRIPTOR가 있는 것을 볼 수 있는데, 여기서 idVendor와 idProduct를 통해 장치의 제조사와 제품명을 알 수 있다. Wacom의 Bamboo Pen인 것을 알았다. 아마 좀 전에 interrupt transfer로 전송된 많은 데이터들은 이 펜마우스로부터 전송된 데이터들인 건가 보다. (3, 4번 패킷도 마찬가지로 descriptor를 확인해보면 허브인 것을 알 수 있는데, 이후 패킷들로는 Pen과 호스트 간에 송수신한 패킷만 존재하므로 패스했다.)
그럼 이제 이 제품의 데이터 전송 형식을 찾은 뒤 capture data만 추출하여 그 데이터들이 그리고 있는 그림이 어떤 것인지 알아내면 key에 대한 정보를 볼 수 있을 것 같다.
사실 이 문제 풀면서 bamboo pen 전송 데이터 형식 찾는 게 제일 어려웠다... 일단 처음에는 bamboo pen protocol과 같은 키워드로 검색을 했는데, 여기서 발견한 것이 다음과 같은 사이트였다. bamboo pen을 판매하는 것과 같은 느낌의 사이트였는데, tech specs에서 이 펜이 microsoft pen protocol을 사용한다는 정보를 얻게 되었다. 곧바로 키워드를 바꿨다.
Microsoft Pen Protocol을 검색해보면 아래와 같은 내용이 담긴 문서를 찾을 수 있다.
문제에서 사용된 장치는 Pen.. 따라서 마우스 부분에 해당되는 부분을 보면 X좌표와 Y좌표 순서로 데이터를 전송한다는 것을 알 수 있다. 그런데 위 내용의 마지막을 보면 알 수 있지만.. Note... "however this interface would not be acceptable for a Boot Device (use separate interfaces for keyboards and mouse devices)" 대략 위의 폼으로 전송되지만 이게 확실한지를 결정하려면 추가적인 정보가 필요하다.
내가 능력이 안 되는 건지.. 정확히 저 모델의 포맷을 찾는데 실패했다,, 그래서 도움을 좀 받은 결과 다음과 같은 포멧을 가진다고 한다. 길이가 9인 Capture Data가 02 F0 4C 1C D8 12 00 00 04의 값을 가진다고 할 때,
02 F0 : 헤더 4C 1C : X 좌표 D8 12 : Y 좌표 00 00 : Z 좌표 (펜을 누른 정도, 압력) 04 : 접미사
따라서 위 패킷 목록에서 Capture Data가 있는 패킷들만 뽑은 후 그 안에서 다시 Capture Data 값만 추출해 낸다. 그 후 다시 여기에서 뽑아낼 수 있는 X 좌표와 Y 좌표를 화면 상에 나타내면 저 펜을 이용하여 어떤 그림을 그렸는지 알아낼 수 있을 것이다.
이 작업을 위해 우선 Wireshark에서 Capture Data가 있는 패킷만 골라 별도의 pcapng 파일로 저장한다. 필터링을 할 수 있는 입력란에 usb protocol packet 중 capdata가 있는 파일만 골라낼 수 있는 검색어인 usb.capdata를 입력하면 된다. 그 후 [File] - [Export Specified Packets]를 이용하여 필터링된 패킷들을 별도의 pcapng 파일로 저장한다.
그 후 패킷 내의 특정 데이터들만 추출하기 위해 Wireshark의 자매품인 tshark를 사용한다. command line 버전 Wireshark라고 생각하면 되는데 이것의 사용을 위해 리눅스를 켠다. 그 후 아래와 같은 명령어로 좀 전에 capdata만 있는 패킷 내에서 capdata 필드만 뽑아서 capdata.txt 파일에 저장한다. (tshark를 설치한 적이 없으면 설치해야 한다.. 당연히..)
$ tshark -r (대상 pcapng 파일) -T fields -e (필드명)
** 뽑아낼 필드가 여러 개일 경우 -e (필드명 1) -e (필드명 2) -e (필드명 3)...처럼 이어서 적어주면 된다.
그러면 다음과 같이 capdata 필드 값만 파일에 저장된 것을 볼 수 있다.
여기에서 필요한 값은 X, Y, Z 값이므로 이들만 추출해주기 위해 다음의 명령어를 사용할 수 있다.
뭐지.. 하는 생각을 한동안 가지고 있다가 알게 된 것이 gnuplot에 넣을 데이터 체계가 gnuplot이 실행되고 있는 시스템의 체계와 일치하도록 해야 된다는 것이었다. 즉, 내 gnuplot이 실행되고 있는 리눅스 환경은 little endian 바이트 체계를 사용하기 때문에 내가 입력해주는 데이터도 little endian 형식으로 만들어서 넣어줘야 한다는 것이다.
http://www.gnuplot.info/docs_5.5/Gnuplot_5_5.pdf
내 데이터는 big endian 체계로 가져온 값이 었는데 이 부분 때문에 문제가 생겼나 보다... 하고 리틀 엔디안 방식으로 x, y값의 체계를 바꿔서 저장할 수 있도록 코드를 수정했다.
from pwn import *
f = open("data.txt", "r")
for s in f.readlines():
ss = s.split(" ")
x = int(ss[0], 16)
y = int(ss[1], 16)
z = int(ss[2], 16)
if z > 0:
print(u16(struct.pack(">H", x)), u16(struct.pack(">H", y)))
** u16 함수와 struct.pack 함수는 pwntools 라이브러리에서 지원하는 함수이다.
u16는 16바이트의 패킹된 바이트 문자열을 인자로 받아 unpacking 된 바이트 문자열로 바꿔주기 위해 사용된다. endian에 대한 별다른 옵션을 붙여주지 않을 경우 기본적으로 들어온 바이트 문자열을 little endian 타입으로 변환한다.
