Unattended

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 3000 10.129.56.92            
Starting Nmap 7.93 ( https://nmap.org ) at 2024-01-30 06:27 EST
Nmap scan report for 10.129.56.92
Host is up (0.0098s latency).
Not shown: 65533 filtered tcp ports (no-response)
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Did a detailed scan:

$ nmap -p 80,443 -sC -sV --min-rate 3000 10.129.56.92
Starting Nmap 7.93 ( https://nmap.org ) at 2024-01-30 06:29 EST
Nmap scan report for 10.129.56.92
Host is up (0.014s latency).

PORT    STATE SERVICE  VERSION
80/tcp  open  http     nginx 1.10.3
|_http-server-header: nginx/1.10.3
|_http-title: Site doesn't have a title (text/html).
443/tcp open  ssl/http nginx 1.10.3
|_http-server-header: nginx/1.10.3
| ssl-cert: Subject: commonName=www.nestedflanders.htb/organizationName=Unattended ltd/stateOrProvinceName=IT/countryName=IT
| Not valid before: 2018-12-19T09:43:58
|_Not valid after:  2021-09-13T09:43:58
|_http-title: Site doesn't have a title (text/html)

There's a custom domain to be added to /etc/hosts.

Web Enum -> Blind SQLI

Visiting www.nestedflanders.htb returns the default Debian page:

I ran a gobuster directory scan with a few wordlists like common.txt. The machine is rather slow, so this took a while. Eventually, it will find some interesting stuff:

/dev returned nothing of interest. Visiting index.php returns this:

Reading the page source was rather unique, since it seems to index pages based on an id parameter.

The id for the About page was 465, and submitting 465' results in a return to the main page. Interesting, as this could signify SQL Injection. I tested it with 465' AND 1=1-- - and it returned me to the About page. Testing it with AND 1=2 results in being redirected to the main page. This confirms there is an SQL injection vulnerability.

First, I had to test which SQL database this was running, and this could be done by testing either version() or @@version.

This confirms it is MySQL, and usage of substr instead of substring works. Next, find the current database:

Next, find the table names within this thing via group_concat.

The above took forever to generate, and there were way too many tables for me to enumerate via blind injection.

Nginx LFI -> Source Code Access

Apart from the SQL database, there was only the /dev endpoint. I looked to Hacktricks for nginx exploits, since the detailed nmap scan told me this server was running on nginx.

Doing the Accutenix tests returns positive results:

This means that I could potentially read some files here. This is probably hosted in /var/www/html, and I wanted to read more about index.php, the page with the Blind SQLI.

I added my comments on the vuln:

There was a dependency on some PHP file named with a hash, but it was useless.

Anyways, the code asked for a $inc parameter, which is taken from the getPathFromTpl($conn,$tpl) function, which is taken from the initial getTplFromID function.

Source Code Analysis

Analysing this code was rather interesting, since I had to find a way to control the value of $tpl from $conn, and there were a few checks on the input passed in:

Checks these conditions:

  1. id needs to be present.

  2. intval of id == id

  3. intval(id) equates to 25, 465 and 587.

I read the documentation for intval, and found that it was a terrible method of verifying whether an input was an integer:

I ran a test on my own device, and found that intval was easily bypassed, which allowed for the initial Blins SQL Injection exploit:

Next, let's look at the query used:

So id=465 means that the name paramter is about. I used the earlier blind SQLI to enumerate idname:

Interesting. So about and main are possible names to be returned as $tpl. Let's take a look at the second function that uses this:

I enumerated filepath too, since I could control $tpl in theory. I enumerated this filepath table. Interestingly, it just contained <HASH>.php file names:

This make sense, and the filename is then returned as $inc to be used in include. This opens a path for PHP file execution via include, and this is probably the way I have to get a shell.

To control this, I want the query to be something like:

To bypass the first query and make it process only the query after UNION, can include an error like 1=2.

Exploitation

Here's the attack path:

  1. Bypass id checks (easy)

  2. Control $tpl somehow

  3. Somehow write a webshell or code into the machine

  4. Access the webshell via SQL Injection to trigger LFI by controlling $inc.

Since we are injecting into 2 queries, need to have 2 sets of comments, as well as 2 sets of error queries via UNION:

This works in getting me an LFI:

Now, I need to somehow use this LFI for RCE. There were a few methods on Hacktricks, all of which involved reading the logs in the machine.

LogoPage not found - HackTricksbook.hacktricks.xyz

I scripted a quick LFI script:

From here, I could read /var/log/nginx/access.log, and technically RCE is possible using this method but I struggled. I read the other methods from Hacktricks, and found that using PHP sessions worked.

I tried writing some extra cookies by adding Cookie: PHPSESSID=n2jb3u50gv104k78v768i9h3h0; test=test as a header, then reading /var/lib/php/sessions/sess_<COOKIE>, and it worked:

Now I can set one of the cookies to be a urlencoded PHP command shell:

This worked!

Now, time to chain the exploit together.

Output:

Privilege Escalation

There's a user guly on the machine, but I cannot access the flag there yet.

MySQL Enum -> Overwrite Script Values

I found some MySQL creds earlier, may as well use them:

There was a config table that I wanted to see more of:

Quite a few things, but most importantly, the ftp_pass could not be cracked, and there was a script present in the checkrelease variable:

I didn't know what this was doing, but it appeared to be running somewhat consistently. I updated the value with Perl reverse shell script:

After a while, I got a reverse shell:

Grub Group -> Root

This user was part of the grub group, something that I had not seen before. I searched for all files users of this group had permissions over:

Interesting... I made a copy and analysed these folders in /tmp.

This was a CPIO file, and using cpio to extract it works:

So there are a lot of file directories here. I checked for all files that contained guly and root.

There was one interesting part here:

I wasn't entirely sure what unitrd was, but the second parameter looked like a kind of password. I just ran it with the parameter:

This hash allowed me to su to root:

Rooted? I don't know why that worked. I read the writeup from 0xdf to find out why, and it was way more complex than I thought. This machine was for more OSWE prep, so I don't really want to dive into the specifics here.

PreviousTimeNextUndetected

Last updated