簡介

兩年前，我發現我家的網絡上出現了一件怪事。當時，我發現了一個漏洞，這個漏洞需要一個外部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等公司有合作?；耸昼娫敿氶喿x后，我發現攔截我流量的人曾試圖使用同一個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賬戶更新請求，也成功了。這證實了我們確實可以讀取和寫入商業賬號。

到此為止，我已經證明我們可以：

1. 搜索客戶，并使用他們的姓名檢索商業賬戶的個人身份信息 ；

2. 檢索連接到客戶賬號的硬件的MAC地址；

3. 通過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請求就可以運行未經授權的命令。

由 CSDN 和 Boolan 聯合主辦的「2024 全球軟件研發技術大會（SDCon）」將于 7 月 4 -5 日在北京威斯汀酒店舉行。

由世界著名軟件架構大師、云原生和微服務領域技術先驅 Chris Richardson 和 MIT 計算機與 AI 實驗室(CSAIL)副主任，ACM Fellow Daniel Jackson 領銜，華為、BAT、微軟、字節跳動、京東等技術專家將齊聚一堂，共同探討軟件開發的最前沿趨勢與技術實踐。