Featured Article

Idle Network Activity of an Amazon Echo

Not too long ago, I acquired an Amazon Echo. It's certainly a nifty gadget, but the "always listening" nature of the device makes one wonder. Room audio data concerns aside, what else does the Echo access on the Internet? To look into this, I simply ran tcpdump for 48 hours and captured everything from the Echo. I intentionally never "asked Alexa" anything in order to keep the capture file limited to the Echo's background activities.

So what did the Echo do?

Power On Activity

For this analysis, I simply loaded the capture file into Wireshark and looked at the sequential contents.

Routine DHCP acquisition of an IP address 5 ICMP pings of the DHCP defined gateway address 1 ICMP ping to the 1st DHCP defined DNS (8.8.8.8) 1 DNS request for the A record on www.example.com from the 2nd DHCP defined DNS (8.8.4.4) 1 DNS request for the AAAA record on www.example.com from the 2nd DHCP DNS 1 mDNS request 1 DNS request for the A record on pindorama.amazon.com to the 1st DHCP defined DNS 1 DNS request for the A record on pins.amazon.com to the 1st DHCP defined DNS 1 SYN/ACK/FIN TCP sequence with no data to 93.184.216.34 on port 80 1 SYN/ACK/FIN TCP sequence with no data to pindorama.amazon.com on port 80 1 DNS request for the A record on www.example.net from the 1st DHCP defined DNS (8.8.4.4) 1 DNS request for the AAAA record on www.example.net from the 1st DHCP DNS 3 UDP packets with the same 136 byte payload to 3 high ports on pins.amazon.com 1 SYN/ACK/FIN TCP sequence with no data to www.example.net on port 80 At this point, the Echo negotiates a secure TLS 1.2 session with pindorama.amazon.com and proceeds to exchange data 1 DNS request for the A record on softwareupdates.amazon.com from the 1st DHCP defined DNS 1 SYN/ACK/FIN TCP sequence with no data to softwareupdates.amazon.com on port 80 At this point, the Echo negotiates a secure TLS 1.0 session with softwareupdates.amazon.com and proceeds to exchange data 1 DNS request for the A record on 1.north-america.pool.ntp.org 1 DNS request for the A record on 2.north-america.pool.ntp.org 1 DNS request for the A record on 3.north-america.pool.ntp.org 50 NTP exchanges between the identified NTP servers 2 UDP packets TBD pins.amazon.com 1 DNS request for the A record on ntp-g7g.amazon.com 1 DNS request for the AAAA record on ntp-g7g.amazon.com 1 DNS request for the A record on 0.north-america.pool.ntp.org 1 DNS request for the A record on todo-ta-g7g.amazon.com 1 DNS request for the AAAA record on todo-ta-g7g.amazon.com 1 DNS request for the AAAA record on 1.north-america.pool.ntp.org 1 DNS request for the AAAA record on 2.north-america.pool.ntp.org 1 DNS request for the AAAA record on 3.north-america.pool.ntp.org At this point, the Echo negotiates a secure TLS 1 session with todo-ta-g7g.amazon.com and proceeds to exchange data

A relative pattern of activity begins to emerge at this point. It is apparent the Echo is socially awkward and checks its watch via NTP rather fervently. When its not checking the time, the Echo hammers away at the gateway IP with ICMP pings. Additionally, it continues to perform DNS lookups on the www.example.net, www.example.com and www.example.org addresses. All of the communications from prior connections remain over TLS v1 and v1.2 links ... except the UDP packets to pins.amazon.com which remain a one-sided communique.

Following the boot activity, the remaining capture file was run over 48 hours just allowing the Echo to idle in order to see where it reached out.

ICMP

Using the basic tshark command from the Wireshark package, it's a simple action to quickly parse the capture file and identify all the ICMP activity. tshark -nr echo.cap -Y "icmp" -T fields -e icmp.type | sort | uniq -c

The Echo processed 3 ICMP types:

Type 0 - Echo Reply - 6199 hits

Type 3 - Destination Unreachable - 24 hits

Type 8 - Echo Request - 6199 hits

1549 of the pings were to the internal LAN gateway. These were a little odd as they took place over a span of 24 hours, a flurry of pings every five minutes.

3100 of the pings were to Google's DNS 8.8.8.8 and 1550 of the pings were to 8.8.4.4, Google's secondary DNS.

The destination unreachable packets seem to just be related to the natural state of network connectivity. 21 of them came from 176.32.98.204, an Amazon address in Ashburn, VA. Another 2 came from a compute host, 23.23.78.3, on Amazon AWS. The last packet was associated to an NTP host in Canada - 199.182.221.110.

NTP

Using the basic tshark command from the Wireshark package, it's a simple action to quickly parse the capture file and identify all the NTP activity. tshark -nr echo.cap -Y "ntp" -T fields -e ip.dst | sort | uniq -c

The Echo reached out to 15 NTP servers 1552 times, nearly every two minutes:

38.229.71.1 - 194 hits

45.63.71.165 - 66 hits

52.0.56.137 - 63 hits

64.113.44.54 - 117 hits

72.21.192.213 - 304 hits

132.163.4.101 - 130 hits

132.163.4.102 - 21 hits

199.182.221.110 - 125 hits

204.11.201.12 - 174 hits

204.2.134.163 - 19 hits

208.75.89.4 - 9 hits

208.88.126.226 - 203 hits

209.141.59.16 - 90 hits

209.242.224.117 - 39 hits

DNS

Using the basic tshark command from the Wireshark package, it's a simple action to quickly parse the capture file and identify all the DNS hosts it resolved. tshark -nr echo.cap -Y "dns.flags.response == 0" -T fields -e dns.qry.name | sort | uniq -c

The Echo reached out to resolve six separate domains:

device-metrics-us.amazon.com - 100 hits

pindorama.amazon.com - 23 hits

softwareupdates.amazon.com - 1 hit

www.example.com - 624 hits

www.example.net - 620 hits

www.example.org - 622 hits

The Echo equally balanced the DNS requests between my local DNS and the 8.8.8.8 Google DNS server.

TCP Connections

Using the basic tshark command from the Wireshark package, it's a simple action to quickly parse the capture file and identify all the TCP activity. tshark -nr echo.cap -Y "tcp" -T fields -e ip.dst | sort | uniq -c tshark -nr echo.cap -Y "ssl" -T fields -e ip.dst -e ssl.handshake.version | sort | uniq tshark -nr echo.cap -Y "dns" -T fields -e dns.a -e dns.resp.name| sort | uniq

The Echo reached out to 10 IP addresses over TCP:

54.239.26.180 device-metrics-us.amazon.com 470 hits 123K downloaded / 126K uploaded Traffic conducted over TLS 1.0

54.239.29.231 pindorama.amazon.com 1696 hits 158K downloaded / 163K uploaded Traffic conducted over TLS 1.2

72.21.207.109 device-metrics-us.amazon.com 511 hits 138K downloaded / 137K uploaded Traffic conducted over TLS 1.0

72.21.207.120 device-metrics-us.amazon.com 439 hits 119K downloaded / 118K uploaded Traffic conducted over TLS 1.0

93.184.216.34 www.example.com www.example.net www.example.org 3724 hits 386K downloaded / 253K uploaded The Echo just exchanged SYN and ACK TCP packets back and forth with this host.

176.32.100.25 pindorama.amazon.com 1691 hits 173K downloaded / 159K uploaded Traffic conducted over TLS 1.2

176.32.98.204 pindorama.amazon.com 2287 hits 206K downloaded / 214K uploaded Traffic conducted over TLS 1.2

176.32.99.246 - 12 hits softwareupdates.amazon.com 12 hits 4K downloaded / 3K uploaded Traffic conducted over TLS 1.0

205.251.242.52 pindorama.amazon.com 545 hits 51K downloaded / 50K uploaded Traffic conducted over TLS 1.2



UDP Connections

Using the basic tshark command from the Wireshark package, it's a simple action to quickly parse the capture file and identify all the UDP activity. tshark -nr echo.cap -Y "udp" -T fields -e ip.dst | sort | uniq -c

33% of the Echo's UDP packets were related to the aforementioned NTP and DNS traffic. However, one IP address continued to standout from the crowd and represented all of the remaining UDP traffic: