汽车移动应用程序有什么问题？

介绍

最近关于控制数十辆特斯拉汽车的 19 岁黑客的故事引起了轰动。我们已经知道第三方应用程序存在问题，该应用程序可以访问 Teslas 的数据。这使得安全研究人员可以锁定和解锁汽车，打开和关闭灯，甚至实现无钥匙驾驶。

由于第三方数据记录软件配置错误，原生 Tesla 应用程序中的所有功能都可用。因此，让我们尝试更好地了解这些应用程序是什么、它们出现在市场上的原因以及它们带来的风险。

关于特斯拉事件的首次公示

大多数现代车辆都配备了特殊的远程信息处理模块。带有内置 SIM 卡的电子控制单元为制造商提供车辆的位置，警告车主即将进行的车辆检查，甚至可以联系紧急服务。此外，车主还可以获得一些方便的功能，例如能够检查车辆的位置、控制门锁、远程打开气候控制，甚至自动停车。而这一切都只需要使用一个移动应用程序。

典型配套应用的界面

但是，当所有这些功能都在汽车制造商的应用程序中可用时，为什么人们还需要第三方应用程序呢？

原生应用程序根本无法满足现代车主对功能的需求。例如，一些用户想要查看燃料/能源消耗如何根据他们的路线而变化。有些人希望在他们的智能咖啡机在早上开始煮咖啡时加热汽车内部。而其他人则不满意他们需要为不同的汽车品牌使用多个移动应用程序，并希望通过一个通用应用程序来管理它们。

那么，会出现什么问题呢？其他各行各业也会发生同样的事情。进入汽车需要钥匙，但在这种情况下，不是钥匙，而是登录名或电子邮件和密码。以及汽车制造商的后端在收到这些凭据时向车主的车辆发送命令的先决条件。它们旨在直接从汽车制造商的本机应用程序传输，但第三方应用程序可以要求用户提供原始凭据并代表他们将其发送到汽车制造商的 API。

应用程序和车辆之间的通信

风险是显而易见的：第三方有能力代表车主解锁汽车或跟踪其所有动作。

范围是多少？

这些解决方案有多少？卡巴斯基分析师检查了移动应用程序、开源软件并搜索了网络服务以找出答案。研究范围包括 155 种最流行的解决方案，这些解决方案需要车主的凭据（登录名和密码对或 API 密钥）才能与车辆进行交互。在开放存储库中发现了总共 69 个移动应用程序和 81 个解决方案，例如各种编程语言的 API 客户端。调查结果还包括 Web 服务以及其他一些有趣的事情。

应用类型

下面描述了这些发现的应用程序类型中的每一个。

关于移动应用程序

让我们从普通用户最容易访问和最容易理解的移动应用开始。如果我们仔细查看这些应用程序的描述，他们通常会谈论它们的强大功能、便利性，甚至与汽车制造商提供的“慢”应用程序进行比较。

随机应用程序的描述

对这些描述的分析表明，超过一半的应用程序没有提及他们使用车主的帐户和汽车制造商的本地服务。

不通知用户凭据使用情况的应用程序份额

是的，这是正确的。这里需要注意的重要一点是，第二个较小的份额由明确声明他们的应用程序不存储用户数据或以加密形式存储或仅使用凭据获取授权令牌的开发人员组成。但是，需要明确的是，您基本上是将您的车钥匙交给一个完全陌生的人，并照他们的话，因为没有办法验证这些陈述。

一些开发人员还建议使用授权令牌而不是用户名和密码来看起来更可信。但问题是，这个令牌可以像访问用户凭证一样访问汽车。而且，用户应该再次意识到，所有这些风险都由他们自己承担。只有 19% 的开发人员认为有必要提及这一事实并警告用户，而不是躲在几个精美的屏幕后面。

警告用户责任的应用程序份额

用户联系应用程序开发人员的最常见方式通常是通过移动应用商店的评论部分中的反馈。但如果问题更严重，需要立即回应怎么办？在这里我们要感谢应用商店和他们的放置规则。

86%的应用程序作者的联系信息是很容易找到的，尽管它通常只是一封没有任何附加信息的电子邮件。但是对于某些应用程序，搜索可能会导致已删除的社交网络页面或没有联系人的存根页面。

与可用联系人共享应用程序（下载）

基于此，很明显这些应用程序大部分是由爱好者开发的。那一定是坏事吗？没有。但是，发烧友开发人员没有责任像州监管机构对汽车制造商的要求一样关心您的车辆的安全性和数据安全性。

哪些汽车品牌最常受第三方应用程序控制？我们总共统计了 31 个品牌，前五名如下所示。请注意，某些应用程序可以控制一种以上的汽车品牌，因此提及次数不等于应用程序的总数。

受影响的汽车品牌前五名

特斯拉以相当大的优势领先，日产紧随其后。似乎通常是汽车爱好者的电动车车主对这些应用程序很感兴趣。

在成本方面，69 个应用程序中有 46 个是免费的，或者至少有演示模式。如果一个程序可以用汽车做很酷的把戏并且花费很多钱，那么很可能会有一个免费的对应物。

免费到付费分配

再加上此类应用程序已从 Google Play 下载超过 239,000 次，您不禁想知道有多少人让陌生人免费使用他们的汽车。

开源 API 客户端和 Web 服务

值得注意的是，稍微高级一点的用户倾向于使用来自 GitHub 的软件。事实上，很容易检查它以查看 API 客户端是否正在将敏感信息传输给第三方。

但是如果源代码有点复杂呢？所有用户都会检查代码吗？检查的程度如何？当然，这并不能保证应用程序本身或其组件没有漏洞。本文第一个链接中的示例很好地说明了这一点。

我们选择的第三种应用程序是 Web 服务。这些服务是在商业基础上提供给用户的。但即使它们可能是由拥有高技能开发人员和完善管理的组织开发的，授权方案也没有那么不同。用户仍然需要提供他们的凭据，但需要提供 Web 表单，而不是移动应用程序或 API 端点。

什么不符合我们的数据？

另一种类型的应用程序与其他应用程序稍有不同。这是因为与常规插件或经典 的“提供用户名和密码 - 获取令牌”不同， 它们被设计为成熟的 B2B 解决方案。B2B？是的，这是正确的。

例如，一家公司希望向用户销售应用程序或服务，而不深入研究不同汽车制造商的具体实施。而 B2B 提供商提供的通用解决方案能够与多家汽车制造商进行交互并促进他们的工作，成为中间环节。

示意图如下：

• 用户在上一节中提到的在线第三方服务中注册。该服务有助于估计为车辆充电的最佳时间和地点。
• 该服务的系统无法直接访问汽车制造商的 API，因此它将用户的凭据传递给上述 B2B 提供商。
• 反过来，B2B 提供商将凭证发送到汽车制造商的 API 并获得授权令牌作为回报，从而允许直接访问用户的车辆及其数据。

因此，用户名和密码同时发送给第三方应用程序和 B2B 提供商。在这种情况下，“中间”的所有者和开发商都处于危险之中，因为用户数据的安全性现在取决于另一家公司。

对于汽车制造商来说，这里也存在一些风险，因为这些服务要处理大量用户的数据。是的，所有这些只有在最终用户同意的情况下才有效，但是，正如最近的事件所显示的那样，成为头条新闻的是汽车品牌，而不是应用程序名称。

结论

如果您在阅读本文后决定停止使用此类应用程序，则需要考虑以下几点：

• 仅删除应用程序是不够的——某些服务要求您终止订阅或在其网站上删除您的帐户；
• 必须更改密码；
• 即使在密码重置后，最好尝试通过制造商的网站（如果有这样的功能）或客户支持服务来撤销访问。

当然，并非所有这些配套应用程序都应被视为不安全或不受信任。其中一些使用汽车制造商专门设计的解决方案，例如，出于安全原因，无法远程解锁车门。

取而代之的是，通过制造商的网站访问车辆数据，无需提供特定应用程序的凭据。用户也可以随时撤销此访问权限。不幸的是，仍然没有很多应用程序能够做到这一点。

因此，我们敦促应用程序开发人员将用户保护放在首位，并采取预防措施，以免损害他们的客户或他们自己。

开发人员可以主动为他们的应用程序配备额外的用户保护技术，而不是假设他们的客户已为潜在威胁做好准备。

向应用程序开发人员推荐以下内容：

• 由于最近通过公共存储库进行的供应链攻击变得更加频繁，因此开发过程需要加强保护以防止外部干扰。采用可以通过运行时应用程序控制、部署前扫描漏洞、容器的例行安全审查和生产工件的反恶意软件测试来保护软件开发过程的解决方案。混合云安全满足开发需求。它保护 Docker 和 Windows 容器并提供“安全即代码”方法，具有容器化主机内存保护、容器任务、图像扫描和可脚本化接口，因此您可以将安全任务集成到 CI/CD 管道中，而不会影响开发过程。
• 在应用程序中实施保护机制。移动安全软件开发工具包支持客户数据保护、恶意软件检测、安全连接等。

原文始发于微信公众号（网络研究院）：汽车移动应用程序有什么问题？