Test

[ * ] 문제 확인

문제를 확인하기에 앞서, 해당 문제는 아래 블로그에서 가져온 연습 문제임을 밝힙니다 :)

http://eniac-security.tistory.com/83

주어진 파일은 위와 같으며 vmdk 파일은 가상 머신에서 데이터를 저장하기 위한 용도로 사용되는 가상의 디스크이며 vmdk 파일이 있다면 디스크를 인식시켜 데이터를 가져올 수 있고, 주어진 지문은 다음과 같다

1. 총 파티션의 개수

2. FAT32 파티션은 존재 하는가

3. NTFS 파티션은 존재 하는가

4. 각 파티션의 크기는 얼마인가

5. 첫 번째 파티션에 있는, 확장자를 포함한 파일 이름은 무엇인가

6. 두 번째 파티션에 있는, 확장자를 포함한 파일 이름은 무엇인가

7. BR 영역에서 올바르지 않은 점은 무엇인가

8. KEY 값은 무엇인가 (Key is로 시작)

[ * ] 해결 방향

해당 문제는 파일 시스템인 NTFS와 FAT32의 구조에 대한 해석이며 해당 문제를 해결하기 위한 기본 지식은 http://forensic-proof.com의 체계적으로 잘 정리되어 있는 자료에서 얻을 수 있다.

[ * ] 해결 과정

주어진 vmdk 파일을 하나의 디스크로 인식시키기 위해 Forensic Tool Kit를 이용하여 마운트 하였고 해당 과정은 아래의 사진과 같다

해당 가상 디스크를 마운트 하기 전 주의사항은 지문에서 주어진 문제를 해결하는 과정에서 디스크의 데이터를 변경해야하기 때문에, 디스크 보호를 위해 기본값으로 되어 있던 Read Only 부분을 Writable로 수정해주어야 한다. 마운트를 하게 되면 아래의 사진과 같이 마운트 과정에서 지정해주었던 드라이브 문자와 함께 X와 Y파티션이 인식 됨으로써 해당 vmdk 파일에는 2개의 논리 파티션이 있음을 알 수 있다

 현재 사용하던 C,F,K 드라이브 이외에 X,Y가 마운트 됨을 확인할 수 있었고, 아래와 같이 디스크가 인식 되지 않음으로 보아 해당 디스크에 손상된 부분이 있음을 알 수 있다

해당 디스크에서 가지고 있는 문제점을 찾아 Trouble-Shooting을 위해 Hxd Editor로 해당 디스크를 열어주었다

주의 점은 디스크를 열기 위해서는 Hex Editor를 관리자 모드로 실행시켜야 하며 데이터를 쓰기 위해서는 읽기전용 항목에 체크를 해제 해주어야 함

가상 디스크 파일을 열어 주었고 첫 번째로 X와 Y 파티션이 가지는 문제점을 찾기 위해 MBR 부분의 구조 분석을 통해 BR이 시작되는 즉, 파티션의 시작 섹터를 찾아야 한다

위의 자료는 MBR이 가지는 전체적인 구조이며 현재 문제를 이해하고 풀기 위해서 필요한 부분은 아래와 같이 Partition Table 부분이다

Partition Table은 총 64바이트를 가지며 각 파티션은 16바이트 씩 사용, 총 4개의 파티션을 만들 수 있고, 하나의 파티션 테이블이 가지는 구조는 아래와 같다

1. 첫 번째 필드는 Boot Flag가 오며 부팅 가능 여부를 나타내고 0x80은 부팅가능, 나머지 값은 부팅 불가능이다

2. 두 번째 필드는 CHS 주소지정 방식을 사용할 경우 파티션의 시작 부분을 나타내며, 528MB라는 저장 공간의 한계로 대개 사용하지 않음

3. 세 번째 필드는 Partition Type을 나타내며 0x07일 경우 NTFS를 나타내며 0x0B 또는 0x0C일 경우 FAT을 나타낸다

4. 네 번째 필드는 CHS 주소지정 방식을 사용할 경우 파티션의 끝 부분을 나타낸다

5. 다섯 번째 필드는 LBA 주소지정방식을 사용할 경우 파티션의 시작 섹터를 나타낸다

6. 여섯 번째 필드는 LBA 주소지정방식을 사용하는 파티션의 총 크기 즉, 총 용량을 나타낸다

파티션 테이블의 각각의 필드가 의미하는 정보를 알아 보았으니 해당 문제의 파티션 구조를 알아보자

마운트 되었던 두 개의 디스크를 통해 알 수 있었던, 파티션 테이블에 두 개의 파티션 정보가 들어가 있음을 확인할 수 있다 

첫 번째 파티션 = 부팅 불가, 파티션 타입 없음, 파티션의 시작 섹터 : 0x0000003F,  파티션의 총 섹터 수 : 0x00A0120E

위의 두 사진처럼 값을 수정해 주었다니 아래와 같이 첫 번째 논리 디스크였던 X 파티션이 인식 되었다

X파티션에 들어갔더니 아래와 같이 파일이 하나 있었고 해당 파일은 확장자를 가지고 있지 않아 파일을 특정짓기 어려웠기에 Hex Editor로 시그니쳐 값을 보았다

png 파일임을 의미하는 시그니쳐 값 "89 50 4E"를 볼 수 있었고 해당 파일의 확장자를 png로 바꾸어 주었더니 아래와 같은 사진 파일을 확인할 수 있었다

여기까지가 첫 번째 파티션의 BR영역 수정을 통한 첫 번째 파티션의 인식 과정과 해당 파티션에 있던 파일을 확인하는 과정이었고 이어서 두번째 파티션 분석을 이어가겠다

두 번째 파티션 = 부팅 불가, 파티션 타입 없음, 파티션의 시작 섹터 : 0x00A0124D, 파티션의 총 섹터의 수 : 0x009FD38C

두 번째 파티션의 시작은 10490445번째 섹터에서 시작하므로 시작주소로 이동했고 FAT32라 적힌 BR영역을 확인할 수 있다

다시 한번 해당 BR영역이 올바른 파일시스템을 가지고 있는지의 확인이 필요하므로 FAT32의 백업본의 위치인 파티션의 시작섹터 +6 섹터 즉, 10490451로 이동해보았다

FAT32 파일시스템이라면 백업본이 위치해야할 섹터에 BR영역으로 보이는 데이터는 보이지 않음을 통해 해당 파일시스템은 FAT32가 아니며 첫 번째 파티션과 반대인 NTFS라고 생각할 수 있고 실제로 백업본의 위치에 가본다면 사실을 알 수 있기에 NTFS의 백업본이 존재하는 파티션의 제일 끝으로 가기 위한 계산식을 이용해서 해당 섹터에 가보았다

"Start LBA Addr + Size of Sector - 1" 

10490445(0xA0124D) + 10474380(0x009FD38C) -1 = 20964824

해당 20964824번째 섹터에 있던 NTFS 파일시스템의 BR 백업본을 복사해 NTFS 파일시스템의 시작 파티션인 10490445번째 섹터에 붙여 넣어 준 뒤 MBR 영역의 Partition Type에 0x07로 값을 수정해 주었다

위의 두 사진처럼 값을 수정해 주었다니 아래와 같이 두 번째 논리 디스크였던 Y 파티션이 인식 되었다

해당 Y파티션에 들어가 보았더니 아래와 같은 Tail이라는 이름의 파일을 확인할 수 있었다

마찬가지로 파일 확장자가 없음으로 인해 파일을 특정짓기 어려웠기에 Hex Editor로 시그니쳐 부분을 확인해 보았고 해당 부분이 비어있음을 확인할 수 있었다

파일의 헤더 시그니쳐 부분이 비워져 있음을 통해 어떻게 특징을 구분짓나 하며 생각하던 도중 해당 데이터의 끝 부분에서 ZIP파일의 시그니쳐를 의미하는 부분이 보였고 헤더를 "50 4B 03 04"로 만들어 주고 확장자를 zip으로 만들어 주었더니 아래와 같이 rtf 파일이 하나 있음을 확인할 수 있었고 해당 파일을 열람하니 문자열을 확인할 수 있었다

해당 문자열은 대소문자와 숫자의 조합을 통해 BASE64 암호화가 되었음을 추측했고 BASE64 복호화를 지원하는 크롬 확장프로그램인 Hasher를 통해 해당 문제의 지문에서 요구하는 Key 값을 구할 수 있었다

1. 총 파티션의 개수 = 2개

2. FAT32 파티션은 존재 하는가 = 존재 함

3. NTFS 파티션은 존재 하는가 = 존재 함

4. 각 파티션의 크기는 얼마인가 = 4.99GB & 4.94GB

5. 첫 번째 파티션에 있는, 확장자를 포함한 파일 이름은 무엇인가 = KEEEEEEEEEEEEEY.png

6. 두 번째 파티션에 있는, 확장자를 포함한 파일 이름은 무엇인가 = Tail.zip

7. BR 영역에서 올바르지 않은 점은 무엇인가 = 백업 영역에서 NTFS와 FAT32가 서로 바뀌어 있음

8. KEY 값은 무엇인가 (Key is로 시작) = Key is :)_Start_Forensic

참조 사이트

http://jh8992.tistory.com/entry/Day1-WarmingUp-%ED%92%80%EC%9D%B4

http://forensic-proof.com

데이터를 붙여준 위의 값으로는 아스키 문자로도 표현이 되지 않을 뿐더러 의미 있는 데이터를 추출해 내기 어려웠으므로 진수 변환을 한다면 특정한 포맷을 가지는 바이너리 데이터가 되지 않을까 하는 생각에 16진수로 바꾸어 주었고 그 결과는 아래와 같다

78, 9C, CB, 8C, CF, 48, 2C, 49, 8D, 2F, 4D, 06, C2, F4, 44, 00, 2A, 9F, 05, B7

위 데이터가 가지는 의미는 무엇일까 하면서 생각하다 40자리라는 SHA-1 해시 함수의 특징을 가졌기에 문자를 해시화해 저장하는, "레인보우 테이블"을 제공하는 온라인 사이트를 이용해 복호화를 한다면 숨겨진 메시지의 원문이 나오지 않을까 싶어 복호화를 시도 해보았지만 테이블에 해당 해시 값이 존재하지 않았고, 다른 방향을 찾아 검색 도중 "78 9C"로 시작하는 시그니쳐의 확장자는 zlib라는 것과 zlib는 C에서 사용하는 데이터 압축 라이브러리의 일종이라는 것을 알게 되면서 해당 16진수 데이터는 zlib의 압축 데이터이며 압축을 풀어주게 되면 해당 문제에서 요구하는 hidden message를 얻을 수 있을 것 같아, 아래와 같이 해당 바이너리를 적어주고 test.zlib로 저장해 보았다

왜 열리지 않나 싶어 생각해보니 라이브러리의 일종인데 그게 압축 해제가 가능할리가 있나 싶었고 아직 미개함에서 벗어나기 위해 공부를 많이 해야겠다는 생각이 들었다 ㅋ.ㅋ 어쨌거나 zlib 파일의 압축의 해제를 어떻게 할까 찾아보다 파이썬에서 zlib 모듈과 해당 모듈에서 Decompress를 지원함을 알 수 있었고 샘플 코드를 찾아 본 뒤 작성해주었더니 mp3 파일에 숨겨진 메시지를 추출해 낼 수 있었다

Hidden Message = i_hate_ucucuga

참조 사이트

https://ko.wikipedia.org/wiki/ID3

https://en.wikipedia.org/wiki/ID3

https://ko.wikipedia.org/wiki/Zlib

http://quangntenemy.blogspot.kr/2014/01/phdays-ctf-quals-2014.html

https://stackoverflow.com/questions/1316357/zlib-decompression-in-python

http://hacktracking.blogspot.kr/2014/01/phdays-ctf-quals-2k14-mp3-me-1400-points.html

[ * ] 문제 확인

2013_ASIS FFinal300.pcap라는 패킷 캡쳐 파일이 주어지며 해당 패킷속에서 Key 값을 찾는 것이 해당 문제가 요구하는 것이다

[ * ] 해결 방향

이전에 포스팅 했던 Codegate_WeirdShark의 문제와는 달리 시원스럽게 열리는 것을 확인할 수 있었고, 해당 패킷의 흐름속에서 주고 받은 텍스트 파일, 사진 파일, 동영상 파일 등과 같은 멀티미디어의 흔적을 찾는다면 해당 문제에서 요구하는 Key 값을 얻어낼 수 있을 것 같다 

[ * ] 해결 과정

현재 문제에서 주어진 파일은 총 3263개의 패킷이 있으며 이를 전부 일일이 분석한다는 것은 시간적인 측면으로도 비효율적일뿐더러 기술적인 면에서도 발전이 더딜거라 생각하기 때문에 수 많은 패킷들 중 특징이 있는 것들로만 모아서 분석을 한다면 조금 더 빠르고 정확하게 찾아낼 수 있지 않을까 라는 생각이 들었다. 근본적으로 패킷이란 서로 다른 두 네트워크 간에 주고 받는 데이터의 흐름이기 때문에 이들이 주고 받는 패킷의 유형과 전체적인 동작에 대한 통계를 냄으로써 다양한 정보를 쉽게 얻을 수 있는 것이 없을까 찾아보다가 WireShark는 Statistics라는 탭에서 통계 기능을 제공한다는 사실을 알 수 있었다

통계 기능 중 Conversations라는 부분이 있는데, Conversations라 함은 장치 사이의 통신이며 MAC 계층 주소, 네트워크 계층 주소, 포트 번호 등을 포함하는 것이며, 해당 부분이 제공하는 기능은 장치 사이의 통신을 패킷, 바이트, 비트/초, 총 대화의 지속 시간등을 기준으로 활발한 연결을 찾는데 많은 도움을 주는 역할을 하며 아래의 사진은 해당 문제에서 Conversations라는 기능을 이용하고자 창을 띄운 것이다

해당 창에서 확인할 수 있는 탭은 Ethernet/IPv4/IPv6/TCP/UDP이며 각 탭의 옆에 있는 숫자는 대화의 수이다 예를 들어 위의 사진 처럼 IPv4 옆 4는 해당 사진에서 볼 수 있듯 4개의 대화가 이루어져 있음을 의미한다

위 사진을 보면 사설 IP 대역인 172.16.133.133과 172.16.133.149에서 상호간에 가장 활발히 패킷을 주고 받음을 알 수 있었으며 해당 패킷의 흐름을 따라가기 위해 패킷의 시작점을 알아야 했고 그 시작점은 Relation Start를 의미하는 듯한 Rel Start라는 부분에서 3.732919라는 패킷의 시작 시간 정보를 알 수 있었다. 알아낸 시간 정보를 기반으로 TCP Stream을 따라가는 과정이 담긴 사진은 아래와 같다

패킷의 흐름을 따라 갔더니 두 사용자 간의 주고 받은 대화가 있었으며 해당 대화에서 문제에서 요구하는 Key 값을 얻을 수 있었다.

Key = M)m5s6S^[>@#Q3+10PD.KE#cyPsvqH

구한 Key 값이 읽을 수 있는 형태가 아닐뿐더러 대화에서 Secret Key라고 한것으로 미루어 보아 암호에 대한 복호화 또는 압축파일에 사용되는 키 값이라 예상해볼 수 있고, 암호화 된 부분을 찾아 해당 키 값을 통해 복호화를 하거나 압축파일의 암호키로 사용되어 플래그 값의 추출을 진행까지 해야하는 문제인 것 같은 느낌이 들어서 해당 문제를 조금 더 알아보고 현재 포스팅 부분을 보완할 예정이다

http://deepinsecurity.blogspot.kr/2013/09/asis-ctf-2013-forensics-100-pcap.html >>>참조 바람.

참조 사이트

http://stih.tistory.com/17

https://openmaniak.com/kr/wireshark_stat.php