11 April 2021

Pentesting Fun Stuff

following the cyber security path…


Starting with a port scan to see the open ports and running services + version.

There is a FTP server running with anon login allowed, a SSH server, a webserver and a proxy-server.
Let’s start with the FTP server.

The picture is showing a network character doing the dab……how appropriate.
At the moment I can’t find anything off with this jpg. Nothing with strings, hexdump, exiftool, etc.
So on the the next service……the webserver on port 80.
The main page is nothing more then a login screen. Maybe I can find something with dirSearch.
Let’s take a look at the proxy-server.
At start I get the following notice: Access denied: password authentication cookie not set
After a while it dawned on my that I didn’t got any further. There is only the login page and as much as I despise trying to brute-force my way in, I don’t think there is any other option.
So I fire up hydra and let the good old rockyou list rip.

Wow…..I should have found that manually 🙁
When accessing the site I get a stock list from some database….nothing further……..but………there is something I got.
A cookie is set:  session:eyJ1c2VybmFtZSI6ImFkbWluIn0.DuHtNw.jhKPXFZyWjVirongDGpCGL639oc
Back to the webserver running on port 8080.
When I capture the HTTP header with burp I get this result.

Is it asking for an authentication cookie with the name password?

Ok…..so my hunch is correct……the value is just not right. What did I  miss?
When I look at the HTTP responses I have from both tries I see a difference which I can use
First try:

Second try:

The content-length is different because of the cookie check. I can use this to guess the correct cookie value.

Let’s try that cookie value.

As a result I get a page with some input fields and a titel with something about a cache engine.
After reading some pages (page1 & page2), it looks like a “memcached system/cache engine” which is a general-purpose distributed memory caching system.
It is often used to speed up dynamic database-driven websites by caching data and objects in RAM to reduce the number of times an external data source (such as a database or API) must be read.
By default memcached listens on TCP and UDP ports, both 11211.
In the github wiki there is a page about commands. Here I found the commands to get more information about the system.
One of the commands I thought would be useful was a retrieval command get. But with this command I need a value. So I used * as wildcard and got:

Hmmm. When looking for some more useful commands I found the stats slabs command which gave out some good output:

It looks like there are 2 slabs that are active slab 16 and slab 26 of which slab 26 is the biggest.
Another page had some useful information about key retrieval.

The first slab gave the key stock and the second slab gave the key users.
When using the get users I would assume I get a better response, but the only output is empty. I tried different commands and read a lot of useless stuff.
Even after a reset of the machine there was nothing. The solution came by just do a logout from the webserver on port 80 and login again.
Then try the get users command again and the result you get is:

A nice JSON file which is bad to read this way….so let’s clean it up a bit with cyberchef.

This is a very long list with usernames and md5 hashes. Next step would be wise to separate the usernames from the hashes so I can feed them in a brute-force attempt.

Next I need to find the plain text value of the hashes……especially the one I need to SSH into the box.
Assuming this is the correct line of thought.
For this you can use hashcat and john the ripper, but hashcat is no good when working inside a vm and john can be somewhat slow when dealing with a large list of hashes. Also its output is not desireable. Instead I use a great tool: hash-buster.

This one does the job in a few seconds.
Because I have a short list of cracked passwords, I want to know which user belongs to a hash.
To do this, I write a simple for loop to verify the data and give a list to use with hydra.

To remove the useless chars and split the creds again:

And run hydra.

I could have run hydra without the hassle of filtering the found creds, but that only took a few minutes while hydra would have run a very long time to try all usernames and all passwords.

And here is the first hash.
Now for root.
I can enumerate by hand, but there is a script that can take the load out of my hands. The only catch is that it gives a lot of output. So don’t get overwhelmed.

There I ran the script and pushed the report back to my machine for save keepings.

A legit clue or a way down the rabbit whole?

Hahahahahahaha………yeah, that would be too easy.
After some searching through the report there were 3 files that caught my eye.

These files have the SUID bit set. /usr/bin/myexec I didn’t know and came up zero with google.
And the other one normally doesn’t have the SUID bit set: -rwxr-xr-x 1 root root 884K Oct 29 21:36 /sbin/ldconfig
When running msexec I need to feed it a password, but my current one doesn’t suffice.

First I try ltrace to see if the hardcoded password will apear.
Ltrace is a debugging utility in Linux, used to display the calls a userspace application makes to shared libraries.

There it is. Now to run the binary again.

It stops at this point and I need to check the binary more to see if there is more to gain.
With objdump -x myexec I can get information from object files.

This is a part of the output which shows its dependencies. libc is standard c library. libseclogin.so is the one I focus on.

Because the SUID bit is set on /usr/sbin/ldconfig I can run ldconfig as root and link libraries local.
In this case I want to create my own version of libseclogin.so and get a root shell.
So I create a libseclogin.c with the following code:

And compile it as libseclogin.so and make it executable.

I use ldconfig to link the folder where my newfound libseclogin.so library is waiting

Next I set the variable LD_LIBRARY_PATH

And finally I run myexec again………..and nothing…..no shell…nada.
What went wrong?
After some more reading I found a page which gave som good pointers about changing the location off libraries.

When checking the dependecies of myexec again I see that this time it has changed.

And finally when running myexec again……it works.

There is the final hash.
Man…..this was a good challenge. I definitely needed to read a lot for this one.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.