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.

/u/sp0di posted:

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 106.13.0.0 (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:

/u/matt-ring:

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.

-Matt

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.

**Later edit**:

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 > 106.13.0.0.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 > 106.13.0.0.1: [udp sum ok] UDP, length 172

You state....
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 (106.13.0.0). This is 106.12.0.0/15 owned by Baidu.
    % Information related to '106.12.0.0 - 106.13.255.255'
    inetnum:         106.12.0.0 - 106.13.255.255
    netname:        Baidu
    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"
and
"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"?

**Edit #2**

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.

Protocol: UDP
Static source port: 51506
Static destination: 106.13.0.0
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 106.13.0.0: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 106.13.0.0:1 via an ACL and plan on taking some pcaps to verify that nothing is making it to the outside.

Full reddit thread

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 106.13.0.0. 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.

Hello Pavan,

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.

Best,

Ring Community Support

At least that's a start.

I've subscribe to a food delivery service called HelloFresh (referral link for free trial). They send recipes and ingredients every week for my wife and I to turn into meals. It's a great service because I come in contact with ingredients I typically wouldn't pick up and we eat fresh and healthy meals at least 3 times a week. Also on the rare occasion when some ingredients are missing or spoiled, we get to play Chopped like on Food Network!

Over the past few weeks, I have had some problems with deliveries. It is frustrating because it's not cheap and the grocery shopping for the week is done with 3 full meals from HelloFresh in the equation. The problem with deliveries has been that the food arrives late and in yesterday's delivery, it didn't even arrive until a day late.

This got me thinking. I know a few folks who personally emailed CEOs of companies that they've had grievances and suggestions for and had pretty decent responses. With that fresh in my head I thought it would be a perfect chance to reach out to the HelloFresh team with not only a complaint, but a suggestion that can help quality control. I originally wrote this long letter saying they have a guy write a script that can parse the pick up time and the delivery time and see if that data is useful. But after typing it all out, it looked simple enough and figured, I may as well brush up on my Python and show them what I mean.

HF_Stats.py was born as well as the first actual post on this blog in years.

import requests
import re
import urllib.request
import datetime
from datetime import datetime

### Hello Fresh has a u, id, and e strings in the URL from their emails. Removing for privacy.
hfu = 'REMOVED'
hfid = 'REMOVED'
hfe = 'REMOVED'


## Buld HF Tracking URL with the different strings
hf_url = 'http://hellofresh.us7.list-manage1.com/track/click?u='+hfu+'&id='+hfid+'&e='+hfe

req = urllib.request.Request(hf_url)
resp = urllib.request.urlopen(req)
respData = resp.read()

fullEx = '(Picked Up|Delivered).*?(\d{2}\/\d{2}\/\d{4}\s+(\d{1}|\d{2})\:\d{2}\s(A|P)M)'
paragraphs = re.findall(r''+fullEx,str(respData))

## Time Object Created
c_Event = paragraphs[0][0]
c_Time = paragraphs[0][1]
print ("Created", c_Time)

## Time Object Picked up by Shipping Company
p_Event = paragraphs[1][0]
p_Time = paragraphs[1][1]
print (p_Event, p_Time)

## Time Delivered
d_Event = paragraphs[2][0]
d_Time = paragraphs[2][1]
print (d_Event, d_Time)

## Converting strings to find total hours between creation,arrival and delivery
t_Format = '%m/%d/%Y  %I:%M %p'
cT = datetime.strptime(c_Time, t_Format)
pT = datetime.strptime(p_Time, t_Format)
dT = datetime.strptime(d_Time, t_Format)
t_Delta = dT - pT
h_Delta = (t_Delta.days * 24)+(t_Delta.seconds/60/60 )

## Final Print Statement
print ('Hours taken from pickup to delivery', h_Delta)

In my case I found the following:

Created 02/24/2017 2:50 PM
Picked Up 02/26/2017 9:07 PM
Delivered 02/28/2017 1:47 PM

Assuming that the delivery was not refrigerated from Pickup to Delivery the entire time, the box of food was not refrigerated for 40.67 hours.
Assuming that the delivery was not refrigerated from Creation on the shipping page to Delivery, the box of food was no refrigerated for 94.95 hours.

At the end of the day, my wife and I love HelloFresh. We hope that they look at this or already look at these numbers and work on delivery times to ensure fresh food is delivered.

Thanks for reading.

 

November 15, 2016

It's been a while but I'm going to try to post every few months. I've said this before but I've gotten busy in some cool cases at work and plan on sharing some of what I've learned here as well.

Some things to look forward to:

- Some home DIY/D-I-Why
- Homebrewing
- Home Automation
- Contact Center stuff
- Dallas Spurs
- Toshi

June 10, 2015

Cisco TAC in Richardson hosts competitions annually to raise money for March of Dimes. Each team(IPCC, CUCM, etc) hosts an event and holds an entry fee and participates.

One of my colleagues was very involved with scouting and had a Pinewood Derby track that he held for his troop and we decided it 0would be a great way for us to raise money for MoD and have some fun building cars at the same time.

I had never built a derby car before so I participated in the stock class and spent one Saturday morning at John's place working on my car, cutting and shaping it to look like an ethernet cable. After some sanding and a lackluster attempt at painting I had my entry.

<Picture_of_Car>

My car placed 2nd in the stock class and our team of 3 cars won 1st place in the team class with our members placing 1st, 2nd, and 4th.

Everyone had a great time and we raised a decent amount for charity. I look forward to putting on this event again next year and will be building outlaw car next year too!

 

Our c