GPS跟踪器安全性分析（Part 2）-安全KER

0x00 前言

去年秋天，我发表了一篇文章（译文），详细分析了我在GPS跟踪设备中发现的漏洞。我向厂商（Shenzen i365）提交了漏洞报告，也提醒广大用户存在的安全风险。虽然已经过去9个月，但我估计现在仍有将近50万设备暴露在互联网中，正在准确地泄露儿童、老人甚至各种设备的实时GPS位置，而这些产品仍信誓旦旦会确保这些信息的安全性。

大家可能会好奇，为什么这种不安全的产品会覆盖全世界许多用户。我发现的问题并不局限于单个设备厂商中存在的单个漏洞，根据我在上一篇文章中的研究，这实际上涉及一个非常大的GPS跟踪器供应链网络，从一个贴牌厂商影响到另一个厂商，从而使安全问题以指数规模增长。

在本文中，我将详细介绍GPS跟踪器本身的基础架构，解释制造商、厂商和消费者之间的关系，系统阐述这些廉价品牌的影响范围。

为了进一步澄清相关概念，本文中的制造商（manufacturer）为实际生产电子产品（跟踪器）的厂家，而厂商（vendor）为销售该设备、并提供附加软件、应用或者云方案的厂家。

我们先回顾下前一篇文章的内容。

0x01 背景

GPS跟踪器涉及到各种制造商和型号，并且用途广泛。厂商在宣传这些设备时，都会以实时跟踪儿童的位置为例来演示。这些设备通常采用手表形状，包含麦克风/扬声器或者摄像头，以便儿童与父母通信。我分析了专为汽车设计的GPS跟踪器，其中某些型号甚至允许黑客连接到汽车的防盗装置，远程停止引擎。我还研究了项圈状的宠物跟踪器、内置紧急呼叫功能的老年人跟踪器以及可挂载钥匙圈上的通用跟踪器。这些跟踪器操作上存在共同点（如下图所示），并且在云端API中存在一些漏洞，允许攻击者获得设备的完整控制权。

图. GPS跟踪器典型工作流程图

0x02 供应链问题

为了完整阐述整个产业链中的问题，我们首先需要先解释一下供应链问题的具体含义。在今天的IoT领域中，第一时间将新产品推向市场在优先级上高于加强产品自身的安全性，这一点在竞争激烈且供应商难以完整构建所有设备组件的廉价产品领域方面尤为突出，因此厂商会从第三方购买各种组件，组成最终产品，这就是所谓的供应链。这并不是一个新的概念，制造业一直都采用这种方式。但今天安全人员担心的一点是，厂商无法保证产品所使用的这些组件是安全的，尤其是在供应商预算有限、无法对物料清单（BOM）中的每项物料进行适当安全评估的情况下。

0x03 全球追踪器

粗略分析全球GPS追踪器市场，可以看到很多追踪器看上去相似，但由不同厂商使用不同名称来销售。虽然全球有无数个追踪器，但实际上这些设备全部由中国的几家工厂来生产。目前几家较为知名的追踪器厂商包括：

Bofan
Coban
LHYK
XexunBofan
BSJ
CanTrack
Meitrack    
Benway
GooMe
ReachFar    
Concox
i365GPS
TKSTAR

如果大家没看过前一篇文章，那么可能不熟悉这些公司。这也很正常，因为这些公司主要生产跟踪器硬件，而最终用户实际上只会跟设备的移动应用程序以及云端架构交互，这些附加产品通常由其他公司贴牌生产。因此，厂商通常只会将来自不同供应商的这3个部件组合起来销售。我们也尝试过将所有的制造商、解决方案提供方以及厂商关系绘制出来，但这是一个庞大的网络，单凭我一己之力难以处理。为了便于演示，我给出了典型的供应链，如下图所示：

上图看上去非常简单，也易于理解，但实际情况要比这个复杂得多。现实世界中情况有所不同，比如云解决方案提供商也可以直接销售带有app和硬件的最终解决方案，而硬件厂商也可以从其他开发者那里获取固件源。

0x04 漏洞概述

之前我发现i365品牌的追踪器存在许多问题，这里我们简单回顾一下。

默认登录凭据

这个厂商的所有跟踪器的默认凭据都为123456，这可能是最不安全的一个密码，该密码被预先配置为默认密码。如果不了解更多情况，用户就不会主动去更改该密码。

云端登录未加密

登录web服务以及移动应用的请求没有经过加密处理，因此任何人都可以截获或修改该请求。

图. 通过登录界面用户可以控制并监控追踪器

云端登录脆弱性

追踪器的用户名同样已预先配置，用户没有机会选择自己的密码。实际上，预先分配的用户名是设备的国际移动设备识别码（IMEI）的一部分，很容易遍历。此外，密码同样预先被设置为123456。

跟踪器与云端传输明文数据

通过跟踪器GPRS移动连接发送的数据没有经过加密，并且缺乏身份认证。此外，攻击者只需要使用预定义的密码发送SMS信息，就可以修改数据发送的端点（IP地址以及端口）。由于没有经过加密，任何人都可以截取和修改通信数据，导致出现诸如数据泄露、用户地址欺骗、发送恶意命令等攻击场景。

图. GPS跟踪器与云服务器之间的通信数据

云架构API脆弱性

API端点遵循SOAP标准通信协议，但存在很多问题。大多数功能不需要通过身份认证即可使用，设备的唯一标识符为6位数字，攻击者可以通过设备相关的数据（如GPS历史或者云端存储的照片等）快速枚举。该API接口同样依托HTTP协议，没有经过加密。但此时明文协议不是特别关键，因为任何人已经可以调用这些API。

图. 如果想获取云端存放的照片，我们只需要设备ID，而该ID为6位数字，图中Key值为固定值。

尽管上图中包含Key字段，但这并不是我们通过登录获取的会话密钥，而是应用内置的密钥。事实证明，该密钥同样由不同厂商共享，再次将线索指向同一个公共云。

前面我提到过，这个问题似乎并不局限于单个中国厂商，事实证明我的猜测非常准确。

0x05 云端安全性分析

前面我专门介绍了供应链背景，假设有这样一个场景：数十家GPS跟踪器制造商生产了这些不同型号的跟踪器，采用自己的固件，使用自有的协议。此时要么这些厂商会创建自己的解决方案以及应用，要么会购买现成的解决方案。如果是你的话，会选择哪条路呢？

由于我非常怀疑这并非一个孤立的问题，因此我曾经思考过从另一个制造商那购买汽车跟踪器来研究，但这一次我决定采用不同的方法。

对物理设备的虚拟研究

我知道哪里可能会存在漏洞，那么我真的需要物理设备来研究吗？这里我挑选了一个设备（挑选指的是我在互联网上，随机搜索GPS跟踪器后找到了这个设备）：

图. TK100汽车GPS跟踪器

根据制造商的官网描述，该跟踪器可以切断汽车点火装置，在点火装置启用时发送警报，也包含其他“标准”功能，比如麦克风以及扬声器。但这次实验中我需要购买该设备吗？我决定先虚拟分析一波，来证明对这类设备以及app进行安全评估并不是一件艰巨的任务。此外也可以验证我前面的猜测：这个设备使用的是相同的后端服务。

首先我们需要获取该设备的操作手册，下载公司提供的应用。在制造商的网页上，我注意到了如下信息：

因此我们得到了一个web门户以及Android应用。我们先来看看web门户：

这个界面看上去非常熟悉。由于我并不知道确切的IMEI或者许可编号（我并没有购买该产品），因此无法登录，但我们至少可以观察一下数据如何通过网络进行传输。

图. 用户名及密码通过网络明文传输

我们已经很熟悉这种行为，但这并不足以确定我的怀疑。现在我们来看一下Android应用。

图. Android应用

界面上并没有提供太多信息。现在我们可以使用Avast提供的Android应用分析工具：apklab .io。

图. 静态分析后找到的URL字符串

现在我们找到了一些线索。通过静态分析这款Android应用，在没有物理设备的情况下，我找到了一个内置的URL，看上去正是我寻找的目标。那么现在来尝试一下该地址：

图. 从APK文件中提取到的URL所对应的API端点

该页面看上去非常熟悉：

图. 上一篇文章中我在分析i365时找到的API端点

现在我们来测试一下这些API是否存在相同的漏洞，先以GetDeviceDetail为例：

图. 使用常规参数测试GetDeviceDetail

我们直接使用先前应用程序内置的密钥来测试，配合我们猜测的DeviceID值（这是我们第3次尝试），然后就得到了预期的结果：

这表明这些跟踪器都有共同点：虽然由不同的制造商制造，但似乎使用同一个公司提供的云端基础架构。为了证明这一点，我下载了用户手册，虽然手册看上去稍微有点不同，我的确找到了证据：

我们可以找到与前一篇文章中相同的模式，比如如何设置服务器的IP地址以及端口，以便跟踪器连接服务器，发送GPS数据、接收命令等，这些信息也没有经过加密，没有身份认证。

善用Google

现在我们知道有多个厂商会使用同一个云，那么如何找到更多云呢？研究的方式可以非常复杂，但有时候我们可以使用Google之类的简单东西，找到丰硕的成果。我在Google上搜索了OpenAPv3.asmx，难以置信的是，我找到了许多页面，URL类似我们曾经看到过的模式。并且我还找到了如下信息：

图. 服务端允许目录遍历

大家都知道，通常来说我们不应该允许任何人来自由浏览web目录（除了C&C服务器相关操作），幸运的是，这个页面现在已经被删除，但该页面给了我不少提示，让我知道API的具体结构以及具体位置。这里我注意到3个细节：

1、Log目录可以浏览。这样我们可以详细了解整个后端系统的具体来源。

2、存在多个版本的API：OpenAPIV1-V4，并且这些API都在访问相同的数据。

3、ZKImages目录中包含GPS跟踪器使用内置摄像头拍到的图像。

显然，我首先注意到的是Log目录。

这些日志非常新，因此我们打开最近的一份日志：

其中包含SQL客户端尝试连接DB时的一些异常信息。然而，这里最有价值的信息为实现该框架的二进制文件的文件名。在信息安全领域，所有灾难都来自于错误的代码，而糟糕的代码通常都来自于程序员。因此我决定沿着这个思路探索。从这个程序的文件名（NewGPS2012.Logic）来看，这可能是非常老的.NET程序。前面使用Google时我的收获不少，因此我决定再次Google一下。

结果令人吃惊，我发现Google收录了很多Log目录，因此找到了使用同一个框架的许多域名，其中有一个比较特殊：

这表示有人将该框架的更新程序也放在服务器上（这个页面现在也已下架）。分析这些文件后，我得到了很多信息（后续可能会就此再发布一些博客），但最重要的一个文件为SendCommandAPI.dll，其中包含一系列函数。

长话短说，我发现这是一个通用API，可以与所有不同制造商生产的所有GPS跟踪器型号交互。这看上去非常合理，如果我们是某款硬件设备的制造商或者厂商，我们很可能需要一个易于使用且兼容的云端解决方案。这里我们不公布该解决方案厂商的名称，尽管大家很容易就能找到这个厂商名。

图. 该API甚至支持定位鞋

掌控一切

这次研究中我找到了更新、也更为严重的漏洞，表明这个解决方案的具体实现和运营非常糟糕。为了分析这一点，我们先回顾前一篇文章的内容。前面我们分析过，在登录web门户时，发往API的请求中包含DeviceID：

这里大家可能会发现更奇怪的一个信息：

这怎么可能呢？我们并没有与这些跟踪器绑定的用户账户，唯一的用户标识符为IMEI或者跟踪器的ID。我发现我目前拥有同一个公司的多个跟踪器，这些跟踪器对应的响应包中都包含相同的UserID。我似乎猜到了什么。

我们来看一下OpenAPIV3.asmx API，详细分析该API提供的函数：

这里我们输入前面使用的UserID以及多次使用的Key，可以收到如下响应：

图中包含loginName。考虑到整个系统安全性并不可靠，我尝试使用前面多次用过的密码，这次我们选择通过Account方式登录：

我直接进入了厂商的控制面板，能看到所有已售的跟踪器。因此前面web门户的UserID实际上为销售具体跟踪器的转售商/厂商的UserID。

这里我们可以完全控制跟踪器，上图中我们可以看到1026个页面，每一页包含10个跟踪器，因此我们可以轻松控制10,260台设备。比如，页面中包含一个密码重置选项，并且该接口不会要求我们输入新密码，会直接将密码设置为123456。

0x06 补丁情况

到目前为止，我们发现这些厂商并不怎么关心设备的安全性。在本文撰写时（2020年6月），厂商已经发布补丁修复该漏洞，但这个补丁更像是热修补程序。从现在开始，我们无法使用123456作为密码，如果已经设置为改密码，用户再次登录时就必须修改密码。

事实上这根本不算成功的补丁，因为这些API端点并没有部署身份认证机制。这里我们再次以OpenAPIv3.asmx端点为例：

看上去似乎比较复杂，但实际上并非如此。这里比较重要的是ID字段，为用户的ID，范围为0-999999，枚举起来也非常容易，其他字段都是已知值。因此通过简单的查询，我们可以得到如下响应：

注意到响应中的resSize。通过一次查询，我们可以得到该账户绑定的所有设备。当我们遍历所有可能的用户ID时，我们能拿到所有的用户和设备。获取这些信息后，我们可以继续获取想要的任何信息，包括手机号码、位置、用户名等。这个端点也可以用来获取用户汽车OBD接口的数据，以及前一篇文章中展示的所有信息。还有一点，我们可以完全控制远程设备，利用跟踪器打电话或者发送SMS。攻击者可以利用这些功能做很多事，比如构建一支移动设备军队，向某个号码发送大量SMS消息，或者操控通过SMS的投票结果等。

我花了很长时间在研究这些不安全的GPS设备，努力去了解该问题的严重程度。目前我确定互联网上有30多个实例在使用该框架，有500多种跟踪器版本在使用这个服务。我们很难估计问题的影响范围，但可以粗略评估大概量级。为此我全面扫描了2个随机的云，得到了如下数字：

这两个云中包含788,644以及251,886个地理位置跟踪设备。那么根据目前我们掌握的情况，可以粗略估计有150万个设备可以被定位和控制。

值得一提的是，由于供应链的原因，这些设备并不全部来自于前面我提到的少数几个廉价的中国品牌。在研究过程中，我还找到了许多欧洲和美国品牌，某些品牌甚至会在Amazon上销售。对于美国版的跟踪器而言，有趣的是该网站使用的是HTTPS，看上去非常安全。并且该设备支持LTE，用户可以按月支付费用。用户需要激活设备、创建用户，但底层使用的是同一个云框架，没有任何安全性。

图. 美国版跟踪器网站支持HTTPS，提供LTE数据付费计划

这个跟踪器并没有沿用OpenAPIV3.asmx命名方式，但最终还是使用了在中国运行的API。由于这些“非中国”品牌大多数会将用户数据存放在中国服务器中（云服务商），因此可能存在数据处理和隐私方面的问题。

这个问题不单单影响中国客户，根据我们对云端执行的2次完整扫描，可以得到跟踪器的分布图，如下所示：

具体数字如下：

厂商A		厂商B
count	country	count	country
99036	China	386231	China
1976	Mongolia	15391	United States
1652	Ghana	6633	Cambodia
818	Dominican Republic	6529	Mongolia
675	Cambodia	6018	Ghana
670	Netherlands	3650	Myanmar
615	Kenya	3432	Bangladesh
598	Myanmar	3339	Kenya
347	Viet Nam	2315	Dominican Republic
267	Peru	2168	India