[Codegate 2016] manager write up

codegate 2016 manager 문제인데, 대회 당시 확인도 안해본 문제였다.

해당 문제를 봤더라도 배경지식이 부족해서 풀지 못 했을 것 같다.

이 문제를 풀기위해서는 OS Command Injection과 Reverse Connection의

기초 지식을 가지고 있어야 한다.

저 두 가지만 알고 있으면 exploit 과정은 쉽다.

Binary 분석

manager 바이너리를 확인 해보면

manager: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=a4698eb00a40f6bd349108bb366744948db63d06, stripped

위와 같이 64bit elf 파일인 것을 확인 할 수 있다.

파일의 보호 기법을 보면 NX-bit와 Stack Canary가 있는 것을 확인 할 수 있다.

NX-bit가 있는 것으로 봐서는 RTL이나 ROP를 이용 해야 될 것으로 판단된다.

하지만 binary 크기가 작고 dynamically linked인 것으로 보아 ROP로 쓸 가젯을 구하기 쉽지 않을 것으로 예상된다.

또한 Stack canary가 있는 것으로 보아 FSB, canary leak 취약점이 필요 할 것 같다.

보통 위에 정보로는 RTL이나 ROP를 생각하는데, 이 문제는 RTL이나 ROP를 하는 문제가

아니였다.

Program Logic 분석

동적으로 프로그램 기능을 확인해보면 manager shell 기능이 먼저 보인다.

위에 보는 것처럼

ps, who, ping, if, logout 등 여러 기능이 있는데,

각 기능이 실제 서버의 shell 명령어로 동작한다는 사실을 알 수 있다.

이를 통해서 command injection의 가능성이 있을 것 같아보였다.

그 외 user info를 입력, 수정, 보기 등의 기능이 있었습니다.

입력, 수정, 보기 기능 중에서도 취약점의 발생 가능성을 염두해두고 분석했다.

먼저 manager shell 기능에서 command injection 가능성이 높아보여서

해당 부분을 집중적으로 분석하였다.

main 소스를 확인해보면 sub_402497 함수 호출 시

인자 전달이 많다는 점이 특이하지만 그 밖에 다른 동작을 하지는 않는다.

sub_402497함수에서 manager shell 기능을 하는 부분을 찾아보겠다.

각 메뉴마다 switch가 jmp eax로 되어있어서 hexray를 통해서 소스를 확인하면,

전체 소스를 확인 할 수 없었다... 이런 경우 설정하는 방법을 알아바야 될 거 같은데

혹시 아시는 분은 알려주시면 감사하겠습니다ㅠㅠ

그래서 어쩔 수 없이 어셈블리어를 확인해서 진행했습니다.

마찬가지로 각 기능별로 동적으로 호출해서, 원격디버깅을 붙이거나

해당 동적 영역을 하나 하나 찾아서 분석해야된다.

다행이 해당 함수에서 사용하는 스트링 값이 있어서 이를 통해서 쉽게 찾을 수 있었다.(shift+f12 누르면 스트링 리스트)

여러 기능 중 추가로 입력 받는 함수는 ifconfig 함수가 있었다.

이를 통해서 가장 command injection 가능성이 높아 보여서 제일 먼저 확인 해봤다.

운이 좋게도 strcat을 통해서 ifconfig 명령어를 붙여서 쓰고 있었고,

popen 함수를 이용하기 때문에 command injection 취약점이 발생한다.

단, str_filter(네이밍한 함수)함수에서 command injection을 방지하기 위해서

블랙리스트 방식으로 필터링 하고 있었다.

Exploit

ifconfig 기능에서 command injection이 가능하지만

블랙리스트 방식으로 필터링을 해서 자주 쓰는 ; / && / `` 문자를 쓸 수 없었다.

다행히 '('), ')', '$' 이 필터링 되어 있지 않아서,

$(command) 를 이용해서 우회 할 수 있었다.

해당 기능을 이용해서 /bin/sh를 실행하고

reverse connecrtion을 통해서 shell 을 얻을 수 있었다.

exploit 과정은 아래 사진처럼 하면 된다.

exploit 과정이 너무 허무해서... pwnable 문제를 푼거 같은 느낌이 안 들지만

이번 기회를 통해서 리눅스 nc에서 -e 옵션이 디폴트로 없는 것을 알았고,

하지만 다른 방법을 통해서 reverse connection을 할 수 있다는 것을 공부 할 수 있었다.

시간이 된다면, nc -e 기능 없이도 다양한 방법으로 reverse connection 하는 방법을

정리해볼 생각이다.

또 os command injection에 사용되는 명령어를 이번 기회를 통해서 정리해서

다음에 유사한 문제가 나오면 빨리 풀 수 있을 것 같다.