cestoliv, il y a 3 ans - lun. 27 sept. 2021

Explore - HackTheBox Machine

A vulnerability in the Android ES File Explorer application allows us to access the smartphone's file system. Then ADB will allow us to take control of it.

Ports enumeration

I scan all ports (with -p-). Despite the -sV which should return the software and its version behind each port, nmap is having a hard time to know what is there, so I modified the following return with some research I did.

nmap -p- 10.10.10.247
# PORT      STATE    SERVICE
# 2222/tcp  open     SSH Server Banana Studio
# 5555/tcp  filtered freeciv
# 40487/tcp open     unknown
# 42135/tcp open     unknown
# 59777/tcp open     ES File Explorer

Vulnerability CVE-2019-6447 in ES File Explorer

Port 59777 belongs to a service accessible via the browser, but the address http://10.10.10.247:59777/ returns a FORBIDDEN: No directory listing. error. We can't list the current directory, but we could potentially access a file if we give its full path.

Reading this article shows us a flaw in the ES File Explorer application, the latter leaves a port open to the world and this allows us to make it execute commands and retrieve their return. So I test with the command getDeviceInfo indicated by the article and it works!

curl --header "Content-Type: application/json" --request POST --data "{\"command\":\"getDeviceInfo\"}" http://10.10.10.247:59777
# {"name":"VMware Virtual Platform", "ftpRoot":"/sdcard", "ftpPort":"3721"}

User own!

The return of the command confirms my theory, we have an ftp accessible via the browser whose base is in the /sdcard of the phone. So we feel around and we finally find that the user flag is accessible at the address http://10.10.10.247:59777/sdcard/user.txt.

The privileges escalation

I continue to dig the ES File Explorer flaw, the repo ESFileExplorerOpenPortVuln informs about other commands we could execute, we can list files, images, videos, etc. I wander a little in the file system and by listing the DCIM folder, I came across a photo whose name seems evocative (creds.jpg)

curl --header "Content-Type: application/json" --request POST --data "{\"command\":\"listFiles\"}" http://10.10.10.247:59777/sdcard/DCIM
# [
# 	...
# 	{"name":"creds.jpg", "time":"4/21/21 02:38:18 AM", "type":"file", "size":"1.14 MB (1,200,401 Bytes)", },
# 	...
# ]

The image is accessed via the browser (http://10.10.10.247:59777/sdcard/DCIM/creds.jpg)

the creds.jpg image found on the explore machine

It looks like a pair of credentials and these indeed allow us to connect in SSH to the smartphone.

Problem, we have access to nothing more than what we had before, we don't have read rights in all the crispy folders where the root flag could be.

FreeCIV Arbitrary Code Execution

A small search on Google for ssh server banana studio exploit seems to give the same result every time, a script by Raed Ahsan, moreover, we come across the same script when we search for freeciv exploit, another service that runs on port 5555.

By analyzing the script a bit, we realize that it does only one thing that we can do in one command, it connects in SSH to the device (which we can do thanks to the credentials of the picture) and exposes the port 5555 of the phone on our local port 5555 :

ssh -p 2222 -L 5555:localhost:5555 kristi@10.10.10.247

As long as this connection is open, we have access to port 5555 of the phone locally. This port will allow us to open an ADB (Android Debug Bridge) connection (https://developer.android.com/studio/command-line/adb) remotely. To do this, we start the adb daemon with adb start-server (the adb daemon MUST be started after redirecting port 5555, if it is already started, we kill it with adb kill-server). If we now run an adb devices, we see that a device is connected:

adb devices
# List of devices attached
# emulator-5554   device

You can now do (almost) anything you want on this phone. For fun, we can even display and control its screen remotely with the [scrcpy] tool (https://github.com/Genymobile/scrcpy).

screenshot of scrcpy displaying the phone screen

However, the problem remains the same: we don't have read rights on the folders we are interested in. An "easy" solution would be that the phone is rooted and that we just have to do an su via the ADB shell to become root. And the more I think about it, the more I think it's possible, and it doesn't cost anything to try:

adb shell
x86_64:/ $ su
:/ #

AND IT WORKS, we now have access to a root shell on the phone!

System own!

A simple find allows us to locate the root.txt file:

find / -name root.txt
# ...
# /data/root.txt
cat /data/root.txt