Hacking the IP camera (part 1)

In recent months my family’s shopping habits have changed, no longer do we mostly go to the big supermarkets, instead we go to the discount dealers.

My better half assumes that this is to economise on the basics but in reality it’s because I’m addicted to browsing through the piles of tat that they sell.

Most of this tat is indeed utter rubbish and ends up getting binned, but occasionally there’s something worth hacking about with.

In this case I was in the local Aldi, and while trying to prevent my kids eating each other due to boredom I came across a Maginon Vision “security” camera.

It boasts outdoor design, wireless connectivity, infra-red mode, cloud access, and mobile app control. All of this functionality comes at a semi-decent price too.

What could I do, other than buy it, and rip it apart?

The camera unit

The unit uses Power over Ethernet (PoE) to provide power and access to the Ethernet front end. It has a wireless connection too. Later testing showed that only one of these interfaces can be used at a time, and that the wireless interface takes priority. Strangely enough if you disable the wireless interface it will copy that IP address to the Ethernet one.

The Ethernet address assigns itself a static IP of 192.168.1.129 which we can portscan:

Interesting titbits; telnet, http and what is that on port 8600/tcp? As it’s a camera it’s likely that the errant port is some flavour of video stream.

The http port leads us to the management front end. Nothing exciting there. Interestingly enough it uses basic HTTP authentication (i.e. the base 64 encoded username and password are passed with each request) to authenticate the user. This isn’t very secure, but it does make it easy to handle. There is also no SSL option to encrypt the management traffic.

The telnet port gives a prompt for credentials, but the default credentials (admin and no password) don’t work so it’s likely that the user isn’t meant to use telnet.

Getting into the camera

Right, so we’re in a situation where we have the camera, some dodgy ports and a default administrator password on a web interface. A quick web search on “8600/tcp camera” brings up a couple of interesting results for similar cameras:

• http://www.drolez.com/blog/?category=Hardware&post=jw0004-webcam
• http://liken.otsoa.net/blog/?x=entry:entry140322-183809
• http://www.asecuritysite.com/subjects/chapter33

These are substantially different cameras from other manufacturers, but all show a similar profile to the one I bought. There’s one way to check this; they all found out the root password for the device as “123456”. Now let’s try it out. Note: This is now running on my wireless network to make it more convenient for me, hence the IP address change:

Well, that was easier than expected! So I’m going to back track and work this out from first principles, by going for the firmware.

The firmware

Searching the various sites referenced in the camera’s documentation gave up nothing about the firmware for this specific device, although I did find firmware for similar models. While abusing “similar” firmware can give you hints about what utilities are installed it’s best to get the specific firmware.

In the end I found the firmware in a most unusual place: In the app that came on a CD with the camera. Yep, physical media, how quaint!:

There appear to be two separate areas:

1. sys_supra – the system firmware itself, which contains the operating system
2. web_supra – the files for the web front end. These have probably been separated out to allow easy customisation and branding of the interface

So, let’s throw one of these into a hex editor. The format is kind of familiar to me, but I’ve colour coded some of it for clarity:

The value highlighted in green (0x50, 0x46, 0x03, 0x04; i.e. “PK”) is the pattern for a zip file. The rest of the following structure adheres to this pattern (e.g. the filename highlighted in orange).

The 32 bit value in blue, taken as a little endian integer is 0x0009bc8e, is 638094. This is close enough to the file size to be a pointer for the files content:

The means the stuff in red is most likely just a header. The “wifi-camera-sys-get” is obvious, but the rest of it is unknown.

But what does this really mean? It means we can extract the firmware by simply chopping off the red and blue bits from the front of the file. I used dd for this to skip the first 36 bytes:

…and now we have a decompressed version of the firmware! We can’t find an obvious /etc/passwd file, but if we grep for the word passwd, then we can find it in the binary file system/bin/daemon.v5.7:

It’s possible that it creates the file on initialisation, so let’s just strings that file to dump all things that look sort of stringy:

Oh look, that’s exactly what it does. It creates the passwd file on the fly. This has a side effect that it may not be possible to change the root password. This means that it’s always vulnerable to exploitation to anybody on the same network. Fail.

For completeness, let’s just throw the passwd file into John the Ripper (as I don’t have hashcat installed on that VM):

The web firmware

Now we’ve cracked open the system firmware, the next step is the web firmware. Chopping off the header gives us a valid zip file, but it appears to be password protected:

Of course if it is protected then the password will be stored somewhere so that it can be extracted in the first place. The best place to look for this is in the system firmware, passed as a parameter to the unzip command. Time to break out grep once more:

Oh look, system/bin/daemon.v5.7 again. Let’s strings it and grep for unzip:

That looks quite passwordy to me so let’s unzip it:

There. We now have the decompressed web files, the system files and root access to the device! In my next post I’ll turn my attention to the cloud features of the device.