Smart Devices - Who's Calling Home?

[Teken]

I intended to post this news article the same day it was published but got side tracked. This should be a reminder to those interested in using such devices which can see, hear, and track your presence. No one should ever think or accept a vendors word that their product is incapable of being abused or circumvented from its intended purpose.

 

This goes back to why having your home connected to the cloud or accessible to the outside world is not a good idea even with the best security practices in place: https://www.forbes.com/sites/aarontilley/2017/03/22/this-smart-doorbell-was-accidentally-sending-data-to-china-until-people-started-freaking-out/#17f62c765984

 

You will note the *Ring* company did not respond to the follow up questions as to what payload was being sent along with why the chip was allowed to be defaulted in this manner. More than five years ago our team was part of a multi national effort to review similar incidents of use.

 

The most famous was a Chinese company which purchased the IBM Lenovo laptop division: http://freebeacon.com/national-security/military-warns-chinese-computer-gear-poses-cyber-spy-threat/

 

Everyday of every hour all of the operating systems we use from Mac OS, Microsoft, Linux, call home to update patches, anti virus, etc. Its up to the end user to fully understand and know what should be allowed Internet access and what metrics are being sent with your consent vs not.

 

Windows 10 since its public release is the all time *Call Home* operating system to date in its default OEM state . . . 

[elvisimprsntr]

Brought to you by the same people who developed the now abandoned Doorbot. They folded the company to get out from under their KS obligations and liability of lifetime replacement guarantee, not to mention a product reputation so bad Amazon pulled the Doorbot.

[Teken]

Brought to you by the same people who developed the now abandoned Doorbot. They folded the company to get out from under their KS obligations and liability of lifetime replacement guarantee, not to mention a product reputation so bad Amazon pulled the Doorbot.

 

LOL - I actually recall you brought that to the forum members attention last year or so. 

[Teken]

For those so inclined you can read this super long thread which initiated the whole fiasco: https://www.reddit.com/r/homeautomation/comments/5xa0h1/ring_pro_doorbell_calling_china/

[MustangChris04]

Wow, unbelievable. Thank you for sharing Teken.

 

I noticed traffic going to China on my Sophos firewall from the doorbell and my hikvision cameras. I immediately blocked a ton of IP ranges because nothing on my network has any business sending ANYTHING to China. 

[Teken]

Wow, unbelievable. Thank you for sharing Teken.

 

I noticed traffic going to China on my Sophos firewall from the doorbell and my hikvision cameras. I immediately blocked a ton of IP ranges because nothing on my network has any business sending ANYTHING to China. 

 

In the big picture for me its not a matter of where / who its going to. Its the simple fact none of this should ever happen! Its a video door bell for God sakes which should not be calling home etc. I recall fondly back in the day laughing at all the *Old School* guys on the team where the conversation was regarding the KISS principle, power of 3, and connected vs not connected appliances.

 

Its safe to say having lived through many years supporting all manner of technology and having lots of this sort of technology in my home.

 

I know first hand the value in KISS, Power of 3, and leaving mission critical infrastructure completely isolated and untethered from the Internet.

 

On a related note, as discussed in a previous *Coffee Forum* thread the USA Government is moving forward in making IoT standards with respect to Security & Operations. I am cautiously optimistic as to what the true intent is but if it forces all the market leaders and start ups to meet a basic minimum with respect to best practices and security.

 

I am on board for that aspect . . .

[jtara92101]

FWIW, I doubt any of those Ring packets actually wind-up in China.

 

I was surprised to find that a x.x.x.0 address can be a valid host address. Apparently, the firmware author was equally misinformed as myself!

 

The company's initial response indicated that the address is "un-routable". But, technically, it is only "unusable". 20 years ago, that is.

 

Prior to CIDR, any x.x.x.0 was unusable as a host address, because the .0 is reserved as a a class C subnet address. As well, .255 is was reserved as Class C broadcast address.

 

Technically, .0 and .255 can now be used as host addresses. But it is unlikely that they would successfully transit every router along the path once handed-off to the Internet.

 

The scary thing here is high-visibility "magic cloud" products like this using black-box components that apparently contain un-examined firmware that apparently has not gone through much if any security assessment.

[Teken]

FWIW, I doubt any of those Ring packets actually wind-up in China.

 

I was surprised to find that a x.x.x.0 address can be a valid host address. Apparently, the firmware author was equally misinformed as myself!

 

The company's initial response indicated that the address is "un-routable". But, technically, it is only "unusable". 20 years ago, that is.

 

Prior to CIDR, any x.x.x.0 was unusable as a host address, because the .0 is reserved as a a class C subnet address. As well, .255 is was reserved as Class C broadcast address.

 

Technically, .0 and .255 can now be used as host addresses. But it is unlikely that they would successfully transit every router along the path once handed-off to the Internet.

 

The scary thing here is high-visibility "magic cloud" products like this using black-box components that apparently contain un-examined firmware that apparently has not gone through much if any security assessment.

 

Yes they did to the Baidu network in China . . .

[jtara92101]

Yes they did to the Baidu network in China . . .

 

Did somebody at Baidu share server logs that show that?

 

These are UDP packets. UDP packets have no acknowledgement. There would be no way of knowing from the sending end whether they got there or not.

[Teken]

Did somebody at Baidu share server logs that show that?

 

These are UDP packets. UDP packets have no acknowledgement. There would be no way of knowing from the sending end whether they got there or not.

 

No, no one at Baidu shared anything with the general public.

 

That isn't the problem - The problem is, this appliance is at random intervals sends private data unbeknownst or approved by the user to third party entities.

 

The secondary link I provided offers more insight about what is happening etc.

 

RE: UDP Packets - Why would it ever matter someone or something replied back?!?! That's like asking how come the bank robber didn't take the time to explain why he's robbing you?

 

Why did the robber decide to take a specific route and not leave you a note saying why.

 

Really???

[KeviNH]

I filter the heck out of connected devices, including by destination country and reputation score.

 

Some devices are at least nice enough to transmit unencrypted, or if they do use SSL, they're dumb enough not to validate the certificate/signer and I can run them through my Netronome.  Or if you really want to confuse the heck out of these devices, give them a default gateway IP that doesn't exist (no ARP).

 

If you have a device that really needs to send email (for example, your ISY994), you can let it talk to a local machine running "smarthost" mail services and relay the mail to approved destinations only.   The tricky part is that if you are on a consumer grade of service through your ISP you won't be able to deliver email outbound using TCP/25, making for a complicated outbound delivery config (OpenSMTPd can easily be configured to deliver through GMail's TLS port, etc).

 

That said, I do the above for a living,and still think it's a hassle and should not be necessary just to get a picture of my front door.

 

In the big picture for me its not a matter of where / who its going to. Its the simple fact none of this should ever happen! Its a video door bell for God sakes which should not be calling home etc.

You'd think so, but between dynamic DNS registration, the need to check for updates, and the feature of creating a tunnel back to the server for alerting and to enable streaming connectivity for home networks with nonexistent or broken UPNP implementations (and the risks of UPNP are a whole other can of worms), it is common and accepted for IoT devices to "phone home".    Most consumers just don't care.
 
Some devices have a setting to disable these features, and an even smaller subset actually respect this setting.
 

Technically, .0 and .255 can now be used as host addresses. But it is unlikely that they would successfully transit every router along the path once handed-off to the Internet.

If you're running a big public website, you generally avoid using these just in case some ISP has a really lame anti-smurf filter (and because of the confusion an x.x.x.0 IP causes in savvy end users)

 

At the client side, I see the .0 and .255 address appear as the assigned IP of a DSL or cablemodem client device quite often -- usually the modem is on a network such that it sees either a /31 (or /32) mask or a supernet mask like /19; in either case, aside from some poorly engineered consumer products, I rarely if ever encounter these last octets being treated as "special" in modern public Internet routing.

 

If you want to play with this at home, change your router from 192.168.1.1/24 to 192.168.1.1/20
 

[jtara92101]

No, no one at Baidu shared anything with the general public.

 

That isn't the problem - The problem is, this appliance is at random intervals sends private data unbeknownst or approved by the user to third party entities.

 

The secondary link I provided offers more insight about what is happening etc.

 

RE: UDP Packets - Why would it ever matter someone or something replied back?!?! That's like asking how come the bank robber didn't take the time to explain why he's robbing you?

 

Why did the robber decide to take a specific route and not leave you a note saying why.

 

Really???

 

I read the secondary link. That's where I got the details about the x.x.x.0 address and that it's UDP.

 

Without somebody at Baidu confirming that they receive any of these packets, there is no proof that they actually get there. That's all I am saying. I think the whole thing is (fortunately) moot, because the packets will never get to that address, even if there were a server there, because routers in-between are just going to drop the packets. That is what the firmware author was counting on, and is probably valid in a practical sense.

 

Were it TCP, acknowledgement of the packets would prove (or lack of acknowledgement disprove) that they reached SOME server. As UDP provides no acknowledgement, there is no proof. There is no way of knowing that a UDP packet ever reaches any host. UDP provides no verification of correct delivery, or delivery period. 

 

The address was a poor choice in any case because of the "visuals". It LOOKS BAD but the packets will likely go no further than your modem or ISP. They should have used 127.0.0.1, or simply wrote proper code that just stops sending when the connection is lost!

 

End-end acknowledgement can be built on top of UDP using higher-level protocols. (Since you next question is... "but then how does the code know that the connection was lost...")

 

If there is anything nefarious here, it is more likely that it is a diversionary tactic. "Well, this is of no harm, so I guess this other packet going to Romania is of no harm either..." And then nobody bothers to notice that the Romanian address doesn't end in .0.

[Teken]

I read the secondary link. That's where I got the details about the x.x.x.0 address and that it's UDP.

 

Without somebody at Baidu confirming that they receive any of these packets, there is no proof that they actually get there. That's all I am saying. I think the whole thing is (fortunately) moot, because the packets will never get to that address, even if there were a server there, because routers in-between are just going to drop the packets. That is what the firmware author was counting on, and is probably valid in a practical sense.

 

Were it TCP, acknowledgement of the packets would prove that they reached SOME server. As UDP provides no acknowledgement, there is no proof. There is no way of knowing that a UDP packet ever reaches any host. UDP provides no verification of correct delivery, or delivery period. 

 

The address was a poor choice in any case because of the "visuals". It LOOKS BAD but the packets will likely go no further than your modem or ISP. They should have used 127.0.0.1, or simply wrote proper code that just stops sending when the connection is lost!

 

End-end acknowledgement can be built on top of UDP using higher-level protocols. (Since you next question is... "but then how does the code know that the connection was lost...")

 

If there is anything nefarious here, it is more likely that it is a diversionary tactic. "Well, this is of no harm, so I guess this other packet going to Romania is of no harm either..." And then nobody bothers to notice that the Romanian address doesn't end in .0.

 

In the big picture the vendor got called out and a as far as the publication - Notes a firmware release has / was pushed out. Next, it just reaffirms the general public needs to more aware of what is coming and going out of the network. Lastly, my view is there are going to be more incidents of such occurrences or breaches in security which are going to lead to a very bad outcome for some.

 

Interesting time we all live in . . .

[jtara92101]

In the big picture the vendor got called out and a as far as the publication - Notes a firmware release has / was pushed out. Next, it just reaffirms the general public needs to more aware of what is coming and going out of the network. Lastly, my view is there are going to be more incidents of such occurrences or breaches in security which are going to lead to a very bad outcome for some.

 

Interesting time we all live in . . .

 

We are agreed.

 

Surprised this took this long to be discovered.

 

We are at the mercy of white-hats who take the time to test these devices, either for personal satisfaction, altruism, or publicity. There is no non-intelligence government agency (that I know of) testing these devices to protect us.

 

Our intelligence agencies test most of this stuff. But they keep the test results to themselves. It is in their interest.

 

I would love to see a wealthy philanthropist fund some non-profit fund a testing agency for IOT security testing. Something like UL could be set-up that might eventually be funded by contributions from manufacturers, and the manufacturer then get the right to use the "seal" when their products pass. Of course, there would have to be frequent retest/test of new firmware releases and some easy means to determine if the product with CURRENT updated firmware still passes.

[Teken]

We are agreed.

 

Surprised this took this long to be discovered.

 

We are at the mercy of white-hats who take the time to test these devices, either for personal satisfaction, altruism, or publicity.

 

Our intelligence agencies test most of this stuff. But they keep the test results to themselves. It is in their interest.

 

Oh like the Vault 7 treasure trove from the CIA: https://www.wired.com/2017/03/wikileaks-shows-cia-can-hack-macs-hidden-code/

 

Keeping in mind the Obama Administration made it public policy that such zero day hacks should not be kept secret from the vendor / general public. 

 

As Peter Parker's (Spiderman) Uncle Ben said: With great power - comes great responsibility.