HiKam A7 – IoT security at its worst [Update]

July 8, 2016

[Update]

I’ll reached out to the company which got back to me today and told me that they are working on fixes for the problems. I’ve also changed my cam from wired to wireless mode today and the app sent the wpa2 password via UDP to the Internet in the clear – I’m glad I used a separate SSID and password for this ;-). I also reported that info to the company.

[/Update]

In my last blog post I’ve written about IoT devices and their bad security and what you can do to mitigate that on a network level – what I didn’t know that I would have such a device in my hands only days later.I did get my hands on a HiKam A7 IP cam, which is at the German Amazon Store the number one product for surveillance cams – so not a nobody. At the end I’ll found 5+ security problems in 2 hours looking at it, but keep on reading for the details. 🙂

As first act I’ve installed the app you need for configuring the cam in the first place. At first start you need to create a user, which should/must be unique per mobile / tablet. Looking at the network traffic I saw a HTTP request to api4.cloud-links.net and guess what was the content of that POST request?

Yes, that seems to be the user name and password in an effort to check if the username is already taken. The Pwd parameter is 32 chars long and looks like hex …. that couldn’t be MD5? Lets ask crackstation.net

Yes! Sure its unsalted MD5 and the password matches. So here are the first 2 security related errors … no HTTPS and than unsalted MD5 over an Internet connection. Something funny – you need to enter the password twice to guard against typing errors … both values are send to the server in the clear …. why not compare them on the client and send the request only if they match? of course also via HTTP and not HTTPS

So the account is also created with an MD5 password – which leads to the third security related problem …. customer passwords are stored as unsalted MD5 in the database … for years now we should know that that’s bad.

Ok, we got an UserID and soon after the app starts sending UDP packets to Chinese server (cloudlinks.cn) … let’s convert the UserID to hex, maybe we find it again

and of course we find it again in the UDP packets

So the userID is also send in the clear every few seconds and is only a 32bit integer … not hard to guess for an attacker – third security related error. So this userID seems to be something important, lets call that registration function multiple times with curl and look at the answers.

{"error_code":"0","UserID":"-2144083657","P2PVerifyCode1":"999048728","P2PVerifyCode2":"1551418556","DomainList":""} {"error_code":"0","UserID":"-2144083654","P2PVerifyCode1":"76169185","P2PVerifyCode2":"196029599","DomainList":""} one minute wait {"error_code":"0","UserID":"-2144083636","P2PVerifyCode1":"1008452257","P2PVerifyCode2":"1056609345","DomainList":""} {"error_code":"0","UserID":"-2144083633","P2PVerifyCode1":"836153359","P2PVerifyCode2":"494065857","DomainList":""}

Oh yeah, the UserID are assigned sequentially for each registration and provided to the user and used later by the client …. not a good idea .. lets call it fourth security related error

So lets stop looking at the app and take a quick look at the cam it self …. first a nmap scan:

PORT STATE SERVICE VERSION 554/tcp open rtsp? 5000/tcp open soap gSOAP soap 2.8 MAC Address: 4A:81:49:xx:xx:xx (Unknown) Device type: general purpose Running: Linux 2.6.X|3.X OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3 OS details: Linux 2.6.32 - 3.2 Network Distance: 1 hop

hm … RTSP ….. let’s take a look with VLC to check if there is a username/password required

vlc rtsp://xxx.xxx.xxx.xxx:554/onvif1

Of course there is no password required, everyone in the same network or who is able to connect port 554 can look at the video (There is no option in the app to configure a RTSP password). So the next security problem is that there is no authentication required at all for RTSP, fifth security problem. As my router has UPNP disabled I did’t check if the cam would open port 554 on the router.

Interesting, I could not find the MAC vendor – even online. Anyway looking at the traffic the cam sends to the Internet, it seems to talk at once after booting to the same UDP port the app does – even the same IP address, but an other DNS name.

a look at the UDP packet shows that the device ID (printed on the cam) in hex is at the same place of the packet as the UserID is:

I could find an authentication between the cam and the cloud servers …. but maybe I missed something … but as I’m not 100% sure I’ll won’t count it. 😉

Ah there is also a button in the app for a firmware update of the cam …… and of course its HTTP and not HTTPS …. easy code inject? I couldn’t find a signature for the file to protect against it, but I didn’t try it so I’ll also don’t count it.

Here is the link to the firmware file, I couldn’t resist an fast check of the file:

$ binwalk npcupg_13.00.00.90.bin DECIMAL HEX DESCRIPTION ------------------------------------------------------------------------------------------------------- 32 0x20 JFFS2 filesystem, little endian 2998728 0x2DC1C8 ELF 32-bit LSB executable, ARM, version 1 (SYSV) 3002209 0x2DCF61 LZMA compressed data, properties: 0x03, dictionary size: 524288 bytes, uncompressed size: 196608 bytes

so lets take a look at the filesystem by mounting the jffs2 file system in RAM.

# modprobe mtdram total_size=32768 erase_size=256 # modprobe mtdblock # dd if=20.jffs2 of=/dev/mtdblock0 5869+1 records in 5869+1 records out 3005295 bytes (3,0 MB) copied, 0,026426 s, 114 MB/s # mount -t jffs2 /dev/mtdblock0 /mnt/

but that’s for an other time …. the blog post is already really loooooong. There seem to be much more possibilities to hack that cam. It even seems possible to access cam from others, as the authentication is only based on one or two 32bit values. But looking at that more deeply would take more than 2 hours (without writting this post itself)

In IT Security | 31 Comments

31 Comments »

RSS feed for comments on this post. TrackBack URI

Thanks for your nice article – thinking about buying an INSTAR IN-5907HD IP Camera.

The documentation seems ok – no cloud services and upnp crap can be disabled.

maybe worth to take a closer look,

regards
Michael

Comment by Michael — July 12, 2016 #
hi robert!

nice blog post.

I don’t see why assigning the UserID sequentially is ‘not a good idea’.
With proper authentication there is no need to keep it secret (like for example e-mail address is public, but passwords for these mailboxes are not).

IoT will bring us some ‘funny’ times…

thanks for the nice read, regards
Daniel

Comment by Daniel — July 13, 2016 #
Hi Daniel,

The problem with sequential IDs is that I couldn’t see enough data in the UDP packages, which could provide a strong authentication. The data part is 28 bytes long. 4 bytes User ID, 4 bytes command, lets say 4 byte crc32 checksum (as udp doesn’t have it integrated) .. leaves 16 bytes where most bytes change for every packet (on retransmit if a server does not answer) …

Comment by robert — July 13, 2016 #
klasse Beitrag! Security wird in diesem preissegment einfach ausgeblendet.
d.h Port 51700 am internetrouter blocken um die internetkommunikation und einen beliebigen Zugriff von außen auf die Kamera zu verhindern?. und dann über onif im internen lan betreiben oder gibt es noch mehrere Ports um das nachhause telefonieren, mit inklusive unverschlüsselter wlan Passwörter Verbreitung, zu unterbinden?

Comment by kay — July 24, 2016 #
I would block all traffic from that IP address to the internet or block traffic from the MAC address to the internet if the router/firewall has an interface in that subnet.

Comment by robert — July 24, 2016 #
I did the same security research you did, but for another camera called “Camnoopy 720p“, also available on Amazon: https://www.amazon.com/Wireless-Camnoopy-Monitor-Security-Surveillance/product-reviews/B01GLAU944

I came across your site before while checking if someone else already wrote about my findings – and there you were.

This Camnoopy camera is sending exactly the same requests with exactly the same payload to exactly the same servers.
See http://api3.cloud-links.net/Users .

I think it’s time to have a FOSS camera firmware running on these creepy insecure things, or at least have some laws against that.

Comment by Andreas — October 1, 2016 #
The same goes for Mini Diva cameras like this https://www.amazon.de/dp/B01GZLSI1K/ref=cm_sw_r_cp_apa_o2Q-xbY1GVQJ4

Comment by Andreas — October 9, 2016 #
Even worse: My EBELL ATZ-DBV003P (IP doorbell) uses same p2p method. So a “hacker” could even enter my house, much worse than just view the pic.
I will have to block internet traffic at all from/to this device and create my own server to use the bell. Unfortunately almost nothing works without internet…

Comment by Riogrande75 — November 8, 2016 #
Crear article

Firmware file link is down (404). Do you have a backup?

Comment by Yago — December 27, 2016 #
*Great

Comment by Yago — December 27, 2016 #
Hi again!
I am working an reverse engingeering the protocol. Robert, it seems that you have made already some progress with the curl authentication.
Can you pls. send me your script(s) you developed so far?
Thx,
Rio

Comment by Riogrande75 — January 4, 2017 #
The link for the actual FW is:
http://upg.cloudlinks.cn/upg/13/00/npcupg_13.00.00.99.bin

Comment by Riogrande75 — January 4, 2017 #
I have also find similar traffic and behavior for a cam with the brand Yoosee.

I am also investigating the thing. Does someone have more information or is there an other blogpost about the same subject? it is hard to find more information about this subject. It looks like they are targeting on the German market isn’t it? Could it be government related?

Comment by anonymous — January 4, 2017 #
How do you think it’s targeting the german market?
I am working on decoding the camera’s (in my case a doorbell) udp messages.
Here are my
1. DNS querys for p2px.cloudlink.cn and p2px.cloud-link.net servers
2. query IP’s for the login server (udp port 51770). This messages is almost decoded.
3. With the reply (UDP msg. with about 10-12 IP’s), the cam sets up traffic on udp port 51880 to this IP’s (not so far yet).
Any help is appreciated!

Comment by riogrande75 — January 5, 2017 #
Hi Riogrande75, please send your contact details on [email protected].I think we can exchange some valuable info with each other.

Comment by anonymous — January 5, 2017 #
I just found another site, where some russian guys are working on this kind of cam too: https://goo.gl/l1OFps

Comment by riogrande75 — January 6, 2017 #
@riogrande75: If you can decode the UDP messages, can you contact me via Email? The authentication for all the UDP message looks at the first glance problematic.

Comment by robert — January 6, 2017 #
[…] articles in this blog about IoT (often called Internet of Targets ) where about a specific cam or about IoT at home. This article series will be different, it will focus on the IoT in companies. […]

Pingback by Implementing IoT securely in your company – Part 1 | Robert Penz Blog — January 6, 2017 #
Thx i already found the Russian site :). I did some sniffing but the UDP messages are encrypted. if we can crack the firmware there must be a way to get the encryption keys isn’t it?

Comment by anonymous — January 6, 2017 #
No. My analysis so far shows, that the UDP messages are not fully encrypted. I am already aware of some parts of the message, but not all 🙁
Work in progress.

Comment by riogrande75 — January 8, 2017 #
Thats correct, you see this already in the original post as at least the userid is send in the clear

Comment by robert — January 8, 2017 #
For all interested users: with the IPC debug tool (http://www.gwell.cc/e/DownSys/GetDown?classid=40&id=16&pathid=0), we might be able to get forward. It’s a windows tool to communicate with the cam/bell. Unfortunately it’s in chinese only, but I managed it to translate it. I can provide the translation if requested.

Comment by Riogrande75 — January 9, 2017 #
Please send me the translation.
This camera is producing similar network traffic: http://www.ebay.com/itm/172327831374

Comment by Cro — January 23, 2017 #
Thanks for your efforts in documenting – Can these defects allow people into my network or other network devices?

Comment by RichyD — April 11, 2017 #
potentially yes. Also the security of the authentication for seeing the camera video is in doubt – so I would not film sensitive stuff.

Comment by robert — April 11, 2017 #
Do you have any news about Hikam?

Comment by M — June 8, 2017 #
No, now news and I believe there will be none.

Comment by robert — June 12, 2017 #
Hi!
Just because a lot a poeple run into this site: I am able to access my IP-Doorbell using UART. I have full access to the running linux, even able to boot other stuff due to open u-boot bootloader.
Tryin now to crosscompile a little program, that makes the device usable in my LAN without cloud.

Comment by riogrande75 — July 7, 2017 #
I crawled some universal firmwares which are also used by Camnoopy:
Download here (90MB) https://file.io/weIRG3

The archive contains the following versions:

npcupg_00.00.00.50.bin
npcupg_11.00.00.16.bin
npcupg_12.00.00.13.bin
npcupg_13.00.00.54.bin
npcupg_13.00.00.83.bin
npcupg_13.00.00.90.bin
npcupg_13.00.00.92.bin
npcupg_13.00.00.94.bin
npcupg_13.00.00.95.bin
npcupg_13.00.00.96.bin
npcupg_13.00.00.98.bin
npcupg_14.00.00.00.bin
npcupg_14.00.00.33.bin
npcupg_14.00.00.35.bin
npcupg_14.00.00.40.bin
npcupg_14.00.00.47.bin
npcupg_14.00.00.49.bin
npcupg_14.00.00.50.bin
npcupg_14.00.00.52.bin
npcupg_14.00.00.53.bin
npcupg_14.00.00.54.bin
npcupg_14.00.00.55.bin
npcupg_14.00.00.57.bin
npcupg_14.00.00.62.bin
npcupg_14.00.00.64.bin
npcupg_14.00.00.65.bin
npcupg_14.00.00.66.bin
npcupg_14.00.00.67.bin
npcupg_14.00.00.68.bin
npcupg_14.00.00.69.bin
npcupg_14.00.00.72.bin
npcupg_14.00.00.73.bin
npcupg_16.00.00.08.bin
npcupg_17.00.00.06.bin

Comment by Andreas — September 10, 2017 #
Andreas, can you re-upload the 90mb of firmware files? Thank you!

Comment by Sander — November 6, 2017 #
Thanks, self tested and send the camera back to amazon 😀

Comment by Daniel — January 2, 2020 #

HiKam A7 – IoT security at its worst [Update]

31 Comments »

Leave a comment