GetDeviceDetail终极工具：具有常规参数的GetDeviceDetailAPI使用先前应用程序中的内置密钥并进行DeviceID猜测

好的，如今让我们从GetDeviceDetail开始测试它们是否存在相同的漏洞：

具有常规参数的GetDeviceDetailAPI

使用以前应用程序中的外置秘钥并进行DeviceID推测：

这证明所有那些跟踪器都有一个共同点：虽然这种跟踪器是由不同的制造商制造的，但其实云基础构架是由同一家公司制造的。只是为了证明我的观点，我下载了该指南，虽然它看上去略有不同，但我得到了帮助：

你可以看见与之前的研究相同的模式，怎么设置追踪器应当联接的服务器的IP地址和端口，以发送GPS数据和接收命令。

2.终极工具Google

我们晓得有多家供应商使用一种公有云框架，并且我们怎样找到更多云平台呢？有时侯Google可以带来丰硕的成果。我在Google上搜索了OpenAPv3.asmx，而且看上去仿佛令人无法置信，我发觉许多页面的URL类似于我早已听到的格式。并且当我也发觉这一点时，真是一个惊喜

容许浏览服务器上的目录

任何人都可以自由浏览它的方法打开站点不是一个挺好的标准，所幸此页面已被删掉。但这为我提供了有关API的结构以及在哪里可以找到的内容的线索。我在这儿注意到三件事：

1.日志目录是可浏览的，这可以为我提供有关整个前端系统来自何处的更详尽的提示

2.API有多种版本，事实证明它们都在访问相同的OpenAPIV1-V4数据。

3.ZKImages文件夹是不言自明的，包含大量GPS追踪器使用外置摄像头拍摄的图象

日志目录是造成我注意的第一件事。

如你所见，日志是最新的

尝试联接到数据库时，SQL顾客端中的个别异常。并且，这儿最有价值的信息是实现框架的二补码文件的名称。你晓得信息安全领域中的所有灾难都来自错误的代码，糟糕的代码一般来自程序员。为此，我决定效法这一点。不仅它可能是很老的.NET二补码文件外，从二补码文件本身的名称NewGPS2012.Logic中看不出哪些。由于之前通过Google搜到了好多信息，所以我再度尝试了。

我对结果倍感十分震惊，发觉许多Google索引的日志目录为我提供了几乎免费使用相同框架的域名列表，但其中一个很非常：

是的，有人刚才留下了框架二补码文件的更新。在剖析这种二补码文件时，我学到了好多东西，而且我发觉的基本要点之一是在SendCommandAPI.dll文件中，该文件有详细的函数列表。

很快，事实证明这是可以与GPS追踪器的所有不同制造商的所有不同机型进行通信的通用API，整个事情就讲得通了。假如你是硬件设备的制造商或供应商，则可能须要一个便于使用且兼容的云解决方案。为了安全起见，我们不公开解决方案供应商的名称，虽然并不难找到。

3.把所有东西都给我

使用Web门户登陆时，会将这种恳求发送到包含以下内容DeviceID的API：

一个奇怪的信息：

我们实际上没有这种跟踪器的用户账户。还记得惟一的用户标示是IMEI或跟踪器的ID吗？更令人担心的是，我有同一家公司的更多跟踪器，但是它们在响应中都具有完全相同的UserID。

步入API并深入了解它提供的OpenAPIV3.asmx功能：

试一下用户名。所以我们只需输入我们早已使用过多次的用户ID和强制秘钥，就得到如下响应：

考虑到整个系统的安全性，我只是尝试使用早已使用过好多次的密码，此次我选择通过“帐户”登录：

步入了供应商的控制面板，其中有所有已售出的跟踪器供我们使用。为此，用户ID实际上是销售商的用户ID，她们向你转让了特定的跟踪器。

从这儿你可以完全控制追踪器。是的，你看对了，每页有1026页，10个跟踪器，让你可以轻松控制10260台设备。比如，有一个重置密码选项，你猜如何着，它不会要求你输入新密码；按下时，会将其设置为123456。

4.漏洞修补

我们看见这种供应商没有关心设备安全性。在撰写本文时，供应商已发布了针对此bug的修补程序，但它更像是一个补丁程序。从现今开始，你将难以选择123456密码，但是假如早已拥有新的登陆名gps端口配置修改工具，则必须修改密码123456。

好吧，事实证明这根本不是一个解决办法，由于这种API端点未正确进行身分验证。我们再瞧瞧OpenAPIv3.asmxAPI：

它可能看上去很复杂，但实际上并不复杂。这儿更重要的是，在本例中，ID是用户的ID，但是它也只是0-999999，这很容易枚举。其余的必填数组是已知的。因而，通过运行一个简单的查询，我们可以很容易地得到以下响应：

注意结果集的大小。通过一次查询，您将获得分配给特定账户的所有设备。当你遍历所有可能的用户ID时，你会得到所有的用户和设备。从哪里你可以得到你想要的任何信息，电话号码，位置，用户名，在这个端点下，还有来自你车辆OBD插口的数据，以及我在上一篇文章中向你展示的所有东西。最后但并非最不重要的一点是，你可以完全控制远程设备，打电话或从追踪器发送邮件。想像一下功击者能做哪些。诸如，招募一大群联通设备向特定号码发送邮件，或在邮件投票中操纵投票。

我早已研究这种不安全的GPS设备很长时间了，努力了解问题的严重性。到目前为止，我早已确定了30多个在互联网上运行的这个框架的不同实例，以及500多个使用这个服务的不同版本的跟踪器。很难恐怕问题的大小，但起码简略恐怕一下，我对两个随机云目标进行了完整扫描，得到了以下数字：

788644+251886来自两个云目标的地理定位追踪器。前提是gps端口配置修改工具，按照我们目前所见到的情况，我们可以简略恐怕，可以定位和控制的设备可能超过1500万台。

还值得一提的是，因为供应链的缘由，并非所有那些设备都是我后面提及的少数几家中国鞋厂生产的廉价品牌。在我的研究中，我还发觉了许多亚洲和澳大利亚品牌，其中一些甚至在亚马逊上销售。但在新加坡版本的跟踪器中，有趣的是，该网站使用HTTPS，看上去相当合法；它还使用了一款支持LTE的设备，你甚至要为这个计划支付月费。你必须激活你的设备并创建一个账户，但下边是我们早已听到的没有安全性的云框架。

日本版的跟踪器虽然合法，可以通过HTTPS进行传输并提供LTE数据计划

后面提及的跟踪器没有使用OpenAPIV3.asmx命名约定，但它使用了在中国运行的相同API

为了说明除了中国顾客遭到影响，以下是我们从两个完整扫描的公有云中按国家、地区划分的跟踪器图表：

扫描公有云上的跟踪器

正如我在一开始所说的，我找到了一家为所有硬件制造商和供应商提供云解决方案的公司，这是它们的服务范围：

0x04研究总结

云解决方案供应商的页面和范围

在这儿，你可以找到所有内容，甚至包括有关OpenAPI合同的文档以及针对特定跟踪器的合同的信息：

在调查过程中，我碰巧发觉了许多受影响的应用程序和供应商，好多时侯她们甚至都不晓得自己有问题。我仍然在思索怎么进行负责任的披露，同时帮助受影响的用户。我决定不公开所有应用程序和云平台，由于在这些情况下，没有简单的方式可以同时完成负责任的披露和公共服务公告。