云端反击
在去年秋天，我发布了一篇深入的，揭示了一系列在广泛使用的GPS追踪器中发现的漏洞。自从我在近9个月前向制造商Shenzeni365披露我的发现，并在Avast博客上发布了，以提醒用户注意这一风险。目前，我估计仍有超过50万台设备在市场上，它们正在暴露儿童、老人甚至物品的实时GPS坐标，这些产品原本承诺能确保安全。
你可能会好奇，这样一个极其不安全的品牌是如何进入全球如此多的消费者手中的。我发现，问题远大于对单个设备厂商的漏洞披露；我在研究的中详细介绍的GPS追踪器实际上让我看到了一个供应链关系的网络，这大大增加了从一个白标厂商到另一个厂商的安全问题。
在这篇后续文章中，我将详细说明这些廉价仿制品牌的隐蔽程度，通过详细阐述GPS追踪器的基础设施以及制造商、供应商和消费者之间的关系。
为了使本文更加清晰，制造商是指真正生产电子设备（追踪器）的人，而供应商则是指以软件、应用程序或云解决方案的形式提供附加价值并销售该设备的人。
但首先，让我回顾一下这项研究的第一部分。
第1章：设备混乱
GPS追踪器有多种款式和型号，适用于各种目的。它们通常被宣传用于追踪儿童的实时位置，通常呈手表形状，并包含麦克风/扬声器或摄像头，以便与父母进行沟通。我还分析了设计用于汽车的GPS追踪器，有些型号甚至允许黑客连接到车辆的防盗系统，远程关闭引擎。我研究了宠物项圈形状的追踪器、具有内置紧急呼叫功能的老年人追踪器，以及带钥匙扣的一般用途追踪器。这些追踪器的共同点是基本的操作模式（如下图所示）——以及在云API中存在的一系列漏洞，这些漏洞可能允许攻击者完全控制设备。
插曲：针对供应链问题的简短介绍
要充分理解这个兔子洞有多深，我需要回到供应链问题本身。在当今的物联网（IoT）环境中，将新产品快速推向市场的优先级高于花时间加固其安全性。特别是在廉价设备的领域，竞争十分激烈，供应商不太可能在内部投资构建所有东西，因此解决方案是从第三方采购各种组件来构建产品。这就叫做供应链。这并不是一个新概念，制造业一直以来都是如此运作，但今天的安全研究人员担心的是，通常没有保证这些产品组件的安全性，特别是在供应商预算有限的情况下，他们无法承担对每一个材料清单中的项目进行适当的安全评估。
第2章：全世界的追踪器团结起来！
观察GPS追踪器市场，许多设备外形相似，但由不同供应商以不同产品名称销售。事实上，市场上有无数追踪器，但它们主要由少数几家工厂在中国制造。如今在中国的著名追踪器制造商包括以下公司：
| | |
—|—|—
Bofan| Coban| LHYK| Xexun
BSJ| CanTrack| Meitrack|
Benway| GooMe| ReachFar|
Concox| i365GPS| TKSTAR|
你可能对此类公司并不熟悉，除非你看过我研究的第一部分。那么，这也不足为奇，因为它们大多数生产追踪器硬件，最终用户主要与伴随的移动应用程序和云基础设施进行互动，而这些通常由其他人进行白标处理。因此，供应商通常是那些销售并结合这些来自不同来源的三大组件的人。我们试图绘制所有制造商、解决方案提供商和供应商的关系图，但由于其网络庞大，我们根本无法全面涵盖。为说明目的，典型的供应链如下图所示：
上述图片看似简单易懂，但那是理想状态。在现实中，这个框架有很多例外；例如，云解决方案提供商也可能直接销售最终解决方案，包括应用和硬件，或者硬件工厂有来自其他开发者的固件来源。
第3章：漏洞回顾
我发现了许多i365品牌追踪器的问题，那么我们来简单回顾一下：
默认登录凭据
该供应商的所有追踪器均配置有123456作为默认密码，这是最不安全的密码之一。没有进一步的提示，用户不会被推动去更改它。
云登录未加密
登录网络服务和移动应用时未加密的数据可能被任何人截获或更改。
云登录弱
追踪器的用户名也被预先配置，用户没有机会选择自己的用户名。实际上，分配的用户名仅仅是设备的国际移动设备身份（IMEI）编号的一部分，容易被迭代。此外，密码再次被预设为123456。
数据以明文传输
在追踪器的GPRS移动连接中，数据没有加密，也缺少身份验证。此外，追踪器允许攻击者通过发送带有预定义密码的普通SMS来更改数据发送的端点（IP地址和端口）。这种缺乏加密的状况使得任何人都能截获和修改通信，导致各种场景的发生，例如数据泄露、用户位置伪造、发送恶意命令等。
云基础设施API破损且不安全
遵循SOAP标准通信协议的API端点存在许多问题。大多数功能不需要预先身份验证；设备的唯一标识符是一个六位数字，可以很快通过设备相关数据（如GPS历史或存储在云中的照片）进行迭代。该API也使用HTTP，因此同样没有加密——尽管在这种情况下，无论如何是无关紧要的，因为任何人都可以调用API，因为它缺乏适当的身份验证。
尽管这里看到的Key字段不是您登录后获得的会话密钥，而是应用程序内置的密钥。事实证明，这个密钥也被不同的供应商共享，这再次指向一个共同的云。
我提到过，这似乎是一个大于单个中国供应商的问题，不幸的是，我的确又一次是对的。
第4章：云端反击！
那么，现在让我来解释为什么我回顾了供应链的引介。想象一下这种情况：有许多GPS追踪器制造商生产各种不同型号的追踪器，并配备各自的固件，它们使用自己的协议，因此它们要么创建自己的解决方案和应用程序，要么购买现成的解决方案。你会选择哪个方向？
因为我相当怀疑这并不是一个孤立的问题，我想购买另一台制造商的汽车追踪器……但是，等等，我有必要再买一台吗？这次，我决定采取不同的方式。
虚拟研究物理设备
我知道在哪里会遇到漏洞，我甚至需要物理设备吗？我找了一款（我选择时只是通过随机搜索找到了GPS追踪器）：
根据制造商的，这款追踪器可以切断汽车点火系统的电源，点火时发送报警，并具备所有“标准”功能，包括麦克风和扬声器。但我需要购买它进行这次黑客实验吗？我决定进行虚拟分析，以证明对任何这些设备及其伴随应用执行适当的安全评估并不困难。此外，我希望证明我怀疑该设备使用相同的后端服务。
第一步是获取设备的操作手册并下载伴随应用。在制造商的网页上，这引起了我的注意：
所以，我得到了Web门户和Android应用程序的源代码。首先，让我们看看门户：
嗯，这似乎很熟悉。由于我不知道确切的IMEI或许可证号码（因为我并没有真正购买它），我无法登录，但至少让我们看看这些登录数据是如何传输的。
到目前为止，这似乎相似，但还不足以确认我的怀疑。那么我们再看看Android应用程序。
好吧，这没有说太多。所以，我转向Avast先进的Android应用分析工具——：
现在发现了一些新东西！通过静态分析Android应用，即使没有物理设备，我仍然发现了一个看起来正是我所寻找的内置URL，因此让我们尝试一下。
哦不（或者我该说哦，对），这看起来很熟悉：
好的，那么让我们先测试他们是否共享相同的漏洞，从GetDeviceDetail开始：
毫不犹豫地，我们使用之前应用内置的密钥，并猜测了DeviceID（这是第三次尝试）。
好吧，我们得到了这个响应：
这证明所有这些追踪器有共同点：尽管由不同制造商制造，但似乎云基础设施由同一家公司构建。为了证明我的观点，我下载了手册，虽然它看起来略有不同，但我得到了我要的：
你可以看到与之前研究相同的模式，如何设置追踪器连接以发送GPS数据并接收命令的IP地址和端口……未加密且未身份验证。
研究人员的终极工具……谷歌
我们知道有多个供应商使用同一云，但如何找到更多？这不是一种非常复杂的研究方法，但有时简单的谷歌搜索能给你带来意想不到的结果。没错，我搜索了OpenAPv3.asmx，不可思议的是，我找到许多页面，其中的URL格式与我之前见过的相似。但当我又
случайно 发现这个 URL 时，结果简直令人惊讶：
你知道，通常把你的网页打开到任何人都可以自由浏览并不是个好标准（除非是C&C服务器的运营者
;))，幸好这个网页已经被删除。但它让我对API结构和可以在这里找到的内容有了启示。我注意到三件事：
- 日志目录是可以浏览的，这可能会给我提供关于这个后端系统来源的更详细提示；
- 有多个版本的API
OpenAPIV1-V4，结果所有版本都在访问相同的数据； - ZKImages文件夹不言自明，是的，里面装满了由GPS追踪器拍摄的图像。
显然，日志目录是吸引我注意的第一件事。
正如你看到的，日志更新得相当快，所以我们打开了最新的日志：
一些关于尝试连接到数据库的SQL客户端异常。然而，最有价值的信息是一个二进制文件的名称，它实现了这个框架。你知道，信息安全领域的所有灾难都源于错误代码，而糟糕的代码通常出自程序员之手。因此，我决定跟随这个线索。你从这个二进制文件的名称NewGPS2012.Logic中几乎无法得出任何东西，除了它可能是一个相当旧的.NET二进制文件。因为我之前在谷歌上走运，所以我再试一次。
我对结果感到震惊。我发现许多被谷歌索引的日志目录，这给了我一个看似可以几乎免费使用的相同框架的域名列表，但其中一个特别：
是的，有人刚刚把框架二进制文件的更新放在了随处可见的地方。（幸运的是这个页面现在已经下线了）。我从分析这些二进制文件中学到了很多（可能以后会有更多关于这个主题的博客文章），但我发现的其中一件重要事情是在SendCommandAPI.dll文件中，它有一长串功能。
简而言之，这看起来是一个可以与所有不同制造商的不同型号GPS追踪器沟通的通用API。这就是整个事情有意义的主要原因。如果你是硬件设备的制造商或供应商，你可能需要一个现成的、兼容的云解决方案。出于理智的原因，我们不会公开该解决方案供应商的名称，尽管找到它并不难。
嗯，定位鞋的支持？现在，我真的很害怕。
给我一切
我发现的一个新的、更严重的漏洞突显了这个解决方案的实施和操作的粗糙。但为了说明这一点，我要回到我们之前的博客文章。你记得在使用网页门户登录时，数据是如何传输的吗？你会得到包含DeviceID的API请求：
也许你会发现这里有一个奇怪的信息：
等等，这怎么可能？我们知道这些追踪器实际上并没有用户账户。记得唯一的用户识别是IMEI或追踪器的ID吗？更令人担忧的是，我还有同一公司的其他多个追踪器，而它们在响应中拥有完全相同的UserID。那么这意味着什么？等等，不，这不可能吧……或者可以？
让我们查看我们的OpenAPIV3.asmx API，深入了解它提供的功能：
嗯，UserID？我们来试试……
所以我们把我们的userID和之前使用过的必需Key放进去，得到了这个响应：
等等，登录名？会出什么问题呢？考虑到整个系统的安全性，我只是用我们之前使用过的著名密码尝试了一下。这次我选择通过“账户”登录：
我看到的令人震惊。我进入了供应商的控制面板，能够访问所有出售的追踪器。所以UserID实际上是你购买的特定追踪器的转售商/供应商的UserID。
在这里，你对追踪器具有完全控制权。没错，你没看错，每页有1,026个追踪器，总共给你轻松控制10,260台设备。例如，有一个重置密码的选项，想想吧，它不要求你输入新的密码；按下时，直接将其设置为123456。
修复或热修复或不修复
到现在为止，我们发现设备安全不在那些供应商的关注范围内。在写这篇文章的时候（2020年6月），该供应商已经对此漏洞进行了修复，但这更像是一个热修复。从现在开始，你不能选择123456作为密码，新的登录需要在已有的123456上进行更改。
哦，结果显示这根本不是修复，因为这些API端点根本没有适当的身份验证。再一次，我们将转向OpenAPIv3.asmx端点：
这看似复杂，但实际上并不复杂。更重要的是，这里的ID是用户的ID，而且它又一次仅为0-999999，非常容易枚举。其余的必需字段都是已知的。因此，通过简单的查询，我们可以轻松获得以下响应：
注意结果集中resSize的数量。通过一次查询，你将获取与特定账户分配的所有设备。当你迭代所有可能的IDs时，你将获取所有用户及其设备。这样你就可以获取任何所需的信息，包括电话号码、位置、用户名，甚至在该端点中的汽车OBD接口的数据，以及我在上一篇文章中展示的所有内容。最后但并非最不重要的是，你可以完全控制远程设备，从追踪器拨打电话或发送短信。想象一下攻击者会怎么做，例如招募大量移动设备向某个高价号码发送短信或者在短信投票中操纵选票。
我已经研究这些不安全的GPS设备一段时间，努力理解问题的规模。到目前为止，我已经识别出了超过**30**个运行该框架的实例，以及**500**多个使用这一服务的追踪器型号。估计这个问题的规模并不容易，但为了获得一个粗略的估计，我对**2**个随机的云进行了全面扫描，并得到了如下数字：
788,644 + 251,886 这两个云中的地理定位追踪器。基于我们迄今见到的情况，我们可以大致推算出，可能有超过
15M 的设备可以被定位和控制。
还值得一提的是，由于供应链，不是所有这些设备都是来自我早些提到的几家中国工厂的廉价品牌。在我的研究中，我还识别了许多欧洲和美国本土品牌，其中一些甚至在亚马逊上出售。但有趣的是，某个美国品牌的追踪器案例显示，尽管这个网站使用HTTPS并且看起来相当合法；它使用支持LTE的设备，你甚至还需为其月度计划付费。你必须激活设备并创建账户，但其背后使用的云框架，我们已经见过的，没有任何安全措施。
上述追踪器不存在OpenAPIV3.asmx命名约定，但最终使用的仍然是相同的API，运行在中国。
这也引发了数据处理和隐私处理方面的合法性问题，因为许多“来自中国外”的品牌仍在中国服务器（属于云解决方案供应商）存储客户数据，这无疑违反了美国和欧盟的最新立法，更不用说以几乎没有安全保障的方式收集和存储个人数据了。
为illustrate 不仅中国客户受到影响，这是从我们扫描的两个云所得到的追踪器按国家分布的图表：
供应商A|供应商B
—|—
数量|国家|数量|国家
99036|中国|386231|中国
1976|蒙古|15391|美国
1652|加纳|6633|柬埔寨
818|多米尼加|6529|蒙古
675|柬埔寨|6018|加纳
670|荷兰|3650|缅甸
615|肯尼亚|3432|孟加拉国
598|缅甸|3339|肯尼亚
347|越南|2315|多米尼加
267|秘鲁|2168|印度
第6章：结论
正如我在开头所说，我发现有一家为所有硬件制造商和供应商提供云解决方案的公司。我们不能命名他们，但仅供示例，以下是他们服务范围的概述：
在这里，你可以找到所有内容，甚至是OpenAPI协议和特定追踪器协议的文档——没有任何安全提示：
我将如何总结这项对廉价GPS追踪器的研究？我认为我能做的最好就是分享在云供应商同一页面上找到的这一自豪声明：
而且只是一台服务器和来自2014的信息。这正是 多么
巨大的问题的规模，同时也可以被视为现代供应链问题有多严重的证明。特别是在廉价的物联网和支持云的设备的情况下。
在我的调查过程中，我偶然发现了许多受影响的应用程序和供应商，许多时候他们甚至不知道自己存在问题。我一直在思考如何进行负责任的披露，同时帮助受影响的用户。我决定不公开所有应用程序和云，因为在这种情况下，没有简单的方法可以同时实现负责任披露和公共服务公告。
如果你觉得你可能受到了影响，请与我们联系，我们会尽力帮助你。你可以随时通过与我们联系。
我还要感谢我的同事和Avast的同行研究者，以及整个信息安全社区对这项研究的支持。特别感谢我的同事NikolaosChrysaidos及其团队，因为他们出色的工具给了我许多深刻的见解，让Android应用程序的逆向工程显得轻而易举。
标签：、、、、、、、、
分享：XFacebook
