Enumeration

Browsing to the webpage on port 8080 lands at a "Zodd Cloud" product page. There seems to be signup and sign in functionality that will be worth exploring.

None of the links work except signup, which lands at an Under Construction page.

Oh, but there is an Upload link kind of hidden at the top right corner of the homepage. Apparently only image files are allowed after I tried to upload a text file. After uploading an image, you get a link to view the uploaded file in the format http://10.10.11.204:8080/show_image?img=wtqqnkYDYi2ifsWZVW2MT4-1200-80.jpg

This seems like perhaps a fairly standard local file inclusion vulnerability. Some more testing needed to determine exactly how this behaves. Turns out you can upload anything with an image file extension. However, when trying to access non-image files, the server returns an error message that the image could not be displayed. Perhaps there is some blind code injection going on. Using curl we get an interesting error:

Sure enough, you can access local files using curl

Initial Access

Phil and Frank are going to be the targets for initial access based on the passwd file.

After a considerable amount of time trying to upload a file, use webshells, find config files, etc. I finally found pom.xml which indicates some versions of components. Specifically, spring-cloud-function-web version 3.2.2 is vulnerable to RCE as part of the Spring4Shell vulnerability.

Using the POC I found here after some searching for POCs, I was able to test command execution with a ping command.

Next step is to shell this bad boy. I tried to use my command injection to write to Phil and Frank's authorized key files but without success. Next up is a reverse shell.

After lots of time trying different payloads, I finally was able to get this one working easily. The reverse shell returned was for the frank user. Within Frank's home directory is a settings.xml file in the .m2 directory that has a username and password for Phil.

DocPhillovestoInject123

With this access I added my public key to the authorized keys file to maintain easy access.

Pivot

Using the password in the file, I was able to su phil to pivot to the Phil user.

Escalation

Root's home folder /root is oddly owned by the staff group which Phil is part of. This is odd.

Searching for files using find / -group staff 2>/dev/null reveals the directory /opt/automation/tasks which looks interesting and related to Ansible.  The directory is owned by the staff group and Phil is part of this group and can write files to the directory. I had a suspicion that Ansible would run any playbook in this directory.

So I created my own playbook.

- hosts: localhost
  tasks:
  - name: Checking webapp service
    shell: "echo $(cat /root/root.txt) > /home/phil/root.txt

Sure enough, after about a minute, my new file ended up in my home directory and had the root key in it!

With this access, you could conceivably write a playbook to do anything including escalate to full root access. That is left as an exercise to the reader.