0x01 基础介绍

GPS追踪器可以帮助定位孩子，宠物、汽车，从而使用户更加安心。用户可以通过提供简单的SOS按钮来呼叫帮助，从而帮助确保老年人或残疾人的安全。为了实现此目的，许多设备在亚马逊和eBay等常见网站上进行了销售，售价为25至50美元，与使用智能手机实现某些相同功能相比，它们在价格上更具吸引力。

但是，我们对这些设备的真正了解有多少，这些设备知道我们在哪里，有时甚至可以听到我们的声音，我们在这里讨论的大多数设备也都带有麦克风。事实证明，当今的某些GPS追踪器，尤其是那些处于低端市场的GPS追踪器，是存在风险的，而不是让你省心。他们不仅缺乏安全警报，而且这些设备更有可能使你的亲人更加危险。

我们决定看一下亚马逊，eBay和阿里巴巴上的几种儿童追踪器，以了解它们如何经受住我们的安全测试。

GPS追踪器基础

当今可用的GPS追踪器使用多种通信渠道和技术。图1显示了一个典型的体系结构。

图1： GPS追踪器的典型配置和架构

其中涉及许多传输协议和网络层，因此我们同时在许多方面进行工作，以评估这些设备的安全性。

通常，追踪器是一种简单，廉价的设备，以SOC（片上系统）模块为主要组件。串行总线将SOC连接到提供位置的GPS模块以及连接到SIM卡的GPRS调制解调器，SIM卡为设备提供DATA + SMS功能。通常，你还可以找到按下“ SOS”按钮时使用的用于电话功能的麦克风和扬声器。

图2：   GPS追踪器内部工作原理

我们将研究分为四类：

分析特定设备的启动过程

分析管理门户网站

分析移动应用程序和云平台之间的流量

分析追踪器和云平台之间的GPRS流量

攻击真实设备

我们决定选择一个追踪器并进行一些更广泛的研究。我们选择了市售的追踪器—— T8 Mini GPS Tracker，该追踪器像一个钥匙扣，具有SOS按钮和双向通讯功能（扬声器和麦克风）。

图3：感兴趣的追踪器

首先引起我们注意的是使用流程，随附的说明：

按照说明，有一个Web门户和一个移动应用程序可用于管理追踪器。我们选择了最便捷的方法，首先打开了一个可达的Web应用程序http://en.i365gps.com。在许多层面都存在错误：

图4： Web应用程序登录截图

如你所见，第一个red flag登录表单是通过HTTP协议提供的，而不是通过更安全的HTTPS。此外，有两个选择可以连接到云平台：使用用户名和密码的帐户或使用ID和密码的帐户。

图5：默认密码

这适用于Android应用程序和Web应用程序。令人震惊的事实是：“ …如果需要通过用户名登录，则用户需要联系经销商注册用户名。”由于你必须致电经销商以请求用户名，因此很明显，可以使用ID，其密码为“ 123456”。

出于演示目的，我们的ID为：17032491112和密码123456。当你登录到平台时，将出现此界面。

图6： Web应用程序界面

这里的所有内容仍然通过不安全的HTTP协议传输，你可以更改密码，但是仍然无法创建帐户，让我们把关注点放在ID上。

用户名 ID

作为进入应用程序的“username”的ID是11位数。正如你在设备信息图7中所看到的那样，它有时被称为IMEI，代表“国际移动设备身份”。

图7：设备标识

你可以看到设备被标识为T8S-49112，因此后五位数字取自“ IMEI”，而开头可能是型号。这里奇怪的是，IMEI的数字不符合标准IMEI规范。根据规范，IMEI应该为15位长，最后一位是所谓的控制位。当我们进行更多搜索时，我们在追踪器（图8）中发现了完整的IMEI ，随后在包装盒上的小标签上也发现了完整的IMEI 。因此，在我们的案例中，完整的IMEI为：

图8：追踪器的内部以及IMEI和ID

图9： IMEI简化的细分

因此，当我们获取“ IMEI”和ID号并将其与规范格式匹配时，我们将获得

图10：与IMEI匹配的ID

TAC的第一部分由各个子部分组成，但为简单起见，我们可以说它以与MAC地址前缀几乎相同的方式分配给供应商。这也意味着所有其他追踪器的数字都是可预测的，你可以轻松枚举它们。结合固定密码，这意味着我们可以按此IMEI编号顺序登录约25％的设备。

0x02 协议分析

好了，暂时将IMEI枚举放在一边，让我们看看设备，移动应用程序和Web应用程序如何与云平台对话。

从Web应用到云平台

我们已经知道Web应用程序中的所有通信都是通过HTTP进行的，所以让我们看一下使用某些标准工具从Web应用程序发出的请求是什么：

图11：   Web应用程序AJAX请求（Chrome中的开发人员工具）

通过使用简单的工具，我们可以看到所有请求都是纯文本格式的标准JSON AJAX请求。我们不需要深入分析这部分，因为这些命令与移动应用程序向云平台发出的命令大致相同。有趣的是，所有JSON请求都再次未加密且以明文形式发送，但更重要的是设备可以发出的命令。除了获得预期的命令外，例如获取GPS坐标和位置，还有其他一些其他的功能：

你可以使追踪器拨打任意电话号码，并且一旦连接，就可以通过追踪器在对方不知情的情况下收听。

你可以使追踪器代表自己将SMS消息发送到任意号码。这可以让你获取设备的电话号码并将SMS用作攻击媒介。

你可以将URL发送到追踪器，追踪器可以从该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中，然后再从设备传输到电信运营商，然后再直接传输到云平台服务器，而没有明显的方法来嗅探数据流向云平台或返回云平台的方式。

如果要分析此类流量，则基本上有两种选择：

建立自己的伪 BTS站并运行自己的GSM网络，以便观察通过的所有流量。

在设备内部的GPRS调制解调器对数据进行编码和发送之前检查数据。

第一种选择很复杂，要合法地进行，你需要一个法拉第笼，因为在大多数国家/地区，在没有许可证的情况下运行自己的GSM网络是非法的。同样，建造设备并非易事，但是有许多开源解决方案（https://osmocom.org/projects/osmobts），与以太网或WiFi嗅探相比，它并不方便易用。

第二种选择需要一些硬件技能，并且设备可能会失效。正如我们在一开始就指出的那样，大多数GPS追踪器内部都将GPRS调制解调器作为一个离散组件，尽管通常很小，但仍有很大的机会利用主CPU和GPRS调制解调器之间的串行线。

在打开GPS追踪器后，确定了一些看上去完全类似于我们所需的连接点的垫。有两组串行连接垫（TXD / RXD / GND），很明显，一组用于GPS到CPU的通讯，另一组用于CPU到GPRS调制解调器，因此通过反复试验，我们确定了正确的一组：

图19：进入追踪器以进行GPRS通信

完成此测试后，我们可以确认所有数据未加密地从GSM网络传输到云平台服务器。通信是基于文本的协议，最重要的是缺少授权，整个工作仅需通过其IMEI识别追踪器即可。

从 SMS 到追踪器

最后一点是，你可以使用另一个频道来控制追踪器，你可以使用简单的SMS消息进行设置并获取一些信息。要获取GPS位置，你可以通过手机向定位器中插入的SIM卡号码发送短信。为此，你需要知道密码，但是除非用户更改了密码，否则所有设备的默认密码都是相同的。

图20：手册中说明的SMS命令

我们通过进行一些硬件逆向学习了所有这些知识，但是我们真的必须这样做吗？事实证明，在研究命令时，你可以通过SMS消息直接向追踪器发出命令，我们发现了这一点：

图21：用于设置追踪器的SMS命令

该命令隐藏在名称“Setup IP and port”下，意味着你可以设置设备与之通信的云平台服务器所在的IP地址和TCP端口。这是攻击者想要的信息；结合用于来回发送数据的不安全协议，你可以轻松地进行MITM中间人攻击，并使用标准IP工具捕获所有数据。

如下测试：

图22：通过恶意服务器转发流量

图23： Wireshark捕获了位置数据包的流量

可以轻松发现IMEI / ID和坐标，已识别命令的格式似乎是文本格式，并且遵循以下格式：

Heartbeat command tracker -> server
[3G*1703249112*000C*LK,0,1226,85]

Heartbeat response server -> tracker:
[3G*1703249112*0002*LK]

Activate monitor mode (callback this number) server -> client:
[3G*1703249112*0015*MONITOR,+420612661749]

Send SMS “Test” to provided number (+420602661749) server->client:
[3G*1703249112*0016*SMS,+420602661749,Test]

Position and status (client->server):
[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]

0x03 查找 API

在调查各种API时，发现我们正在调查的平台似乎已被许多其他供应商广泛使用。通过谷歌搜索，我们找到了移动应用程序->云接口的文档：

图24：在另一个实例中找到的记录的部分列表API

遍历此API提供的每个命令并不是本研究的目的，但是让我们看一些示例以进一步说明安全性有多糟糕以及这会对普通用户造成什么后果。

尽管我们调查的追踪器没有摄像头，但其他使用相同云平台框架的追踪器却有摄像头，例如下图的A19-3G Network GPS Smart Watch，此命令激起了我们的兴趣。

图25：内置摄像头的儿童GPS追踪器

当我们查看命令的参数时，我们看到了以下内容：

图26：获取追踪器拍摄的照片列表所需了解的输入参数

如你所见，实际上并不需要很多参数：DeviceID是登录帐户时获得的6位数字。TimeZones 是唯一被用于调整图片的输出时间戳的参数，Key是分配给使用此API的Android应用程序的固定密钥。（请参见图14）。

当我们使用内置摄像头对追踪器进行测试时，我们发现让设备转储其所有照片列表非常容易。

图27：获取照片列表的代码片段

转储结果是一个JSON格式的文档，格式如下：

你唯一需要做的就是附加imgUrl到photoName，你便获得了图片的URL，无需进一步的授权。另外，如果你注意到的话，你会发现photoName似乎是很熟悉的模式。

事实证明，该ID实际上是用于登录该帐户的追踪器的IMEI / ID。因此，从理论上讲，你可以扫描时间戳并获取特定时间段内的所有图片。但老实说，最简单的方法是扫描所有DeviceIDs（图27），因为它只有6位数字，并且你实际上不需要任何其他内容。

0x04 白色标签

让我们回到IMEI / ID，它与默认密码一起用作你帐户的凭据。还记得扫描具有相同前缀的1M可能的IMEI号码有多么容易吗？因此，我们自己扫描了一个任意的4M序列号，只是为了了解设备规模，并且我们了解到至少有六十万个设备使用默认密码。我们对其中一百万个设备的子集进行了更深入的扫描，以确定其品牌，型号和位置；在我们扫描的100万中有167,000处。

图29：详细扫描追踪器设备的1M序列号的结果

图30：追踪器的最新GPS位置

现在很明显了，该厂商使用的所有或至少大多数追踪器都使用相同的基础结构，因为我们在扫描1M IMEI时发现了29种不同型号的追踪器。所有型号均由批发商深圳i365出售，我们能够确定此扫描中的某些型号以不同的产品名称出售，这使我们得出结论，基础设施和设备都贴有白色标签，并以不同的品牌名称出售。 但是，在许多情况下，我们只能确定通用型号。

图31： 1M详细样本扫描中的追踪器型号及其数量

图32：受影响的型号

你可能已经感觉到，这个分析还有很多不尽人意之处，因为我们发现在此扫描过程中该公司未生产这些设备。事实证明，这个问题比看起来要严重得多。我们将在此后续分析中向你展示，该后续活动将更深入地介绍不同产品与公司之间的关系以及有关云平台基础架构的许多令人惊讶的事实。我们发现了更多令人震惊的漏洞，以及此云平台和追踪器的更多实例。

但是到目前为止，我们认为我们正在分析大约50个不同的应用程序，它们共享相同的平台，也可能是相同的漏洞，如下图所示：

图33： 研究仍在继续，在第二部分中详细介绍了云平台

0x05 可能的攻击效果

考虑到这些产品所使用的每个与云平台的通信通道均存在安全问题，因此存在无限的利用可能性。但是，让我们专注于最有趣的部分：

锁定设备

似乎从设备制造之日起每个设备的帐户都处于活动状态，因此攻击者甚至可以在仅基于IMEI号码购买追踪器之前就将用户锁定在帐户之外，因为你可以更改帐户密码属于尚未使用的设备。

电话号码

你只能通过使用SMS消息向追踪器发出一些命令，例如，允许你设置数据流向的云平台服务器的命令。但是，如果用户未将其追踪器的SIM卡号放入帐户中，则攻击者将不知道该号码，但是很容易得到它。通过该帐户，攻击者可以使跟踪程序将SMS发送到他所拥有的电话的电话号码，从而使他可以将跟踪程序的ID与其电话号码绑定在一起。一旦知道了这个信息，攻击者就可以发送SMS，该SMS设置云平台服务器的新IP地址和PORT，并将所有流量从追踪器重新路由到你选择的服务器。所有这些操作都可以远程完成，从而使攻击者可以查看使用该设备的任何人的全部动作。

监控用户

由于云平台使你可以向任何追踪器发送命令，使其可以语音呼叫任意号码，因此你可以轻松监视追踪器的用户，而无需他们知道追踪器已呼叫某人。

位置欺骗

在云平台上告诉追踪器在其他地方或正在做其他事情是非常容易的，因为云平台中的服务是开放的，唯一需要做的就是查看数据包中的ID / IMEI，所有其他信息由你决定。

0x06 研究结论

如你所见，有很强的迹象表明此问题远远超出了一个供应商的范围。我们发现不同的应用程序使用了相似的API，并且还发现了与该云平台基础架构链接的该特定供应商其他的型号。此研究的下一部分，主要集中在正在使用的云平台基础架构以及如何将这一问题扩大到更大的规模。

本文翻译自：https://decoded.avast.io/martinhron/the-secret-life-of-gps-trackers/如若转载，请注明原文地址