物联网探索：2016款福特Flex

作者：David Fletcher
发布于2017年8月31日

我和妻子最近购买了一辆2016款福特Flex，替代因意外事故报废的同款旧车。在功能讲解过程中，销售人员特别强调这款Sync平台的便利性——可以通过Wi-Fi直接更新信息娱乐单元的固件。

话音刚落，妻子就转头对我说：“别打什么主意。“但她心里明白，我至少会分析这个更新过程。车辆到家后，我按照这篇博客文章的方法创建了一个软件接入点，开始研究更新过程涉及的安全特性。

检查车辆功能时，我发现每个暴露的接口都可以通过触摸屏界面禁用，包括Wi-Fi、蓝牙和固件自动更新功能。相关屏幕截图如下所示：

（此处应插入屏幕截图）

为了测试，我同时启用了Wi-Fi和自动更新功能以便观察整个过程。为了尝试更新，我需要将车辆连接到我的软件接入点。

首先注意到的是：车辆可以毫无抱怨地连接任何无线网络。我的软件接入点特意配置为无安全模式，想看看车辆是否会至少警告这是不安全的行为。

如下图所示，车辆愉快地连接到了我提供的完全没有认证和加密的无线网络。请注意，Wi-Fi接口的唯一明确用途就是信息娱乐单元的空中更新(OTA)。

首先看到的是Wi-Fi网络选择器。唯一表明网络不安全的指示是一个打开的锁图标。

选择网络后会显示以下对话框，允许操作者连接或查看网络详情。没有任何关于网络安全的警告来让用户三思。请记住，更新车辆是Wi-Fi连接的唯一目的。

查看网络详情会显示以下对话框，明确标识网络没有任何安全措施。这里也没有向操作者提供任何警告。

点击连接后，返回以下成功消息。仍然没有安全警告。

最后，查阅了车辆的用户手册，发现在向操作者描述该功能时也缺乏任何形式的警告。以下是随车提供的Sync 3补充手册的摘录。

回到我的软件接入点，我观察到车辆连接到我的SSID并获取了DHCP租约。

在将车辆连接到互联网之前，我启动了tcpdump来捕获车辆产生的任何通信。事实上，我在多个不同日期多次完成连接过程，以捕获多个更新周期。

捕获每个更新周期后，我使用Wireshark协议分析器分析更新过程。最初连接到无线网络时，出现了一阵活动，包括预期的IPv4和IPv6 DHCP请求。然而，也有意外行为，如检查自动配置IP地址可用性的ARP请求和来自车辆的多播DNS请求。

在这种流量模式重复几分钟后，车辆终于启动了更新周期。首先，使用DNS解析更新主机，然后启动与更新服务器的连接……通过明文HTTP。

观察到更新服务器的FQDN是ivsu.software.ford.com，经过多个CNAME查找，最终解析到IP地址191.236.55.220，如下所示。需要注意的是，我从未直接与这些服务器交互，只是使用Wireshark记录了我的车辆执行的交互。

重组HTTP更新请求事务后，显示了一个大型JSON POST请求，随后是服务器的类似响应。

请求和响应中的嵌入数据具有明显的Base64编码数据特征。首先将请求传递给Linux base64工具进行解码，揭示了一个大型嵌入式XML文档，其中包括我的车辆VIN以及有关嵌入式组件的信息，包括序列号、ECU地址和MAC地址。

在请求消息的末尾是另一个标记为"SyncData"的嵌入式base64编码值。

解码该值显示嵌入数据包括二进制和字符串信息。

将此输出传递给Linux strings工具后，得到以下输出。

在字符串输出中有一个福特汽车公司的电子邮件地址和一个字符串，表明嵌入的XML有效载荷已加密。

分析请求后，我开始分析响应消息。使用相同的技术，发现响应包含与请求类似的数据，除了加密的base64编码值。

对解码响应的审查显示了一个字段列表，这些字段似乎与请求中包含的字段匹配。响应中的信息是描述请求消息中字段格式和长度的规范。

在随后的一次分析会话中，我实际上捕获到了车辆下载更新的过程。更新是通过明文HTTP从服务器检索的，如下所示。此外，我还下载了两个更新文件以供后续分析。但这需要留待另一篇文章讨论。

总结来说，车辆没有以未加密方式向服务器传递操作者敏感信息。但它确实包含了车辆中包含的组件信息。此外，任何处于车辆和更新服务器中间人位置的人都可以通过IP地址地理定位来识别车辆的更新位置。一些被违反的最佳实践：

• 车辆连接开放Wi-Fi时没有警告操作者
• 操作手册没有包含任何关于使用开放Wi-Fi的警告语言
• mDNS守护进程在车辆上运行并查询连接网络上的服务
• 车辆与服务器之间的通信通过明文HTTP完成
• 没有身份验证方案来限制对更新内容的访问
• 交易数据使用base64编码进行模糊处理

直到下一篇文章发布之前……与此同时，我对我的车辆非常满意。不过，我会暂时关闭Wi-Fi和自动更新功能。