Hackin' around the Christmas tree

The following blog post shows how we found and exploited a WAN Remote Code Execution vulnerability within the Abis HD6000+ SMART Android projector.

When performing an assessment against an unknown device, an in-depth information gathering phase is great to get a better understanding of the target. Here, Google is our helpful elf. Following you will find a non-exhaustive list of documents and resources you may want to look at on the Internet:

• Device’s User Manual
• Device’s Amazon description page
• Device’s component manufacturers website/ Github
• Information about the OS running on the device

It was possible to retrieve some device specification thanks to Amazon's description of the product [1], the projector was an android-based device running version 6.0. After booting it and projecting onto the least flat wall we can find, we confirmed the aforementioned claims:

We immediately identified a couple of problems here:

• The AOSP was Android 6.0, which is outdated and affected by several security issues.
• The build running on the device was a userdebug build which, according to Android’s documentation [2] allows users to have root access on the device.

Once we achieved a satisfying knowledge about our target, we moved on to enumerating the attack surface.

My favourite way to analyse wifi-ready devices is connecting them to a controlled Wi-Fi hotspot (usually using an external Wi-Fi card). This is convenient for a number of reasons:

• It makes it easier to run Wireshark, Burp and other network analysis tools
• It makes it easier to simulate an Evil Access Point attack scenario

Once the projector was connected to our hotspot, we identified its IP address and ran a nmap scan against it:

If you are a mobile security enthusiast like me, TCP port 5555 will immediately take your attention. In fact, on Android, 5555 TCP port open usually means Android Debug Bridge Daemon (ADBD) listening over the network. We verified it by connecting with ADB:

As you can see above, not only we were able to get shell access to the device using ADB over the network, we were also able to get root privileges due to the fact that the AOSP is built in userdebug mode.

If you are an android geek, you are probably wondering why we were not prompted with a message like this:

The reason behind it is because the AOSP compiled in userdebug has the system property ro.adb.secure set to 0, therefore authentication is not required. You can check it yourself reading the Android source code [3].

This attack could allow an attacker on the local network to access the device without credentials and run any command as root on the device.

The 'attack' highlighted in the previous chapter is cool, but we were hunting for bugs that don’t require ADB access. Fortunately for us we had some other ports to check that could result in some other attack opportunity. Having ADB access on the device allowed us to use netstat in order to recognise which process was listening on a specific port. Unfortunately, Android’s netstat does not have some cool flag such as –p (which would show the PID listening on a specific port), therefore, we used busybox’s netstat which, luckily for us, was already available on the device.

The output above showed even more open ports identified during the previous nmap output, this is because nmap was instructed to run against only the top 1000 ports. In the following chapters, we will concentrate our analysis on the com.cloudtv package, which is listening on ports 9909 and 9915. However, the same methodology can be performed against all packages available on the device.

In order to analyse the application's APK, we need to download it on our testing machine. For this purpose, we used android’s pm utility to retrieve information about the package and then the adb pull command to download it locally:

Once we had downloaded the APK, we analysed it using jadx, an awesome DEX disassembler and decompiler. jadx also has a cool GUI which is super handy.

Because we wanted to know which portion of the code was handling traffic on port 9909, we used jadx's Search functionality, looking for where '9909' occurs within decompiled Java code.

We clicked on the first entry and inspected the following code:

Android allows users to mix Java and C++ code. This is done using the Java Native Interface (JNI) which allows to load native libraries at runtime. Once the library is loaded,in our case the p2p_old library, we can call native functions exported by the library from Java-land. We can do so by calling the methods declared as 'native'.

In order to understand how the application handled traffic on port 9909, we need to analyse the native library. Android native library can be found by unzipping the application’s APK and looking under the lib folder:

At this point we said goodbye to Java-land and jumped into native-land. For this purpose, we used Ghidra.

Because we were analysing a native dynamic ELF library, we focused on unsafe usage of system(), strcpy(), memcpy() and other native functions. Usually we tend to start looking for system(), because passing data to this function, without properly sanitising it, may result in code injection, which is easy to spot and to exploit.

Identifying usage of system() within the code using Ghidra, was possible by double-clicking the system() function from the ‘Function’ folder, and then clicking to the ‘Function call tree’ in the Window menu.

From Ghidra's window above, we saw that the system() function was called within the function _deal_debug which in turn was called by the handle_get function. The last function sounded like a HTTP requests parser.

By taking a closer look at the handle_get function, we realised that the entire code block was an embedded HTTP web server. The following portion of code handled a request to the /crossdomain.xml path.

in order to understand what a valid request looked like, we got a hint by analysing some debug files written in the /sdcard folder:

As you can see in the screenshot above, a valid request was in the form of /ctv.xml?cmd=stop_all_chan. We could easily spot the parameter value within the following code block:

The local_8c variable, contained a pointer to the value of the parameter cmd. Therefore, in order to jump to the function where the system() function was called, the cmd value has to be set as 'debug':

We then continued the analysis of the _deal_debug function:

The _deal_debug function checked for the bs parameter value, if it existed a string was created using the basic_string function, and formatted using the snprintf function on the ‘%s > %s/debug.txt’ format string. Then the formatted string was passed to system(). Bingo! This meant that we were able to execute the ‘id’ command on the server using the following request:

Server’s response confirmed our hypothesis as shown below:

It should be noted that this function is a debug capability (or backdoor) left in the code by developers. Finally, we obtained a reverse shell using nc defined within busybox which was already on the device:

The command above was executed after running nc in listening mode on the 4444 port, within a different shell.

This attack allows an attacker on the local network, to have shell access on the device just by sending a malicious payload to the vulnerable HTTP endpoint. 

Can we exploit our LAN RCE from the internet? To answer this question, we thought about our LAN RCE attack and we highlighted the following characteristics:

• It’s triggered via a HTTP GET request.
• The endpoint is not authenticated.
• CSRF protections are not in place.

Potentially we could create a phishing page, force the user to visit it and trigger an XMLHttpRequest to the vulnerable endpoint on the background. Unfortunately, we didn’t know the projector's internal IP. However, thanks to WebRTC, we could retrieve the user’s internal IP address by tricking the victim to visit a page that we control. Once we have the victim's internal IP address, we can send our malicious payload to all the devices on the private network, by bruteforcing IPs directly from victim’s browser. The full PoC is only available for people not on Santa's naughty list.

The following video, is a full proof of concept of the attack:

As you can see in the video above, this could allow an attacker to compromise the Abis HD6000+ SMART Android projector, by tricking the user to click to a malicious page controlled by the attacker.

Merry Xmas from WithSecure!

[1] https://www.amazon.co.uk/gp/product/B01675T3OA/ref=ppx_od_dt_b_asin_title_s00?ie=UTF8&psc=1

[2] https://source.android.com/setup/build/building

[3] https://android.googlesource.com/platform/system/core/+/bcd37e67dbf1e420c41b7cbaa22142c14ec5d8fc/adb/daemon/main.cpp#162

• Mark Barnes
• Toby Drew
• Mateusz Fruba