Internet of Things Exploration: 2016 Ford Flex
My wife and I recently purchased a 2016 Ford Flex to replace an aging version of the same make and model that met an untimely fate. During the feature walk-through the salesperson identified how convenient this version of the Sync platform was because you could update the firmware on the infotainment unit over WiFi.
As soon as the words were spoken my wife turned to me and said, “Don’t get any ideas.” However, she knew that there would be no stopping me from at least analyzing the update process. When we got the car home, I created a software access point as described in the blog post found here. Then I began to explore security features involved in the update process itself.
Inspecting the features of the vehicle, I found that each of the exposed interfaces could be disabled using the touch screen interface. This included disabling Wi-Fi, Bluetooth, and Automatic Update of the vehicle firmware. Screen captures of each can be seen below.
For the purposes of testing, I enabled both the Wi-Fi and Automatic Update features so I could observe and inspect the process. In order to attempt an update, I needed to connect the car to my software access point.
The first thing that I noticed was that the car allowed me to connect to ANY wireless network without complaint. My software access point was configured explicitly to have no security to see if the car would at least warn me that this was a bad idea.
As seen below, the car happily connected to the wireless network I had provided that completely lacked authentication and encryption. Mind you, the only identified purpose for the Wi-Fi interface is for over the air update of the infotainment unit.
First, you see the Wi-Fi Network selector. The only indicator that the network is not secure is the open lock.
Selecting the network presents the dialog below which allows the operator to connect or view the details for the network. No warning about security of the network is presented to make the user think twice. Keep in mind that updating the vehicle is the ONLY purpose for Wi-Fi connectivity.
Reviewing the network details presents the following dialog that plainly identifies that no security is available on the network. No warning to the operator is presented here either.
After clicking connect, the following success message is returned. Still no warning about security.
Finally, the Owner’s Manual for the vehicle was consulted and also found to lack any kind of warning when describing the feature to the operator of the vehicle. Excerpts from the Sync 3 supplement that is delivered with the vehicle can be seen below.
Back on my software access point I observed the car connect to my SSID and obtain a DHCP lease.
Prior to connecting the vehicle to the internet, I started tcpdump to capture any communication produced by the vehicle. In fact, I completed the connection process several times over a wide range of dates so I could capture several update cycles.
After capturing each update cycle, I analyzed the update process using the Wireshark protocol analyzer. Upon initially connecting to the wireless network there was a flurry of activity including expected DHCP requests over IPv4 and IPv6. However, there was also unexpected behavior like ARP requests to check for AutoConfigure IP address availability and the presence of Multicast DNS requests from the vehicle.
After several minutes of this traffic pattern repeating, the vehicle finally initiated the update cycle. First, the update host was resolved using DNS and then a connection to the update server was initiated…over plain text HTTP.
The FQDN for the update server was observed to be ivsu.software.ford.com which resulted in multiple CNAME lookups and finally resolved to the IP address 191.236.55.220 as seen below. It should be noted that at no point did I directly interact with these servers. I simply recorded the interaction that my vehicle performed using Wireshark.
Reassembly of the HTTP update request transaction resulted in display of a large JSON POST request followed by a similar response from the server.
The embedded data in both the request and response had the distinct appearance of Base64 encoded data. The request was first passed to the linux base64 utility and decoded to reveal a large embedded XML document which included my vehicle’s VIN and information regarding embedded components including serial numbers, ECU addresses, and MAC addresses.
At the end of the request message was another embedded base64 encoded value labeled “SyncData”.
Decode of this value revealed that the embedded data included both binary and string information.
Passing this output to the linux strings utility resulted in the following output.
Within the string output was an email address for Ford Motor Company and a string indicating that the embedded XML payload was encrypted.
After analyzing the request, I moved to analyze the response message. Using the same techniques, the response was found to contain data similar to the request with the exception of the encrypted base64 encoded value.
Review of the decoded response revealed a list of fields that appeared to match those included in the request. The information included in the response was the specification describing the field formats and lengths in the request message.
During one of my ensuing analysis sessions I was actually able to catch the vehicle downloading an update. Updates were retrieved from the server over clear text HTTP as seen below. In addition, I downloaded both of the update files for follow-on analysis. However, that will have to wait for another post.
To recap, the vehicle didn’t pass what could be considered operator sensitive information to the server unencrypted. However, it did include information about the components included in the vehicle. In addition, anyone with Man-in-the-Middle position between the vehicle and update server can identify the vehicle’s update location by geolocating the IP address. Some best practices that were violated:
- The vehicle connected to open WiFi without warning the operator.
- The operator’s manual didn’t include any language warning about use of open WiFi.
- An mDNS daemon is running on the vehicle and interrogating services on the connected network.
- Communication between the vehicle and server was accomplished over clear text HTTP.
- No authentication scheme was in place to restrict access to update content.
- Transaction data was obfuscated using base64 encoding.
Until the next post… In the meantime, I’m very happy about my vehicle. However, I’ll be leaving WiFi and Automatic Updates off for the time being.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
