Spaghetti

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 3000 -Pn 192.168.208.160
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-21 11:31 +08
Nmap scan report for 192.168.208.160
Host is up (0.18s latency).
Not shown: 65530 closed tcp ports (conn-refused)
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
80/tcp   open  http
6667/tcp open  irc
8080/tcp open  http-proxy

IRC is open on this device, which is rather unusual. I did a detailed scan too:

$ nmap -p 25,80,6667,8080 -sC -sV --min-rate 3000 192.168.208.160 
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-21 11:33 +08
Nmap scan report for 192.168.208.160
Host is up (0.18s latency).

PORT     STATE SERVICE VERSION
25/tcp   open  smtp    Postfix smtpd
|_smtp-commands: spaghetti.lan, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, SMTPUTF8, CHUNKING
| ssl-cert: Subject: commonName=spaghetti.lan
| Subject Alternative Name: DNS:spaghetti.lan
| Not valid before: 2021-03-09T11:39:07
|_Not valid after:  2031-03-07T11:39:07
|_ssl-date: TLS randomness does not represent time
80/tcp   open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Spaghetti Mail
6667/tcp open  irc
| irc-info: 
|   users: 2
|   servers: 1
|   chans: 1
|   lusers: 2
|   lservers: 0
|   server: irc.spaghetti.lan
|   version: InspIRCd-3. irc.spaghetti.lan 
|   source ident: nmap
|   source host: 192.168.45.153
|_  error: Closing link: (nmap@192.168.45.153) [Client exited]
8080/tcp open  http    nginx 1.18.0 (Ubuntu)
| http-title: Postfix Admin - 192.168.208.160:8080
|_Requested resource was login.php
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-open-proxy: Proxy might be redirecting requests

Port 6667 is indeed running IRC, and it has some functionality.

Web Enum

Port 80 was entirely static.

Port 8080 was running a non-vulnerable version of Postfix, with a login page:

I had no credentials, so let's move on first.

IRC -> Source Code -> RCE

I used nc to first enumerate the IRC server. Initially when connecting, it tells me that it cannot resolve my hostname, which we can fix by using NICK.

It will then send this when we register a user:

Seems like we have a functioning IRC server here. I first listed the channels available:

I decided to use a GUI tool called pidgin to connect to the IRC server instead. We just have to add irc.spaghetti.lan to our /etc/hosts file. I used the same username as per what I nicked myself earlier.

Then, I went to Conversations > Join a Chat and used #mailAssistant as the channel name to join. This dropped me within another chat group with a bot.

We can open a separate DM with this bot:

It drops a link to this Git repository:

Looks like we have some source code reviewing to do. There was one function within the irc_bot.py script that had the send_message function:

The parameters are not sanitised at all. As such, we can attempt to chain commands using && to inject commands into the script since it passes these arguments to shell commands.

Privilege Escalation

Cronjob -> MySQL Shell Injection

I ran linpeas.sh to enumerate, and it picked up on a cronjob running:

Here's the script contents:

Nothing much, it just keeps running the python script. I also ran pspy64 to enumerate the processes the root user might be running:

root is running a certain script. Here's the script contents:

The script basically sends emails to users. However, I noticed that the parameters from the MySQL database aren't sanitised at all, and passed directly into the mail command. This opens up a chance for injecting some commands. ${RESULT[0]} is the parameter that is vulnerable, and it is the username parameter from the database.

To exploit this, we can first put a reverse shell script within the host and chmod it:

Now, we need to find SQL credentials, which might be located within the Postfix files based on the name of the file root uses. I found it within the /var/www/postfixadmin/config.local.php file:

From here, we can login to the database and use the postfixadmin database.

The script uses the mailbox table, so we can update the entries within it:

Afterwards, we can just wait for root to execute it and give us a reverse shell:

Last updated