[HTB] Inject Writeup
포트스캐닝을 통해 정보를 수집해보자.
nmap -sC -sS -sV -p- -O -o scanResult.txt 10.129.176.111
22, 8080 port 가 open되어있었다. 해당 포트에 취약점이 있는지 확인해보자.
nmap --script vuln 10.129.176.111 -p 22,8080 -o nmapVulnScanResult.txt -Pn
8080포트에는 아래와 같은 웹 서비스가 오픈되어 있었다.
디렉토리 나 경로 정보를 수집해보자.
gobuster dir -k -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -u http://10.129.176.111:8080/ -x .php,.html,.txt,.jsp -o gobusterResult.txt
돌아가는 동안 해당 웹 서비스를 살펴보았다. 다른 기능들은 다 막혀있었고, 파일 업로드 기능만 사용 가능했다.
파일에 대한 필터링이 있었다.
여러 방식으로 필터링 우회를 시도해보았다. 하지만 잘 되지 않았다.
우선 우회가 되지 않더라도 업로드 자체는 성공했던 케이스를 통해 업로드한 파일을 확인 할 수 있는 기능이 있음을 알게 되었다.
해당 /show_image 로직에서 LFI가 발생함을 알 수 있었다.
../ 등을 통해 디렉토리를 조회 시도 시 디렉토리인덱싱 처럼 파일이나 디렉토리 목록이 노출되는 것을 확인 할 수 있었다.
사실 이때는 파일 업로드 로직의 소스코드를 읽어서 우회 방법을 찾는 시나리오 일 것이라고 생각했는데 직접 확인해보니 파일 업로드 로직은 안전한 로직으로 보였다.
일일히 디렉토리와 파일을 확인하며 frank라는 계정의 home 디렉토리에서 phil이라는 계정정보 및 패스워드 정보를 획득 할 수 있었다.
DocPhillovestoInject123
22번 포트가 열려 있었기 때문에 바로 접근을 시도했지만 실패했다.
꽤 오랜 시간을 헤매다가 사용중인 컴포넌트의 버전에 따른 알려진 취약점을 활용하는 시나리오일까 싶어 pom.xml 파일을 조회해보았다.
spring framework 2.6.5 버전을 사용한다는 것을 확인했고, 관련해서 조사를 해보았다.
얼마전에 잠깐 log4shell 처럼 핫한 취약점이 될 뻔했던(?) spring4shell 취약점 관련 내용이 많이 나왔다.
여러 POC들이 있긴 했지만 그것들을 활용해서 테스트해봤을때는 잘 되지 않았다. 해당 취약점이 log4shell에 비해 파급력이 적었던 이유가 트리거하는 조건이 까다로워서라는 말이 있었는데, 그래서인지.. 혹은 비교적 알려진지 얼마 안된 취약점이라서 자료가 부실했는지.. 혹은 내가 테스트를 잘못했을수도 있다.
무튼, 오랜만에 metasploit의 도움을 받아보기로 했다.(search spring -> use 3)
https://www.akamai.com/blog/security/spring-cloud-function
Akamai Blog | Spring Cloud Function SpEL Injection (CVE-2022-22963) Exploited in the Wild
Although Spring Cloud Functions are not as widespread as the Log4j library, and should provide a good separation from the hosting server, some draw the line between the two, due to the ease of exploitation over HTTP/s. This new vulnerability will definitel
www.akamai.com
옵션들을 지정해주고 run을 해보니 유효함을 확인 할 수 있었다.
phil 계정 홈 디렉토리에 user.txt 파일이 있음을 확인 했지만 권한이 없었다.
확인을 해보니 현재 frank 사용자 권한의 shell 이었다.
아까 찾아놓은 패스워드를 활용해서 phil 사용자로 접속하는데 성공했다.
이후 권한 상승을 통해 여러 시도를 해봤지만 잘 되지 않았다.
...
...
...
그러다가 /opt 디렉토리에 아래와 같은 내용의 파일을 확인 했다. (playbook_1.yml)
파일을 읽어보니 ansible 관련 내용인것 같았다.
Ansible이 뭔지 확인해보니 Chat gpt가 친절히 알려줬다.
디렉토리 이름이 automation인 것과, Ansible이 자동 처리 관련 오픈소스라는 점을 참고하여,
root권한으로 .yml파일의 내용이 자동으로 처리되지 않을까 라는 시나리오를 구상해보았다.
관련 취약점을 조사해보니 응용할만한 내용이 있어서 시도해보았다.
Ansible Playbook Privilege Escalation | Exploit Notes
Ansible Playbooks are lists of tasks that automatically execute against hosts.
exploit-notes.hdks.org
우선 리버스 쉘을 공격자 서버로 보내는 .sh파일을 생성 후
추가 yml 파일을 작성하여 해당 파일이 실행되도록 유도하였다.
nc를 열어놓고 조금 기다리니 위 시나리오가 유효하여 루트 권한의 리버스 쉘을 얻으며 문제를 해결 할 수 있었다.
[user] e4babeb99e93fa909489306c942635e8
[root] 5dd4954587a706b2ba757c925136ef07
