本文经授权转自公众号CSDN（ID：CSDNnews）
本文作者通过偶然间发现了网络上存在的一个漏洞，顺藤摸瓜，有了一些意外的发现。
原文链接：https://samcurry.net/hacking-millions-of-modems
1、简介
两年前，我发现我家的网络上出现了一件怪事。当时，我发现了一个漏洞，这个漏洞需要一个外部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。
2、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进行钓鱼攻击。
3、黑客攻击黑客？
这真是奇怪。就在一年前，这个IP地址曾被用于托管针对南美一家网络安全公司的钓鱼基础设施。假设他们控制这个IP地址已经三年了，那么这意味着，他们至少使用这个IP地址进行了两次不同的钓鱼活动，还似乎曾作为路由器恶意软件的指挥和控制（C&C）服务器？
通过URLscan，我了解到isglatam.online和isglatam.tk网站曾托管过通用BeEF钓鱼网站。
攻击者的签名非常有趣，因为他们通过同一台设备上进行了许多不同的不法活动，而且显然在过去的3年中并没有被暂停。很难搞清楚他们在Adidas、ISG Latam和调制解调器黑客事件中的意图，因为它们都来自同一个IP地址。这个IP地址可能已经在多年中几经易手，但又似乎不太可能，因为各个事件之间的间隔很长，而且不太可能立即重新分配给另一个不法团伙。
此时，我突然想起被感染的设备仍在运行，于是我走过去，拔下插头，然后把它放进了一个纸箱。
4、提供证据
我使用的调制解调器是Cox Panoramic Wifi网关。
在得知该设备很可能被入侵后，我去了当地的Cox商店，向他们展示了我的设备，并要求换一个新的设备。
这个请求的唯一问题是，为了换取新的调制解调器，我必须交出旧的。
可悲的是，这台设备并不是我的财产，而是我跟ISP租来的。
我向Cox的员工解释，我想要保留这台设备，并实施逆向工程。
他们瞪大了双眼。
看似他们并不想把设备还给我。
我问道：
“我不能保留这台设备吗？
”ISP的代表说：
“不行，我们必须拿走旧设备，才能给您一台新设备”。
没有商量的余地。
尽管我很想拆开设备，转储固件，看看能否发现任何潜在的被入侵痕迹，但可惜我已经把设备交给了员工。
于是，我拿起新设备离开了商店。
我感到很失望，因为我没法进行进一步的调查了。
设置好新的调制解调器后，以前的行为完全停止了。
我的流量不会再被重复发送了。
日志中也没有“其他IP”。
一切看似都修好了。
我已经无法调查自己的调制解调器是如何被入侵的，我有点失望。
因为我已经把设备交给了ISP，并换取了新设备，所以我只能检查电脑是否被入侵，除此之外，什么都做不了。
我放弃查找原因。
至少短期内只能这样了。
5、三年后
三年后，也就是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地址的域名。
鉴于我之前的调制解调器被入侵了，而新设备是同一型号，我很好奇攻击者是否找到了重新入侵的方法。在网上快速搜索了一番后，我了解到我的调制解调器型号并没有公开的漏洞，如今已事隔三年，如果存在漏洞，他们也做好了保密工作。
另一种可能性是，他们利用的漏洞并非出自通用路由器，而且看似这种可能性更大。我非常好奇，想要调查一下我的设备可能是如何被入侵的。
6、利用TR-069协议攻击REST API
回到家后，恰好一位好朋友要搬家，问我能否帮忙。
我帮他转移了Cox调制解调器，在连接到光纤线路后，我拨打了ISP支持电话，询问他们能否推送更新，以便设备可以在新位置上工作。
代理确认他们可以远程更新设备设置，包括更改WiFi密码和查看连接的设备。
支持代理能够控制设备的能力引起了我的兴趣，尤其是他们几乎可以更新设备上的任何东西。
这种广泛的访问是通过一种名为TR-069的协议实现的，该协议于2004年实现，允许ISP通过7547端口管理其网络内的设备。
此协议已成为多个技术大会的演讲主题，而且没有对外公开，所以我对发现该协议的漏洞并不感兴趣。
但是，我对支持代理用来管理设备的工具非常感兴趣。
理论上，如果我是一名想要入侵我的调制解调器的黑客，我可能会瞄准代理使用的支持工具底层的基础设施。支持代理可能会使用管理设备的内部网站，后台由一个API提供支持，可以执行任意命令并更改或查看客户设备的管理设置。如果我能找到某种方法访问这些功能，就能发现我最初被黑的真相，或者至少能杜绝一种入侵我的调制解调器的途径。
7、入侵数百万台调制解调器
我决定首先查看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 路径，然而……
