利用開源工具分析新型PowerPoint惡意文檔

5月20日晚上，我花了幾天時間研究雅虎的Messenger應用程序。但是我依然無法搞清楚背後的工作管理。所以我走出了外面走走，決定找到一個新的目標。我發現了另我我感興趣的事情是，那就是名為Sean的某個研究人員在參與雅虎的Bug獎勵計劃時，測試範圍超出了雅虎的允許範圍而被列入了黑名單。

回來房子之後，我跟好友Thomas討論之後，我決定研究安全研究人員(Sean)被列入黑名單之前測試的應用。

步驟1：偵察

從Sean給出報告來看，這些公司的域名包括如下

* .mediagroupone.de * .snacktv.de * .vertical-network.de * .vertical-n.de * .fabalista.com

雖然有不少的域名出現在Sean的報告中,但是他的報告大部分的時間都是針對於SnackTV的內容管理系統，我和Thomas決定重複Sean使用的方法，針對SnackTV的www站點為目標，因為Thomas已經在這個站點上花了一些時間，同時也找到了一些XSS盲打漏洞。並且這個站點跟其他站點有所不同，原因有兩點：（1）這是個德國公司，（2）這是為視頻製作者準備的開發者網站。

SnackTV的搜索頁面。很明顯，這是一個視頻網路，但註冊的用戶必須人工審核，因此我們無法直接訪問該網站上的上傳頁面。

步驟2：掃描

我和Thomas在查看新範圍時,都會後台運行一些工具，我使用了「subbrute」以及「dirsearch」這個工具。

後台運行這些工具一段時間後，我們收到了大量的輸出，但是並沒有多大幫助。大多數信息是非常標準的響應信息，如「.htpasswd」被阻止在標準的HTTP 403錯誤之後，「admin」頁面重定向到登錄頁面等等。然而，最終，dirsearch發現了一個脆弱點。

有問題的文件名是「getImg.php」隱藏在「imged」目錄（http://snacktv.de/imged/getImg.php）後面。經過一些環顧之後，我們意識到這個文件可以通過Google dork「sites：snacktv.de filetype：php」公開訪問。

這一步非常重要，因為易受攻擊的文件需要GET參數才能返回內容。如果我們要知道GET參數，可能需要幾周的時間來猜測，很少有人去猜GET的參數，因為它們通常還需要另外的參數配合才可以。

所需GET參數的示例

1、訪問「http://example.com/supersecretdevblog.php」：返回HTTP 500內部伺服器錯誤

2、訪問「http://example.com/supersecretdevblog.php?page=index&post=1」：返回HTTP 200響應

我們到目前為止知道信息如下

1、文件「getImg.php」採用多個HTTP GET參數，如果通過「imgurl」參數提供了圖像的鏈接，將自動下載修改的圖像文件。

2、根據Google搜索中出現的參數,我們知道裁剪函數使用ImageMagick。

步驟3：訪問及獲取許可權

從獲取的信息我們得知這個網站使用了"ImageMagick",第一時間就想到了「ImageTragick」(CVE-2016-3714)，並決定測試幾個POC。

我和Thomas花了幾個小時的時間，構造包含漏洞載荷的圖片文件。漏洞利用的原理是把svg圖片文件（即包含載荷的圖片文件），交給ImageMagick」命令行工具處理，ImageMagick存在漏洞，導致處理過程中存在任意命令執行漏洞。然而我們的poc沒有一個成功，我們懷疑他們已經打了ImageMagick補丁。

我們發往伺服器的paylod如下所示。圖片地址使用的是我們的私人域名，將載荷上傳到伺服器後，我們通過「imageurl」參數獲取伺服器上的載荷圖片。我們的目標是使伺服器執行一條任意命令。請注意其中「xlink:href」所指向的圖片地址。

除了伺服器在處理文件所屬的URL地址上有點奇怪之外，一切都很正常。我們向伺服器發送了一些隨機的文本文件，伺服器返回的數據總是與上一次調用相同。我們仔細閱讀了「ImageMagick」相關資料，結合漏洞披露細節，我們發現伺服器似乎不存在這個漏洞，也有可能伺服器沒有使用ImageMagick。我們暫緩攻擊這個文件，決定看一下網站是否存在其他漏洞。

貌似在凌晨3:30時，我們發現了存儲型跨站腳本漏洞、HTTP 401響應注入漏洞以及常見的管理不當問題，但這些都不是關鍵問題。當你在參與bug獎勵計劃、這些漏洞獎金通常會大幅縮水，因為這些問題的影響非常低。在某些人眼裡，拿到打折的獎金還是可以接受，但對其他人而言這只是在浪費時間。收購的子公司為目標的唯一好處在於，許多人在這些目標上會放鬆安全警惕性。

重新回到URL地址後，我變得有些煩躁，開始懷疑伺服器在處理圖片文件的具體實現。如果雅虎沒有將圖片作為一個整體來處理，而是採用將URL注入到XML中的「image xlink:href」的處理方式呢，這種方式與漏洞PoC中的情況類似。那麼我需要嘗試哪種載荷才能驗證我的猜想？

我在瀏覽器的地址中附加了一個額外的雙引號，然後看到了一些有趣的輸出信息，如下所示：

請求：

GET /imged/getImg.php?imageurl=" HTTP/1.1Host: snacktv.deConnection: closeUpgrade-Insecure-Requests: 1

伺服器響應：

By default, the image format is determined by its magic number.To specify a particular image format, precede the filename with an image format name and a colon (i.e. ps:image)...... or specify the image type as the filename suffix (i.e. image.ps). Specify file as - for standard input or output.

我之所以使用這個請求，是因為在之前的PoC所使用的XML文件中，我們是在URL實體上使用了雙引號（可能單引號也可以）。如果我們向伺服器發送一個雙引號，就可以迫使伺服器跳出這個邏輯處理區域，然後獲取伺服器上寫入命令位置的寫許可權（參考前文引用的PoC）。

看來伺服器的確使用了ImageMagick！在某種程度上，我是否打破了伺服器的執行流程呢？這是否就是命令行的輸出？我應該接著發送更多請求。

請求：

GET /imged/getImg.php?imageurl=";ls HTTP/1.1Host: snacktv.deConnection: close

伺服器響應：

By default, the image format is determined by its magic number. To specify a particular image format, precede the filename with an image format name and a colon (i.e. ps:image)... ... or specify the image type as the filename suffix (i.e. image.ps). Specify file as - for standard input or output. [redacted] [redacted] index.php getImage.php [redacted] [redacted]

我發送上面列出的字元串的原因是逃避第一個命令範圍。在Linux環境中，您可以將分號附加到初始命令中，並開始編寫第二個命令。這對攻擊者很有用，因為它允許在初始預定義內容之外執行。

在這一點上我很興奮。我在滲透測試生涯中首次實現命令注入。在此之前，我愚蠢的認為發送引號和分號來試圖實現命令注入這是一種不現實的想法，但這一次完全改變了我的觀點。不久之後，我通過HackerOne針對雅虎的bug賞金計劃報告了這一點。我在24小時內收到了一個回復，並將該bug修復了六個。

結論

你以為會有四步？不，不。我們是白帽的黑客...記得嗎？

獎勵：$ 3,000

CVSS得分：9.9

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！