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.
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.
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.
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.
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.
> 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 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.
It's like saying we pay our interns, but the payment is $0.01 per century. It's not true.
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.
Edit: I did miss a key paragraph—they keys are also 16 bits–port enumeration was just the first place my mind went.
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.