Devvortex
Created by 7u9y
The following post by 0xb0b is licensed under CC BY 4.0
Summary
An Nmap scan identified open SSH and Nginx web server ports. Through directory and VHOST scanning, the target dev.devvortex.htb was pinpointed, revealing a vulnerable Joomla CMS on its administrator page. Exploiting a known RCE vulnerability in Joomla version 4.2.6, MySQL database credentials were extracted and used to gain administrative access at the Joomla backend.
With administrative access, a web shell was uploaded to Joomla, allowing command execution on the server. This capability led to a reverse shell as www-data, and subsequent access to user logan's account after cracking password hashes found in the database.
The final stage involved exploiting a vulnerability in apport-cli for privilege escalation. By creating a crash report and escaping out of a crash report view, a root shell was spawned, providing complete control over the system.
Recon
We scan the target with a Nmap scan and discover 2 open ports. We have SSH on port 22 and a Nginx web server in version 1.18.0 on port 80
We then enumerate the web server's directories using Gobuster, but find nothing special.
Inspecting the site manually only reveals static links and no possible entry points.
We use Ffuf to enumerate further VHOSTs, and we find what we are looking for: dev.devvortex.htb will be our next target.
A directory scan on dev.devvortex.htb reveals an administrator page and an api page. A little more interesting.
The index page is not that promising.
When we visit the administrators page, we see that we are dealing with the Joomla cms.
Shell as www-data
Let's see what kind of version and possible vulnerabilities we are dealing with this Joomla. For this we make use of joomscan. And we are dealing with version 4.2.6.
joomscan --url http://dev.devvortex.htb
After a short research, we find an RCE vulnerability for this old version, whose POC can also be found in the following article. First, we are dealing with an information leak vulnerability that allows us unauthorized to extract sensitive information such as MySQL database credentials in clear text.
With the following request to the web server, we receive the MySQL credentials of the user lewis.
โโโ(0xb0bใฟkali)-[~/Documents/htb-app/devvortex]
โโ$ curl -v http://dev.devvortex.htb/api/index.php/v1/config/application?public=true
On exploit-db you can also find a ruby script that provides a clearer output.
sudo gem install httpx
sudo gem install docopt
sudo gem install paint
https://www.exploit-db.com/exploits/51334
Next, we try to log in with those credentials via SSH and the Joomla login. And are able to log in successfully at Joomla. Nice, now we need to manage to get a web shell.
For this, there are various web shell plugins for Joomla available:
We request the following page, and we see that we are allowed to upload plugins.
http://dev.devvortex.htb/administrator/index.php?option=com_installer&view=install 
Next, we download the web shell plugin mentioned before and build it.
Then we can just drop the created zip into the field of uploading and installing Joomla extensions.
Now we are able to execute commands at the following page.
http://dev.devvortex.htb/modules/mod_webshell/mod_webshell.php?action=exec&cmd=id
The exploit also comes with a python script that makes the web shell a bit more interactive. However, it is still a web shell. We use revshells.com, set up a listener and spawn a reverse shell.
After having the interactive reverse shell as www-data we upgrade the shell. Unfortunately, we did not reach the user flag yet.
Shell as logan
We have the user logan on the system. From our automated exploit CVE-2023-23752, we know that logan is also registered with Joomla. We may also find his credentials in the user database. With a bit of luck, these could have been reused. We use the credentials from the previous steps to login to the MySQL database.
sd4fg_users looks promising.
Querying the contents of the table sd4fg_users, we find the hashes of lewis and logan.
The hash is a bcrypt $2*$, Blowfish (Unix) hash and can be cracked with mode 3200.
We are able to log in with the credentials of logan and find the user's flag in the home directory of the user.
Shell as root
When enumerating as logan, we immediately notice that we can call /usr/bin/apport-cli using sudo. Not the nasty binary found on GTFOBins. So let's take a look at the version to find possible vulnerabilities.
After a little research, we find what we need. Our version is vulnerable and allows us to extend our rights. In short, when we read a crash report, we can spawn a shell. Below are all the resources and explanations found:
A privilege escalation attack was found in apport-cli 2.26.0 and earlier which is similar to CVE-2023-26604. If a system is specially configured to allow unprivileged users to run sudo apport-cli, less is configured as the pager, and the terminal size can be set: a local attacker can escalate privilege. It is extremely unlikely that a system administrator would configure sudo to allow unprivileged users to perform this class of exploit.
The apport-cli supports view a crash. These features invoke the default pager, which is likely to be less, other functions may apply.
It can be used to break out from restricted environments by spawning an interactive system shell. If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access.
apport-cli should normally not be called with sudo or pkexec. In case it is called via sudo or pkexec execute `sensible-pager` as the original user to avoid privilege elevation.
Proof of concept:
$ sudo apport-cli -c /var/crash/xxx.crash
[...]
Please choose (S/E/V/K/I/C): v
!id
uid=0(root) gid=0(root) groups=0(root)
!done (press RETURN)This fixes CVE-2023-1326.
Bug: https://launchpad.net/bugs/2016023 Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
Unfortunately, we do not have any crash reports on the system. What a pity.
But we can create one ourselves using the parameter tag -f.
After creating the report we can immediately view the report by entering V. There we place :!/bin/bash to spawn a shell, since we run this in the context of root using sudo we get a root shell, and are able to reach out to /root and read the root flag at /root/root.txt.
:!/bin/bash
Another way to generate a crash report could be to kill a process with the SIGSEGV signal, which would mean a SEGFAULT.
Background Execution of
sleepCommand:sleep 10 &starts a background process that pauses for 10 seconds, allowing parallel command execution.Inducing a Segmentation Fault:
killall -SIGSEGV sleepsends a segmentation fault signal to all activesleepprocesses. TheSIGSEGVsignal forces these processes to terminate as if they encountered an invalid memory access. This action results in the operating system generating a crash report, useful for debugging and testing system error handling.
We can then read in the report using -c and enter !:/bin/bash to spawn a root shell.
Last updated
Was this helpful?