Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Warning to Users of NurseryCam

cybergibbons.com

Post reply on HN
Print view View original

51–60 of 75 posts

Re: A Warning to Users of NurseryCam

#51

Post by duskwuff »

Limb wrote: post #12
KaiserPro wrote: post #2

The whole saga is just utterly insane. Its the same people who shipped the "people counting" raspberry pi system with the bruno mars mp3s in them. First they try and report the security consultants to the police, then they claim that they are too expensive to work with. Then even more bizarrely they launch a halfarsed sock puppet campaign using the CEO's wife's account. Then they start publishing reviews on their own…

Wow the thread about the raspberry pi system was a wild ride. For anyone else who wants to give it a read: https://twitter.com/OverSoftNL/status/1357296455615197184

Reading about FootfallCam, I can't shake the feeling that someone gave the project to a single, heavily inexperienced developer, the developer quit, and the manufacturer shipped the contents of that developer's home directory, as-is, as the final product. And the marketing was written before the product was developed, based on what they wanted the product to do, rather than what it actually did.

Re: A Warning to Users of NurseryCam

#52

Post by exikyut »

Sooo, getting Java in Firefox working has completely taken the wind out of my sails and I am VERY bored now, but suffice it to say that

- I image-searched "nurserycam dvr" and immediately found a video, from NurseryCam itself, showing how to reboot the DVR

- I also found a PDF with some "HDD reset" instructions and noticed the PDF had a closeup of the control panel buttons

- Googling the button labels from found me some extremely hazy model info - your standard "but which manufacturer?!" fare, it seems to be around the midpoint of "full AliExpress" at one end and actual reputability at the other

- After image-searching " web interface" I stumble on a screenshot of a directory service that registers DVRs via DNS and gives them a domain

- "site:*." found a few results

- visit one of them, open devtools, and yes, there's a unique Server: string

Then it was your standard

- how to into applet in 2021? oh, FF 52.0 ESR, ok

- download java 8

- find random website with java 8 .tar.gz because Oracle

- unpack java 8, create symlink, yay!

- security exception. oh.

- replace with java 7

- [A LONG TIME LATER] ohhhh, firefox updated itself and that's why everything looks wrong and the plugin stopped working

- okay let's go through shoda... actually you know what this is really boring.

TL;DR: it look about 3 hours to install Java and about 25 minutes to figure out what brand of DVR this company is using. Security through... ADHD incompatibility, anybody?

Re: A Warning to Users of NurseryCam

#54

Post by thayne »

stefan_ wrote: post #44
Wowfunhappy wrote: post #40

Earlier quoted context omitted.

Putting aside all of NurseryCam's other security issues for a moment, I do think using http is reasonable under the circumstances, perhaps with an option to enable https via a self-signed cert (or a user-provided cert) for advanced users. This is the approach taken by basically every router.

HTTP is an unhappy medium, just like an Open WiFi: we could have perfect forward secrecy encryption alone, but instead we have to choose between "no encryption, no authentication" and "encryption and authentication". Now we would still like both of course but as the GP correctly states, Google et al have no interest in any of that. They are much better off when both the device and the app just connect to the vendor c…

https without certificate verification still leaves you vulnerable to MITM, as long as the attacker can intercept, and manipulate, the session negotiation. However, I do think there is value in a trust-on-first-use (TOFU) model for trusting self-signed certificates. The biggest challenge is how to educate users on when it would be appropriate to accept the risks of TOFU.

Re: A Warning to Users of NurseryCam

#55

Post by thayne »

mleonhard wrote: post #30

> To make matters worse, the connection to the DVR is using HTTP, not HTTPS. It is unencrypted, allowing someone to eavesdrop on the video feed, username, and password. What is the proper way to provide certificates to devices with embedded servers? - Generate a self-signed certificate with the appropriate IP address and train users to bypass the browser's scary warnings? - Buy certificates for every deployed device.…

Another option is you could use dynamic DNS on subdomains you control for the devices, then use ACME to provision certificates for those subdomains, and then have the DVR devices fetch the certificate for itself over a secure and authenticated channel.

> The device must be publicly accessible so the ACME server can reach it.

My understanding is that these devices are publicly accessible so that parents can access the DVR without being on the local network.

Re: A Warning to Users of NurseryCam

#56

Post by Rainymood »

(Tried to re-write your intro article a bit for ... you know ... a non-technical audience.)

# Summary

Let me get straight to the point.

If you (or your daycare) uses NurseryCam, ANYONE CAN SPY ON YOUR CHILDREN.

Let me repeat that.

If you (or your daycare) uses NurseryCam, ANYONE CAN SPY ON YOUR CHILDREN. ANYONE.

Hi, my name is John Doe and I'm a cyber-security consultant who specialises online video security.

NurseryCam is a camera system that is installed in nurseries, allowing parents to view their children remotely. There are tens of nurseries stating that they use this system. News articles go back as far as 2004.

The problem is that NurseryCam's system contains serious security issues. The worst part is that NurseryCam is lying about it. NurseryCam were informed of these as early as February 2015 – 6 years ago and still haven't done anything to fix them. These issues would allow any parent, past or present, to access the video feeds from the nursery. There is also the chance that anyone on the Internet could have accessed them.

So if you use NurseryCam, anyone can spy on your children. Do you really want that?

If you are a concerned parent now, please do not hesitate to reach out to me on john@doe.com.

If you want more technical details, keep reading on down below.

# Technical details

...

Re: A Warning to Users of NurseryCam

#57

Post by londons_explore »

mleonhard wrote: post #30

> To make matters worse, the connection to the DVR is using HTTP, not HTTPS. It is unencrypted, allowing someone to eavesdrop on the video feed, username, and password. What is the proper way to provide certificates to devices with embedded servers? - Generate a self-signed certificate with the appropriate IP address and train users to bypass the browser's scary warnings? - Buy certificates for every deployed device.…

Issue a proper HTTPS certificate for each DVR. Do it with the DNS validation method, so the DVR company can set up the necessary DNS TXT records to obtain the certificate, and then the device can retrieve that certificate and use it.

Set the DNS A record to either be a publicly routable IP (if UPnP has worked) or to a local IP (if It didn't).

Sure, an internet connection is required. But most users have that. Now all users get HTTPS with no custom setup required.

All users can now connect to https://bobsdvr.dvrcompany.com/ from inside their wifi and see their DVR. If UPnP or port forwarding has worked, they can visit https://bobsdvr.dvrcompany.com:1234/ from outside and it works too.

If all this is too much complexity for the users, you can still run a proxy server for the low volume traffic (status pages, etc.), and use the above method behind the scenes for the expensive video feeds. This has the benefit you can show a proper "Your DVR is offline" message rather than a generic error page.

Re: A Warning to Users of NurseryCam

#58

Post by bombcar »

Wowfunhappy wrote: post #47
technion wrote: post #41

Earlier quoted context omitted.

It'll "work" but the cert will be considered compromised as soon as an end user pulls the device apart and obtains it.

Right, so I'd count that as "not working." :)

Ah I see that the request was for a "generic" SSL cert for all router.lan type addresses - not your particular install of such a beast.

Re: A Warning to Users of NurseryCam

#59

Post by lazyasciiart »

netsharc wrote: post #7

I guess this comment will be burned to the ground [instead of people telling me why they disagree], and yeah a single username and password is bad, but the article smells like fear-mongering. "Zomg, strangers will look at your children!", even though the kids are in a place that is semi-public, and the viewers are mostly remote. Hmm, then again, if someone was filming my children, I'd be creeped out. And if someone w…

I have picked up my sisters children from four different nurseries over the years, and absolutely none of them would let you pick up a child without having had the parent previously give your name and identifying information to them. One of them I had to go in and show id before i was on the list. And even then they had to tell the nursery specifically each day that I was picking them up instead of a parent. The big risk for kidnapping at nurseries or schools is non-custodial parents. This means the threat model is someone who knows the children, knows their schedule and is recognized and possibly welcomed by the children. Learning what time they normally leave is worthless.

Re: A Warning to Users of NurseryCam

#60

Post by [deleted] »

kccqzy wrote: post #33
mleonhard wrote: post #30

> To make matters worse, the connection to the DVR is using HTTP, not HTTPS. It is unencrypted, allowing someone to eavesdrop on the video feed, username, and password. What is the proper way to provide certificates to devices with embedded servers? - Generate a self-signed certificate with the appropriate IP address and train users to bypass the browser's scary warnings? - Buy certificates for every deployed device.…

> Proxy all device connections through a central server. This could be expensive for high-bandwidth uses like streaming video. The central server doesn't need to proxy the actual data stream. There are plenty of peer-to-peer video implementations that only require a central server for signaling and connection establishment.

[deleted]
Post reply on HN