Gofer

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 4000 10.129.53.84
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-30 20:51 +08
Nmap scan report for 10.129.53.84
Host is up (0.17s latency).
Not shown: 65530 closed tcp ports (conn-refused)
PORT    STATE    SERVICE
22/tcp  open     ssh
25/tcp  filtered smtp
80/tcp  open     http
139/tcp open     netbios-ssn
445/tcp open     microsoft-ds

Did a detailed scan as well:

$ nmap -p 80,139,445 -sC -sV --min-rate 3000 10.129.53.84             
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-30 20:52 +08
Nmap scan report for 10.129.53.84
Host is up (0.17s latency).

PORT    STATE SERVICE     VERSION
80/tcp  open  http        Apache httpd 2.4.56
|_http-server-header: Apache/2.4.56 (Debian)
|_http-title: Did not follow redirect to http://gofer.htb/
139/tcp open  netbios-ssn Samba smbd 4.6.2
445/tcp open  netbios-ssn Samba smbd 4.6.2
Service Info: Host: gofer.htb

We can add this domain to our /etc/hosts file.

Web Enumeration -> LFI

Port 80 hosted a typical corporate site:

Within the site, there wasn't much apart from a few names like Jocelyn Hudson and stuff.

gobuster scans reveal nothing much, but a wfuzz scan shows one subdomain has been returned.

Visiting this subdomain requires credentials:

Weak credentials don't work at all. I tested a few common directories with different requests, and found that index.php accepted POST requests without credentials:

Testing it a bit more reveals where the URL parameter can be specified:

So we have SSRF on this machine with this url parameter. I attempted some LFI using the file:// protocol, but there's a WAF in the way:

A bit more testing by removing / characters eventually works! This tells me that the WAF is rather weak.

SMB -> Phishing Download

Port 445 is open on this Linux host, and it shows us one share.

We can access this share via smbclient.

There was one file present, and when read it points us towards using phishing as the initial access.

We need to use an .odt format to exploit this, and it appears that this is from the user Jeff Davis from the company site (with a username of jdavis, so we know the username naming convention).

Since we have some kind of SSRF on the proxy service, we might be able to force a user to download and execute a malicious .odt file via macros to get the first shell. However, we first need to find out how to send an email through the proxy to the user since SMTP is not publicly facing.

Based on the box name alone, I sort of figured out that we need to use the gopher:// protocol, which is used to send files to other users.

LogoServer-Side Request Forgery to Internal SMTP AccessMedium

This repository can generate the payloads required:

LogoGitHub - tarunkant/Gopherus: This tool generates gopher link for exploiting SSRF and gaining RCE in various serversGitHub

This payload almost works, except for the fact that the IP address is flagged:

We can specify the IP address in decimal mode in order to bypass this.

However, even after bypassing the WAF, it doesn't work and I get no hits on my HTTP server. I URL decoded it and found that there was some syntax errors with the commands send to SMTP and also some control character errors, since we needed to send \r to register as an 'Enter' key.

I edited the payload a bit and URL encoded it to send the

Here's the final payload that I used:

Since there were some quotes I was lazy to deal with, I sent it in Burp and got a reponse saying it worked:

We would also get hits on our HTTP server.

Document Creation -> RCE

I followed this to create my own malicious .odt file:

LogoUsing Malicious LibreOffice Calc Macros to Target Linuxjamesonhacking.blogspot.com

Here's the macro I used:

We can then assign this to the Open Document event:

Then we can host this file on a HTTP server and send our Gopher payload. This would give us a reverse shell as the user!

This image became corrupted when uploading...oops.

Privilege Escalation

Tbuckley Creds

I ran pspy64 and found some user credentials:

We can then su to tbuckley, who is part of the dev group:

Notes SUID -> Reverse Engineering

I ran a linpeas.sh it picked up on this weird SUID binary:

When we run this thing, it appears that we can do quite a few things:

I transferred the binary back to my machine via base64 and used ghidra to analyse it. Within it, I found some interesting parts. Option 1 is the user creation part:

  • It allocates 40 bytes for the username in the Heap via malloc(0x28), and afterwards checks whether the malloc worked.

  • There seems to be 2 parts for this memory, of which it uses the first 24 (0x18) bytes for the username since the username part is set to the first block of memory.

  • The next 16 bytes appears to be something else. _Var1 is the UID of the current user, and if we are root, it sets the 25th to 29th byte to 0x6e696d6461. If we are not an admin, it just sets the next part to 0x72657375.

  • When decoded, the non-root user is called user and the root user is assigned as admin:

  • So basically, the first 24 bytes is the username, and the next 16 bytes is the privilege level of the user, which is set to user by default.

Option 3 is the delete user option, and it is vulnerable due to dangling pointers:

  • This is a classic case of a Use After Free vulnerability. The local_10 variable is free here, but the pointer still remains and is not set to NULL.

  • This indicates that the pointer is a 'dangling', meaning that any future accesses to it will still point to the allocated memory even if it does not belong to us.

  • The bytes of memory for a previous user creation remains.

Option 4 is the write note option, which allows us to overwrite the memory due to the dangling pointer:

  • One thing to note about malloc is that dangling pointers are 'used again', meaning we can reaccess the memory allocated from the user creation.

LogoDangling pointers in CStack Overflow

Option 8 is the main vulnerability:

This part of the code checks whether the role of the user has been set to admin, and then grants us access to the tar command, which does not have its full PATH specified and is thus vulnerable to PATH Hijacking.

To exploit this, we need to:

  • Create a user -> Creates the allocated block of 40 bytes.

  • Delete the user -> Creates a dangling pointer to our first user created.

  • Write a note -> Using the notes function, we can write 24 characters for the username, and the have admin after the 24th byte to escalate privileges, which looks something like this: 111111111111111111111111admin.

  • Use option 8 to execute our malicious tar binary.

Exploit -> Root

First, let's create our tar binary:

Then, follow the exploit path I laid above.

Then, we can easily escalate privileges:

Rooted!

PreviousDownloadNextIntentions

Last updated