Proving Grounds | ZenPhoto


Host is up (0.24s latency).
Not shown: 65531 closed ports
22/tcp open ssh OpenSSH 5.3p1 Debian 3ubuntu7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 1024 83:92:ab:f2:b7:6e:27:08:7b:a9:b8:72:32:8c:cc:29 (DSA)
|_ 2048 65:77:fa:50:fd:4d:9e:f1:67:e5:cc:0c:c6:96:f2:3e (RSA)
23/tcp open ipp CUPS 1.4
| http-methods:
| Supported Methods: GET HEAD OPTIONS POST PUT
|_ Potentially risky methods: PUT
|_http-server-header: CUPS/1.4
|_http-title: 403 Forbidden
80/tcp open http Apache httpd 2.2.14 ((Ubuntu))
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.2.14 (Ubuntu)
|_http-title: Site doesn’t have a title (text/html).
3306/tcp open mysql MySQL (unauthorized)
|_ssl-date: ERROR: Script execution failed (use -d to debug)
|_tls-alpn: ERROR: Script execution failed (use -d to debug)
|_tls-nextprotoneg: ERROR: Script execution failed (use -d to debug)
No exact OS matches for host (If you know what OS is running on it, see ).
TCP/IP fingerprint:

Uptime guess: 0.017 days (since Fri Aug 6 01:54:04 2021)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=202 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 8080/tcp)
1 239.52 ms
2 239.95 ms

NSE: Script Post-scanning.
Initiating NSE at 02:17
Completed NSE at 02:17, 0.00s elapsed
Initiating NSE at 02:17
Completed NSE at 02:17, 0.00s elapsed
Initiating NSE at 02:17
Completed NSE at 02:17, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 1402.24 seconds
Raw packets sent: 68977 (3.040MB) | Rcvd: 119342 (14.853MB)

The homepage for port 80 says that they’re probably working on a web application.

Visiting the /test directory leads us to the homepage for a webapp called zenphoto. By typing keywords into the search input, we can notice that the database looks to be empty. I initially googled for default credentials for ZenPhoto, while further enumerating directories/pages, but did not find credentials. However, the source code for /test/index.php contains information leakage of the webapps version → zenphoto v


Again, we google for publicly available exploits → This exploit does not need authentication and by skimming through the exploit, we can determine that the exploit is uploading a php web shell by sending a POST request to zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager/ajax_create_folder.php and putting the php web shell payload into Content-Length header. After which, sending a GET request to zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager/inc/data.php trigger the RCE.

We could get a reverse shell a couple of ways, but the fastest way is to use this reverse shell payload below.

We can confirm that the exploit indeed uploaded our php webshell into data.php.


By using auto enumeration script linenum, we can observe that we can write to the binary changeip, which seems to be doing some networking and dns stuff. After processing what the script does, checking SUID binaries if any of them will run this binary, and using pspy to see if the root user runs this as a cron job — I felt that there was no way for me to escalate privileges through changing the script as there was no way for me to run it as root.

Next, I checked out config files for the ZenPhoto app to look for things that could be of value.

In /var/www/test/zp-data/zp-config.php, we can find credentials for the mysql database.

Using the given credentials, I was able to login into the database.

After careful enumeration of the database, I found the admin user and it’s respective password hash.

This seems to be SHA-1 hash as recognized by the hash-identifier binary on our kali linux. I tried cracking the hash using john and hashcat against rockyou.txt, however was not able to crack it.

Next, I’ve used linux exploit suggester script on the host to determine exploits that I could use to escalate privileges. Dirtycow and rds both came up as highly probable. DirtyCow was not working in this case, but RDS worked like a charm. RDS exploit →

Just compile the exploit by gcc -m32 rds.c -o rds, transfer it to the target host, grant execute privileges, then run to become root.