儿童GPS跟踪器安全性分析（Part 1）

 

0x00 前言

GPS跟踪器的作用是帮助家长获得儿童、宠物甚至汽车的位置信息，也可以提供一个简单的SOS（紧急求助）按钮，帮助老年人或残疾人更快寻求帮助。在Amazon及eBay上等常见电商平台上，这类产品的价格通常为25至50美元，在价格上比具备相同功能的智能手机更具吸引力。

但这些设备为什么总是能知道我们的具体位置，有时候甚至能听到我们的声音（本文分析的大多数设备安装了麦克风），大家是否清楚背后原理？事实证明，相比起这些产品带来的便捷性，现在某些GPS产品（尤其是市场上低端产品）可能会给我们带来不少困扰。这些产品不仅在安全性上令人担忧，而且很有可能给我们的亲人带来更多伤害。

在本文中，我们决定仔细研究Amazon、eBay以及Alibaba上的几款儿童跟踪器，分析其中的安全问题。

 

0x01 背景知识

现代GPS跟踪器会使用各种通信渠道以及技术，典型的架构如图1所示：

图1. GPS跟踪器典型配置及架构

这里涉及到许多传输层协议及层次化结构，因此我们从多个方面进行评估，研判这些设备的安全性。

通常情况下，跟踪器本身比较简单，廉价的设备中SOC（system on chip，片上系统）模块是其主要组件，串行总线将SOC与GPS模块连接起来，GPS模块负责提供位置信息。SOC也会与GPRS调制解调器相连，后者连接至SIM卡，以提供数据+SMS功能。此外，我们经常可以找到麦克风及扬声器部件，当按下“SOS”按钮时，这些部件可以提供电话功能。

图2. GPS跟踪器内部工作原理

我们将研究内容分成以下4大类：

• 分析特定设备的新手使用过程；
• 分析web页面及管理入口（如果存在）；
• 分析移动应用及云端的流量；
• 分析跟踪器及云端的GPRS流量。

 

0x02 设备上手

我们决定挑选一款跟踪器进一步研究。我们在市场上挑选了一款“T8 Mini GPS Tracker”，大小样式类似钥匙环，具有SOS按钮、两路通信功能（扬声器及麦克风）。

图3. 跟踪器

我们首先注意到的是新手使用过程，产品附加的说明书中有如下一段话：

其中提到，产品附带了一个web入口以及移动应用，可以用来管理跟踪器。我们采取比较直接的方式，首先打开浏览器，访问http://en.i365gps.com，这里可以看到一些错误信息：

图4. web登录界面

从上图红色警告信息中我们可知，该站点基于HTTP协议，并没有使用更加安全的HTTPS。此外，我们有两个选项可以连接到云端：使用用户名及密码，或者使用ID及密码。这里要选择哪种方案？我们可以看一下说明书上的说明：

图5. 默认密码

以上描述适用于Android应用程序以及web应用。这里还有一段话：“……如果用户需要使用用户名登录，那么应当联系经销商来注册用户名”。由于我们需要联系经销商来获取用户名，因此用户很可能会使用ID，对应的密码为123456。从安全角度来讲，这并不很好的开头。

在演示场景中，我们使用的ID号为17032491112，密码为123456。当我们登录web时，可以看到如下界面：

图6. web界面

这里数据依然通过HTTP协议传输，我们可以修改密码，但无法创建账户。我们把重点放在ID上。

 

0x03 用户ID

登录应用程序所使用的ID为11位数字，在弹出的信息框中，这个信息被称为IMEI（international mobile equipment identity，国际移动设备识别码）码。

图7. 信息框

从上图中可知，该设备被表示为T8S-49112，因此最后5位数字来自于“IMEI”，前面的字符应该是具体型号。这里很奇怪的是，虽然这个号码称为“IMEI”，但并不符合IMEI标准。根据规范，IMEI长度应为15位，并且最后一位应该是控制位。当我们搜索一番后，在设备底部找到了完整的IMEI号（如图8所示），后面又在盒子上找到了一个贴纸。这里我们看到的完整IMEI为：

图8. 跟踪器背部及IMEI、ID号

图9. 设备IMEI号分解

因此如果参考前面的“IMEI”及ID号，与标准格式对比，我们可以得到如下对比结果：

图10. 将ID与IMEI进行匹配

第一部分为TAC部分，包含各种子字段，这里简单起见，我们可以把它当成分配给厂商的一种标识符，角色上类似于MAC地址中的前缀信息。此外，这也意味着所有跟踪器的编号都可以预测，我们可以采用枚举方式来遍历这些设备。再结合前面提到的默认密码，这意味着我们可能成功登录大约25%的这一系列设备。

 

0x04 分析协议

这里我们可以先不去管IMEI枚举攻击，来看一下设备、移动应用以及web应用如何与云端交互。

从web端到云端

前面提到过，设备web应用的通信数据都基于HTTP协议，因此我们可以使用一些分析工具来观察从web端发出的请求。

图11. web应用AJAX请求（采用Chrome开发者工具分析）

利用这些简单的工具，我们可以看到web端发送的请求为明文形式的标准的JSON AJAX请求。我们可以先不去深入分析这些请求，因为所使用的命令与移动端发往云端的命令基本一致。这里需要注意的是，所有JSON请求都没有经过加密处理，采用明文形式。此外我们还要重点关注设备能够发出的命令。除了基本命令之外（比如获取GPS坐标和设置地理围栏），还有一些值得注意的命令：

1、我们可以让跟踪器拨打任意电话号码，一旦连接成功，我们就可以通过跟踪器来监听第三方，并且不会引起对方警觉；

2、我们可以让跟踪器向任意号码发送SMS消息，这样我们就可以通过SMS拿到跟踪器的手机号，这也是一种攻击向量；

3、我们可以向跟踪器发送一个URL，作为固件升级地址，允许攻击者将新固件部署到设备上。

从移动应用到云端

图12. 移动应用

我们看到的是名为AIBEILE的一款Android应用，现在来看一下该应用如何与云端通信。使用Wireshark捕捉流量后，我们发现该应用使用明文HTTP协议，通过非标准端口（TCP:8018）来与云端通信。

图13. 在登录时捕捉到的Android应用数据包

整个通信过程未被加密，以明文形式将数据发送到目标端点（http://(redacted):8018/openapiv3.asmx）。实际请求报文如下所示：

图14. 登录报文

这里有趣的是登录请求中使用了内置的Key及LoginAPP值，我们可以根据这个信息猜测有其他应用在使用这个“框架”，因为这个Key是APK文件中硬编码的一个值。

LoginType字段会随着登录方式不同而有所不同（比如通过用户名及密码方式登录时，LoginType=0；通过IMEI及密码登录时，LoginType=1）。这个参数控制用户正在使用的是那组凭据。

成功登录后，服务端会通过HTTP协议，以XML字符串封装一个响应，响应数据其实是一个JSON格式数据。典型的成功登录响应包如下所示：

图15. 对应登录请求的JSON响应

这里我们可以看到许多字段，这些字段含义比较明显，最重要的两个字段为key2018，这是经过Base64编码的一个64字节长会话密钥，还有一个deviceID，后续请求及命令中都需要携带这两个字段。

比如某个命令为GetTracking，我们可以看到登录后应用就会发出该命令（如图13所示）。这里唯一的输入参数如下：

图16. 请求跟踪器实际位置或者最近记录的位置

这里我们不能完全确定Model字段的具体含义，其他字段看上去比较直白。我们得到的响应如下：

图17. 对GetTracking请求的响应

现在我们知道应用程序与云端的交互完全采用明文形式，没有经过加密。

从跟踪器到云端

我们来分析下这款设备本身如何与云端通信，跟踪器如何通过移动运营商基站与服务器交互数据。

对于在LTE或者GPRS移动协议上使用IP传输层的协议，想解码或者逆向分析并不是特别容易。通常我们没法简单对流量着手分析，因为流量封装在GPRS中，由设备发送到电信提供商，然后再转到云端服务器，没有特别直观的方法来嗅探与云端交互的数据。

如果想分析这类流量，我们主要可以采用两种方法：

1、自己构建“伪”BTS站，运行自己的GSM网络，这样我们可以观察其中流经的所有流量；

2、在数据编码并被设备中的GPRS调制解调器发送前进行观察。

第一种方法比较复杂，如果想从法理上规避问题，我们需要一个法拉第笼，因为在大多数国家中，如果没有获得许可，我们不能运行自己的GSM网络（想获得许可非常困难）。此外，相关设备准备起来也不是那么容易，虽然有许多开源解决方案，但与以太网或WiFi嗅探相比，操作起来也没有那么简单。

第二个选项需要一点硬件技能，并且也需要承担设备无法保修的后果，对于这两方面我们都没有问题。前面我们提到过，大多数GPS跟踪器都会将GPRS调制解调器部署成内部的独立元件，即使内部布局非常狭小，我们还是可以在CPU和GPRS调制解调器之间重接串行线。

我们按照这个思路操作，打开GPS跟踪器后，我们找到了几个接线点（pad），这些pad看上去非常像我们寻找的连接点。这里有两组串行连接pad（TXD/RXD/GND），一组用于GPS到CPU通信，另一组用于CPU到GPRS调制解调器。通过反复实验，我们确认右侧那组是我们所需的连接点。

图19. 在跟踪器内部接线，获取GPRS通信数据

完成分析工作后，我们再次确认从GSM网络到云服务器端的通信数据全都未经加密处理。通信基于明文协议，并且不存在身份认证机制，云端单纯通过IMEI号来识别跟踪器。

从SMS到跟踪器

此外还有一种通道能够用来控制跟踪器。由于跟踪器是一个轻量化移动手机，因此我们可以使用简单的SMS消息来设置并获取一些信息。如果想获取GPS位置，我们可以从我们手机端向插入跟踪器的SIM卡号发送一条SMS。为了完成该任务，我们需要知道跟踪器密码，但如果用户不修改密码，默认密码与前文提到的一致，所有设备都采用相同的默认密码。

图20. 手册中提到的SMS命令

虽然前面我们通过逆向分析方式了解到这些信息，但其实只要好好研究手册，我们可以看到如下命令：

图21. 用来设置跟踪器的SMS命令

“Setup ip and port”实际上是用来设置云端服务器的IP地址及TCP端口号信息，这对攻击者（安全研究人员）来说意义非凡：结合前面提到的非安全协议，我们可以发起MITM（中间人）攻击，使用标准的IP工具捕捉到所有数据。因此我们采用如下方式：

图22. 通过恶意服务器中转流量

图23. 利用Wireshark捕捉位置报文流量（我们可以找到IMEI/ID以及坐标信息）

我们找到的命令似乎采用文本形式，满足如下格式：

其中，跟踪器到服务端的心跳命令格式为：

[3G*1703249112*000C*LK,0,1226,85]

服务端到客户端的心跳响应为：

[3G*1703249112*0002*LK]

激活监控模式，服务端到客户端：

[3G*1703249112*0015*MONITOR,+420612661749]

向跟踪器手机号发送“Test” SMS消息，服务端到客户端：

[3G*1703249112*0016*SMS,+420602661749,Test]

位置及状态信息，客户端到服务端：

[3G*1703249112*0090*UD,210619,053538,V,37.481010,N,-122.2315369,W,0.00,0.0,0.0,0,86,86,0,15,00000000,4,255,202,1,2082,5673,140,2082,12,128,2082,5671,118,2082,11,115]

 

0x05 寻找所有API

在研究各种API接口时，我们发现正在研究的这个平台似乎也在被其他厂商所广泛使用。经过一番Google后，我们找到了移动app到云端的一个接口文档，如下所示：

图24. 在其他地方找到的API文档截图

本文的目的并不是深入分析API所提供的每条命令，但我们可以选取几条命令来演示这里存在的安全性问题，以及会对正常用户造成哪些风险。

以GetDevicePhoto命令为例。虽然我们研究的这个跟踪器没有搭载摄像头，但使用相同云框架的其他设备可能搭载，如下图的“A19-3G Network GPS Smart Watch”产品。这条命令直接引起了我们的注意。

图25. 搭载内置摄像头的儿童跟踪器

查看该命令参数时，我们看到如下信息：

图26. 需要输入的参数，以获取跟踪器拍摄的照片

这里只需要3个参数：DeviceID是登录账号时得到的6位数字，TimeZones实际上关系不大，只是用来调整照片的时间戳信息，Key时分配给使用该API的Android应用的固定值（如图14所示）。

当测试搭载摄像头的跟踪器时，我们发现导出所有照片列表操作起来非常简单：

图27. 只需要一点代码就能导出照片列表

返回结果是非常标准的JSON格式数据：

我们只需要将photoName附加到imgUrl后，就可以获得某张图片的完整URL，不涉及任何身份认证。此外，我们还可以发现photoName似乎满足如下格式：

研究后发现，ID实际上是跟踪器用来登录账户的IMEI/ID值。因此理论上我们可以遍历时间戳，提取某一时间段内的所有照片。但说实话，最简单的方法是遍历所有DeviceID（如图27所示），这是1个6位数值，我们不需要再做其他额外操作。

 

0x06 统计信息

让我们再把目光转到IMEI/ID，配合默认密码后，这些信息组成了我们账户的登录凭据。扫描100万个可能的IMEI号实际上非常简单，因为这些编码采用相同的前缀。因此我们随机扫描了400万个顺序序列号，统计这些设备的规模。统计后我们发现，网上至少有60万台设备在使用默认密码。我们对其中100万台设备进行扫描，提取品牌、型号及位置信息，找到了超过167,000台设备的相关信息。

图29. 对跟踪器设备中100万个序列号的详细扫描结果

图30. 这些跟踪器的最近GPS位置

我们观察到该厂商生产的所有（或者大部分）跟踪器都采用相同的架构，在100万个IMEI扫描结果中，我们识别出了29款不同的跟踪器型号。这些型号均由“Shenzen i365”批发销售。我们还发现此次扫描中某些型号正以不同的产品名来销售，因此我们认为这些设备都采用代工方式，只是贴上了不同的厂商品牌。然而在大多数情况下，我们只能确定这些设备的通用型号。具体型号信息如下图所示：

跟踪器数量	跟踪器型号
60601	T58
36658	A9
26654	T8S
20778	T28
20640	TQ
11480	A16
10263	A6
9121	3G
7452	A18
5092	A21
4083	T28A
3626	A12
2921	A19
2839	A20
2638	A20S
2610	S1
1664	P1
749	FA23
607	A107
280	RomboGPS
79	PM01
55	A21P
26	PM02
16	A16X
15	PM03
4	WA3
4	P1-S
3	S6
1	S9

图31. 在100万扫描空间中提取的跟踪器型号及数量

图32. 涉及到的型号

大家可能会猜到这个故事还可以继续拓展，因为我们在这次扫描中竟然找到了不属于这家公司的其他产品，因此问题似乎比原先设想的要大。但影响范围究竟有多大？在后续文章中，我们将进一步分析这些产品和公司之间的关系，得到关于这个云架构的更多令人惊讶的结论，我们找到了更多漏洞，也发现了这个云和跟踪器的更多实例。

但到目前为止，我们发现大约有50个不同的应用在使用同一个平台（因此可能存在相同的漏洞），如下图所示：

图33. 在第二部分文章中，大家可以看到关于平台/云架构的更多信息

 

0x07 可能的攻击向量

由于这些产品所使用的与云端的每条通信渠道都存在安全问题，因此有各种漏洞利用方法，但我们主要关心如下几种：

提前锁定设备

似乎每个设备的账号在设备生产时已处于激活状态，因此攻击者可以在用户购买设备之前，根据IMEI号来修改账号密码，成功锁定这个账户（设备没有启用前肯定使用的是默认密码）。

提取手机号

我们可以通过SMS消息向跟踪器发送命令（比如设置云端服务器地址）。然而如果用户并没有插入SIM卡，那么攻击者并不知道手机号信息。但这个问题操作起来也不麻烦，通过跟踪器账户，攻击者可以让跟踪器向某个手机号发送SMS，这样就能将跟踪器ID与手机号关联起来。一旦获取手机号后，攻击者可以发送SMS，设置云端服务器的新IP地址及端口，将跟踪器的所有流量重定向到攻击者的服务器。远程扫描完毕后，攻击者可以查看佩戴该设备用户的所有运动轨迹。

监听用户

由于云端支持我们向任意跟踪器发送命令，呼叫任意号码，因此我们可以在不引起用户警觉的情况下，轻松监听这些用户。

位置欺骗

由于云端服务公开可用，并且报文中只需要ID/IMEI，因此我们可以欺骗云端，告知一个错误的跟踪器位置或者执行其他操作。

 

0x08 总结及后续工作

根据本文分析，这里涉及到的问题远远超过某个特定的供应商。我们发现不同应用也在使用相似的API，并且不属于这家厂商的其他型号也与这个云架构有关。我们正在撰写第二部分文章，内容主要关注正在使用的这个云架构，分析问题影响到的具体规模。

欢迎大家阅读第二部分内容，我和小伙伴Nikolaos Chrysaidos将深入分析品牌代工、平台共享以及设计上的一些缺陷，讨论IoT和智能设备存在的安全性问题。

我们在2019年6月24日向该厂商报告漏洞细节，但直到今天还没有得到任何回应。