Anker’s Eufy lied to us about the security of its security cameras(theverge.com)
theverge.com
Anker’s Eufy lied to us about the security of its security cameras
https://www.theverge.com/2022/11/30/23486753/anker-eufy-security-camera-cloud-private-encryption-authentication-storage
79 comments
False advertising is rampant. Amazon has misleading advertising for local storage on their Blink cameras. They claim to support local storage, but use the subscription (trial) features for 3 months before dropping you into a degraded (local) experience with no thumbnails or bulk deletion of videos. It’s complete trash and, IMO, an intentional scam to deceive users for long enough that they feel like they can’t ask for a refund.
I don’t get the thumbnail thing either. They don’t need to put thumbnails online. At the very most the only thing they need is to relay your (encrypted) data to get around firewall related issues.
I don’t get the thumbnail thing either. They don’t need to put thumbnails online. At the very most the only thing they need is to relay your (encrypted) data to get around firewall related issues.
Article says they can stream unencrypted video which certainly could be done via NAT traversal without sending data to the cloud. There's plenty of appliances that do that. It's also possible they thoroughly encrypt the data at rest but just don't use https because that's tricky to do without static IPs/hostnames. Not saying Eufy is off the hook but I'd like to see a little more technical of a breakdown.
They at the least upload thumbnails to the cloud, which would include photos of the areas being recorded and people's faces. If this is part if a notification system, that probably includes timestamps. That's enough to begin to build a profile of the user, patterns regarding visitors, etc.
Agree, with the nuance that “unacceptable” is not binary. This is bad and wrong and contrary to their promises, and also not the most terrible thing ever.
In-short: "Anker has built a remarkable reputation for quality over the past decade [...], including the Eufy home security cameras [...]. Eufy’s commitment to privacy is remarkable: it promises your data will be stored locally, [...], that its footage only gets transmitted with “end-to-end” military-grade encryption, and that it will only send that footage “straight to your phone.”
So you can imagine our surprise to learn you can stream video from a Eufy camera, from the other side of the country, with no encryption at all."
And a tweet showcasing how to get the unencrypted video/images from the security researcher who discovered the issue: https://twitter.com/paul_reviews/status/1595421705996042240
So you can imagine our surprise to learn you can stream video from a Eufy camera, from the other side of the country, with no encryption at all."
And a tweet showcasing how to get the unencrypted video/images from the security researcher who discovered the issue: https://twitter.com/paul_reviews/status/1595421705996042240
As I understand it, the Homebase is responsible for the encryption and storage.
That said, I realized I could watch live my doorbell via the app when away. I assumed this would be encrypted somehow, too, but I suppose their findings are that they're not. Bummer.
That said, I realized I could watch live my doorbell via the app when away. I assumed this would be encrypted somehow, too, but I suppose their findings are that they're not. Bummer.
The supposed lack of encryption has not been confirmed.
There's been quite a bit of FUD spreading since this story hit, and I'm convinced that the security researcher involved has some misconceptions about what it means for content to be encrypted. He seems to believe that because he can see the network requests in browser developer tools, communication is not encrypted.
Up to this point, the most solid claim is the fact that thumbnails are transmitted to Eufy to facilitate push notifications. Eufy confirmed this, and pledged to improve the messaging on the options that enable the feature.
The concerns related to the streaming of video is as-of-yet not confirmed, and would indicate a breathtaking lapse on Eufy's part if true. It's been disheartening to watch all of this unfold with too many folks taking pretty huge claims at face value. It could be true, but people are acting as if it absolutely it.
There's been quite a bit of FUD spreading since this story hit, and I'm convinced that the security researcher involved has some misconceptions about what it means for content to be encrypted. He seems to believe that because he can see the network requests in browser developer tools, communication is not encrypted.
Up to this point, the most solid claim is the fact that thumbnails are transmitted to Eufy to facilitate push notifications. Eufy confirmed this, and pledged to improve the messaging on the options that enable the feature.
The concerns related to the streaming of video is as-of-yet not confirmed, and would indicate a breathtaking lapse on Eufy's part if true. It's been disheartening to watch all of this unfold with too many folks taking pretty huge claims at face value. It could be true, but people are acting as if it absolutely it.
The video being streamed to eufy's cloud instance is very much not encrypted:
https://i.imgur.com/nWJywdw.png
This is the RTMP stream from my eufy homebase going to an amazon ec2 instance. Unless RTMP encrypts data inside keyframes they're not using encryption for that at least.
https://i.imgur.com/nWJywdw.png
This is the RTMP stream from my eufy homebase going to an amazon ec2 instance. Unless RTMP encrypts data inside keyframes they're not using encryption for that at least.
Yeah. As a Eufy owner I'm not really concerned about the thumbnails, especially since they can be turned off.
The video streaming is of more concern, but the reporting has been really weird and bad about it. Why do they keep mentioning VLC like it's some secret hacker tool? If unencrypted, why do they mention a shared AES key?
Really wish a reliable source would give more details.
The video streaming is of more concern, but the reporting has been really weird and bad about it. Why do they keep mentioning VLC like it's some secret hacker tool? If unencrypted, why do they mention a shared AES key?
Really wish a reliable source would give more details.
> Wasabi also noted that the way the remote URLs are configured, there are only 65,535 combinations to try, "which a computer can run through pretty quick.")
- From the ars article
It's a bit confusing, but I think they what they are implying is that there is a total of 65,535 possible keys. Devices may be assigned one of those randomly. The URL must send the key and some sort of device ID. It's possible that if you know the device ID, it would only take 65,535 attempts to gain access to the stream.
It's a bit confusing, but I think they what they are implying is that there is a total of 65,535 possible keys. Devices may be assigned one of those randomly. The URL must send the key and some sort of device ID. It's possible that if you know the device ID, it would only take 65,535 attempts to gain access to the stream.
Did I miss something? I didn’t see anything explicitly stated, but I took that number to mean that Wasabi was doing simple port enumeration—there are only 65,535 ports that need to be checked to enumerate a TCP network interface.
Edit: I did miss a key paragraph—they keys are also 16 bits–port enumeration was just the first place my mind went.
Edit: I did miss a key paragraph—they keys are also 16 bits–port enumeration was just the first place my mind went.
Encrypting something with the same key, that is public, is functionally equivalent to unencrypted.
It's like saying we pay our interns, but the payment is $0.01 per century. It's not true.
It's like saying we pay our interns, but the payment is $0.01 per century. It's not true.
> It's like saying we pay our interns, but the payment is $0.01 per century.
https://dilbert.com/strip/2009-01-11
https://dilbert.com/strip/2009-01-11
The streaming of video has been confirmed by multiple sources including the Verge and Linus Tech Tips
Sort of, but with caveats.
From The Verge:
> This week, we repeatedly watched live footage from two of our own Eufy cameras using that very same VLC media player, from across the United States — proving that Anker has a way to bypass encryption and access these supposedly secure cameras through the cloud.
Missing is how they connected "VLC can play a stream" to "Anker has a way to bypass encryption". The ability to open a stream in VLC does not automatically imply it is encryption-free.
> There is some good news: there’s no proof yet that this has been exploited in the wild, and the way we initially obtained the address required logging in with a username and password before Eufy’s website will cough up the encryption-free stream. (We’re not sharing the exact technique here.)
Things continue to be fuzzy and it's not clear what they believe "encryption-free" means. Since everyone is being understandably cautious about releasing the actual details, all of this is still frustratingly incomplete information.
On the LTT side, they went full rage mode in their coverage and it became difficult to take them seriously based on how they were discussing the thumbnail issue.
We desperately need an end-to-end review and summary from a reputable security person.
From The Verge:
> This week, we repeatedly watched live footage from two of our own Eufy cameras using that very same VLC media player, from across the United States — proving that Anker has a way to bypass encryption and access these supposedly secure cameras through the cloud.
Missing is how they connected "VLC can play a stream" to "Anker has a way to bypass encryption". The ability to open a stream in VLC does not automatically imply it is encryption-free.
> There is some good news: there’s no proof yet that this has been exploited in the wild, and the way we initially obtained the address required logging in with a username and password before Eufy’s website will cough up the encryption-free stream. (We’re not sharing the exact technique here.)
Things continue to be fuzzy and it's not clear what they believe "encryption-free" means. Since everyone is being understandably cautious about releasing the actual details, all of this is still frustratingly incomplete information.
On the LTT side, they went full rage mode in their coverage and it became difficult to take them seriously based on how they were discussing the thumbnail issue.
We desperately need an end-to-end review and summary from a reputable security person.
> The ability to open a stream in VLC does not automatically imply it is encryption-free.
Yes it does, doesn’t it? Unless you’re loading keys that are used for decryption into VLC you’re streaming unencrypted data. The URL might be authenticated, but that’s not encryption. The transport (https) might be encrypted, but that’s not what anyone cares about. The data (aka video) should be encrypted with a client owned key.
Yes it does, doesn’t it? Unless you’re loading keys that are used for decryption into VLC you’re streaming unencrypted data. The URL might be authenticated, but that’s not encryption. The transport (https) might be encrypted, but that’s not what anyone cares about. The data (aka video) should be encrypted with a client owned key.
Yes, I’m crystal clear on the difference between authentication and encryption.
> The transport (https) might be encrypted, but that’s not what anyone cares about.
I was referring to transport encryption. Paul was rather vague about what he meant by unencrypted, and if there’s no transport encryption this is a breathtakingly big issue. So I’d argue that people do/should care about this.
Data encryption would obviously be ideal, but in my mind, that wasn’t even the initial bar to clear after a claim of “unauthenticated and unencrypted”.
The biggest issue with all of the communication up to this point has been a lack of precision/specificity, and that has led to multiple interpretations of the findings and plenty of misunderstanding.
> The transport (https) might be encrypted, but that’s not what anyone cares about.
I was referring to transport encryption. Paul was rather vague about what he meant by unencrypted, and if there’s no transport encryption this is a breathtakingly big issue. So I’d argue that people do/should care about this.
Data encryption would obviously be ideal, but in my mind, that wasn’t even the initial bar to clear after a claim of “unauthenticated and unencrypted”.
The biggest issue with all of the communication up to this point has been a lack of precision/specificity, and that has led to multiple interpretations of the findings and plenty of misunderstanding.
I wonder how much confusion is around people thinking "authentication" when saying or hearing "encryption"
The researcher's claim is about both authentication and encryption, so there's at least some distinction baked into the claim.
I suspect the disconnect is regarding transport encryption vs. data encryption. There seems to be an assumption that transport encryption is a given, but I don't believe that to be true.
I suspect the disconnect is regarding transport encryption vs. data encryption. There seems to be an assumption that transport encryption is a given, but I don't believe that to be true.
A lot. Several comments here even get it wrong.
I wish LTT was better at the research and testing side things. The production value is pretty good but man do they get it exactly wrong a lot.
Reading "military-grade encryption" should trigger everyone's BS detector every time.
The media transfers are encrypted. But he uses the Developer Tools of the browser, so he sees the content of the encrypted packets.
It is obvious that any cloud-based security camera has to send the media to the cloud! There is no other way.
The marketing people at Eufy made a long series of mistakes. It is a marketing problem.
It is obvious that any cloud-based security camera has to send the media to the cloud! There is no other way.
The marketing people at Eufy made a long series of mistakes. It is a marketing problem.
Eufy markets their cameras as privacy focused, using local storage and local processing without using cloud storage so I'm not sure how you concluded against their marketing that it's cloud based.
Also he opens the link in a new private session which doesn't have the auth cookies. Furthermore, he later explains that there is no auth happening. Lastly The Verge confirmed it by watching the camera stream using plain VLC.
Also he opens the link in a new private session which doesn't have the auth cookies. Furthermore, he later explains that there is no auth happening. Lastly The Verge confirmed it by watching the camera stream using plain VLC.
> There is no other way.
That's not true, or at least not always.
Plex manages this just fine with my media content.
Plex Media Server reaches out to my router and punches an inbound port to itself. When I'm then watching from outside my home network, the traffic is going direct to my home IP.
That's not true, or at least not always.
Plex manages this just fine with my media content.
Plex Media Server reaches out to my router and punches an inbound port to itself. When I'm then watching from outside my home network, the traffic is going direct to my home IP.
Eufy isn't cloud-based.
The fact that they are indeed cloud-based is why this story has been blowing up and making quite a few people upset.
The reality is, even if the cameras are not configured to save video to Eufy's cloud service, thumbnails are still transmitted to Eufy for the purpose of facilitating push notifications (confirmed by Eufy), and the researcher who discovered this claims to have found a way to access camera feeds without authentication as well (this is not confirmed, and one of the most questionable claims).
I own several of these cameras but have them configured as HomeKit devices, and while I'm not terribly concerned about the transmission of thumbnails since this is the name of the game if you want a preview in a push notification, I've always felt a little weird about the fact that these cameras require a Eufy account to configure, and you can access the live streams by logging into that account, even after the cameras have been configured as HomeKit cameras.
The reality is, even if the cameras are not configured to save video to Eufy's cloud service, thumbnails are still transmitted to Eufy for the purpose of facilitating push notifications (confirmed by Eufy), and the researcher who discovered this claims to have found a way to access camera feeds without authentication as well (this is not confirmed, and one of the most questionable claims).
I own several of these cameras but have them configured as HomeKit devices, and while I'm not terribly concerned about the transmission of thumbnails since this is the name of the game if you want a preview in a push notification, I've always felt a little weird about the fact that these cameras require a Eufy account to configure, and you can access the live streams by logging into that account, even after the cameras have been configured as HomeKit cameras.
>The fact that they are indeed cloud-based is why this story has been blowing up and making quite a few people upset.
No, its "Cloud Enhanced" if you choose it.
If you dont turn on the thumbnail images, or pay for the cloud storage extra option then it just plain doesn't use the cloud.
The streaming a camera issue is something else. Possibly something that can be fixed with a patch
No, its "Cloud Enhanced" if you choose it.
If you dont turn on the thumbnail images, or pay for the cloud storage extra option then it just plain doesn't use the cloud.
The streaming a camera issue is something else. Possibly something that can be fixed with a patch
> If you dont turn on the thumbnail images, or pay for the cloud storage extra option then it just plain doesn't use the cloud.
I wish this were true, but that's not quite right. In order to configure your new Eufy cam, you must:
1. Create a Eufy account
2. Log into that account on your device
3. From that point forward, your Eufy cam is always accessible via the web portal even if you configure it to use HomeKit
Furthermore, the setting that allows screenshots to be sent is enabled by default.
You're correct that you must opt in to send actual video to Eufy's cloud, but right out of the gate, a new Eufy deployment is susceptible to all of the issues described.
Jury's out on the streaming thing.
I wish this were true, but that's not quite right. In order to configure your new Eufy cam, you must:
1. Create a Eufy account
2. Log into that account on your device
3. From that point forward, your Eufy cam is always accessible via the web portal even if you configure it to use HomeKit
Furthermore, the setting that allows screenshots to be sent is enabled by default.
You're correct that you must opt in to send actual video to Eufy's cloud, but right out of the gate, a new Eufy deployment is susceptible to all of the issues described.
Jury's out on the streaming thing.
> this is the name of the game if you want a preview in a push notification
I’m not sure that’s actually true. iOS has notification service extensions that I think could be used to decrypt an image for display in a notification.
I’m not sure that’s actually true. iOS has notification service extensions that I think could be used to decrypt an image for display in a notification.
It's possible that this is something that Apple rolled out since the last time I dug deeply into push notifications and my understanding of this part could be out of date.
This looks more like negligence than malice. In order to send the push notification you have to send the content to a server that then gets pushed down through say Apple's Push Notification Service. The doorbell cannot talk directly to your device. The notification contains the image and whatever other text and metadata shown.
I'd imagine that what they mean by "planning to encrypt" this content is to E2EE the content and register a notification extension (something like: https://developer.apple.com/documentation/usernotifications/...) that transforms the content once received by the client.
As most people probably know, E2EE isn't a simple problem to do in a user-friendly way. Perhaps when setting up the app/doorbell the doorbell could have some certificate that the app is aware of that's used for encrypting the data before it leaves the doorbell, and decrypted using the app's private key but this obviously isn't something provided out of the box.
Obviously a warrant could be served to Apple/Google/Eufy for notification content, but I don't take this as being particularly nefarious.
It genuinely wouldn't surprise me if other offline doorbells like Ubiquiti's UniFi line were also affected.
*I should probably mention I wrote this comment after reading a different article/video but didn't catch that their marketing mentioned that everything is E2EE. So yeah, seems like a pretty glaring lie in that regard.
I'd imagine that what they mean by "planning to encrypt" this content is to E2EE the content and register a notification extension (something like: https://developer.apple.com/documentation/usernotifications/...) that transforms the content once received by the client.
As most people probably know, E2EE isn't a simple problem to do in a user-friendly way. Perhaps when setting up the app/doorbell the doorbell could have some certificate that the app is aware of that's used for encrypting the data before it leaves the doorbell, and decrypted using the app's private key but this obviously isn't something provided out of the box.
Obviously a warrant could be served to Apple/Google/Eufy for notification content, but I don't take this as being particularly nefarious.
It genuinely wouldn't surprise me if other offline doorbells like Ubiquiti's UniFi line were also affected.
*I should probably mention I wrote this comment after reading a different article/video but didn't catch that their marketing mentioned that everything is E2EE. So yeah, seems like a pretty glaring lie in that regard.
The issue is that Anker said the footage was e2e encrypted. If they needed to be able to decrypt it to send notifications, they shouldn't have advertised it as providing end-to-end encryption.
If something is E2EE it is deeply inconvenient and fragile. If something is easy to use, it cannot be E2EE.
Another fairly good rule of thumb is that any product specifically marketed based on privacy fears is probably snake oil.
Another fairly good rule of thumb is that any product specifically marketed based on privacy fears is probably snake oil.
> If something is E2EE it is deeply inconvenient and fragile. If something is easy to use, it cannot be E2EE.
The only difficult part of E2EE is establishing trust. As in: how do I securely exchange encryption keys with this other entity in a way I know isn’t being spoofed?
The online banking I do all the time is E2EE from my device to my bank and it’s convenient and not fragile at all. I message friends over iMessage and there’s nothing inconvenient or fragile about that.
If a developer can’t put together a solution that’s convenient and robust, it’s likely due to lack of experience, not anything inherent to E2EE.
The only difficult part of E2EE is establishing trust. As in: how do I securely exchange encryption keys with this other entity in a way I know isn’t being spoofed?
The online banking I do all the time is E2EE from my device to my bank and it’s convenient and not fragile at all. I message friends over iMessage and there’s nothing inconvenient or fragile about that.
If a developer can’t put together a solution that’s convenient and robust, it’s likely due to lack of experience, not anything inherent to E2EE.
I respectfully disagree.
E2EE is often difficult because it involves 2 or more parties at either end. You must exchange keys in some secure way and that should occur over a P2P/alternate channel. That is really hard to do when you're not in physical proximity.
In this case, you own both sides _and_ it's likely that both devices will be on the same network to connect P2P. Many of these wifi devices handle initial setup with a device2device connection that then does the Wifi hand-off.
E2EE is often difficult because it involves 2 or more parties at either end. You must exchange keys in some secure way and that should occur over a P2P/alternate channel. That is really hard to do when you're not in physical proximity.
In this case, you own both sides _and_ it's likely that both devices will be on the same network to connect P2P. Many of these wifi devices handle initial setup with a device2device connection that then does the Wifi hand-off.
You can exchange keys securely over an untrusted channel.
https://en.m.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_e...
https://en.m.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_e...
That doesn't solve the problem of knowing if the other end is who they say they are. That's why we have CAs, but those are an extra entity you need to trust.
[deleted]
Not sure how that changes much here. You know this, I know this, the average Joe without much tech knowledge does not.
IoT companies lie all the time, and when they don’t lie they fail to implement proper security by some omissions or sloppy engineering. Either way, my opinion is that IoT as the industry is a complete clusterfuck.
Just an anecdote. I’ve reverse engineered a cat feeder with a camera some months ago. It did not claim any local storage, but it happily claimed all the standard bullshit about having the “military-grade” secure encryption. As a matter of fact, for whatever reason, they chose to not encrypt P- and B-frames, only I-frames (and audio). I’m not really an expert on video encoding but even I immediately understood that this is absolutely a bad idea, as all the motion vectors are right there in plain for whoever has access to the recording in the cloud (or wherever the appliance is told to upload, any S3-compatible storage works). Still, I don’t think it was malicious, just some engineer somewhere being very ignorant or not caring about the product (or probably both). They’ve been told to throw in encryption, they ticked that box.
Now, the thing is, it seems to be based on a couple SDKs (a mix of Tyua and Goke stuff) that’s used by millions of devices - not just pet feeders but security and nanny cameras too. And while I don’t know for sure because it’s the only device with a camera I’ve worked on, I kinda doubt it’s a design error unique to my particular device or vendor.
And I’m very sure it’s not an isolated incident. I had RE’d other devices that were using other SDKs and while none of the devices had any PII (like a video feed) because it was mostly lights - I have seen a lot of very sloppy engineering. Just that blast radius of a smart light is smaller so I had cared less.
I wouldn’t trust any camera on the market unless it’s either vouched for by some hacker, or if manufacturer would explicitly recommend setting up a dedicated isolated VLAN for it, in a way it is never able to talk to anything outside my LAN.
Just an anecdote. I’ve reverse engineered a cat feeder with a camera some months ago. It did not claim any local storage, but it happily claimed all the standard bullshit about having the “military-grade” secure encryption. As a matter of fact, for whatever reason, they chose to not encrypt P- and B-frames, only I-frames (and audio). I’m not really an expert on video encoding but even I immediately understood that this is absolutely a bad idea, as all the motion vectors are right there in plain for whoever has access to the recording in the cloud (or wherever the appliance is told to upload, any S3-compatible storage works). Still, I don’t think it was malicious, just some engineer somewhere being very ignorant or not caring about the product (or probably both). They’ve been told to throw in encryption, they ticked that box.
Now, the thing is, it seems to be based on a couple SDKs (a mix of Tyua and Goke stuff) that’s used by millions of devices - not just pet feeders but security and nanny cameras too. And while I don’t know for sure because it’s the only device with a camera I’ve worked on, I kinda doubt it’s a design error unique to my particular device or vendor.
And I’m very sure it’s not an isolated incident. I had RE’d other devices that were using other SDKs and while none of the devices had any PII (like a video feed) because it was mostly lights - I have seen a lot of very sloppy engineering. Just that blast radius of a smart light is smaller so I had cared less.
I wouldn’t trust any camera on the market unless it’s either vouched for by some hacker, or if manufacturer would explicitly recommend setting up a dedicated isolated VLAN for it, in a way it is never able to talk to anything outside my LAN.
It might be difficult, but it's possible to send encrypted push notifications as you mention, and you don't get to make the E2EE claims until you actually do it. I don't think UniFi or most other cameras claim anything like Eufy did.
Fair point that their marketing explicitly says this stuff is end-to-end encrypted. Seems like an obvious gap in validation/coverage of their network comms.
This article seems confused about the claims it's making.
The embedded Tweet shows that the thumbnails for push notifications are stored on AWS as a secret URL. Thats not great, but also expected for the convenience of having push notifications include media.
The part about VLC seems to be a completely different issue.
> This week, we repeatedly watched live footage from two of our own Eufy cameras using that very same VLC media player, from across the United States — proving that Anker has a way to bypass encryption and access these supposedly secure cameras through the cloud.
The part about streaming from across the United States is irrelevant. Just because can be accessed over the internet doesn't mean it's using "the cloud."
And of course Anker has the capability to access streams. They allow you to login to the app using a username and password and then start streaming from your devices. Them abusing that capability was always a risk.
The embedded Tweet shows that the thumbnails for push notifications are stored on AWS as a secret URL. Thats not great, but also expected for the convenience of having push notifications include media.
The part about VLC seems to be a completely different issue.
> This week, we repeatedly watched live footage from two of our own Eufy cameras using that very same VLC media player, from across the United States — proving that Anker has a way to bypass encryption and access these supposedly secure cameras through the cloud.
The part about streaming from across the United States is irrelevant. Just because can be accessed over the internet doesn't mean it's using "the cloud."
And of course Anker has the capability to access streams. They allow you to login to the app using a username and password and then start streaming from your devices. Them abusing that capability was always a risk.
>The part about streaming from across the United States is irrelevant. Just because can be accessed over the internet doesn't mean it's using "the cloud."
You're forgetting about the part where the video was supposed to be E2E encrypted.
You're forgetting about the part where the video was supposed to be E2E encrypted.
It’s a shame they don’t seem to want to support Apples HomeKit Secure Video platform on their new devices. At least with apple we can trust everything stays local.
The Eufy cameras I do have that support home kit, I’ve blocked internet access to them from my router and can only access them through Apples Hone app.
That said I do recommend blocking internet to all cameras and use a self hosted app like Scrypted or Homebridge to manage your cameras
The Eufy cameras I do have that support home kit, I’ve blocked internet access to them from my router and can only access them through Apples Hone app.
That said I do recommend blocking internet to all cameras and use a self hosted app like Scrypted or Homebridge to manage your cameras
Heck, I went beyond blocking and just pulled the Ethernet. The only time I need to look at the DVR is when my house has been broken into.
The root of the problem here is that there is this idea that “cloud storage“ or “network access” can be private.
The root of the problem here is that there is this idea that “cloud storage“ or “network access” can be private.
I recall that there was a trick to block Eufy from phoning home by connecting them to a Wifi network that connects to the internet only through a custom DNS server that blocks all the Eufy specific hosts.
I am not sure about it but was wondering if anyone has done it successfully so far?
I have Eufy cameras too but never trusted them for security, although they are pretty reliable for me from a service perspective.
I am not sure about it but was wondering if anyone has done it successfully so far?
I have Eufy cameras too but never trusted them for security, although they are pretty reliable for me from a service perspective.
> there’s no proof yet that this has been exploited in the wild
Give it a few days.
Give it a few days.
If you want a truly local camera system with all the fancy features, check out Home Assistant (homeassistant.io) and Frigate (https://github.com/blakeblackshear/frigate).
My biggest concern about setting up a camera system is not about the fancy features, but about the camera hardware itself and its firmware. Frigate recommends[1] only Chinese devices, which is a deal breaker for me. Yes, I could restrict them from accessing the internet, put them behind a VLAN or VPN etc., but it's a hassle. I would ideally like to trust the device that handles such sensitive data, and not have to fight it.
Do you have a recommendation of a reputable camera manufacturer? Or failing that, a device that can be flashed with trusted open source firmware?
At this point I'm ready to just use an old Android phone instead. It's ridiculous how seemingly nobody in this industry is capable of producing trustworthy products.
[1]: https://docs.frigate.video/hardware
Do you have a recommendation of a reputable camera manufacturer? Or failing that, a device that can be flashed with trusted open source firmware?
At this point I'm ready to just use an old Android phone instead. It's ridiculous how seemingly nobody in this industry is capable of producing trustworthy products.
[1]: https://docs.frigate.video/hardware
IP CCTV systems which are set up correctly are always air-gapped, because the firmware of all of them - yes all of them, including the EU/US premium vendors - is insecure crap. Separate CCTV network/VLAN costs essentially nothing and is extremely effective.
There's no open source firmware for any of this because you're in the image processing badlands, where everything is proprietary, triply patented and only available under quintiplicately signed NDA. For a lot of the image sensors you can't even freely get the "marketing copy" version of the datasheet, let alone a full datasheet. The closest thing would be a Raspberry Pi with the HQ camera, since the necessary blobs are made available through the RPi Foundation. In terms of image quality in low light that will be more than a full order of magnitude worse than a 230 $ 4K Dahua with an 1/1.2" IMX485 (e.g. IPC-Color4K-X/T / DH-IPC-HFW5849T1-ASE-LED). The 5442 Dahua models are even cheaper (though accordingly worse than the models with the larger sensors; these have the same pixels). Planning a good CCTV system that actually fulfills the requirements (you do want to have an idea what you want to achieve with it) is not as simple as buying a kit of four ultra-wide wifi cameras and slapping them on the outside of the house.
All consumer CCTV cameras are useless crap in comparison to these; no known exceptions.
There's no open source firmware for any of this because you're in the image processing badlands, where everything is proprietary, triply patented and only available under quintiplicately signed NDA. For a lot of the image sensors you can't even freely get the "marketing copy" version of the datasheet, let alone a full datasheet. The closest thing would be a Raspberry Pi with the HQ camera, since the necessary blobs are made available through the RPi Foundation. In terms of image quality in low light that will be more than a full order of magnitude worse than a 230 $ 4K Dahua with an 1/1.2" IMX485 (e.g. IPC-Color4K-X/T / DH-IPC-HFW5849T1-ASE-LED). The 5442 Dahua models are even cheaper (though accordingly worse than the models with the larger sensors; these have the same pixels). Planning a good CCTV system that actually fulfills the requirements (you do want to have an idea what you want to achieve with it) is not as simple as buying a kit of four ultra-wide wifi cameras and slapping them on the outside of the house.
All consumer CCTV cameras are useless crap in comparison to these; no known exceptions.
> the image processing badlands, where everything is proprietary, triply patented and only available under quintiplicately signed NDA. For a lot of the image sensors you can't even freely get the "marketing copy" version of the datasheet, let alone a full datasheet.
A friend of mine took a job as a "sales representative" for a company that makes microchips to be used in missiles.
Her duties were to respond to people who contacted her to ask about pricing. This meant determining who they were and what company they represented, and checking them against a list of known customers. Or, if they weren't already a known customer, verifying the existence of their company. In either case, she'd inform them of the price and then have to record the steps taken, the fact that a price was released, and the company the price was released to.
What I found slightly surreal about all this was the fact that, despite the intense paperwork requirements, there was only one price (per product). Everyone got the same price. It is not obvious to me why so much effort is devoted to maintaining the secrecy of a uniform price, especially when strangers are allowed to contact you and learn the price.
(Also of note, my friend was trained by her predecessor that, because it was so much work to verify incorporation papers, it was fine to just release the price to an unknown customer and do the verification when and if the customer actually wanted to make a purchase.)
A friend of mine took a job as a "sales representative" for a company that makes microchips to be used in missiles.
Her duties were to respond to people who contacted her to ask about pricing. This meant determining who they were and what company they represented, and checking them against a list of known customers. Or, if they weren't already a known customer, verifying the existence of their company. In either case, she'd inform them of the price and then have to record the steps taken, the fact that a price was released, and the company the price was released to.
What I found slightly surreal about all this was the fact that, despite the intense paperwork requirements, there was only one price (per product). Everyone got the same price. It is not obvious to me why so much effort is devoted to maintaining the secrecy of a uniform price, especially when strangers are allowed to contact you and learn the price.
(Also of note, my friend was trained by her predecessor that, because it was so much work to verify incorporation papers, it was fine to just release the price to an unknown customer and do the verification when and if the customer actually wanted to make a purchase.)
Zero Trust is a better way, for me that means my IoT and Camera's are on a completely seperate vLAN and Wifi network with zero internet access. HA is the bridge between the 2 networks, HA is the only device on both networks.
So even if the the Camera's want to phone home, they have zero path to do so
So even if the the Camera's want to phone home, they have zero path to do so
> Yes, I could restrict them from accessing the internet, put them behind a VLAN or VPN etc., but it's a hassle
Even if you find goldilocks IoT devices with completely open hardware/firmware/software and no backdoors, if they’re accessible from the internet, you’re still on the hook for maintaining their security forever. To me, monitoring and patching vulnerabilities for a bunch of different IoT devices is a _much_ bigger hassle than setting up a few VLANs.
So if you’re going to isolate the devices regardless, you shouldn’t really care if they’re running firmware written in China with a bunch of backdoors.
Even if you find goldilocks IoT devices with completely open hardware/firmware/software and no backdoors, if they’re accessible from the internet, you’re still on the hook for maintaining their security forever. To me, monitoring and patching vulnerabilities for a bunch of different IoT devices is a _much_ bigger hassle than setting up a few VLANs.
So if you’re going to isolate the devices regardless, you shouldn’t really care if they’re running firmware written in China with a bunch of backdoors.
> It's ridiculous how seemingly nobody in this industry is capable of producing trustworthy products
Apple HomeKit and Eve Cam. My choice.
Apple HomeKit and Eve Cam. My choice.
You still need to block internet access to the camera via your router once it’s setup with HomeKit
I traced it, Cam does not talk to outside. But yes, its still wise to block
Anker is also very much Chinese. It just pretends to be from the US.
Debunked, this is just clickbait: https://youtu.be/a_rAXF_btvE
LTT has already replied to this, and no, it's still very much a problem. https://youtu.be/Luz82RG5PqA?t=160
Linus was out of his depth with this discussion. When it was brought up on the WAN show it was clear to me he didn’t understand enough to offer an educated opinion.
Is this the video where Linus talks about how RCE is only something that happens in the movies? I wish he would realize that people actually think he knows what he’s talking about and be a bit more careful.
You misunderstood that then. He wasn't saying that at all. He was just saying that simply having a port open isn't an automatic RCE, because there needs to be something that listens on that port that has a vulnerability to exploit. A simple web API is not that likely to have a vulnerability if the dev of the API did their job correctly.
Given the hourly updates from CVE, I am exceedingly sceptical that an online device, let alone a cloud system, can be invulnerable.
https://twitter.com/CVEnew/
https://twitter.com/CVEnew/
Sounds like you have the same misunderstanding that Linus has. Shellshock would like a word with you. Imagemagick is in line behind it, and after that are the majority of IoT devices (including several camera manufacturers).
> if the dev of the API did their job correctly
You're not wrong, but we can see the current setup the devs came up with and I don't think they have either the time or skill to build a secure local server app.
The sad fact of the matter is that most IoT devices with publicly accessible web servers are feeding grounds for botnets within a few years after release.
You're not wrong, but we can see the current setup the devs came up with and I don't think they have either the time or skill to build a secure local server app.
The sad fact of the matter is that most IoT devices with publicly accessible web servers are feeding grounds for botnets within a few years after release.
Did you know Microsoft Defender had a wormable RCE not long ago? It executed things it thought looked like javascript. Oh and by the way, it runs with the highest privilidges in Windows :)
I mean it's not that debunked, I was able to confirm that the homebase will send unencrypted video to mediaserver-usa3.eufylife.com (hosted in ec2 at the time of writing) when I request a video stream while logged into mysecurity.eufylife.com in about half an hour most of which was deciding the best place to packet capture.
Its very much sending video data to the cloud upon request.
Its very much sending video data to the cloud upon request.
Thanks for the video. That is well-done.
Not sure it's deliberate clickbait, though. That speaks to intent.
Not sure it's deliberate clickbait, though. That speaks to intent.
True, I suppose it's just reporters capitalizing on outrage without actually doing much research. Not sure if that's much better though.
This video is full of questionable stuff. Images within notifications don't need to be hosted on an internet-facing service without authentication, for example, they can use authentication just fine. They don't even need the cloud for anything but basic signalling (thanks, Apple and Google, for forcing your proprietary notification servers on every app). Authenticated peer to peer protocols (and failing that, end-to-end encrypted protocols) are everywhere and most of us use them every day. The reliance on cloud stuff isn't because it's impossible to live up to the claims on their website, it's because doing what they claim to be doing is hard and piping everything through Amazon is easy.
The video also seems to confirm that content is in fact mirrored on the internet, which Eufy promised not to do. It also claims that Eufy chose to not do local-only processing for facial recognition for performance reasons, which is entirely valid were it not for the local-only promises.
The GDPR regulations do not necessarily apply to user content in the context of account deletion; content, which by the promises of the seller's website, should've never left the device in the first place. The 30 day limitation of deletion requests is not related to deleting files, it's merely the maximum response time for the company upon receiving a correction or deletion request. If the GDPR were involved at all, Amazon should be listed as a data processor in the privacy policy, which it isn't, so that would be illegal. Even still, "we legally have the right to keep your data even longer" is a dickish excuse for not quickly throwing out the access keys/encryption keys/data for deleted accounts/files.
The video completely glosses over the complete breach of trust Eufy committed by saying "some parts of the initial reporting are exaggerated". Eufy did in fact lie about the security of its product and they lied about how it works. This is a huge blemish on the good name of Anker.
The video also seems to confirm that content is in fact mirrored on the internet, which Eufy promised not to do. It also claims that Eufy chose to not do local-only processing for facial recognition for performance reasons, which is entirely valid were it not for the local-only promises.
The GDPR regulations do not necessarily apply to user content in the context of account deletion; content, which by the promises of the seller's website, should've never left the device in the first place. The 30 day limitation of deletion requests is not related to deleting files, it's merely the maximum response time for the company upon receiving a correction or deletion request. If the GDPR were involved at all, Amazon should be listed as a data processor in the privacy policy, which it isn't, so that would be illegal. Even still, "we legally have the right to keep your data even longer" is a dickish excuse for not quickly throwing out the access keys/encryption keys/data for deleted accounts/files.
The video completely glosses over the complete breach of trust Eufy committed by saying "some parts of the initial reporting are exaggerated". Eufy did in fact lie about the security of its product and they lied about how it works. This is a huge blemish on the good name of Anker.
eufy/anker are fucking useless.
https://community.security.eufy.com/t/major-flaw-delete-home...
I spent ~1 month full-time savings on a camera kit, cameras + base station. I was to be able to return the product for a refund (NZ law), I luckily found that thread within 24 hours of buying that SHIT.
p.s. don't confuse an existing good NZ law with our current inept government (i.e. we have a female Trudeau)
https://community.security.eufy.com/t/major-flaw-delete-home...
I spent ~1 month full-time savings on a camera kit, cameras + base station. I was to be able to return the product for a refund (NZ law), I luckily found that thread within 24 hours of buying that SHIT.
p.s. don't confuse an existing good NZ law with our current inept government (i.e. we have a female Trudeau)
That’s insane. My understanding is that if someone knows how to, they can destroy all of your locally stored footage by pressing and holding a button?
This seems easy enough to remove from the firmware and migrate to software, protected by some kind of auth layer.
This seems easy enough to remove from the firmware and migrate to software, protected by some kind of auth layer.
A baddy gets the camera, holds the button for some time and that resets the camera (disassociates the camera from the base station). The recordings for that camera on the base station are now gone because they are encrypted and rely on the association the camera had.
Eufy refused to fix the problem. It was something that could have been fixed with a firmware update via its app.
It was a shame, the cameras were good but the product overall wasn't fit for purpose (due to their incompetence).
Eufy refused to fix the problem. It was something that could have been fixed with a firmware update via its app.
It was a shame, the cameras were good but the product overall wasn't fit for purpose (due to their incompetence).
p.s. I use the term encrypted loosely, the mechanism could be as basic as a unique file name... whatever it is the association to the existing footage is lost.
>Keep Privacy in Your Hands
>HomeBase uses local storage kept off of cloud servers to ensure that only you are reviewing your data.
From: https://web.archive.org/web/20221003175526/https://us.eufy.c...
Even if it's just a thumbnail - their copy is crystal clear about the fact that your data does not end up on the cloud. They are then putting data on the cloud.
They claim:
>Safe and Private
>Your videos and other data is stored privately in your own home behind 3-step military-grade AES-128 encryption. Only you have the key to access.
Their marketing is very clear. They sold devices based on this claim, and violating it to any extend is unacceptable.