研究人員發(fā)現(xiàn)，總共存在37個(gè)安全漏洞，影響了四個(gè)開源虛擬網(wǎng)絡(luò)計(jì)算（VNC）實(shí)施，并且自1999年以來的20年中一直存在。
卡巴斯基工業(yè)系統(tǒng)緊急響應(yīng)小組（ICS CERT）安全研究員Pavel Cheremushkin對(duì)LibVNC，TightVNC 1.X，TurboVNC和UltraVNC VNC解決方案中發(fā)現(xiàn)了這些缺陷。該研究人員對(duì)RealVNC進(jìn)行了廣泛分析，因?yàn)樗辉试S進(jìn)行逆向工程，因此未經(jīng)分析。
這些VNC系統(tǒng)可用于多種操作系統(tǒng)，包括但不限于Windows，Linux，macOS，iOS和Android。
VNC實(shí)現(xiàn)由客戶端和服務(wù)器兩部分組成，允許用戶在使用RFB協(xié)議的VNC客戶端的幫助下，遠(yuǎn)程訪問運(yùn)行VNC服務(wù)器的計(jì)算機(jī)，以傳輸“屏幕圖像，鼠標(biāo)移動(dòng)和按鍵事件”。
您可以在下面找到有關(guān)Cheremushkin分析的VNC實(shí)現(xiàn)的更多詳細(xì)信息：
LibVNC –一個(gè)開放源代碼的跨平臺(tái)庫，用于基于RFB協(xié)議創(chuàng)建自定義應(yīng)用程序。LibVNC的服務(wù)器組件例如在VirtualBox中用于通過VNC提供對(duì)虛擬機(jī)的訪問。
UltraVNC –專為Windows開發(fā)的流行的開源VNC實(shí)現(xiàn)。許多工業(yè)自動(dòng)化公司推薦使用RFB協(xié)議連接到遠(yuǎn)程HMI接口。
TightVNC 1.X – RFB協(xié)議的另一種流行實(shí)現(xiàn)。許多工業(yè)自動(dòng)化系統(tǒng)供應(yīng)商推薦使用* nix機(jī)器連接HMI接口。
TurboVNC –開源VNC實(shí)現(xiàn)。使用libjpeg-turbo庫壓縮JPEG圖像以加速圖像傳輸。
可能暴露超過60萬臺(tái)VNC服務(wù)器
根據(jù)這些信息，卡巴斯基的ICS CERT研究人員發(fā)現(xiàn)了 600,000多個(gè)VNC服務(wù)器，這些數(shù)據(jù)可以根據(jù)使用Shodan搜索引擎為連接Internet的設(shè)備收集的信息通過Internet進(jìn)行遠(yuǎn)程訪問-此估計(jì)不包括本地運(yùn)行的VNC服務(wù)器。區(qū)域網(wǎng)絡(luò)。
Cheremushkin發(fā)現(xiàn)的VNC安全漏洞都是由不正確的內(nèi)存使用引起的，利用這些漏洞的攻擊導(dǎo)致拒絕服務(wù)狀態(tài)，故障以及對(duì)用戶信息的未授權(quán)訪問，以及可以在目標(biāo)設(shè)備上運(yùn)行惡意代碼的選項(xiàng)。
卡巴斯基的報(bào)告補(bǔ)充說： “盡管我們的同事的重點(diǎn)是在工業(yè)企業(yè)中使用VNC，但這些威脅與部署該技術(shù)的任何企業(yè)都息息相關(guān)�！�
雖然研究人員向開發(fā)團(tuán)隊(duì)披露的大多數(shù)VNC內(nèi)存損壞漏洞是固定的，但在某些情況下，至今仍未解決。
TightVNC 1.X就是這種情況，其開發(fā)人員表示他們不會(huì)解決發(fā)現(xiàn)的安全問題，因?yàn)樵撥浖牡谝粋�(gè)版本“不再支持其系統(tǒng)的第一個(gè)版本[..]”。他們目前維護(hù)TightVNC 2.X商業(yè)產(chǎn)品。
VNC解決方案中發(fā)現(xiàn)的錯(cuò)誤
Cheremushkin在LibVNC庫中發(fā)現(xiàn)了基于堆的緩沖區(qū)溢出，這可能使攻擊者“繞過ASLR并使用溢出來實(shí)現(xiàn)客戶端上的遠(yuǎn)程代碼執(zhí)行”。
TightVNC附帶了一個(gè)空指針取消引用，導(dǎo)致拒絕系統(tǒng)（DoS）狀態(tài)，以及兩個(gè)堆緩沖區(qū)溢出和一個(gè)全局緩沖區(qū)溢出，這可能導(dǎo)致遠(yuǎn)程代碼執(zhí)行。如上所述，這些安全問題將無法解決。
在TurboVNC服務(wù)器中發(fā)現(xiàn)了堆棧緩沖區(qū)溢出漏洞，盡管該漏洞需要服務(wù)器上的授權(quán)或在連接前對(duì)VNC客戶端進(jìn)行控制，但這可能導(dǎo)致遠(yuǎn)程執(zhí)行代碼。
關(guān)于UltraVNC，研究人員說，他能夠發(fā)現(xiàn)UltraVNC中的“整個(gè)'動(dòng)物園'漏洞-從strcpy和sprintf中的瑣碎緩沖區(qū)溢出到或多或少的好奇漏洞，這些漏洞在現(xiàn)實(shí)世界項(xiàng)目中很少遇到”。
在他發(fā)現(xiàn)的所有UltraVNC缺陷中，緩沖區(qū)下溢跟蹤為CVE-2018-15361，可在100％的攻擊中觸發(fā)DoS，但也可用于遠(yuǎn)程執(zhí)行代碼。CVE-2019-8262已分配給多個(gè)堆緩沖區(qū)溢出漏洞，這些漏洞可能導(dǎo)致遠(yuǎn)程執(zhí)行代碼。
卡巴斯基的Pavel Cheremushkin發(fā)現(xiàn)的已發(fā)現(xiàn)VNC漏洞的完整列表在下表中列出：
| VNC實(shí)施 | 漏洞 |
| VNC庫 | CVE-2018-6307 CVE-2018-15126 CVE-2018-15127 CVE-2018-20019 CVE-2018-20020 CVE-2018-20021 CVE-2018-20022 CVE-2018-20023 CVE-2018-20024 CVE-2019-15681
|
| 緊VNC 1.X | CVE-2019-8287 CVE-2019-15678 CVE-2019-15679 CVE-2019-15680
|
| TurboVNC | |
| 超VNC | CVE-2018-15361 CVE-2019-8258 CVE-2019-8259 CVE-2019-8260 CVE-2019-8261 CVE-2019-8262 CVE-2019-8263 CVE-2019-8264 CVE-2019-8265 CVE-2019-8266 CVE-2019-8267 CVE-2019-8268 CVE-2019-8269 CVE-2019-8270 CVE-2019-8271 CVE-2019-8272 CVE-2019-8273 CVE-2019-8274 CVE-2019-8275 CVE-2019-8276 CVE-2019-8277 CVE-2019-8280
|
“積極的一面是，利用服務(wù)器端漏洞經(jīng)常需要密碼認(rèn)證，并且服務(wù)器出于安全原因可能不允許用戶配置無密碼認(rèn)證方法。例如，UltraVNC就是這種情況�！� Cheremushkin總結(jié)。
“作為防范攻擊的措施，客戶端不應(yīng)連接到未知的VNC服務(wù)器，管理員應(yīng)使用唯一的強(qiáng)密碼在服務(wù)器上配置身份驗(yàn)證。”
卡巴斯基提供以下建議，以阻止攻擊者利用這些VNC安全漏洞：
•檢查哪些設(shè)備可以遠(yuǎn)程連接，并在不需要時(shí)阻止遠(yuǎn)程連接。
•盤點(diǎn)所有遠(yuǎn)程訪問應(yīng)用程序-不僅是VNC-并檢查其版本是否為最新。如果您對(duì)它們的可靠性有疑問，請(qǐng)停止使用它們。如果打算繼續(xù)部署它們，請(qǐng)確保升級(jí)到最新版本。
•使用強(qiáng)密碼保護(hù)您的VNC服務(wù)器。這將使攻擊他們變得更加困難。
•請(qǐng)勿連接到不受信任或未經(jīng)測(cè)試的VNC服務(wù)器。
有關(guān)Cheremushkin發(fā)現(xiàn)的VNC漏洞的更多信息和更多詳細(xì)信息，請(qǐng)參見卡巴斯基實(shí)驗(yàn)室ICS CERT網(wǎng)站上的完整VNC漏洞研究報(bào)告。
經(jīng)營(yíng)性網(wǎng)站備案信息
可信網(wǎng)站信用評(píng)價(jià)
網(wǎng)絡(luò)警察提醒您
誠信網(wǎng)站
中國(guó)互聯(lián)網(wǎng)舉報(bào)中心
網(wǎng)絡(luò)舉報(bào)APP下載