It is currently 20-10-2017 01:06

The study of the internal structure and security IP camera

The study of the internal structure and security IP camera

by sigismund » 2016-07-26 00:37:16


this article will explain how I analyzed the traffic cheap PTZ IP camera, and then connected to the serial console on the Board, got the root password and logged in using telnet via the wireless interface


In this article you will learn about how I analyzed the traffic cheap PTZ IP camera, and then connected to the serial console on the Board, got the root password and logged in using telnet via the wireless interface. My main goal was to find vulnerabilities and improving safety is very cheap IoT devices (Internet of Things; Internet of things).

The experimental device will be the model Logilink WC0030A in the world also known as the Apexis APM-JP8015-WS.


figure 1: External view of IP-cameras LogiLink


Over the last couple of years, IP camera much cheaper. Due to mass production the price of the good sensors images and the option Board have fallen significantly. Our experimental IP camera, at the time of this writing, can be bought for 43 EUR. A similar model/copies and clones from China are sold even cheaper.

On the one hand, a cheap device – it's just great, if you don't want to shell out much on the alert system, or just for fun want to watch neighbours or animals. On the other hand, the cheapness suggests that security developers have not paid much attention (how many paid, so much got). App/firmware is full of holes, poor functionality, and issues of security are in last place.

Safety in cheap IoT devices becomes one of the main problems. Manufacturers don't really care about personal data of users who use similar products. And the users themselves do not have sufficient knowledge to assess the safety or protect your device (in some cases, the main advice – do not use the device at all).

As an example, you can enter the following query in the search engine Shodan, which searches for IoT devices and everything that is not indexed by Google. The results of the query a bit mind-boggling as to the number of unsafe chambers, to which you can connect, is in the shops, living rooms, playgrounds, Parking lots, kitchens, stairwells, parks, factories, bedrooms (o_O), auditoriums, hotels, and even funeral services.

Before using the above model, I wanted to know the amount of "leaking" of information and how difficult is it to connect from the side to observe my dog.

Part of camera Logilink WC0030A sensor is 0.3 MP, wired Ethernet interface, a WiFi radio (wired and WiFi interface cannot be used simultaneously), several infrared sensors and 2-way audio. The camera can be rotated/tilted and has a warning system. In short, a standard set.

Inside the camera has a web server and accessed through a web interface. In addition, the camera is compatible with a large number of mobile applications, many of which are "slightly" leaky. The manual mentioned two accounts (admin:admin and 000000:1234). Trial and error in the different places where authentication is required, helped to get the best results.


figure 2: Web interface of IP camera the Logilink


In the web interface has standard buttons and sections, and also contains the firmware version of the interface (this interface is "non-native"; at the time of this writing I have installed a version from the company Apexis). In addition, I don't own a purple couch (not white balance). In the settings you can configure DNS, but even if the settings or disable the DNS, apparently, the camera is always connected with built-in dns server (oipcam.com). Completely disconnect there is no way. Apparently, a direct MJPEG stream is available at

Code:__tp://[IP]/videostream.cgi?usr=[USERNAME]&pwd=[PASSWORD].

We will try to login to the camera and to access the terminal, see the operating system version and check to see where data is sent.

First, scan ports and check the work of the service:

Code:$ nmap [IP]

Starting Nmap 6.40-2 ( __tp://nmap.org )
Nmap scan report for [IP]
Host is up (0.012 s latency).
Not shown: 998 closed ports
PORT STATE SERVICE
23/tcp open telnet
80/tcp open http

Nmap done: 1 IP address (1 host up) scanned in 3.10 seconds


What is open port 80 was expected. The presence of telnet is already causing mixed feelings. Try to connect using the standard password:

Code:$ telnet [IP]
Trying [IP]...
Connected to [IP].
Escape character is \'^]\'.

(none) login: admin
Password: 1234
Login incorrect
(none) login: admin
Password: 000000
Login incorrect
(none) login: Connection closed by foreign host.


At least the passwords mentioned in the documentation are not suitable for access via telnet. It would then be possible to start a direct search standard accounts and passwords, but first let's look if the external service connects to the camera (and therefore the passwords used).

If you need to perform incoming/outgoing traffic, Wireshark is probably the best choice. Of course, we can't launch this utility directly on the camera, so will intercept the packets through the router that is connected to the device. I use a cheap and functional model Nexx WT3020 distribution OpenWRT. The ideal system for sniffing connected hosts.
We will connect to the router via SSH, use tcpdump to intercept all packets, which will then be redirected to Wireshark.

Install tcpdump-mini can be either through LuCI (the web interface in openWRT) or via SSH:

Code:[email protected]:~# opkg update
[email protected]:~# opkg install tcpdump-mini


Next, connect to the router and run a packet sniffer on interface br-lan (except for the SSH port) and the information forwarded to Wireshark:

Code:ssh -x [email protected] tcpdump \'tcp port not 22\' -i br-lan-s0 -U -w - | wireshark -k-i -

You can go the other way and unload all packages .pcap file and then to analyze.

Code:ssh -x [email protected] tcpdump \'tcp port not 22\' -i br-lan-s0 -U -w - > dump_$(date +\'%T_%m-%d-%y\').pcap

After connecting with the camera and the completion of the cycle of downloading we open the file with the collected packet in Wireshark and start filtering:

Code:eth.src == 54:cd:ee:[MAC] || eth.dst == 54:cd:ee:[MAC]


This filter gives all the packets passing through the chamber. As a filter use the MAC address of the device:


figure 3: Filter the packets passing through the chamber


The picture above shows that the first camera generating a standard DHCP request after getting the IP address from the router. Then the camera sends a DNS request for hosts time.nuri.net and checkip.dyndns.org. The first address is the NTP server (somewhere in China), which may have been used to set the time. The second URL is used to retrieve the external IP address of the camera via dyndns.org.

The device then continues to create a DNS request for the address oipcam.com and sends the following HTTP request:

Code:__tp://www.oipcam.com/vipddns/upgengxin.asp?username=o9428&userpwd=958&userdomain=o9428.oipcam.com&userport=80&mac=00-00-00-00-00-00

(In the query I changed the username/password and reset the MAC address). Host oipcam.com sends the HTTP packet of "200 OK" with content "UP".
Then forms a DNS request for the address www.apexisalarm.com with the following HTTP request (uid changed)

Code:__tp://www.apexisalarm.com/apns.php?cmd=reg_server&uid=53XHWU68T345HGf571N0

In response comes the following: reg_server !!!!
Server device 53XHWU68T345HGf571N0 login.
The camera then pings the router. It is possible to check whether the network is running.

Next, another DNS query for the address checkip.dyndns.org and two ping the router. Then a DNS request for the address www.3322.org with the HTTP request __tp://www.3322.org/dyndns/getip. The latter need to identify the IP address of the camera.

Then a few DNS queries for the address www.ip138.com that fail. In the end, the camera will fixate on the ping of the router.
In the end we found 2 external service used by the camera and located at oipcam.com and apexisalarm.com. Other queries can be used to set the time and identify the external IP address (here, of course, also can be leakage of IP).
Attempt to use accounts that are designed for external services, connecting to telnet without success.
Next, open the camera case to determine where the ticking!


figure 4: the Rear panel of the camera


Ports are on the rear side of the camera. Please note that the silk screen on the input/output terminals of the notification system is manifested more clearly than others the marking of the shell.


figure 5: Reverse side of the Board


On the reverse side of the Board. The reset button is on the right, blank space for chips, along with the tying of the findings on the left and the microphone at the top.


figure 6: control Board


The control Board is marked Ralink RT5350F and, most likely, is an OEM module that is inserted into the main charge. Marking JP8015 indicates the model number of the camera. In addition, we see that the movement of the camera is controlled by two stepper motors, powered from the batteries to 5V and operating at a constant current.

The chip is quite functional and is used in some small, cheap WiFi routers, most of which are running OpenWRT distribution. Runs on Linux at a frequency of 360 MHz, has 24 GPIO pins, storage at 8 MB and RAM of 32 MB. Probably this chip has a strong resemblance with the model NixCore X1, but not completely. And let's hope that the output pins of the main substrate are the same.

After examining this table and the documentation for the X1, I come to the conclusion that we can access the serial terminal on the chip RX2/TX2 via 39 and 40 pins. If you look at the camera, those two pins are in our module, but not hooked up to anything. A good sign.
After connecting a serial USB Converter, working voltage is 3.3 V, the module at speed of 57600 baud we get to the right place!

Boot-Protocol:
U-Boot 1.1.3 (Nov 18 2012 - 20:35:15)

During the boot process reveals a lot of interesting things, but let's focus attention on connecting to the camera via telnet. Running a simple command:

Code:$ cat /etc/passwd
root:1naesbIMqm.cY:0:0:root:/:/bin/sh


In the end find only one root user with a password 1naesbIMqm.cY. Of course the password is encrypted with the irreversible algorithm of DES.
Will try to do a brute force using John the ripper:

Code:$ john --show passwd
root:123456:0:0:root:/:/bin/sh

1 password hash cracked, 0 left


The task was simple.
We are trying to connect to telnet:

Code:$ telnet 192.168.1.242
Trying 192.168.1.242...
Connected to 192.168.1.242.
Escape character is \'^]\'.

(none) login: root
Password: 123456


BusyBox v1.12.1 (2012-11-19 22:34:42 PST) built-in shell (ash)
Enter \'help\' for a list of built-in commands.

#


And again fall into the right place (the second time).

Code:# cat /proc/version
Linux version 2.6.21 ([email protected]) (gcc version 3.4.2) #136 Mon May 20 11:39:34 CST 2013
# cat /proc/cpuinfo
system type : Ralink SoC
processor : 0
cpu model : MIPS 24K V4.12
BogoMIPS : 239.61
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes
ASEs implemented : mips16 dsp
VCED exceptions : not available
VCEI exceptions : not available


You can now begin to study the file system. Probably the script test.sh performs most of the work and runs two main processes:

Code:...
videocatch>/dev/null 2>&1 &
ipcamn>/dev/null 2>&1 &
...


If you stop one of these processes will stop the watchdog timer and the system restarts.
Look loaded kernel modules:

Code:# lsmod
Module Size Used by Tainted: P
usbvideo 56752 1 - Live 0xc0116000
watchdog 2064 1 - Live 0xc012d000
gpio 3968 3 - Live 0xc012b000
i2s 10688 3 - Live 0xc0140000
i2c 2816 0 - Live 0xc008a000
rt2860v2_sta 1319712 1 - Live 0xc0265000 (P)


For sound use the I2S interface, or UVC-usbvideo – cheap camera Alcor Micro Corp USB (058f:3861). The I2C interface is probably used to the stepper controller module gpio for input/output pins of system alerts and led display.

If to unload all the rows of the executable file videocatch, we get the following list:
__tps://gist.githubusercontent.com/JelmerT/699a6897741d47a4fdda/raw/a5599868aef1cf7afaf2b9d49e22ad0661b3ec84/strings_videocatch

From the list above we can see the process initialisere USB camera and somehow works with videos.
Unload all rows of the process ipcamn:

__tps://gist.githubusercontent.com/JelmerT/da0b5e2c242ba38f7ee7/raw/0e251c5a3022bc9f28fd8e47b5750487e3626f72/strings_ipcamn

Apparently, the process Ipcamn responsible for all other functions and interaction with external services.

At the moment we know the services to which the camera is connected and what ports are open. We were able to analyze the file ipcamn, but due to the presence of the superuser account, I don't want to do this now.

My current task is to block all traffic passing through the chamber (both incoming and outgoing), at the level of the router. In addition, I would like to make a video server based on the system motionEyeOS or ZoneMinder that will record, store and stream videos.

The ideal solution is to make a separate build of OpenWrt and load it into the camera. Of course, it is necessary to achieve efficiency on the basis of the Webcams and other USB devices input/output. In this case we have full control over the camera, and all the data. Since the firmware is OpenWRT and DD-WRT can transform cheap WiFi routers in a network equipment, the same distributions for IP cameras could transform this device into a cheap stable surveillance system. Distributions could be called, for example: CamWrt or OpenCamWrt or OpenCam. I'm not sure yet. This topic for a future post.
sigismund
moderators
Сообщений: 788
Депозит: 0 BTC

Rating: 5