Inject
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 3000 10.129.178.106
Starting Nmap 7.93 ( https://nmap.org ) at 2023-03-11 22:25 EST
Nmap scan report for 10.129.178.106
Host is up (0.17s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
8080/tcp open http-proxyZodd Cloud LFI
Port 8080 a corporate webpage for some product:
There's an Upload function in the top right of the page. When we upload a file, we can view it on the server:
There's an LFI vulnerability here.
Two users frank and phil are on the machine. Running a gobuster scan, this is what we find:
The release notes shows that the creators added some 'checks' for the upload feature, which obviously failed if LFI can be used:
We need to find out what kind of framework this is running. Because this uses images, I found out we can read directories like this:
Going into WebApp, we find more directories:
We should be searching for the code used for the upload function. This can be found at /var/www/WebApp/src/main/java/com/example/WebApp/user/UserController.java.
Spring Cloud RCE
There does not seem to be much here, and I can't find any loopholes. In cases like this, we can look at the dependencies and see if we can break that. This uses springframework, which is known to have SOME vulnerabilities.
We can read the /var/www/WebApp/pom.xml file to get more information about the dependencies:
We can notice this is running spring-cloud-function-web version 3.2.2, which happens to be vulnerable to CVE-2022-22963, an RCE exploit.
The PoC is pretty simple:
We find that this works!\
Now we have RCE, we can easily get a reverse shell. I got this via 2 commands, one that downloads a small reverse shell script via curl and then executes it with bash.
We can upgrade the shell by dropping our public key in a authorized_keys folder in frank home directory.
Privilege Escalation
Phil Credentials
Within frank home directory, we can find the credentials of the other user:
With this, we can su to phil.
Playbook PE
I ran a pspy64 to see the processes being run by root. Here are some of the interesting lines seen:
We can see that the root user is running Ansible playbooks in the background. We can also see that there is a wildcard being used to detect .yml files via /opt/automation/tasks/*.yml. The user phil can also create files within this directory.
Pretty straightforward PE vector. We can see the existing playbook to follow the format required.
This playbook using the built-in systemd module, and we can replace that with ansible.builtin.shell to execute commands.
After changing the module and command, we need to specify become: true to enable privilege escalation. This is the malicious playbook created:
Download this via wget to the machine and wait. After a bit, we should get an easy root shell.
Pwned.