Rick's b.log - 2017/06/17
It is the 5th of May 2024 You are 18.118.150.80, pleased to meet you!

I broke my IPCAM but I don't care

So I was writing a tool to extract pictures from the 610AW - that's the tilt and turn camera, when I made an error and the GET request asked for the index page without the leading slash. The content was returned without any login prompting. So, knowing that the camera intelligently places important configuration information into the served "www" directory, so I asked for "/system.ini" and the server returned the expected 401 error as authentication was required. Next, I requested "system.ini" (no slash prefix) and...to my absolute horror, this is what I got back:

The key to the coloured highlight boxes:

• Blue is the camera's unique ID. With this, if you know the ID of the camera you can go to the website's DDNS and if the camera is running it'll provide you with the IP address and port of the camera.
  
• Green are the login usernames.
• Magenta are the login passwords.
• Cyan is the WiFi access point SSID and the WEP/WPA/WPA2 passcode.

So, guess what. This means that with only knowing the IP address and port of the camera (easy enough to scan for), a bit of custom code to send a malformed URL request it all it would take to extract the administration login and password.
In short, there's absolutely NO way that this device can be connected to the public Internet. At all. In any way.

So I thought, the simplest hack would be to change the name of the ini file and binary-hack the executable in order to point to the new filename. This doesn't fix the problem (and amusingly, this has been a long-standing flaw in the GoAhead server, it isn't something they broke when writing such deplorable firmware), but it is a way to obfuscate so that extracting the private information won't work unless the filename is known.

Only it didn't work. I don't know if the ftp transfer failed or if there's some sort of checksum in the executable. Either way, the device is currently "dead" as the big binary lump doesn't appear to want to load. I can revert back to the originals (they're on the filesystem), but while telnetd ought to be running (it is invoked before the other parts of the firmware), nothing at all is going to happen as the big firmware lump is what sets up the network hardware. So... yeah... with no connectivity there's no way to telnet in to fix the problem.
Oops.

☺

But, then, this is the part where I'm less bothered about the fact that the camera is now defunct. After all, what is the point of having a camera when it's basically an open door to your network.

Is it over? No - not by a long shot. There are four little holes on the RT5350 SOC board. A quick prod with my oscilloscope shows me something that looks like serial data. So some day when I've nothing else to do, I'll solder on some bits of paperclip so I can plug in a TTL to USB dongle and plug it into my PC. The serial datastream looked wider than before, so I'll try 57600bps first. With that, I can hopefully get directly into the system. Maybe the kernel log might give an idea of what went wrong? If not, so long as I can get to the filesystem to put the original files back.
The base Linux system is not upgradable at all, so that will all be okay and intact, it's just the problem of getting into the thing.

The other (HD) camera? Trying to look for a file, nothing unexpected happened, but then the HD camera is running lighttpd/1.4.35 and not GoAhead.

Otherwise... if the little tilt and turn camera is revived, I will need to keep the camera on the local network, and bounce requests through some code on my Pi to sanitise inputs in a way that should have been done on the device. This also shows the danger of never having firmware updates. It could have been quite possible to rebuild the firmware with a fixed version of GoAhead (or, at least, fixing the massively hacked version and rebuilding), but no. It's a camera that is built by the thousand, has a label slapped on it by a distributor, and then gets shovelled out the door...

Suffice to say, if you have one of these IP (VGA resolution) cameras:

I contacted MCL to ask about providing the GPL source code, as is required by the licence of the firmware in the devices that they sell. No reply. I don't expect one either as they likely don't touch the code at all, just some configuration hacks to make it an MCL camera instead of some other brand.
I also contacted them to ask about updated firmware because of the various issues that I had uncovered earlier. Guess what. No response.

Here's the product information page, and I just sent them this message:

Your comments:

Rob, 21st June 2017, 16:21

I've got all my IoT things on a completely separate VLAN these days. Hopefully that way they can't damage too much if things go wrong. It's a bit of a pain for those "apps to control your XX" that only scan the immediately visible subnet rather than allowing you to specify an IP, but for the times I need to do that, I can connect to the devices's wifi instead...

Rick, 17th August 2017, 01:17

Just to update you more, never had a reply to either message.  Now, a company releasing a device with GPL software on board, making no offer to provide source code, and ignoring a message asking for it...  ...that's surely a GPL violation?!?

David Boddie, 18th August 2017, 02:37

I've sometimes managed to get the kernel and busybox sources by telling the supplier that they are legally obliged to supply it, but that implies some two-way communication is already happening. I don't have a stake in the Linux kernel but I wish those running the project would stop pussyfooting around companies like this and just start chasing them down for copyright infringement. It's not like the OS needs more mindshare; insecure products like this one are just harming its reputation at this point.