前言
本次滲透測驗為授權滲透測驗，
提示：不許危害到任何用戶，盜取任何人的密碼資訊，以及不允許危害到服務器權限，
點擊→【查看學習資料】←
草率的資訊收集
因為只發了一個域名，提供給我們進行學習Python，所以此時筆者首先使用layer進行爬取域名，
在這里筆者發現幾個敏感的點如下：
A域名泄露原始碼問題
可以看到，這種站點模擬了github，筆者在想，會不會這些站點里的源代碼搭建到目前收集到的某些域名？
結果發現這些都是go語言撰寫的，這是在勸退筆者，如圖：
不過這里話同時記錄了用戶名，
**le5，為此筆者進行收集了一些用戶名，
觀察到登錄介面，沒有驗證碼，那么進行爆破操作，
如圖：
觀察HTTP請求包，發現有csrf驗證token，但是token在cookie中，如圖：
這樣就不需要特地的去準備python腳本了，爆破之：
這里因為web有記錄時間戳的功能，影響了BurpSuite包回傳長度，那么爆破就需要特意的撰寫python腳本，并且爆破的效率看起來也一般般，先把這條路放到最后，【點擊查看資料】
B域名一處未授權訪問
在B站點中，筆者訪問一下第一眼顯示管理界面，然后突然就發生了跳轉，查看源代碼：
存在跳轉操作，那么禁用js：
但是點來點去發現都是白頁，先不去研究，
C域名一個未知上傳點
但是是無任何東西的，上傳點也是壞的，上傳記錄也是空，目測開發到一半程式員跑路了，
一處邏輯漏洞
轉了一圈回來倒是收集了點資訊，因為目標的站點我是可以使用我自己的學號的，那么登錄之，發現存在系結手機號的功能，如圖：
看到這里大家懂得都懂，4位數驗證碼爆破可成功，如圖：
遺憾的是開發人員并沒有添加一項“找回密碼”這樣的功能，那么這個系結手機號也沒什么意義了，
令人激動的在線代碼運行
因為是在線學習python，那么筆者在web中翻到了一處“在線代碼運行”，如圖：
發現進行了過濾，那么使用__import__函式進行繞過，
如圖：
運行之，在此whoami問候，如圖：
驚喜的發現是root權限，查看一下根目錄是否存在docker檔案，如圖：
看來是白白高興一場，不過服務器是docker自有docker的利用方式，【點擊查看資料】
先看一下os的過濾是什么樣的：
居然使用ast抽象語法樹來進行過濾，這里筆者簡單說一下有如下種繞過方式：
1.剛剛所說的__import__方法
2.使用eval方法來進行拼接字符
3.使用python的沙箱逃逸
4.使用未過濾的subprocess
5.使用 from os import system 來進行繞過等
通過查看nodejs源代碼，發現該功能模塊是通過“前端->websocket->nodejs->執行python”，是這種流程，那么觀察驗證點，如圖：
這里有一處token驗證，這里的token是該站點的HTTP頭的token，如圖：
故與賬號憑證系結的死死的，不存在漏洞，下面還有一處原型鏈污染，但是無法自定義設定key，也是挺可惜的，如圖：
Package.json檔案中也沒發現什么庫導致的漏洞，這里nodejs的研究告一段落，
但是目前該站點為多用戶一服務，也就是說，A用戶指向websocket服務器，B用戶同樣也指向websocket服務器，所以這臺docker服務器可以幫助我們觸發XSS，
例如：
將這里插入xss代碼，然后重啟node服務即可，實戰中筆者并沒有這么做，因為觸發了用戶隱私，
OSS導致的全域名XSS淪陷
在前期的一些簡單的資訊收集中，所發現的B域名的一處未授權訪問中，發現一處在線代碼編輯器，如圖：
那么抓包：
可以看到，key隨著我們所上傳的檔案發送到目標存盤站點，在OSS中，檔案雖然不會被編程語言所決議，但是卻不會驗證任何后綴，上傳也不會被重名，也就是一個簡單的存盤檔案功能而已，
那么在這里，筆者發現該域名下隨便一個站點都有引入OSS的站點的js腳本，如圖：
但是目前的檔案上傳的OSS服務器并不是指明了js的OSS服務器，那么如果這兩臺的服務器的密鑰設定都是一樣的話，那么就會造成A站點與B站點的key是一樣的，具體攻擊思路如下:
如果密鑰一樣的情況下，我們借用OSS A的key來上傳惡意js腳本，替換掉OSS B原有的js腳本，這里就可以產生一個XSS漏洞，那么筆者進行嘗試，
如圖：
居然真的存在密鑰復用問題，那么回到主站點：
成功污染站點，通過觀察，該域名下的站點的js指向全部都在該OSS服務上，那么全站淪陷，
漏洞提交
至此整個漏洞程序完美結束，OSS服務器密碼復用問題可以看到是多么的可怕，交作業，收工！
↓ ↓
【網路安全學習資料·攻略】
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/355241.html
標籤：其他