heyrick1973 -at- yahoo -dot- co -dot uk

Silencing the webcam / IPCAM

Just for fun, I set up my XP box to do Internet connection sharing. I tweaked the camera's static IP address to match XP (192.168.0.1 vs the Livebox's 192.168.1.1). Then I booted the camera to check that I could ping the device, and it could ping Google's DNS. With all of that working first time, I fired up WireShark and rebooted the camera.

Oh boy.

Or maybe I should say:

Oh God.

 

I had set the camera to disable its built-in DDNS. The web interface seemed to be ignoring me, so I hacked the scripting and extracted the command to make it work:

http://192.168.1.20:8080/set_smarteye_factory_params.cgi?loginuse=NAME&loginpas=PASSWORD&se_ddns_enable=0

Turns out, by the way, that the HTML setup document would never show DDNS as unticked, as the script ticks the box if it is loaded in an unticked state. Lovely.

The DDNS, by the way, is used by the app to provide an easily-found camera. The address is xxxxxxx.nwsvr1.com. You might be wondering why I don't want to use the nwsvr1.com service when my own server is accessible via no-ip. Well, easy. What you know when you look at no-ip is that something is there. Usually it is my Pi. From time to time, it'll be my camera as well (it is only on when I punch a hole in the NAT to allow the world access).
What do you know about nwsvr1.com? They're IPCAMs, the same sort. All of them. A person with some spare time could figure out the pattern (it appears to be three digits counting from either 000 or 001 followed by four lower-case alphabet letters), and then just start looking through all of them. By my reckoning, 26*26*26*26 is 456,976. That's how many letter combinations exist, in total. Trying uppercase letters redirects to a lowercased version, so, yeah. Multiply that by 5 or 6, meaning you just need to try something in the region of 2.5 million fetches. All of the ones I've randomly typed into Firefox returned "OFFLINE". However you only need to spot a redirect to know you've hit a live camera. When you have, I wonder how many can be pwned by using the login name admin and the password admin? Better yet, if it's a horribly insecure router (or a stupid user) and port 23 is available - the login name is root and the password is 123456 and this cannot be changed!
So, yeah. Better not to scream "insecure camera here", don't you think?

 

So, in my gross naivety, I thought that maybe it wasn't going to be blathering my information around the place.

 

The transaction starts fairly normally. The device tries to find out who and where it is, and if its gateway/DNS is working. It then appears to send out a UPnP request (I turned that off too, so a good thing I also have it disabled at the Livebox end!).
Then KURONEKO (the XP box) sends an announcement of what it offers.
The camera then spams maybe two dozen malformed UDP packets saying "Hello, I'm online!" (seriously, that's the payload data) to 192.168.0.1 (the XP box) and also to 255.255.255.255.
Some more registration stuff takes place, and by now the camera is ready to talk to the outside world. The first thing it does is look for p2p1.mclview.com. While it is waiting on a reply, it bounces a STUN request off of 94.23.26.228 and 5.135.188.138 and 5.135.188.205. It would seem that "STUN" is a method of a device behind a NAT determining its outward-facing IP address. The device knows that it is 192.168.0.20 but it doesn't know what that means in global scope.
These servers appear to reply with a TFTP Write Request. I can only imagine that WireShark is misinterpreting this, as the destination file specifier are three bytes followed by the outside IP address bytes.
I guess spamming three servers is simpler than asking one and if it fails, trying another...
It seems that this process goes back and forth, now including the mclview server as well.
That done, the camera looks up www.nwsvr1.com and that done, performs an HTTP request for:

GET /api/userip.asp?username=XXX&userpwd=XXX&vertype=913&language=0&dtype=0&tcpport=8080&lanip=192.168.0.20&

Yup. Hardcoded password. I used that to specify a bogus port and LAN address for my camera. The Chinese (or whoever) will think my camera is on port 666.
But it gets worse.
MUCH WORSE.

Just as an experiment, I replaced the username field with a different sequence of numbers and letters.
The server replied "Update-OK".
Holy hell, who codes shit like that?
Excuse my Old Norse/Germanic there, but this is such a pile of fail I'm sure you uttered even worse words, likely of Middle Dutch origin. ☺

And, to test, I entered 001abcd.nwsvr1.com into my browser and looked at what came back:

Connection: Keep-Alive
Content-Encoding: gzip
Content-Length: 20
Content-Type: text/html
Date: Mon, 22 Aug 2016 19:22:21 GMT
Keep-Alive: timeout=20, max=100
Location: http://90.32.247.121:666
Server: Apache/2.2.22 (Ubuntu)
Vary: Accept-Encoding
x-powered-by: PHP/5.3.10-1ubuntu3.11

There you go. My IP address and a redirect to port 666.

Assuming there's no sort of rate limiting (and assuming not given that this nastiness works at all!), I wonder how long it would take for somebody to identify available cameras and redirect them. It might be non-trivial if the camera has a custom password, but if it is the admin/admin pair... whoa...

 

I won't go any further. We've seen enough. The device is really talkative, doing the STUN stuff about every 30 seconds. In the middle of this, XP blasts a load of SSDP notify packets at 239.255.255.250 to advertise its services.

Five minutes later, nwsvr1 is updated again. You know, just in case the IP address changed.

 

Thankfully my camera isn't quite as braindead as the ones that would happily provide the URI http://x.x.x.x//proc/kcore without any attempt at user authentication. If my camera did that, it would be straight back in its box and back to the supermarket before you could blink.

So, since we have something we could try playing with, time to rummage around inside. The directory /etc contains the password file (with the hardcoded root username), and some other configuration stuff.
There is no hosts file.

Easily sorted.

vi hosts
vi is less than friendly. You need to press 'i' to go to insert mode, to then type the following:
127.0.0.1 www.nwsvr1.com p2p1.mclview.com
Then press Enter, followed by Escape.
Back in command mode, type :w then press Enter to write the file to disc, and then :q and Enter once more to quit. Do it as two separate commands, it doesn't seem to like the :wq! syntax.

Reboot and...

Nothing.

What's worse, the /etc/hosts file was no longer there. Great. They must be dynamically recreating that directory from saved stuff.

Okay, so let's try something else. The folder that contains the camera initialisation script is /system/init with a script called ipcam.sh. As it happens, this folder is writeable. Sweet.

The hosts file is recreated there, and the ipcam script modified as follows:

export LD_LIBRARY_PATH=/system/system/lib:$LD_LIBRARY_PATH
export PATH=/system/system/bin:$PATH
telnetd
/system/system/bin/daemon.v5.5 &
/system/system/bin/cmd_thread &
/system/system/bin/gmail_thread &
cp /system/init/hosts /etc/hosts

Reboot and... it didn't work. Actually, it seems to have silenced p2p1.mclview.com as the camera was now looking for p2p2.mclview.com, but it didn't silence nwsvr1.com.

 

Okay then. Here's the sledgehammer approach. I really couldn't be bothered to work out where best to put the file copy so it would get noticed but wouldn't get deleted, so...

The /system/init/hosts file:

127.0.0.1 p2p1.mclview.com p2p2.mclview.com www.nwsvr1.com

And the sledge-ha-mmer ipcam.sh file:

export LD_LIBRARY_PATH=/system/system/lib:$LD_LIBRARY_PATH
export PATH=/system/system/bin:$PATH
cp /system/init/hosts /etc/hosts
telnetd
cp /system/init/hosts /etc/hosts
/system/system/bin/daemon.v5.5 &
cp /system/init/hosts /etc/hosts
/system/system/bin/cmd_thread &
cp /system/init/hosts /etc/hosts
/system/system/bin/gmail_thread &
cp /system/init/hosts /etc/hosts

 

Bingo!

The first two minutes of communications after boot contain a mere 65 transactions, which are: the standard setup and service discovery (including from XP), the STUN to determine the outward IP (to 94.23.26.228 - this address appears to be hardcoded), fetching the time from an NTP server (time.nist.gov), and... actually that's about it. We're about a hundred packets down on the first two minutes of the original boot. I consider this to be a good application of duct tape over the camera's mouth. ☺

 

Not tried, but, hmmm - I wonder if I could paste in a replacement passwd file using this method?

 

 

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

Rob, 23rd August 2016, 17:01
Some good detective work there!  
It's almost as if these things were thrown together with absolutely no thought to security at all..
Rick, 23rd August 2016, 20:58
That's probably EXACTLY what it was. After all, what domestic user that buys something like this from a supermarket is going to know diddly/squat about security? 
Sadly, that's probably true... 
 
I have examined the scripting for the "mobile view" option to see how it works. God - it sets up some Javascript to simply spam the get_snapshot function. So, yeah, it isn't even video, it's just a repeatedly updated still JPEG as fast as the network can push 'em over. 
On the other hand, ought to be able to throw together some code for RISC OS to do that... ;-) 
 
I'm going to go water the plants and listen to Nightwish. This stuff frazzles my poor little braincell. 
David Pilling, 31st August 2016, 18:40
It is interesting how the people making these have access to more powerful processors than does the hobbyist. Generally these pan and tile ip cams are a lot more expensive than yours, and this makes me wonder if yours is a fake. I recently bought some super cheap digital cameras off ebay, and they were fakes - full of electronics which kinda sorta worked, but was useless. Only good enough to convince you it worked long enough to buy it and get it home. A common situation amongst the people selling 'Rolex' watches on Blackpool's 'Golden Mile'. 
Rick, 31st August 2016, 19:11
To take your comments on reverse order - of course it is a "clone". I won't say fake as it does work, but it's really just a knock off FOSCAM. But then one could use similar logic to say the Pi is just an inferior Beagle, see? :-) 
 
To your first point, I don't think so. It's an ethernet/wifi chip with a MIPS core clocking something like 300MHz. This is the sort of spec I would expect to see in a budget bit of "smart" networking kit, like a WiFi repeater or the like. It runs Linux. Well, somebody figured they could hook a camera to the USB port, control a couple of motors from the GPIO, and the result is an inexpensive web camera. 
Remember, it is outputting MJPEG, not anything that requires actual processing grunt - and I'm not sure this device is up to that...

Add a comment (v0.08) [help?] . . . try the comment feed!
Your name
Your email (optional)
Validation Are you real? Please type 27659 backwards.
Your comment
Calendar
«   August 2016   »
MonTueWedThuFriSatSun
2467
89111214
15161718192021
232425262728
293031    

Japan - can you help?
Japanese Red Cross
日本 赤十字社

Earthquake relief donations have closed.

Read about the JRC
Make a general donation

Last 5 entries

List all b.log entries

Return to the site index

Search

Search Rick's b.log!

Etc...

Thank you:
  • Fred
  • Bernard
  • Michael
  • David

Last read at 21:28 on 2017/11/23.

QR code


Valid HTML 4.01 Transitional
Valid CSS
Valid RSS 2.0

 

© 2016 Rick Murray
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.

 

Have you noticed the watermarks on pictures?
Next entry - 2016/09/04
Return to top of page