A Warning to Users of NurseryCam(cybergibbons.com) |
A Warning to Users of NurseryCam(cybergibbons.com) |
"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.
# 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
...
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.
(I'm only halfway joking.)
No one said that except you. You shuld get less into the technical, and more into the actual reading.
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?
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
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.
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.
https://cybergibbons.com/security-2/serious-issues-in-nurser...
Good idea, but the article is full of specific technical details + technical diagrams that are irrelevant to getting the point across.
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.
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?
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.
pedophiles can view/record naked infants and toddlers with relative ease.
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).
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 ...
- 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?
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.
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.
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.
This seems like the most reasonable approach given that the need for HTTPS certificates arises from public accessibility.
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.
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.
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.
> 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.
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.
https://www.theregister.com/2021/02/12/footfallcam_twitter_k...
This company has absolutely no business being anywhere near security/software/hardware development.
https://www.theregister.com/2021/02/12/footfallcam_twitter_k...
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.
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.)
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.
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.
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).
And, this wouldn't affect this situation, since, you're doing it with external IPs for external clients.
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?
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.
The material gets collected and sold via darknet forums.
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.
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.
The more salient point is that even once is too many.
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?