危險(xiǎn)！ChatGPT存在“零點(diǎn)擊攻擊”安全問題。

用戶無需點(diǎn)擊，攻擊者也能從ChatGPT連接的第三方應(yīng)用竊取敏感數(shù)據(jù)，甚至竊取API密鑰。

一位研究軟件安全問題，名為塔米爾·伊沙雅·沙爾巴特（Tamir Ishay Sharbat）的小哥發(fā)了篇文章說道。

OpenAI也意識(shí)到這種安全漏洞問題，并采取了防范措施，但是仍然抵擋不了攻擊者通過其他方法惡意入侵。

也有網(wǎng)友指出，這是規(guī)模化的安全問題。

一起看下怎么回事。

攻擊鏈?zhǔn)窃趺葱纬傻?/span>

這個(gè)漏洞出現(xiàn)在攻擊ChatGPT連接第三方應(yīng)用這個(gè)環(huán)節(jié)。

攻擊者通過向被連接的第三方應(yīng)用（如Google Drive、SharePoint等）中傳輸?shù)奈臋n里注入惡意提示，使ChatGPT在搜索和處理文檔時(shí)，不知不覺地將敏感信息作為圖片URL的參數(shù)發(fā)送到攻擊者控制的服務(wù)器。

這樣攻擊者就可以竊取敏感數(shù)據(jù)，甚至API密鑰，詳細(xì)技術(shù)操作過程如下。

入侵過程

用戶直接把文檔上傳到ChatGPT讓它分析并給出答案。

攻擊者會(huì)在文檔里注入惡意指令，就是在文檔中注入一個(gè)不可見的提示注入載荷（比如，隱藏在文檔中，1px白色字體），然后等待有人將其上傳到ChatGPT并處理，從而AI被誘導(dǎo)執(zhí)行攻擊行為，如下圖所示。

如果從企業(yè)內(nèi)部風(fēng)險(xiǎn)考慮，有惡意的內(nèi)部工作人員就可以輕松簡單地瀏覽他們可訪問的所有文檔，并污染每一個(gè)文檔。

甚至他們可能向所有用戶散布看起來很可信的長文件，因?yàn)橹榔渌麊T工很可能會(huì)將這些文件上傳到ChatGPT尋求幫助。

這使得攻擊者的間接提示注入，成功進(jìn)入某人ChatGPT的可能性大大增加。

成功進(jìn)入之后，如何將數(shù)據(jù)回傳給攻擊者呢。

這個(gè)出口是通過圖像渲染，如下圖所示。

告訴ChatGPT如何做之后，它可以從特定的URL渲染圖像：

當(dāng)ChatGPT返回Markdown內(nèi)容時(shí)，它就會(huì)在客戶端渲染為圖像。

攻擊者為了竊取數(shù)據(jù)，只需要將想要泄露的信息嵌入到圖像的URL參數(shù)中。

這樣，當(dāng)ChatGPT渲染圖像時(shí)，無需點(diǎn)擊就會(huì)立即向攻擊者的服務(wù)器發(fā)送請(qǐng)求，數(shù)據(jù)就被竊取了。

那攻擊者又是怎么竊取用戶的API密鑰的呢。

攻擊者將以下提示注入載荷嵌入到文檔中，并等待受害者像上面所示的那樣將文檔插入他們的ChatGPT。

這是攻擊者創(chuàng)建的完整提示注入載荷：

如上圖所示，在提示注入中，攻擊者指示ChatGPT不要總結(jié)文檔，而是執(zhí)行以下操作：

1.前往用戶連接的Google Drive，搜索API密鑰。

2.一旦ChatGPT找到API密鑰，將它們嵌入以下短語中：

這將會(huì)生成一張圖片，并向攻擊者的beeceptor（一個(gè)模擬API服務(wù)）端點(diǎn)發(fā)送請(qǐng)求，將受害者的API密鑰作為參數(shù)。

3.為了避免被檢測到，攻擊者指示ChatGPT不要提及它收到的新指令，因?yàn)樗鼈儭艾F(xiàn)在沒有關(guān)系”。

OpenAI防范措施

上述客戶端圖像渲染是一個(gè)強(qiáng)大的數(shù)據(jù)外泄路徑，OpenAI也意識(shí)到了，他們已經(jīng)部署了一些措施防范這樣的漏洞。

具體來說，在ChatGPT渲染圖像之前，客戶端會(huì)進(jìn)行一項(xiàng)緩解措施，檢查URL是否惡意以及是否安全才能渲染。

這項(xiàng)緩解措施會(huì)將URL發(fā)送到名為url_safe的端點(diǎn)，并且只有當(dāng)URL確實(shí)安全時(shí)才會(huì)渲染圖像。

攻擊者隨機(jī)的beeceptor端點(diǎn)就會(huì)被認(rèn)定為不安全并禁止執(zhí)行。

但是，攻擊者也找到了繞過這種防范措施的方法。

攻擊者是如何繞過的

攻擊者清楚ChatGPT非常擅長渲染由微軟開發(fā)的云計(jì)算平臺(tái)服務(wù)Azure Blob托管的圖像。

不僅如此，他們還會(huì)將Azure Blob存儲(chǔ)連接到Azure的日志分析——這樣一來，每當(dāng)有請(qǐng)求發(fā)送到他們存儲(chǔ)的某個(gè)隨機(jī)圖像所在的blob時(shí)，就會(huì)生成一條日志。

他們知道這條日志會(huì)包含與該請(qǐng)求一起發(fā)送的所有參數(shù)。

所以，攻擊者不會(huì)再讓ChatGPT渲染beeceptor端點(diǎn)，而是會(huì)命令它從Azure Blob渲染圖像，并把想要竊取的數(shù)據(jù)作為參數(shù)包含在請(qǐng)求中，如下圖所示。

當(dāng)受害者總結(jié)文檔時(shí)，他們會(huì)得到以下回應(yīng)：

如下圖所示，攻擊者的圖像就已成功渲染，并且在Azure Log Analytics中得到了一個(gè)很棒的請(qǐng)求日志，其中包含了受害者的API密鑰。

這樣一來，攻擊就成功了。

攻擊風(fēng)險(xiǎn)與整體防范措施

除了上面說到的攻擊行為，攻擊者還會(huì)用其他技巧來說服AI大模型做這些不被允許的事情，比如利用特殊字符、“講故事”來繞過AI的安全規(guī)則，執(zhí)行惡意指令。

傳統(tǒng)的安全培訓(xùn)，比如培訓(xùn)員工不點(diǎn)擊可疑鏈接或者電子釣魚郵件，也沒辦法規(guī)避這種安全漏洞。

畢竟文檔在內(nèi)部流轉(zhuǎn)，員工上傳到AI幫忙解析的時(shí)候，無需點(diǎn)擊，數(shù)據(jù)就在后臺(tái)被偷偷竊取了。

如今，企業(yè)采用AI作為提升企業(yè)整體效率的方法越來越普遍。

但是AI工具存在如此嚴(yán)重的安全漏洞，造成企業(yè)數(shù)據(jù)全面泄漏的重大風(fēng)險(xiǎn)（比如人力資源手冊(cè)、財(cái)務(wù)文件或戰(zhàn)略計(jì)劃的SharePoint站點(diǎn)泄露），這個(gè)問題急需解決。

更何況，這不是個(gè)例。除了ChatGPT存在這樣的問題，微軟的Copilot中的“EchoLeak”漏洞也發(fā)生同樣的情況，更不用說針對(duì)其他AI助手的各種提示注入攻擊。

于是就有安全專家提出以下防范建議，

• 為AI連接器權(quán)限實(shí)施嚴(yán)格的訪問控制，遵循最小權(quán)限原則。
• 部署專門為AI agent活動(dòng)設(shè)計(jì)的監(jiān)控解決方案。
• 教育用戶關(guān)于“上傳來源不明的文檔到AI系統(tǒng)”的風(fēng)險(xiǎn)。
• 考慮網(wǎng)絡(luò)級(jí)別的監(jiān)控，以檢測異常的數(shù)據(jù)訪問模式。
• 定期審計(jì)連接的服務(wù)及其權(quán)限級(jí)別。

專家建議是面向企業(yè)的，對(duì)咱們AI工具用戶來說，注意日常AI操作細(xì)節(jié)中存在的問題或許更有用。

有沒有遇到過文檔內(nèi)容被誤讀或感覺“不對(duì)勁”的情況？