2020 NEWSECU CTF write up

$ Capture The Flag $

2020 NEWSECU CTF write up

ws1004 2020. 2. 23. 12:51

File Forensic

Disk

문제 파일을 압축 풀어보면 아래와 같이 newsecu 라는 파일이 하나 나옵니다.

파일의 hex값을 확인해보면 아래와 같습니다.

알 수 없는 값을 띄고 있지만, 비밀번호를 같이 준것으로 보아 TrueCrypt로 암호화 했을 가능성이 있습니다.

TrueCrypt를 이용해서 mount를 해보겠습니다.

mount가 완료 되었고 디스크 안에 있는 파일을 확인해 보겠습니다.

50.0MB 짜리 가상 하드디스크 인 vhd 파일이 존재합니다.

하지만 마운트를 하기 위해서 Arsenal Image Mounter를 이용했지만 아래와 같은 창이 출력 됩니다.

데이터가 손상된 것 으로 확인이 됩니다.

hex값을 확인해 보면 PASSWORD RECOVERY 라는 문자열을 확인 할 수 있습니다.

해당 문자열을 보면 323818-582835-535667-541277-630894-033132-013915-228217 로 bitlocker 복호화 키라고 생각이 됩니다.

0x260 부터 00으로 쭉 덮여 있습니다.

0x10000에 데이터가 시작해야 하지만 아래와 같이 조금 밀려 있습니다.

그렇기 때문에 0x10000에서 데이터가 시작할 수 있도록 값을 아래와 같이 조정해 보겠습니다.

그리고 mount를 해 보겠습니다.

마운트 성공 했습니다.

예상대로 비트락커로 암호가 걸려있습니다.

위에서 확인한 복호화 키를 넣어보면 아래와 같습니다.

FTK Imager로 해당 Logical Disk를 import 시켜서 확인해 보겠습니다.

해당 폴더와 파일을 살펴 보면 flag.txt라는 파일이 있습니다.

하지만 size가 0 입니다.

허나 $RECYCLE.BIN(휴지통)이 눈에 보입니다.

안에 보면 Flag를 찾아 볼 수 있습니다.

Flag : NEWSECU{BITLOCK3R_FOR3NS1CS_P3NT4L}

IOS Forensic

Board

해당 문제는 메모장을 분석해 봐야 합니다.

더 있을 수도 있지만 필자는 2가지 방법으로 Flag를 발견 했습니다.

1. NoteStore.sqlite 에서 데이터 찾기

2. rtf 파일에서 데이터 찾기

첫번째 방법 부터 설명해 드리도록 하겠습니다.

NoteStore.sqlite 파일이 있는 경로를 먼저 찾아 보면 아래와 같은 경로에 파일이 존재 합니다.

해당 경로에 존재 하는 sqlite 파일을 db 파일을 열어볼 수 있는 DB Browser for SQLite 를 이용해서 열어 보겠습니다.

많은 테이블 중에서 ZICCLOUDSYNCINGOBJECT 테이블에는 Note의 TITLE 이 들어있으며 ZICNOTEDATA 테이블 에는 Note의 Contents 가 들어 있습니다.

ZICCLOUDSYNCINGOBJECT 테이블 에서 주의 깊게 봐야 하는 칼럼은 Z_PK칼럼 과 ZTITLE1칼럼 입니다.

TITLE 값이 들어있는 Z_PK 는 8,9,10,11입니다.

그리고 ZICNOTEDATA 테이블을 볼텐데 해당 테이블 에서 주의 깊게 봐야하는 칼럼은 ZNOTE칼럼과 ZDATA 칼럼 입니다.

해당 칼럼에서 봐야할 점은 앞에서 확인한 TITLE 값이 들어있는 Z_PK 와 ZNOTE의 값이 같다는 점과 ZDATA 값 입니다.

ZDATA 란 메모에 들어있는 데이터가 들어있는 칼럼 입니다.

BLOB 라는 데이터는 문자열이 아닌 바이너리 데이터가 DB 파일에 들어있어서 저렇게 표시를 하는 것입니다.

여기서 유심히 봐야할 점은 ZNOTE == 11 인 ZDATA에는 NULL 이라고 되어 있습니다. 원래 해당 데이터 자리에는 FLAG 데이터가 들어있습니다.

하지만 왜 NULL 데이터가 들어 있는가 있는 가를 보면 이미지 파일을 열어본 FTK Imager 로 가보면 NoteStore.sqlite 파일 경로에 아래와 같은 파일들을 확인 할 수 있습니다.

위의 NULL 데이터가 들어있는 DB파일은 NoteStore.sqlite 파일 하나만 추출한뒤에 DB Browser for SQLite 에 넣은 모습입니다.

하지만 파란색 상자로 된 NoteStore.sqlite-shm 파일과 NoteStore.sqlite-wal 파일을 NoteStore.sqlite 파일과 같이 총 3개의 파일을 추출한뒤 DB Browser for SQLite 에 넣고 위와 같은 쿼리문을 다시 확인 해 보면 아래와 같이 데이터를 확인 할 수 있습니다.

ZICCLOUDSYNCINGOBJECT 테이블의 Z_PK == 11 인 ZTITLE1의 값을 보면 RkxBR3tOM1dTM0NVXzFQaDBuZV9GMHIzbnNpY19CMGFyZH0= 라는 값이 들어가 있습니다. 이는 Base64로 된 인코딩 문자열이고 디코딩을 하면 FLAG{N3WS3CU_1Ph0ne_F0r3nsic_B0ard} 라는 flag를 얻을 수 있습니다.

이렇게 바로 Flag 가 나오지만 ZICNOTEDATA 테이블의 ZDATA 를 다루는 이유는 위의 FLAG는 TITLE에 적혀있던 FLAG이기 때문에 파일 내용을 찾고자 하시는 분이 있으실수 있기 때문에 풀이에서 다뤄 봤습니다.

ZICNOTEDATA 테이블의 ZNOTE == 11 인 ZDATA 를 확인해 보면 아래와 같이 바이너리 데이터가 들어있는 것을 알 수 있습니다.

해당 HEX 값은 1F 8B 시그니처로 GZ 파일 입니다.

그렇기 때문에 내보내기 할때 ~~~.gz 을 하면 내보내기를 성공 적으로 할 수 있습니다.

gz압축을 해제 후 내부 파일의 hex 데이터를 확인해 보면 아래와 같이 FLAG가 Base64 인코딩된 문자열이 들어있는 것을 확인 할 수 있습니다.

첫번째 방법을 이용해서 문제에 접근을 할 때 꼭 db파일과 wal 파일과 shm 파일을 전부 추출후 db파일을 열어보시길 바랍니다!

이번에는 두번째 방법 입니다.

rtf 파일에서도 FLAG를 찾을 수 있었는데요!

먼저 rtf 파일이란?

서식 있는 텍스트 포맷 또는 리치 텍스트 포맷(Rich Text Format) 이라고 해서 마이크로소프트 사가 개발한 문서 파일 형식입니다.

메모장은 아니였지만 FLAG가 rtf 파일에도 들어 있었습니다.

rtf 파일의 경로는 아래와 같습니다.

TXT.rtf 를 열어보면 아래와 같이 파일 내용에 Base64 인코딩 문자열이 들어 있습니다.

이를 디코딩 하면 FLAG{N3WS3CU_1Ph0ne_F0r3nsic_B0ard} 를 의미 합니다.

물론 해당 ios 문제 파일인 Apple iPhone6.tar 을 strings 명령을 이용해 보면 FLAG를 바로 확인 할 수 있습니다.

Flag : FLAG{N3WS3CU_1Ph0ne_F0r3nsic_B0ard}

Can you find music?

녹음한 파일의 노래 제목과 음악 앱에 저장한 음악 제목을 찾으면 되는 문제 입니다.

녹음파일은 아래의 경로에 있습니다.

Recordings 폴더 하위에 있는 m4a 파일을 찾아보면 아래와 같이 총 6개의 파일이 존재 합니다.

이중에서 5개의 파일은 똑똑 거리는 소리밖에 나지 않지만 "20191220 111017.m4a" 파일은 노래소리가 녹음 되어 있습니다.

녹음된 노래의 제목은 아이유 의 Love Poem 입니다.

FLAG{lovepoem: 까지 찾은 셈입니다.

이번에는 음악 앱에 저장한 음악을 찾아 보겠습니다.

음악 앱을 IPhone 에서 유명한 앱인 iTunes로 생각하고 iTunes 폴더로 찾아가 봤습니다.

해당 폴더 하위에 MediaLibrary.sqlitedb 파일이 있습니다.

이번에도 shm 파일과 wal 파일이 같이 있기 때문에 같이 추출해 보겠습니다.

추출한뒤 DB Browser for SQLite 를 이용해서 열어보면 아래와 같습니다.

해당 DB 파일에는 테이블이 41개나 존재 합니다.

주의 깊게 봐야하는 테이블은 album 테이블, base_location 테이블, item_artist 테이블, item_extra 테이블입니다.

album 테이블을 확인해 보면 다운로드 받은 album 이름이 적혀 있습니다.

Album Name은 Frozen 2 (겨울 왕국 2 OST) 라고 되어 있습니다.

base_location 테이블을 확인해 보면 노래가 다운로드 되어있는 경로가 적혀 있습니다.

해당 파일이 들어 있는 전체 경로는 아래와 같습니다.

이번에는 item_artist 테이블을 확인해 보겠습니다.

해당 음원의 artist 가 들어있는것 같습니다.

Artist Name 은 Idina Menzel & Evan Rachel Wood 라고 되어 있습니다.

item_extra 테이블은 아래와 같습니다.

음원의 제목은 Show Yourself 이며, 저장된 파일의이름은 UGES.mp3입니다.

앞서 언급한 경로인 \private\var\mobile\Media\iTunes_Control\Music\F22\UGES.mp3 를 확인해 보면 show yourself 라는 것을 알 수 있습니다.

Flag : FLAG{lovepoem:show_yourself}

Search

해당 문제는 아이폰으로 사이트에 접속후 댓글을 남겼는데 해당 주소를 찾는 문제 입니다.

먼저 해당 이미지 파일인 아이폰 에서 어떤 브라우저를 사용했는지 확인해 보면 Safari 만 사용한 것을 알 수 있습니다.

Safari 의 History.db 파일에 접속 로그가 남아있기 때문에 해당 경로를 살펴 보겠습니다. 경로는 아래와 같습니다.

해당 History.db 파일도 shm파일과 wal파일과 동시에 추출해서 DB Browser for SQLite 에 넣어서 열어보겠습니다.

해당 db파일에는 8개의 테이블이 존재합니다.

이중 눈여겨 봐야하는 테이블은 history_items 입니다.

이런식으로 접속한 URL이 존재합니다.

이 많은 URL 중에서 https://blog.system32.kr/m/50?category=819446 에서 댓글을 적은 것을 확인 할 수 있습니다.

@newsecu.ctf 라는 문자열이 있는걸 보니 답과 관련이 있는 댓글 같습니다.

Flag : FLAG{https://blog.system32.kr/m/50?category=819446}

Memory

해당 문제는 IPhone의 메모리 덤프 파일을 주어주고 보내던 매일의 내용과 수신자의 메일을 찾는 문제입니다.

dump 파일은 바이너리 값으로 이루어진 파일들이기 때문에 string 검색으로도 문제를 해결할 수 있습니다.

해당 파일 전체를 대상으로 strings 명령어를 사용해 보겠습니다.

0x102000000_dump.data 파일에서 위처럼 Flag로 확인되는 문자열이 존재 합니다.

발신자 : <newsecu.ctf@gmail.com>

파일내용 : M4il_F0rensics_W1th_M3m0ry_Dump

수신자 : <mail.forensics@protonmail.com>

이라는 것을 확인 할 수 있습니다.

Flag : FLAG{M4il_F0rensics_W1th_M3m0ry_Dump_mail.forensics@protonmail.com}

Recovery SMS

2가지의 문자 데이터를 찾아야 합니다.

1. 전송한 문자 메시지의 내용과 한국시간

2. 삭제한 문자 메시지의 내용과 한국시간

문자 메시지의 저장 경로는 아래와 같습니다.

sms.db 파일도 마찬가지로 sms.db-wal 파일과 sms.db-shm 파일 이 존재 하기 때문에 한번에 추출해서 분석해야 합니다.

DB Browser for SQLite 를 이용해서 sms.db 파일을 열어보면 아래와 같습니다.

해당 DB에서 중요한 테이블인 message 테이블 과 sync_deleted_messages 테이블을 유심히 보시면 될 것 같습니다.

message 테이블을 확인해 보면 FLAG 가 눈에 먼저 보입니다.

FLAG가 들어있는 문자를 보낸 문자로 확인 하면 될 거 같습니다.

또한 위의 문자들을 확인해 보면 FLAG문자열이 받은 문자에 대한 답변으로도 생각 할 수 있습니다.

문자 내용은 1ph0ne_sms_f0r3nsics_v3ry_sp3cia1 입니다.

해당 문자를 보낸 시간을 확인해 보면 아래와 같이 DATE를 보시면 됩니다.

599562650267624960 입니다.

앞자리 9자리를 잘라보면 599562650 입니다.

해당 값을 dcode.exe 라는 툴에 넣어서 확인해보면 아래와 같습니다.

20200101181050 이 문자를 보낸 한국 시간입니다.

FLAG{1ph0ne_sms_f0r3nsics_v3ry_sp3cia1:20200101181050_ 지금까지 알아낸 FLAG입니다.

이제 삭제한 문자를 찾으면 될것 같습니다.

이번에는 sync_deleted_messages 테이블을 확인해 보겠습니다.

삭제된 문자가 들어있는 테이블입니다.

ROWID가 19와 20인 데이터는 recordID 가 NULL이기 때문에 유심히 안봐도 되지만 ROWID가 21 22인 데이터는 recordID가 없습니다.

생각할 수 있는 부분은 아직 wal 파일에서 데이터가 안들어 왔다라고 생각이 되서 sms.db-wal 파일을 확인해 봤습니다.

sms.db 파일은 DB Browser for SQLite 에서 열리지만 sms.db-wal 파일은 열리지 않습니다.

그래서 해당 사이트(https://github.com/n0fate/walitean) 에서 wal 파일을 db 파일로 만들어주는 툴입니다.

해당 툴을 보면 완벽하게 복구를 하지는 않은 것 처럼 보입니다.

DB Browser for SQLite 를 이용해서 확인해 보면 아래와 같습니다.

똑같은 데이터를 반복적으로 뽑아낸 이유는 뭐 툴문제 인거 같긴 하지만 저희가 봐야하는 문자열은 2개 입니다.

5D0E8A32-7C29-4F63-ACB2-BDF513B419B7 : Can you carve the message?

547BE327-80CD-4FB5-A71B-76183592A338 : FLAG{C4rv1ng_1os_M3ssage}

삭제한 보낸 문자는 FLAG 문자열이 붙은 C4rv1ng_1os_M3ssage 입니다.

하지만 메시지 보낸 시간을 알 수 없습니다.

툴 때문인지 나오지 않기 때문에 바이너리 데이터를 바탕으로 시간을 구해야 할것 같습니다.

sms.db 파일 에서 어떻게 데이터가 들어있는지 확인해 보겠습니다.

FLAG 데이터의 GUID는 CFEC81D2-5FEE-4344-AAB2-05781918E5D7 입니다.

CFEC81D2-5FEE-4344-AAB2-05781918E5D7 와 관련된 db 데이터 입니다.

먼저 앞서 찾은 시간은 599562650267624960 이였습니다. 해당 값을 16진수로 바꿔 보면 0x0852130DC5CB2600 입니다.

위의 hex값을 찾아보면 아래의 위치에 존재 합니다.

똑같이 sms.db-wal 파일을 hex 값을 확인해서 같은 위치에 존재하는 값을 추출해 보겠습니다.

0x08569663D4D47100를 10진수로 바꿔 보면 600832955817160960 값이 나오는데 앞자리 9자리를 끊어서 dcode에 넣어보면 아래와 같습니다.

삭제한 메시지를 보낸 시각은 20200116110235 입니다.

Flag : FLAG{1ph0ne_sms_f0r3nsics_v3ry_sp3cia1:20200101181050_ C4rv1ng_1os_M3ssage:20200116110235}

Scenario

Scenario 0

시나리오 설명인것 같습니다.

Flag는 그냥 입력하면 Clear! 됩니다.

Flag : flag{newsecu_challenge}

Scenario 1

PC의 내부 IP 주소를 알아 내기 위해서 FTK Imager을 이용해서 열어보겠습니다.

대부분 IP 주소는 레지스트리 키에 들어 있기 때문에 다른 문제들을 대비해서 아래의 레지스트리 키 파일을 추출하겠습니다.

해당 파일들을 추출하고 REGA 라는 레지스트리 키 파일을 이용해서 값을 확인 할 수 있는 툴을 이용해서 열어보겠습니다.

IP 주소가 들어있는 레지스트리 키 경로인 HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces 하위에 알맞은 GUID 하위에 IP 주소가 들어 있습니다.

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{d4ab6859-3b8b-4e3d-84f4-5cabdc109841}의 서브키 DhcpIPAddress 키에서 IP 주소를 찾을 수 있었습니다.

Flag : flag{10.0.0.4}

Scenario 2

악성코드의 C2 Server로 추정되는 IP를 찾는 문제 입니다.

악성코드 관련 통신이 있었다면 이벤트 로그에 데이터가 남아 있을 것 입니다.

이벤트 로그의 경로는 C:\Windows\System32\winevt\Logs 입니다.

이벤트 로그로 분석을 해서 C2 Server을 찾는 것은 알 겠으나 방대한 양의 로그 중에서 어떤 것을 찾아야 하는지 알 수 없습니다.

FTK Imager 에서 파일을 찾던중 C:\하위에 mimi 라는 폴더를 확인했습니다.

해당 폴더 하위에는 mimikatz.exe 프로그램이 들어 있었습니다.

mimikatz.exe 프로그램은 윈도우에서 사용자의 계정을 탈취 할때 사용하는 프로그램입니다.

그렇기 때문에 해당 프로그램과 C2 Server와 관련이 있을것도 같습니다.

Logs 파일을 대상으로 검색을 해보겠습니다.

먼저 로그파일에 문자열이 어떻게 들어가는지 확인 해보겠습니다.

모든 문자열이 1글자당 2바이트의 값을 가지고 있습니다.

mimikatz가 아닌 \x6d\x00\x69\x00\x6d\x00\x69\x00\x6b\x00\x61\x00\x74\x00\x7a\x00 라고 검색을 해야 할 것 같습니다.

총 3개의 evtx 파일에 mimikatz 라는 문자열이 들어 있습니다.

1. Microsoft-Windows-PowerShell%40perational.evtx

2. Microsoft-Windows-Windows Defender%40perational.evtx

3. Windows PowerShell.evtx

PowerShell이 자주 보이는 것으로 보아 mimikatz에 대한 작업을 한것으로 여겨 집니다.

여기서 해당 파일들을 분석을 하면되지만 더빨리 하는 방법이 있습니다.

grep 옵션중 -o를 없애면 해당 mimikatz가 포함된 값을 보여주게 됩니다.

하지만 위의 사진에서 -o를 넣은 이유는 깔끔하게 확인 하기 위해서 입니다.

-o를 없애면 위와 같이 아스키숫자 범위를 넘어가는 값들은 저렇게 뜨기 때문에 지워뒀었습니다.

실행 결과 첫줄을 보면 wget를 이용해서 http://13.209.138.195/upload.mimikatz_trunk/x64/mimikatz.exe 를 다운 받은 흔적이 있습니다.

그렇기 때문에 악성코드 관련 C2 서버는 위와 같이 13.209.138.195 입니다.

Flag : flag{13.209.138.195}

Scenario 3

일단 앞서 Scenario 2 에서 크리덴셜 탈취에 사용된 도구가 mimikatz.exe 라는 것을 찾았었기 때문에 최초로 다운로드 시도한 시간을 찾으면 될 것 같습니다. 앞에서는 -o 옵션을 제거해서 확인했지만 이번에는 최초 다운로드 시간을 찾아야 하기 때문에 정렬을 이용해야 할 것 같습니다.

이벤트 뷰어 파일을 확인해 보면 아래와 같습니다.