More Eufy Flaws Found (including remote unencrypted feed viewing)

[wanderingfool2]

18 minutes ago, LAwLz said:

Care to explain how you would make that work without an external server or port forwarding?

I think there is a distinction between using the "cloud" vs using an external server to accomplish the task.

 

I haven't really dealt with Android notifications really, but I linked a stackoverflow in regards to an example bit of code.  At least from what is shown in stackoverflow you essentially create a notification service, where you can then query the server to see if there is a notification.

 

While not a good way, you could have it query the Eufy server, then if the Eufy server recognizes that there is a notification (but importantly the data isn't sent to Eufy servers).  The Eufy server sends a command to essentially open up a direct connection between the phone and the camera station.  At that stage your phone can download the image, and present it as a notification.

 

In the above primitive example all Eufy's servers would need to know is that the camera system has a notification and having it so it can establish the hole punching.  Or they could have sent the information encrypted to the cloud so that the App (which only it and the camera system should have the key) can decrypt it.  Thus not compromising the security.

[LAwLz]

5 minutes ago, wanderingfool2 said:

I think there is a distinction between using the "cloud" vs using an external server to accomplish the task.

"The cloud" is just another name for an external server. I mean, how else would you define "the cloud" if not external servers? The context of the person I was quoting also seems to indicate that they used the word "cloud" to refer to external servers.

I think your suggestion is good and probably how I would want the system to work, but your suggestions either requires an external server or port forwarding. The person I replied to said that you can send push notifications without either. I can't think of a way that is possible, which is why I asked how they would make it work.

[wanderingfool2]

12 minutes ago, LAwLz said:

"The cloud" is just another name for an external server. I mean, how else would you define "the cloud" if not external servers? The context of the person I was quoting also seems to indicate that they used the word "cloud" to refer to external servers.

I think your suggestion is good and probably how I would want the system to work, but your suggestions either requires an external server or port forwarding. The person I replied to said that you can send push notifications without either. I can't think of a way that is possible, which is why I asked how they would make it work.

I think an issue here is really about what people are talking about when they are talking about "cloud".

 

In this case, the defenders of Eufy so far refer to the "cloud" being necessary in order to hold the images for download by the cell phone.  I mean at it's heart of things you could call anything connected to the internet as working on the cloud.  Lets say in the example of a server that is performing hole punching.  I would more consider that as just a 3rd party server, and wouldn't be talking about it existing as part of the cloud.

 

You really aren't using it as a "resource" per se, instead just an intermediary to establish a communication.

 

The tl;dr you need a server to act as an intermediary, and I don't think Jad would disagree with that.  I think the issue is that we are using the term cloud in regards to how it's being used, where the cloud is referring to needing the images stored on the server.

[jagdtigger]

1 hour ago, LAwLz said:

Care to explain how you would make that work without an external server or port forwarding?

UDP hole punching to the rescue.....

[LAwLz]

10 hours ago, jagdtigger said:

UDP hole punching to the rescue.....

I don't think UDP hole punishing works the way you think it works. It typically requires a third party server to work, which would fall under the "cloud" umbrella you said you didn't need.

[Heeroo]

15 hours ago, wanderingfool2 said:

This is also a reminder to anyone who might also be trying to defend Eufy.

 

Remember Eufy was also the company that accidentally had a software update that let other users see other cameras.  There are just too many issues with Eufy, in my mind there is no reason for them to ever be redeemed as a company as they have shown time and time again that they do not have any clue when it comes to safety or security.

I see other issues with ring and booboo and Arlo too. Eufy had good hardware for a good price. Unifi is for many just too expensive. 

[Heeroo]

13 hours ago, wanderingfool2 said:

I think there is a distinction between using the "cloud" vs using an external server to accomplish the task.

 

I haven't really dealt with Android notifications really, but I linked a stackoverflow in regards to an example bit of code.  At least from what is shown in stackoverflow you essentially create a notification service, where you can then query the server to see if there is a notification.

 

While not a good way, you could have it query the Eufy server, then if the Eufy server recognizes that there is a notification (but importantly the data isn't sent to Eufy servers).  The Eufy server sends a command to essentially open up a direct connection between the phone and the camera station.  At that stage your phone can download the image, and present it as a notification.

 

In the above primitive example all Eufy's servers would need to know is that the camera system has a notification and having it so it can establish the hole punching.  Or they could have sent the information encrypted to the cloud so that the App (which only it and the camera system should have the key) can decrypt it.  Thus not compromising the security.

And how

 

13 hours ago, wanderingfool2 said:

I think an issue here is really about what people are talking about when they are talking about "cloud".

 

In this case, the defenders of Eufy so far refer to the "cloud" being necessary in order to hold the images for download by the cell phone.  I mean at it's heart of things you could call anything connected to the internet as working on the cloud.  Lets say in the example of a server that is performing hole punching.  I would more consider that as just a 3rd party server, and wouldn't be talking about it existing as part of the cloud.

 

You really aren't using it as a "resource" per se, instead just an intermediary to establish a communication.

 

The tl;dr you need a server to act as an intermediary, and I don't think Jad would disagree with that.  I think the issue is that we are using the term cloud in regards to how it's being used, where the cloud is referring to needing the images stored on the server.

The direct connection isn't reliable. Your need to use firebase on play Store at some degree, which can't do this that way. But encrypted could be possible. The apps though get killed and the notification service too, only firebase is reliable

[jagdtigger]

2 hours ago, LAwLz said:

. It typically requires a third party server to work, which would fall under the "cloud"

3rd party server != cloud, especially not when it just used to craft udp packets with alter src address....

[LAwLz]

1 hour ago, jagdtigger said:

3rd party server != cloud,

I don't see how you could define "the cloud" as something that didn't include the server you are suggesting.

I mean, you are suggesting a server which is shared between users, used on demand, and is accessed over the Internet. That is what the cloud means.

 

But it's not like it matters. The fact of the matter is that if you want to be able to deliver notifications, you most likely need to use an external server by sending data over the Internet.

You could argue that the data that needs to be transmitted is different, but to say that you don't need the server at all is just incorrect.

 

1 hour ago, jagdtigger said:

especially not when it just used to craft udp packets with alter src address....

It's still using an external server, which I think you heavily implied wasn't needed.

 

 

Also, I don't think relying on UDP hole punching would be a good idea for an application like this. That would probably result in even more backlash than this scandal.

It would be super easy to construed that revelation into "Chinese company opens ports on your phone and makes it listen to commands from their servers!" or something dumb and completely unnuanced like that.

 

 

 

 

 

I've done a tiny bit more research regarding this topic now and to me it seems like at worst this whole scandal is about false advertising. They said things worked a certain way in their ads and in reality it didn't. I do however think that people are jumping to some seemingly incorrect conclusions such as this is being done because "the Chinese government wants to spy on users!".

It doesn't help that Linus seemingly just read a headline and did barely any research (seemingly even less than I have done) and then made a grand display of the whole thing which got his army of fans to mobilize.

[Heeroo]

38 minutes ago, LAwLz said:

I don't see how you could define "the cloud" as something that didn't include the server you are suggesting.

I mean, you are suggesting a server which is shared between users, used on demand, and is accessed over the Internet. That is what the cloud means.

 

But it's not like it matters. The fact of the matter is that if you want to be able to deliver notifications, you most likely need to use an external server by sending data over the Internet.

You could argue that the data that needs to be transmitted is different, but to say that you don't need the server at all is just incorrect.

 

It's still using an external server, which I think you heavily implied wasn't needed.

 

 

Also, I don't think relying on UDP hole punching would be a good idea for an application like this. That would probably result in even more backlash than this scandal.

It would be super easy to construed that revelation into "Chinese company opens ports on your phone and makes it listen to commands from their servers!" or something dumb and completely unnuanced like that.

 

 

 

 

 

I've done a tiny bit more research regarding this topic now and to me it seems like at worst this whole scandal is about false advertising. They said things worked a certain way in their ads and in reality it didn't. I do however think that people are jumping to some seemingly incorrect conclusions such as this is being done because "the Chinese government wants to spy on users!".

It doesn't help that Linus seemingly just read a headline and did barely any research (seemingly even less than I have done) and then made a grand display of the whole thing which got his army of fans to mobilize.

It's kinda both. The remote access issue is a real one, the pictures and notifications miss wording in this setting what it does. 

[wanderingfool2]

4 hours ago, Tecardo said:

I see other issues with ring and booboo and Arlo too. Eufy had good hardware for a good price. Unifi is for many just too expensive. 

Their issues haven't been as big as Eufy.  I wouldn't recommend Ring to anyone anyways.

 

If Eufy is so willing to essentially lie or try weaseling their way out of fixing the issue that they advertised then what else are they willing to do?  Eufy boasts they aren't vulnerable to the same level of hacks, yet 2021 shows if they got hacked a hacker could view everyone's cameras.  They boast your data stays local and are caught sending data to an amazon bucket.

 

Add on that anyone with physical access to the camera can delete all the footage regarding that camera and Eufy by far is the worst company to trust.  Sure, Ring has had issues but they don't try pretending it's a "feature" instead of a bug.

 

2 hours ago, LAwLz said:

It's still using an external server, which I think you heavily implied wasn't needed.

Like I said in a previous post, it was clear @jagdtigger was using "cloud" as more of the usage of storage.  He wasn't implying you don't need a 3rd party server, he along with a whole swath of people don't feel that a 3rd party server used for hole punching constitutes as "cloud".

 

That's inherently the issue, "cloud" really didn't have a good definition back when it really became a thing...and then pretty much anything internet facing could be called a cloud as long as it's not under your control and on the internet.

 

The less strict way of looking at the cloud though is that cloud only is represented when there is a resource itself being utilized (not including network traffic).  Like using CPU cycles, or storage.

 

2 hours ago, LAwLz said:

Also, I don't think relying on UDP hole punching would be a good idea for an application like this. That would probably result in even more backlash than this scandal.

It would be super easy to construed that revelation into "Chinese company opens ports on your phone and makes it listen to commands from their servers!" or something dumb and completely unnuanced like that.

I don't think it would create scandal at all.  They would do hole punching between your phone and camera system, so the only traffic going between Eufy would be the request to setup the hole punching...which is a whole lot less traffic than what already exists between the system and Eufy.  So I doubt it would ever become a thing, because the only people who would even realize what is occurring are already smart enough to know that it's a better solution than keeping things going through the Eufy servers.

 

2 hours ago, LAwLz said:

I've done a tiny bit more research regarding this topic now and to me it seems like at worst this whole scandal is about false advertising. They said things worked a certain way in their ads and in reality it didn't. I do however think that people are jumping to some seemingly incorrect conclusions such as this is being done because "the Chinese government wants to spy on users!".

It doesn't help that Linus seemingly just read a headline and did barely any research (seemingly even less than I have done) and then made a grand display of the whole thing which got his army of fans to mobilize.

Well a large part of it is about false advertising, but that and Eufy's response to this is I believe a big part of why they cut ties.  At least one their talking on the WAN show, I think they did do adequate research.  The issue becomes that there are people who are also offering support to what Eufy did by going to what was released...like requiring cloud storage to implement notifications (which even if you never logged in and didn't accept notifications it still apparently sent it according to one article I read).

 

While not mentioned as much, Paul Moore had found the AES code (or suspects it's the AES code)...it was "ZXSecurity17Cam@", which if that truly is the decryption key for the camera feed, it is in no way safe.

Actually the bit that bothers me about this is that they claim it's E2EE, they claim it's local...and yet in 2021 they had users viewing other users cameras.  That to me screams their E2EE model is fundamentally broken.  All it would take is a compromise on Eufy's end and a malicious actor could log into anyone's Eufy camera system.

 

The tl;dr of Eufy issues:

Eufy advertising states it's yours and stored locally - it wasn't [probably enough to get Linus to axe them as a partner until it's corrected]

Eufy's "military grade encryption" is AES 128...but it appears as though the password used is quite guessable *See note, it gets worse

Eufy's response - pretty much lets hide it but keep doing it

Eufy in 2021 had an issue where other uses could see other cameras

Eufy allows the reset button on the camera to remove all clips (claims its a feature not a bug).

 

Their responses are enough to show how little they care about security, which as a security camera company they should care deeply about implementing things correctly.  (At least the WAN show's second talk on it they seemed to imply they had talked to some insiders as well, but didn't want to reveal it)

 

Big Note:

While writing this, I decided to look into a bit more into the "AES" key issue where on the WAN show they mention it's shown in plain text and it's AES 128.  It's actually a whole lot worse than what has been said.  As mentioned above Paul Moore's was "ZXSecurity17Cam@", which is pretty bad that it's guessable and shown in plain text.  In a tweet Paul Moore confirmed that using that key he was able to decrypt his local storage.

 

The worse part though...I decided to google the security key and found this
https://github.com/FuzzyMistborn/python-eufy-security/blob/dev/API.md
The modified date says 2019...using the same AES key as Paul Moore...other researchers also have come up with the same AES key...so Eufy's "military grade encryption" is literally, let's reuse the password for everyone's devices.

[LAwLz]

2 hours ago, wanderingfool2 said:

Like I said in a previous post, it was clear @jagdtigger was using "cloud" as more of the usage of storage.  He wasn't implying you don't need a 3rd party server, he along with a whole swath of people don't feel that a 3rd party server used for hole punching constitutes as "cloud".

Considering his reply my guess is that he didn't intend for that definition, but now that he has realized UDP hole punching also requires external servers that's what he is going with.

Anyway, it does fall into the definition of "cloud" so I still think he is wrong.

 

 

2 hours ago, wanderingfool2 said:

That's inherently the issue, "cloud" really didn't have a good definition back when it really became a thing...and then pretty much anything internet facing could be called a cloud as long as it's not under your control and on the internet.

I think it has a good definition. If we go to vendors like Microsoft, IBM and VMWare they all have more or less the same definition.

A centralized and shared server pool hosted by a third party that is accessible on demand through a carrier like the Internet.

I think you will find that 99,9% of IT people will describe that or something very close to that when asked what "the cloud" is. 

 

 

Anyway, I got my question answered. I was wondering how jagd was going to send notifications without using an external server and the answer is that he wasn't. 

 

 

 

2 hours ago, wanderingfool2 said:

The less strict way of looking at the cloud though is that cloud only is represented when there is a resource itself being utilized (not including network traffic).  Like using CPU cycles, or storage.

I think that's a ridiculously dumb definition of the word and I can't find anyone who uses it that way on Google, but even if that was the case a server used for UDP hole punching would still fall into that definition.

 

 

2 hours ago, wanderingfool2 said:

I don't think it would create scandal at all.  They would do hole punching between your phone and camera system, so the only traffic going between Eufy would be the request to setup the hole punching...which is a whole lot less traffic than what already exists between the system and Eufy.  So I doubt it would ever become a thing, because the only people who would even realize what is occurring are already smart enough to know that it's a better solution than keeping things going through the Eufy servers.

You'd be surprised how much people will twist the truth and ignore important details in order to drum up controversy and a story.

I mean, even in this story it seems to be a lot of half-truths and flat out misinformation. Things like the pictures not requiring authentication, or that anyone can view your stream in VLC. Complete lies. I wouldn't be surprised if the story would have been "Chinese app opens your phone up for remote connections" if UDP hole punching was used. "Why is this Chinese-made app asking your phone to open up and listen to foreign connections!? Is it a backdoor!?".

 

 

2 hours ago, wanderingfool2 said:

While not mentioned as much, Paul Moore had found the AES code (or suspects it's the AES code)...it was "ZXSecurity17Cam@", which if that truly is the decryption key for the camera feed, it is in no way safe.

Actually the bit that bothers me about this is that they claim it's E2EE, they claim it's local...and yet in 2021 they had users viewing other users cameras.  That to me screams their E2EE model is fundamentally broken.  All it would take is a compromise on Eufy's end and a malicious actor could log into anyone's Eufy camera system.

I only heard about Eufy earlier today so I don't know what their previous scandals are about, but E2EE does not make it impossible to potentially see other peoples' feeds. It is entirely possible that they use proper E2EE, and other issues caused people to be able to see each others feeds. Seeing other peoples' feed is a serious issue, but it is in no way an indication of their E2EE being broken or flawed. 

 

 

Just to be clear. I did not know about Eufy before today and I honestly don't care about them.

What I do care about is people making a bunch of assumptions on a subject as complex as IT security. There is a lot of very important details to understand when discussing this, and on top of that I think we only really have one side of the story. I haven't heard of Paul Moore before either but looking through his tweets he does not seem like a fun or nice guy. He has been calling people correcting some misinformation regarding this thing shills.

 

I haven't looked at much of what Linus said but the little I saw was hilariously stupid. 

Quote

it's a little more complicated. When you open up a port on your router you're not exposing data to the open web. You are exposing a port on your network to the open web, through which a malicious actor could potentially do something but I think it's unlikely that they would be able to... you know... it's in the movies where they can use that open port to "hack into the mainframe and gain root access to the system" and that's not, probably, going to be the issue.

Holy shit why is Linus allowed to talk about stuff he has no fucking clue about? Why does Linus think he knows everything when he clearly doesn't understand the first thing about what he is talking about!? This is so fucking infuriating because he is so clueless.

I wonder if Luke understands the issue with the above statement but was too afraid to speak up. He added a "you never know" and seemed to smile a little which to me indicates that he knows how stupid Linus was being, but didn't want to oppose his boss or risk being perceived as defending Eufy.

 

For those who don't know, this does not just happen in movies. It happens all the time in real life. Port scanning is extremely common and we absolutely do NOT want our IoT devices to start opening ports out to the Internet so that anyone who spends 10 seconds doing a port scan can see and connect straight to our devices from the Internet.

[wanderingfool2]

1 hour ago, LAwLz said:

I only heard about Eufy earlier today so I don't know what their previous scandals are about, but E2EE does not make it impossible to potentially see other peoples' feeds. It is entirely possible that they use proper E2EE, and other issues caused people to be able to see each others feeds. Seeing other peoples' feed is a serious issue, but it is in no way an indication of their E2EE being broken or flawed. 

The general concept is what is E2EE meant to protect?  Eufy can perform a MITM attack if they so choose to.  They don't even need actually anything active, they can literally access your videos if they so choose.  The use and concept of using E2EE is that you can't trust the other actors involved, and you want to implement E2EE in a way that malicious actors can't do something such as a MITM, Eufy even advertises pretty much that.  Yet the 2021 issue of User A being able to access User B's cameras shows that it's fundamentally flawed in that Eufy can initiate connections if they wish.

 

There is also the talk about using the same key for AES encryption of local footage, which tells you pretty much all you need to know.

 

1 hour ago, LAwLz said:

I think we only really have one side of the story

Eufy literally issued a press release.  They said it's required for notifications.

 

Can there be 2 sides to the story, sure...but the fact is enough information has come out which pretty much blows every statement that Eufy tried claiming in their marketing out of the water.  It's like a company trying to sell 7200 RPM but then actually selling 6800 RPM drives.  Is there a second side to the story?  Sure, but the evidence already shows what the product was claimed and marketed as is false.

 

Literally there is no excuse for encrypting local footage with the same AES key.

There is no excuse for saying your privacy matters yet uploading images to the cloud, and their excuse was we are sorry we didn't inform the users.

There is no excuse for leaving sensitive calls already unencrypted.

There is no excuse for saying your data says with you with E2EE and Eufy being able to view your cameras and footage if they so wished to.

There is no excuse for leaving in a flaw where someone holds the reset button on the camera and then destroys the camera (and now you have zero footage of what happened).

 

There might be a reasoning on Eufy's end, but they are selling a product with certain claims on it and were caught with their pants down.

 

1 hour ago, LAwLz said:

Holy shit why is Linus allowed to talk about stuff he has no fucking clue about? Why does Linus think he knows everything when he clearly doesn't understand the first thing about what he is talking about!? This is so fucking infuriating because he is so clueless.

When I heard Linus say that, I assumed he was talking about the concept of hole punching to open a port...which is pretty much safe (not much more dangerous than having the constant connection with Eufy).

 

1 hour ago, LAwLz said:

I think it has a good definition. If we go to vendors like Microsoft, IBM and VMWare they all have more or less the same definition.

A centralized and shared server pool hosted by a third party that is accessible on demand through a carrier like the Internet.

I think you will find that 99,9% of IT people will describe that or something very close to that when asked what "the cloud" is. 

Or you know, you can try actually using context of the wording used and not assume.  Like I said earlier, it was clear that Jad didn't consider using a 3rd party to hole punch as utilizing the "cloud".  For that amount, in the context of this discussion I don't either...as it's clear from any person who is trying to understand the context that cloud was referring to the cloud storage aspect.

 

Oh, and here is MS's definition

Quote

The definition for the cloud can seem murky, but essentially, it’s a term used to describe a global network of servers, each with a unique function. The cloud is not a physical entity, but instead is a vast network of remote servers around the globe which are hooked together and meant to operate as a single ecosystem. These servers are designed to either store and manage data, run applications, or deliver content or a service such as streaming videos, web mail, office productivity software, or social media. Instead of accessing files and data from a local or personal computer, you are accessing them online from any Internet-capable device—the information will be available anywhere you go and anytime you need it.

Businesses use four different methods to deploy cloud resources. There is a public cloud that shares resources and offers services to the public over the Internet, a private cloud that isn’t shared and offers services over a private internal network typically hosted on-premises, a hybrid cloud that shares services between public and private clouds depending on their purpose, and a community cloud that shares resources only between organizations, such as with government institutions.

 

Again I am saying based on how you define the cloud then anything that relies on the internet is the cloud.  Cloud never really had a clear definition originally, which is why it is being used for a bunch of things, but in general something such as a server that is acting as a hole punching tool I wouldn't really consider much as "cloud" when referring to the whole concept of this thread.

 

 

[divito]

This entire story can be summed up with, people aren't understanding plain, written English, nor much about how internet technology actually works. All they see is "China BAD" and logic goes out the window.

 

 

[wanderingfool2]

2 hours ago, divito said:

This entire story can be summed up with, people aren't understanding plain, written English, nor much about how internet technology actually works

The video you posted has faults in his analysis.

 

Like I said here, you can effectively do hole punching which eliminates his whole "port forwarding" arguement.

 

No you don't agree to having your information uploaded to the cloud by access it through Eufy's website

 

Yes there are ways to access it unencrypted

 

They use the same AES password for local storage (like everyone's is the same).

 

So enlighten use, how are we supposed to interpret it.  They claim AES military grade encryption to protect local storage, yet use the same password for multiple users.

 

They claim your data is yours and remains local, yet upload to the cloud pictures.  People are getting worked up because having things as a local storage only is a major selling feature for most people./businesses.

[LAwLz]

12 hours ago, wanderingfool2 said:

The general concept is what is E2EE meant to protect?  Eufy can perform a MITM attack if they so choose to.  They don't even need actually anything active, they can literally access your videos if they so choose.  The use and concept of using E2EE is that you can't trust the other actors involved, and you want to implement E2EE in a way that malicious actors can't do something such as a MITM, Eufy even advertises pretty much that.  Yet the 2021 issue of User A being able to access User B's cameras shows that it's fundamentally flawed in that Eufy can initiate connections if they wish.

I don't know how their system works but in general, E2EE protects against MITM attacks. Seeing someone else's feed is not necessarily a MITM attack.

I won't really comment on what happened or why since I don't know the details, but I don't think we should jump to conclusions either.

 

 

13 hours ago, wanderingfool2 said:

There is also the talk about using the same key for AES encryption of local footage, which tells you pretty much all you need to know.

Do we know this to be true, or is that an assumption? I know Paul said he managed to decrypt his locally stored footage using that key, but has someone replicated it and are we sure there aren't other safeguards in place? 

It seems like a bad idea right now, but I don't feel conformable making a definitive statement without having a better understanding of their software architecture. Again, details can be extremely important in these types of discussions.

 

 

13 hours ago, wanderingfool2 said:

There might be a reasoning on Eufy's end, but they are selling a product with certain claims on it and were caught with their pants down.

True.

Like I said earlier, to me this mostly seems like an issue of false advertising. So far I haven't seen any indication of malice however.

 

 

13 hours ago, wanderingfool2 said:

When I heard Linus say that, I assumed he was talking about the concept of hole punching to open a port...which is pretty much safe (not much more dangerous than having the constant connection with Eufy).

Nope he wasn't, because he specifically replied to a statement about port forwarding. Linus just doesn't know what he is talking about.

Also, UDP hole punching is potentially a lot less secure than what Eufy is doing. They are not at all on the same scales of dangerous. UDP hole punching is more secure than port forwarding, but it still leaves a port completely open, detectable through port scans, and since it won't have any checks such as segment boundaries or fixed ordering it is a lot easier to craft and have malicious packets accepted.

[wanderingfool2]

6 hours ago, LAwLz said:

I don't know how their system works but in general, E2EE protects against MITM attacks. Seeing someone else's feed is not necessarily a MITM attack.

I won't really comment on what happened or why since I don't know the details, but I don't think we should jump to conclusions either.

Strictly speaking E2EE only protects certain types of MITM attacks.  It strictly doesn't protect against an MITM attack where Eufy plays around with the exchanging of initial keys to communicate with E2EE.  If the protocol is better designed though, each device should be able to check the given key is the one that correlates with the other device they are connecting with.

 

There is no other plausible way in this scenario, you are welcome to try disputing it with a clear way how it isn't MITM.  Eufy admitted that it allowed User A to access User B's camera, they admitted that it was a backend software update that caused it.  Again, if multiple users are able to see other peoples cameras then one of the following must have happened.  Sessions initiated (by Eufy servers) are streaming feeds unencrypted (which breaks E2EE) or Eufy can initiate the connection and make the users exchange key without either verifying...which means they can effectively pull off a MITM.

 

7 hours ago, LAwLz said:

Do we know this to be true, or is that an assumption? I know Paul said he managed to decrypt his locally stored footage using that key, but has someone replicated it and are we sure there aren't other safeguards in place? 

It seems like a bad idea right now, but I don't feel conformable making a definitive statement without having a better understanding of their software architecture. Again, details can be extremely important in these types of discussions.

At this point though, it's better to assume it's true than assume it's false (unless Eufy comes out with a direct statement).  What we do know is that the response message does say "ZXSecurity17Cam@" it's variable is labeled as AES 128 encryption/decryption.  That key was found by multiple people as well.  I'm inclined to agree with Paul that his testing could be decrypted is correct.  After all Eufy has shown a gross absence of proper security practices. [They don't even verify the token to start the rtmp stream, as per a couple publications]

 

7 hours ago, LAwLz said:

Like I said earlier, to me this mostly seems like an issue of false advertising. So far I haven't seen any indication of malice however.

I haven't really said it's malice.  I'm saying they were incompetent enough to implement things in a way it never should be, and their laughable PR response to it.  A company that makes bold claims on security and privacy and blames things on a misunderstanding is not to be trusted.

 

7 hours ago, LAwLz said:

Nope he wasn't, because he specifically replied to a statement about port forwarding. Linus just doesn't know what he is talking about.

Also, UDP hole punching is potentially a lot less secure than what Eufy is doing. They are not at all on the same scales of dangerous. UDP hole punching is more secure than port forwarding, but it still leaves a port completely open, detectable through port scans, and since it won't have any checks such as segment boundaries or fixed ordering it is a lot easier to craft and have malicious packets accepted.

It shouldn't really be a lot less secure than what Eufy is currently doing.  It does not leave the port "completely open", it only leaves it open for the specific address.  So at that stage to do port scanning you would have to spoof the address, guess the port they are going to communicate on, know that it's an Eufy connection and know about an active exploit.

 

To address your "detectable through port scans", it would only be detectable if they are spoofing the address that the hole punch occurred on.  Then that assumes Eufy's device actually responds to the request (it could very well reject it if the proper packet isn't sent...like have a signature so they can tell a valid packet from a spoofed one).  If that is the case then port scanning becomes pretty much a non-starter.  The only way then would be a MITM attack, and that would be a lot less likely.

 

For Eufy's current implementation, you would have to compromise their Amazon bucket.  From there you would have access to the information needed to access pretty much anyone's RTMP stream.  They are different types of attacks, but I'd argue in this day and age Amazon buckets are more likely to be compromised.

 

From what I saw on the section of the WAN show, I still heavily believed that Linus was talking more in regards to hole punching, but each to their own.  Unless he clarifies, we can't really know.

 

[LAwLz]

1 hour ago, wanderingfool2 said:

If the protocol is better designed though, each device should be able to check the given key is the one that correlates with the other device they are connecting with.

Absolutely agree with that. In fact, E2EE is quite useless unless the users verifies the keys. 

 

 

1 hour ago, wanderingfool2 said:

There is no other plausible way in this scenario, you are welcome to try disputing it with a clear way how it isn't MITM.

MITM means someone is sitting in the middle of the connection and snooping. I have not found any evidence of this being the case.

It was a big security fuckup and definingly some type of attack, but not strictly speaking MITM. Again, when it comes to security the details are very important. Seeing someone else's feed is not a MITM unless your device also passes along the same feed to the intended viewer in a transparent manner, which does not seem to be the case here.

I agree with a lot of what you said, but I would strongly recommend being careful with the words you use, because they are in some cases wrong.

 

 

1 hour ago, wanderingfool2 said:

it's better to assume it's true than assume it's false

I disagree. 

 

 

1 hour ago, wanderingfool2 said:

What we do know is that the response message does say "ZXSecurity17Cam@" it's variable is labeled as AES 128 encryption/decryption.

Yes but without knowing what that code does or how it interacts with everything else we don't know how severe that issue is.

Maybe that's a seed value that is used in conjunction with something else? Maybe that's one of the passwords used by one function in the program but not necessarily an important one? 

 

 

1 hour ago, wanderingfool2 said:

It shouldn't really be a lot less secure than what Eufy is currently doing.  It does not leave the port "completely open", it only leaves it open for the specific address.  So at that stage to do port scanning you would have to spoof the address, guess the port they are going to communicate on, know that it's an Eufy connection and know about an active exploit.

If you don't know how UDP hole punching works, why write so much about it?

Again, you are making assumptions and in this particular case you are completely wrong.

UDP hole punching does leave it open to traffic from all sources. No spoofing necessary. The fact that you even say this shows that you don't understand how UDP hole punching works. The entire point is that it allows a connection from a previously unknown source. You contact a server and that server tells a different device "contact this device". 

UDP hole punching will accept traffic from any source. No spoofing is needed.

 

 

 

1 hour ago, wanderingfool2 said:

For Eufy's current implementation, you would have to compromise their Amazon bucket.  From there you would have access to the information needed to access pretty much anyone's RTMP stream.  They are different types of attacks, but I'd argue in this day and age Amazon buckets are more likely to be compromised.

Do we even know if Eufy uses Amazon buckets or is this another assumption you are making, or are you using incorrect terms?

I don't see how compromising a bucket would result in someone getting access to the feed either.

 

 

1 hour ago, wanderingfool2 said:

From what I saw on the section of the WAN show, I still heavily believed that Linus was talking more in regards to hole punching, but each to their own.  Unless he clarifies, we can't really know.

Of course Linus will say he meant UDP hole punching if he gets the chance. However, the conversation went like this:

Eufy: Port forwarding is unsafe.

Linus: No it isn't. People only use open ports as attack surfaces in movies.

 

I do not see any possible way how it can be interpreted as "Linus was talking about UDP hole punching", but even if he was it's still less secure because as I said a UDP hole punch leaves it open for anyone to connect through. Hole punched UDP ports do not check the source address. That is the entire point. The entire point is to accept a connection from a device you do not know the source from.

[wanderingfool2]

9 minutes ago, LAwLz said:

MITM means someone is sitting in the middle of the connection and snooping. I have not found any evidence of this being the case.

It was a big security fuckup and definingly some type of attack, but not strictly speaking MITM. Again, when it comes to security the details are very important. Seeing someone else's feed is not a MITM unless your device also passes along the same feed to the intended viewer in a transparent manner, which does not seem to be the case here.

I agree with a lot of what you said, but I would strongly recommend being careful with the words you use, because they are in some cases wrong.

The fact they can initiate a connection between users does mean a MITM attack is 100% possible.  They literally could setup themselves in the middle, and monitor all the communication (and feed it to the other user).  I'm not saying that they did perform a MITM attack, but the act of being able to when they are boasting about security features like E2EE is not acceptable.  It pretty much eliminates the whole purpose behind having E2EE, as the gatekeeper they are capable of MITM if they chose to (the fact that they had 2 users mix up shows that it's possible).

 

12 minutes ago, LAwLz said:

I disagree. 

When it comes to security, if everything shows as incompetence it's not safe to assume their supposed security features they talk about are true...until they demonstrate it's true.

 

17 minutes ago, LAwLz said:

Yes but without knowing what that code does or how it interacts with everything else we don't know how severe that issue is.

Maybe that's a seed value that is used in conjunction with something else? Maybe that's one of the passwords used by one function in the program but not necessarily an important one? 

You are grasping at straws though, Eufy hasn't come out denying it despite Paul bringing it up (and having Eufy's legal involved).  Again, I am going with what Paul says as Eufy hasn't denied it and they have had ample opportunities to dispel it if it were false.  Paul was the one who got all this stuff going, and forced Eufy's original response.  So it's safe to say that at this moment it's more trustworthy that he admitted he could decrypt it using that vs Eufy's radio silence.

 

24 minutes ago, LAwLz said:

If you don't know how UDP hole punching works, why write so much about it?

Again, you are making assumptions and in this particular case you are completely wrong.

UDP hole punching does leave it open to traffic from all sources. No spoofing necessary. The fact that you even say this shows that you don't understand how UDP hole punching works. The entire point is that it allows a connection from a previously unknown source. You contact a server and that server tells a different device "contact this device". 

UDP hole punching will accept traffic from any source. No spoofing is needed.

UDP hole punching does not open the port up to the entire traffic.  Do you even understand how hole punching works with UDP?

 

Here's the basics because you seem to lack knowledge.

Cmp A needs to communicate with Cmp B (Cmp B already has an established connection with Server C)

Cmp A asks server C to communicate with Cmp B

Server C sends a packet to Cmp B with Cmp A's details; and sends a packet to Cmp A with Cmp B's details (IP and port)

Now Cmp A and B both know each other's IP and port they are communicating on.

Cmp A sends an UDP packet to B on that port, and Cmp B does the same.

The firewall sees the outgoing packet, and the target IP address/source port.  IT DOES NOT OPEN UP THE PORT TO ALL TRAFFIC FROM ANY CONNECTION

 

If you have IP address 1.1.1.1 and send an UDP packet to 2.2.2.2 the firewall will only accept UDP packets back from 2.2.2.2.  If IP 3.3.3.3 decides to start sending packets on the same port your firewall will reject it.  If your firewall doesn't do that then you need a new firewall.

 

If you want to poison it you have to spoof the IP address of 2.2.2.2

 

The POINT of hole punching is to provide a channel of communication between two devices which do not have public facing ports.  It's not to open a particular port to the world.  The fact that you think that it effectively opens a port for everyone is laughable and shows your lack of knowledge.

 

39 minutes ago, LAwLz said:

Of course Linus will say he meant UDP hole punching if he gets the chance. However, the conversation went like this:

Eufy: Port forwarding is unsafe.

Linus: No it isn't. People only use open ports as attack surfaces in movies.

 

I do not see any possible way how it can be interpreted as "Linus was talking about UDP hole punching", but even if he was it's still less secure because as I said a UDP hole punch leaves it open for anyone to connect through. Hole punched UDP ports do not check the source address. That is the entire point. The entire point is to accept a connection from a device you do not know the source from.

Just like how you thought Jad was talking about not needing "cloud" to mean not using a 3rd party server and saying no one would understand...yet somehow you were the only one who seemed to misunderstand.

 

40 minutes ago, LAwLz said:

Do we even know if Eufy uses Amazon buckets or is this another assumption you are making, or are you using incorrect terms?

I don't see how compromising a bucket would result in someone getting access to the feed either.

It's been known that they use AWS Buckets, they have already had one partial breach of AWS buckets before.  It's mentioned in the articles.  I am using the correct terms, so stop talking down to me as if I am some uneducated buffoon when you can't even get facts like UDP hole punching correct.

 

[divito]

15 hours ago, wanderingfool2 said:

No you don't agree to having your information uploaded to the cloud by access it through Eufy's website

He was explaining it as the likely stance of Eufy to make their features work. I agree that it should be explicitly stated as such as opposed to unmentioned.

Plus, given that they've been audited in the EU, who are heavy pro-individual and privacy and love giving out fines, I think they're operating just fine.
 

15 hours ago, wanderingfool2 said:

Yes there are ways to access it unencrypted

Still yet to see actual proof of this. Possible != likely or practical. Kind of how most people fearmonger vulnerabilities but fail to mention you need physical access among other hurdles.

Screen grab by this wasabi person is questionable even; he's an owner of the camera and thinks outside network access is special when it's a feature. When he can access a stranger's camera, then it'll be more believable. He's refused to do this though.

Even The Verge has backpedaled slightly from their original claims. Paul Moore also went quiet and did a 180 on his campaign to out Eufy, magically giving them time to "investigate." If he was adamantly correct and crusading, this doesn't jive for me.
 

15 hours ago, wanderingfool2 said:

They use the same AES password for local storage (like everyone's is the same).

Haven't seen any article mention this outside of pure speculation, link of proof?

 

15 hours ago, wanderingfool2 said:

They claim your data is yours and remains local, yet upload to the cloud pictures. People are getting worked up because having things as a local storage only is a major selling feature for most people./businesses.

This is one of those plain English things I mentioned before. and this 'uploading' is explained in several articles and the video I shared.

 

The data is yours, and it remains on your local hardware until you delete it. I've tried to find reference to this "local only" claim people keep repeating, but I've yet to find it. The closest thing is one of their marketing images saying "your private data never leaves the safety of your home, and is accessible by you alone."

1. I've yet to see a non-Eufy owner accessing video streams or images. Most accusations have come from Eufy owners that already have been authed, or logged in from their devices that have used the software. Not sure people realize that apps and devices save such information and it's not magically flushed away most of the time. You can argue about the security of such practices, but still waiting for a legit non-Eufy owner using a random device to access someone's video from a camera.
 

2. I would definitely argue against two screen grabs going to the cloud for notification/feature purposes constitutes a breach of your "private data." Not to re-mention again, that Eufy complies with GDPR and those images will be gone in short order. There isn't some magical folder online somewhere with the thousands of facial screen grabs or video recordings from your cameras somewhere. I will gladly eat my words if this is ever discovered.

I think there should be a more noticeable disclaimer about how notifications technology work on devices with such low processing power, necessitating a quick cloud intermediary; and from news reports, Eufy is apparently adding this. 

Notifications processing is done temporarily with cloud assistance; data is still stored locally. 

[wanderingfool2]

6 minutes ago, divito said:

Plus, given that they've been audited in the EU, who are heavy pro-individual and privacy and love giving out fines, I think they're operating just fine.

Being audited doesn't mean that it's valid.  Theranos was audited multiple times, and yet those audits didn't catch the fact they were faking it.  Similar to how Tesla was tested by a 3rd party yet the windshield pressure issue wasn't caught.

 

8 minutes ago, divito said:

Even The Verge has backpedaled slightly from their original claims. Paul Moore also went quiet and did a 180 on his campaign to out Eufy, magically giving them time to "investigate." If he was adamantly correct and crusading, this doesn't jive for me.

The specifics being that he was in touch with the legal department.  It could mean a bunch of things, including a potential of legal to gag him.  George Hotz is a prime example of it, he's no longer allow to "hack" any Sony products because he essentially was forced into a binding agreement.

 

17 minutes ago, divito said:

Still yet to see actual proof of this. Possible != likely or practical. Kind of how most people fearmonger vulnerabilities but fail to mention you need physical access among other hurdles.

There are a few things that lead it to be assumed true.  If you search around there are people who have connected to Eufy cameras using RTMP links.  While not 100% proof that it allows unencrypted, there are rtmp links that are talked about not rtmps.  I guess strictly speaking he could be passing in the AES keys into VLC, but that would seem like a lot of work.

 

Another example would be this: https://github.com/birkir/homebridge-plugin-eufy-security/issues/10

The person had ffmpeg switch it to a rtp stream I believe, but the key is that he used an rtmp link for eufy.  The rtmp link matches approx. what Wasabi posted (the snippets that were posted).  There were other help threads that I saw where people ended up effectively doing similar things (streaming the cameras using an rtmp link).  No one mentioning rtmps or rtmpe.

 

40 minutes ago, divito said:

He was explaining it as the likely stance of Eufy to make their features work.

The problem though is that you can get those features to work without the way Eufy implemented it.  When your whole shtick as a security camera company revolves around security, keeping you in control you take the extra time to implement features that don't betray that privacy.  If they want that as a feature, but it breaks their models then make it very clear that it does and make sure to only use when necessary (if you didn't log in with the phone at all it still exhibits the same behavior).

 

43 minutes ago, divito said:

Screen grab by this wasabi person is questionable even; he's an owner of the camera and thinks outside network access is special when it's a feature. When he can access a stranger's camera, then it'll be more believable. He's refused to do this though.

It was more than a screen grab.  He showed a video with him doing it to his system.

 

There is also a major issue with brute forcing it with someone else's device.  Literally doing that instantly puts you into federal crimes and more-so if Eufy or the person whose camera you accessed wished to levy charges...even if they don't want to charge you the prosecution could still decide to charge you anyways (never forget what happened to Aaron Swartz).

 

51 minutes ago, divito said:

This is one of those plain English things I mentioned before. and this 'uploading' is explained in several articles and the video I shared.

Making excuses why they had to does not make it acceptable.  It's like a bank that claims to be rob proof and when they get robbed trying to say it's okay they never stole your money.

 

How about this plain English from their privacy matters site

Quote

Whether it’s your newborn crying for mom, or your victory dance after a game,your recorded footage will be kept private. Stored locally. With military-grade encryption. And transmitted to you, and only you.

Let's see, "stored locally" yet sending to the cloud violates that.

"transmitted to you and only you" the 2021 incident proves otherwise (and shows they haven't utilized the proper protocols in regards to end user communication)

"kept private" storing on a cloud unencrypted is in no ways kept private.

1 hour ago, divito said:

Notifications processing is done temporarily with cloud assistance; data is still stored locally. 

If you save images to the cloud, NO that is not storing the data locally.  If they can't make a device that meets the needs for which they advertised for then they do not have the right to sell the product

[divito]

23 minutes ago, wanderingfool2 said:

If you save images to the cloud, NO that is not storing the data locally. 

What...If I save a file on my PC, but it is also copied to my server offsite, you consider that not stored locally?

 

I want to respond to the rest of your post but I can't take this seriously by what you just said.

[wanderingfool2]

21 minutes ago, divito said:

What...If I save a file on my PC, but it is also copied to my server offsite, you consider that not stored locally?

 

I want to respond to the rest of your post but I can't take this seriously by what you just said.

Eufy literally advertises that only storing data locally.  I missed writing the word only, but you know what you do you.  Try twisting their advertising to assuming they are innocent here or they are somehow justified.  Ask anyone to read Eufy's statements on storing data locally (prior to this) and ask if they upload your information to the cloud.  They will say no, they don't send it to the cloud

 

Ignore the fact that I posted a source which showed RTMP links, which should be unencrypted.  Keep your blindfold on.

[divito]

1 minute ago, wanderingfool2 said:

Eufy literally advertises that only storing data locally.  I missed writing the word only, but you know what you do you.  Try twisting their advertising to assuming they are innocent here or they are somehow justified.

"Storing" generally implies long-term. I disagree with your assertion that processing that notification snapshot temporarily is "storing your data." The "data" will exist on your device locally longer than AWS.

And as Eufy responded to Moore, the URLs are restricted to those authenticated devices, and are gone within 24 hours. A claim no one has been able to showcase as incorrect.

 

9 minutes ago, wanderingfool2 said:

Ignore the fact that I posted a source which showed RTMP links, which should be unencrypted.  Keep your blindfold on.

If you're talking about that Homebridge plugin thread, I agree there is an RTMP link listed, but even the users with tokens and authenticated devices were having trouble. I don't really see how that non-Eufy plugin issue relates properly to this issue. 

[wanderingfool2]

1 hour ago, divito said:

If you're talking about that Homebridge plugin thread, I agree there is an RTMP link listed, but even the users with tokens and authenticated devices were having trouble. I don't really see how that non-Eufy plugin issue relates properly to this issue. 

The RTMP doesn't utilize encryption.  You wanted proof that you could initiate a connection without encryption, well there it is.

 

Wasabi also specified that it actually doesn't verify the token (rather one of the things is that the camera itself has to almost be interacted with).  That leaves 4 bytes of protection and the serial number of the camera device, which by what Paul Moore was showing earlier might have been available unencrypted (so someone snooping could have figured it out).

 

1 hour ago, divito said:

And as Eufy responded to Moore, the URLs are restricted to those authenticated devices, and are gone within 24 hours. A claim no one has been able to showcase as incorrect.

He was able to access it after logging out, the url's aren't restricted to those authenticated devices.  They are simply have a generated token attached to them, which prior to encrypting the API calls you could have likely snooped on the data.

 

1 hour ago, divito said:

"Storing" generally implies long-term. I disagree with your assertion that processing that notification snapshot temporarily is "storing your data." The "data" will exist on your device locally longer than AWS.

That's an useless PR type of argument, trying to claim that storing implies long term.  NO if you are claiming your data stays with you and stored locally then NO it is not correct to say storing something on AWS doesn't count