Yamatosec-2014/05/31

大和セキュリティ勉強会 @potetisensei

じこしょうかい

じこしょうかい ● 小池悠生 – @potetisensei – 私立灘高等学校 1年 – パソコン研究部部長 – EpsilonDeltaのバイナリ担当 ● 主にpwn ● CTF歴: 1年9ヶ月ほど

じこしょうかい ● 戦績 – CSAW 2013 Quals 33位 – Facebook CTF Finals 6位 – 30c3 Quals 16位 – PHDays Quals 28位 – SECCON 2013 Finals 2位 – CODEGATE 2014 Quals 39位 – DEFCON 2014 Quals 31位

はなすこと

はなすこと ● CTFのバイナリ入門？

はなすこと ● CTFのバイナリ入門？ – 自分で(ある程度)やってくれ

はなすこと ● CTFのバイナリ入門？ – 自分で(ある程度)やってくれ – microcorruption, ksnctf etc...

はなすこと ● CTFのバイナリ入門？ – 自分で(ある程度)やってくれ – microcorruption, ksnctf etc... – バイナリ書籍も最近は多い

バイナリしょせき

バイナリしょせき ● x86アセンブラ入門 – 読めないと話にならないので...

バイナリしょせき ● リバースエンジニアリングバイブル – 解析特化 – 体系的に解析の基本がまとまってる – CTFのReversing問題も

バイナリしょせき ● Hacking: 美しき策謀 – めずらしいExploitation寄りの本 ● C言語の基礎からShellcodeまで – ネットワーク、暗号理論も少し – 書式指定子攻撃を扱う数少ない本

バイナリしょせき ● たのしいバイナリの歩き方 – 基本を抑えた上でかなり幅広い ● 解析 ● Exploit ● 実装 ● ツールの利用 – 近状に則した新しい話題が多い

バイナリしょせき ● 他にも – ハッカープログラミング大全 – Art Of Reversingシリーズ – ももいろテクノロジー(サイト) ● http://inaz2.hatenablog.com/

で、何するの？

(再掲)

バイナリの走り方(pwn)

バイナリの走り方(全力疾走)

バイナリの走り方(全力疾走) ● 基本は掴んだ、簡単な物は解けるという人向け

バイナリの走り方(全力疾走) ● 基本は掴んだ、簡単な物は解けるという人向け – 少し難しい問題を解くには？

バイナリの走り方(全力疾走) ● 基本は掴んだ、簡単な物は解けるという人向け – 少し難しい問題を解くには？ ● CTFは過去問をやり込むしか無い

バイナリの走り方(全力疾走) ● 基本は掴んだ、簡単な物は解けるという人向け – 少し難しい問題を解くには？ ● CTFは過去問をやり込むしか無い – 泥臭いですが、それしかない ● (Writeup見てるだけじゃダメ)

バイナリの走り方(全力疾走) ● 基本は掴んだ、簡単な物は解けるという人向け – 少し難しい問題を解くには？ ● CTFは過去問をやり込むしか無い – 泥臭いですが、それしかない ● (Writeup見てるだけじゃダメ) – いくつかの良問、難問を紹介したいと思います

バイナリの走り方(全力疾走) ● ただし – microcorruptionやってる間も勝手に話します – 解きたい人、聞きたい人ご自由に – 休憩目的なので、小話を幾つかする感じです – 質問があればすぐに止めて頂いて構いません

一旦中断？(microcorruptionタイム)

CSAW 2013 Exp300 fil_chal

http://bit.ly/1hpuvpG ● CSAW CTF – 比較的簡単なので入門にオススメ – 基本ジャンル + Recon, Trivia, Misc – 今年も9月にあるので皆さん出ましょう

http://bit.ly/1hpuvpG ● Exp300 fil_chal – オーソドックスな問題 – バッファーオーバーフローの基本 – あらゆる問題はこの形に落とし込めば勝ち

http://bit.ly/1hpuvpG ● 環境(重要)

http://bit.ly/1hpuvpG ● 環境(重要) – Full RELRO ● GOT Overwriteなどの攻撃は不可 – No canary found ● stack overflowのmitigationがない – NX disabled ● NX bitによるデータ実行防止がない ● shellcodeを利用することが出来る – ASLR disabled(これは実行環境依存) ● stackやheap, libcはアドレスが固定

http://bit.ly/1hpuvpG ● 基本挙動

http://bit.ly/1hpuvpG ● 基本挙動 – とりあえず動かしてみる癖を付ける(demo) ● malwareには注意...

http://bit.ly/1hpuvpG ● 基本挙動 – とりあえず動かしてみる癖を付ける(demo) ● malwareには注意... – 初めにユーザー名とパスワードを求められる ● 特に難読化はないのでstringsで対応 – csaw2013:S1mplePWD – ログインに成功すると日記を付けられる ● ここが怪しそう...?

http://bit.ly/1hpuvpG ● 静的解析

http://bit.ly/1hpuvpG ● 静的解析 – “ある程度手で確かめた上で”静的解析に移る ● 「動かした時に起こった挙動」を確認しつつ ● 怪しいと思った所を見てみる

http://bit.ly/1hpuvpG ● 静的解析 – “ある程度手で確かめた上で”静的解析に移る ● 「動かした時に起こった挙動」を確認しつつ ● 怪しいと思った所を見てみる – ここら辺は勘、あるいは経験 ● 全てに静的解析行うのは次の手段(だと思ってる) ● (demo)

http://bit.ly/1hpuvpG ● 怪しい箇所? – バッファーオーバーフローがないか調べたい – 初めに文字数を入力した上で文字列を入力するっぽい – そもそも入力サイズの上限は? ● 0x400で適正っぽいなあ – このチェックを回避できないか考える ● 整数値オーバーフローはない?

0x08048F09 ~ 0x08048F36 mov eax, [ebp+arg_4] mov [ebp+var_4AC], ax movsx eax, [ebp+var_4AC] mov [ebp+n], eax mov eax, [ebp+n] add eax, 1 cmp eax, 400h jbe short loc_8048F5B http://bit.ly/1hpuvpG

0x08048F09 ~ 0x08048F36 mov eax, [ebp+arg_4] ; string size mov [ebp+var_4AC], ax ; short movsx eax, [ebp+var_4AC] ; cast to int mov [ebp+n], eax mov eax, [ebp+n] add eax, 1 ; eax = size + 1 cmp eax, 400h ; cast to uint jbe short loc_8048F5B http://bit.ly/1hpuvpG

short size; if ((unsined int)(size+1) <= 0x400) { ・・・ http://bit.ly/1hpuvpG

http://bit.ly/1hpuvpG ● size = -1の時?

http://bit.ly/1hpuvpG ● size = -1の時? – 「(-1 + 1) <= 0x400」 ⇔ 「0 <= 0x400」は成立

http://bit.ly/1hpuvpG ● size = -1の時? – 「(-1 + 1) <= 0x400」 ⇔ 「0 <= 0x400」は成立 – 入力サイズには-1(0xffffffff)が用いられる ● 明らかな整数値オーバーフロー ● これでバッファーオーバーフローは利用できる

http://bit.ly/1hpuvpG ● 利用する脆弱性が決まったら – exploit構築フェーズ – 本質ではないここに時間がかかってはいけない ● 慣れれば5分程度でexploitは書けるようになります

http://bit.ly/1hpuvpG ● 唯一考えなければならない事

http://bit.ly/1hpuvpG ● 唯一考えなければならない事 – 今回exploitに必要なアドレスは何か?

http://bit.ly/1hpuvpG ● 唯一考えなければならない事 – 今回exploitに必要なアドレスは何か? ● stack(shellcodeさえ配置できれば良い)

http://bit.ly/1hpuvpG ● 唯一考えなければならない事 – 今回exploitに必要なアドレスは何か? ● stack(shellcodeさえ配置できれば良い) – それに対して利用できるアドレスは?

http://bit.ly/1hpuvpG ● 唯一考えなければならない事 – 今回exploitに必要なアドレスは何か? ● stack(shellcodeさえ配置できれば良い) – それに対して利用できるアドレスは? ● ASLRはdisbled

http://bit.ly/1hpuvpG ● 唯一考えなければならない事 – 今回exploitに必要なアドレスは何か? ● stack(shellcodeさえ配置できれば良い) – それに対して利用できるアドレスは? ● ASLRはdisbled – ただし実行環境依存であるstackのアドレスはわからない – stackのアドレスはleak出来るか？

http://bit.ly/1hpuvpG ● Address leak – 出力系関数によってメモリ領域のアドレスを知ること

http://bit.ly/1hpuvpG ● Address leak – 出力系関数によってメモリ領域のアドレスを知ること – 大きく分けて2タイプ ● 出力するアドレスを決め打ち – 有効なアドレスであれば返ってくる ● 既知のアドレスの中身を見る – 知りたいアドレスが中にあることが前提

http://bit.ly/1hpuvpG ● 出力するアドレスを決め打ち – 有効なアドレスであれば返ってくる今回はこちらが妥当

http://bit.ly/1hpuvpG ● 根拠

http://bit.ly/1hpuvpG ● 根拠 – 出力関数がsendであること ● アドレスさえ当ててしまえば無限長読み出せる

http://bit.ly/1hpuvpG ● 根拠 – 出力関数がsendであること ● アドレスさえ当ててしまえば無限長読み出せる – ASLRは無効である = アドレスは固定 ● 一度でも当てれば良い

http://bit.ly/1hpuvpG ● 根拠 – 出力関数がsendであること ● アドレスさえ当ててしまえば無限長読み出せる – ASLRは無効である = アドレスは固定 ● 一度でも当てれば良い – ASLRなしのスタックの大体の位置 ● 0xbfff0000 ~ 0xbfffffff ● 0xffff0000 ~ 0xffffffff ● 16 * 2回の探索で行けそう

http://bit.ly/1hpuvpG ● これらを踏まえて書いたexploit fil_chal.py

http://bit.ly/1hpuvpG ● これらを踏まえて書いたexploit fil_chal.py – search_fd ● バッファーオーバーフローによりfdを上書きしてしまう ● 大体のfdの値を求める必要がある

http://bit.ly/1hpuvpG ● これらを踏まえて書いたexploit fil_chal.py – search_fd ● バッファーオーバーフローによりfdを上書きしてしまう ● 大体のfdの値を求める必要がある – search_stack ● 前述の通り、stack領域がどこにあるか探す

http://bit.ly/1hpuvpG ● これらを踏まえて書いたexploit fil_chal.py – search_fd ● バッファーオーバーフローによりfdを上書きしてしまう ● 大体のfdの値を求める必要がある – search_stack ● 前述の通り、stack領域がどこにあるか探す – search_shellcode ● 実際にshellcodeを格納できるアドレスがどこか探す

http://bit.ly/1hpuvpG ● これらを踏まえて書いたexploit fil_chal.py – search_fd ● バッファーオーバーフローによりfdを上書きしてしまう ● 大体のfdの値を求める必要がある – search_stack ● 前述の通り、stack領域がどこにあるか探す – search_shellcode ● 実際にshellcodeを格納できるアドレスがどこか探す – gain_shell ● 127.0.0.1 4444にconnectbackさせるshellcodeを起動

http://bit.ly/1hpuvpG ● 実行してみる... – (demo)

http://bit.ly/1hpuvpG ● 実行してみる... – (demo) – 遅くない...?

http://bit.ly/1hpuvpG ● 実行してみる... – (demo) – 遅くない...? – Flag: signness_oh_what_a_world_we_live_in! – とりあえずFLAGが手に入ったので良しとしよう

http://bit.ly/1hpuvpG ● 余談

http://bit.ly/1hpuvpG ● 余談 – 総当りは美しくない ● 上手く行ったが時間がかかる ● ASLRが有効ならば通用しない

http://bit.ly/1hpuvpG ● 余談 – 総当りは美しくない ● 上手く行ったが時間がかかる ● ASLRが有効ならば通用しない – ASLR有効な場合ではどうすればよかったのか

http://bit.ly/1hpuvpG ● 余談 – 総当りは美しくない ● 上手く行ったが時間がかかる ● ASLRが有効ならば通用しない – ASLR有効な場合ではどうすればよかったのか ● わざわざstackに置かなくても、より良い場所がある ● Stager ROPという概念 ● ここで説明することはないので課題とします

Hacklu 2012 Bin300 braincpy

http://bit.ly/1hpuvpG ● Hacklu CTF – バイナリ寄りなCTF – かなり質の良い問題しか出ない

http://bit.ly/1hpuvpG ● Bin300 Braincpy – 典型ROP問題 – Stack PivotとROPの基本が集約された良問 – ssh接続 + setgidされたバイナリ

http://bit.ly/1hpuvpG ● 環境(重要) – Partial RELRO ● GOT Overwrite可能 – No canary found ● Stack Canaryは存在しない – NX enabled ● NX bitによるDEPが有効 ● return2libc, あるいはROPで攻める

http://bit.ly/1hpuvpG ● 基本挙動 – とりあえず動かしてみる癖を付ける(demo) ● malwareには注意... – よく分からん

http://bit.ly/1hpuvpG ● 基本挙動 – とりあえず動かしてみる癖を付ける(demo) ● malwareには注意... – よく分からん ● argc != 2ならNO! ● argc == 2 && strlen(argv[1]) <= nならNOMNOMNOM! ● strlen(argv[1]) > nならNO! ● みたいな感じ...?

http://bit.ly/1hpuvpG ● 怪しい箇所? – envpを全てNULLで上書きしている ● envpは使って欲しくない問題みたい？ – seteuid, setegidが呼び出されている ● exploit中で権限を設定し直す必要がある – argv[1]<=strlen(0x60)の時、argv[1]がstrcpyされる – 明らかにバッファーオーバーフローしている ● ただしオーバーフローするサイズが小さすぎる(demo)

http://bit.ly/1hpuvpG ● 8byteしかオーバーフロー出来ないっぽい？ – 書き換えられるのはebp, return addressのみ – ROPは(そのままでは)構築出来ない....

http://bit.ly/1hpuvpG ● 通常のROP

http://bit.ly/1hpuvpG local variables2 stack saved ebp return address ● 通常のROP local variables1 arguments1

http://bit.ly/1hpuvpG local variables2 stack saved ebp return address local variables1 overwritten ● 通常のROP BufferOverflow local variables1 arguments1

http://bit.ly/1hpuvpG local variables2 stack saved ebp return address func1 args[n] local variables1 junk ● 通常のROP BufferOverflow functon1 addr n pop gadget local variables1 arguments1 functon2 addr

http://bit.ly/1hpuvpG ● 通常のROP function1の呼び出し function1の引数分popを行うgadgetへのreturn function2の呼び出し・・・

http://bit.ly/1hpuvpG ● 今回の場合 local variables2 stack saved ebp return address local variables1 arguments1

http://bit.ly/1hpuvpG ● 今回の場合 local variables2 stack saved ebp return address local variables1 overwritten local variables1 arguments1 local variables2 arguments1 BufferOverflow

http://bit.ly/1hpuvpG ● 思考

http://bit.ly/1hpuvpG ● 思考 – ROPを行うには“下に”十分な書き込みが必要

http://bit.ly/1hpuvpG ● 思考 – ROPを行うには“下に”十分な書き込みが必要 – すなわち、espの指すアドレスの下に入力を与えたい

http://bit.ly/1hpuvpG ● 思考 – ROPを行うには“下に”十分な書き込みが必要 – すなわち、espの指すアドレスの下に入力を与えたい – 2通りの方法

http://bit.ly/1hpuvpG ● 思考 – ROPを行うには“下に”十分な書き込みが必要 – すなわち、espの指すアドレスの下に入力を与えたい – 2通りの方法 ● 入力系関数で更に読み込む ● espそのものの値をいじってしまう

http://bit.ly/1hpuvpG ● espそのものの値をいじってしまう今回はこちらが妥当

http://bit.ly/1hpuvpG ● 根拠 – そもそも引数をいじれないので入力関数は呼べない – 入力自体は96byteも与えている ● espをいじってどうにか利用できないか

http://bit.ly/1hpuvpG local variables1 overwritten local variables2 arguments1 esp returnする時点での位置

http://bit.ly/1hpuvpG local variables1 overwritten local variables2 arguments1 esp これをreturn後に上手くずらせれば...

http://bit.ly/1hpuvpG local variables1 local variables2 arguments1 esp ROPは実行可能になる！ functon1 addr ・・・

http://bit.ly/1hpuvpG ● espをいじる – このような手法をstack pivotという

http://bit.ly/1hpuvpG ● espをいじる – このような手法をstack pivotという – 一度のreturnだけでespをいじれるgadgetを探す ● gadgetの列挙にはrp++を使用(demo)

http://bit.ly/1hpuvpG ● 探したいgadget

http://bit.ly/1hpuvpG ● 探したいgadget – sub esp, n ● 良いのがなさそう...

http://bit.ly/1hpuvpG ● 探したいgadget – sub esp, n ● 良いのがなさそう... – add esp, n(負数)でもいいのでは？

http://bit.ly/1hpuvpG ● 探したいgadget – sub esp, n ● 良いのがなさそう... – add esp, n(負数)でもいいのでは？ ● add esp, dword [ebp+0x0A] ; ret – ebpをいじれるしちょうど良さそう – 後は -0x60 = 0xffffffa0を指すようなアドレスを探す

http://bit.ly/1hpuvpG ● IDAで0xffffffa0を指す固定アドレスを探す(demo) – sequence of bytesが便利

http://bit.ly/1hpuvpG ● IDAで0xffffffa0を指す固定アドレスを探す(demo) – sequence of bytesが便利 – 0x08086C1C

http://bit.ly/1hpuvpG ● Exploit: braincpy.py, braincpy2.py – braincpy.py ● 実際に/home/braincpy/braincpyを起動 ● freadを呼び出し、入力をbufferに読みこむ ● stackをbufferに変更(espをbufferに変更) – braincpy2.py ● freadで読み込む入力を与える ● setegidをsyscallで、fopen,fgets,putsをret2libcで呼ぶ ● freadへの入力なのでNULL文字が含まれても問題ない

http://bit.ly/1hpuvpG ● 実行してみる... – (demo) – 良さだ – Flag: ROP_GOLF_IS_A_NICE_GAME!

http://bit.ly/1hpuvpG ● 実行してみる... – (demo) – 良さだ – Flag: ROP_GOLF_IS_A_NICE_GAME! – freadによる読み込みは最高

SECUINSIDE 2013 Pwn750 Pwnme!!

http://bit.ly/1hpuvpG ● SECUINSIDE CTF – 韓国のCTF – CODEGATEと性質が似ていて、バイナリが重たい

http://bit.ly/1hpuvpG ● Pwn750 Pwnme – 難問中の難問 ● 感じだけでも掴んでもらえれば

http://bit.ly/1hpuvpG ● 環境(重要) – Partial RELRO ● GOT Overwrite可能 – No canary found ● Stack Canaryは存在しない – NX enabled ● NX bitによるDEPが有効 ● return2libc, あるいはROPで攻める – PIE enabled ● 全ての領域のアドレスがランダマイズされる

http://bit.ly/1hpuvpG ● 基本挙動 – とりあえず動かしてみる癖を付ける(demo) ● malwareには注意... – 名前を入力するだけっぽい ● server側で、clientが入力した名前を出力 ● バッファーオーバーフローはしてそう

http://bit.ly/1hpuvpG ● 怪しい箇所? – 明らかにバッファーオーバーフローしている ● braincpyと同様、ROPには足りてない... ● またespをズラしてやればいいだけっぽい？

http://bit.ly/1hpuvpG ● 探したいgadget(demo)

http://bit.ly/1hpuvpG ● 探したいgadget(demo) – sub esp, n ● !!!そもそも存在しなかった!!!

http://bit.ly/1hpuvpG ● 探したいgadget(demo) – sub esp, n ● !!!そもそも存在しなかった!!! – add esp, n(負数)は？ ● 負数のnは存在してないですね... ● braincpyは静的リンクしていたからgadgetが豊富だった

http://bit.ly/1hpuvpG ● 思考

http://bit.ly/1hpuvpG ● 思考 – CTFは必ず解けるようになってる

http://bit.ly/1hpuvpG ● 思考 – CTFは必ず解けるようになってる ● 問題不備もたまにあるけど、絶対に解法があるはず

http://bit.ly/1hpuvpG ● 思考 – CTFは必ず解けるようになってる ● 問題不備もたまにあるけど、絶対に解法があるはず – stack pivotは必ず使う ● ROPの本質は自分の入力をstackに持ち込むこと ● pivot先のアドレスを考えることがこの問題の本質

http://bit.ly/1hpuvpG ● 勘、あるいは経験則

http://bit.ly/1hpuvpG ● 勘、あるいは経験則 – stack pivotは絶対に必要

http://bit.ly/1hpuvpG ● 勘、あるいは経験則 – stack pivotは絶対に必要 ● ただし、espを相対的にいじるgadgetはなかった ● leaveなどで絶対的なアドレスを代入するしかない

http://bit.ly/1hpuvpG ● 勘、あるいは経験則 – stack pivotは絶対に必要 ● ただし、espを相対的にいじるgadgetはなかった ● leaveなどで絶対的なアドレスを代入するしかない ● PIEがネック

http://bit.ly/1hpuvpG ● 勘、あるいは経験則 – stack pivotは絶対に必要 ● ただし、espを相対的にいじるgadgetはなかった ● leaveなどで絶対的なアドレスを代入するしかない ● PIEがネック – 高得点問題にはLinuxやELF、libcの中身を問うケースも ● 何か関係あるのだろうか...

http://bit.ly/1hpuvpG ● 勘、あるいは経験則 – stack pivotは絶対に必要 ● ただし、espを相対的にいじるgadgetはなかった ● leaveなどで絶対的なアドレスを代入するしかない ● PIEがネック – 高得点問題にはLinuxやELF、libcの中身を問うケースも ● 何か関係あるのだろうか... – (server側の不自然なprintfが怪しい)

http://bit.ly/1hpuvpG ● 勘、あるいは経験則 – stack pivotは絶対に必要 ● ただし、espを相対的にいじるgadgetはなかった ● leaveなどで絶対的なアドレスを代入するしかない ● PIEがネック – 高得点問題にはLinuxやELF、libcの中身を問うケースも ● 何か関係あるのだろうか... – (server側の不自然なprintfが怪しい) ● 作問を経験し、作問者の気持ちになるのは重要 ● このprintf要らなくない??? ● あまり違和感はないので、僕も気づかなかったかも

http://bit.ly/1hpuvpG ● 勘をまとめる

http://bit.ly/1hpuvpG ● 勘をまとめる – stack pivotは使う ● ただし絶対的なアドレス代入のみ

http://bit.ly/1hpuvpG ● 勘をまとめる – stack pivotは使う ● ただし絶対的なアドレス代入のみ ● stack領域はPIEなので総当りきつそう

http://bit.ly/1hpuvpG ● 勘をまとめる – stack pivotは使う ● ただし絶対的なアドレス代入のみ ● stack領域はPIEなので総当りきつそう ● 他に入力を保存してるバッファないかな...

http://bit.ly/1hpuvpG ● 勘をまとめる – stack pivotは使う ● ただし絶対的なアドレス代入のみ ● stack領域はPIEなので総当りきつそう ● 他に入力を保存してるバッファないかな... – printf怪しくないですか？ ● そういえば、出力バッファみたいなのなかった？？？

http://bit.ly/1hpuvpG ● 勘をまとめる – stack pivotは使う ● ただし絶対的なアドレス代入のみ ● stack領域はPIEなので総当りきつそう ● 他に入力を保存してるバッファないかな... – printf怪しくないですか？ ● そういえば、出力バッファみたいなのなかった？？？ ● どちらにせよPIEはどうなんですかね

http://bit.ly/1hpuvpG ● 実験

http://bit.ly/1hpuvpG ● 実験 – 領域によってASLRのエントロピーに差はあるか(demo)

http://bit.ly/1hpuvpG ● 実験 – 領域によってASLRのエントロピーに差はあるか(demo) ● stack領域・・・ 16^3 = 4096 ● glibc領域・・・ 16^2 = 256 ● 総当りとはいえ、かなり上手く行きそう

http://bit.ly/1hpuvpG ● 実験 – 領域によってASLRのエントロピーに差はあるか(demo) ● stack領域・・・ 16^3 = 4096 ● glibc領域・・・ 16^2 = 256 ● 総当りとはいえ、かなり上手く行きそう – printf内に入力を保存しているバッファは存在するか ● glibcは読みたくないのでgdbで調べる(demo)

http://bit.ly/1hpuvpG ● 実験 – 領域によってASLRのエントロピーに差はあるか(demo) ● stack領域・・・ 16^3 = 4096 ● glibc領域・・・ 16^2 = 256 ● 総当りとはいえ、かなり上手く行きそう – printf内に入力を保存しているバッファは存在するか ● glibcは読みたくないのでgdbで調べる(demo) ● 存在してるっぽい！

http://bit.ly/1hpuvpG ● これらを踏まえて exploit pwnme.py – daemon型なのでアドレスは変化しない ● 256回の総当りを行う – libcのアドレスのみでexploitを構成する事が重要 ● system関数、引数のbuffer、leave-ret gadget

http://bit.ly/1hpuvpG ● 実行してみる... – (demo) – Excellent – Flag: yeah you got a key! – 非常に良い問題だった

まとめ

まとめ ● Exploitation問題は、ここ数年の難化が激しい

まとめ ● Exploitation問題は、ここ数年の難化が激しい – ROPが前提条件となってきている

まとめ ● Exploitation問題は、ここ数年の難化が激しい – ROPが前提条件となってきている – もはや初心者が簡単に入って来れるものではない...

まとめ ● Exploitation問題は、ここ数年の難化が激しい – ROPが前提条件となってきている – もはや初心者が簡単に入って来れるものではない... ● 何を学んで欲しいか

まとめ ● Exploitation問題は、ここ数年の難化が激しい – ROPが前提条件となってきている – もはや初心者が簡単に入って来れるものではない... ● 何を学んで欲しいか – exploit構築の上で何が必要なのかを考える力

まとめ ● Exploitation問題は、ここ数年の難化が激しい – ROPが前提条件となってきている – もはや初心者が簡単に入って来れるものではない... ● 何を学んで欲しいか – exploit構築の上で何が必要なのかを考える力 ● どの脆弱性がある時どのようなexploitを組むのか

まとめ ● Exploitation問題は、ここ数年の難化が激しい – ROPが前提条件となってきている – もはや初心者が簡単に入って来れるものではない... ● 何を学んで欲しいか – exploit構築の上で何が必要なのかを考える力 ● どの脆弱性がある時どのようなexploitを組むのか ● どの領域のアドレスをどのようにして手に入れるのか

まとめ ● Exploitation問題は、ここ数年の難化が激しい – ROPが前提条件となってきている – もはや初心者が簡単に入って来れるものではない... ● 何を学んで欲しいか – exploit構築の上で何が必要なのかを考える力 ● どの脆弱性がある時どのようなexploitを組むのか ● どの領域のアドレスをどのようにして手に入れるのか ● address leakやstagerなどの手法の知識も重要

ご静聴ありがとうございました

Yamatosec-2014/05/31

by Yuki Koike

on May 31, 2014

Statistics

Views

Actions

1 Embed 4

Accessibility

Categories

Upload Details

Usage Rights

Report content

Yamatosec-2014/05/31 Presentation Transcript