0x00 前言

本次滲透測試為授權滲透測試，為此筆者還與開發人員交了個好朋友。

要求：不許危害到任何用戶，盜取任何人的密碼信息，以及不允許危害到服務器權限。

PS：該次滲透測試為師生關系。

好像是因為企業入駐學校的原因，班里所有人被安排上了一門培訓課程，給學生們在線學習Python。

0x01 草率的信息收集

因為班長只發了一個域名，提供給我們進行學習Python，所以此時筆者首先使用layer進行爬取域名。

在這里筆者發現幾個敏感的點如下：

A域名泄露源碼問題

可以看到，這種站點模擬了github，筆者在想，會不會這些站點里的源代碼搭建到目前收集到的某些域名？

結果發現這些都是go語言編寫的，這是在勸退筆者。如圖：

不過這里話同時記錄了用戶名。

**le5，為此筆者進行收集了一些用戶名。

觀察到登錄接口，沒有驗證碼。那么進行爆破操作。

如圖：

觀察HTTP請求包，發現有csrf驗證token，但是token在cookie中，如圖：

這樣就不需要特地的去準備python腳本了。爆破之：

這里因為web有記錄時間戳的功能，影響了BurpSuite包返回長度，那么爆破就需要特意的編寫python腳本，并且爆破的效率看起來也一般般，先把這條路放到最后。

B域名一處未授權訪問

在B站點中，筆者訪問一下第一眼顯示管理界面，然后突然就發生了跳轉，查看源代碼：

存在跳轉操作，那么禁用js：

但是點來點去發現都是白頁，先不去研究。

C域名一個未知上傳點

但是是無任何東西的，上傳點也是壞的，上傳記錄也是空，目測開發到一半程序員跑路了。

0x02 一處邏輯漏洞

轉了一圈回來倒是收集了點信息，因為目標的站點我是可以使用我自己的學號的。那么登錄之，發現存在綁定手機號的功能，如圖：

看到這里大家懂得都懂，4位數驗證碼爆破可成功。如圖：

遺憾的是開發人員并沒有添加一項“找回密碼”這樣的功能。那么這個綁定手機號也沒什么意義了。

0x03 令人激動的在線代碼運行

因為是在線學習python，那么筆者在web中翻到了一處“在線代碼運行”，如圖：

發現進行了過濾，那么使用__import__函數進行繞過。

如圖：

運行之，在此whoami問候，如圖：

驚喜的發現是root權限，查看一下根目錄是否存在docker文件，如圖：

看來是白白高興一場。不過服務器是docker自有docker的利用方式。

先看一下os的過濾是什么樣的：

居然使用ast抽象語法樹來進行過濾，這里筆者簡單說一下有如下種繞過方式：

通過查看nodejs源代碼。發現該功能模塊是通過“前端->websocket->nodejs->執行python”，是這種流程，那么觀察驗證點，如圖：

這里有一處token驗證，這里的token是該站點的HTTP頭的token，如圖：

故與賬號憑證綁定的死死的，不存在漏洞。下面還有一處原型鏈污染，但是無法自定義設置key，也是挺可惜的，如圖：

Package.json文件中也沒發現什么庫導致的漏洞，這里nodejs的研究告一段落。

但是目前該站點為多用戶一服務。也就是說，A用戶指向websocket服務器，B用戶同樣也指向websocket服務器。所以這臺docker服務器可以幫助我們觸發XSS。

例如：

將這里插入xss代碼，然后重啟node服務即可，實戰中筆者并沒有這么做，因為觸發了用戶隱私。

0x04 OSS導致的全域名XSS淪陷

在前期的一些簡單的信息收集中，所發現的B域名的一處未授權訪問中，發現一處在線代碼編輯器。如圖：

那么抓包：

可以看到，key隨著我們所上傳的文件發送到目標存儲站點，在OSS中，文件雖然不會被編程語言所解析，但是卻不會驗證任何后綴，上傳也不會被重名。也就是一個簡單的存儲文件功能而已。

那么在這里，筆者發現該域名下隨便一個站點都有引入OSS的站點的js腳本，如圖：

但是目前的文件上傳的OSS服務器并不是指明了js的OSS服務器，那么如果這兩臺的服務器的密鑰設置都是一樣的話，那么就會造成A站點與B站點的key是一樣的，具體攻擊思路如下:

如果密鑰一樣的情況下，我們借用OSS A的key來上傳惡意js腳本，替換掉OSS B原有的js腳本，這里就可以產生一個XSS漏洞。那么筆者進行嘗試。

如圖：

居然真的存在密鑰復用問題，那么回到主站點：

成功污染站點，通過觀察，該域名下的站點的js指向全部都在該OSS服務上，那么全站淪陷。

0x05 漏洞提交

至此整個漏洞過程完美結束，OSS服務器密碼復用問題可以看到是多么的可怕。交作業，收工！