一次授權(quán)測(cè)試引起的全域名淪陷

0x00 前言

本次滲透測(cè)試為授權(quán)滲透測(cè)試，為此筆者還與開發(fā)人員交了個(gè)好朋友。

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

PS：該次滲透測(cè)試為師生關(guān)系。

好像是因?yàn)槠髽I(yè)入駐學(xué)校的原因，班里所有人被安排上了一門培訓(xùn)課程，給學(xué)生們?cè)诰€學(xué)習(xí)Python。

0x01 草率的信息收集

因?yàn)榘嚅L(zhǎng)只發(fā)了一個(gè)域名，提供給我們進(jìn)行學(xué)習(xí)Python，所以此時(shí)筆者首先使用layer進(jìn)行爬取域名。

在這里筆者發(fā)現(xiàn)幾個(gè)敏感的點(diǎn)如下：

A域名泄露源碼問題

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

結(jié)果發(fā)現(xiàn)這些都是go語言編寫的，這是在勸退筆者。如圖：

不過這里話同時(shí)記錄了用戶名。

**le5，為此筆者進(jìn)行收集了一些用戶名。

觀察到登錄接口，沒有驗(yàn)證碼。那么進(jìn)行爆破操作。

如圖：

觀察HTTP請(qǐng)求包，發(fā)現(xiàn)有csrf驗(yàn)證token，但是token在cookie中，如圖：

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

這里因?yàn)閣eb有記錄時(shí)間戳的功能，影響了BurpSuite包返回長(zhǎng)度，那么爆破就需要特意的編寫python腳本，并且爆破的效率看起來也一般般，先把這條路放到最后。

B域名一處未授權(quán)訪問

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

存在跳轉(zhuǎn)操作，那么禁用js：

但是點(diǎn)來點(diǎn)去發(fā)現(xiàn)都是白頁，先不去研究。

C域名一個(gè)未知上傳點(diǎn)

但是是無任何東西的，上傳點(diǎn)也是壞的，上傳記錄也是空，目測(cè)開發(fā)到一半程序員跑路了。

0x02 一處邏輯漏洞

轉(zhuǎn)了一圈回來倒是收集了點(diǎn)信息，因?yàn)槟繕?biāo)的站點(diǎn)我是可以使用我自己的學(xué)號(hào)的。那么登錄之，發(fā)現(xiàn)存在綁定手機(jī)號(hào)的功能，如圖：

看到這里大家懂得都懂，4位數(shù)驗(yàn)證碼爆破可成功。如圖：

遺憾的是開發(fā)人員并沒有添加一項(xiàng)“找回密碼”這樣的功能。那么這個(gè)綁定手機(jī)號(hào)也沒什么意義了。

0x03 令人激動(dòng)的在線代碼運(yùn)行

因?yàn)槭窃诰€學(xué)習(xí)python，那么筆者在web中翻到了一處“在線代碼運(yùn)行”，如圖：

發(fā)現(xiàn)進(jìn)行了過濾，那么使用__import__函數(shù)進(jìn)行繞過。

如圖：

運(yùn)行之，在此whoami問候，如圖：

驚喜的發(fā)現(xiàn)是root權(quán)限，查看一下根目錄是否存在docker文件，如圖：

看來是白白高興一場(chǎng)。不過服務(wù)器是docker自有docker的利用方式。

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

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

通過查看nodejs源代碼。發(fā)現(xiàn)該功能模塊是通過“前端->websocket->nodejs->執(zhí)行python”，是這種流程，那么觀察驗(yàn)證點(diǎn)，如圖：

這里有一處token驗(yàn)證，這里的token是該站點(diǎn)的HTTP頭的token，如圖：

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

Package.json文件中也沒發(fā)現(xiàn)什么庫導(dǎo)致的漏洞，這里nodejs的研究告一段落。

但是目前該站點(diǎn)為多用戶一服務(wù)。也就是說，A用戶指向websocket服務(wù)器，B用戶同樣也指向websocket服務(wù)器。所以這臺(tái)docker服務(wù)器可以幫助我們觸發(fā)XSS。

例如：

將這里插入xss代碼，然后重啟node服務(wù)即可，實(shí)戰(zhàn)中筆者并沒有這么做，因?yàn)橛|發(fā)了用戶隱私。

0x04 OSS導(dǎo)致的全域名XSS淪陷

在前期的一些簡(jiǎn)單的信息收集中，所發(fā)現(xiàn)的B域名的一處未授權(quán)訪問中，發(fā)現(xiàn)一處在線代碼編輯器。如圖：

那么抓包：

可以看到，key隨著我們所上傳的文件發(fā)送到目標(biāo)存儲(chǔ)站點(diǎn)，在OSS中，文件雖然不會(huì)被編程語言所解析，但是卻不會(huì)驗(yàn)證任何后綴，上傳也不會(huì)被重名。也就是一個(gè)簡(jiǎn)單的存儲(chǔ)文件功能而已。

那么在這里，筆者發(fā)現(xiàn)該域名下隨便一個(gè)站點(diǎn)都有引入OSS的站點(diǎn)的js腳本，如圖：

但是目前的文件上傳的OSS服務(wù)器并不是指明了js的OSS服務(wù)器，那么如果這兩臺(tái)的服務(wù)器的密鑰設(shè)置都是一樣的話，那么就會(huì)造成A站點(diǎn)與B站點(diǎn)的key是一樣的，具體攻擊思路如下:

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

如圖：

居然真的存在密鑰復(fù)用問題，那么回到主站點(diǎn)：

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

0x05 漏洞提交

至此整個(gè)漏洞過程完美結(jié)束，OSS服務(wù)器密碼復(fù)用問題可以看到是多么的可怕。交作業(yè)，收工！