A Warning to Users of NurseryCam
cybergibbons.com> This blog post is intended for a non-technical audience
"OK, folks, let's start briefly with bridging firewall/NAT/non-static-IP-addr/UX by network port-forwarding, and then move on to the protocol scenario event trace diagrams..." :)
I appreciate this writer's work to document the surprising technical failings, and to try to protect people. And there's some good effort to make it accessible to non-technical audience, though some of it seemed a bit confusing/intimidating.
This might be a good occasion for coaching from (or collaboration with) a professional journalist or other writer. As a techie myself, I can only guess what the result of expert help might be, but maybe even more inverted-pyramid writing style for this audience's perspectives, getting into understandable threats/implications near the top, and then supporting that with the minimum technical explanation necessary. With a pointer to a very technical separate post, for credibility, and for the benefit of journalists and other techies.
BTW, maybe my contemporary US cultural bias is showing here (and the article mentioned UK)... I saw some mentions of "parent" where it seemed some of the threats might be more understandable, and more persuasive to some of the people who could benefit, were it to include something to the effect of "...or ill-intentioned computer-savvy person, outside the daycare, or even anywhere on the Internet". Not to promote paranoia over stranger-danger, but those aren't hypothetical additional vulnerabilities to which I think a parent would want their child exposed for (what appears to be) absolutely no reason.
(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
...
While I agree the article is more technical than the author claims, that summary says very little and sounds like fear mongering. It is important to have a credible tone in order for a serious issue to be treated seriously.
One of the interesting things about the original article are the technical details. If the claims are true, almost anyone who has a decent knowledge of computer networking can circumvent the security measures. Even replacing jargon with descriptions more amenable to a non-technical audience would likely convey the same thing. This is in stark contrast to most of the vulnerabilities we hear about these days, where a much deeper knowledge is required to exploit the vulnerability even when a thorough description is provided.
Since 1) this is supposed to be for "a non-technical audience" and 2) the target audience is parents of young children who feel it's necessary to monitor (in real-time) their child(ren)'s day care facilities in the first place, I can't help but think that your rewritten intro missed out on an absolutely perfect opportunity by failing to include -- for maximum effect and attention-grabbing, obviously -- terms like "pedophile", "child predator", and so on.
(I'm only halfway joking.)
Hello, NO. > ANYONE CAN SPY ON YOUR CHILDREN
No one said that except you. You shuld get less into the technical, and more into the actual reading.
> 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. Make each device download a new certificate when its current one expires. Set up dynamic DNS so the user can reach the device at a URL that matches the certificate.
- Make the device use an ACME server to provision its certificate. The device must be publicly accessible so the ACME server can reach it.
- Proxy all device connections through a central server. This could be expensive for high-bandwidth uses like streaming video.
All of these options are poor. Why has nobody solved this problem? Is it because the powerful browser makers (first Microsoft and now Google) prefer lucrative centralized technology? Google will make a lot less money when everyone can easily run their own server to do shared docs and messaging. Or is it because IoT companies prefer centralization so they can sell subscriptions to users and gather user behavior data? Or is it just that nobody has put in enough effort to solve it yet?
> - Make the device use an ACME server to provision its certificate. The device must be publicly accessible so the ACME server can reach it.
Not really. The most common challenge is DNS which doesn't require the ACME servers to be able to connect to the subject via HTTPs.
Probably the gold standard for how to do this is how Plex implemented it: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
Not exactly trivial but definitely not impossible.
As the Plex docs notice, this is still broken: if your DNS server filters local network IP addresses as a form of some voodoo DNS rebinding "protection", this doesn't work.
Still the best way of doing it IMO, even if not perfect.
And, this wouldn't affect this situation, since, you're doing it with external IPs for external clients.
Don't embedded devices fix the DNS-server to a specific one? Worst case the provider fixes it to their own. That has downsides too though.
The DNS queries in question are on the clients, not on the server.
> 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.
> - Make the device use an ACME server to provision its certificate. The device must be publicly accessible so the ACME server can reach it.
This seems like the most reasonable approach given that the need for HTTPS certificates arises from public accessibility.
Certificates arise from authentication. What does any part of it have to do with public accessibility? I can share GPG keys with my friend by printing them, but when it's a certificate I should really get it validated by Egypt Mubarak CA services, TurkTrust or RussiaRSA?
You should get it validated by Let's Encrypt so that the warning goes away.
The reality is that you either push the button (get the key certified), or bad things happen (users get warnings and - for the average user - simply can't use encryption). Pushing the button also doesn't have significant negative effects, and while you can lament alternative proposals at length, there is _some_ reason behind the status quo.
So you should push the button.
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.
> Sure, an internet connection is required.
It's much worse than that. The existence of the company and their servers is required. So when those disappear, the customer-owned hardware is bricked? No thanks.
No customer-owned hardware should ever depend on the continued existence of the company that sold it.
> So when those disappear, the customer-owned hardware is bricked? No thanks.
Yes please. If the company that developed some consumer networked hardware goes away, I don't want botnets of that hardware sending spam...
Software updates for security are now the norm for internet connected things, and if a piece of hardware can't be supported anymore, it will probably be exploited and siphon your private data to the highest bidder. It's far better to disable unsupportable hardware than keep using it.
If companies going bankrupt starts harming consumers, government could step in and force companies to contribute to a "support fund" for continued support of their hardware after bankruptcy if necessary.
Thank you for advocating for the continued erosion of user rights with regards to hardware they own. How about we stop tethering devices to manufacturer servers and reserve that for optional, over-the-top features?
The right to swing your fist ends at my nose.
Internet connectivity is an optional over the top feature. You don't deserve the right to be on the shared public internet using a computer someone else made if you can't be cut off for antisocial behavior.
You can make your hardware from raw components if you want.
That's a pendulum that swings both ways, however. Disabling a manufacturer's entire fleet of product when they go out of business is a little bit far on that scale, IMO. Like you said, the right to swing your fist ends at my nose.
That's why I said "how about we stop tethering devices to manufacturer servers" implying that their basic functionality should always be standalone. Why should we be increasing long-term waste by bricking such products?
I'll go with the first one, because it is as you said: the authoritarian security industry, and the corporate types in general, love centralised control, and HTTPS-everywhere is their attempt at grabbing more of it.
Honestly, as another commenter here noted, I don't think this is that big of a problem --- and is comparable to all the other open webcams out there.
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.
What I do is request a wildcard cert from Let's Encrypt on one of my public-facing servers, and then copy that to all my other machines.
I don't think that will work on an end-user device though, right?
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.
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 cloud where they can happily vacuum data. Local network is a not use case at all.
I think we're saying the same thing—it would be good if such a standard existed, but it doesn't. So of the available options, simply settling for http seems like the most reasonable to me.
The only real alternative I can think of is to make the entire device dependent on a cloud service of some sort. Which IMO would be clearly worse for a whole host of reasons (among them, now your device is useless if that service goes down).
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.
This kind of highlights the problem with these kinds of products. They are extremely difficult to do properly and expose the user to quite a lot of danger. Really we should be settling for “well it is quite hard so we will let these faults pass”. The product should simply not be allowed to be sold if it can not be done properly.
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 staff, including private health info.
Just utterly bat shit insane
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.
Looks to me like some developer somewhere made a RaspberryPI camera prototype and some dumb money ran with it creating a marketing campaign and getting the prototype in the market as if it were a complete solution.
There's an article over at TheRegister related to the FootFallCam saga:
https://www.theregister.com/2021/02/12/footfallcam_twitter_k...
People should mirror this whole twitter thread and its content to use as a literal textbook example of everything not to do.
Yeah... I didn't fully appreciate just how insane this is because the information's scattered all over the place. Then I read the Register article and a collated Twitter thread... and yeah, it's insane...
This company has absolutely no business being anywhere near security/software/hardware development.
https://www.theregister.com/2021/02/12/footfallcam_twitter_k...
> First they try and report the security consultants to the police, then they claim that they are too expensive to work with.
Hahaha what? Are you saying they paid these guys, then reported them to the police, and then the police found a contract and they just said "well they're too expensive!"
> Then even more bizarrely they launch a halfarsed sock puppet campaign using the CEO's wife's account.
Sure, why not?
> Then they start publishing reviews on their own staff, including private health info.
I am so confused. I read the article and still don't understand this comment.
This should absolutely be an end of this company.
1. They did not just give unauthorized access, they gave admin access.
2. It’s been going on for 6 years.
3. It seems very basic.
4. Not using HTTPS is another big red flag
5. Having this secure access feature is one of their selling points, by not providing it they essentially defrauded the public.
Mistakes happen, and it worse when it happens in security field. But this is not an honest mistake, this is negligence.
The short version:
For all parents connecting to a given nursery, they are given the same username and password for the DVR. In the examples I have been shown, the username is admin and the password is either admin888 or nurserycam888.
Sigh.
And they knew about the issue for over 5 years...
The initial blog post with more of the technical detail is here:
https://cybergibbons.com/security-2/serious-issues-in-nurser...
> This blog post is intended for a non-technical audience – specifically parents and nurseries using the NurseryCam system.
Good idea, but the article is full of specific technical details + technical diagrams that are irrelevant to getting the point across.
I think that statement was about the first three paragraphs and those are pretty clear and to the point.
Then again, I doubt most people are going to be particularly alarmed. The flaw means that people who know the nursery ip and the password to the camera could connect after they lose access to the website if they are tech savvy enough. Most people will probably shrug at that. It's a nursery cam for parents. What's the threat model exactly?
It might be of interest to people buying a new system however.
Out of curiosity, why is viewing nursery footage seen as serious?
Should it be patched, sure. I see it as different than some random IOT device in the crib, this is at the nursery itself.
Why are parents given access to particular feeds at a nursery?
Why does it matter that they can watch other kids at a nursery if you’re already giving this access?
Yeah I get that now ANYONE can watch them too, ooh scary men in trench coats and top hats watching children.
I’m missing something about the wording of this:
“The issues with NurseryCam are about as serious as it gets.”
Is it though?
> Out of curiosity, why is viewing nursery footage seen as serious?
As a parent you are your child's guardian, which generally means that it is your responsibility to protect your child. I would assume most people would try to protect themselves against having their surveillance footage accessed by unauthorized parties and so this parent (the author) is trying to achieve this for their children.
I personally can imagine scenarios where for the purposes of social engineering it is advantageous for a malicious actor to get access to the footage of your child's nursery to, for example, study when your child is generally there or when you pick them up or who picks them up.
> Out of curiosity, why is viewing nursery footage seen as serious?
pedophiles can view/record naked infants and toddlers with relative ease.
Not sure why I’m trying downvoted. Maybe the mere mention of pedophelia disgusts people.
This is a real threat, but honestly I’m not concerned... and I have a toddler in a facility that uses a system like this (not the same one).
I have a toddler in a facility too. But I'm not at all convinced that this is a real threat. I'm having trouble even imagining it as a theoretical threat.
Pedophiles are bad for sure. But internet people watching nursery footage doesn't seem to make that any better or worse. I expect roughly all of nursery footage to be uniformly boring. Even if a pedophile got access to it... then what? Where's the threat?
They get attached to specific kids and grab them in the park after they see the kids are getting ready for their daily trip?
On average, yeah, nothing bad will happen. But that’s true for someone leaving their front door unlocked too. Eventually you are likely to get fucked.
I guess. I take issue with the use of the word "likely" here though.
Any individual kindergarden may be unlikely to have it happen, but this is a business selling to multiple.
The more salient point is that even once is too many.
> Even if a pedophile got access to it... then what? Where's the threat?
The material gets collected and sold via darknet forums.
I haven't done any research on this particular system/device myself. I skimmed this article and just finished the Twitter thread about the other product designed to count people.
Beyond the boogeymen watching the feed threat, this device itself can easily be taken over given the relaxed/non-existent security mentioned (everyone getting admin). This can in turn lead to all kinds of shenanigans ...
Ah yeah it was saying that was admin, the article didn’t go into that and was devoid of the threat greater than people watching footage
I honestly think the article skims this point in an effort to focus on the bare necessary information to communicate this to relatively non-technical people.
Most of the nurseries here have big windows so everyone walking past can see nearly everything inside.
Sure, but anyone standing there for long enough to be noticed will eventually be asked to leave.
I'd just like to highlight the response to Andrew: https://twitter.com/A_Mitchell1966/status/136102436212456653...
The words “NurseryCam” is warning enough for me :-). Will leave IoCrap stuff like that well alone.
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 "<manufacturer> web interface" I stumble on a screenshot of a directory service that registers DVRs via DNS and gives them a domain
- "site:*.<domain>" 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?
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 was using this to identify kids and their day-to-day patterns (e.g. pick up hours), they could theoritically show up 10 minutes earlier, say they're there sent by the parents to pick up someone, and "the kid is wearing a blue top and yellow shorts" or whatever. But IMO kidnap scares are overblown, and if a nursery falls for that trick without calling the parents first, they should be shut down for being too stupid.
It is a very real concern.
Most people know that taking an interest in children who are not in their care is frowned upon and will not watch other people's children unless there is very good reason to. As a result, someone watching children with unknown motivations is suspect. Should it be that way? Probably not, but it is given the social context.
This is even evident in public spaces. If an unknown person is watching children, someone will strike up a conversation with them. It isn't about being friendly. In fact, the person responsible for the safety of the children is probably quite annoyed. The point of that conversation to let the unknown person know that their presence is known and that they are being monitored. Why? A social norm is being violated so extra care must be taken. Is the concern excessive? Perhaps, but it is negligence if extra care is not taken and something happens.
That social expectation does not simply disappear when technology is involved. In some ways, the violation is worse since it is easier for that unknown person to conceal their presence.
(Source: I am involved with recreation programming.)
> but the article smells like fear-mongering. "Zomg, strangers will look at your children!"
1) It should be reasonable to expect some privacy when you give your kids into the care of other people. There is a whole lot difference: someone can walk by a day care and see kids playing outside and anyone on the internet can access these systems. I don’t know how these nurseries work that use these systems, but I assume that not that many people have access to the kids, only staff and maybe other parents/guardians.
2) The company producing these camera systems claims them to be more secure than online banking. This is flat out wrong, one might even argue fraud.
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.
Is your child's bedroom semi-public?
This is a system sold to commercial nurseries, not installed in peoples homes.
Yeah, and in this commercial nurseries children spend a good amount of time. So its their second bedroom.
I don't understand that at all. If I spend a lot of time at Starbucks, is that my second bedroom? Why are other people using the bathroom attached to my bedroom?