My WiFi wasn't working with my old access point, so I replaced my Draytek AP700 by a Enginus ECB300 last night. After connecting to WiFi my Model S showed a new update was available, so the first thing I did was turn on 'tcpdump' on my Linux router and start sniffing all the traffic my Model S did. Some things I found out: * Model S uses a WiFi chip from Parrot: FC6050 B/W - Parrot OEM ** Seems to do WiFi, 3G and 4G * It seems to sync the time via NTP with pool.ntp.org * It uses OpenVPN to encrypt all the traffic with the Tesla servers. VPN endpoint: vpn.vn.teslamotors.com * It seems to do some plain HTTP HEAD requests to some servers at Akamai and the user agent reports: "curl/7.21.0 (arm-unknown-linux-gnueabi) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18" * It does not respond on ICMP echo-requests (ping) * During the update a FTP server opened up on Model S. I browsed through it a bit, but I forgot to download it all. Now the FTP server is offline again. * Model S does some SSDP queries in the network. The last thing shows us the Model S uses a ARM based CPU to run the internal systems. For now I haven't found anything alarming, it even seems very solid that they used OpenVPN for all the connections so we can't see what it's communicating with the Tesla servers. I'll keep sniffing and digging, for our own safety
Damn, any chance of doing a man in the middle system to get into that VPN Tunnel? I know it is possible with https traffic. I'm going to whip up something to do that before my car gets an update so as soon as I get something I can start recording all traffic the car does. and damn, if I had FTP access to the thing for just a few minutes I'd suck down the entire thing!
What kind of files were they? I'm assuming you weren't browsing the root folder. Were they files used in the updating process? Probably not. Model S wouldn't accept a connection if the key's don't match up (which they wouldn't because you would be spoofing it).
Nice find. So ARM based Linux. Do we know more about the OS? Self-made or Android? I think I read the Video chip is Nvidia?
I'm guessing they're using a modified version of an existing distro, no reason to reinvent the wheel. https://www.linux.com/learn/tutorials/598228-4-fine-linux-arm-distros-
Yep, Tegra 3's CPU core is ARM. It's running Linux but not Android, according to various reports on this forum.
Well, I didn't know the FTP server only opened up during the software update, I thought it was by default. Until it closed down about 30 minutes later I figured out it was only there during the upgrade. It showed me a couple of directories like "share", "dev", "udev", "Rx", "Tx". I don't remember seeing any files in there, but the directories "share" and "udev" clearly show us it's a Linux system, the user agent it uses shows it even more. The FTP server didn't show a banner telling me which version it was. So I can't tell if it was ProFTPd, Pure-ftpd or such. EDIT: Come to think of it, I think they are using the FTP server to update the car! They probably push the update to the car instead of pulling it. So the car spawns a FTP server which binds on *:21 and via the VPN connection their servers push the update. So you should be able to fetch the firmware while it's being uploaded. Not sure, but worth a shot.
Yes, the fun part would be to get the update file and open it up. But we'd have to have man-in-the-middle setup BEFORE the update notification on the car. I believe that by the time the car notifies us, it has already downloaded the update file.
And you can be sure the guys at Tesla are reading this so don't be surprised if the process changes a bit.
That's my point of posting it out here. Keeps the Tesla guys sharp and whatever we find they can fix it. If they see us vectoring in on possible attacks they can be a step ahead of fixing those. Because you can be sure there are people out there trying to do the same thing as we are doing, but they aren't sharing their findings.
Agree with that. However, I've know some rather complacent network engineers. I could see them sitting around a table - "well, we are vulnerable during update but it's only a small window so the risk is low". Hopefully, none of those guys work at Tesla. I'm sure someone will figure out how to spoof an update.
FTP server during update does not equal a vulnerability. Even if someone hacked into your network during your car's update (which already assumes a lot), they would not be able to side load any firmware, say a Trojan for instance. Firmware is digitally signed by Tesla and any tampered code will not be installed.
I logged in too, when the car was updating. The files are basically a database with the phonenumbers and contact information from the phones that were connected to the car. So no really interesting stuff.
Interesting WiFi Packets (Speculation) So, I finally got my Model S on WiFi in hopes it will get the 5.9 update. My home network is run by a custom Debian Linux machine for a router, so I setup a script that is using libpcap to capture traffic to/from the Model S and will send me an email alert if its bandwidth usage goes over a threshold, presumably letting me know when it is downloading an update! No update yet, but, I was poking through the packet capture a little and noticed some interesting packets. Code: No. Time Source Destination Protocol Length Info 24100 2014-03-28 05:15:59.504982 192.168.0.163 10.33.20.15 TCP 74 52802 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=36700612 TSecr=0 WS=64 24115 2014-03-28 05:16:02.511886 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 52802 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=36700913 TSecr=0 WS=64 24116 2014-03-28 05:16:08.517582 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 52802 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=36701514 TSecr=0 WS=64 24118 2014-03-28 05:16:20.534537 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 52802 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=36702716 TSecr=0 WS=64 26665 2014-03-28 07:09:53.396736 192.168.0.163 10.33.20.75 DNS 89 Standard query 0x5f0d A mothership.vn.teslamotors.com 26666 2014-03-28 07:09:53.398072 192.168.0.163 10.33.20.75 DNS 89 Standard query 0x5f0d A mothership.vn.teslamotors.com 26667 2014-03-28 07:09:53.399313 192.168.0.163 10.33.20.85 DNS 89 Standard query 0x5f0d A mothership.vn.teslamotors.com 27628 2014-03-28 07:44:06.158894 192.168.0.163 10.33.20.75 DNS 89 Standard query 0x24c1 A mothership.vn.teslamotors.com 28699 2014-03-28 08:00:48.719789 192.168.0.163 10.33.20.15 TCP 74 59416 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=37689535 TSecr=0 WS=64 28714 2014-03-28 08:00:51.732127 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 59416 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=37689836 TSecr=0 WS=64 30110 2014-03-28 08:07:37.772079 192.168.0.163 10.33.20.15 TCP 74 58947 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=37730441 TSecr=0 WS=64 30125 2014-03-28 08:07:40.786317 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 58947 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=37730743 TSecr=0 WS=64 30133 2014-03-28 08:07:46.793122 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 58947 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=37731344 TSecr=0 WS=64 30134 2014-03-28 08:07:58.835192 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 58947 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=37732548 TSecr=0 WS=64 30630 2014-03-28 08:10:52.984076 192.168.0.163 10.33.20.15 TCP 74 46580 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=37749962 TSecr=0 WS=64 30647 2014-03-28 08:10:56.005885 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 46580 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=37750264 TSecr=0 WS=64 30648 2014-03-28 08:11:02.015571 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 46580 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=37750866 TSecr=0 WS=64 30649 2014-03-28 08:11:14.037869 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 46580 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=37752068 TSecr=0 WS=64 31090 2014-03-28 08:14:02.295399 192.168.0.163 10.33.20.75 DNS 89 Standard query 0x9fa5 A mothership.vn.teslamotors.com 31553 2014-03-28 08:15:43.196044 192.168.0.163 10.33.20.75 DNS 89 Standard query 0x504e A mothership.vn.teslamotors.com 31554 2014-03-28 08:15:43.197390 192.168.0.163 10.33.20.75 DNS 89 Standard query 0x504e A mothership.vn.teslamotors.com 31555 2014-03-28 08:15:43.198367 192.168.0.163 10.33.20.85 DNS 89 Standard query 0x504e A mothership.vn.teslamotors.com 38228 2014-03-28 15:06:43.742389 192.168.0.163 10.33.20.75 DNS 89 Standard query 0xe0c3 A mothership.vn.teslamotors.com 38229 2014-03-28 15:06:43.743996 192.168.0.163 10.33.20.75 DNS 89 Standard query 0xe0c3 A mothership.vn.teslamotors.com 38230 2014-03-28 15:06:43.744616 192.168.0.163 10.33.20.85 DNS 89 Standard query 0xe0c3 A mothership.vn.teslamotors.com 39428 2014-03-28 15:16:30.173720 192.168.0.163 10.33.20.15 TCP 74 55177 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=40303632 TSecr=0 WS=64 39512 2014-03-28 15:16:33.176052 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 55177 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=40303933 TSecr=0 WS=64 39610 2014-03-28 15:16:39.183439 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 55177 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=40304534 TSecr=0 WS=64 40162 2014-03-28 15:17:42.090568 192.168.0.163 10.33.20.75 DNS 89 Standard query 0x8b36 A mothership.vn.teslamotors.com 40163 2014-03-28 15:17:42.091170 192.168.0.163 10.33.20.75 DNS 89 Standard query 0x8b36 A mothership.vn.teslamotors.com 40164 2014-03-28 15:17:42.092267 192.168.0.163 10.33.20.85 DNS 89 Standard query 0x8b36 A mothership.vn.teslamotors.com 47498 2014-03-28 21:29:35.042632 192.168.0.163 10.33.20.75 DNS 89 Standard query 0xbe93 A mothership.vn.teslamotors.com 51045 2014-03-29 00:30:41.098269 192.168.0.163 10.33.20.75 DNS 89 Standard query 0xd62e A mothership.vn.teslamotors.com 51046 2014-03-29 00:30:41.099235 192.168.0.163 10.33.20.75 DNS 89 Standard query 0xd62e A mothership.vn.teslamotors.com 51047 2014-03-29 00:30:41.103403 192.168.0.163 10.33.20.85 DNS 89 Standard query 0xd62e A mothership.vn.teslamotors.com 56738 2014-03-29 01:59:07.072665 192.168.0.163 10.33.20.75 DNS 89 Standard query 0x6281 A mothership.vn.teslamotors.com 62239 2014-03-29 02:54:51.179114 192.168.0.163 10.33.20.75 DNS 89 Standard query 0x2eae A mothership.vn.teslamotors.com 68625 2014-03-29 03:46:37.533140 192.168.0.163 10.33.20.15 TCP 74 56455 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=4294948825 TSecr=0 WS=64 68630 2014-03-29 03:46:40.548096 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 56455 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=4294949126 TSecr=0 WS=64 68670 2014-03-29 03:46:46.559016 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 56455 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=4294949728 TSecr=0 WS=64 68812 2014-03-29 03:46:58.598992 192.168.0.163 10.33.20.15 TCP 74 [TCP Retransmission] 56455 > tram [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=4294950932 TSecr=0 WS=64 135899 2014-03-29 08:51:26.141682 192.168.0.163 10.33.20.75 DNS 89 Standard query 0xacc1 A mothership.vn.teslamotors.com 135900 2014-03-29 08:51:26.143652 192.168.0.163 10.33.20.75 DNS 89 Standard query 0xacc1 A mothership.vn.teslamotors.com 135901 2014-03-29 08:51:26.146541 192.168.0.163 10.33.20.85 DNS 89 Standard query 0xacc1 A mothership.vn.teslamotors.com (Times are UTC) These packets were obviously not intended to go out on the WiFi interface. I assume that these happened right around a reset of some sort on the OpenVPN connection to Tesla HQ and they just leaked to the default gateway. Most likely Tesla should include something like an iptables filter to ensure these don't go out the wrong interface. Probably nothing useful here. The TCP packets contained no data (were just SYN and retries of the same). As far as I can tell the only things revealed here really are some internal VPN-based IPs and an internal hostname. 10.33.20.85 and 10.33.20.75 seems to be DNS servers. 10.33.20.15 is some server that presumably accepts connections on TCP port 4567. I wonder if the built in web browser could help me poke around at these internal IPs... maybe something like http://jsscan.sourceforge.net/jsscan2.html would work... anyone dare try? -wk