再談CSV注入攻擊

02-11

從某些方面來說，CSV注入漏洞是一個老漏洞了，但是在其他方面……好吧，我想幾乎沒有人意識到這個漏洞的破壞性有多大並且這個漏洞無處不在。我曾經看到的很多應用程序都可以使用一些攻擊向量來進行CSV注入，這些應用程序需要用戶輸入一些數據，並允許管理員將這些數據批量導出到CSV文件中。

CSV注入漏洞的確與每一個應用程序都有關。

值得一提的是， 2014年的一篇文章中已經提到了我的這篇文章討論到的一些攻擊向量。當然還有另一篇文章也討論了CSV注入漏洞。

所以讓我們來設置一個場景 – 想像一個時間或標籤跟蹤應用程序。用戶輸入他們的時間（或標籤），但是不能看到其他用戶輸入的內容。然後，網站管理員將數據導出到csv文件中並用電子表格應用程序中打開它。這些操作看起來很正常很規範，沒什麼不對的。

攻擊向量1

CSV文件我想大家都很了解。它最大的特點就是這種文件的結構很簡單。這些導出的數據可能看起來像下面這樣：

UserId,BillToDate,ProjectName,Description,DurationMinutes1,2017-07-25,Test Project,Flipped the jibbet,602,2017-07-25,Important Client,"Bop, dop, and giglip", 240

非常的簡單，並且文件內容沒有什麼危險的東西在裡面。甚至按照RFC文檔的規範來說，CSV文件包含的數據也不會造成什麼危害：

為了好玩一點，讓我們嘗試修改一下數據，內容修改如下：

UserId,BillToDate,ProjectName,Description,DurationMinutes1,2017-07-25,Test Project,Flipped the jibbet,602,2017-07-25,Important Client,"Bop, dop, and giglip", 2402,2017-07-25,Important Client,"=2+5", 240

在Excel中顯示的結果

在Google Sheets中顯示的結果

嗯…看起來很奇怪。儘管單元格里的文本內容被包含在引號中，但它似乎被解釋為一個公式了，就是因為第一個字元是一個等號(=)符號。事實上，在Excel表格里，任何運算符（=、-、+、@等）都能夠觸發這樣的行為，這也是最先引起我注意的地方。這個比較神奇，不過此時還沒有產生什麼危害。

好吧，看起來一個數據公式就是一種可執行的代碼。因此，用戶可以讓代碼（也就是數學公式）在管理員機器上的用戶的安全上下文中進行執行。

那麼如果我們再改一下csv文件的內容呢？（注意最後一行的描述信息那一列）

當我們在Excel中打開這個文件時會發生什麼？

哇靠！嗯，你沒看錯，系統的計算器被打開了。

顯然，這是有問題的。因為這個CSV文件的內容就是一大坨文本，一般人不會仔細查看文件的內容。即使你仔細檢查了數據內容，我也強烈建議你，在任何時候都只打開來源可靠的數據文件。

但是，你知道嗎，這些文件可是管理員從應用程序里導出來的。他們當然非常信任這個來源咯！

可是這些用戶的技術過硬嗎？顯然不是的，那就更糟糕了，他們只知道 CSV格式的文件是一些文本數據，不可能會有什麼有害的。我保證。

就這樣，通過這種攻擊方式，攻擊者就可以免費下載一個鍵盤記錄器，安裝東西，並且不僅可以遠程執行代碼，而且還可以遠程執行任何其他人的計算機上的代碼，而且還可以保證有權訪問所有用戶的數據; 例如經理或公司管理員的數據。我不知道他們可能還會有一些什麼其他類型的文件？

攻擊向量2

好的，上面就是一個的例子，但畢竟那是一個小的且已知的漏洞。作為一名安全專業人員，你可以確保警告所有的管理員要對Excel文件非常小心，甚至可以考慮使用Google表格。畢竟，Google表格不受宏的影響。

那樣做確實沒錯。所以讓我們想一下我們之前的「運行任何我們想要的代碼」的野心，而是著重去竊取數據。畢竟，這裡攻擊成功的前提是攻擊者是普通用戶，只能訪問自己在系統中輸入的內容。管理員擁有更高的許可權，可以看到每個人的數據，我們可以以某種方式入侵嗎？

請記住，雖然我們無法在Google表格中運行宏，但我們絕對可以運行公式。公式不必局限於簡單的算術。事實上，Google Sheets裡面有沒有可以將數據轉移到其他地方的「數學公式」呢？答案當然是肯定的，而且還不少。

讓我們仔細看一下IMPORTXML的語法。

IMPORTXML（url，xpath_query）

當這個方法被執行後，會在運行時對指定的URL進行HTTP GET請求，然後嘗試在我們的電子表格中解析並插入返回的數據。

那麼,如果我們的csv文件包含的內容是下面這樣的：

攻擊者構造了以=符號為前綴的單元格，然後將IMPORTXML的url參數指向其控制的伺服器，附加的參數是電子表格中的數據。現在他們可以打開他們的伺服器日誌和BAM程序。你可以在http://Requestb.in嘗試一下。

這裡的危害是什麼呢？沒有警告，沒有彈出窗口，根本沒有理由去認為這背後的任何事情。攻擊者只需要構造一些類似格式的內容，最後管理員打開導出的CSV文件時，那些被限制為只有管理員才能看到的數據就會被偷偷的發送到攻擊者指定的地方。

然而，事情遠不止這些。

這些公式是在管理員的瀏覽器中運行的，準確的說是在他們的用戶帳戶和安全上下文中執行的。在Google表格中，不僅限於查看自己的數據，實際上他們可以從用戶訪問的其他電子表格中提取數據。所有攻擊者必須知道的是其他工作表的ID。這些信息通常不會被認為是保密數據; 它會出現在電子表格的網址中，並且通常會以電子郵件進行發送，或發布在公司內部的文檔中，依靠Google的安全性，以確保只有授權的用戶才能訪問到該數據。

因此，攻擊者竊取的信息不僅僅是包含了「公式」的表格里的內容。管理員保存在其他表格里的比如客戶信息和工資信息等，只要管理員訪問了這些表格，這些表格中的信息一樣可以在神不知鬼不覺的情況下被竊取。哎呀，太可怕了！

當然，類似的技巧在Excel中也有效。事實上，Excel的這種能力已經被警方利用來跟蹤罪犯。

但，這並不一定。

我已經向很多安全研究人員展示了這些攻擊手法，他們指出了各種惡作劇的做法。例如，一名在他們自己的通信中植入信息的犯罪分子，這些信息可以發到他們控制的伺服器上。這樣一來，如果一個安全研究人員被授權從這些通信內容中獲取犯罪證據，那麼在他查閱這些表格時，就會有信標出現，以至於犯罪分子就會察覺到有人在監聽他們。

這看起來並不理想。

預防措施

那麼是誰的錯導致了這一切呢？

這不是CSV格式的措施。格式本身不能更清楚的分辨出自動執行任何「看起來像公式」的內容是不是有害的。因此，問題就出在流行的電子表格程序做了錯誤的事情。當然，Google表格必須保持與Excel的功能一致，Excel必須支持已經存在的數百萬個複雜的電子表格。但是，要讓這些程序不這麼做，是一件很難的事情，那麼既然改變不了程序，那就改變人類吧。

我已經將這個漏洞報告給了Google，作為他們的表格產品中的一個漏洞。他們審核通過了，但聲稱已經意識到了這種威脅。雖然我確信他們明白這是一個漏洞，但我得到了一個明確的態度：他們並沒有真正考慮到在實踐中可能會被濫用的情況。至少在CSV導入即將生成外部請求時，Google表格應至少給用戶發出警告。

但是把這個錯誤推到應用程序開發人員上也是不切實際的。畢竟，沒有理由讓開發人員在商業軟體里花費很大的精力來避免出現這種安全問題。即使他們按照RFC文檔的規範來做，一樣無法避免。

要如何防止這種漏洞的發生呢？

儘管StackOverflow和其他一些網站提供了很多建議，但我發現了一種很可靠的方法：

在所有帶有=、-、+或者@運算符的單元格里，在前面加上tab空格字元，如果有引號的話，那麼要保證所有字元都在引號裡面。

看起來有些奇怪，但是很實用，並且tab空格在表格里是不可見的。

不幸的是，事情還沒結束。Tab空格雖然看不到，但它仍然是存在的。使用字元串長度檢查=LEN(D4)就可以確認。因此，這只是一個勉強可以接受的解決方案。此外，插入tab字元將導致數據不一致。csv格式本身就是用於應用程序之間的數據交換。這就意味著一個單元格的數據將會從一個表格里導入到其他的表格里，那麼額外增加的tab字元也就跟著導入進去了。

所以，當你導出數據到CSV 文件時你必須要清楚的知道這些數據將要被用到什麼場景中。

· 如果數據只是在電子表格軟體中使用，那麼在出現運算符的時候，在運算符前面加tab就可以。尤其是在你不希望你輸入的「-2+3」被莫名其妙的顯示成1的時候。

· 如果數據要在別的應用程序里交換數據，那就不要加tab了。

· 如果你不知道這些數據會用在什麼地方，或者是這些數據先在電子表格軟體里使用，然後又需要導入到其他軟體中使用，那你還是放棄吧。（當然還可以這樣做：繼續用Excel但是記得將電腦的網路斷開，並且按照安全提示來操作。）

這是一個破壞性比較大並且沒有完美的解決方案的漏洞，這需要被更多的人知道。

本文翻譯自：http://georgemauer.net/2017/10/07/csv-injection.html ，如若轉載，請註明原文地址： http://www.4hou.com/technology/8321.html 更多內容請關注「嘶吼專業版」——Pro4hou