Recommended
Recommended
More Related Content
Featured
Featured (20)
live-ctf-11.pdf
- 1. Live CTF 11
- 2. Reversing
- 3. power_obfus_royalty Concept • Powershellの難読化といえばこれ • Invoke-Expression • base64 -enc • string obfuscation • live ctf 10, TSG CTFに引き続き3問目のPowershell Rev • 流石に王道も出さなくてはという Difficulty • easy
- 4. Invoke-Expression (iex) • Invoke-Obfuscationというツールもあるくらい、このコマン ドレットを使った難読化は有名 • Powershellを使う攻撃やマルウェアで使われることが多い(要出典) • 文字列を受け取り、それをコードとして実行
- 5. iexによる難読化 長所 • 実行するコードのそれぞれの要素に対する難読化など考える 必要がなく、単にstringに対する難読化をするだけで全体の操 作を隠すことができる。 • ifやelseのstatementの難読化が容易にできる • iexの中でiexを使うといった入れ子の構造での難読化ができる (1行なので、行単位のデバッグができない) • & operatorを使えばiex自身もstringに対する難読化を適用でき る • 実装が簡単
- 6. iexによる難読化の解析方法 • iexというコマンドレットに相当する部分を探し出し、それを 取り除いたものをpowershell上で実行すると、呼び出したが っているstring本体がわかる。 • stringに対する難読化は、実行してそれを出力するだけで破れられて しまう。 • 入れ子になっていっても、段階的にiexを外して行けば、大元の攻撃 者が難読化したいと思っていたプログラムの中身を露わにすること ができる。
- 7. base64 -enc • powershellの実行の際に-encオプションからbase64でエンコ ードされたstringを渡すと、それをデコードした結果をコマン ドとして実行する • これもマルウェアで本当によく使われる手法 • ワンライナーで実行するコードを書けてpowershell.exeに渡せる • 永続化キーに登録しやすい • ディスクにファイルとして保存しない • 検知されにくい • デコードしない限り、中の操作を解析することはできない
- 8. base64 -encの注意点 • オプションとして渡せる長さには限界があるので、あまりに 長いコードを渡すことはできない • 実装上の注意としては、例えばPython3を例に出すとコード base64エンコードする際は、encodingに’utf-16-le’を指定す る必要がある
- 9. base64 -encのデコード • Cyberchefを使うと一発 • base64関連のライブラリを使ってデコード
- 10. stringの難読化 • 前回のLive CTF 10においてstring_relatedという問題で色々な 手法を扱ったのでそれを是非解いて見てください • 今回は下の3つの手法を組み合わせて使った • stringを一文字ずつに分割して足し算する • [char]101などでコード上ではasciiの数字として扱う • 大文字と小文字の区別が必要ない部分ではランダムに大文字と小文 字を使う • 例えば[ChAr]101など
- 11. stringの難読化の解析 • ここがstringだという目星をつけて切り分けて実行する • CTFだと悪意のあるコードではないという前提でやりがち • 難読化の種類を特定して、一つずつプログラムでパースして 元に戻す
- 12. Solution 方法1 • iexによって入れ子の構造で難読化されている部分を適宜戻す • base64 -encもプログラムで直すか、実行してしまって結果の 文字列を手にいれる 方法2 • 難読化を元に戻すようなプログラムを何回も適用して元に戻 す。 方法3 • 末尾にsleepなり入力を受け付ける関数を追加してそこで実行 を止め、メモリダンプをとってFLAGをゲットする
- 13. Pwn
- 15. mini_cyberchefの全体像 Recipeという構 造体を使う converterというメンバは Recipeを引数に取る 関数ポインタ base64関係の libraryをinclude
- 22. mini_cyberchefの全体像 bufの内容を 8byteずらして 上書きして コピー 開けた先頭8byteに “Result: ”という 文字列を格納 ● strcat的な 操作をし ている
- 24. Solution • ROT13を指定して、0xf8 + 2サイズを送り込む • 2の部分がpointerのPartial Overwriteに相当 • 確率1/16で正しいWin関数のアドレスへと書き換えることができる • 下3nibbleは固定なので、2byte (4nibble)の書き換えの1nibbleが正しい値とな っている時には書き換え成功 • ROT13後の値がcopyされることに注意 • 2回目のrecipe->converterの実行時にwin関数が実行され、 Flagを手にいれることができる
- 26. mini_cyberchef_production Concept • mini_cyberchefとの変更点 • win関数がない • ポインタのpartial overwriteのprimitiveからどのようにし てShellを取るか。 Difficulty • med-hard
- 27. 現在のprimitiveを整理 • 関数ポインタをOverwriteできるprimitive • Partial Overwriteも可能 • ROT13の中でadd_resultを呼ぶ時にそのprimitiveが発火する • text領域のアドレスをreadできるprimitive • 1回目のROT13の結果を得る時、末尾のrecipe->converterをリークで きる。(win関数のアドレスを書き込む時にはこの結果はまだわから ない) • main関数のコードのどこかにRIPを飛ばすことで、上記の primitiveを複数回使える可能性がある。
- 28. Exploitに必要なprimitive • libcのアドレスリークのprimitive • win関数がないので、system関数のアドレスが必要 • recipe->converterを呼ぶ時の第一引数はrecipeが渡されていて、 recipeのアドレスはrecipe->bufのアドレスと同一であるので、ユー ザーの制御の下にある
- 29. Format String Attack (FSB) • printfは第一引数に書式指定文字列を取る • “%s”など • アセンブリをみると、rodata領域の該当する文字列リテラルへのポ インタをrdiに格納してprintfのpltエントリをcallするコードとしてコ ンパイルされている。(ユーザーは普通は制御できない) • この書式指定文字列を、ユーザーが入力から制御できれば、 好きな%書式指定子を使って様々な攻撃が可能 • “%10$p”などで、stack上に存在するアドレス、(text, libc, stack)の アドレスをリーク可能(実装によってはheapも) • “%n”を使って書き込みが可能(AAW)
- 30. FSBの危険性 • FSBは強力なprimitiveだが、なかなか現実では紛れ込みにくい と思われる • linterでチェックが入る • コンパイル時Warningが出る • 実際CTFでも最近見ない • 露骨でない形でFSBを出すのは難しそう？
- 32. movapsによるSegmentation Faultの回避 • 1回目のPartial Overwriteで前のスライドのようにFSBを発火 させようとすると、Segmentation Faultで落ちる • printf関数の中にmovaps命令が存在するせい • mainの中でcallでmainの中に飛ぶと、saved RIPによってスタックが 8byteズレてSSE命令で落ちる • system関数でもこれがおきる • よって、1回余分なcallを挟んでstackをもう8byteずらせない かを考える
- 33. Partial Overwrite to FSBの条件 • 1回目のPartial OverwriteからのRIPの飛ばす先は、main関数 の中の1回目のROT13の入力を受け付けるところに飛ばす ROT13の ポインタを restore
- 34. Partial Overwrite to FSBの条件 • そのまま実行し、2回目のOverwriteからのrecipe->converter を呼ぶまでのコードの中にSSE命令(主にmovaps)がなければ、 再びRIPを制御してmainのどこかに実行を移せる • 2回callをしているので、8+8で16byteスタックがずれてmovapsで落 ちない • FSBが発火できる!!
- 35. FSBによるlibcリーク • FSBというprimitiveの強い点は、任意のアドレスに書き込みが できることもそうだが、text領域、libc、stackのアドレス全 てのleakができるprimitiveでもあること • 今回はwrite primitiveは別で存在しているのであまり恩恵はないが、 read primitiveはtext領域のアドレスのみだったので、このFSBのおか げでより強力かつexploitに十分なread primitiveを得ることができた • 例えば”%11$p”を指定するとlibcリークができる。
- 36. System(“/bin/sh”)を実行 • SSE命令のコードが実行できるstackの状態であるので、次の3 回目のポインタのOverwriteでSystem関数のアドレスをわたす。 • recipe->bufに“/bin/sh¥x00”が入っている状態でrecipe- >converterを呼べばSystem(“/bin/sh”)を起動できる。 • 今回は簡単のためにrecipe構造体のbufメンバを1番上にして(つまり recipeのアドレスと一致させて)、out_bufとの間にcntとnumを設置 したが、cntとnumが先頭にきている自然なコードであっても、FSB を複数回呼んでなんでもできるので、Exploit可能である。
- 37. 補足 • text領域のアドレスの関数ポインタ書き換えでFSBに繋げるに は、1回目のポインタ書き換えで、ポインタ書き換えができる 部分へと飛び、2回目のポインタ書き換えでtext領域のprintf のpltエントリを呼ぶ直前に飛ばす • 途中でSSE命令がないことと、rdi指すバッファに任意の文字列を格 納できる条件においては成功する。 • read primitiveがない時の候補の一つとして、考慮する価値はあると 思う。 • text領域にsystem関数を呼ぶ部分があれば、間にFSBを挟まなくても 良い。 • でも、system関数を使うコードよりもprintfを使うコードの方が圧倒的に多い ので、こっちの方が可能性はあるんじゃないかと思っている。 • 関数ポインタの書き換え自体は、UAFとかで十分存在し得る。