2015年12月13日日曜日

ROPでDEPBypassしてwindows connectbackシェルコードを走らせてみる

CTFAdvent Calendar 12/6日のネタ。
なんか「ここ開いてるから書いてみ」みたいなTweetが回ってきたので埋めてみるデース。
CTFに直接は関係なくて申し訳無さはある。(本来はWriteupとか書くべき)

あ、どうもせぐふぉです

WindowsのバイナリをExploitするCTFってあんまり見たことないね。
でも、なんか将来的にIoTCoreとか使いそうではないかな・・・?(苦しい言い訳)

元ネタはももテクの
Windowsでconnect-backシェルコードを書いてみる

これです。
ここでは、Windows Sockets APIが攻撃対象アプリ内で呼ばれてること前提で話が進んでいるので
ws2_32.dllが仮想メモリ空間上にロードされています。
さらに、WSAStartupとか呼ばなくて良いのでソケットにcmd.exeをリダイレクトするだけです。


なので、発展課題版として、攻撃対象アプリ内でWindowsSocketsAPIが呼ばれていないし
DLLもロードされていない場合どうすればいいのか書いてみます。

元ネタ記事に書かれてることは理解している前提で話を進めます。

WindowsのPEB万能っぽいって感じた。(こなみかん)

脆弱性のあるプログラムのソース

Connect backシェルコード

下のコードはももいろテクノロジーにあるソースの追加分。
フル版はここ
本当に動くのかやってみる

LoadLibraryして、返却値を捨ててるように見えてるけど、捨ててます。
でも、PEBからロードされているDLLを走査して、関数を見つけてくれるので
ロードするだけでおっけー、ハンドルは要らないので捨てる ってわけです。

脆弱なファイル16進数ダンプアプリ(スタックオーバーランを起こすもの)
fileRead関数でオーバーフローが起こるのでそのリターンアドレスを
IATにあるVirtualProtectに向けてやる。(IATはLinuxで言うPLTみたいなところっぽい)
DEP有効・ASLR無効・SSP無効

ものすごく単純でなんのひねりもないExploitをしてみる
ROPでVirtualProtectを実行し「実行・書き込み・読み込み」の属性を全てを
globalValue変数(配列)のあるページに付与する

実際に正常時の動作と、Exploitを流した時の動作
また、デバッガを使い、制御を奪う際どのような挙動をするか、確認する。

動画(Youtube本家に行くと多分1080pで見られると思われます)






0 件のコメント:

コメントを投稿