Latte의 보안이야기

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

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

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

- OS : Windows 10 EnterPrise 64bit

- RAM : 32GB

- 필요 Tool : HxD 또는 WinHex

DMA 스터디가 쉰지도.. 대략 1년? 그정도가 된 듯 싶다. 개인의 사정에 의해, 그리고 여러가지 핑계로 인해 쉰지 약 1년쯤.. 그리고 지금으로 부터 한 두달전쯤일까.. 아래 두 Quest를 준 팀원이 어김없이 문제를 하나 던졌다. 그에게서 주어진 문제는 hi.docx 파일 뿐. 본인도 기억나진 않지만 CTF에서 나왔던 문제라고 했고, Flag를 가져오라는 미션이 주어졌다.

저기요??? 시작부터 난관에 부딧치기 시작했다. 물론 지금처럼 이렇게 함부로 파일을 열어서는 안된다. 가상머신을 켜지 않은 지금은 더더욱 이래서는 안됐다. 문서를 받을 때 이미 수없이 질문하고 검증을 했으니 이번만은 넘어가도록 한다. 아무튼 정상적으로 켜지지 않았지만, 강제로 확인을 계속 눌러봤다.

" 이 문서는 오픈 포멧으로 저장되었습니다" 라는 문구가 보인다. 
오픈 포멧은 다음과 같이 정의되어있다. "오픈 포맷(open format)은 디지털 자료 저장을 위한 규격으로 보통 사유가 아닌 표준 조직이 관리하며 사용에 법적 제한이 없다."[1] 과연 오픈 포멧이라는 문구가 힌트가 될지, 아니면 함정이 될지는 문제를 풀어가면서 봐야 할 듯 하다.

한가지 중요한건, 이 문서가 100% 정상적인 Word 파일은 아닌것 같다는 점이다. 정상적인 워드 파일이라면 [그림 1]과 같은 오류코드는 나타나지 않고 [그림 2]의 문구가 열려야 정상이기 때문이다. 물론 완전히 손상된 파일은 또 아닌 것 같은데, 이는 어쨋든 복구로는 열리긴 열린다는 점이다.
일단, 문서 내에 흔히 랜섬웨어에 사용되는 매크로 같은 것들은 포함되지 않은 것으로 보여진다. 본 분석에 사용된 PC는 필자가 집에서 개인적으로 사용하는 PC인데, 기본적으로 워드파일의 매크로 설정을 사용하지 않고, 필요 시 알림 처리 하도록 되어 있기 때문이다.

문서 내에서 확인할 수 없다면 문서 밖에서 살펴보도록 하자. 우리가 늘 그래왔던 것처럼.. 일단 HxD를 켜서 해당 문서를 열어보도록 하자. 이미 어느정도 공부를 했던 분들이라면 이 문서의 일부분을 본순간 "아! 저 답은 어디에 있겠구나!"라는 것을 알 수 있겠지만, 이 블로그의 기본 목적은 그래도 나름 쉽게 풀어보는 것이기 때문에 조금 지루하더라도 같이 보는 친구에게 스포를 하지 말도록 하자.

아마 과거에 모든 파일에는 File Signature라는 것이 존재한다는 것을 이야기 한 적이 있다. 시그니처라는 것은 일종의 그 존재만이 가지고 있는 유일한 것을 의미한다. 실제로 개인이 카드 결제 후 하는 서명도 Signature라고 하는데, 우리가 흔히 싸인 이라고 말하는 signature라는 것은 결국 자신만이 하는 서명이기 때문이다. 
필자가 분명히 바로 위에서 signature는 유일 한 것이라고 했다. 이 부분에서 고개를 갸우뚱 하는 독자분들도 분명히 존재할 것이다. 몇몇 게시글에서도 이야기 했지만 [그림 4]의 가장 앞 두개(0x4B50, PK)는 우리가 잘 알고 있듯이 ZIP의 시그니처이기 때문이다.

위 사진은 자주 애용하는 File Signature 정리 사이트[2]에서 캡쳐한 부분으로, 일반적으로 파일의 값이 PK로 시작할 경우 ZIP 파일인 경우가 대부분이다. 그런데 왜 워드파일인 docx의 확장자에서 zip파일의 파일 시그니처가 확인 되는 것일까?

마이크로소프트에서 제공하는 Office 확장자들(docx, pptx, xlsx 등)은 OOXML(Office Open XML)을 기반으로 한 파일 포멧을 가지고 있는데, 기본적으로 XML 파일을 기반으로 하고 있다. 2000년 Excel 을 위해 만들어진 초기 버전이 발표되었으며, 2002년 워드를 위한 파일포멧이 추가되었고, 2003년 오피스에 통합되었다. 그리고 이 OOXML은 '압축된' XML 기반의 파일형식을 가지고 있기 때문에 HxD에서 확인될 때 ZIP파일과 같은 PK로 시작하는 signature를 가지고 있는 것이다. 자, 이제 그러면 본격적으로 분석을 위해 분석용 백업 파일을 생성하고 확장자를 zip으로 변경하도록 하자.

파일 시그니처가 zip파일과 동일하기 때문에 zip 파일로 확장자를 변경한다 하더라도 동작을 안한다거나 하는 문제가 발생하지는 않는다.(zip 파일 이외에 7zip같은 확장자로 변경을 시도하지는 말자. 두 확장자는 파일 시그니처가 다르다.)
[그림 6]에서 보이는 모습이 실제 word 파일의 구조라고 보면 된다. 위에서 설명했듯이 OOXML 파일포멧을 가지고 있는 word 파일은 압축된 XML의 형태를 가지고 있고 폴더를 들어가보면 xml 파일들이 다수 들어가 있는 것을 알 수 있다.

각각의 폴더의 내용들에 대해서는 이곳에서 다루지는 않을 것이다. 주 목적이 아닐뿐더러, 글이 너무 길어지면 보기 짜증나는 수도 있으니까 말이다. 아무튼 위에서 워드파일은 압축된 xml 파일들이라고 말했다. 이제부터 각 폴더를 들어가 특이한 내용이 있는지 한번 확인해보도록 하자.

필자의 경우는 무식하게 하나하나 열어보긴 했었지만, 이 글에서는 그 부분은 생략하도록 한다. word라는 폴더를 보면 secret.xml이라는 뭔가 우리를 부르는 듯한 파일이 하나 존재한다. 해당 파일을 열어보면 아래와 같은 내용이 존재한다.

secret.xml을 열면 우리가 알 수 없는 문자열로 표기되어 있는 xml 파일을 볼 수 있다. 그런데 뭔지 모르겠으면서도 뭔가 어디선가 본거 같은 형태이다. =(equal) 표시가 있다면 가장 확실하겠지만 그렇게 난이도가 쉬운 문제를 CTF에서 내 줬을것 같지는 않다. 일단 가장 머리속에 가장 의심되는 base64를 먼저 이용해보자. 구글에 base64 decoding을 검색하면 가장 먼저 뜨는 사이트가 있다. 필자는 그곳을 제일 많이 이용하는 편이다.[3]

우리가 원하는 값이 저곳에 포함되어 있는 것으로 보인다. CTF란 말 Capture The Flag, 즉 Flag를 찾으면 되는 내용이고 친절하게 secret flag= 라는 내용이 있는 것으로 봐서 bcactf{0OxMl_1s_4m4z1Ng가  Flang 값인 것을 알 수 있다.
마지막으로 끝내기 전에, secret.xml이 기본적으로 워드파일내에 존재하는지 확인해 보도록 하자.
동일한 내용의 워드파일을 test.docx라는 파일로 만들고 zip 파일로 변경하였다.

이후 백업파일을 생성 후 위 과정과 동일한 과정을 거쳐 secret.xml이 존재하는지 확인해 보았다

변조되지 않은 워드 파일에는 secret.xml이 없다!
문제를 푸는데는 여러가지 방법이 있을 수 있다. 이 방법 외에 다른 방법이 더 있을지는 모르겠으나, 공부에는 왕도가 없고 풀이에도 크게 왕도는 없다!! 문제 출제자가 원하는 답변은 있겠지만...

※ 출처

[1] https://ko.wikipedia.org/wiki/%EC%98%A4%ED%94%88_%ED%8F%AC%EB%A7%B7
[2] https://www.garykessler.net/library/file_sigs.html
[3] https://www.base64decode.org/

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

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

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

 - OS : Windows 10 EnterPrise 64bit

 - RAM : 32GB

 - 필요 Tool : HxD 또는 WinHex

이 문제를 처음 받았을 때의 정확한 날짜는 기억이 나질 않는다. 단순히 밥을 먹던 저녁 시간때 인 것만 기억날 뿐.. 대략 19시 정도..? 지난 Quest_1에 해당하는 문제를 줬던 팀원이 다시한번 문제를 발송했다. 주어진 시간은 2시간 정도? 그리 길게 시간이 주어지지 않은 것으로 보아 문제 난이도가 그리 높지는 않아보였다. 

[그림 1. 출제 문제]

우리에게 주어진 것은 png 확장자로 된 파일 하나, 그리고 그 파일에는 [그림 1]과 같이 hackover18이라고 쓰여있었다. 사실 처음에는 저게 문제가 아니라 저 사이트를 찾아 들어가는 줄 알았는데 그게 아니라 저 파일 자체가 문제였다.(기존 문제처럼 첨부가 아니라 단순 사진으로 올라와서 햇갈렸기 때문이다.

이 글을 보는 독자라면 Quest_1도 보고 왔으리라 생각하지만, 그래도 혹시모르니까 다시 한번 이야기를 하도록 하자. 아마 이번이 마지막으로 설명하는 내용이 아닐까 싶다. 

파일은 각자를 표현하는 고유한 값이 존재한다. 이 값을 File Signature 라고 하며 그것을 볼 수 있는 사이트[1]를 공유하니 참고하기 바란다. 물론 모든 File Signature가 다 다른건 아니다. 보통 앞의 4개가 Signature로 구분되기는 하나, 파일이 너무 많고 비슷한 구조가 있어 뒤에 4자리 까지 더해 8자리로 구분하거나 중간에 값을 통해 구분하기도 하니 무조건 맹목적으로 앞의 4자리만 보는 일은 없도록 하자.(Ex MS Office)

[그림 2. PNG 확장자 File Signature]

[그림 3. hackover18.png 파일의 File Signature와 Trailer]

[그림 2]에서 보는바와 같이 png 파일의 File Singature는 89 50 4E 47 0D 0A 1A 0A 이며 Trailer 값은 49 45 4E 44 AE 42 60 82 이다.(물론 이렇게 외우는 것 보다 %PNG / IEND 로 외우는게 더 편하다) 이를 토대로 볼때, 이 파일은 확장자 변조가 되지 않은 정상적인 PNG 파일임을 알 수 있다. 

그럼 여기서 문제가 하나 생긴다. 하나의 통으로 정상적으로 된 PNG 파일이란 소린데, 그림에는 아무 힌트도 없다. 그렇다면 설마 [그림 3]에 보이는 저 알 수 없는 값들을 해석해야 한단 소리인가? 아무리 분석이 노가다라지만 저 노가다는 사실 하고 싶지는 않다. 어떤 분들은 이 포스팅의 제목에서 눈치를 챘을 수도 있을 것이고, 아니면 PNG 파일을 열어 봤을 때 눈치를 챘을 수도 잇을 것이다. 필자는 문제를 받아 PNG 파일음을 봤을 때 어느정도 감이 오기는 했다.

[그림 3]의 Trailer는 분명 정상적인 PNG 파일의 끝을 나타내 주는 문구가 맞다. 다만 그것은 어디까지나 이 파일이 하나의 PNG Structure를 가지고 있을 때의 이야기다. 이제 어느정도 감이 오는가? 결론부터 말해주자면 이 파일은 하나의 PNG 파일이 아니다.

우선 [그림 3]을 보기 위해 열었던 HxD로 돌아가 보도록 하자. 그리고 커서를 가장 앞쪽에 위치하도록 해주자. 그리고 [Ctrl + F] 눌러 찾기로 들어가서 아까 알려준 File Signature 사이트로 접근하여 PNG 파일에 해당하는 Trailer의 hex 값을 복사하도록 하자.(띄어쓰기도 동일하게 적용해야 한다.) 그리고 확인을 눌러 [그림 3]에서 봤던 가장 마지막 부분으로 가는지 확인하자.

[그림 4. Trailer값 복사하기]

[그림 5. Trailer 결과 확인]

이상하다. [그림 5]에서 보면 중간에 PNG 파일의 끝부분이 나온 뒤 다시 PNG 파일의 Signature가 시작된다. 분명 내가 보는 것은 하나의 파일인데 두개의 파일이 들어있는 것 처럼 보인다. [그림 5] 부분에서 다시 검색을 하면 그제서야 이제 마지막 부분의 Trailer가 보이게 된다. 이제 새 File Signature부터 마지막까지 선택한 뒤 복사하여 새 PNG 파일로 저장해 보도록 하자.

[그림 6. 새 PNG 파일의 결과]

Quest_1에서 봤던 것처럼 이번에도 그림에 우리가 찼던 Flag 값이 보이는 것을 알 수 있다. 해당 문제는 실제 외국에서 있었던 CTF 문제로 지난번 Quest_1에 비해서는 어찌보면 조금 더 직관적으로 쉽게 풀수 있는 문제가 아니었나 싶다. 해당 문제는 찾기가 그리 어렵지 않을 듯 하기에 한번쯤은 풀어볼 것을 추천한다.

 * 참 조

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

* 본 게시판은 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