• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
診断ツールを作ってみようと思う
 

診断ツールを作ってみようと思う

on

  • 1,008 views

 

Statistics

Views

Total Views
1,008
Views on SlideShare
994
Embed Views
14

Actions

Likes
4
Downloads
5
Comments
0

1 Embed 14

https://twitter.com 14

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    診断ツールを作ってみようと思う 診断ツールを作ってみようと思う Presentation Transcript

    • Webアプリ診断ツール を作ってみようと思う。
    • 自己紹介 Titter: abend@number3to4 Webアプリケーションのセキュリティをメインでやっています。 ときどき、お酒をInjectすることが趣味です。
    • Webアプリ診断って Webアプリケーションに内在する脆弱性を発見するための手法の 1つ。 http://www.slideshare.net/abend_cve_9999_0001/web- 22186183 参考(Webアプリって奥が深いんです) それ以外に ・ペネトレーション ・ソースコード診断 ・ファジング …etc
    • どうやる? 脆弱性の有無を判定 1)リクエストに攻撃パターンを付加。 2)レスポンスの内容から脆弱性の有無を判定。 診断対象 リクエスト レスポンス 攻撃パターン付加
    • 診断対象画面 ログイン画面 ユーザ名: パスワード: ログイ ン 様々な攻撃パターンを試行。 ・ 「"><script>alert()</alert> 」 ・「'」 ・「'|||'」 ・記号やNull文字(空文 字) ・5000バイトの文字列 1)各項目に数十~百パターン程度試行。 2)レスポンスの内容により、攻撃パターンを修正し試行。 どうやる?2
    • ヒトがやるんだったら 「'」を入力 Webアプリ 「java.sql.SQLException:[Micro soft][ODBC SQL Server Driver][SQL Server]オブジェク ト名 'xxxx' は無効です。」が出 力 リクエスト レスポンスブラックボックス この結果なら、次は「'+'」 にしよう。
    • ツールって1 ツールは、決まったルール(プログラム)に従い、決まった内容 をリクエスト。 敷かれたレールの上でしか動けないのです。
    • ツールって2 レスポンスの評価する手法も3つが一般的だと思う。
    • ツールって3 ① grep リクエストした内容がレスポンスにどう出力されているか。 怪しそうな文字列を探し出す。
    • ツールって4 ② diff 複数のレスポンス結果にどんな差分が存在しているか。 似たような結果であったとしても、どんな差分が 出ているか差分内容を精査する必要あり。
    • ツールって5 ③ 挙動のチェック レスポンス時間など挙動にどんな差分が存在しているか。 本来のキモいほどの激しい挙動が特定リクエストで遅くなる など動きに差分がないかを確認する。
    • ヒトとツールの違い1 ツールのダメなところ ・検出できない項目がある。 ・診断できないアプリケーションがある。 4)、8)、9)がツールでは 検出が不可または困難。 ○ CAPCHAなど視覚を必要とするもの ○ パラメータをクラインアント側で生成するもの など
    • ヒトとツールの違い2 ツールのいいところ ・ヒトと違い、バグがなければミスがない。 ・ヒトよりも早い。 サーバの通信状況にもよるが、 2秒あれば送信も可能。 こんなこともできるようになる
    • 適材適所 ヒトの仕事を減らすために。 ヒトのようにミスがないので定型的な箇所はツールに、それ以外 をヒトが行うようにする。
    • 想定される構成 こんな構成を想定しています。 診断対象 操作端末 開発対象 ①「操作端末」から診断 対象にアクセスして、 「開発対象」に「診断 対象」の情報を蓄積。 ③「開発対象」に蓄積 された情報から「診断 対象」へ診断。 「診断対象」の情報 ②「診断対象」 の情報を蓄積。
    • どんなツールにするか1 ・GUIで操作できるようにしたい。 ・お手軽に結果が得られるようにしたい。 ・Javaクライアントアプリにしたい。 ・DBを使わなくてもイケるようにしたい。 どんなツールにするか考えてみた。
    • どんなツールにするか2 ・診断対象取り込み機能 ・診断機能 ・結果分析機能 ・レポート機能 ・スペシャル機能 機能は、こんな感じ。
    • なので、作り始めた(と思う) 一番最初にやり始めたのは、多分2年前。途中まで作っていた ことを最近思い出して、また再開させた。 ふと作り始めた診断ツールを命名するときに、尾崎豊のShellyを 聞いていたので、「Shelly」に命名。
    • Shelly 機能 実装状況 診断対象取り込み機能 × 診断機能 △ 結果分析機能 △ レポート機能 × スペシャル機能 × いまの現状は、というと ほとんどできていない。
    • 診断対象取り込み機能1 「操作端末」のProxyとして動作させて、アクセスした「診断対象」 の情報(リクエストとレスポンス)を保存させる。 ローカルProxyとして動作し、Proxyした結果から「診断対象」の リクエストやレスポンスを自動的に抽出できるようにしたい。
    • 診断対象取り込み機能2 実装するときに以下を注意する必要がある(と思ってます)。 ・HTTPSの取り扱いに関して 診断対象操作端末 Shelly 暗号化された通信暗号化された通信 「診断対象」の証明書Shellyの証明書 Shellyの証明書は自己証明書で「操作端末」と通信をする必要がある。
    • 診断機能1 保存されたリクエスト情報をもとに、「診断対象」に攻撃パターン を付加したリクエストを送信する。 リクエスト情報 ・URL ・パラメータ …etc 攻撃パターン アドオン
    • 診断機能2 HTTPS時のProxyに関して HTTPリクエストを送る前にCONNECTメソッドを送信し、Socket 通信できるように準備が必要となる。
    • 診断機能3 オレオレ証明書を用いたサイトへのアクセス オレオレ証明書などの不正な証明書を使用しているサイトへの アクセスは、NoSuchAlgorithmExceptionが発生してしまうため initSSLContextをオーバライドさせて、オレオレ証明書のサイト でもアクセスできるようにした方がいい。
    • 結果分析機能1 リクエストした内容に応じて、レスポンス結果を分析する機能。 分析に必要なことは前述のとおり。 grep diff 挙動のチェック 実装済み 実装済み 未実装
    • 結果分析機能2 grepに関して XSSだけでも攻撃パターンは複数のパターンになるが、すべて 同じ文字列をgrepすればいいというわけではない。 入力例 "><script>alert(48264)</script> 特定のリクエストで出力された結果であることを確認する ために、入力値にランダムな数値をセットして、それを 検出するようにする。 検出例 alert(48264)
    • 結果分析機能3 alert(xxxx)という文字列をgrepし、アウトする場合 過剰検知(FalsePositive)が多数検出される可能性が高い。 お問合せフォームなどフリーフォーマット(記号も入力を許可) の場合に、脆弱性がなくても検出してしまう可能性が高い。
    • 結果分析機能4 SQLインジェクションの場合 SQL文の断片が評価されたことを検知できる仕組みが必要 だけど、それって結構むずい。
    • 結果分析機能5 たとえば、認証が通った場合にレスポンスの「$flg」が1にセット され、それ以外は0にセットされるようなアプリケーションでは ~~省略~~ <script> var flg = $flg; if(flg == 1){ location.href='http://xxx/ok' }else{ location.href='http://xxx/ng' } </script> ~~省略~~ POST /login HTTP/1.0 Id=1&pass=secret リクエスト レスポンス
    • 結果分析機能6 それだと、変化の割合(全体に対してどのくらい変化があったか) のみの評価では、検知漏れ(False Negative)につながる。 「' or 'a’ = 'a」、「' or 'a’ = 'b」の真偽値の違いと レスポンスの差分から脆弱性の有無を判定するブラインドSQL インジェクションの場合、差分が1行しかない可能性がある。 検知漏れをなくすためには、変化の割合ではなく、変化の有無を 確認する必要があるが、時間の経過とともに、レスポンスが変化 するアプリケーションは多数存在するため、過剰検知(False Positive)が増える。
    • 結果分析機能7 変更のあった割合と変更のあった内容をサマリ化し、ヒトが 内容を確認することで検知漏れを少なくするようにした。 ツールにすべてを任せるのは難しいので まだまだ、改善の余地がある。。。
    • レポート機能 脆弱性を見つけた後は直す必要があるので、開発者が直しやすい ように、どんな問題がどこにあったかをまとめる。 ・検出箇所 ・検出した脆弱性 ・検出した際のリクエストおよびレスポンスログ
    • スペシャル機能 診断をしているときの気晴らし機能は、絶対に必要!! 例: 「↑↑↓↓→← →←AB」打つと、スレッド化されてリクエスト が2倍出力される。 本当に2倍もリクエスト出している と小ばかにするための機能。 性格のゆがんだ方にオススメ。 この機能は、どんどん追加していく所存です。
    • それ以外にも1 シグネチャに関して データベースを使わないことを前提にしているので 1つのシグネチャを1つのファイルとして管理する。
    • それ以外にも2 ログの取り方に関して すべてのリクエストとレスポンスは、自動的に蓄積される ようにする。 それとは別に、個別に脆弱性を検出した際のログを出力させる。 理由は、膨れたログから検索するのがめんどいから。
    • さいごに いつ完成するか不明だが、完成したら公開しようと思ってます。