Spider

This is a hard difficulty Linux machine from HackTheBox created by infoSecjack and chivato. This machine is really complex with a lot of topic, it's excelent to refine your concept and scripting skills. In this scenario, my IP is 10.10.14.83 and the target’s IP is 10.129.193.169

Gathering Information

The first steps are about getting basic information about the target, by using nmap and searching information from the website.

Local Terminal
ping -c 1 10.129.193.169

Pinging 10.129.193.169 with 32 bytes of data:
Reply from 10.129.193.169: bytes=32 time=181ms TTL=63
Reply from 10.129.193.169: bytes=32 time=174ms TTL=63
Reply from 10.129.193.169: bytes=32 time=184ms TTL=63
Reply from 10.129.193.169: bytes=32 time=199ms TTL=63

Ping statistics for 10.129.193.169:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 174ms, Maximum = 199ms, Average = 184ms

The machine is alive, and by the TTL (close to 64) we can assume and confirm that is definitely a Linux Machine

Local Terminal
nmap -p- --open -T5 -v -n 10.129.193.169 -oN Ports

Completed SYN Stealth Scan at 17:30, 57.82s elapsed (65535 total ports)
Nmap scan report for 10.129.193.169
Host is up (0.17s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

By searching "OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 launchpad" in google, we find that our target is a Linux-Bionic machine, is good to know every detail about the target... and the other information to the pocket, is that the port 80 use nginx/1.14.0.

We received an http error, let's add the IP to our /etc/host.

All right, there is a lot of basic information over the table, now we need to explore the website http://spider.htb/.

After exploring a little bit, is just a simple shop without weird directories, let's intercept the current session anywhere.

Looks like a simple base64 hash.

It looks like something to store our cart data, this means that there is a possible escenario where the cookie is connected to some sort of database. Create an account, login, add items to your cart and Intercept your Home-session.

After registration page

Interesting, after registration, the login process is by using some sort of UUID code... for now it is irrelevant, let's "buy" and then intercept.

Our cookie is now laaargeeeeeer

Ok, it works, from the cookie we can retrieve information...

and after a long search, because we can see the username after login, the best option now is to apply a Server Side Template Injection, to see how this happen, we are going to register as {{config}}, if it works, it's because is vulnerable.

From this point, my IP is 10.10.14.103 and the target IP is 10.129.194.26...

Output at "User Information" when you register as {{config}}

It's a lot of information, save the output in a file, in this page that file will be called "Config"

Config content with the replacement ":%s/,\r/g" (Transform every "," to "\r")

We found some configuration stuff like a new key to use, 'SECRET_KEY': 'Sup3rUnpredictableK3yPleas3Leav3mdanfe12332942', and by the structure of the configuration, maybe this project is using Flask.

Exploit

Well, we receive a positive response by using the flask-unsign command, now we can use that command to create custom sessions by using the secret key.

With the previous command, the output is equal to the cookie when we login as {{config}}, this means that we successfully execute the reverse process.

What if this JSON data lecture is vulnerable to SQL Injection? Just by adding { \' and sleep(10)-- - } at the end before the '}

After 10 seconds, this was the response... it works!

For agility reasons, I will follow this process using Burpsuite, and spoiler, it works if you the following query: " order by 1 -- -"

There is no new message por "Test" at the webpage, so we are working with a Blind SQL Injection, so the best method here is to create a python script to get character by character the information that you need.

Output

And the command works, remember that we could use as payload a list with the most common database names, if you don't want to make a whole brute force script.

Now that we know the name of the database, the only thing that is necessary to change at the script is the payload.

To know about other tables, we have two options, the first one is to change the "limit 0,1" to "limit 1,1" and so on, the other one is to add another for loop [for j in range(1,10)] to make a list with table names.

Table user found! Now we have to do the same thing but with columns, it's the same login:

Now we know the column name from the table "users". Still, is almost the same logic, first just add some characters to the poll.

From here, is a cycle between changes at the payload, only to select another column and get more information.

Login to the web page with the new credentials.

I tried some stuff but nothing happens, but there is an URL there.

  • browser: spider.htb/a1836bb97e5f4ce6b3e8f25693c1a16c.unfinished.supportportal

Has a block too.

We don't know which characters are banned, our best option now is to get a payload and make change from every error, the payload will be:

Payload result after many many many changes:

The command "sleep 5" works so we have a new potential way to execute commands...

And finally, we are at the machine!

Follow the steps from TTY treatment to upgrade your bash

Look at this, free credentials!

But didn't work... let's get the flag then.

Privileges Escalation

To make thing easier, go to /home/chiv/.ssh and copy the public id_rsa at your local machine, then connect to the target.

Now we proceed with the scouting.

There is something at the port 8080, usually used to host other website.

It exist, but isn't redirecting us, so an alternative here is to use a local portforwarding to connect from our machine to that website.

  • Browser: localhost

We can login with any... username...
Login interception.

If you intercept the moment when you login, you send the username, here was "hola", and you send a "version", then receive a new cookie. We know the process to decrypt that cookie.

We receive the following output:

{'lxml': b'PCEtLSBBUEkgVmVyc2lvbiAxLjAuMCAtLT4KPHJvb3Q+CiAgICA8ZGF0YT4KICAgICAgICA8dXNlcm5hbWU+aG9sYTwvdXNlcm5hbWU+CiAgICAgICAgPGlzX2FkbWluPjA8L2lzX2FkbWluPgogICAgPC9kYXRhPgo8L3Jvb3Q+', 'points': 0}

It's an XML, a nice clue for a XXE (XML Externar Entity) vulnerability, but first we have to decrypt that section.

The output return the API version, this in definitely a modifiable part from the request, so, let's create a payload and use Burpsuite to send it.

Interception with payload, login as test.

Then press forward and voila, you will see the whole /etc/passwd, for some reason, if you try to advance by only using Burpsuite, remember to change the current cookie to the new one.

Sucess

Now let's try with a new payload

Request with payload
Change the cookie and then "Follow Redirection"
Then send again

Copy the id_rsa and try to connect again to the target.

Last updated