[tryhackme] Red

김기훈·2024년 9월 23일

tryhackme

목록 보기
9/12

아주 정신사나웠던 문제..이기도 했지만 타임어택하는 느낌이어서 나름 재미도 있었다.

Q1. What is the first flag?

머신 스타트하기 전에 흥미로운 배경설명이 있었다.
나는 블루이고 레드와 해킹 배틀(?)을 하는 중인 상황인 것 같다.
레드는 이미 머신을 장악하고 블루인 내가 머신을 장악하지 못하게 온갖 방해공작을 마련해두었다고 한다.

해킹 배틀이라는 신박한 상황이 흥미로웠다. 어떤 방해공작을 마련했는지 들어가보자.

웹 먼저 접속해봤다. 로그인 페이지나 업로드 기능도 안보이고 볼만한 건 없었다.
하지만, URL을 잘 보면 html 파일이 page 파라미터에 그대로 입력되고 있었다.

http://<MACHINE_IP>/index.php?page=home.html

LFI 취약점이 있을 것 같아서 파라미터에 ../../../etc/passwd를 넣어보았지만 계속 원래 페이지로 리다이렉트 된다.

HackTricks에 있는 Filter bypass tricks들을 시도해보던 중 아래 코드를 입력하니 ROT13 암호화된 /etc/passwd 파일을 얻을 수 있었다.

php://filter/read=string.toupper|string.rot13|string.tolower/resource=file:///etc/passwd

이래저래 시도해보니 php://filter를 사용하면 굳이 ROT13 암호화할 필요없이 파일명만 입력해도 passwd 파일을 얻을 수 있었다.

php://filter/resource=file:///etc/passwd

그리고 index.php에서 왜 계속 리다이렉트 됐던건지 소스코드를 불러봤다.

<?php 

function sanitize_input($param) {
    $param1 = str_replace("../","",$param);
    $param2 = str_replace("./","",$param1);
    return $param2;
}

$page = $_GET['page'];
if (isset($page) && preg_match("/^[a-z]/", $page)) {
    $page = sanitize_input($page);
    readfile($page);
} else {
    header('Location: /index.php?page=home.html');
}

?>

두 가지 필터링이 걸려있었다.

  • preg_match를 통해 입력값의 첫번째 문자가 알파벳 소문자가 아니면 home.html 페이지로 리다이렉트 된다.
  • 입력값의 첫번째 문자가 알파벳 소문자이면 sanitize_input 함수로 ../, ./ 문자를 공백으로 치환한 뒤 페이지를 읽어들인다.

두 가지 필터링을 모두 php://filter로 우회할 수 있었다.

다시 돌아가서 passwd 파일을 보면 사용자 blue와 red를 확인할 수 있고

php://filter/resource=file:///home/blue/.bash_history

위 입력값을 통해 blue의 bash history를 확인할 수 있었다.

hashcat으로 .reminder 파일을 가지고 best64.rule을 적용하여 passlist 파일을 생성한 흔적이 남아있다.

.reminder 파일이 존재하고 있었고 패스워드로 보이는 문자열 하나가 들어있었다.
이걸 가지고 명령어를 똑같이 실행해서 지워진 passlist.txt 파일을 복구시켜야겠다.

총 77개의 패스워드가 생성됐다.

nmap 스캔을 해보니 ssh 포트가 열려있었다.
blue 계정으로 ssh 브루트포스 공격을 시도해보자.

blue 계정으로 접속 성공했고 첫번째 플래그를 얻었다.

Q2. What is the second flag?

엥.. 접속한지 얼마안돼서 연결이 끊겨버렸다.
똑같이 패스워드를 입력하고 접속시도했는데 이제는 접속조차 안된다..?

문제 설명란에 Red가 비밀번호를 변경하는 것을 좋아한다는게 이런거였구나ㅎㅎ
hydra로 다시 패스워드를 확인했고 역시나 패스워드가 달라져 있었다.

블루를 떠나지 않으면 너의 쉘을 부숴버린다는 협박 문구도 나오고 생각보다 친절한지 힌트도 넌지시 흘려준다ㅎㅎ

힌트를 줬으니 linpeas와 pspy를 가져와서 돌려봤다.

pspy로 프로세스 모니터링을 해보니 red가 백도어를 심어둬서 주기적으로 리버스쉘이 실행되고 있었다.
/etc/hosts 파일에서 redrules.thm을 내 IP로 바꾸고 리스닝하고 있으면 red 계정은 내꺼~

echo "10.8.51.29 redrules.thm" >> /etc/hosts

나는 위 명령어로 호스트 파일을 변경해서 난관에 부딪치지 않았지만 vim 이나 nano 편집기를 통해 수정은 안되게 막아놨었나보다.

ls 명령어로 권한상태를 보면 others에게도 write 권한이 부여돼 있어서 당연히 수정이 될 것 같다.
하지만 파일의 속성을 확인하는 lsattr 명령어로 보면 append-only 속성이 설정되어 기존 파일의 내용을 수정하거나 삭제하지는 못하고 오직 새로운 내용 추가만 가능하다고 한다.

그래서 echo 명령을 통해 내 IP를 밀어넣는건 가능했나보다.

어쨋든 red 계정을 얻었고 두번째 플래그도 얻었다.

Q3. What is the third flag?

이제 최종목표는 역시나 root 계정이다.

red 홈디렉토리에는 .git 폴더가 있고 안에는 setuid가 설정된 pkexec 바이너리가 있다.
구글링해보니 CVE-2021-4034(PwnKit) 취약점을 통해 pkexec으로 권한상승이 가능하다고 한다.

정말 놀라웠던게 이 취약점이 2009년 5월 pkexec 의 첫 번째 버전부터 취약점이 발견되기까지 무려 12년간 드러나지 않았고 모든 리눅스 배포판에 존재하는 기본파일이라고 한다. 😱

github에 있는 c코드를 가져와 컴파일하고 해봤지만 알 수 없는 이유로 동작하지 않았다.

그러다 python으로 작성된 exploit을 발견했고 exploit에 성공했다.
https://github.com/Almorabea/pkexec-exploit/blob/main/CVE-2021-4034.py

마지막부분에 pkexec 경로를 /usr/bin/pkexec이 아닌 /home/red/.git/pkexec로 변경해주어야 한다.

마지막 플래그는 root 폴더에 있다.

0개의 댓글