#1. Quest_1 - 패킷을 분석해 Flag 찾기

* 본 게시판은 DMA 팀원이 기존에 풀었던 CTF 문제나, 개인이 작성해 낸 문제를 정리한 내용입니다. 문제에 대한 공유 및 관련 내용은 댓글에 문의해 주시거나, 필자의 E-Mail로 문의 주시면 내부 회의 후 답변 드리도록 하겠습니다. 추가적으로 포스팅의 제목과 실제 CTF문제와의 관련은 없으며 풀이 과정을 토대로 어떤 내용인지에 대한 간략한 설명을 제목에 작성하였습니다.

 - 필자 E-Mail : wotmd9408@naver.com

 - 가상머신 : 미사용(본래 분석간에는 가상머신 활용 권고)

 - OS : WIndows 10 EnterPrise 64bit

 - RAM : 32GB

 - 필요 Tool : WireShark 혹은 기타 패킷 분석 프로그램(본 풀이는 와이어샤크로 진행 예정)

특별히 다를게 없었던 토요일이었던 것으로 기억된다. 그날도 특이사항 없이 스터디는 진행되었고, 그렇게 또 하루가 지나가는 것 처럼 보였다. 다만 평소와 달랐던 점은, 팀원 중 하나가 숙제를 내 주었다는 점..?

주기적으로 올라오지는 않을 것으로 보이는 이 게시판은 DMA 내에서 CTF 문제풀이 숙제(?)에 대한 풀이로 구성 된다. 문제 공유 등에 관련해서는 가장 상단에 기재한대로 문의를 주시면 답변 드리도록 하겠다.

이번에 풀어볼 문제는 패킷파일을 분석해 Flag 값을 찾아내는 문제이다. Flag를 찾는 문제는 CTF(Capture The Flag)에서 흔히 나오는 내용으로 취약점이나 분석을 통해 특정 Flag를 찾는 형태로 되어있다.

[그림 1. 문제 파일의 속성 정보]

해당 파일은 pcapng 확장자로 되어있는데 해당 확장자는 PCAP Next Generation의 약자로 기존의 pcap 확장자를 발전시킨 파일 형식이다. 기존 pcap 파일에 비해 인터페이스 정보, 주석, 이름 확인 정보 등 더 다양한 정보가 들어가있다.[1]

파일을 열어보면 아래와 같이 여러 통신 패킷이 나오는데 눈에 띄는 몇가지를 한번 보도록 하자.

[그림 2. 문제 파일의 패킷 정보]

해당 패킷들을 보면 여러가지 종류의 Protocol을 볼 수 있는데 눈에 확 들어오는 Protocol은 TCP, FTP, FTP-data, TLSv1.2이다. 패킷자체를 처음부터 끝까지 보더라도 Flag에 대한 단서는 보이지 않기에 다른 정보를 찾아야 할 것으로 보인다.

TCP 통신은 현재 패킷에서 크게 특이점이 없어보이고 TLSv1.2는 내용을 알 수 없게 쓰여있기 때문에 FTP 관련된 내용을 먼저 보도록 하자. 와이어샤크의 필터 기능을 이용해 ftp만을 따로 필터링을 하면 [그림 3]과 같이 FTP 관련된 패킷만 확인 할 수 있으며 패킷에 대해 마우스 우클릭 -> Follow -> TCP Stream을 클릭하면 [그림 4]처럼 패킷에 대한 문구만 따로 볼 수 있다.

[그림 3. FTP Packet Filter 결과 값]

[그림 4. FTP Filter 한 패킷에 대한 TCP Stream 값]

[그림 3]도 나쁘지 않게 정리가 되어 있지만, 아무래도 [그림 4]가 우리눈에는 조금 더 보기 편하니 [그림 4]를 보고 해당 FTP 통신이 어떤 행위를 하는지 확인해 보도록 하자. 우선 확인하고 넘어가야할 부분이 있다. 위 패킷에서 볼 수 있듯이 FTP는 암호화 통신을 하지 않는다. 따라서 FTP 통신을 하는 서버나 그 사이에서 도청(할 수 있다면)을 하는 경우 FTP 계정 정보 및 어떤 행위를 하는지 탈취가 가능하다. 그래서 많이 사용하는 것이 SFTP(Secure FTP)로 SSH 위에서 동작하기 때문에 암호화도 되어있고 보안적으로 안정되니 해당 기능을 사용하도록 하자.

명령어들을 간략히 살펴보면, 우선 해당 FTP의 USER 계정은 user / 비밀번호는 password 임을 알 수 있다.

또한 파일을 전송하는 방식을 Ascii 모드(TYPE A)로 전송하려 함을 알 수 있고 Passive 모드로 하기위한 명령어(PASV)도 확인 할 수 있다.

LIST 명령어를 통해 디렉터리를 확인하고 files 디렉터리로 이동해(CWD fiels) key.zip 파일을 클라이언트로 보내는 명령(RETR key.zip)을 내리는 것을 확인 할 수 있다.

실제로 파일을 전달하는 명령어를 확인했고, Transfer Complete 명령어를 확인했다면 정상적으로 key.zip 파일이 전달 되었음을 알 수 있다. 그럼 이제 할 일은 해당 전달된 파일의 패킷을 찾아서 실제로 파일을 획득하는 일이다.

[그림 5] 처럼 필터를 ftp에서 ftp-data로 변경해 보자. ftp-data는 FTP 사용 간 실제 데이터를 보낼 때 사용되는 Port 이다.

[그림 5. ftp-data 필터 결과]

ftp-data로 패킷을 필터링하면 [그림 5]와 같이 데이터가 전송된 것을 볼 수 있는데 우리가 봐야할 패킷은 RETR key.zip이 있는 세번째 패킷이다. 세번째 패킷에 대고 아까와 동일하게 마우스 우클릭 -> Follow -> TCP Stream 을 누르면 [그림 6]과 같은 알 수 없는 문자 배열이 나타나는 것을 볼 수 있다.

[그림 6. RETR key.zip 관련 패킷에 대한 TCP Stream]

대충 보면 아실 분도 있으시겠지만, 해당 파일은 server key.pem 파일을 가지고 있는 무언가로 보인다. 알 수 없는 문자열이 다수 존재하지만, 내부 내용을 보면 우리가 알만한 경로의 주소경로도 보이기 때문이다. 저 내부 내용을 해석하기 전에 우선 File Signature에 대하여 알아보도록 하자.

File Signature는 해석 그대로 파일의 서명을 의미한다. 서명이란 무엇인가? 일상 생황에서 서명은 주로 5만뭔 이상의 금액을 결제할 때 많이 사용한다. 아니면 계약서를 작성할 때 사용하던가? 즉 서명은 자신을 증명하는 무언가다. Sign이 될 수도 있고, 도장이 될 수도 있다. 즉, File Signature는 파일이 가지고 있는 '고유한 값'을 나타낸다. 

자 여기서 문제는 우리가 사용하는 파일의 개수가 많아도 너무 많다는 것이다.  exe, ppt, xml, sh, py 등등.. 물론 외우고 다니시는 분들도 있으실 것이다. 자주 보다보면 외우게 되는 signature도 분명히 존재하니까 말이다. 다만 필자는 게으름을 이겨내지 못했는지 아직 외우지 못한것이 많아 특정 사이트를 이용하고 있다. [2]. 

해당 사이트를 들어가면 (구글에 File Signature 라고 검색하면 최 상단에 위치한다) 여러가지 글귀가 보이고 아래로 내리면 우리가 뭔하는 File Signature 정보를 확인할 수 있다. Hex 값으로 된 Signature를 확인 할 수도 있으며, 이미 알고있는 확장자 혹은 ASCII 값으로도 확인이 가능하다. 위에서 ASCII 값으로 보이는 PK를 기준으로 찾아보면 가장 위쪽에 zip 파일이 있고 그 아래에도 여러가지 PK로 시작하는 File Signature 들이 존재한다.

그럼 저 위에 내용을 기준으로 어떻게 파일 확장자를 구문할까? 내부에서 알아볼 수 있는 문구들로 알 수 있는 분들도 계실것이다. 하지만 그것만으로 구분이 힘든 분들은 [그림 6] 중앙 하단에 보면 Show and save data as 부분이 있는데 저 ASCII를 Hex Dump로 변경하면 ASCII 값과 함께 각 값에 해당하는 Hex 값을 얻을 수 있다.

[그림 7. Hex Dump 결과]

File Signature Site를 보면 알 수 있겠지만, 같은 PK 값을 Signature로 가졌다고 해서 동일한 Hex 값을 가지지 않습니다. 물론 PK 부분은 동일한 값을 가지지만 파일간의 구분을 위해 뒤에 내용을 약간 다르게 해서 구분합니다. 이를 기준으로 볼 때, 해당 파일은 압축파일에 해당하는 ZIP 파일임을 알 수 있습니다.

패킷들을 토대로 보면, 우리는 서버에서 클라이언트로 key.zip 파일이 전송되었고, 해당 파일에 대한 데이터 패킷이 [그림 6] 과 [그림 7]에 포함되어 있는 것을 알 수 있다. [그림 2]에는 전체가 보이지 않지만, 전체 패킷을 보면 Flag로 추정되는 패킷은 보이지 않고 TLSv1.2가 보이는 것으로 보아 뒤쪽에서는 SSL 통신을 하는 것을 알 수 있는데, 우리가 찾은 key.zip이 해당 key 파일 이기를 빌면서 파일을 받아 보도록 하자.

일반적으로 파일을 HxD에 옮겨보면, 그 파일에 대한 hex값이 나오개 된다. 당연히 [그림 7]의 값을 복사하거나, [그림 6]의 값을 복사해서 넣으면 간단하다 라고 보는 사람도 있겠지만, 그것이 반드시 그렇지만은 않다. [그림 6]의 ASCII 값을 복사할 경우, HxD에 넣을 때 16진수의 값이 아니기 때문에 맞게 넣을 수 없다고 나오며, [그림 7]을 넣기 위해서는 노가다가 상당히 필요하다. 그러나 'Show and save data as'에서는 Raw 기능도 지원하는데 이는 말 그대로 Raw한 16진수 값으로만 파일을 주게 된다. 해당 값을 그대로 전부 복사하여 HxD에 붙여 넣으면 [ㄱ림 8]과 같이 저장되고, 그것을 zip파일로 풀어내면 우리는 [그림 9]와 같은 파일을 볼 수 있다.

[그림 8. Raw로 보기와 HxD에 복사한 화면]

[그림 9. key.zip 파일 안에서 나온 pem 파일]

zip 파일을 풀면 server_key.pem 이란 파일을 확인 할 수 있는데 내부 내용을 notepad 등으로 열어보면 기존의 pem파일과는 약간 다른 것을 알 수 있다. pem 파일은 인증서와 key 파일로 구성되어 있기 마련인데, 이 파일은 Key 파일만으로 구성된 것으로 보아 실제 파일 확장자는 .key 임을 추측 할 수 있다.(그러나 pem 파일로 그냥 둬도 문제를 푸는데는 하등의 지장이 없다.) 그럼 우리는 이 key 파일을 어디에 사용할 수 있을까?

고민의 답은 그렇게 오래 걸리지 않을 것으로 보인다. 전체 패킷을 처음부터 자세히 훝어보면 SSL 통신을 하는 패킷이 보인다. 패킷은 전체적으로 내용이 암호화 되어있어 보이지 않으며, 현재 우리가 찾은 정보는 Flag 값이 아니기 때문에 우리가 찾는 최종 정보가 .key 파일도 아닌것으로 보인다.(실제로 문제를 보내준 팀원에게 저 값을 답으로 보냈다가 좀 더 노력하라는 답변을 들었다.)

그러면 이제 우리는 SSL 통신의 암호화를 풀어야 한다. 집에 도어락을 열기 위해서는 암호가 필요하듯이, 현재 우리가 보는 패킷에도 키 파일이 필요하다. 상당히 우연스럽게도(?) 우리가 구한 key.zip에는 key 파일이 들어있었다. 이 파일을 이용해서 SSL 통신을 복호화 해 보자.

[그림 10. 현재 패킷에 Key 파일 등록하기]

WireShark에서 SSL Decrypt를 위해 Key 파일을 넣는 방법을 알아보자. 우선 Menu의 [Edit] 탭에 들어가서 [Preference]를 누르면 [그림 10]의 큰 화면이 나오게 된다. 해당 탭에서 왼쪽 메뉴란의 Protocol을 눌러 SSL을 찾아 내려가면 Secure Socket Layer가 나오는데 RSA keys list를 눌러 작은 그림과 같이 파일을 넣어주면 SSL 등록이 완료 된다.

SSL Key 파일 등록을 완료했다면 아까는 암호화되어 제대로 보이지 않던 SSL 통신들이 HTTP로 복호화 되어 우리 눈에 알 수 있게 보이게 된다. 패킷을 아래로 내리다보면 우리가 찾고있던 Flag로 의심되는 파일에 대한 패킷을 볼 수 있다.

[그림 11. 복호화 된 SSL Packet에서의 Flag 값]

보통 CTF의 목표는 Flag 값을 찾아서 입력하여 OK Sign을 받는 경우가 대부분이기에 현재 저 Flag.jpg 파일을 받았다고 해서 이 분석이 마무리 된 것은 아니다. 아까 zip파일을 보던 것과 같이 Follow Stream을 통해 전송 데이터를 확인해야 한다. 단, 아까는 TCP Strem으로 봤더면, 이번엔 SSL Stream으로 봐야 정상적인 데이터 값이 보이게 된다.(해당 통신은 SSL 통신을 복호화 한 것이기 때문이다.)

[그림 12. Flag.jpg 파일의 SSL stream 값]

그 다음 과정은 key.zip 파일을 얻기 위해 진행했던 과정과 동일하다. Show and save data as ASCII 를 Raw로 변환한 뒤 복사하여 HxD에 붙여넣고 jpg File Signature(FF D8 FF E0)을 찾아 해당 파일부터 마지막까지 값을 jpg 확장자로 저장한다. 그러면 [그림 13]과 같은 최종 값을 알 수 있다.

[그림 13. Flag.jpg 파일 복원]

[그림 13]에서 알 수 있듯이 해당 CTF는 TJ CTF라는 외국 CTF 문제 중 하나이다. 패킷을 분석해 Flag 값을 찾는 CTF 문제로 CTF에서는 꽤 출제되는 유형이다. 향후 [무작위_문제풀이]에 올라오는 문제들의 경우 팀에서 공유된 문제에 대한 간단한 Write Up 형식으로 올라올 가능성이 높다. 다만 필자는 실제 CTF에 참여해 본 경험이 없기에 보고서 형식의 Write Up이 아닌 이런 문제 풀이 방식의 Write Up을 올릴 것으로 보인다. 되도록이면 앞으로 자주 블로그를 할 수 있도록 노력하겠다.

* 참조

 [1] https://chp747.tistory.com/55

 [2] https://www.garykessler.net/library/file_sigs.html