[Pwn] Docker파일 주어진 경우 Heap 분석 환경셋팅

최근 Pwnable 문제를 풀면서 부딪힌 Error에 관해 해결방법을 찾아 정리한 글로

잘못된 부분이 있다면 댓글로 알려주시기 바랍니다.

 

---

Heap 분석을 위한 플러그인

포너블 문제를 하다보면 stack과 heap을 분석해야 할 경우가 많다.

작성자가 사용하는 pwndbg나 pwn-peda의 경우 아래의 Github및 명령어를 이용해 빌드하는 편이다.

 

# pwndbg install
git clone https://github.com/pwndbg/pwndbg
cd pwndbg
./setup.sh

# gdb-peda install
git clone https://github.com/longld/peda.git ~/peda
echo "source ~/peda/peda.py" >> ~/.gdbinit

#heapinfo 등 명령어 추가
cd ~/
git clone https://github.com/scwuaptx/Pwngdb.git 
cp ~/Pwngdb/.gdbinit ~/

 

문제는 pwndbg에서는 heap구조를 보기 쉽게 보여주는 명령어가 없고

(작성자가 못찾은 것일 수도 있지만 알 수 없었다.)

 

gdb-peda에서는 플러그인을 추가해야만 heap구조와 tcache_entry등을 볼수 있었다.

 

위와 같이 peda에서는 heapinfo, parseheap등으로 현재 디버깅중인 바이너리의

heap구조를 확인할 수 있다.

 

이렇게만 보면 heap구조를 분석하는데 아무런 문제가 없어보이지만

실제로 이렇게 분석을 하게 되면 remote와 local에서의 차이가 발생한다.

 

---

Pwnable분석 버전 패치

기본적으로 pwnable CTF나 워게임의 문제로 나오는 것은 바이너리 파일이다.

그리고 이러한 바이너리 파일은 빌드된 버전의 영향을 받는다.

 

이때 사용되는 라이브러리또한 버전 취약점 패치가 이루어져

버전에 따라 Exploit이 가능하냐 불가능하느냐가 갈리기에 libc와 ld를 함께 제공하거나

맞는 우분투, 리눅스를 빌드 할 수 있는 Docker file을 함께 제공하는 것이

기본으로 이루어 지고 있다.

 

 

그래서 기존에는 Docker를 빌드하고 해당 도커에서

바이너리 파일을 ldd로 확인해 사용된 라이브러리 파일의 경로를 찾고

사용된 libc와 ld를 확인해 이를 gdb-peda 와 분석툴이 있는 Docker 밖으로 추출하여

 

바이너리를 아래의 명령어로 패치를 진행해왔다.

patchelf --set-interpreter ./ld ./binary
patchelf --replace-needed libc.so.6 ./libc ./binary

 

이렇게 파일의 libc와 ld를 패치하면 local과 remote에서의 라이브러리가 동일해지면서

버전 문제로 안보이던 취약점을 찾을 수 있거나

leak하려던 주소들의 offset등이 동일해져 Exploit Code를 작성할 수 있었다.

 

---

Heap분석 Error

하지만 최근에 문제를 풀던중 분석툴에 추가한

Heap을 볼 수 있게 해주는 플러그인이 동작하지를 않았다.

 

(해당 플러그인은 아래의 Github에서 받은 플러그인을 사용했다.)

https://github.com/scwuaptx/Pwngdb.git

GitHub - scwuaptx/Pwngdb: gdb for pwn

 

특이한 점 없이 기존의

Pwnable 문제를 분석하던 대로

도커에서 libc와 ld를 추출하고 분석 툴이 깔린 위치에서

바이너리 패치를 진행한뒤 gdb-peda로 동적분석을 시도했다.

 

패치가 잘못됬다면 실행에 실패해야 했지만,

바이너리 파일은 정상적으로 작동하고 vmmap등을 확인해 봐도

정상적으로 패치된것을 확인할 수있었다.

 

하지만 heap구조를 보려고 플러그인으로 추가된 명령어

heapinfo나 parseheap등을 사용하면 다음과 같은 에러를 리턴한다.

해당 에러를 플러그인을 받은 Github에서 확인해 보았더니

플러그인의 python코드에서 global libc_version을 받아오지 못하는 경우의 발생하는 에러라는 것을

확인 했을 뿐 패치를 진행했음에도 왜 받아오지 못하는 것인지 이유를 알 수 없었다.

 

그러다 version 에러를 키워드로 검색하다 동일한 문제를 겪고 해결한 사람을 찾을 수 있었다.

https://whitel0tus.tistory.com/65

[0x41414141 CTF] Babyheap

마침 버전도 동일한 2.27에서 발생했는데 이러한 에러가 발생하는 문제는

디버깅 심볼 정보를 읽어오지 못했기 때문으로 libc와 ld말고도 디버깅 심볼등의 정보가 담긴

파일이 필요하다고 한다.

 

위의 글에서 알려준 대로 링크를 타고가 해당 파일을 다운받으려고 했는데

해당 글이 작성된지 오래된 글이여서 인지

우분투측에서 더이상 해당 파일다운의 경로를 제공하고 있지 않았다.

구글링을 해봤지만 공식적으로 해당 파일을 제공하고 있는 곳을 찾을 수 없었다.

 

추가로 heap분석을 하면서 다른 문제에서도 같은 문제가 발생한다면

매번 버전에 맞는 디버깅 심볼 파일을 찾아야 하는 반복적인 문제가 발생한다.

 

그래서 이러한 문제를 어떻게 해결할 수 있을지 멘토에게 질문을 넣었다.

 

---

해결 방법

멘토에게서 받은 자료를 그대로 공개할 수는 없어 글로 정리한다.

 

기본적으로 바이너리는 환경구축이 까다롭고 데몬, 라이브러리 관련 문제와

환경 구축시 초기화의 어려움등이 있다.

그리고 이러한 문제는 분석 시간의 지연으로 이루어지는데

한마디로 정리하면 종속성의 문제가 있다는 것이다.

 

그리고 이러한 종속성의 문제는 동적 분석을 하는데 문제를 일으키고

local과 remote간의 차이를 증가시켜 Remote Exploit 성공률을 낮추게한다.

 

그래서 착안한 방법이 디버깅환경을 문제의 Docker 안에 주입시켜

까다로움을 최소화 시키는 방법을 선택한다고 한다.

 

도커 문제는 요청시 프로세스가 하나씩 떨어져나와 새롭게 생성되는데

실제로 작성자가 겪은 문제의 도커도

재실행을 할때마다 컨테이너를 새롭게 생성했다.

 

그래서 멘토님은 환경 초기화를 하기위해 매번 새롭게 구축할 필요없이

image를 재실행하는 것으로 프로세스를 새롭게 받아 분석하는 방법을 사용할 수 있다고 한다.

 

정리하면 아래와 같은 분석툴의 libc version이 맞지 않는다거나

 

환경 셋팅의 문제가 발생하면 문제에서 제공한 Docker를 빌드할때

gdb, nc, git, tmux, python등 필요한 툴을 설치하는 명령어를 Docker file에 추가하고

Docker를 빌드하여 해당 도커안에서 직접 분석을 하는 것을 추천하셨다.

 

직접 도커안에서 분석툴을 설치한 결과는 다음과 같다.

도커안에 peda를 설치하고 heapinfo, parseheap같은 플러그인이

정상적으로 작동해 동적분석과 함께 heap의 분석이 가능해졌다.

 

추가로 해당 Docker환경에서 Exploit이 성공하면 offset등 또한

remote와 일치하기 때문에 Remote Exploit Code를 구성하는데도 매우 수월하다.

---

Docker 추가 분석도구 명령어

#Dockerfile에 추가후 Docker build
RUN apt-get install python -y
RUN apt-get install netcat -y
RUN apt-get install vim -y
RUN apt-get install gdb -y
RUN apt install git -y
RUN git clone https://github.com/longld/peda.git ~/peda
RUN echo "source ~/peda/peda.py" >> ~/.gdbinit
RUN git clone https://github.com/scwuaptx/Pwngdb.git ~/Pwngdb
RUN cp ~/Pwngdb/.gdbinit ~/.gdbinit

 

위 도구 외에도 tmux등 본인이 익숙한 분석환경 도구를 설치하면 좋지만

최대한 서버의 환경과 비슷해야 하므로 최소한의 설치가 좋다고 합니다.