HTB Dab (Hard) - Writeup
Difficulty: Hard
Initial foothold was gained by fuzzing cookie names and values, leading to the discovery of a hidden authentication mechanism and access to restricted functionality. An exposed Memcached instance was exploited to extract sensitive data, including valid credentials. Privilege escalation was achieved via shared library hijacking in a misconfigured SUID binary, allowing execution of arbitrary code with root privileges.
Nmap
The nmap scan revealed four open ports:
Port 21 - FTP
I’ll start with ftp as I often do when it’s open on CTF’s.
We can login with username “anonymous” and a blank password “”.
There is only one file and it is a .jpg photo.
I’ll transfer it with GET command.
First I will check metadata with exiftool.
Nothing intresting there.
Steganography is a way to hide secret information or even entire files inside normal files, like images or audio.
For example, a document can be hidden inside a photo without visibly altering the image.
We will now look for hidden files.
There is a hidden file but it’s just a rabbit hole.
Port 80 - Website
Website contains login page, default credentials didin’t work.
We can try a bruteforce attack, normally we would bruteforce usernames first but I’ll just guess that there is an admin account:
We got valid credentials.
Let’s use them to login to the website.
It doesn’t contain anything intresting, we will now move to port 8080 and maybe comeback to port 80 later.
Port 8080 - Second Website
It gives us “Access Denied” but also a hint that there is a cookie that could give us more access.
We will perform Fuzzing on the Cookie name:
After running it for the first time we noticed that everything returns 30 W, meaning we need to us –hw 30 to filter it out as shown above.
We’ve successfully found a cookie name, we can try bruteforcing it with the same tool.
We will use a list from seclists containing parameter names.
Now we have both cookie name and it’s value.
We will now open developer tools with F12 and add a cookie called “password” with a value “secret”.
Now when we refresh the page we get more access.
It’s a TCP socket test site.
We can specify a port and a line to send.
I’ll try some basic command injection.
Unfortunately it has a filter for that.
After looking at how this web app behaves we notice that it gives “500 internal server error” for non-listening ports.
I’ll use wfuzz again to check for other open ports that may be working locally that we weren’t able to talk to before.
First let’s create a list for all port numbers.
And now use it with wfuzz and filter out http code 500:
We have found port 11211.
it’s used for memcached - “a high-performance, distributed memory object caching system.”
It’s designed to speed up web apps by caching frequently accessed data.
Memcached - Port 11211
I had to google a cheatsheet with memcached commands to enumerate it.
This article contains everything we would need:
https://www.hackingarticles.in/penetration-testing-on-memcached-server/
We can start with enumerating version:
It worked, now we can look for info about items cached in memory.
Notice that we need to login as admin on port 80 to get this info because caching times out.
We have two active slabs as shown above, slab with ID 16 and slab with ID 26.
The first one is nothing important just the contents that are on the website on port 80.
Let’s check the second slab.
Using stats cachedump, 26 = ID, 0 = keys we want (zero means all keys).
We can see that there is ITEM called users, that seems intresting.
It dumped usernames with it’s hashes.
all we need to do is put them in a file and run hashcat with mode 0 for md5.
hashcat -m 0 hashes.txt /usr/share/wordlists/rockyou.txt
After it run we can use –show to see all hashes that successfully cracked.
We can take hashes, match them with usernames and put it in a file.
Now as we have this file we can try to login with ssh using hydra.
-C flag is for a file that has usernames and passwords combined.
Shell as genevieve
We can now login with ssh:
Priv esc to root
After running linpeas we have found two SUID binaries.
/sbin/ldconfig
and
/usr/bin/myexec
Let’s check myexec first.
It just asks for a password.
we can use ltrace to check interactions with shared libraries.
This is a line where this binary compare password specified to the real password:
strcmp("s3cur3l0g1n", "test")
Meaning we now have a correct password “s3cur3l0g1n”.
Now we can check what happens when we use correct password:
Exploiting SUID binary
We have SUID bit set in ldconfig also which is a tool used to link libraries.
Let’s trace system calls when we run this app by using strace command:
From the output we notice that it loads custom share library called /usr/lib/libseclogin.so
It could be done with ldd which will also be a more clear way.
ldd prints shared libraries use by a program.
We have ldconfig with SUID bit set, meaning we can try to hijack a shared library.
First we need to create a new shared library.
I’ll create a new directory first /tmp/hijack.
Now we can create libseclogin.c there. here is an exemplary code:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
__attribute__((constructor))
void pwn() {
setuid(0);
setgid(0);
system("/bin/bash");
}
Now we need to compile it:
We end up with /tmp/hijack/libseclogin.so
ldconfig uses files in /etc/ld.so.conf.d/ directory to determine which libraries it will load.
We can now just simply create new file with our /tmp/hijack path specified.
Now if we run ldconfig it will update a path, it can be verified simply by using ldd again.
Now when we run myexec binary it should load our malicious shared library instead and execute it with root privileges (since we have SUID bit set).
It worked, thank you for reading.