在撰寫本文時，一家名為 VoIP.ms 的主要 VoIP 提供商已經(jīng)受到分布式拒絕服務(wù) (DDoS) 攻擊一周多了。結(jié)果，他們無法為他們的客戶服務(wù)，客戶反饋說他們無法連接到 VoIP.ms 的 SIP 服務(wù)器以及其他資源。與此同時，有人聲稱自己是 REvil 勒索軟件組織的一員，要求支付贖金來恢復(fù)業(yè)務(wù)。
這并不是一個孤立的案例，因為本月早些時候，一些英國供應(yīng)商也受到了攻擊，報告還提到 REvil 是攻擊的來源。來自安全社區(qū)的許多人都認(rèn)為它不太可能是真正的 REvil，但這不是我想在這里寫的。
我們確實聯(lián)系了其中一家受到攻擊的英國供應(yīng)商的人，他解釋說，在他們對攻擊流量的采樣中，他們沒有看到任何 SIP 數(shù)據(jù)包。相反，他們確實看到的是 DNS、SNMP 和其他通常出現(xiàn)在放大攻擊和僵尸網(wǎng)絡(luò) DDoS 攻擊中的流量。
通過閱讀這些DDoS攻擊的公開報告，可以清楚地看到，受害公司不僅在其SIP終端遭受攻擊。有人提到了大量的流量，這表明攻擊可能是飽和性的，而不是特定于應(yīng)用程序的。
在 VoIP.ms 的示例中，他們最初有一個 DNS 中斷，然后轉(zhuǎn)向使用 Cloudflare 作為他們的 DNS。他們還將他們的網(wǎng)站置于 Cloudflare 的網(wǎng)站 DDoS 保護之后，并開始要求驗證碼等。
他們還移動了 POP(接入點)SIP 服務(wù)器的 IP 地址，并且在論壇上可以看到人們抱怨 SIP 連接失敗。最近，有人注意到他們正在通過 Cloudflare 的 Magic Transit 路由他們的 SIP 流量，它提供 UDP DDoS 保護。
然而，它們似乎仍然存在斷斷續(xù)續(xù)的連接，或者有時似乎處于離線狀態(tài)。
以下是來自 SIPVicious PRO 的 SIP ping 的日志：
這不是SIP服務(wù)器第一次遭到攻擊了
早在 2011 年，一個感染了名為 Sality 的惡意軟件的僵尸網(wǎng)絡(luò)就開始傳播 sipvicious。賽門鐵克當(dāng)時就寫了文章進(jìn)行分析，我們當(dāng)時也進(jìn)行了分析。本質(zhì)上，目標(biāo) SIP 提供商無法處理正在傳播的 SIP 破解攻擊。這與對 SIP 服務(wù)器的 DDoS 攻擊具有相同的效果，即使這可能是無意的。
攻擊 SIP 很容易
我們在進(jìn)行 DoS 和 DDoS 模擬練習(xí)時發(fā)現(xiàn)，攻擊 SIP 服務(wù)器很少需要飽和攻擊。相反，SIP 洪水式攻擊通常會覆蓋大多數(shù)以前從未經(jīng)過測試的 SIP 服務(wù)器，因此可以抵御此類攻擊。對于我們的許多客戶來說，他們已經(jīng)擁有針對 SIP DoS 的保護，但我們經(jīng)常發(fā)現(xiàn)，一旦我們開始傳播，他們的系統(tǒng)就會出現(xiàn)故障。所謂傳播，我指的是少量的服務(wù)器，而不是你在實際攻擊中看到的大規(guī)模僵尸網(wǎng)絡(luò)。
這種失敗的主要原因似乎是保護機制往往沒有任何實際的測試。因此，它們往往有差距，我們在DoS模擬中濫用，導(dǎo)致目標(biāo)服務(wù)停止響應(yīng)合法用戶。
這就是我們經(jīng)常在測試中取得成功的原因。但是還有一個很好的問題要問：為什么 SIP 服務(wù)器如此容易被攻擊?因為SIP服務(wù)器很復(fù)雜。
以下是一些經(jīng)常被攻擊的項：
?身份驗證機制，由于存儲憑據(jù)的數(shù)據(jù)庫存在安全漏洞;
?大量 SIP 調(diào)用導(dǎo)致媒體服務(wù)器端口耗盡;
?處理 SIP 會話和對話所需的 CPU 和/或內(nèi)存使用量超過了可用資源;
?已知會導(dǎo)致錯誤、填充日志文件或日志服務(wù)器的特定格式錯誤的 SIP 消息;
?在基于TCP或TLS的SIP上，我們會遇到文件描述符資源耗盡的情況，特別是在SIP INVITE洪水式攻擊期間;
大多數(shù)都是在沒有大量網(wǎng)絡(luò)流量的情況下觸發(fā)的。不幸的是，即使在速率受限的地方，這些攻擊工作得也相當(dāng)好。
如何測試 SIP DDoS 漏洞?
在測試過程中使用 SIPVicious PRO 的 SIP DoS Flood 工具。在偵察階段，我們進(jìn)行各種測試，以發(fā)現(xiàn)最明顯的漏洞，例如通過測試各種不同的SIP消息類型。在 SIP INVITE 洪水式攻擊的情況下，我們還指定如何處理調(diào)用，是否在某個時間掛斷調(diào)用。并發(fā)連接的數(shù)量或用于 SIP 的傳輸協(xié)議是另一個重要的考慮因素。最后，我們選擇低于任何現(xiàn)有保護機制但高于 SIP 服務(wù)器可能承受的發(fā)送速率。
然后，我們就可以開始攻擊了。
舉個簡單的例子，你可以觀看我們?yōu)?Kamailio World 2019 提供的無腳本演示。
當(dāng)然，設(shè)置目標(biāo)設(shè)備的人沒有時間準(zhǔn)備我們的拒絕服務(wù)測試。運行 FreeSWITCH(我相信它是 FusionPBX 安裝)的系統(tǒng)沒有任何保護。所以這根本不是一個公平的例子，但它確實展示了我們的一些工具，部分地展示了我們?nèi)绾芜M(jìn)行此類測試。
保護和緩解
解決這一威脅的一個很好的解決方案是，首先避免將關(guān)鍵基礎(chǔ)設(shè)施暴露給基于網(wǎng)絡(luò)的攻擊者。
另一方面，如果你的業(yè)務(wù)模型必須把 SIP 服務(wù)器暴露給網(wǎng)絡(luò)，那么緩解措施就不那么明確了。因此，我們首先應(yīng)該區(qū)分飽和攻擊和應(yīng)用程序級攻擊。
容量攻擊所需的保護通常需要DDoS緩解提供商提供足夠大的管道，以處理承受此類攻擊所需的大規(guī)模帶寬。對 VoIP.ms 和英國提供商的攻擊似乎屬于飽和攻擊的范疇。
另一方面，針對特定于SIP或應(yīng)用程序的攻擊的DDoS保護將涉及對基礎(chǔ)設(shè)施、架構(gòu)和底層軟件配置的調(diào)整。通常，人們可能會將配置良好的Kamailio / opensip服務(wù)器放置在邊緣，可能配置為阻止過多的SIP通信。為了使這些變化有效，需要通過DDoS模擬的結(jié)果來通知它們。這個反饋循環(huán)對于加強對此類攻擊的防范至關(guān)重要。
如果對 VoIP.ms 的攻擊實際上確實包含飽和攻擊中的 SIP 流量，那么很可能需要兩種保護或緩解機制來實際解決它們的問題。這或許可以解釋為什么即使在 Cloudflare 的 Magic Transit 之后，VoIP.ms 似乎仍然存在重大安全隱患。
參考及來源：https://www.rtcsec.com/post/2021/09/massive-ddos-attacks-on-voip-providers-and-simulated-ddos-testing/
原文來源：嘶吼專業(yè)版
