據(jù)悉，uClibc庫域名系統(tǒng)(DNS)組件中的一個(gè)漏洞影響了數(shù)百萬的物聯(lián)網(wǎng)設(shè)備。

全球工業(yè)網(wǎng)絡(luò)安全領(lǐng)域領(lǐng)導(dǎo)者Nozomi Networks警告說，大量物聯(lián)網(wǎng)產(chǎn)品使用的uClibc庫域名系統(tǒng)(DNS)組件中存在漏洞，被追蹤為CVE-2022-05-02。該漏洞還影響所有版本的uClibc-ng庫的域名系統(tǒng)(DNS)，uClibc-ng庫是專門為關(guān)鍵基礎(chǔ)設(shè)施部門路由器的通用操作系統(tǒng)OpenWRT設(shè)計(jì)的分支。

攻擊者可以利用該漏洞發(fā)起DNS緩存中毒或DNS欺騙的網(wǎng)絡(luò)攻擊，并將受害者重定向到惡意網(wǎng)站而不是合法網(wǎng)站。

Nozomi Networks在公告中表示，該漏洞是由庫生成的DNS請(qǐng)求中包含的事務(wù)ID可預(yù)測(cè)性引起的，這使得攻擊者能夠?qū)δ繕?biāo)設(shè)備發(fā)起DNS中毒攻擊。

uClibc庫被主要的供應(yīng)商使用，包括Linksys、Netgear和Axis，以及Embedded Gentoo等Linux發(fā)行版。因?yàn)楣?yīng)商尚未解決該問題，所以安全專家沒有透露該漏洞的細(xì)節(jié)。

Nozomi的研究人員通過查看物聯(lián)網(wǎng)設(shè)備在其測(cè)試環(huán)境中執(zhí)行DNS請(qǐng)求的過程發(fā)現(xiàn)了這個(gè)問題。他們能夠從Wireshark的輸出中確定執(zhí)行DNS請(qǐng)求的模式，事務(wù)ID首先是遞增的，然后重置為0x2值，然后再次遞增。請(qǐng)求的事務(wù)ID是可預(yù)測(cè)的，這種情況可能允許攻擊者在某些情況下發(fā)起DNS中毒攻擊。

研究人員分析了該可執(zhí)行文件，發(fā)現(xiàn)創(chuàng)建DNS請(qǐng)求的問題存在于C標(biāo)準(zhǔn)庫uClibc的0.9.33.2版本中。

Nozomi Networks還表示：“源代碼審查顯示，uClibc庫通過調(diào)用位于源文件"/libc/inet/resolv.c "中的內(nèi)部"__dns_lookup "函數(shù)來實(shí)現(xiàn)DNS請(qǐng)求。鑒于事務(wù)ID現(xiàn)在是可預(yù)測(cè)的，要利用該漏洞，攻擊者需要制作包含正確源端口的DNS響應(yīng)，并贏得它與合法DNS響應(yīng)之間的競(jìng)爭(zhēng)。該漏洞的可利用性完全取決于這些因素。由于該功能沒有應(yīng)用任何明確的源端口隨機(jī)化，如果操作系統(tǒng)被配置為使用固定或可預(yù)測(cè)的源端口，它就很可能被輕松地利用。”

如果操作系統(tǒng)使用源端口的隨機(jī)化，則利用該問題的唯一方法是通過發(fā)送多個(gè)DNS響應(yīng)來暴力破解16位源端口號(hào)，同時(shí)贏得與合法響應(yīng)之間的競(jìng)爭(zhēng)。

Nozomi Networks總結(jié)道：“正如預(yù)期的那樣，截至本博客發(fā)布時(shí)，該漏洞仍未被修補(bǔ)。維護(hù)者無法為該漏洞開發(fā)修復(fù)程序，他們希望能夠獲得幫助。自2022年1月以來，計(jì)算機(jī)緊急事件響應(yīng)小組協(xié)調(diào)中心已向200多家受邀參與VINCE案例的供應(yīng)商披露了該漏洞。”