水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2009年度 IPA情報セキュリティセミナー 技術コース専門編

2009年度 IPA情報セキュリティセミナー 技術コース専門編

2009年6月26日(金曜日)

2009年度 IPA情報セキュリティセミナー 技術コース専門編

公開: 2009年6月30日0時20分頃

午後は専門編。ケーススタディ中心に脱線交えつつだったりもしたので、本当に雑多なメモになっております。

※というかですね、ロビーの状態が酷すぎでトイレに行くにも息を止めなければならず、後半は体力が保たなかったですよ。パーティションで区切られただけのスペースを「喫煙所」と称されても……。皆さんあんな状態に耐えられるのが凄いですね。

ケーススタディ: DNSを攻撃された事例
  • たいていのインシデントは苦情で始まる (昔は。最近はインシデントが分かりにくい)
  • ウェブに(たまに)つながりにくい、メール遅延、メールが来ない→ネットワーク障害を疑う
  • メール受信は遅延するものの、送信は問題ない。ウェブサイトも、内側から見る分には問題ない。サーバ負荷も問題ない→原因特定できず。ISPに問い合わせるも障害報告もなし
  • 「御社のウェブサイトを見たらウィルス対策ソフトが反応」「これまでと違うページが見えることがある」という報告→管理グループに連絡、緊急対応開始
  • SQLインジェクションを疑うも、何もなし。XSS? 監視サービスにも、ログにも何もないが……。ベースライニング→ベースラインを作って、逸脱したアクセスを洗い出す
  • 念のため社外から(携帯電話回線経由で)アクセスしてみると、微妙に違うサイト、ウィルス対策ソフトが反応。リロードすると何度かに一度出てくる (再現率が100%ではない)
  • →パケットキャプチャして調査。家からのアクセスでパケットをキャプチャして調査→知らないIPアドレスに誘導されている、nslookupで調査
  • 何年か前に使っていて、今は使っていないはずのネームサーバが存在。昔委託していた業者のDNSサーバが登録されっぱなし。期限切れ後に第三者がそのドメインを取得→数分の一の確率で偽サーバに誘導されてしまう
  • 悪意あるメールサーバは、メールを受信してから本物サーバにフォワードしていた。だから、遅くなるがメールは届いていた (発覚が遅れる原因)
  • 被害……公式サイトにアクセスした人にウィルス感染、外部からのメールも読まれてしまっていた(情報漏洩)
  • やめる、いなくなるときの処理は漏れがち(たとえば退職処理)。いつその情報を消せば良いのか?

※不正なDNSサーバによる誘導の説明。メールの場合、MXを解決→そのAを解決、となるので実際には説明より1ステップ多くなる。Webの例で良いのでは。また、メール送信のパケットキャプチャはクライアントでやっても駄目なはず (ほとんどの場合、クライアントはMXを引いたりせず、決められたサーバに投げるだけなので)。

  • ウィルス新種70万/月
  • iframeの脆弱性で、見ただけでファイル実行→Windows Updateが行われていれば脅威はない。最近はQT,PDF,Flashなどのプラグイン、マルチメディア系の脆弱性が利用されることが多い(最近のブラウザはきちんと対策されているし、自動アップデートもある)
  • 最初はダウンローダーだけが入る。検出困難 (ネットワークインストールを行うsetup.exeと区別がつかない)
  • 昔のボットはIRCを使っていたが、最近のボットはHTTP/HTTPSでふつうにGETアクセスしたりするので正規の通信と区別が難しい
  • LAME delegationの原因……設定変更忘れ、スペルミス (example→exmaple)
  • これらはNG: DNSとして応答しない、権威あるはずの人が Non-Autohoritative Answer、サーバごとに異なる応答
  • ドメイン情報ハイジャックで不正なDNSサーバを立てられると……メールアドレスがあれば、正式なSSL証明書を取得できる可能性がある
  • トラフィックの100%を誘導できるわけではない (複数あるネームサーバの一つだけが乗っ取られているので)
  • チェック: 現状の動作ではなく仕様を見る
  • TTLが短すぎると危ない

    ※とはいえカミンスキー氏によって「長くても危ない」となったような気もするところ

Webアプリケーションの脆弱性
SQLインジェクション
  • 「直接攻撃」に分類。攻撃者が直接サーバを攻撃。
  • Webサーバのログに怪しい形跡が残る……が、ステータスコードを見ても攻撃が成功したかどうかは分からない。POSTリクエストの場合、普通はログに残らない。Webサーバのログではなく、DBのログを見ると実際に攻撃が成功したかどうか分かる
  • DB側で用意された機能でエスケープすると良い……が、データベースの開発者も攻撃の動向をすべて知っているわけではない。特に、多バイト文字を考慮していないことがある
  • 究極の対策 (?) として「サイト閉鎖」という選択もある。実際、届け出られたサイトが閉鎖されることも。閉鎖するなら教えてほしい
XSS
  • 「間接攻撃」。悪い人が直接対象のサーバにアクセスするわけではない

※デモに関しては園田さんの所のコメント (d.hatena.ne.jp)参照。あと、多くのフィルタは"javascript"ではなく"script"を処理するので、javaとscriptの間に文字を混入しても突破できない可能性が高い気がしたりとか。

インシデントレスポンス
  • RFC2350
  • 誰かが試しにIDSを動かしたら検出。誰が試しに稼働したんだ?(w
  • 検出されたのはold fashionな攻撃、Nimda系
  • 一昔前→ワームがどーん、大量トラフィックで派手に始まる
  • 今のインシデント→静かに始まる。ビジネスが目的なので、長く息の続く踏み台にして稼ぎたい
  • アンチウイルスのプロセスが停止されている。未知のウィルスに感染。
  • 他にも怪しい挙動をしているマシンがあるかも知れない。全体への影響を知るため、止めたりせずに調査
  • 調査ツールをインストールしたりすると証拠隠滅活動を行う可能性もあるため、外から観察
  • 何かをダウンロードしている。Wiresharkの便利機能でストリームをフォロー、分割データを一つに合体。"MZKERNEL32.DLL"などの文字列を発見。実行ファイルのダウンロードを行っている事が判明
  • ダウンロードがウィルスの活動とは限らないが、ユーザーの証言と照らし合わせて、全く心当たりのないダウンロードと判断できればインシデントと判断できる。ダウンロードされたファイルに対してマルウェア解析を行うかどうかは判断による
  • とりあえず virustotal に投げてみる? pedump で PE ヘッダを確認? CCCに投げてみる?
  • ダークマターIPアドレス(未使用IPアドレス、本来、そこに対する通信は発生しないはず)にハニーポットを設置という方法も

関連する話題: セキュリティ / IPA

最近の日記

関わった本など