와이어샤크 가지고 놀기 - Telnet, Bittorrent, Tor 프로토콜 분석

학교 과제로 제출했던 것이고 Bittorrent, Tor 프로토콜의 경우 다소 분석이 부실하게 됐습니다만 그래도 읽어볼만은 할 것 같습니다. 캡쳐 파일은 제가 알아차리지 못한 다른 민감한 정보가 혹시 같이 섞여있을까 걱정되어 공개하지 않겠습니다.

우선 실습은 Windows 10 Pro 운영체제에서 Wireshark 2.4.6버전을 기준으로 진행되었습니다.

1. Telnet 프로토콜

Telnet 프로토콜은 원격지의 호스트 컴퓨터와 양방향 통신을 하기 위한 프로토콜이다. 주로 23번 포트를 사용한다. 이 프로토콜은 TCP 연결을 한다. 이 때 NVT(Network Virtual Terminal)이라는 것이 존재해 Client와 Server 사이의 데이터 통신 프로토콜을 일치 시킨다.
Telnet Protocol Specification은 RFC 854에서 확인할 수 있다.
접속을 하면 우선 서버와 클라이언트는 TCP 3way handshake를 한 이후 데이터를 주고 받는다. TCP 연결이기 때문에 reliable한 통신이지만, 오가는 데이터에 대한 encryption은 전혀 존재하지 않아 Wireshark를 통해 오가는 데이터를 전부 들여다볼 수 있고, 이로 인해 계정 정보를 포함한 민감한 정보가 중간자에게 노출되거나 변조될 가능성이 있다. 이는 Telnet이 사장되고 SSH가 주로 사용된 이유이기도 하다.

윈도우에서 기본 제공되는 Microsoft Telnet Client 10.0.16299.15 버전을 이용해 x.theundergroundbbs.net 에 접속을 해서 통신하는 과정을 와이어샤크로 캡쳐했고 이를 분석하겠다.

Wireshark에서 제공하는 telnet 필터를 통해 TELNET 프로토콜로 통신한 패킷을 알아낼 수 있었다.

서버의 IP 주소는 47.199.161.87이고, ip.addr == 47.199.161.87 필터를 통해 총 914개의 패킷에 대해 TELNET 통신과 더불어 통신이 시작할때 이루어지는 TCP handshake, 그리고 TELNET 프로토콜로 통신한 이후 reliability를 위해 TCP 통신을 주고 받는 것을 확인할 수 있다.

이 때 아무 패킷이나 선택해서 내용을 확인해보면 서버로부터 제공받은 데이터를 그대로 확인할 수 있다. 밑의 예시는 765번 패킷의 내용을 확인한 것이다.

이 내용은 아래의 텍스트와 대응될 것으로 추정할 수 있으며, 이 때 중간에 들어가있는 0x1b, 0x5b와 같은 글자는 글씨의 색깔을 지정하기 위해서 쓰이는 문자이다.

악의적인 사용자가 텔넷 통신을 캡쳐했다고 할 때 가장 관심이 있을 정보는 계정 정보일 것이다. 클라이언트가 입력한 계정 정보를 탈취하기 위해 telnet.data contains “password” 필터를 통해 password라는 substring을 telnet data로 가지고 있는 모든 패킷을 확인할 수 있다. 검색을 해본 결과 아래와 같이 총 6개의 패킷을 얻을 수 있었다.

이 중 436번 패킷에서 Password를 입력받는 것으로 추정되는 “New password (4-8 chars)” string을 확인할 수 있었다. 또한 438번부터 454번 패킷 까지 서버와 클라이언트가 password를 한 글자씩 주고받는 것을 관찰할 수 있었다. 이는 TCP Follow Stream을 통해서도 명확하게 확인할 수 있다.

이와 같이 텔넷 프로토콜은 데이터가 그대로 노출되어 굉장히 쉽게 오가는 데이터의 내용을 확인할 수 있다.

2. Bittorrent 프로토콜

BitTorrent 프로토콜은 P2P 파일 공유를 위해 쓰이는 프로토콜이다. 원래 파일을 네트워크 상에서 내려받을 때에는 서버에 완성된 파일이 있고, 그 파일을 서버로부터 받는 방식으로 내려받았는데 BitTorrent는 파일을 여러 조각으로 나눈 후, 다운로더가 파일을 다운 받으면서 동시에 다시 그 조각들을 다른 다운로더에게 배포한다. 그렇기에 세션이 늘어나면 늘어날수록 사용자의 다운로드 속도는 점진적으로 늘어난다. 토렌트 파일을 클라이언트가 열면 해당하는 파일의 조각을 가지고 있는 피어의 리스트를 그 토렌트 파일에 적힌 트래커에게 요청한다. 그렇게 피어의 리스트를 받은 이후 파일을 내려받는다. 기본적으로 6881포트에서 TCP 통신을 진행하고, 트래커를 찾기 위해서 트래커의 리스트를 가지고 있는 트래커 서버에서 트래커 정보를 받을 때 HTTP(TCP) 혹은 UDP 통신을 사용한다. 토렌트 파일에는 토렌트 파일의 이름, 내려받을 파일의 이름과 해쉬값, 트래커의 주소, 생성 일자와 생성자 정보, 파일 조각의 크기가 들어있다.

RFC 상에서 Bittorrent는 RFC 5694에서 언급이 되어있고 Specification은 bittorrent 홈페이지에서 확인할 수 있다.

μtorrent 3.5.3 버전에서 ubuntu-budgie-18.04 버전 토렌트 파일을 이용해 파일을 내려받는 전 과정을 와이어샤크로 캡쳐했고 이를 분석하겠다. (첨부한 torrent.pcap 파일이 텔넷 통신을 캡쳐한 파일이다.) 토렌트 파일은 linuxtracker.org(link)에서 다운로드 받았다.

우선 토렌트 파일로부터 아래와 같이

http://linuxtracker.org:2710/00000000000000000000000000000000/announce, http://torrent.ubuntu.com:6969/announce 가 트래커 서버로 미리 등록이 되어있는 것을 확인할 수 있다.

또한 조각은 512KB 단위임을 확인할 수 있다.

토렌트 프로그램의 실행 화면 캡쳐는 아래와 같다.

pcap 캡쳐 파일 상에서 두 트래커 서버로 파일의 info-hash 값을 전송하는 것을 확인할 수 있다.(info-hash 값은 SHA1 해쉬값을 bencoding한 값이다.) 첫 번째로 23번 패킷에서 178.63.18.77로 info-hash를 전송하고, 두 번째로 55번 패킷에서 91.189.95.21로 info-hash를 전송하는 것을 확인할 수 있다. 아래의 캡쳐는 178.63.18.77에 보낸 23번 패킷의 정보이다.

두 트래커 서버에서 하는 일은 비슷할 것이므로 178.63.18.77과 주고받는 패킷을 더 자세히 확인하기 위해 ip.addr == 178.63.18.77 필터를 적용시킨 결과는 아래와 같다.

이 결과로부터 178.63.18.77에 파일의 info_hash를 보내고, 정황상 패킷에서 peer list를 받아온다고 유추를 하였다.(다만 역량의 부족으로 정확히 peer list를 어떤 형식으로 받아오는지는 알아내지 못했다.) 또한 Statistics -> Endpoints를 확인하면 다양한 ip로부터 여러 데이터를 수신함을 알 수 있다.

 

이제 bittorrent 프로토콜을 자세히 알아보기 위해 bittorrent 필터를 적용한 결과는 아래와 같다.

 

필터 상에 수많은 패킷이 존재하고, 대부분은 실제 파일의 데이터가 오가는 것이고 일부는 현재 peer의 상태에 대한 정보이다. 상태에 대한 정보는 <Prefix><len><id><additional information>으로 이루어져있다. Prefix 0~8은 각각 choke, unchoke, interested, non interested, have, bitfield, request, piece, cancel에 대응된다. 이를 prefix의 종류대로 grouping을 시켜본 결과는 아래와 같다.

피어에게서 파일 공유를 받을 때에는 우선 TCP 3way Handshake를 진행한다. 이 Handshake가 정상적으로 진행되었을 경우 피어는 상대방에게 have prefix를 통해 자신이 보유하고 있는 piece에 대한 정보를 알린다. 아래는 680773번 패킷의 Have 메시지이다.

Have 메시지를 통해 상대방이 어떤 조각을 가지고 있는지 안 이후에는 Request 메시지를 통해 필요로 하는 조각의 index와 데이터의 크기 정보를 보낸다. 아래는 853658번 패킷에 대한 정보이다.

이후 TCP 스트림을 통해 조각을 주고 받는다. 단, 이 때 해결하지 못한 의문 사항이 몇 가지 있는데, 첫 번째로 모든 Have, Request 메시지를 유일하게 109.90.173.89에서만 주고받은 점이다. Endpoint의 통계 상으로는 더 많은 피어로부터 파일을 다운로드 받은 것으로 보인다는 점에서 의문이다. 두 번째로, 분명 로컬 ip가 Request를 보내야 파일을 수신받을텐데 아래 사진에서 보듯 Request를 받기만 할 뿐 보내지 않는다.

지식의 부족으로 Wireshark가 Bittorrent 프로토콜을 온전하게 캡쳐를 못하는 것인지, 프로토콜에 아직 파악 못한 점이 있는 것인지 제대로 확인을 못했고 의문점들을 해결하지 못했다.

3. Tor 프로토콜

Tor 프로토콜은 미국 해군 연구소에서 처음으로 시작된 익명 웹 브라우저로, Tor 웹 브라우저를 사용하는 클라이언트는 일반 웹 서버에 도달하기 위해 2개 이상의 Tor 서버를 거친다. 이러한 라우팅 과정을 onion routing이라고 부르며, 클라이언트와 중간 Tor 서버, 그리고 중간 서버끼리는 Diffie-Hellman을 통해 암호화 세션 키를 교환하고 TLS 상에서 통신을 진행하기 때문에 설령 공격자가 마지막으로 거친 Tor 서버와 웹 서버 사이의 통신을 도청한다고 해도 이 통신의 시작점이 누구인지를 아는 것은 불가능에 가깝다. 또한 Tor 브라우저를 이용해서만 접속할 수 있는 onion 도메인이 존재한다. onion 도메인의 주소는 마치 비트코인의 지갑 주소와 비슷하게 공개키 암호화 방식을 이용해 제작되어 익명 서버 호스팅 기능을 제공한다. Tor 프로토콜 Specification은 공식 홈페이지에서 확인할 수 있다.

Tor browser 7.5.3 버전에서 여러 웹 사이트를 순회하는 전 과정을 와이어샤크로 캡쳐했고 이를 분석하겠다.

토르 브라우저로 현재 ip를 확인해주는 myip.com에 접속한 결과, 현재 컴퓨터의 ip와는 전혀 상관없는 주소가 적혀있음을 확인할 수 있었다. 참고로 현재 주소는 아래와 같이 124.197.219.142이다.

캡쳐한 와이어샤크 패킷 리스트를 보더라도 접속한 사이트에 대한 그 어떠한 정보를 확인할 수 없었다. 다만 163.172.82.3과 TLSv1.2 통신을 여는 것을 확인할 수 있었다.

그렇기에 클라이언트가 첫 번째로 거치는 Tor 서버가 163.172.82.3일 것이라고 강하게 추정할 수 있고, ip.addr == 163.172.82.3 필터를 통해 163.172.82.3과의 통신을 살펴보았다.

일반 클라이언트와 163.172.82.3이 키를 교환한 이후에는 키를 모르는 이상 뒷 부분의 통신을 알아낼 방법이 전혀 없기 때문에 키 교환이 이루어지는 부분을 중점적으로 살펴보았다.

22번 패킷인 Server Hello 부분을 보면 modulus와 공개키 e가 나와있음을 확인할 수 있다. 현재 m은 1024bit이기 때문에 현실적으로 소인수분해를 하는 것이 불가능하지만 TLS 내의 예기치 않은 버그로 인해 m이 소인수분해가 된다면 적어도 클라이언트와 첫 번째 서버 사이에서 어떤 정보가 오고 갔는지는 확인할 수 있게 된다.