DeadFace CTF 2022 Write Up

CTF/해외CTF

DeadFace CTF 2022 Write Up

Ron Weasley 2022. 10. 18. 22:40

2022년 10월 14일 오후 2시부터 15일까지 열린 DeadFace CTF에 참가하였다. (사실 기간이 지나고 포렌식 문제를 풀려고 들어간 것)

바로 롸업을 작성하도록 하겠다.

Forensic

[First Strike]

문제를 보겠습니다.

문제를 읽어보면, 7월 27일에 ESU 웹사이트에 사이버 공격이 있었다고 한다. 직원은 공격으로부터 데이터를 수집했으며, 이를 검토하여야 한다고 말한다. 그래서 공격이 시작된 IP 주소에 대해서 묻는 문제이다.

주어진 문제 파일은 Access.log와 Error.log가 있는데, Error.log에 들어가서 로그를 살펴 보도록 하겠다.

로그를 살펴보면, 클라이언트 165.227.73.138로부터 hostname(우리)인 143.244.178.213으로 request를 보내는데, 에러가 뜨는 것을 볼 수 있다.

결국엔, 공격자는 클라이언트의 IP주소인 165.227.73.138이 된다.

FLAG : flag{165.227.73.138}

[ToolBox]

문제를 한번 보도록 하겠다.

문제를 보게되면, 2022-07-27 14:13 UTC 시간에 공격을 한 도구를 찾는 문제이다.

이제는 Error.log가 아니라 Access.log를 보면 된다. 로그를 살펴보면, 공격자 클라이언트 165.227.73.138 IP로 부터 Nmap으로 네트워크 스캐닝을 하는 것을 볼 수 있다.

그래서 답은 Nmap이된다.

FLAG : flag{Nmap}

[Agents of Chaos]

문제를 보게 되면, 네트워크 스캔을 도구 중 첫번째는 nmap이고 두 번째로 해당하는 것을 찾고, 첫번 째 공격을 찾는 문제이다.

Nmap에서 Nikto로 툴이 바뀐 것을 확인할 수 있다.

그리고 우측에 Test : Port Check가 보이고 포트를 검색하는 그런 기능인 것 같다.

Port Check로 플래그를 넣어줬지만 플래그가 인식이 되지 않아서 Mozilla부터 (Port Check) 까지 붙혀넣으니 답이 된다.

Mozilla/5.00 (Nikto/2.1.6) (Evasions:None) (Test:Port Check)

위에 나오는 문장이 플래그이다.

[Iterations]

문제를 한번 보도록 하겠다.

문제를 읽어 보면, 로그인을 시도 했고 로그인을 성공한 도구가 있다고 한다. 그 도구의 이름을 찾는 문제이다.

Hydra라는 툴을 사용하였고, GET으로 올린 파일의 이름이 login.php이다. 결국엔 Hydra 툴이 답이 된다.

FLAG : flag{Hydra}

[Submission]

1번부터 이어지는 문제 중 마지막 문제이다.

문제를 읽어보면, 파일 시스템에 액세스하기 위해 ESU의 웹 사이트에 올린 아티팩트는 무엇인지 찾는 문제이다.

위에서 설명 했듯이, login.php로 로그인을 시도해서 권한을 탈취하는 것 까지는 분석을 진행하였다.

이 로그들을 보시면, login.php로 로그인을 성공하여 계속해서 파일을 업로드하는 것을 볼 수 있다.

문제를 읽어보면, 웹 사이트에 올린 아티팩트를 찾는 문제인데, 결국엔 업로드 한 파일중에서 찾아봐야 하는 것이다.

로그 가장 하단에 보면, 정보에 대한 php파일이 업로드 되는 것을 확인할 수 있다.

infomation에는 파일 시스템에 대한 정보도 들어있으므로 info.php가 플래그 값이 된다.

FLAG : flag{info.php}

[Grave Digger1]

문제를 한번 보겠습니다.

문제를 읽어 보시면, crypto_vamp 계정이 취약하니까 들어가서 플래그를 찾아라. 이말로 해석이 될 수 있는데,

결국엔 ssh로 접속을 바로 해보시면 됩니다.

ssh crypto_vamp@env.deadface.io

password : 123456789q

위와 같은 명령으로 접속을 진행하면 다음과 같은 화면처럼 될 것이다.

이제 분석을 진행하기 위해서 해당 서버의 환경을 봐야해서 env 명령을 사용하였다.

근데 바로 플래그값이 나와서 조금 당황했지만, 그럴 수 있다고 생각한다!

[Inode What you Did Last Summer]

문제를 한번 보겠습니다.

문제를 보면, 7월 27일에 있었던 공격에 대한 내용중 파일이 수정된 것을 찾고, 그 파일에 대한 아이노드 값을 가져오라는 문제인데 처음에 이 문제만 딱 받았을때는 진짜 고민이 많았습니다. inode 번호를 본 적도 없고...그래서 반나절 이상 삽질을 진행했던 것 같습니다. 풀이를 바로 쓰도록 하겠습니다.

주어진 문제를 다운로드하면, gz 파일을 하나 줍니다.

gz 파일을 풀면, 메모리 덤프 파일과 zip 파일을 하나 주어집니다.

메모리 덤프 파일을 분석하기 위해 볼라틸리티를 사용했고, 볼라틸리티를 이용해서 해당 메모리 덤프 파일의 운영체제 버전을 확인하도록 하겠습니다.

볼라틸리티 설치 방법은 제 블로그에 volatility3를 보시면 됩니다.

$ python3 vol.py -f esu-mem-20220727154029.dmp banner

입력을 하게 되면, 리눅스 메모리 덤프 파일로 되어있으며 버전은 5.4.0-122 입니다.

리눅스 메모리 포렌식을 하기 위해서는 볼라틸리티 프로그램 내부에 커널 버전을 심어주고 info 명령어를 통해서 인식을 시켜줘야 분석이 가능합니다.

그래서 ubuntu 커널 버전에 맞는 ISF 파일을 찾아서 심어줘야 하는데 이번 문제에서는 착하게 주어주는군요..!

위에 압축 파일에 있는 Ubuntu_5.4.0-122-generic.zip 파일을 바로 심어주면 되는데, 저는 이번 문제가 볼라틸리티 3으로 분석을 하니 플러그인이 많이 부족해서 볼라틸리티 2버전을 사용했습니다.

volatility2에 리눅스 파일을 심어줄려면 /volatility/volatility/plugins/overlays/linux 파일에 넣어주기만 하면 됩니다.

이렇게 심어줬으면, info 명령어로 한번 볼까요?

프로파일이 인식이 되면, 정상적으로 잘 심어준 겁니다!!

리눅스 플러그인은 다음 링크를 통해서 배우시면 됩니다.

https://github.com/volatilityfoundation/volatility/wiki/Linux-Command-Reference#linux_bash

프로세스 리스트를 먼저 보겠습니다.

$ python vol.py -f [이미지 파일] --profile=LinuxUbuntu_5_4_0-122-genericx64 linux_pslist

27일 이후에 된 프로세스들을 보면, apache2도 보이고 avml(메모리 덤프) 프로그램도 보이는 것을 확인할 수 있습니다.

그래서 메모리 덤프 파일의 리스트를 보면 되니까 리스트를 한번 보겠습니다.

$ python vol.py -f [이미지 파일] --profile=LinuxUbuntu_5_4_0-122-genericx64 linux_find_file -L > find_file.txt

너무 많은 양을 보여주기 때문에 txt 파일로 추출해서 좀 보겠습니다.

backups 경로에 gz으로 된 백업 파일도 보이고 하는데, 더 찾아 보도록 하겠습니다.

pcap파일이 2개 있네요?? pcap 파일을 추출해보도록 하겠습니다.

$ python vol.py -f esu-mem-20220727154029.dmp --profile=LinuxUbuntu_5_4_0-122-genericx64 linux_find_file -i 0xffff9591bb1a3890 -O capture_20220727124309.pcap

추출을 하니까 NULL값으로 꽉 채워진 파일이 하나 나오는 것을 보아 정상적으로 추출이 되지 않은 것 같습니다...그래서 아까 우리가 프로세스에서 본 것 중에서 27일 이후로 된 프로세스중 avml로 된 메모리 덤프를 시켜주는 프로그램을 본 적이 있습니다. 그래서 avml을 찾아보도록 하겠습니다.

avml을 보니까 backup.py가 있어서 뭘 백업하는지 궁금해서 추출하니까 다음과 같은 스크립트가 짜져 있었습니다.

보니까 아까 위에 backup 경로에 있는 backup.gz이 이 스크립트를 통해서 만들어진 것을 확인할 수 있었습니다.

그래서 backup.py 파일에 나와있는 788070이 inode 값이 되고, 입력을 하니 정답이 풀렸습니다.

근데 완벽하지 않은 상태에서 찝찝하게 푼 이 기분이 참 더러워서 하단에 네트워크 패킷 분석하는 롸업이 있는데 그거랑 합쳐서 적어보겠습니다.

공격의 원리를 살펴보면, access.log에서 봤다시피 네트워크 스캔을 하고 login.php를 올려서 injection을 하고 로그인을 성공했다. 까지만 나와있었습니다. 하지만 추후에 남기는 로그들이 pcap 파일에 있었으나, 해당 메모리 덤프 파일에서는 추출이 되지 않아서 Traffic 카테고리에서 나오는 패킷을 보니 동일한 NULL 값으로 추출된 pcap 파일의 크기와 분석을 하기 위해 쓴 pcap 파일이 같은 바이트와 같은 파일 이름을 가지는 것을 확인할 수 있었다.

왼쪽은 추출한 pcap 파일이고, 우측은 분석을 하라고 준 pcap 파일이다.

결국엔 트래픽 카테고리 문제와 포렌식 카테고리의 문제가 이어져 있다는것인데...참 황당한 일이다.

그래서 패킷을 보면, shell을 가져와서 backup.py를 실행시키고 gz을 생성하는 이런 일련의 과정들을 다 하는 것을 볼 수 있다. (뒤에 설명)

그리고 dump 파일을 hxd로 열어보면 답을 좀 찾을 수 있다.

welcome.php 파일이 보이는 것으로 보아 아이디에 접속을 했다는 뜻이고, 하단으로 내려보면 backup.py를 tmp 파일로 옮기는 것을 볼 수 있다.

이를 보면서 풀 수도 있겠지만...사실상 말이 안되는 문제이다!!!

Steganography

[The Goodest Boy]

문제를 한번 보겠습니다.

주어진 사진 파일을 다운 받아서 hxd로 열어보면 하단에 패스워드가 하나 존재합니다.

패스워드가 있다는 말은 즉, steghide나 opensteganography툴을 사용해서 패스워드만 입력하면 풀린다는 말이다.

그래서 칼리에서 steghide툴을 사용해서 패스워드를 해제하고 숨겨진 플래그를 찾아보도록 하겠다.

명령어를 입력하게 되면 itsasecret.pdf 파일이 하나 추출되는 것을 볼 수 있다.

열어보면 플래그가 존재한다.

[Eye Know, Do you?]

문제를 한번 보겠다.

주어진 이미지 파일에서 플래그를 찾아라는 문제인데, 파일을 다운로드 하면 이상한 눈이 하나 나온다.

hxd로 열어봤더니 패스워드는 보이지 않아서, 명암을 조절해주기 위해 stegsolve를 사용하였다.

하단에 플래그로 보이는 것이 나오는데, 글씨가 흐릿해서 잘 보이진 않는다.

그래서 자꾸 색을 바꿔주니...어느 정도는 알 수 있게 나왔다.

FLAG : flag{Deadface_Knows_All_Seas_All}

[Life's a Glitch]

문제를 한번 보겠습니다.

문제를 읽어 보면 GIF 파일을 하나 줄테니까 스테가노그래피해라라고 적혀있습니다.

마찬가지로 hxd로는 답이 나오지 않아 stegsolve를 사용하니까 플래그 값을 구할 수 있었습니다.

Traffic Analysis

이번에 푼 카테고리는 Traffic Analysis라고해서 네트워크 패킷을 가지고 분석을 하는 문제들이다.

근데 이번 카테고리와 포렌식 카테고리가 이어지는 부분이 있어보인다. 왜냐하면 포렌식 마지막 문제를 푸는 것이 네트워크 패킷 로그를 분석해야 되는데 리눅스 메모리 포렌식에서 pcap파일이 추출되지 않아서 분석을 좀 진행해보니 지금 분석하고 있는 카테고리에서 동일한 파일이 포렌식 메모리 덤프 파일에서 나오는 것을 발견하여 같이 보면서 풀면 쉽게 풀리는 문제들이 많이 있었다.

[Dreaming of You]

문제를 한번 보겠습니다.

pcap파일을 하나 주고, 플래그를 찾으라는 문제인데 뭐...명확한 문제를 주질 않았으니 와이어샤크로 분석을 진행하겠습니다.

패킷 캡쳐 내용을 보면, TELNET 프로토콜을 가지고 접속을 한 흔적이 보입니다.

TCP Stream으로 분석을 좀 해보면, 로그인을 하기 위해서 많은 시도를 하는 것을 볼 수 있습니다.

그래서 필터링으로 TELNET 프로토콜을 제외하고 다 지워보고 분석을 시도했습니다.

아까 위에서 본 사진이 TELNET 프로토콜의 TCP Stream 0번 이였다면, 밑에 나와있는 것은 4번입니다.

TCP Stream 4번을 보니까, 리눅스가 아니라 윈도우 환경으로 접속을 하는 것을 볼 수 있습니다.

또 보시면, 볼륨 넘버가 F0DA-E16B로 잡히는 것을 볼 수도 있습니다.

쭉 내리다 보면, 플래그 값을 볼 수 있습니다.

[Scans]

문제를 한번 보겠습니다.

Traffic Analysis 문제이기 때문에 마찬가지로 pcap파일을 주는데, zip 파일로 압축되어서 파일을 하나 줍니다.

압축 파일의 패스워드는 하단에 있는 것과 같이 열면 pcap파일을 하나 줍니다.

이번 문제에서는 deadface가 처음 시작한 스캔의 유형을 찾는 문제입니다.

ICMP 프로토콜이 있는 것으로 보아 ping을 보낸 것 같구여, ping을 보낸 이유는 해당 ip를 인식 시켜주기 위해서 그런 행동입니다.

그래서 41518 포트에서 80포트로 ACK 패킷을 보냈는데 80포트에서 RESET을 보냄으로써 에러가 발생했습니다.

다음은 41518 포트가 443 포트에 SYN 패킷을 보내고, 443 포트에서 답장으로 SYN, ACK 패킷을 보냈습니다. 하지만 3-way-handshake 과정에서는 SYN→SYN, ACK→ACK 형태로 되어야 하지만, ACK를 보내지 않고 RESET을 보냅니다. 이것으로 보아 처음 시작한 스캔의 유형을 보면, ping을 제외하고 다음에 오는 ACK 패킷도 제외를 하면, 클라이언트에서 보낸 패킷 중 가장 먼저 보낸 패킷은 SYN 입니다.

FLAG : flag{syn}

[Passing on Complexity]

문제를 한번 보겠습니다.

이 문제는, 앞에서 분석했던 scans 문제랑 같은 파일을 가지고 풀어야 하기 때문에 주어진 문제 파일은 따로 없습니다.

문제를 보면, 사용자가 백업을 했는데, 백업 사용자의 암호를 확인해달라고 하니까 평문이나 암호화된 문자로 password가 존재함을 알 수 있다.

패킷을 보면 90000개 이상 잡혀있는데, 다 필요없는 패킷들이고, TCP Stream 4999번째를 보면, 다음과 같은 데이터들이 잡힌것을 볼 수 있다.

리눅스에서 입력한 명령어들이 잡힌 패킷들을 볼 수 있는데, 하단으로 쭉 내려보니 backup파일이 하나 보인다.

위 사진에서 cat /opt/backup.py를 하고 난 후, 실행된 python 코드를 보면, -pbackup123으로 된 부분을 볼 수 있다.

-p 옵션이 패스워드를 입력하는 부분이기 때문에 패스워드는 backup123이다.

FLAG : flag{backup123}

[Shells]

문제를 한번 보겠습니다.

이번 문제도 scans 문제에서 준 pcap 파일로 푸는 문제이고, 문제 해석을 하면, 공격자가 웹 서버 백엔드에 액세스하기 위해 info.php라는 파일을 업로드 했다고 한다. 여기서 info.php는 포렌식 카테고리에 있는 access.log를 읽어보면 나온다. 그리고 공격자에게 웹 셸을 제공한 셸의 이름을 찾는것이다.