Backdoor in DVR firmware sends CCTV camera snapshots to email address in China | Hacker News Reader

Backdoor in DVR firmware sends CCTV camera snapshots to email address in China

pentestpartners.com

188 pointscampuscodi52 comments

Someone with the same name has some chinese CCTV apps on the Apple appstore, one updated 5 days ago: https://itunes.apple.com/us/app/ipctester/id870933100

And on Google Playstore https://play.google.com/store/apps/details?id=com.juanvision...

Do they also contain backdoors? Domain and email used: www.dvr163.com caostorm@163.com Screenshots in the app come from this site: http://www.juancctv.com/jishu.asp

I would love to see a documentary / an interview of the developer (team?) behind these Chinese crappy products. Are they really that incompetent or is it just totally different culture?

I mean, after all they are capable of bundling the all FOSS together, writing some code by their own, and even shipping a working product, but they don't realize that running commands as root from query string is horrible idea? That's hard to buy.

Maybe the culture is "get it done now" with no care for security and the managers may be ignoring the engineers.

I use a bunch of cheap ip cameras of various brands: foscam, crenova, etc. They all have telnet backdoors, which is actually pretty convenient for me.

I keep mine on a separate lan which can't connect to the internet or the other more-trusted lan. The average grandpa connecting these things to the internet is screwed though.

That's essentially where I am. I actually want a simple camera with options for standard format streams over IP so I can connect them to a NAS on its own LAN, hidden in a closet for a cheap security setup using hardware I already own.

But so many of these things are pitched as "oh so easy to set up! Just plug it in and open an app on your iPhone and you can monitor your house from anywhere!"

It's bad enough that this app-centric branding/marketing pitch ignores the fact that you never even see the popup saying "for security purposes, change your password", much less mentions just how this easy access works.

Sure, it's easier to just plug something in and get a picture with no more action needed than pointing at a square on a screen. But even the ones that can be made moderately secure (at least versus casual Shodan searchers and Google dorks) by setting a password and turning off DDNS, telnet, ftp, etc. are often left in their wide-open setup state by users.

On the flip side, I don't want something that only works with a "cloud" subscription or by going through a third party that I may or may not have to pay for monthly. I just want to be able to pull an mp4 or mjpeg stream from an old computer running iSpy or my Synology on the local-only LAN.

tl;dr: these things are affordable and very useful if you know how to set them up but by default they're wide open and often irresponsibly marketed as plug-and-play and never actually configured.

I knew a guy who spent an internship after his first year of university at some such place in China. He said he told them the PSU design was no good (dangerously ungood), proposed part substitutions were invalid, but nobody cared.

It's just ~~desire~~ mandate to "ship it cheap", and no desire or care at all. He didn't go back.

That sounds horrific.

This code seems related - it has the cow ascii art and the email-sending functionality and email address mentioned in the article: https://github.com/simonjiuan/ipc/blob/master/src/cgi_misc.c - I wonder what else is in there!

Good find. Wow, that repo is a class act. Binaries checked in and everything. Clearly looks like this and the OP's DVR share lineage.

From what I can tell, the e-mail address etc. are defaults used in CGI_send_email, which is only invoked as the handler for the /email endpoint. Looking at the order of endpoints defined in https://github.com/simonjiuan/ipc/blob/master/src/ipcam_netw... it seems that /email was probably left out in the DVR's code, so it's possible this function is simply never invoked, and we're just left with the WTF that not only did the original author (Mr. Law) think that an e-mail service needed a default "To", but that he thought it should be him, and that he left it in the final product.

Yeah, it wasn't at all clear to me from 2 minutes of static analysis under what circumstances an email would be sent and to which address. I'd hope the authors of the linked article would have verified this with a packet sniffer (as mentioned in another comment here) before making the claim.

Sorry, should have been more clear.

Yes, it does send the emails.

Good find.

And according to that source, you can change that target email address via a request parameter.

I surely hope that somebody can figure out how to make firmware images for these, and use this code as a base to fix these flaws. A kind DD-DVR project, if you would.

Just got deleted. Anyone has mirror?

Yes. http://archive.is/HUW8c

Thanks, I found another repo here: https://github.com/zackxue/ipc

They don't say whether they actually caught the DVR in the act of e-mailing frames. A simple Wireshark trace could reveal the difference between malintent and some dumb vestigial debugging code.

Actually, from a brief scan of a related codebase, it's likely that it doesn't send e-mails. The title of the article is therefore at a minimum unsubstantiated.

I'm the author.

My device sends an email at boot to the email address, and it has also been triggered at other times - I am not sure why.

It looks like there are a number of variants of the device out there.

The repo mentioned in another comment has a MakeFile for another device, and has been forked 9 times. It could be used anywhere.

The article will be updated, but I'll have to get a trace another time.

Someone else who has looked at them has pointed out that theirs reboots randomly. I haven't actually been using the DVR functionality, so I suspect that the emails are only sent at boot and it boots more often than I expected.

"Visiting moo shows us a curious image of a cow."

That image isn't so curious. Try 'apt-get moo' on any debian based box.

Thanks, updated the post.

Very interesting talk at Blackhat about the numerous security vulnerabilities CCTV cameras have such as hard coded master passwords in firmware: https://www.youtube.com/watch?v=LaI0xjeefpg

I have one of those. Root password is "juantech". Did not know about the shell, how useful! The telnet daemon crashed quickly on mine last time I played with it.

... :-/

Fortunately, I disconnected it from the network a long time ago. Works well standalone, the UI is ok.

Yeah, I tried juantech. Not the password, unfortunately.

openssl passwd -salt a0 juantech a0hDjN2cjQ1hI

I've bruteforced all alphanumeric for the descrypt hash, and not found anything. Trying the whole space now, but it will be weeks.

I think mine was regularly rebooting, but I've put it away so need to check.

Are there any DVRs in the consumer space that aren't terrible? I bought a Dahua based on some recommendations, but in the end am disappointed.

Blue Iris and IP cameras, you'll never look back.

I've always been a fan of iSpy (https://www.ispyconnect.com/) and still occasionally mess with it even though my couple of cheapo cameras (a Foscam and a Dahua) now just record on motion to my Synology NAS.

I think I messed with Blue Iris when I was initially playing with using an old laptop as an IP cam DVR but never bought it after the trial expired.

Looks like to get the most out of iSpy you need a subscription, starting at $8 per month and going up to $50 per month, sorry no thanks. Blue Iris is a one time fee, I get SMS and email alerts included. I don't like paying subscriptions for things that I'm hosting myself.

Sorry for the late reply. I never used any of the "pro" options so I guess it never came up for me. It's like Plex in that regard, at least how I personally use it. I just use iSpy as a free, flexible program I can run on an old computer, attach it to the same LAN as the IP cameras, and set it up for motion detection, recording, and storage/archive.

I definitely agree that if you want some or all of the "premium" features, a one time purchase is the only option. I don't like recurring subscriptions and avoid them when possible. I guess in this case, since you're paying for functionality on their servers it makes sense to pay as you use it. Still, as an end user, I do avoid subscriptions if I can.

Good to know you've got a better option though. Anything that allows you to self-host this stuff (mostly at least) is a positive thing IMO. In my early experiments before moving to the Synology software on my NAS, I had the computer running iSpy save to the Dropbox folder on that computer and limited the archive size to match the capacity of that Dropbox account. That way I could at least access recordings from elsewhere but I never got into email or SMS alerts. Not sure how I'd personally set that up.

I've already invested in the cameras and the cable runs, and I'd rather avoid Windows (although I see I can add a capture card to support my cameras.)

Any other suggestions?

Neo: Who are you? The Architect: I am the Frank Law, the architect. I created the Matrix. I've been waiting for you.

---

Someone please go arrest this voyeur before he deletes the evidence.

If he was some low level engineer i would perceive this as unintentional. That's not the case. Unless the title "chief software engineer" means something else in China... https://www.linkedin.com/in/frank-law-2b14b790

From my sleuthing experience, deleting things [the github repository] usually means some kind of wrongdoing; not necessarily related to the erased.

It is my belief this was intentional.

I can't figure out whether this is malicious intent or just incompetency. Regardless, we really need consumer protections for software flaws.

If you can come up with a non-malicious intent scenario why the images from the first camera would be mailed to some address I'll be most impressed.

Debug code that was never removed?

Yep. A manual, end-to-end smoke test of the firmware: Put the new software image some hardware, turn it on and wait for an email. If you get a correctly-formed picture of your own face, that's a pass.

It's a dirty dangerous hack even for a debug scenario, but you can see how it might come about

Unlikely, after all the mistake would have been discovered by now and an updated firmware would be shipped. After all, that email address is still active and is still receiving those images.

Easy, just borrow a little PR for Windows 10 privacy concerns. "Mvpower 8 Channel Security DVR collects information so the product will work better for you."

The Amazon link presented in the article has no reviews of this product that explain what it does. If anyone decides to buy one to play with, it'd be good to leave a warning to others about this sort of behavior. The product does not appear to be available in the US for whatever reason.

http://www.amazon.co.uk/dp/B0162AQCO4

(Link has been shortened to use only the ASIN.)

Author here.

I submitted a review but it has yet to be approved.

It has been approved but the exploit link and link to the blog post are not in it.

https://www.amazon.co.uk/review/R20SLCJIPN9UDB/ref=pe_157228...

Thank you. I can't seem to comment on .co.uk as my account is on .com, or I'd mark it helpful.

lawishere@yeah.com

yeah.com is early free hosting and email provider in China.

maybe the same person with an avatar http://tieba.baidu.com/home/main?un=lawishere

maybe his blog http://blog.csdn.net/lawishere

lots of C/C++, mpeg, streaming stuff.

A few other passwords too https://github.com/simonjiuan/ipc/blob/master/src/cgi_misc.c...

More info:

On Google Play, https://play.google.com/store/apps/developer?id=Frank+Law

The developer email is the same.

By the nicknames combine(lawishere and Frank Law), this maybe his Github page, https://github.com/lawishere

Yes - his GitHub actually had the repo for this in the past.

Someone reported the issue on there before I found it.

I wonder if a project to build an open replacement firmware for DVRs, along the lines of OpenWRT, would gain traction.

Possibly.

Part of the problem though is that there is not a full toolchain. You could replace the DVR app, but the OS is still going to be crap.

I had a very quick go at updating the firmware with Juantech and it failed. There is some check in place to prevent this.

I did one openwrt-based CCTV for a client, it's certainly possible, this one seems using hisilicon chips.

I'm thinking about what we can do about the flood of hideously insecure embedded devices. I wonder if there are industry standard, consumer-visible product security certifications?

the Esee Cloud Android App seems to be developed by the one who own the email address in the article: https://play.google.com/store/apps/details?id=com.juanvision...

Yes, the device has reference to Esee and IIRC it sends XML data to their server.

I didn't look into that as the other stuff meant it was game over.

In 2001 I wrote a 10,000 word series of articles for the physical security industry on emerging computer-based threats. Apparently they didn't read them.

the github code has been removed, that's fast.

This post could be titled:

"Backdoor in DVR firmware sends CCTV camera snapshots to email address in China"

"Backdoor in DVR firmware sends CCTV camera snapshots to email address"

Notice the difference?

Reply on news.ycombinator.com