With Home Automation and Internet of Things (IoT), there is always a concern over security. As a user of Ring Pro, a thread on reddit's /r/homeautomation caught my attention when a user found that the Ring Pro was sending packets to China.
So recently installed a ring doorbell and found some interesting network traffic.
At random intervals, it seems to be sending a UDP/1 packet to 22.214.171.124 (China). All other traffic goes to AWS.
Anyone have any thoughts to iot devices calling back to China
This caught my attention so I sent a tweet out to Ring with a link to the thread and never had a chance to look back. After doing so, I was somewhat alarmed at what their VP of security had to say:
Hi I'm the VP of Security at Ring and I thought it might be helpful to give you all some background on what you are seeing.
Occasionally at the end of live call or motion, we will lose connectivity. Rather than abandoning the entire call, we send the last few audio packets that are corrupted anyway to a non-routable address on a protocol no one uses. The right way to do that is to use a virtual interface or the loopback to discard the packets. The choice to send it to somewhere across the world and let the ISP deal with blocking is a poor design choice that the teams on working on addressing ASAP.
From a risk/disclosure perspective, it's relatively benign but like the everyone else, when my team first saw it in the wild we had similar concerns.
i will circle back when we have updated firmware.
I'm not a security expert, but I smelled some nonsense being spewed. Luckily, /u/33653337357_8 also felt the same and went through the post and laid out some concerns.
This is ridiculous. You are trolling, right? Let's pretend you were even going to do this ridiculous technical implementation and you didn't have an explicit loopback. Why can't you just drop? Why would you pick some random address (not even RFC1918)? Why not just send it to the IP address of the Ring device itself? Or how about the default gateway? Why not 127.0.0.1 and maybe it makes it out to be blocked by an egress filter but at least it doesn't get to a routable public network.
The state of IoT security is already poor - and this is is what Ring does to deal with "end of call" packets? Come on.
Sorry Matt, but I am going to have to pull your response apart a bit more here.
This is what the traffic looks like (from /u/sp0di):
10:06:12.263764 6c:0b:84:f9:df:fc > 90:6c:ac:84:51:9e, ethertype IPv4 (0x0800), length 214: (tos 0x0, ttl 64, id 6080, offset 0, flags [DF], proto UDP (17), length 200)
10.23.1.125.51506 > 126.96.36.199.1: [udp sum ok] UDP, length 172
13:10:22.224408 6c:0b:84:f9:df:fc > 90:6c:ac:84:51:9e, ethertype IPv4 (0x0800), length 214: (tos 0x0, ttl 64, id 5547, offset 0, flags [DF], proto UDP (17), length 200)
10.23.1.125.51506 > 188.8.131.52.1: [udp sum ok] UDP, length 172
Occasionally at the end of live call or motion, we will lose connectivity. Rather than abandoning the entire call, we send the last few audio packets that are corrupted anyway to a non-routable address on a protocol no one uses.
This is not a non-routable address (184.108.40.206). This is 220.127.116.11/15 owned by Baidu.
% Information related to '18.104.22.168 - 22.214.171.124'
inetnum: 126.96.36.199 - 188.8.131.52
descr: Beijing Baidu Netcom Science and Technology Co., Ltd.
descr: Baidu Plaza, No.10, Shangdi 10th street,
descr: Haidian District Beijing,100080
UDP is a protocol no one uses? Do you mean port 1 (tcpmux)? What exactly happened to your end point (the other host) and why aren't packets just continuing to be sent there, even if they are disregarded on that side?
"we send the last few audio packets that are corrupted anyway to a non-routable address on a protocol no one uses"
"The choice to send it to somewhere across the world and let the ISP deal with blocking is a poor design choice"
are mutually exclusive statements.
How does a non-routable address make "somewhere across the world" so an "ISP [can] deal with blocking"?
It has now been confirmed by two users that Ring is using a fixed source port, destination, and destination port. This means that Ring is effectively poking a UDP NAT hole that would allow return traffic to traverse the NAT gateway and reach the Ring.
Static source port: 51506
Static destination: 184.108.40.206
Static destination port: 1
In a very theoretical scenario, let's say this transmits periodically (which it does), then this would keep open a NAT translation on your edge router and many common NAT devices will use the same OUTSIDE source port if it isn't already in in use for translation.
Traffic sourced from 220.127.116.11:1 and destined for yourip:51506 would reach the Ring device. Let's now pretend the Ring has a backdoored firmware that is simply waiting for a UDP packet to show up and provide an IP for the next command and control channel. In theory, it would only require 2^32 packets to hit every host on the Internet. You can now simply spray every host with one packet and wait to see who shows up.
I'm going to assume this isn't a backdoored firmware, but it very easily could be and the attack vector looks plausible.
**Matt, I think you need to provide a little more information. This isn't adding up.**
What's concerning is that a VP of Security said that throwing packets onto the internet and hoping they get dropped is better than locally disposing of them on a null interface or with a static route on the device itself and that leaving a port open on your egress gateway is not a security concern.
The above is very concerning especially with the Vault7 leaks just a few days ago. Now I will try not to attribute malice to what could be an oversight but I would hope that someone at Ring would give a hoot about securing their devices and properly routing data themselves. Hopefully they fix this and take a look at other security concerns that may be brought up.
In the mean time, I am trashing all packets for 18.104.22.168:1 via an ACL and plan on taking some pcaps to verify that nothing is making it to the outside.
EDIT: To follow up on this topic, I ran around 15 different calls through my Ring Pro with motion activation and calling using a live stream but did not see any packet destined for 22.214.171.124. There may be a specific trigger for this behavior that is not easily reproducible but a few folks on reddit were able to reproduce this but am reaching out to Ring to see if this was fixed or if there is a plan to address this.
EDIT 2: I reached out to Ring for comment and received the following response.
Thank you for contacting Ring Community Support. My name is Genero.
Our development team is fully aware and is hard at work in finding a solution to the packet routing issue you mentioned above. We expect the firmware to be released by the end of this month. We do not have an exact release date but will have more information on this subject matter as we draw towards the end of this month.
We appreciate your patients and for being a valued neighbor in the Ring Community. If you have any other questions or concerns please let us know.
Ring Community Support
At least that's a start.