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)

Ready your home network for IoT

July 2, 2016

I’ll keep reading about the whole Internet of Things (IoT) but something I see missing is the security aspect. Sure there are white papers and article out there how an enterprise should deploy IoT in a secure way, but not much for home and SOHO networks. In this blog post I’ll address the problems of current IoT devices and what you can do to mitigate them.  I’ll concentrate on typical IoT devices used/designed for home users.

Why the security of IoT devices sucks

Just remember one mantra – IoT devices suck at security – and here is the why.

• Many of these devices are build by Start-ups, which have one goal. Get the product out as fast as possible and get the company bought by someone and hit pay day. Even if not, they need to get enough revenue first and to start than fixing the security problems.
• If the device is not build by a Start-up than it got build by an established manufacturer in the area the IoT device is build for. The problem is the manufacturer has no idea about connected devices and that Internet stuff – Its called “Neuland” :-). They will make every error the IT industry did 10-15 years ago. Yes, if you’re that long in the business as I’m you’ll see the same security holes you saw in the first years of this millennium for normal PCs now for IoT devices.
• Usability and security is not easy .. so most of the time the easy to use and insecure variant is used
• If the IoT device is for a semi established area like IP cams / baby cams the devices are build and designed by a Chinese company and sold under various labels. The company selling the devices does not know anything about the internal workings. If a security problem is found and somehow the OEM vendor in China fixes the problem, you’ll wont get an update from the company that sold the devices.
• Automatic updates of the devices is not the norm, so most devices wont get any updates. While in the PC marked it is for years now common that  software get updates automatically, the same is not true for most IoT devices. And lets be honest who is checking for security updates of the light bulbs on a regular base?
• But before we can talk about automatic updates lets don’t forget that for most IoT devices you’ll get updates only for a short period of time. The vendor wants to sell his next product, so why support the old one? To make the problem bigger most IoT will get used longer than a typical mobile phone, which also suck at security update time frames. No one will replace his/her IP cam every 2 years like a mobile phone (ok, that’s also not true, but its typical a shorter interval)
• UPNP was a bad idea and still is one. Some IoT automatically open ports from the internet so any security flaw can be exploited directly from anywhere in the world. Oh, joy! 🙂
• Even if the device does not use UPNP it often connects per default directly to a cloud service, over which you (and potentially an attacker) can access your device. e.g. accessing the baby cam via the mobile phone app via and cloud service. There have been some horrible security flaws in the past, like a consecutively numbered ID without password or the MAC address of the device as ID (really heard the guess an MAC address if you know the vendor ID 😉 ).

There are some more points I could made, but these should be already depressing enough.

ps: yes, there are some IoT devices with good security but these are less than 5% of the total market.

Theoretical mitigating the problems

As we’ve established that the security is not good, we need ways to mitigate the problem, within the scope of a home network. To be honest that can’t be done by your typical mum, but needs some one technical minded – but others would not read my blog anyway.

Securing or hardening IoT devices is sometimes possible but for most consumer ones that won’t work. So lets accept that the device will have security problems. In some cases that will be a big problem in its own right, e.g. a IP cam that can be watched from anyone world wide. In other cases e.g. a light bulb that can be controlled from anyone world wide is more a nuisance that a real problem. The same is true for weather station that is readable world wide.

For the first case there is nothing that can be done on the network level as general rule, as disabling the Internet connection for the device will prevent it from working in the first place. Sure there are cases where the cloud connection is not needed, in these you can deactivate or block it. But for the second case there is something. Let’s assume the attacker got access to the IoT device, which is by itself in this example case not that bad, surely a nuisance but not a big problem. The problem arises now from the fact that the IoT device is controlled by the attacker and what he can do with that. So lets look at some possible scenarios.

• If the device is connected via WiFi the attacker has now the WPA2 PSK key from your WiFi.
• If the family NAS provides the shares without username/password an attacker can access it
• Maybe the router can be configured without a secure password or has also a weakness. The attacker can use this to change the DNS servers to allow MiTM attacks
• ARP spoofing and similar attack are also possible.

To guard against that attacks you need to segment the IoT network from your normal network, even better isolate the various IoT devices from each other.

Practical mitigation – three stupid routers

The segmentation can be achieved in various ways. The first one needs only standard routers …. just more than one … you need 3 routers. Lets take a look at the diagram:

The first router is often provided by the cable or telephone company and you need to buy 2 stupid/cheap routers behind it. One is for the normal internal network and one for the IoT devices that connect a cloud service. For the IoT device router configure the WiFi in client isolation mode (if possible). As both (internal and IoT) routers masquerade their clients a direct connection is not possible. If a connection should be possible a port forwarding needs to be enabled and also make sure that the IP subnets are different.  If one IoT devices gets compromised it can not leak the internal WiFi password as it does not have it. Also accessing the NAS is not possible as the ARP spoofing is not possible. Use the provider router for guest which should not be able to get anything except Internet.

The setup is quite simple and also cheap but has its short comings:

• Works only for apartments and small houses – if you need more than one access point for you’re house it does not work.
• You need multiple routers, which need more power.
• You lack flexibility

Practical mitigation – intelligent router / access points

If you move away from the typical stupid routers you can make use of the more advanced features. The exact setup depends on the used network devices, so I’ll can only show a possible setup. Following requirements need to be met by scenario setup.

• Three floors, each with its own access point
• IoT and internal devices in each flow, cable and wireless connect ones (multiple SSIDs on each access point)
• Clients want to move within the building without loosing connection (same SSIDs on all access points)

Just to make it clear, there are other setups possible to fulfill the requirements. Following diagram shows the possible setup.

The router or firewall (could be a router like a Mikrotik or a pfSense firewall) is the gateway for all 3 networks (yes, I through a guest network in for good measure 🙂 ). On it the policy which network is allowed to connect to which other network is configured. All three networks are connected to the managed switch (if the router has enough ports it may can fulfill the role of switch too).  On the switch most ports will be configured for one VLAN but the ports to the access points get all three VLANs.

The access points get configured in way that the management IP address is in the internal VLAN and a separate SSID is used for each VLAN. All access points use the same SSID for the same VLAN, so roaming for the clients is possible. Set the SSID for IoT and external use to client isolation mode (one wireless client can’t communicate with an other)

Optional, if the the switch supports it. Configure private VLANs for the IoT and external network, so only the router can talk with all devices

I hope this blog post shows you the basics for readying your home or maybe SOHO network for IoT devices which will surely come.