fr33f0r4llスマートフォン用の表示で見るfr33f0r4ll自分用雑記この広告は、90日以上更新していないブログに表示しています。参考にしたサイトhttps://teamrocketist.github.io/2018/11/04/Pwn-Seccon-2018-Profile/Writeupその1、丁寧な方https://github.com/sajjadium/ctf-writeups/tree/master/SECCON/2018/profileWriteupその2、概要しか書かれていないのでこれだけでは解けなかったhttp://shift-crops.hatenablog.com/entry/2018/11/05/042149作問者さまのサイト、ソースコードとExploitを参考にした問題profileというプログラムとlibcが降ってくる。セキュリティ機構は以下。(0x400000)標準的なセキュリティ機構は有効で変わったところはない。strippedx64らしい。解析Radare2で解析してみたらC++だった。復習目的だったのと、ちょっと探しただけじゃ脆弱性を見つけられなかったのですぐにWriteupを見た。Writeupその2によると、バッファオーバーフローがあるらしい。stringクラスの内部メモリ構造を理解する必要があり、文字列の内部ポインタを上書きすることで任意の読み出しができるそうだ。RCEでsystem(/bin/sh)を実行する。上の文章はほぼ直訳になってる。stringクラスWriteupその1を参考にした、要は長さが16未満の文字列をコンストラクタに渡したときはヒープに領域を確保せずスタックに積むようになるということらしい。自分じゃコードとか解析しきれなかった、パワーが足りない...Writeupその1から取ってきたPoCコード。}}実行すると16文字以降からはヒープに領域が確保され、それまではスタックに確保されていることが分かる。Profile::update_msgで使われているmalloc_usable_sizeはスタックのアドレスが引数として渡された場合は負数を返すようになっている。関数内で負数のチェックをしていないため、文字列長のチェックをすり抜けバッファオーバーフローさせられる。作問者さまのサイトから拾ってきたソースコードの該当する部分。ここで、sizeがunsignedなので巨大な正の数として扱われる}説明のためにコード中にコメントを書き加えた。ExploitstringとProfileクラスがスタック上でどうなっているのかよく分からなくて苦戦した。おおまかには次のようになっている、pwndbgのtelescopeほぼそのまま。size);でバッファオーバーフローさせることで、p.nameの文字列が格納されている場所へのポインタが書き換えられる。profileを選択することで、任意のアドレスの値を表示させられる。ASLRを考慮してか、WriteupのExploitでは末尾1バイト分を書き換えるようになっていた。末尾だけを0x00から0xffの範囲で書き換えて順番に表示することで、スタックの一定の範囲を全てダンプすることができる。上の例にならうと0x7fffffffd4XXの範囲の値を全て見ることができる。p自身も含まれている可能性が高い。以上のことから、0x00から0xffの範囲をダンプしてp.msgに入力した文字列を探し、その相対位置からcanaryを特定することが可能になる。次に、p.nameの指すアドレスをGOT領域のreadに設定して、readが実際に存在しているアドレスを特定する。実際に存在しているアドレスとlibc内のオフセットから、libcのベースアドレスを知ることができる。RCEを使い、canaryによる検知を回避して、ripを奪いシェルを起動すればいい。Writeupその1とか作問者さまのサイトにあったコードを参考にしつつ、Exploitを作成。exitしてmain関数からリターンするio.interactive()感想C++のバイナリはあまり慣れていないから新鮮だった。stringの構造については調べることすらろくにできなかったので、本番でもどうしようもなかった気がする。Writeupでは細かいテクニックを色々使って解いているので勉強になった。(1)はてなブログをはじめよう!hiziriAIさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。