Month: January 2014

The AWS of Things

8982747118_b726398973You’ve no doubt heard that Google has announced it is buying Nest Labs, maker of smart thermostats and smoke alarms, for $3.2 billion in cash. In a very well written NYTimes blog post, Quentin Hardy notes that “Nest did all of it on Amazon Web Services.”

Hmm…interesting. This is the first I’ve heard about Nest running in AWS, though I admit that I’ve not really followed the home automation craze that closely. With this new knowledge, I decided to poke around and see what I could find about the AWS-based service.

A quick Google search for nest firewall ports (which is what I commonly append to a product/application term when looking for what ports are used) provided 433,000 results. Phew, that’s a lot.

After looking at several pages, the general consensus from Nest users was that port 9543/tcp needed to be allowed through their respective home routers for the product to work.

So AWS + a port 9543/tcp (for those of you keeping track at home)

One page provided the FQDN that the Nest thermostat connects to: XXXX.transport.nest.com

According to research by a couple of the forum members:

The nest does frequent dns lookups for something in XXXX.transport.nest.com, which currently maps to an amazon EC2 instance. Then it makes a TCP connection to port 9543 which it seems to hold open. This probably is so that when you go to the nest website it’s able to instantly communicate with your thermostat and not have to worry about your firewall. I think the traffic is encrypted, but it looked like a self signed SSL certificate. I didn’t dig any deeper at the time.

[N]est communicates with the server over 9543. the web client communicates to the same server on port 9443. I would assume port 9543 is just HTTP traffic. The certificate is self signed. attempts at a man in the middle attack to decrypt the ssl packets haven’t worked for me so far.

If you attempt to goto https://XXXXXXXX.transport.nest.com:9543/ in your browser you’ll be presented with the same cert. after that you will be prompted with an authentication window. I haven’t tried using any of the api’s i’ve sniffed from the web client. however i suspect they are probably very similar.

At this point, I decided I had enough information to go on to start my own research. The first thing I did was use nslookup to see what the transport.nest.com provided:

$ nslookup transport.nest.com
Server: 208.67.222.222
Address: 208.67.222.222#53

Non-authoritative answer:
transport.nest.com canonical name = transport.production.nest.com.
transport.production.nest.com canonical name = transport-service-production-909910888.us-east-1.elb.amazonaws.com.
Name: transport-service-production-909910888.us-east-1.elb.amazonaws.com
Address: 107.20.222.81
Name: transport-service-production-909910888.us-east-1.elb.amazonaws.com
Address: 54.243.109.243

What is most interesting is that Amazon’s Elastic Load Balancing (ELB) is being used, likely to help distribute the load across multiple guest instances.

Using brisket, and Robert Graham’s masscan tool, I started scanning for AWS guest instances with open 9543/tcp ports.

Figure 1 – Subnet to IP Address Mapping for 9543/tcp

subnet2ip

We really have no way of knowing if all of the Nest-related guest instances are represented in the above chart. In fact, based on a host query, at least 3 guests have FQDN’s associated with a non-default AWS public DNS name. Another 5 guests, based on returned banners, appear to be running other applications (such as SSH) on non-standard ports.

Since Nest is a widely adopted product, we could guess that the subnets with the highest number of discovered IP-to-port mappings represent the “Nest Cloud” – but that really would be a guess.

Figure 2 – Top 10 Subnets With Discovered Port 9543/tcp

top_10_subnet
Looking at it another way, the Top 10 count of detected servers look something like this:

Figure 3 – Top 10 Subnets With Counts

subnet_to_ip_square
It’s probably safe to assume that Nest is using VPC given the number of devices it has claimed to have sold to date (~1 million according to a Forbes post). Unfortunately, without getting the device-to-server count directly from Nest, I doubt we’ll ever really know the final number. It’s also probably safe to assume that the IP addresses employed by Nest are load balanced (using ELB) to the servers within its VPC network.

Photo Credit: dailyamazon via Compfight cc

Cloud Data Snapshot – AWS Gov Cloud App to App Stack

Taking another look at the AWS Gov Cloud data I wanted to see what applications (e.g. nginx, Apache, etc.) and application stacks (e.g. PHP, ASP.NET, etc.) were most commonly used for ports 80/tcp and 8080/tcp. The total number of applications (508) far exceeds the application stack count (121) so after eliminating the servers without an application stack (387) we can see the counts below.

Application Server with Application Stack

app and appstack count
How do these map? The Sankey diagram below shows the most common mapping between applications and application stacks on the AWS Gov Cloud.

Application Server to Application Stack Mapping

app_to_stack
My friend Jay Jacobs (@jayjacobs) brought up an interesting idea this afternoon. Why not see what kinds of “popularity contests” exist between applications/application stacks and public/Gov cloud hosting. Maybe I’ll dig into that in the future.

Cloud Data Snapshot – AWS Gov Cloud Global Access

Today we’ll look at the access certain countries have to AWS cloud server guest instances. Using the scan data from January 1st through 10th (inclusive) we can see in the Sankey diagram below that access to IP addresses varies by country.

Represented in this scan are scanners located within Russia, Australia, China, and the US using a number of TCP ports – as defined by the scan schedule. The diagram isn’t the easiest to read but you can click on the image to enlarge it in a new window.

scanner_to_ip

I may post the Port-to-Target Sankey diagram later today.

Scroll to top