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