聚焦源代碼安全，網(wǎng)羅國(guó)內(nèi)外最新資訊！編譯：奇安信代碼衛(wèi)士團(tuán)隊(duì)卡巴斯基 web 防護(hù)功能將攔截廣告和追蹤器，警告用戶關(guān)于惡意搜索結(jié)果等等。但這個(gè)功能在瀏覽器中運(yùn)行而且需要和主應(yīng)用程序通信。要確保這種通信的安全性，必須要回答的問(wèn)題是：它把通向王國(guó)的鑰匙放在了哪個(gè)地墊之下？本文作者Wladimir Palant 詳細(xì)分析了自己向卡巴斯基從該功能中找到的多個(gè)漏洞，這里說(shuō)明的是其中一個(gè)。奇安信代碼衛(wèi)士翻譯如下：2018年12月，我可以證實(shí)，多個(gè)網(wǎng)站能夠劫持卡巴斯基瀏覽器腳本與其所有配置中主應(yīng)用程序之間的通信。網(wǎng)站從而能夠以多種方式操縱該應(yīng)用程序，包括禁用廣告攔截和追蹤的防護(hù)功能。卡巴斯基當(dāng)時(shí)表示會(huì)在2019年7月份解決這些問(wèn)題。但進(jìn)一步調(diào)查發(fā)現(xiàn)他們只限制了更為強(qiáng)大的 API 調(diào)用，而任何網(wǎng)站仍然可以訪問(wèn)大量應(yīng)用程序。更糟糕的是，卡巴斯基發(fā)布的新版本泄露了大量用戶系統(tǒng)信息，如卡巴斯基程序的唯一標(biāo)識(shí)符，同時(shí)還引入一個(gè)新問(wèn)題，可導(dǎo)致任意網(wǎng)站觸發(fā)應(yīng)用程序崩潰，使得用戶系統(tǒng)無(wú)法得到病毒防護(hù)功能的保護(hù)。殺毒軟件通常通過(guò)瀏覽器擴(kuò)展實(shí)現(xiàn) web 防護(hù)措施，這樣使得和主應(yīng)用程序的通信更加方便快捷：瀏覽器擴(kuò)展可使用易于保護(hù)的本地消息傳遞機(jī)制 (native messaging)。原生應(yīng)用程序內(nèi)置多種安全預(yù)防措施，指定了哪些瀏覽器擴(kuò)展可以與其連接。但我們這里考慮的環(huán)境不僅僅是瀏覽器擴(kuò)展。如果用戶拒絕安裝卡巴斯基的瀏覽器擴(kuò)展，那么卡巴斯基軟件不會(huì)輕易放手，而是會(huì)直接將必要腳本注入所有的網(wǎng)頁(yè)。這種做法甚至適用于 HTTPS 網(wǎng)站中，因?yàn)榭ò退够鶠榱瞬倏v所有的網(wǎng)站不惜突破 HTTPS 連接。另外，更特別的是 IE 瀏覽器插件。由于IE 瀏覽器并不會(huì)提供適當(dāng)?shù)臄U(kuò)展 API，其插件限制將腳本注入網(wǎng)頁(yè)中。雖然它并不要求操縱網(wǎng)頁(yè)的源代碼，但腳本仍然會(huì)在這些頁(yè)面上下文中執(zhí)行且不會(huì)具備任何特別權(quán)限。因此，卡巴斯基這樣做的目的似乎是為這三種環(huán)境提供和卡巴斯基應(yīng)用程序統(tǒng)一的通信方式。但在其中兩種環(huán)境中，卡巴斯基的腳本所具有的權(quán)限和已被注入腳本的網(wǎng)頁(yè)的權(quán)限完全一樣。那么如何阻止網(wǎng)站連接到使用同樣方式的應(yīng)用程序呢？現(xiàn)在知道這個(gè)任務(wù)的挑戰(zhàn)性有多大了吧？卡巴斯基的卡法人員顯然給出了一種解決方案，不然我也不會(huì)寫(xiě)這么一篇文章了。他們決定在應(yīng)用程序和腳本（他們?cè)诖a中稱之為“signature”）之間共享一個(gè)秘密。在建立連接時(shí)，必須提供這個(gè)秘密值，而本地服務(wù)器只有在收到正確的值之后才會(huì)響應(yīng)。那么，擴(kuò)展和腳本如何才能知道這個(gè)秘密是什么？Chrome 和火狐瀏覽器使用本地消息傳遞機(jī)制進(jìn)行檢索。至于IE 瀏覽器擴(kuò)展和直接被注入網(wǎng)頁(yè)中的腳本在這里變成該腳本的一部分源碼。由于網(wǎng)站受制于同源策略無(wú)法下載該源碼，因此它們無(wú)法讀取該秘密，至少?gòu)睦碚撋蟻?lái)講是這樣的。2018年12月，當(dāng)我查看 Kaspersky Internet Security 2019 產(chǎn)品時(shí)發(fā)現(xiàn)它們的 web 集成代碼在所有的環(huán)境中都在泄露該秘密（CVE-2019-15685）。不管你是用的是什么瀏覽器，也不管是否安裝了瀏覽器擴(kuò)展，所有的瀏覽器都能夠提取到和卡巴斯基主應(yīng)用程序進(jìn)行通信所需的秘密。入之前說(shuō)書(shū)，如果沒(méi)有瀏覽器擴(kuò)展，那么卡巴斯基軟件將直接把腳本注入到網(wǎng)頁(yè)中。由于 JavaScript 是高度動(dòng)態(tài)化的執(zhí)行環(huán)境，因此幾乎可任意遭操控。例如，網(wǎng)站可以替代 WebSocket 對(duì)象并看到腳本和本地服務(wù)器之間建立連接。當(dāng)然，卡巴斯基的開(kāi)發(fā)人員也想到了這種場(chǎng)景，于是他們確保自己的腳本會(huì)在網(wǎng)站腳本之前運(yùn)行。同時(shí)還復(fù)制了 WebSocket 對(duì)象并且僅使用該對(duì)象。但這種方法并非滴水不漏。比如，網(wǎng)站僅能保證再次執(zhí)行相同的腳本，但這次是在受操控的環(huán)境中執(zhí)行。雖然需要腳本 URL 才能這么做，但是它可以自行下載并從響應(yīng)中提取該腳本 URL。如下是我的方法：fetch(location.href).then(response => response.text()).then(text =>{ let match = /<script\b[^>]*src='([^']+kaspersky[^']+\/main.js)'/.exec(text); if (!match) return;
let origWebSocket = WebSocket; WebSocket = function(url){ let prefix = url.replace(/(-labs\.com\/).*/, '$1'); let signature = /-labs\.com\/([^\/]+)/.exec(url)[1]; alert(`Kaspersky API available under ${prefix}, signature is ${signature}`); }; WebSocket.prototype = origWebSocket.prototype;
let script = document.createElement('script'); script.src = match[1]; document.body.appendChild(script);});
IE 瀏覽器擴(kuò)展把門檻又稍微提高了一下。雖然腳本也還是在可遭網(wǎng)站操縱的環(huán)境中運(yùn)行，但腳本執(zhí)行是由該擴(kuò)展直接觸發(fā)的。因此不具備可使網(wǎng)站再次找到并執(zhí)行的腳本 URL。另一方面，該腳本并不會(huì)復(fù)制所有使用的函數(shù)。例如，在沒(méi)有確保 String.prototype.indexOf() 函數(shù)是否遭操縱的情況下就會(huì)調(diào)用它。不過(guò)我們無(wú)法通過(guò)該函數(shù)窺探秘密。然而，結(jié)果調(diào)用它的函數(shù)獲取所傳輸?shù)拿臻g KasperskyLabs 作為第一個(gè)參數(shù)，而這正是存儲(chǔ)所有重要信息的地方。let origIndexOf = String.prototype.indexOf;String.prototype.indexOf = function(...args){ let ns = arguments.callee.caller.arguments[0]; if (ns && ns.SIGNATURE) alert(`Kaspersky API available under ${ns.PREFIX}, signature is ${ns.SIGNATURE}`);
return origIndexOf.apply(this, args);};
從 Chrome 和火狐瀏覽器擴(kuò)展中提取最后，我們?cè)倏聪翪hrome 和火狐瀏覽器擴(kuò)展。和其它場(chǎng)景不同，這里的內(nèi)容腳本是在無(wú)法遭網(wǎng)站操縱的獨(dú)立環(huán)境中執(zhí)行的。因此無(wú)需做任何事情就能避免敏感信息遭泄露，就是不應(yīng)該將敏感信息傳給網(wǎng)頁(yè)。但事實(shí)是 Chrome 和火狐瀏覽器擴(kuò)展也泄露了 API 訪問(wèn)權(quán)限。這里的攻擊利用的是內(nèi)容腳本和被注入網(wǎng)頁(yè)中的框架之間的通信方式中存在一個(gè)缺陷。URL Advisor 框架從程序上來(lái)講最容易觸發(fā)，因此攻擊必須從具有像 www.google.malicious.com這樣主機(jī)名的HTTPS 網(wǎng)站上發(fā)動(dòng)。這里的主機(jī)名以 www.google 開(kāi)頭，確保啟用了 URLAdvisor 并考慮如下 HTML代碼作為搜索結(jié)果：<h3 class='r'><a href='https://example.com/'>safe</a></h3>
URL Advisor 將會(huì)在該鏈接后添加一個(gè)圖像以證實(shí)它是安全的。當(dāng)鼠標(biāo)移動(dòng)到該圖像時(shí)，就會(huì)打開(kāi)一個(gè)具有更多詳情信息的框架：而該框架將接收某些數(shù)據(jù)來(lái)初始化自己，其中包括能夠訪問(wèn)卡巴斯基 API 的一個(gè) commandUrl 值。卡巴斯基開(kāi)發(fā)人員并未使用該指定擴(kuò)展 API 來(lái)和框架通信，而是使用了一個(gè)快捷方式：function SendToFrame(args){ m_balloon.contentWindow.postMessage(ns.JSONStringify(args), '*');}
這里我借用MDN的話，說(shuō)明在擴(kuò)展中使用 window.postMessage，尤其是使用“*”作為第二個(gè)參數(shù)時(shí)會(huì)發(fā)生什么結(jié)果：“Web 或內(nèi)容腳本可以使用帶有“*”的targetOrigin 來(lái)向所有監(jiān)聽(tīng)者廣播，但不鼓勵(lì)這樣做，因?yàn)閿U(kuò)展無(wú)法確認(rèn)這類信息的源，而其它監(jiān)聽(tīng)者（包括不受限的監(jiān)聽(tīng)者）也能竊聽(tīng)。”而這里恰恰就是這種情況，盡管該框架是由擴(kuò)展的內(nèi)容腳本創(chuàng)建的，但也不能保證它仍然包含屬于該擴(kuò)展的頁(yè)面。惡意網(wǎng)頁(yè)能夠檢測(cè)到被創(chuàng)建的框架并替換其內(nèi)容，從而能夠竊聽(tīng)發(fā)送到該框架的任意信息。而框架創(chuàng)建很容易從程序上通過(guò)虛假的 mouseover 事件觸發(fā)。let onMessage = function(event){ alert(`Kaspersky API available under ${JSON.parse(event.data).commandUrl}`);};let frameSource = `<script>window.onmessage = ${onMessage}<\/script>`;
let observer = new MutationObserver(list =>{ for (let mutation of list) { if (!mutation.addedNodes || !mutation.addedNodes.length) continue;
let node = mutation.addedNodes[0]; if (node.localName == 'img') node.dispatchEvent(new MouseEvent('mouseover')); else if (node.localName == 'iframe') node.src = 'data:text/html,' + encodeURIComponent(frameSource); }});observer.observe(document, {childList: true, subtree: true});
這個(gè)場(chǎng)景和之前所述有些微卻別：commandUrl 并不包含連接到該應(yīng)用程序所必須的簽名 (signature) 值。然而它卻包含 ajaxId 和 sessionId 值（下節(jié)將會(huì)講到），因此可導(dǎo)致通過(guò)已經(jīng)存在的會(huì)話發(fā)送命令。從技術(shù)層面講，這里運(yùn)行的并非是本地 web 服務(wù)器，而是混雜所有互聯(lián)網(wǎng)連接的卡巴斯基軟件。它會(huì)直接回復(fù) kis.v2.scr.kaspersky-labs.com 子域名的請(qǐng)求，提供 API 等信息。該 API 可通過(guò) WebSockets 和 AJAX 調(diào)用訪問(wèn)。我將繼續(xù)說(shuō)明后一種調(diào)用方式，因?yàn)樗菀籽菔尽?/span>知道“signature”之后，任何網(wǎng)站都能夠通過(guò)加載如https://ff.kis.v2.scr.kaspersky-labs.com/<SIGNATURE>/init?url=https://www.google.com/這樣的地址初始化會(huì)話。這里的前綴 “ff” 是火狐瀏覽器特有的，在 Chrome、Edge和 IE 瀏覽器中，它就是 gc、me和ie。我們聲明是在https://www.google.com/中被注入的腳本，不過(guò)這其實(shí)也沒(méi)啥關(guān)系。我們從響應(yīng)中得到很多 JSON 數(shù)據(jù)：這里的重要值是 ajaxId 和SeesionId，我們需要通過(guò)它們來(lái)調(diào)用更多的命令。瀏覽器擴(kuò)展能夠禁用廣告攔截和追蹤防護(hù)功能等。但這些功能是為了保護(hù)用戶的安全，因此使網(wǎng)站禁用這些功能顯然是糟糕的，而這也是我剛開(kāi)始PoC 頁(yè)面所做的事情。首先必須連接到 light_popup插件：POST /14B5494F-B7D9-3144-8889-C542E89DC9EC/E039014D-D6B8-1C40-82CA-4670F4165F27/to/light_popup.connect HTTP/1.1Host: ff.kis.v2.scr.kaspersky-labs.comContent-Length: 60
{'result':0,'method':'light_popup.connect','parameters':[1]}
之后，將真實(shí)命令發(fā)送，靜默禁止追蹤防護(hù)功能：POST /14B5494F-B7D9-3144-8889-C542E89DC9EC/E039014D-D6B8-1C40-82CA-4670F4165F27/to/light_popup.command HTTP/1.1Host: ff.kis.v2.scr.kaspersky-labs.comContent-Length: 86
{'result':0,'method':'light_popup.command','parameters':['dnt','EnableDntTask',false]}
參數(shù) ['ab','EnableAntiBannerTask', false] 具有類似的廣告攔截禁用功能。當(dāng)然，這并非能夠控制的所有功能，除此之外還有很多。例如，可以顯示或隱藏虛擬鍵盤?？梢愿慊靸?nèi)部數(shù)據(jù)和其它數(shù)據(jù)?；蛘呖梢韵驈V告黑名單添加過(guò)濾器*，而它和其它動(dòng)作不同，并不需要經(jīng)過(guò)用戶確認(rèn)。 如果用戶不小心接受了該彈出消息，那么 web 就會(huì)崩潰且?guī)缀鯚o(wú)法修復(fù)。而這只是冰山一角：如果應(yīng)用程序的內(nèi)部結(jié)構(gòu)被暴露給任意網(wǎng)站，那么其中所隱藏的漏洞也被暴露了。2019年7月，卡巴斯基通知我稱所有問(wèn)題均已修復(fù)。然而，當(dāng)我嘗試新發(fā)布的 Kaspersky Internet Security 2020 產(chǎn)品時(shí)，仍然能夠很輕松地從被注入腳本中提取秘密，其中主要的問(wèn)題就是將我的 PoC 代碼適用于 API 調(diào)用約定的更改。坦白說(shuō)，我也不能怪卡巴斯基開(kāi)發(fā)人員甚至沒(méi)有做任何嘗試：私以為在他們無(wú)法控制的環(huán)境中保護(hù)自己的腳本注定失敗。更讓人驚訝的是，我發(fā)現(xiàn) Chrome 和火狐瀏覽器中內(nèi)容腳本和框架的通信問(wèn)題本以為容易修復(fù)，但卡巴斯基什么都沒(méi)有做。我的 PoC 頁(yè)面仍然能夠在無(wú)需任何修改的情況下連接到卡巴斯基API。并不是說(shuō)這樣做非常重要：鑒于卡巴斯基解決 Heise Online 報(bào)告的隱私問(wèn)題的方式，被注入的腳本現(xiàn)在出現(xiàn)在固定的地址下了。因此即使瀏覽器是激活狀態(tài)而且不易受攻擊，惡意網(wǎng)站仍然能夠加載并利用該腳本。卡巴斯基的開(kāi)發(fā)人員似乎并未放棄在不安全的環(huán)境中存儲(chǔ)密碼的做法，而是放棄保護(hù) API 的訪問(wèn)權(quán)限。我注意到的變化只是問(wèn)題得到緩解。具體而言： 就我目前所知好，這些限制只有在一些 edge 瀏覽器案例中才會(huì)被規(guī)避。例如，在火狐64 及以下版本中，可以避免發(fā)送 Origion 頭部。IE瀏覽器中的 Origion null 適用于本地文件且看似僅適用于這些文件。因此任意本地文件均可規(guī)避這些限制，但通常在沒(méi)有另外確認(rèn)的情況下，這些文件甚至不可能運(yùn)行 JavaScript 腳本。不止如此，任何 Chrome 或火狐擴(kuò)展都能夠規(guī)避這些限制，當(dāng)然也包括本地安裝的任何應(yīng)用程序。真的，這些措施僅僅設(shè)法限制了對(duì) light_popup 函數(shù)的訪問(wèn)權(quán)限。其它函數(shù)無(wú)法被以相同的方式鎖定，因?yàn)楸蛔⑷氲哪_本也在使用它們，而不僅僅是瀏覽器擴(kuò)展在使用。因此雖然網(wǎng)頁(yè)無(wú)法再禁用廣告攔截功能了，但仍然能夠調(diào)用abn.SetBlockStatus 命令來(lái)靜默地將自己添加到白名單中 (CVE-2019-1568)。另外，網(wǎng)頁(yè)也無(wú)法禁用追蹤保護(hù)功能了。但現(xiàn)在 init 命令的響應(yīng)包含一個(gè) AntiBannerHelpUrlSettings 的值，而該值包含所有關(guān)于用戶的可識(shí)別信息（CVE-2019-15687）。雖然僅僅是為卡巴斯基支持人員提供的，但現(xiàn)在任何網(wǎng)站都可讀取。更不用說(shuō)卡巴斯基仍然授權(quán)網(wǎng)站訪問(wèn)其應(yīng)用程序內(nèi)部結(jié)構(gòu)了。我偶然遇到的一個(gè)問(wèn)題恰恰提供了相關(guān)證據(jù)。結(jié)果表明，卡巴斯基開(kāi)發(fā)人員在增加來(lái)源檢查時(shí)又引入了一個(gè)新的 bug。在初始化會(huì)話時(shí)傳遞不合法的 URL 導(dǎo)致該應(yīng)用程序崩潰，大概有一分鐘的延遲 (CVE-2019-15686)。我再?gòu)?qiáng)調(diào)一次：使這個(gè)殺毒應(yīng)用程序崩潰的是任意網(wǎng)站，它導(dǎo)致你的系統(tǒng)無(wú)任何殺毒防護(hù)措施。而且即使重啟該應(yīng)用程序（有時(shí)它會(huì)自動(dòng)重啟），它的 web 防護(hù)組件也不會(huì)運(yùn)行，這樣必須同時(shí)重啟瀏覽器。這里發(fā)生了什么？網(wǎng)頁(yè)試圖加載https://ff.kis.v2.scr.kaspersky-labs.com/<SIGNATURE>/init?url=ha!。當(dāng)處理該請(qǐng)求時(shí)，應(yīng)用程序會(huì)解析這里提到的 URL 并試圖從中復(fù)制原始部分。它把URL 的開(kāi)頭部分復(fù)制到主機(jī)名的末尾。除非不存在主機(jī)名，而該結(jié)構(gòu)的相應(yīng)成員是一個(gè)空解指針。這就導(dǎo)致該應(yīng)用程序?yàn)閺?fù)制結(jié)果分配了大量?jī)?nèi)存緩沖區(qū)（指針差作為無(wú)符號(hào)整數(shù)），而且如果出現(xiàn)內(nèi)存分配失敗這種幸運(yùn)的結(jié)果，使應(yīng)用程序可以處理相應(yīng)的異常。然而，更常見(jiàn)的情況是內(nèi)存分配成功執(zhí)行，而應(yīng)用程序開(kāi)始復(fù)制數(shù)據(jù)。最后，它會(huì)達(dá)到未分配的內(nèi)存區(qū)域，進(jìn)而出現(xiàn)界外讀取，最終崩潰。我自己并非內(nèi)存安全出錯(cuò)方面的專家。雖然有文章認(rèn)為“損壞敏感信息”和“代碼執(zhí)行”是這類漏洞的潛在影響，但我真的不知道這里會(huì)如何產(chǎn)生這樣的后果。從業(yè)余者的角度來(lái)看，我認(rèn)為這個(gè)問(wèn)題會(huì)導(dǎo)致拒絕服務(wù)攻擊，除此以外無(wú)它。但這種后果已經(jīng)相當(dāng)嚴(yán)重了。幾周前，卡巴斯基再次通知我表示漏洞已修復(fù)。如我所料，訪問(wèn)其 API 的權(quán)限仍然未受限制。即使在安裝瀏覽器擴(kuò)展的情況下，內(nèi)容腳本和其框架之間通信不安全的問(wèn)題仍然存在。因此網(wǎng)站仍然能夠連接到卡巴斯基的應(yīng)用程序。而他們明顯改動(dòng)的地方是，網(wǎng)站上禁用 anti-banner 的功能被遷移到無(wú)法由網(wǎng)站使用的 light_popup 插件中了。因此影響得到了進(jìn)一步的控制。Init 調(diào)用的響應(yīng)也進(jìn)行了更改，它無(wú)法暴露任何敏感數(shù)據(jù)。但是，崩潰問(wèn)題怎樣了？解決了。除非你傳遞的值像http:///(它是具有空主機(jī)名的合法地址),否則仍然會(huì)崩潰。幸運(yùn)的是，制種情況只有在繞過(guò)來(lái)源檢查的情況下才會(huì)發(fā)生，因此網(wǎng)站再無(wú)法觸發(fā)這種崩潰了，只有本地應(yīng)用程序或?yàn)g覽器擴(kuò)展才能辦到。卡巴斯基表示，余下的問(wèn)題將會(huì)在下一個(gè)補(bǔ)丁中發(fā)布，會(huì)在幾天內(nèi)有結(jié)果。總體而言，我對(duì)卡巴斯基的修復(fù)情況不甚滿意。距離發(fā)報(bào)告已過(guò)去將近一年了，根本問(wèn)題還未解決，卡巴斯基做的只是控制破壞。只要卡巴斯基開(kāi)發(fā)人員堅(jiān)持向網(wǎng)頁(yè)中注入腳本，作為用戶拒絕安裝其擴(kuò)展場(chǎng)景下的退路，那么保護(hù)其內(nèi)部 API 訪問(wèn)權(quán)限的結(jié)果注定會(huì)失敗。他們似乎也是這樣認(rèn)為的，因此他們甚至都不嘗試一下，而是試圖保護(hù)瀏覽器擴(kuò)展使用更為廣泛的更加強(qiáng)大的 API 調(diào)用。然而這種方式仍然導(dǎo)致網(wǎng)頁(yè)能訪問(wèn)多種功能。界外讀取漏洞尤令人煩心。這種漏洞似乎“僅能”使應(yīng)用程序崩潰，導(dǎo)致用戶系統(tǒng)裸奔。但我注意到大量代碼使用的數(shù)據(jù)結(jié)構(gòu)并不具備內(nèi)置安全性。由于本文所述問(wèn)題的存在，網(wǎng)頁(yè)能夠訪問(wèn)很多代碼，后續(xù)應(yīng)該會(huì)看到更多的內(nèi)存安全問(wèn)題爆出。截至目前，我已經(jīng)查看了其它殺毒解決方案（F-Secure、McAfee、Norton、Avast/AVG）。它們都只是依靠瀏覽器擴(kuò)展來(lái)管理“web 防護(hù)”組件。可能卡巴斯基太癡迷于將腳本直接注入網(wǎng)頁(yè)的做法了，確實(shí)這也是它們產(chǎn)品的一大特色，畢竟即使用戶拒絕安裝擴(kuò)展它也能執(zhí)行自己的任務(wù)。但是這一功能也是一個(gè)安全威脅，而且似乎是無(wú)法解決的威脅。因此我只能寄希望于它最終能克服這個(gè)問(wèn)題吧。2018-12-21: 通過(guò)卡巴斯基漏洞獎(jiǎng)勵(lì)計(jì)劃提交三分關(guān)于 API 劫持的漏洞報(bào)告：分別影響注入腳本、IE 擴(kuò)展和 Chrome/火狐瀏覽器擴(kuò)展。
2018-12-24: 卡巴斯基確認(rèn)漏洞存在并表示正在著手修復(fù)。
2019-07-29: 卡巴斯基將問(wèn)題標(biāo)注為“已解決”。
2019-07-29: 請(qǐng)求公開(kāi)漏洞報(bào)告。
2019-08-05: 卡巴斯基拒絕披露請(qǐng)求，指出用戶需要時(shí)間來(lái)更新老舊版本后來(lái)討論決定將“11月左右”作為最終披露時(shí)間。
2019-08-19: 向卡巴斯基發(fā)送了另外兩份報(bào)告：內(nèi)部 API 仍然可被網(wǎng)頁(yè)訪問(wèn)且它仍然泄露信息，而傳遞不合法的 URL 可能會(huì)引發(fā)拒絕服務(wù)攻擊。披露最后期限定在2019年11月25日。
2019-08-19: 通知卡巴斯基稱我計(jì)劃在11月25日發(fā)布博客文章。
2019-08-19: 卡巴斯基表示已經(jīng)收到新報(bào)告，承諾在完成首次分析后進(jìn)一步溝通（但未兌現(xiàn)）。
2019-08-23:我跟進(jìn)郵件表示內(nèi)部 API 仍然可被以多種方式濫用，如操縱廣告攔截配置等方法。
2019-11-07: 卡巴斯基通知我稱問(wèn)題已經(jīng)在2019（Patch I）和2020 （PatchE）家族產(chǎn)品中解決。
2019-11-15: 我評(píng)估修復(fù)方案后告知卡巴斯基崩潰修復(fù)方案并不完整。
2019-11-20: 卡巴斯基表示將在未來(lái)幾天內(nèi)提供完整的崩潰修復(fù)方案，應(yīng)該會(huì)在11月28日完成。
據(jù) ZDNet 報(bào)道稱，卡巴斯基表示該問(wèn)題已修復(fù)。
