本文作者通过偶然间发现了网络上存在的一个漏洞，顺藤摸瓜，有了一些意外的发现。
原文链接：https://samcurry.net/hacking-millions-of-modems
未经允许，禁止转载！
作者 | Sam Curry 责编 | 夏萌
译者 | 弯月
出品 | CSDN（ID：CSDNnews）
简介
两年前，我发现我家的网络上出现了一件怪事。当时，我发现了一个漏洞，这个漏洞需要一个外部HTTP服务器来传输文件，所以我启动了一个AWS虚拟机并运行了一个简单的Python网络服务器来接收来自漏洞服务器的流量：
在Web服务器运行期间，我从家里的电脑上发送了一个cURL请求，为的是确定它能够接收外部HTTP请求：
几秒钟后，我看到了如下日志：
太好了，这意味着我可以通过虚拟机接收网络流量。一切看似顺利，但就在我准备利用这个漏洞干点什么的时候，我的日志文件中出现了一些非常奇怪的内容：
一个未知的IP地址在10秒钟后发送了一条一模一样的HTTP请求。
我当时想：“好奇怪啊。”有人在我家的网络和AWS虚拟机之间的某个地方拦截我的HTTP流量，并重发了一遍。这种流量应该是访问不到的。这两个系统之间不应该有任何中间人能看到这些数据。我当即想到我的电脑有可能被黑客入侵了，并且这名黑客正在积极监控我的流量。
为了检查其他设备上是否也有这种行为，我拿出了我的iPhone，在Safari中输入了URL，发送请求，然后检查日志文件：
同一个未知IP地址拦截并重复发送了我的电脑和iPhone的HTTP请求。有人正在拦截并重复发送我家网络中每台设备的网页流量，只不过我不知道他们利用了何种方法。
惊慌失措间，我启动了一台运行Nginx的新AWS虚拟机，以确保原来的实例没有通过某种方式被入侵。
我再次通过iPhone打开了那个URL，并看到了完全相同的日志：
有可能是我的互联网服务提供商（ISP）、调制解调器或AWS遭到了入侵，有人正在拦截并重复发送我发送的HTTP流量。虽然AWS被入侵的想法很荒谬，但为了排除这种可能性，我在Google云平台（GCP）上启动了一台服务器，结果还是观察到同一个未知IP地址重复发送我的HTTP请求。AWS的嫌疑被排除了。
剩下唯一合理的可能性就是我的调制解调器被黑了，但攻击者是谁呢？我查询了IP地址的所有者，发现这个IP地址属于DigitalOcean。这很奇怪，这肯定不是我的ISP。
159.65.76.209，你是谁？
为了展开调查，我将这个IP地址发送给了一些在网络安全情报公司工作的朋友。他们发给我一个VirusTotal的链接，其中详细列出了过去几年中解析到这个IP地址的所有域名。
在最近解析到该IP地址的5个域名中，有3个是钓鱼网站，2个看起来是邮件服务器。以下这些域名都曾解析为DigitalOcean的这个IP地址：
与IP地址159.65.76.209关联的两个域名是isglatam.online和isglatam.tk。这两个域名都曾是钓鱼网站，来自南美一家名为ISG Latam的网络安全公司isglatam.com。
实际访问了ISG Latam的网站后，我了解到他们总部位于巴拉圭，与CrowdStrike、AppGate、Acunetix、DarkTrace和ForcePoint等公司有合作。花了十分钟详细阅读后，我发现拦截我流量的人曾试图使用同一个IP地址对ISG Latam进行钓鱼攻击。
黑客攻击黑客？
这真是奇怪。就在一年前，这个IP地址曾被用于托管针对南美一家网络安全公司的钓鱼基础设施。假设他们控制这个IP地址已经三年了，那么这意味着，他们至少使用这个IP地址进行了两次不同的钓鱼活动，还似乎曾作为路由器恶意软件的指挥和控制（C&C）服务器？
通过URLscan，我了解到isglatam.online和isglatam.tk网站曾托管过通用BeEF钓鱼网站。
攻击者的签名非常有趣，因为他们通过同一台设备上进行了许多不同的不法活动，而且显然在过去的3年中并没有被暂停。很难搞清楚他们在Adidas、ISG Latam和调制解调器黑客事件中的意图，因为它们都来自同一个IP地址。这个IP地址可能已经在多年中几经易手，但又似乎不太可能，因为各个事件之间的间隔很长，而且不太可能立即重新分配给另一个不法团伙。
此时，我突然想起被感染的设备仍在运行，于是我走过去，拔下插头，然后把它放进了一个纸箱。
提供证据
我使用的调制解调器是Cox Panoramic Wifi网关。在得知该设备很可能被入侵后，我去了当地的Cox商店，向他们展示了我的设备，并要求换一个新的设备。
这个请求的唯一问题是，为了换取新的调制解调器，我必须交出旧的。可悲的是，这台设备并不是我的财产，而是我跟ISP租来的。我向Cox的员工解释，我想要保留这台设备，并实施逆向工程。他们瞪大了双眼。看似他们并不想把设备还给我。
我问道：“我不能保留这台设备吗？”ISP的代表说：“不行，我们必须拿走旧设备，才能给您一台新设备”。没有商量的余地。尽管我很想拆开设备，转储固件，看看能否发现任何潜在的被入侵痕迹，但可惜我已经把设备交给了员工。于是，我拿起新设备离开了商店。我感到很失望，因为我没法进行进一步的调查了。
设置好新的调制解调器后，以前的行为完全停止了。我的流量不会再被重复发送了。日志中也没有“其他IP”。一切看似都修好了。
我已经无法调查自己的调制解调器是如何被入侵的，我有点失望。因为我已经把设备交给了ISP，并换取了新设备，所以我只能检查电脑是否被入侵，除此之外，什么都做不了。
我放弃查找原因。至少短期内只能这样了。
三年后
三年后，也就是2024年初，我和一些从事网络安全工作的朋友一起去度假。晚餐期间，我向他们讲述了这个故事。他们饶有兴致，要求我详细讲述所有细节，而且他们认为亲自调查一次会很有趣。
引起他们注意的第一件事是两个邮件服务器域名的格式（limit742921.tokyo 和 jingoism44769.xyz）。他们提取了limit742921.tokyo的mx1子域名的IP地址，然后对所有曾经指向同一个IP地址的域名进行了反向IP搜索。结果发现有超过1,000个域名都遵循完全相同的模式……
他们找到的每一个IP地址注册的域名都使用了相同的命名规则：
[1个单词][6个数字].[顶级域名]
由于注册地址的域名和算法结构的数量很大，我们认为这是恶意软件运营商使用的域名生成算法，用于轮转解析C＆C服务器的地址，以达到混淆视听的目的。反复发送我的流量的IP地址很有可能是一个C&C服务器，我认为是邮件服务器的两个域名实际上是算法生成的指向C&C服务器的指针。
有些令人失望的是，这些域名都已成为历史，最后一个注册于2023年3月17日。我们无法再解析这些域名，也找不到任何类似的注册到同一个IP地址的域名。
鉴于我之前的调制解调器被入侵了，而新设备是同一型号，我很好奇攻击者是否找到了重新入侵的方法。在网上快速搜索了一番后，我了解到我的调制解调器型号并没有公开的漏洞，如今已事隔三年，如果存在漏洞，他们也做好了保密工作。
另一种可能性是，他们利用的漏洞并非出自通用路由器，而且看似这种可能性更大。我非常好奇，想要调查一下我的设备可能是如何被入侵的。
利用TR-069协议攻击REST API
回到家后，恰好一位好朋友要搬家，问我能否帮忙。我帮他转移了Cox调制解调器，在连接到光纤线路后，我拨打了ISP支持电话，询问他们能否推送更新，以便设备可以在新位置上工作。代理确认他们可以远程更新设备设置，包括更改WiFi密码和查看连接的设备。
支持代理能够控制设备的能力引起了我的兴趣，尤其是他们几乎可以更新设备上的任何东西。这种广泛的访问是通过一种名为TR-069的协议实现的，该协议于2004年实现，允许ISP通过7547端口管理其网络内的设备。此协议已成为多个技术大会的演讲主题，而且没有对外公开，所以我对发现该协议的漏洞并不感兴趣。但是，我对支持代理用来管理设备的工具非常感兴趣。
理论上，如果我是一名想要入侵我的调制解调器的黑客，我可能会瞄准代理使用的支持工具底层的基础设施。支持代理可能会使用管理设备的内部网站，后台由一个API提供支持，可以执行任意命令并更改或查看客户设备的管理设置。如果我能找到某种方法访问这些功能，就能发现我最初被黑的真相，或者至少能杜绝一种入侵我的调制解调器的途径。
入侵数百万台调制解调器
我决定首先查看Cox Business的门户网站。该网站有很多有趣的功能，可以远程管理设备、设置防火墙规则和监控网络流量。
虽然没有Cox Business的账号，但我打开了门户网站的登录页面，并抓取了一个名为main.36624ed36fb0ff5b.js的文件，其中提供了网站的一些核心功能。在格式化该文件后，我解析出了所有的路径并浏览了一遍：
有100多个不同的API调用都使用了相同的基础路径/api/cbma/。由于这个路径提供的功能似乎大部分都与设备相关，所以我认为值得调查一下/api/cbma/端点是否是另一个主机的反向代理。为了验证我的想法，我发送了以下请求：
不以api/cbma开头的HTTP请求（返回301）：
以api/cbma开头的HTTP请求（返回500）：
通过发送上述HTTP请求，我了解到api/cbma端点是一个明确的路径，并且很可能是另一个主机的反向代理，因为HTTP响应的行为不同。当我请求api/cbma之外的任何内容时，它会响应302重定向，而不是来自api/cbma的500内部服务器错误。
这表明他们将API请求代理到了一个专用后端，同时从常规系统提供前端文件。
由于API本身提供了所有的设备管理功能，所以我的重点应该放在api/cbma路径的后半段，看看是否存在容易被入侵的漏洞，比如暴露的执行器、API文档或任何目录遍历漏洞，这些漏洞都可以帮助我们提升权限。
于是，我给api/cbma路径下的Cox Business门户的注册请求做了个代理：
这个HTTP请求包含了一堆不同的授权，包括用户之间共享的通用API密钥。clientid和Cb_session键看起来是自定义的，这表明应用程序中使用了多种角色和权限。
HTTP响应看起来像是一个通用的Spring响应，我们只需简单地将POST请求改为GET请求，然后观察响应，就可以确认后端API是否运行在Spring上：
没错，这确实是一个Spring错误。由于已确认反向代理运行的是Spring，所以我决定检查执行器和暴露的API文档。
我想试试看能不能猜中执行器的路径：
很遗憾，看来攻克执行器没有那么简单。接着，我检查了API文档：
找到了！一个Swagger 登录页面的路径为：/api/cbma/profile/swagger-ui/index.html。我加载了这个页面，本以为会看到 API 路径，然而……
一片空白。由于某种原因导致页面未能加载。我检查了网络流量，似乎在尝试加载任何静态资源时出现了一个无限重定向循环：
看起来页面的静态资源（.png、.js、.css）的加载请求都是通过基本URI路由的，而不是通过反向代理API主机。这意味着，静态资源的代理存在某种规则，因此我更改了扩展名：
确认遇到.js 扩展名，请求会被路由到原主机后，我们需要找到一种方法，从 API 反向代理加载资源，但又不触发路由静态文件的规则条件。由于请求需要通过代理，所以最简单的方法是检查是否存在任何可以在传输中“丢弃”的字符。
从反向代理 API 加载静态资源
为了测试这一点，我使用了 Burp 的 Intruder，挨个试URL末尾的字符：从%00到%FF。大约 30 秒后，我获得了200 OK 的响应，URL末尾的字符为%2f（/的编码）：
只需在.js 扩展名后面加上%2f，我们就可以加载 JS 文件。我使用 Burp 的匹配和替换功能编写了一个规则，为所有静态资源添加了%2f，然后重新加载了页面。
然后，Swagger 路径就顺利加载了。我使用相同的技巧加载了所有其他 API 端点的 Swagger 文档。总共有大约 700 个不同的 API 调用，每个 API 的调用数量如下：
快速浏览之后，我发现以下 API 拥有的与硬件交互和访问客户账户的功能最多：
我复制了注册网站的 HTTP 请求，并运行了一个 Intruder 脚本来访问每一个 GET 端点，检查是否存在未经身份验证即可访问的 API 端点。返回的结果非常有趣。有一半端点返回了授权错误，而另一半则返回了 200 OK 的 HTTP 响应。
意外发现 Cox 后端 API可以绕过授权
在利用Intruder扫描了所有 API 端点后，我快速检查了一下是否存在任何有趣的响应。以下"profilesearch"端点有一个有趣的 HTTP 响应，似乎是一个空搜索返回了一个空 JSON 对象：
检查JavaScript代码，似乎我们需要在 URI 中添加一个参数来搜索配置文件。于是我在 URI 中输入了 test，得到了以下响应：
无效的用户令牌？可我刚才还能访问这个端点？我删除了URI中的test，并重新发送了请求。又一个授权错误！由于某种原因，现在原始的端点没有参数时会返回授权错误，但我在运行 intruder 时可以直接访问这个端点。
我检查了一遍，并确认了 intruder 和我后来发送的请求之间没有发生任何变化。我又发了一遍请求，但令人惊讶的是，这一次返回了 200 OK 和来自 intruder 的 JSON 响应！到底怎么回事？似乎这个端点有时会返回授权错误，有时又说请求成功。
为了测试实际的搜索查询能否重现这个问题，我在 URI 中写入了 cox 并重新发送了 2~3 次请求，直到看到以下响应：
我的天！这似乎是 Cox 商业客户的个人资料。虽然没有太高的期待，但我将单词 "cox" 替换为 "fbi"，想看看能否真的提取客户数据：
不会吧？上面的响应包含了几个 FBI 办公室的真实地址，他们是 Cox 的商业客户。管理客户搜索 API 请求真的成功了。这可不太妙！
以上，我已确认只需简单地重复发送 HTTP 请求，就可以绕开 API 端点的授权，而且可供使用的API请求有700多个。下面，我们来试试看真正的影响力。
确认我们可以访问任何人的设备
我回顾了入侵扫描的结果，现在我知道只需重复发送请求就可以绕过授权。为了弄清楚是否可以利用这个漏洞黑掉我的调制解调器，我需要知道这个 API 是否拥有住宅网络的访问控制级权限。Cox 提供了住宅服务和商业服务，但我猜测底层 API 实际上拥有两者的访问权限。
接着，我提取了一个看似很简单的请求，这个请求接受一个 macAddress 参数，我想通过它测试能否通过 API 访问我的调制解调器。
这是一个 GET 请求，可用于检索调制解调器的 IP 地址，需要一个 macAddress 参数。我登录到 Cox，获取了自己的 MAC 地址，然后一遍又一遍地发送 HTTP 请求，直到返回 200 OK：
居然真的成功了！我通过 Cox Business 网站 API 访问了自己的设备！这意味着，我们可以利用这个网站上运行的任何API来与设备通信。Cox 为几百万客户提供服务，而我可以利用这个 API 直接通过 MAC 地址与任何人的设备进行通信。
接下来我需要搞清楚的问题是，我们能否通过某人的账号ID访问他们的硬件MAC地址。我在 Swagger 列表中找到了一个端点accountequipment/services/accountequipment/v1/equipments，然后使用我的账号ID运行Burp Repeater，返回信息如下：
成功了！HTTP 响应返回了我的设备信息。
访问并更新Cox Business的客户账号
为了测试我是否可以利用这个漏洞来访问和修改商业客户的账号，我找到了一条可以通过电子邮件查询客户的 API 请求。我发送的HTTP请求以及获得的响应如下：
另外，我还发送了一条类似的POST账户更新请求，也成功了。这证实了我们确实可以读取和写入商业账号。
到此为止，我已经证明我们可以：
搜索客户，并使用他们的姓名检索商业账户的个人身份信息 ；
检索连接到客户账号的硬件的MAC地址；
通过API，针对MAC地址运行命令。
下面，我们来查找一些真的能够写入设备的API端点，并模拟黑客执行代码。
通过泄露的加密密钥覆盖任何设备的设置
我又查看了一遍 swagger 文档，发现每个硬件修改请求（例如更新设备密码）都需要一个名为 encryptedValue 的参数。如果我能找到生成这个值的方法，就能演示如何写入调制解调器，进而远程执行代码。
为了调查能否生成这个 encryptedValue 参数，我必须深入研究网站的 JavaScript，找出签名方式。
追踪了encryptedValue参数之后，我发现了以下两个函数：
这两个函数都接受仅存在于运行时的变量，所以最简单的调用这两个函数的方法是找到调用它们的用户界面。经过一番搜索后，我发现在注册账户时设置的4位个人识别码使用了相同的函数加密。
我在调用encryptWithSaltAndPadding函数的地方设置了断点，然后按下了回车。
此时，我已经设置了断点，而且还掌握了函数的上下文中，接下来我只需将函数粘贴到控制台，并运行任何我想要的代码。为了验证这种方法确实可行，我复制了POST请求中发送的个人识别码的加密值，并将其传递给解密函数。
果然不出我所料。现在唯一的问题是获取设备的加密值。我询问了一圈，找到了一个做托管服务的朋友，而且他们使用的是Cox Business。他给了我一个账号的登录信息，我看到身份验证结束后，有一个HTTP响应中包含一个加密值参数。我复制了这个值，并传递给了解密函数：
看起来这个加密参数包含了MAC地址，还有一个账号ID和一些额外的参数。
如果这个API通过某种验证机制检查MAC地址是否与账户 ID 匹配，那么利用这个漏洞的难度就会加剧。所以，我展开了进一步的调查。
在任何调制解调器上执行命令
为了检查这个API是否会验证账号ID与MAC地址匹配，我尝试使用垃圾数据签署“encryptedValue”字符串，只保留正确的MAC地址，比如123456789012;1234567;123456789;1;f4:c1:14:70:4d:ac;ANYTHING。
上述参数中唯一有效的是设备序列号。如果此请求有效，则意味着我可以在 API 中使用不匹配账户 ID 的“encryptedValue”参数。
我发送了请求，得到了与上面完全相同的 HTTP 响应！这证明我们不需要任何额外的参数，只需知道 MAC 地址（我们可以查询客户姓名、获取账户 UUID，然后通过 UUID 获取所有连接的设备），就可以查询任何硬件设备。到此为止，我们建立了一条完整的攻击链。
我编写了以下 HTTP 请求，作为概念验证，更新我自己的设备的 MAC 地址 SSID：
成功了吗？我只获得了一个空的 200 OK 响应。我尝试重新发送 HTTP 请求，但请求超时了。我的网络掉线了。一定是这个更新请求重置了我的设备。
大约 5 分钟后，我的网络重启了。SSID 名称已更新为“Curry”。也就是说，我可以利用这个漏洞，对任何人的设备进行读写操作。
这表明我们确实可以通过这个API调用更新设备的配置。这意味着，黑客可以通过这个API来覆盖配置设置，访问路由器，并在设备上执行命令。此时此刻，我们拥有的权限接近ISP技术支持，而且我们可以利用这些访问权限，通过这些API访问数百万台Cox设备中的任何一个。
我通过Cox的网页联系了他们，并分享了漏洞的详细信息。他们在六小时内关闭了暴露的 API 调用，然后开始解决授权漏洞。第二天，我再也无法重现任何漏洞了。
影响
本文展示了黑客入侵的一种方式，一个陌生的外部攻击者可以执行命令并修改数百万调制解调器的设置，访问任何商业客户的个人身份信息，并获取与ISP技术支持团队相同的权限。
Cox 是美国最大的私营宽带提供商，第三大有线电视提供商，以及第七大电话运营商。他们拥有数百万客户，是十个州内最受欢迎的 ISP。
黑客入侵的具体流程如下：
利用姓名、电话号码、电子邮件地址或账号，通过公开的API搜索Cox的商业客户。
通过第一步查询返回的UUID检索账号的身份信息，包括设备的MAC地址、电子邮件、电话号码和地址。
查询客户的硬件MAC地址，获取WiFi密码和连接的设备。
执行任意命令，更新任何设备属性，并控制受害者账号。
Cox有700多个公开的API，其中许多API都提供了管理功能（例如查询调制解调器的连接设备）。每个API都存在相同的权限问题，即黑客重复发送HTTP请求就可以运行未经授权的命令。
