When baby monitors fail to be smart
sec-consult.com
sec-consult.com
- Available Serial Interface (referring to easy-to-solder console port pads on PCB, accessible once you tear device apart);
- Weak Default Credentials (referring to weak root password that is only ever accepted via serial console).
Life-span of a baby monitor is couple of years, by definition. After that, this hardware could either become a cool easy-to-tinker Linux device, or e-waste.
Researchers at sec-consult seem to think e-waste option is better, or at least it's a necessary evil to deter those pesky hackers who sneak near your child's crib, armed to their teeth with soldering irons and screwdrivers.
Unless you have more than one baby. Or friends/family with babies. My nephews are using products that weren't even new when I played with them, decades ago.
Ever have an infant crying for 45 mins because the monitor failed and you thought he was still sleeping? Really really upsetting.
Honestly, the static re-assures me it's still listening to my child.
Probably similar reasons why the light switches in my home will remain analog. I need it to work 100% of the time. I can't trust a computer for that.
People who have covert spy teams entering their home hacking serial interfaces on baby monitors probably shouldn't be buying this thing. The vendor in this case seems to have build a pretty decent solution considering the pricepoint and purpose.
The only vulnerability here is the consumer vulnerability for buying something as trivial as a baby monitor that is dependent on some random consumer company's cloud service for a core function. It would be better to have a fallback to a multicast DNS service so it could function on the local network.
When I bought a baby monitor I made sure it was dumb, because why would I trust some random company with data from a camera in my house?
I imagine probably 99% of them are but I don't have any research to actually back that up.
They’re also not networked, so an adversary would have to get into range, making a potential attack much more complicated. It certainly won’t defend you from a targeted attack, but it will keep $random_person_on_the_internet reliably away and I don’t have to rely on $companies server/network security.
"We begin by coveting what we see every day... Clarice"
Many of the smart ones both broadcast like the dumb ones and, separately, send a signal on wifi to a central server for online viewing, so they fully incorporate the problems of the dumb ones.
And as of right now, the only 2 things that go through that firewall are the nest thermostat (yeah, it's pretty and hasn't given me any trouble, so i'm happy with the tradeoff here), and the google homes (again, another tradeoff myself and my family are comfortable making).
Everything else is on that network without access to the "internet" directly, with WPA2 encryption for protection against local eavesdropping, and pushed through an open-source home-automation controller called "Home Assistant" running on an intel NUC served up over HTTPS to our devices.
I don't have any baby monitors yet (no babies!) but we do have cameras and with this system they work great and I sleep pretty well at night knowing it's all secure enough that i'm happy buying cheap devices knowing the security is garbage.
Most of them will output standard formats and streams that you can hook into in my experience (but i might be inadvertently selecting for those)
Get a new device, plug it in to a locked-down network that passes all packets through a deep packet inspector connected to some ML. Add in proxy features so if the vendor turns off their service, your personal network MitM can mimic the server on the other side.
I doubt this is feasible due to the fact that consumers clearly value "it just works" (implying simplicity/less security) over secure/private. (And probably a bunch of other factors I'm not thinking of.)
https://www.amazon.com/Sony-BabyCall-Receivers-Discontinued-...
Actually, considerably less.
Sure: baby monitor security is important too: if you can get it right for a baby monitor you've probably got the framework (technical, social, regulatory, etc) to get it right for a bunch of other things.
But are baby monitors themselves solving a problem or causing one? The alternative is to either have the baby in the room with you (distracting: they're like a campfire!) while you do your chores or talk to your visitor or whatnot, or learn to be able to be in another room from your baby.
Sounds luddite, but it helps lay the foundation for a healthy, non-helicoptering relationship with your kid and doesn't slip tolerance for pervasive surveillance into your home.
I think that's a pretty big exaggeration. "helicopter parenting" usually characterises parents who refuse to/cannot step back from their child's life and let them make decisions on their own. A sleeping newborn child cannot make decision on it's own - the only acceptable form of parenting is helicopter parenting when your child isn't capable of doing anything for itself!
Sudden Infant Death Syndrome exists. You can hardly blame people for wanting to protect their child from it.
She was alert when the paramedics showed up, but the subsequent tests at the hospital proved nothing. The cardiologist, nurses, and other doctors all seemed to agree that it was "nearly a SIDS thing" and that we just got lucky.
After that night, and for every night since (2 more kids since then) we've used a breathing monitor. Occasionally I've noticed the kids will go in a "deep sleep", and the monitor will go off a few times during the night, you'll have to reposition them; they'll wince (in their sleep) and carry on. If that's what it takes, then that's what it takes.
From my research after that event, it seems like SIDS is all-encompassing, and the amount of time allowed for an infant to slip into death may play a factor in it's "suddeness".
My counter example is my sister in law who is very helicopter of her first child, even now that he is over a year old. They've been in small apartments, and have traveled a lot with him in arms(no car, so no car seat). I doubt they have ever used a monitor. I bet if she had had more opportunities to put him in another room to sleep without concern, she'd be more willing to let family play with him in other rooms of my parents' house during holidays.
I really need to hear if/when my newborn is having breathing problems.
We never had any real issues with either of our kids, and only false alarms. But I know my wife got better sleep just because the alarm was there (only in part because I was usually the one to check when the alarm went off).
Definitely is a sanity-saver.
We stopped using it nearly immediately. It was a glorified audio only monitor for us, the check for movement/breathing was giving lots of false positives and drove us insane.
Other parents even turned on a beep for each breath, made it sound like a hospital. You subconsciously gold your breath if the device beeps with a tiny delay.. beep..beep....???beep
For us it was the wrong choice.
Now, what would be really helpful for small babies is consumer-available version of the 'clicker' breathing monitors they use in NICU wards. Our oldest was in NICU for nearly two weeks due to being a little prem, and when we got them home the lack of that regular 'click... click...' from the monitor was so hard to get used to.
It's not a medical grade device like the NICUs have, but it lets you rest easier knowing you'll be notified if your baby's pulse or O2 levels drop.
Where a (video-capable, audio-muted) monitor helps with my 1-year-old is that I can see at a glance whether he's just fighting a loosing battle with sleep, or if he has won that battle, is standing up and sleep has lost this battle.
If it's the former, I dare not open the door. If it's the latter, I need to go in and rock him back to sleep. Having this tool has saved him and I from many cranky, nap-deprived days.
And, btw, it's a dumb monitor with a ~400 foot range. All 3 neighbors within range are trusted to watch the kid - if they want to help, great!
Yes, we use a movement-based monitor and have for the last 6 years (3 kids). It doesn't require anything on the baby, and sits under the mattress. Sensitivity is adjustable and it's very accurate. It truly lets me sleep better at night.
I know all babies are somewhat different, but at least ours seems to be happy to sleep through most noises - up to and including using a vacuum-cleaner in the next room.
I try to keep things a little quieter than usual around bed/nap-times, but otherwise the family life must go on. If the baby wakes up sometimes because you boiled a kettle, dropped a book, or turned on the laundry then that's just something you have to deal with at the time.
But with our first child we had a near-SIDS experience; nothing terrible came of it, but it definitely shook my core.
Having a baby monitor that tells when it can't feel the baby breathing any more is a complete sanity saver. It's the one and only reason I recommend them.
That’s the important sentence to me. That’s where we all gone wrong in my opinion.
And we all know what the password is... "1234"
Much the same logic as the market for indoor security cameras from Canary/Nest/Arlo et al, and those seem to sell well enough. I know several colleagues who use a Nest in this way, for families and pets.
There's nothing wrong in principle with using a certificate (other than it being overly complicated...there's a reason we aren't all using client certificates to authenticate with our email server, Twitter, Facebook, etc). Just as there is nothing wrong in principle with using a user/password scheme.
Both certificates and user/passwords suffer from the same serious problem: how do you change them on the device? If you don't have a way to change them, all someone has to do is learn the factory default and game over. (Even if you provide a way to change them there is the issue of how to make sure people actually change them, which is a whole other problem).
IoT devices often do not have a good interface on the device itself that you could use to change a user/password (let alone enter a new certificate!).
You could include Bluetooth in the device, and provide a configuration application that the user runs on their phone. If the device does not otherwise need Bluetooth that is going to raise the cost a little, and if the device does not otherwise need a mobile app making people get one just to set the thing up is going to seriously annoy many.
What I would like to see is this:
1. Every IoT device (and every non-IoT device, for that matter, for reasons given below) should have at least one of: (A) A USB port that you can plug a thumb drive into, (B) A USB port that you can use to connect the device to a computer, or (C) some type of SD card port. I think that USB is cheap enough now that it would not cost much to add it.
2. If you plug a FAT or FAT32 formatted thumb drive or SD card into the device, it reads and applies configuration information from a file on the drive or card. There should be a convention established for the naming and location of configuration files so that multiple devices from multiple vendors can all have configuration files on the same drive.
3. If you plug the device into a computer via USB, the device shows up as a FAT or FAT32 formatted drive with its current configuration in files on that drive. You can edit them to change the configuration.
4. When you connect a thumb drive or insert an SD card and there is a "DOCS" directory on it, the device makes a subdirectory in that named after itself, and in that directory writes a copy of its user manual and other documentation. If there is a "LOGS" directory, it should do a similar thing, but with any logs it keeps. If there is an "INFO" directory, do a similar thing but with information about the device, such as model number, serial number, and other such stuff useful to have if you need to contact customer service.
5. This mechanism could also be used to provide firmware updates to the device.
(#4 and #5 are why I want this everywhere, not just IoT).
Another issue with IoT devices, once you have figured out how to change authentication information, is how to keep that safe? For instance, I'm making a motion detecting bird camera to take photos of the birds that stop by for the food I leave out. If I want it to use my home wifi to upload photos...it needs my home wifi credentials.
But it will be outside. If someone steals it, they have my credentials! (I'm currently using a Raspberry Pi, so they could just steal the SD card...or if they came prepared they could just borrow it, copy it, and put it back, and I might not even find out about it).
My current thoughts are to have the thing come up after boot offering its own wifi network. I can connect to that from my computer, and start the bird cam software, which can ask for my wifi credentials. It can then stop offering a wifi network and join mine, keeping the credentials only in RAM.
Still vulnerable, but it would then take an attack more sophisticated than simply stealing it, or cloning the SD card.
A simple solution is to ship every IoT device with an individual certificate or key embedded in NVM (non-volatile memory).
To add some flexibility and improve security you would also need to have some certificate management capabilities like revoking or even provisioning.
They really thought things through (can I add another "th" word in here?).
Thankfully, they thoroughly thought these threatening things through.