0x00 前言

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

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

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

好像是因?yàn)槠髽I(yè)入駐學(xué)校的原因，班里所有人被安排上了一門(mén)培訓(xùn)課程，給學(xué)生們?cè)诰€(xiàn)學(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域名泄露源碼問(wèn)題

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

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

不過(guò)這里話(huà)同時(shí)記錄了用戶(hù)名。

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

觀察到登錄接口，沒(méi)有驗(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)度，那么爆破就需要特意的編寫(xiě)python腳本，并且爆破的效率看起來(lái)也一般般，先把這條路放到最后。

B域名一處未授權(quán)訪(fǎng)問(wèn)

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

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

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

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

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

0x02 一處邏輯漏洞

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

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

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

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

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

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

如圖：

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

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

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

先看一下os的過(guò)濾是什么樣的：

居然使用ast抽象語(yǔ)法樹(shù)來(lái)進(jìn)行過(guò)濾，這里筆者簡(jiǎn)單說(shuō)一下有如下種繞過(guò)方式：

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

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

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

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

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

例如：

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

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

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

那么抓包：

可以看到，key隨著我們所上傳的文件發(fā)送到目標(biāo)存儲(chǔ)站點(diǎn)，在OSS中，文件雖然不會(huì)被編程語(yǔ)言所解析，但是卻不會(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à)，那么就會(huì)造成A站點(diǎn)與B站點(diǎn)的key是一樣的，具體攻擊思路如下:

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

如圖：

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

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

0x05 漏洞提交

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