시작

일단 첫 THM 문제여서 어떤식으로 진행되는지 1도 몰랐다.

무작정 들어가서 시작한거라 아무것도 몰랐다.

THM VPN에 접속한 뒤 해당 문제서버의 nmap을 날렸다.

포트 스캐닝

처음 nmap을 진행했을 때는 옵션을 -p0- 으로 진행했는데, 너무 느려서 그냥 타 writeup에서 찾은 포트를 스캐닝 했다.

처음에 -A 옵션을 줬을 때는 ssh, http, mysql 그리고 Asterisk라는 서비스의 포트가 열려있었다.

해당 포트의 서비스들을 알게 되었고 한개씩 접근해보았다.

포트별 정보수집

해당 포트들을 보면 ssh, http, mysql, Asterisk가 있었다.

나머지는 다 한번씩 본 포트, 서비스들인데 Asterisk만 본적이 없다.

그래서 Asterisk가 무엇인지 알아보았다.

Asterisk은 VoIP에서 전화 교환을 맡는 PBX 서비스였다.

해당 5038 포트를 포함해서 모두 접근해보았다.

http

해당 페이지를 브라우저로 접근하니까 이런 페이지가 떴다.

근데 로그인 화면만으로는 모르겠어서 이 페이지가 지나가기 전에 뭐가 지나갔었는데

바로 이 이미지었다.

찾아보니까 MagnusBilling 이라고 하는 VoIP 요금 계산기였다.

그래서 기본 패스워드를 입력했는데 당연하게도 막혀있었다.

하지만 찾아보니까 RCE가 터졌던 CVE가 있었는데 해당 부분을 먼저 보면 될 것 같다.

ssh

일단 사용자 정보가 필요한 ssh 특정상 특이점을 찾진 못했다.

그래서 그냥 다른 서비스들을 더 뒤져보기로 했다.

mysql

mysql이 있었는데 이렇게 SQL 서버가 노출 되어 있을때는 그냥 인증없이 접근이 가능한 경우가 있는데 그래서 해봤다.

하지만 실패하고 기본중에 기본인 root/admin 을 시도했지만 실패했다.

Asterisk

보니까 http도 아니고, ssh도 아니고 해서 마지막으로 시도한게 telnet인데 해당 프로토콜에선 접속이 가능했다.

하지만 입력이 가능하지도 않고 asterisk Asterisk Call Manager/2.10.6 이라는 글자만 보여주며 해당 세션은 한 2~30초 내로 닫혔다.

http 웹서버 분석

관련 CVE를 찾았는데, 바로 CVE-2023-30258 이었다.

어떤 취약점이냐면,

해당 웹페이지에는 인증없이 접근할 수 있는 곳이 있는데, 바로 http://10.10.13.178/mbilling/lib/icepay/icepay.php 였다.

일단 해당 icepay.php에는 Command Injection 취약점이 있었다.

이제 파라미터로 democ=;{악성 명렁어} 를 넣게 되면 악성 명령어가 실행되게 된다.

웹쉘을 넣으려고 이리저리 시도했는데 왜인지 실패를 했다.

그래서 좀 쌈@뽕한 웹쉘을 찾던 도중,

metasploit-framework에 해당 CVE의 리버스 쉘이 있었다.

그래서 바로 msfconsole 을 이용해서 공격을 진행했고, 성공적으로 리버스 쉘이 따졌다.

이렇게 리버스 쉘을 따고 msf의 meterpreter 콘솔에 명령어인 shell을 이용해서 bash를 실행하는데 성공했다.

첫번째 FLAG 찾기 - user.txt

이제 첫번째 문제인 user.txt를 찾아야한다.

find를 돌렸는데 결국에는 못찾았다.

그래서 일단 / 로 이동해서 home 내부를 들어갔다.

이중에 한군데에는 있겠지 라는 생각으로 일단 들어가보면서 찾았다.

행운이었을까, 찾았다. 아직도 이거 된게 신기합니다...

여튼 해당 FLAG를 제출하고 다음 문제인 root.txt로 넘어갔다.

두번째 FLAG 찾기 - root.txt

일단 앞서 user.txt는 찾기 수월했다.

하지만 이번 root.txt는 예상하기로는 /root 디렉터리에 있을것이기에 권한 상승을 해줘야한다.

일단 권한 상승에서 가장 먼저 떠오르는 명령어는 sudo 이기에 바로 sudo -l로 sudo를 사용할 수 있는지 확인했다.

보다시피 딱 한개의 프로그램에 모든 유저가 패스워드 없이 root로 sudo 사용이 가능하도록 해두었다.

fail2ban인데, 난 이게 뭔지 몰랐고 찾아보니까 외부로부터 이상 행위, 공격 등이 감지되면 해당 IP를 차단하는 프로그램이라고 한다.

근데 이 fail2ban이 iptables같은 root권한이 필요한 작업을 더러 해서 그런지 root 권한으로만 사용이 가능하다.

그래서 위 사진처럼 sudo가 저 프로그램에만 열려 있던 것 같다. sudo가 왜 가능하게 해놨는지는 아직도 이해할 수 없다.

이 fail2ban은 iptable이나 관련 매니저 명령어 등을 통해서 IP 밴 조치를 진행한다.

그러면 IP 밴 명령 대신 권한 상승을 위한 명령어를 넣게 된다면 어떻게 될까?

bash를 $가 아닌 #으로 쓸 수 있다는 말이다.

그렇게 권한 상승 공격을 진행했다.

1차 시도 - 실패

음... 실패했다. 이건 Gemini가 추천 해줬던건데 안된다 역시.

import pty; pty.spawn("/bin/bash")

2차 시도 - 성공

일단 이번에 쓸 명령어가 좀 길다.

sudo /usr/bin/fail2ban-client set asterisk-iptables action iptables-allports-ASTERISK actionban 'chmod +s /bin/bash'

이거다. 하나하나 설명해보자면,

• sudo -> root로 권한 상승 (관리자 권한으로 실행)
• /usr/bin/fail2ban-client -> fail2ban 클라이언트
• set -> fail2ban의 설정/재설정을 진행할 때 쓰는 하위 명령어
• asterisk-iptables -> 특정 규칙(jail)의 이름
• action -> jail 내의 여러 설정 정보 중 action 항목을 의미하는 하위 명령어
• iptables-allports-ASTERISK -> action의 이름
• actionban -> IP 차단할 때 실행되는 명령어를 의미하는 하위 명령어
• 'chmod +s /bin/bash' -> bash에 SUID 비트를 설정하여 켜질때마다 root 권한으로 실행하도록 하는 명령어

이런식으로 풀어서 설명 할 수 있다.

한마디로 IP 밴 할때 쓰는 명령어를 '항상 bash를 root 권한으로 실행' 명령어로 바꾼 셈이다.

해당 명령어를 사용하면 즉시 SUID 비트가 활성화 된것을 볼 수 있다.

이렇게 rwS 권한이 들어간 것을 볼 수 있다. 그룹 권한에 들어간건 내가 명령어를 잘못 사용해서 생긴 일이다.

이 뒤에 새롭게 /bin/bash를 실행시키면?

될리가 없다.

이유를 찾아보니까 최신 bash 에서는 보안상의 이유로 SUID가 설정되면 실제 사용자와 유효 사용자가 다를 경우 권한을 강제적으로 권한을 낮춘다고 한다.

이를 해결하기 위해서는 -p 옵션을 넣게 되면 비활성화 되어서 유효 사용자의 ID로 유지한 상태로 실행하도록 설정할 수 있다.

추가적으로 리버스 쉘 환경이라 그런지 인터렉티브한 작업이 안되서 -i 옵션까지 추가해서 풀이를 진행했다.

보면 SUID 사용으로 id 명령어를 실행하면 uid와 euid가 나눠져서 나오게 된다. 신기하다

마무리

이렇게 Flag 2개를 잘 찾으면서 첫 THM 문제 풀이는 끝이 났다.

일반적인 워게임하고는 다르게 1-day를 사용해서 Exploit 하는 풀이방식이 좀 신기했고 재미있었다.