Setting Up the Lab Environment
To gain access to CONFLUENCE01, we need to leverage the command execution
vulnerability in the Confluence web application to get a reverse shell.
After discovering that the Confluence web application is vulnerable to
CVE-2022-26134, we’ll find a blog post from Rapid7 that includes a
cURL command containing a proof-of-concept payload
claiming to exploit the vulnerability and return a reverse shell.
Let’s review the example payload from the Rapid7 blog post.
We don’t run payloads without understanding exactly what they do,
so we first need to figure out what’s happening in this proof-of-concept.
The verbose curl request is being made to http://10.0.0.28:8090,
which we assume is the blogpost author’s vulnerable Confluence server.
After this, the URL path looks more interesting.
We observe that a lot of the characters in it are URL encoded,
so we need to URL decode them
to get a clearer sense of what the payload actually does.
After URL decoding the path, the function of the payload is clearer.
The URL path is an OGNL injection payload.
OGNL is Object-Graph Notation Language,
an expression language commonly used in Java applications.
OGNL injection can take place when an application handles user input
in such a way that it gets passed to the OGNL expression parser.
Since it’s possible to execute Java code within OGNL expressions,
OGNL injection can be used to execute arbitrary code.
The OGNL injection payload itself uses Java’s ProcessBuilder class
to spawn a Bash interactive reverse shell.
This proof-of-concept payload is almost perfect for our needs.
However, we need to modify it before we can use it.
This is for two reasons.
First, the Confluence server that the payload is pointing to in the original
payload is not where our vulnerable Confluence server is.
Second, the Bash reverse shell payload is pointing at port 1270 on 10.0.0.28,
which is not where our Kali machine is.
We need to modify these parameters in the payload before we can reuse it to exploit
CONFLUENCE01 and return a shell to our own Kali machine.
While making these modifications, we also need to take the URL encoding into account
The payload string in the proof-of-concept isn’t completely URL encoded.
Certain characters are not encoded.
Although it’s not always the case, for this particular exploit,
this turns out to be important to the functioning of the payload.
If any of these characters are encoded, the server will parse the URL differently,
and the payload may not execute.
This means we can’t apply URL encoding across the whole payload
once we’ve modified it.
Keeping this in mind, we’ll manually modify the parameters we need,
using the original proof-ofconcept payload as our base.
We’ll change the Confluence server IP to 192.168.50.63,
and the Bash interactive shell payload IP and port to a listener we’re going to open
on our Kali machine.
We’ll also remove the curl verbosity flag.
Now that our payload is customized for our use,
we can start a Netcat listener on our Kali machine on TCP port 4444.
With our listener running, let’s switch back to the first tab,
then run the curl command we just constructed.
The command itself doesn’t return anything,
but the reverse shell is caught by our listener.
The id command confirms that this shell is running with the privileges
of the confluence user.
This user has quite limited privileges.
Regardless, we now have a reverse shell from CONFLUENCE01 to our Kali machine.
We can now start some light enumeration of CONFLUENCE01 using our new shell.
We’ll check the network interfaces using ip address.
The output shows us that CONFLUENCE01
has two network interfaces: ens192 and ens224.
ens192 has the IP address 192.168.50.63,
and ens224 has the IP address 10.4.50.63.
We can then check the routes using ip route.
The command shows us that we should be able to access hosts in the
192.168.50.0/24 subnet through the ens192 interface,
and hosts in the 10.4.50.0/24 subnet through the ens224 interface.
Continuing our enumeration,
we’ll find the Confluence configuration file at the following directory.
While reading the contents using cat,
we discover some plaintext database credentials located within.
We’ll find the IP address of the database server,
as well as the plain text username and password used to connect to it.
We can use these credentials to authenticate to the database
and continue our enumeration.
We’ve hit a limitation, however.
CONFLUENCE01 doesn’t have a PostgreSQL client installed on it.
Since we are running as the low-privileged confluence user,
we are also unable to easily install software.
We do have the PostgreSQL client psql installed on our Kali machine,
but we can’t connect directly to PGDATABASE01 from our Kali machine,
since it’s only routable from CONFLUENCE01.
In this scenario, there is no firewall in place between our Kali machine
and CONFLUENCE01,
meaning that there is nothing stopping us from binding ports on the WAN interface
of CONFLUENCE01 and connecting to them from our Kali machine.
This is exactly the type of situation in which port forwarding can be useful.
We can create a port forward on CONFLUENCE01 that listens on a port
on the WAN interface, then forward all packets received on this port
to the PGDATABASE01 on the internal subnet.
In the next section, we will use Socat to achieve this.