這一題是出現在 PlaidCTF 的題目,屬於 Web 類。
出題者的註解,可以在 CTFTime 上找到。
這是三條系列題中的第一題,主要是打 XSS 和 CSRF。比較奇特的是,這題牽涉到一顆 Google Home。
透過看出題者留下的註解,我們可以知道:
Clipshare 網站,大概有這幾種功能。
這題我當時有打,Clipshare 服務本身不太有漏洞,且這題主要的目標並不是它。
根據題目註解,初步的攻擊方向大概會跟 XSS 有關。如果先試試的話,會發現網站有設定了 CSP:
關於 CSP,可以參考這份文件。CSP 主要限制了可以出現在該頁面上的物件來源,故可以讓 XSS 的實作更難。
根據 MDN 的文件,這個 CSP 並不限制 <img src=""></img>
的載入。故我們若送出 <img>
的 XSS,我們可以透過 User-Agent
辨識目標的瀏覽器。(在此題中,目標使用 Chrome)
我們接著可以看看音訊上傳的部分。頁面上寫著:
You can upload .wav/wave, .mp3, .ogg, .webm
但就算頁面上和後端有檢查副檔名和檔案,但不一定會檢查 Magic Number 和檔案的內容。例如有的上傳站可能會用 imagemagick
的 identify
來檢查圖檔是不是正常的,但我們這裏先忽略這種可能性。
由於目標是使用 Chrome,假設我們在 Chrome 中設下同樣的 CSP,並測試,會發現:
<script src="test.wav"></script>
<script src="test.mp3"></script>
<script src="test.ogg"></script>
<script src="test.webm"></script>
<script src="test.wave"></script> <---- 這個可以成功引入
這是因為 <script>
會檢查引入的 MIME-type,但 .wave
是沒有對應的 MIME-type 的,故檢查可以通過。
這裏依據實作不同,可能會有不同的做法。印象中,這裏的上傳(但看的其中一篇 [1] 沒有遇到這個問題) 會檢查上傳檔案的 Magic Number,所以我們必須僞造一個檔案,帶有正常的 Magic Number,但是又可以被 <script>
執行。
從 List of file signatures - Wikipedia 這邊,我們可以看到 wav
的 Magic Number 是 RIFF....WAVE
。如果我們寫了 RIFF/*WAVE*/='test';console.log('1')
的話,這個檔案就帶有正常的 Magic Number,但又是一份正常的 Javascript。
由於登入的 Cookie PHPSESSID
不是HttpOnly
,故我們可以用一份會用 document.cookie()
的檔案取回 PHPSESSID
。
當我們取得對方的 PHPSESSID
後,就可以看對方到底上傳了什麼(該平臺預設的分享都不是公開的)。從兩個分享檔案中,我們可以得知:
speculate
下一步就勢必要達成三件事:
就我看的兩種攻擊模式,都是透過以下這些路徑來達成這些事情:
navigator.mediaDevices.getUserMedia
來請求音訊權限CreateAudioElement
錄回復,並用 fetch
丟回來完成之後,Flag 就到手啦。後來主辦單位有貼出他們的場景,真的是這樣: