Penetration Testing of the XTU J9 Smart Door Camera

Device Overview

At the start of this project, I worked with the XTU J9 Smart Door Camera, a robust IoT device with advanced security and monitoring features. This camera offers 1080p HD video streaming, motion detection, night vision up to 10 meters, and two-way audio communication. It is powered by a 4800mAH battery and supports local and cloud storage, including local SD card storage up to 128 GB. For connectivity, it uses Wi-Fi and allows real-time alerts to be sent directly to the user's smartphone.

The functionality of the device revolves around monitoring the live feed, communicating via two-way audio, and receiving real-time notifications about visitors or suspicious activities. The device communicates with the Cloudedge app for real-time interaction and allows seamless remote access.

Investigation Process and Device Setup

I began by setting up the XTU J9 camera using the Cloudedge app. The device setup process was quite straightforward, involving scanning a QR code generated from the app to establish a Wi-Fi connection. During the initial setup, I proxied the connection through my machine to capture network traffic using Wireshark and Burp Suite. My goal was to intercept packets during the interaction between the camera and the app.

1. Intercepting Packets

Once I started the device and clicked "Add Device" on the app, I noticed that the app sent a request to the cloud server (apis-us-west.cloudedge360.com) with query parameters that returned the setup video URL.

When I entered the Wi-Fi credentials, the app generated a QR code based on the provided network details. This QR code was meant to be scanned by the camera, and it was generated using a cloud-based API. Although I didn’t have time to explore further, it was evident that forging this QR code would be relatively easy using tools like CodeUtils.

2. Wi-Fi and Device Communication

Following the Wi-Fi setup, I found that the device was receiving an IP address via DHCP as expected. However, during an Nmap scan, I discovered that all the ports on the device were closed, which raised some curiosity about the device's architecture.

Device in Use: Network Traffic and Security Analysis

Once the setup was complete, I started testing the camera's functionality. Pressing the alarm button on the device triggers the two-way audio feature, allowing communication between the camera and the app. During this interaction, I observed several unencrypted HTTP POST requests being sent to the cloud.

The POST request sent visitor event data (like the timestamp and device ID) to the cloud server, while subsequent traffic transmitted encrypted video data to the cloud storage server. Although the video data was encrypted, the lack of encryption in some of the HTTP requests presented a potential vulnerability.

Detailed Reverse Engineering: APK Analysis

To analyze the device further, I decompiled the Cloudedge app used to control the camera. Using MBSF Framework for static analysis, I uncovered several critical vulnerabilities:

1. World-readable Sensitive Data

Sensitive information, including Wi-Fi credentials and cloud login details, was stored insecurely in SharedPreference files within the app. I retrieved files like WIFI_INFO.xml and MEARI_USER.xml that contained unencrypted sensitive data, exposing the device to attackers who could potentially access these files.

2. Weak Encryption

The app used vulnerable encryption methods, particularly DESede with weak initialization vectors (IVs) and hardcoded secrets. This could potentially allow attackers to brute force the encrypted data.

3. SQL Injection

During my analysis, I found that the app’s internal database was vulnerable to SQL injection attacks. Raw SQL queries without proper input sanitization were used for operations like deleting account passwords.

Possible Attack Vectors

• Replay Attacks
• Unencrypted Traffic
• Cloud Interaction Vulnerabilities
• De-authentication and Wi-Fi Brute Force Attack

Since the device uses Wi-Fi for connectivity, it is vulnerable to de-authentication attacks using tools like Aircrack-ng. By sending continuous de-authentication frames, I was able to prevent the doorbell from reconnecting to the router, resulting in a denial of service. A brute-force attack could then be performed using a captured WPA handshake.

The de-authentication attack works well with the smart video doorbell. If continuously sending the de-authentication frames, the smart doorbell will not be able to connect to the router and be used normally.

This is a kind of DoS attack. IEEE 802.11w protocol provides a solution against the de-authentication attack. However, the 802.11w protocol is only effective for resolving the de- authentication attacks with low flooding rates and not effective under high flooding rates.

Figure 6: De-auth Attack

After We have got the handshake, we can brute force it with a password dictionary using Aircrack-ng tool.