ぎーくになりたい

情弱エンジニアがゆるーくぎーくになろうとする技術ブログ

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関数みたいな、イカニモな関数がないかだけ探る
checksecpwntoolsのセキュリティ表層解析機能で実行ファイルのメモリプロテクト情報を確認できる

    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で拡張しておくのが良い

CTFの準備の準備

使えるものを更新していく方針

Peda (GDBの拡張)

git clone https://github.com/longld/peda.git ~/peda
echo "source ~/peda/peda.py" >> ~/.gdbinit

Pwntools(pythonのPWNツールキット)

sudo pip install pwntools

Ropper

sudo pip install ropper

32bit Compiler for 64bit Linux

sudo apt install lib32z1
sudo apt install libc6-dev-i386

証明書にも色々あってな

あー、なんでこんなにも記事がないんだ

最近、よくデジタル証明書を取り扱うけど、兎にも角にも日本語の情報が少ないのです。
ようやく見つけても、方法に差分があったりして、どれが正しいのか分からない。
というわけで、出来るだけ自分で調べた情報をここで纏めてみようと思います。
今回は証明書のニュアンスについて、説明します。技術的な話は次回以降かなぁ……

証明書 =「水戸黄門の印籠」

証明書と言っても、サーバー証明書・クライアント証明書・組み込み機器の証明書……等々たくさんあります。
これらは「用途」が異なるだけで、本質的には「誰かに正当性を証明してもらった鍵」であること。
公開鍵があるんだけど、「〜〜さんの鍵であること」「〜〜用の鍵であること」「〜〜まで有効な鍵であること」等の情報とともに、権威(普通はCAとか)に保証してもらうわけです。 まあ、「この紋所が目に入らぬか!!」ってやつですね。
最近?だとハガレンの銀時計も近いけど。

署名と公開鍵のイメージはここがわかりやすい

persol-tech-s.co.jp

証明書の種類(PKI階層別)

上記の通り、「誰かに正当性を証明してもらう」必要があるわけでございます。
そのためには、「北海道の田中さんに保証してもらいました」では困るわけで、「日本の総理大臣に保証してもらいました」みたいなある程度「誰もが信頼してくれる人」である必要があります。
別に、総理大臣が信用できるかってのは主観によるので、誰でもいいけどさ。

証明書の場合「この信頼の根っこは誰なのさ?」というと下記のヒエラルキーがあります。

  1. ブラウザなど
  2. ルートCA証明書  :「こいつは絶対に疑わないぜ」っていう証明書のこと
  3. 中間CA証明書  : ルートに保証(署名)されている証明書。諸々の事情でこいつらが必要
  4. 末端証明書    : 末端。役割によって、サーバー証明書だったりクライアント証明書だったり、はたまた組み込み機器のデバイス証明書だったりする

中間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通信を)使いたい人用の証明書
    • 安全〇 
    • 安心▲ (極端な話だが、「詐欺師が詐欺用ECサイトG00gle.comを作ったよ」でも取得できる可能性あり。こういう酷いサイトに対して、取締の方法をGoogleは検討中)
      • 常時HTTPS対策という点で期待されている Let's Encrypt様はこちら
  • 自己署名証明書:俗に言うオレオレ証明書
    • 安全△ :根本的に設定しないと使えないので、不特定多数への公開用ではない。社内等のクローズな環境でなら、設定すれば問題ない?
    • 安心×  :「俺のWEBサイトは安全だ。俺が保証する」

お金を使用するサイトでなければ、「DV証明書(Let's Encrypt)で十分
間違っても、自己署名証明書だけは信用してはならない。