Hack The Box: Machines - Explore (Easy)

 


Introduction

Today I will be dealing with the Explore machine from Hack The Box. As you can read from the post topic it's an easy machine running on Android. This is my first attempt at breaking into the Android machine, therefore I've decided to share my path to the final solution. The only thing that I know about this operating system is that it's open-source, based on Linux, and apps are commonly written in Java. Without further talking let's jump into the catacombs.

Enumeration

First things first - in order to attack an infrastructure you have to get as much information about the target as possible. The better you know your target the greater chance you have. So as usual I'm going to launch the nmap with default scripts and services enumeration.

The command: nmap -sC -sV -p- -Pn -T4 -v 10.129.221.17 -oN nmap/explore.nmap

The result:



So the device that we want to pwn is a phone. The machine is running Banana Studio SSH server on port 2222, ES File Explorer on port 42135, and the Bukkit JSONAPI HTTP server on port 59777. As I've mentioned earlier, I don't really know Android yet so I've searched the Internet for any useful info on those services.
ES File Explorer is a file manager/explorer designed by ES Global, a subsidiary of DO Global, for Android devices. It includes features like cloud storage integration, file transfer from Android to Windows via FTP or LAN,[1] and a root browser. It was removed from the Google Play Store for committing click fraud.



As wiki states - the ES File Explorer is simply a file manager which can transfer files from Windows to Android devices via FTP for instance.
JSONAPI is a plugin for Bukkit/Spigot/Paper that allows you to access data and other information about your server and your players through a simple, yet secure, HTTP API. This allows you to make awesome websites, iPhone apps, and a way for your players to purchase goods online and automatically receive them in game.

The Bukkit service running on port 59777 is used for talking to the HTTP server. 

Notice that there is an exploit for the ES File Explorer 4.1.9.7.5. The exploit exact CVE is CVE-2019-6447 (https://www.exploit-db.com/exploits/50070). If you would like to read about how this attack works you can follow the exploit analysis under this link -> https://medium.com/@knownsec404team/analysis-of-es-file-explorer-security-vulnerability-cve-2019-6447-7f34407ed566 But I will give you an insight. 

First of all, you need to know that ES File Explorer is designed for working with other devices than a local phone. It means that you can for example access files from your phone with a computer. This feature is implemented using the HTTP protocol. The ES File Explorer has a built-in browser and it also bounds the HTTP service on port 59777 which is our Bukkit service. Therefore on port 59777, there is the HTTP server with access to files from the device. The arbitrary read in the exploit is done by making HTTP requests to that server. The vulnerability exists because those requests aren't validated. We can get access to the files from the remote machine that isn't really linked with the phone owner. This is how I understand the whole attack.

The exploit is available through Metasploit:

With the help of this exploit, we can get access to the files on the target phone. Unfortunately, the Metasploit version of the exploit didn't work as expected and it said that the target is not vulnerable. Maybe it's true but first, we should check it with the official PoC. The code lies inside this repo -> https://github.com/fs0c131y/ESFileExplorerOpenPortVuln The description tells us that we can also get files from the vulnerable phone and even launch apps! Ok, this is huge. But first I'm going to enumerate the machine and leak files.

There aren't interesting files in here but we can fuzz the sd card. This specific task can be done with the curl usage as states in the repo description. After issuing this command:

curl --header "Content-Type: application/json" --request POST --data '{"command":"listFiles"}' http://10.129.221.37:59777/sdcard


we can see that the user flag is on the sd card.


Let's fetch the user flag with the GET request.


As you remember the SSH service is running on the phone thus there might be credentials saved somewhere on the box. Most likely those credentials lie inside the photo gallery.


This is what I've expected. The creds.jpg file most likely contains the credentials to the SSH service. So let's fetch the picture and read them.


If you open the fetched file you will see the SSH credentials.



Privilege escalation

After searching the Internet for some useful information about sending commands to the phones I found that the adb (Android Debugging Bridge) is the tool that I was looking for. It acts as a shell but for Android devices. The adb is implemented as a client-server and has exactly three stages. It consists of a server, a client, and a daemon (adbd). A server manages communication between a client and a daemon. A client sends commands to a daemon and a daemon executes those on the target device. The way how it works is like this:

1. A client checks if a server service is running. If not, it creates the server process. When the server starts it binds to port 5037 and is running on the attacking machine. Obviously, the server listens for commands from the client and for the responses from the daemon.

2. The server then sets up a connection to all running devices. It scans the ports in range 5555-5585. Bear in mind that a device with debugging enabled uses even-numbered ports for console connections and odd-numbered ports for adb daemon.

Once the server sets up connections to all accessible devices we can send commands to them. Shells are opened in such a case.

But notice that a device should be connected to the USB in order to execute commands in a "normal" situation. Sometimes vendors can throw phones on the market with adb access available remotely. This gives governments the opportunity to control those devices. Here is an article about the topic -> https://dev.to/exadra37/android-devices-being-shipped-with-tcp-port-5555-enabled-1ig5 After doing scan with nmap for instance you can see that port 5555 is filtered but this is an indicator that something is going on with remotely available adb. To get access to the phone's shell we can simply create the SSH tunnel between port 5555 on the attacking machine and port 5555 on the target phone.


This tunnel works fine since the SSH is listening for a connection on port 5555. You can check this using netstat. The last thing to do is to connect to the SSH tunnel and start talking to the phone's shell:


When somebody gets access to the shell using adb he or she has full control over the compromised device. It means that getting root is as simple as typing su root.


The root flag is inside the /data directory. Because Android is based on Unix systems, you can use find command to search for the flag.



Sum-up


This was my first Android machine ever so I've been doing it with the Internet help. But I've learned a lot without any doubt. For me this box was amazing and it was probably launched for beginners in Android exploitation. Thank you all for reading and see you next time. Take care!

Comments

Popular posts from this blog

Learning of malware analysis. Solving 9-1 lab from the "OllyDbg" chapter. ("Practical Malware Analysis" book)

Learning of malware analysis. Basic static analysis labs from "Practical Malware Analysis" book