基於Ubiquiti設備發現協議的反射攻擊

0x00概述

Ubiquiti（優倍快）網絡公司生產的網絡設備在全球有較廣泛的部署。2019年2月某安全團隊披露了基於Ubiquiti設備的AP發現服務實施的反射DDoS攻擊，攻擊發生在2018年7月，這是最早被爆出該公司網絡設備可被利用作爲DDoS的反射放大器的案例。

攻擊披露後，Ubiquiti網絡公司即時發佈了漏洞補丁，並提醒用戶升級更新。但近幾年來該公司的網絡設備一直被黑客頻繁利用發起DDoS反射放大攻擊。百度安全智雲盾團隊在對抗DDoS攻擊中也經常攔截到此類反射攻擊流量。

0x01 攻擊態勢

1）攻擊趨勢

智雲盾團隊持續關注Ubiquiti反射攻擊態勢，多次針對這類攻擊進行過跟蹤分析。在2020年監測到4301次Ubiquiti反射攻擊，並在去年十月達到頂峯。雖然Ubiquiti公司發佈過補丁修復，但是從智雲盾監測到的攻擊趨勢來看，公網上仍然存在大量的未實施修復的設備。

圖1 Ubituiti反射攻擊態勢

2）首次攻擊

2019年2月安全研究人員Troutman披露黑客自2018年7月開始利用Ubiquiti公司設備上的AP發現服務進行DDoS反射放大攻擊活動，Troutman表示黑客向Ubiquiti設備上開放UDP 10001端口的AP發現服務發送56字節的小數據包，設備立即回覆206字節的數據包。之後另一安全研究人員Jon Hart表示，這類服務的放大倍數可以提高到30-35倍。

Ubiquiti網絡公司官方在關注到這些攻擊後確認了這一問題，並臨時提供了兩個解決方案：1、非必要，禁用UDP 10001上的AP發現服務；2、如果必須使用AP發現服務，開啓僅限內部網絡使用的ACL策略。之後官方第一時間發佈新版本，用於增強該服務器的安全性。

攻擊首次披露後，Ubiquiti網絡公司統計共有485,000個設備向公網開放了UDP 10001端口，攻擊資源分佈在全球各地。

0x02 技術分析

智雲盾系統跟蹤這類攻擊時，自動對流量進行採樣，安全專家及時介入對採樣包進行深層次分析和演練。

1）攻擊分析

通過對智雲盾的攻擊採樣包發現，反射流量的來源端口是10001端口，下圖紅色箭頭指向的是反射源端口

圖2 採樣包內攻擊來源端口

數據包中的payload明顯爲某類設備名稱和版本，通過搜索分析，我們確定了這是Ubiquiti公司的設備和版本信息，採樣包中UDP攜帶的payload如下圖所示：

圖3 採樣包內UDP攜帶的payload

查詢Ubiquiti公司官網可知，他們在UDP10001上使用發現服務協議。這個協議格式與SSDP設備發現服務不同，沒有固定格式，爲此我們將此類反射攻擊命名爲UbiquitiDP Reflection，中文簡稱爲Ubiquiti反射攻擊。

我們提取數據包中的設備名進行統計分析，分析發現有87%的設備名爲Ubiquiti公司標準名稱，並能在公司的官網檢索到，但是有13%的數據包payload帶有HACKED（被黑）字樣，很明顯這些設備名已經被黑客惡意修改。

圖4 設備名稱

我們對含有HACKED的數據進行統計分析發現，分析發現每個名稱均以HACKED-ROUTER-HELP-SOS開頭，剩餘字段有WAS-MFWORM-INFECTED、HAD、VULN-EDB-39710、FTP這四類，其中WAS-MFWORM-INFECTED佔比67%，MFWORM表明這個設備已經被MF蠕蟲感染，我們查詢MF蠕蟲披露的資料很少。少部分設備包含FTP字樣，我們主動探測這些IP的FTP服務發現均關閉，我們推測這些服務器最早可能被黑客利用作爲FTP服務。

圖5 惡意修改主機名的設備

2）Ubiquiti服務缺陷

造成此次攻擊的是Ubiquiti公司設備自帶的AP發現服務，該服務使用UDP傳輸數據，綁定在設備10001端口，響應任何UDP包。

該服務在設計之初便沒有按照UDP協議的安全規範實現，一方面開放到公網的UDP服務應當避免請求與響應存在倍率，另一方面UDP服務本身應對客戶端進行校驗。黑客向設備發送一個構造的UDP最小包，該服務便會返回一個或多個UDP大包，請求與響應相差數倍。

3）攻擊模擬

我們在攻擊模擬的過程中發現，大多數反射源在收到單個請求時只回復一個響應包，但是有少數反射源在收到單個請求後，會響應海量的UDP大包，每個數據包長固定。我們分別對這兩類反射源進行分析，結果如下：

A單包反射

安全專家對該事件深入分析，同時從智雲盾威脅中心提取到的請求流量進行對比，並完成攻擊場景模擬，模擬過程中抓包如下：

圖6 模擬攻擊

圖6中模擬發送了載荷長爲4字節的UDP小包向反射源傳輸無驗證數據，反射源返回載荷長爲512字節的數據包，返回的UDP大包payload包含了Ubiquiti公司的設備信息。

B海量包反射

我們在選取反射源發起請求時，發現有少數IP地址在發送任意內容的UDP請求後，會響應超量的UDP大包，最多的一個反射源響應了3510個UDP大包。

我們向其中一個反射源發送一個空載荷的請求包，並抓包分析，下圖展示了發包過程：

圖7 模擬攻擊

圖8 抓包顯示

服務器共響應3510個UDP大包（去掉一個請求包），每個數據包長度固定爲1370字節，下圖展示了我們發送的空請求與服務器的響應。

圖9 返回超量UDP大包

在測試過程中，我們分別發送空請求、小包和大包UDP請求到反射源，每次均收到海量的UDP大包。這些反射源對任何UDP請求均會響應大量的數據包，危害較大。

我們在單包反射中發送一個請求載荷爲4字節的數據包，收到一個載荷長512字節的響應包。在海量包反射中發送一個0字節的數據包，收到總共3510個載荷長爲1328字節的海量數據包。在智雲盾系統監測到具備響應超量UDP大包的IP共計127個。截止到目前，這些IP仍然可以響應海量UDP大包。

0x03 放大倍數

按照我們前期對反射放大倍數的研究，採用科學的統計放大倍數時，請求響應的包頭甚至網絡間隙都要考慮在內。詳細的方案可以參閱 《Memcached DRDoS攻擊趨勢》 一文。

科學的計算方式還應該考慮每包的網絡間隙20字節，沒有包括FCS字段的4個字節，另外數據包小於60字節會被自動填充到60字節。

協議頭和網絡幀間隙計算爲：14（以太頭）+20（IP頭）+8（UDP頭）+4（FCS頭）+20（幀間隙）=66字節。

單包反射中計算得到的放大倍數爲（512+66）/（60+20+4）=6.88倍。

海量包反射計算得到的放大倍數爲（1328+66）*3510 / （60+20+4）= 58249.29倍。

如果按照傳統方式（攻擊載荷之比）計算海量包反射的放大倍數：1328*3510 / 0（空請求）= ∞，那麼得到的結果爲無窮大，可見這個計算方式存在理論缺陷。

0x04 全網數據

1）Ubiquiti公司介紹

Ubiquiti公司主要在全球範圍內設計、製造和銷售創新性的網絡設備。主品涵蓋了無線設備，安全網關，交換機，遠程管理控制器和攝像機這五種設備。目前Ubiquiti公司的產品部署在全球超過180個國家和地區。

Ubiquiti公司的設備在10001端口會開啓AP發現服務，該服務採用UDP傳輸數據，並且支持客戶端採用組播或者單播的請求方式進行數據交互。

2）反射源

智雲盾共捕獲到的反射源達到39002個。通過對反射源IP進行調查發現。反射源分佈在全球82個國家和地區，其中42%的反射源分佈在美國。驗證發現這些設備都爲Ubiquiti公司的設備並且10001端口對公網UDP請求數據包都響應，TOP10地區分佈如下圖：

圖10 反射源分佈地區TOP10

從zoomeye上對全球10001端口進行檢索發現，全球約有百萬臺公網設備主動暴露了10001端口。這些設備都將可被用作反射源進行攻擊，如下圖所示：

圖11 zoomeye全球數據

我們在zoomeye上查詢被攻擊者惡意修改主機名的數據發現，共計8W多Ubiquiti設備被惡意修改了主機名。

圖12 被惡意破壞主機名的設備

0x05 防範建議

此次攻擊是黑客利用固定設備廠商的UDP服務缺陷發起的DDoS反射放大攻擊。反射攻擊相比較傳統的洪泛攻擊具有更好的隱蔽性，並且流量更大的特點。從我們近期對新型攻擊的監測發現，黑客在尋找新的攻擊方式上不再拘泥於傳統公共服務，而是對暴露在公網，並且具備一定規模的UDP服務都嘗試利用作爲反射源。

針對此次攻擊行爲我們建議相關廠商參考下面方式提升防護能力。

1. 對Ubiquiti公司
1. 10001的AP發現服務應該限制請求響應字節數比例爲1:1
2. 對使用Ubiquiti公司設備的企業用戶
1. 在設備或者上層交換機配置策略，限制非本網段的UDP包請求10001端口.
2. 遵循Ubiquiti的建議，禁止使用AP發現服務
3. 如果必須使用AP發現服務，升級開放10001端口的AP發現服務爲最新版

0x06 智雲盾團隊介紹

智雲盾防護系統基於百度安全成熟的防禦技術，爲數據中心建設安全基礎設施。具備本地快速檢測和防禦DDoS，同時能自動化拓展T級雲防。並集成一系列百度安全能力，在提高數據中心防禦DDoS基礎上，具備完善的安全威脅檢測和防禦能力。

本文分享自微信公衆號 - 百度安全實驗室（BaiduX_lab）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。