(1) 사건의 원인?
첨부된 vmware 파일을 열어서 확인해 보면 default 경로에 아래와 같이 숨겨진 파일들이 엄청 많은 것을 확인 할 수 있다.
이런 파일 중에서 .viminfo 파일이 눈에 보입니다.
.viminfo 파일이란 vim을 사용했을때 작성되는 일종의 log 파일을 의미합니다.
해당 파일에는 vim 을이용해서 수정하고 작업을 했던 파일의 로그 파일 형식처럼 작성이 됩니다.
해당 파일을 열어보면 매우 방대한 내용이 들어있습니다.
여기에 적혀있는 파일들을 정리해 보면 아래와 같습니다.
위의 경로를 확인해 본 결과 /root/ 는 접근이 불가능 했고, /var/www/html/test.html 파일은 존재 하지 않았다.
wordpress 와 관련 있는 파일들을 자세히 봐야 할것 같다.
그중 /var/www/html/wordpress/wp-admin/user/web/flaskr/flaskr.py 에서 key 값을 확인 할 수 있었습니다.
k33333y is werkzeugvspr0t0ss 라는 문자열을 비밀키 라고 지칭하고 있다.
답 : werkzeugvspr0t0ss
허나 왜 공격자는 /var/www/html/wordpress/wp-admin/user/web/flaskr/flaskr.py 해당 파일에 key를 숨겨 둔것일까 라는 의문이 들었다.
먼저 flaskr 가 무엇인지 알아보자.
flaskr 란? 블로깅 응용 프로그램으로 일종의 게시판 기능을 하는 웹서버를 구동 시켜줍니다.
아래의 내용은 flaskr의 소개 및 기능입니다.
1. 사용자가 구성에 지정된 자격 증명으로 로그인 및 로그 아웃하도록합니다. 한 명의 사용자 만 지원됩니다.
2. 사용자가 로그인하면 텍스트 전용 제목과 텍스트에 대한 일부 HTML로 구성된 새 항목을 페이지에 추가 할 수 있습니다. 이 HTML은 우리가 사용자를 신뢰하기 때문에 위생 처리되지 않았습니다.
3. 색인 페이지에는 지금까지의 모든 항목이 역순 (맨 위)에 표시되며 사용자는 로그인 한 경우 여기에서 새 항목을 추가 할 수 있습니다.
그렇다면 key가 숨겨져 있었던 flaskr.py는 flaskr를 실행시켜주는 실행 파일입니다.
flaskr.py에서 USERNAME 은 admin 이며, PASSWORD 는 default 이고, DEBUG의 값이 True로 되어있어서 디버깅 모드가 켜져 있습니다.
먼저 flaskr.py를 실행 해 보겠습니다.
그리고 localhost:5000 으로 접속을 해보면 아래와 같은 창이 출력이 됩니다.
login을 클릭해 보면 login 폼이 출력이 됩니다.
flaskr.py 에 있던 ID와 PW인 admin / default 를 입력해줍니다.
그러면 아래와 같이 게시판이 출력이 되는데 XSS 공격을 실시해보겠습니다.
해당 게시판 관련 코드의 권한 문제로 인해서 sqlite3.OperationalError : attempt to write a readonly database 가 출력이 되게 됩니다.
기본적으로 어떤 파일의 몇번째 줄에서 오류가 나는지 정도만 출력이 되지만 아래의 사진처럼 콘솔을 열수 있는 버튼이 존재 합니다.
해당 콘솔 버튼을 클릭해서 파이썬 코드를 입력하면 프롬프트에서 실행이 됩니다.
아마도 flaskr.py에 키값을 넣어둔 이유가 디버깅 모드가 켜져 있어서 에러를 일으켜 프롬프트 콘솔창을 실행 시킨뒤에 악성 행위가 가능해서 라고 생각 했습니다.
(2) 공격 방법은 무엇인가?!
1번 질문에서 localhost:5000에 접속 해서 디버깅 모드시에 에러가 터졌을때 콘솔을 이용할수 있다는 것을 확인 했었습니다.
주요 키워드 들인 wordpress flaskr debugger CVE 로 검색을 해봤습니다.
CVE-2015-5306 이라고 해서 CVE 취약점이 존재하는 것을 확인 했습니다.
CVE-2015-5306에 대해서 좀더 확실하게 맞는지 확인하기 위해서 검색해본 결과 아래의 주소에서 확인할 수 있었습니다.
주소 : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5306
앞서 확인한 취약한 부분과 매우 일치하는 취약점이였습니다.
답 : CVE-2015-5306
(3) 취약점 패치
앞서 확인한 CVE 를 다시 봐보면 디버그 모드가 활성화됬을 때 발생하는 취약점 입니다.
그렇기 때문에 디버그 모드를 활성화 시킨 코드가 원인이기 때문에 해당 코드의 라인넘버와 코드를 답으로 제출하면됩니다.
답 : 11_"DEBUG = True"
(4) 백도어와 리눅스
1번 질문에서 확인한 .viminfo 파일에서 /tmp/.mysqlsock_113992 파일을 확인은 했지만 언급을 안했습니다.
Password가 적혀 있는 것을 확인 할 수 있습니다.
해당 파일에 Password를 저장하고, 파일명을 보았을 때 mysql sock 이라고 되어있으므로 소켓통신으로 파일 빼내는것 같습니다.
해당 파일과 연결되어있는 링크 파일이 있을 수도 있기 때문에 / 경로에서 grep 를 이용해서 찾아 보겠습니다.
이진파일 ~~~ 과 일치 문자열을 확인해 보면 총 3개가 존재 하는데 /proc/3320/ 디렉터리가 존재 하지 않습니다.
그렇기 때문에 유일하게 하나남은 /lib/x86_64-linux-gnu/security/pam_unix.so 파일이 백도어 라는 것을 알 수 있습니다.
답 : /lib/x86_64-linux-gnu/security/pam_unix.so
(5) 공격자를 알아내자
앞서 찾은 /lib/x86_64-linux-gnu/security/pam_unix.so 파일이 백도어 파일이였습니다.
해당 백도어 파일을 이용해서 악성코드를 이용했을 가능성이 크기 때문에 pam_unix.so 파일을 분석해 보겠습니다.
so 파일을 strings 명령어로 문자열을 확인해 보면 /tmp/.mysqlsock_113992 문자열을 확인할 수 있습니다.
또한 /etc/skelecton &> /dev/null 이라는 문자열도 확인 할 수 있습니다.
/var/log/auth.log 파일을 확인해 보면 /etc/skelecton 디렉터리를 삭제 한 것을 알 수 있습니다.
하지만 현재 존재하는 /etc/skelecton 파일을 확인해 보면 ELF 파일인 것을 확인 할 수 있습니다.
/etc/skelecton 파일을 IDA 에 넣어서 확인해 보면 loc_40126E 에서 중요한 문자열을 찾을 수 있습니다.
curl 명령을 이용해서 파일을 주고 받은 것 같습니다.
위와 같이 악성 파일은 /etc/skelecton 인것을 알 수 있습니다.
답 : skelecton
(6) 근원지를 찾아라
악성코드 파일인 skelecton 에서 C&C 서버의 근원지를 찾았다고 했으니 해당 파일을 분석해 봐야 할 것 같습니다.
앞서 본 IDA에서 0x4012BF에서 curl 명령어를 확인 했습니다.
그렇다는 것은 해당 명령어의 인자값으로 C&C IP를 사용했을수도 있다는 뜻이기 때문에 GDB 를 이용해서 한번 확인해 보겠습니다.
0x4012BF 이긴 하지만 아래와 같이 미리 선언 됩니다.
그렇기 때문에 선언하는 부분을 넘긴뒤에 스트링을 확인해 보면 값을 확인 할 수 있습니다.
0x401169 에 break를 걸고 run을 진행해 보겠습니다.
그리고 $rsp 를 문자열로 확인해 보겠습니다.
mysql 소켓을 이용해서 http://211.239.122.233/logger.php 로 값을 보내는 것을 확인 할 수 있습니다.
답 : 211.239.122.233
(7) Secret Key!
6번문제에서 악성코드를 분석했을때 C&C IP주소와 암호화된 키를 문자열로 확인 했었습니다.
암호화된 키 : U2FsdGVkX18rxOpW5IDMvgRo3SOfHkKMK+k0o6OueIC23CUz+SOCVw==
해당키의 길이가 56이기 때문에 DES 암호문으로 판단이 됩니다.
DES는 현재 로서는 취약한 암호화 기법이면서, DATA : 56bit KEY : 8bit 으로 해서 총 64비트를 가지고 있습니다.
brute force를 진행해서 키값인 1234를 획득 하고 아래의 사이트에서 복호화를 진행하면 데이터를 확인 할 수 있습니다.
https://www.browserling.com/tools/des-decrypt
답 : SKELECTONISSKELECTON
(8) 드러나는 배후조직
앞서 /home/hdcon/.viminfo 파일에서 다루지 않았던 파일인 /etc/.Clue을 확인해보면 해당 파일은 존재하지 않습니다.
대신 /etc/.clue 파일이 있는 것을 확인 할 수 있습니다.
/etc/.Clue 에서 /etc/.clue 로 변경된 이유는 /var/log/auth.log 에서 확인 할 수 있습니다.
mv명령어를 이용해서 이름을 변경 한것을 알 수 있습니다.
JackTheRipper 라고 이야기를 하고 있습니다.
답 : We Are JackTheRipper
비고(개인 공부 정리용) :
앞서 분석한 skelecton 에 대해서 좀더 다뤄 보려고 합니다.
문제를 해결하려고 했을때는 해당 파일을 분석할때 재대로 분석을 하지 않아서 놓친 부분들이 좀있었습니다.
먼저 아래와 같이 key=%s&data=%s 와 curl - d \"%s\" '%s' -s & 문자열을 포함하고 있는 loc_40126E 에 해당하는 함수에 break 를 걸고 run이 안되는 현상이 있었습니다.
run이 안되는 이유는 주요함수라고 생각되는 sub_401014 에 있었습니다.
참고로 저는 IDA 7.0을 사용했는데 IDA 7.2로 디컴파일을 확인해 보면 조금 다르게 나온다.(=보기좋게)
하지만 아직 이상한 부분이 존재합니다.
키값도 보이지않고 여러 값이 없습니다.
그이유는 디컴파일 시에 프로그램에 존재하는 함수들이 너무 많아서 전부 디컴파일이 되지 않았기 때문입니다.
806개의 함수를 전부 디컴파일을 한뒤에 sub_401012를 확인해 보면 아래와 같이 잘 나오는 것을 확인 할 수 있습니다.
이중 0x40126E 에 brake후에 run이 안되는 이유는 위에 표시한 코드에 있습니다.
sub_418180 이라고 되어있지만 해당함수를 보기 쉽게 변경해보면 아래와 같이 변경할 수 있습니다.
open 함수와 거의 일치합니다.
또한 2번째 인자값으로 들어간 값은 unk_4A2E08 인데 아래의 사진과 같이 'r'을 의미합니다.
그렇기 때문에 /tmp/.mysqlsock_113992 파일이 있어야 접근이 가능합니다.
파일을 생성한 뒤에 break 및 run을 해보면 잘되는 것을 확인 할 수 있습니다.
핵심 값을 확인해 보겠습니다.
문자열이 잘나오는 것을 알 수 있습니다.
또한 sub_401014에서 무한 루프의 while 문이 존재 하는데..
해당 while 문은 키로거를 의미합니다.
'Forensic Chellenge' 카테고리의 다른 글
[CFReDS Project] Hacking Case (0) | 2020.04.12 |
---|---|
[CFReDS Project] DFR-01-RECYCLE(FAT) : Recover one file from emptied recycle bin (0) | 2020.04.08 |
OtterCTF 2018 write up (0) | 2020.04.03 |
WhiteHat 2015 write up (0) | 2020.03.11 |
CCE 2017 write up (0) | 2020.03.09 |