Amaterasu#

A 5-point machine on Proving Grounds Play.

Executive Summary#

The target machine contained a vulnerable web app which allowed for arbitrary file upload. Leveraging this to overwrite a critical user configuration file allowed remote access to that user account. A cron job accessing information from a lower-privileged directory could then be exploited to gain privileged code execution. Full root shell access was gained by adding an additional root user using the privileged code execution.

Methodology#

Port Mapping / Service Discovery#

nmap

Route discovery#

GoBuster / DirBuster

Cron Job Enumeration#

ls, cat

Payload Generation#

hand-written bash scripts

Information Gathering#

Initial port scanning of the in-scope target revealed one open port, for FTP on port 22. After confirming operation of the FTP server, additional port mapping was performed in the extended port range, to cover the full range of possible ports. Three additional services were located, on 25022, 33414, and 40080.

These services were determined to be ssh, a python “Werkzeug” webserver, and Apache respectively.

Vulnerability Assessment#

Probing each service in turn found 1 vulnerability, the Werkzeug web server was configured to allow file upload without restrictions and directory enumeration, again without restriction or authentication.

The FTP server allows anonymous access, which was initially thought to be a vulnerability, but there appears to be no escalation path at current. It will still be recommended to disable all unauthenticated procotols.

The SSH server apears to be running a recent version without known vulnerabilities.

The Apache server appears to serve static content and not contains vulnerable content.

Exploitation#

Probing the Werkzeug api endpoints further, we were able enumerate files on the machine using the /file-list endpoint. We then found that a user alfredo was present on the machine, with ssh credentials. Working on an assumption that the default ssh configuration was in use, we utilized the file-upload endpoint to place an authorized_keys file into the alfredo user’s ssh configuration.

This allowed remote login to the alfredo user.

Post Exploitation#

Having achieved our initial unprivileged access, we moved to internal enumeration and vulnerability assesment. As one of the initial enumeration steps we checked the cron jobs that are configured. We found 1 cron job set to run every minute, which reads files from a folder the alfredo user controls. Because of the way the cron job’s script is designed, it allowed low-privileged user alfredo to control the PATH environment variable in which commands were executed. By placing a shell script into the PATH we were able to cause the cron job to invoke our shell script using the root user privileges.

Using this privileged code execution pathway, we added an additional uid 0, root2 user with known password w00t to the /etc/passwd file. We were then able to escalate the authenticated login shell we had obtained for user alfredo using the root2 user credentials.

Risk Analysis#

This attack was trivial, and presents a critical risk that the machine can be completely controled by any unauthenticated parties with the ability to send packets to it on ports 25022 and 33414.

Recommendations#

We recommend removal of the vulnerable web service, and reconfiguration such that the web service runs as a restricted privileged service account configured without a login shell and without access to the full filesystem. Additionally the web app should be updated to restrict the files and folders that can be read or written to with stricter checks on user input. Finally the web app should add a layer of authentication so unauthenticated users cannot interact with these endpoints.

The cron job should also be reconfigured to run in the context of a specific daemon account, again with simularly low privileges and no login shell. Potentially this could be the same user account as the web service but we would recommend a different one, as to allow the backup cron job access to the backup location without allowing the web app service account access to that location.