CTF バイナリ解析のお勉強メモ ①
CTFなどのバイナリ解析時に、ひとまずやってみることまとめ
インストール関連は下記にまとめる
alt256.hatenablog.com
1. fileの種類をざっくりと掴む
# file <filename> # string <filename> | grep "{"
file
で大枠のファイル拡張子が判明するので、最初に叩いて方針を立てる
実行ファイルの場合はビルド環境もある程度分かる
`x86-64` : Linux 64bit 実行ファイル `80386` : Linux 32bit 実行ファイル `ARM` : ARM 実行ファイル
string
でバイナリ内部の文字列が判明するので、ダメ元でCTFの接頭辞も確認しておく
2. binaryファイルの情報を集める(Tool使用)
# strace <filename> # ltrace <filename> # objdump -d -M intel <filename> # checksec <filename>
ltrace
はmemcmpなどで単純な値比較をしていると値を確認できる(初級問題はこれだけで解けることもある)
strace
はシステムコールの追跡を実施するので、プロセスIDなどの確認可能
objdump
は色々な用途があるが、一旦はread_flag
関数みたいな、イカニモな関数がないかだけ探る
checksec
はpwntools
のセキュリティ表層解析機能で実行ファイルのメモリプロテクト情報を確認できる
Arch: amd64-64-little RELRO: Partial RELRO Stack: No canary found NX: NX disabled PIE: No PIE (0x400000) RWX: Has RWX segments
3. 普通に動かしてみる
注:CTF以外の場合は、マルウェア感染対策は必須
方針:とにかくセグる方法を探すこと ① とりあえず、普通に実行 ② 長い文字列を入力 ③ %p を入力(フォーマットストリングバグ) ④ 異常値入力(正の整数なら、マイナスや超大きい数など)
4. gdbで動かしてみる
# file <filename> # objdump -d <filename> # gdb -q <filename> # gdb -q -p <PID>
上の2つはすでに叩いているが、GDB用に再度確認する。
1. file
で得られるno stripped
(デバックシンボルあり)になっているか?
2. objdump
で得られる関数や命令(Breakpoint用)
gdb
には、新たにプロセスを起動する場合と、起動中のプロセスにアタッチする場合があるので、適切な方を選ぶといい。
また、素のGDBだと使用感がイマイチなので、gdb-peda
で拡張しておくのが良い
証明書にも色々あってな
あー、なんでこんなにも記事がないんだ
最近、よくデジタル証明書を取り扱うけど、兎にも角にも日本語の情報が少ないのです。
ようやく見つけても、方法に差分があったりして、どれが正しいのか分からない。
というわけで、出来るだけ自分で調べた情報をここで纏めてみようと思います。
今回は証明書のニュアンスについて、説明します。技術的な話は次回以降かなぁ……
証明書 =「水戸黄門の印籠」
証明書と言っても、サーバー証明書・クライアント証明書・組み込み機器の証明書……等々たくさんあります。
これらは「用途」が異なるだけで、本質的には「誰かに正当性を証明してもらった鍵」であること。
公開鍵があるんだけど、「〜〜さんの鍵であること」「〜〜用の鍵であること」「〜〜まで有効な鍵であること」等の情報とともに、権威(普通はCAとか)に保証してもらうわけです。
まあ、「この紋所が目に入らぬか!!」ってやつですね。
最近?だとハガレンの銀時計も近いけど。
署名と公開鍵のイメージはここがわかりやすい
証明書の種類(PKI階層別)
上記の通り、「誰かに正当性を証明してもらう」必要があるわけでございます。
そのためには、「北海道の田中さんに保証してもらいました」では困るわけで、「日本の総理大臣に保証してもらいました」みたいなある程度「誰もが信頼してくれる人」である必要があります。
別に、総理大臣が信用できるかってのは主観によるので、誰でもいいけどさ。
証明書の場合「この信頼の根っこは誰なのさ?」というと下記のヒエラルキーがあります。
- ブラウザなど
- ルートCA証明書 :「こいつは絶対に疑わないぜ」っていう証明書のこと
- 中間CA証明書 : ルートに保証(署名)されている証明書。諸々の事情でこいつらが必要
- 末端証明書 : 末端。役割によって、サーバー証明書だったりクライアント証明書だったり、はたまた組み込み機器のデバイス証明書だったりする
中間CA証明書は諸般の事情によって1〜N枚になります。ごく稀に中間CA証明書がない構成もあるけど、それは稀。
昨今の事情ではありえないっぽいです。
ちなみに、0. ブラウザを置いているのは個人の主観です。
論理上はブラウザとルートCAに明確な力関係はないです。PKIに関わる団体「CA / Browser Forum」もCAとブラウザ双方の団体が参加しています。
ただし、ルートCAの資格(Web Trust For CA )を取得しても、ブラウザに組み込んで貰えるかどうかはブラウザ側が決めること
です。
CA側としてはブラウザに組み込んで貰わないと生きる道がないのも確かなので、生殺与奪の権利の権利はブラウザ側にある。
そんなわけで、現実的には「ブラウザ > CA」という力関係があるかと思っています。
証明書の種類(署名者別)
- EV 証明書 :ECサイトの意識高い系。銀行や証券会社とかが使用する信頼度の高い証明書
- OV 証明書との違い:発効前の実在性証明(会社の登記確認とか)がメチャクチャ厳密
- 安全〇 (別にアルゴリズムが強固なわけではないから◎にはならない)
- 安心〇 (ブラウザのURL部分が緑色になるので、一般利用者にも見分けがつく)
- OV 証明書 :普通の企業が使いたがる証明書。
- 安全〇
- 安心△ (見た目がDV_SSLと変わらないので安心なサイトかは分からない)
- DV 証明書:とにかく安く証明書を(=HTTPS通信を)使いたい人用の証明書
- 自己署名証明書:俗に言うオレオレ証明書
- 安全△ :根本的に設定しないと使えないので、不特定多数への公開用ではない。社内等のクローズな環境でなら、設定すれば問題ない?
- 安心× :「俺のWEBサイトは安全だ。俺が保証する」
お金を使用するサイトでなければ、「DV証明書(Let's Encrypt)で十分
間違っても、自己署名証明書だけは信用してはならない。