セキュリティ勉強会に参加しました
会社のセキュリティ勉強会に参加しました。
初回はこれからの進め方と社内のセキュリティ部署のお仕事について話をうかがって今日は二回目でしたが、記事が続くか自信が無いので番号はつけません。
今日はBurpを使って、HTTPリクエストのパラメータを読み取る方法や、リクエストメソッドを書き換える方法や、 えせ証明書を発行して、ブラウザに読み込ませたりと言ったローカルプロキシのツールの使い方を確認したり、 徳丸本の輪読を行いました。
長くなったので前半分だけメモ。
内容
- Burpを使う
Burpを使う
徳丸本ではローカルプロキシソフトとしてFiddler(Windows用アプリ)を使うのですが、会社で支給されているパソコンはMacなので、 Fiddlerを使うのは結構頑張る必要があります。端的に言うとすぐ落ちるそうです。
http://shim0mura.hatenadiary.jp/entry/2014/02/05/012358
なので、かわりにBurpのフリー版(こちら)を教えていただいたのでそちらを利用して進めることにしました。
そして、参加者の中に初心者がいた(言うまでもなく自分です)ので、ツールの使い方からとなりました。
Burpのインストール
ダウンロードしてjarファイルを実行するだけ、お手軽ですね。 Professional EditionとFree Editionがありますが、徳丸本の演習はFree Editionで十分だそうです。
そもそもローカルプロキシとは
実は、ローカルプロキシがよく分かっていなかったので、下記を見ながらGoogle拡張噛ませて１つ余分な手順を踏んだりしてました。
(下記はいろんな環境に手軽に一気に対応したいとか、そういう意図で一段噛ませてある気がしますが、今回は皆基本Macなのでそういうのはいいんです)
http://securitymemo.blogspot.jp/2014/12/owasp-zap-4owasp-zap.html
こちらのサイトを参考にすると、ローカルプロキシの以前にプロキシとは、「クライアントとサーバの間に立ってデータのやり取りの仲介をするコンピュータ、もしくはソフトウェア」だそうです。
これを使う事で下記のようなメリットがあります。
各項目の細かいことは参考先を読むとして、ローカルプロキシは、自分のパソコンの中にインストールしたプロキシソフトの事を言い、 自分のパソコン(主にブラウザから送られる)とサーバの間の通信の様子を調べたり、いじったりするソフトウェアのことを言うようです。
brewで入っているものについて
brew でburpを入れると以下のものが入るようです。 https://github.com/Homebrew/homebrew/blob/master/Library/Formula/burp.rb
これの公式ページはこちら。 こちらはCUIクライアントみたいです...。
ブラウザのプロキシの設定をする
我々がインターネットにリクエストを送る時は主にブラウザからリクエストを送りますが、直接ブラウザからサーバにリクエストを送っているわけではなく、先程述べたプロキシを経由してリクエストをサーバに送ります。
この、プロキシにはとても大雑把に分けると公共の(Wifiやインターネット業者が提供している)プロキシと、ローカルプロキシがあるのですが、 ブラウザは通常、デフォルトではローカルプロキシを利用せず、公共のプロキシを利用します。
プロキシソフトでHTTP通信の内容を調べるには、プロキシソフトに登録しているプロキシを経由して通信を行う必要がありますので、 ブラウザにローカルプロキシを利用してもらうように設定する必要があります。
Burp Suiteには最初からlocalhost(127.0.0.1):8080がプロキシとして登録されています。
以下では、localhost(127.0.0.1):8080をブラウザに利用するように設定します。
Chromeの場合
右上のメニューの設定をクリックします。
ネットワークの項目の「プロキシ設定の変更...」ボタンを押してください。
ネットワークのメニューのプロキシの項を開いてください。 構成するプロトコルを選択で、今回はHTTPとHTTPSの通信をプロキシで扱いたいので、 「Webプロキシ(HTTP)」と「保護されたWebプロキシ(HTTPS)」にチェックを入れます。
そして、それぞれの「Webプロキシサーバ」にlocalhost(127.0.0.1):8080を入力します。
入力した後は、適用ボタンを押してください。また、勉強用等でプロキシを使い終わった後はこの設定は解除するのを忘れないようにしましょう。
HTTPSはこのままだとHTTPS証明書が無いので利用する事が出来ません。 信頼できないにも程がある気がしますが、とりあえず、Burp Suiteで証明書を発行します。
Burp Suiteのメニューの「Proxy Listeners」の項の下側、「CA certificate」というボタンを押してください。 Burp Suiteのプロキシが利用するHTTPS証明書の書き出しを行います。
Google Chromeにとりあえず発行する証明書はCertificate in DER formatでよいです。
書き出し先、ファイル名を指定します。とりあえず拡張子はなんでもよさそうですが、.derにします。
書き出した証明書を登録しましょう。
先ほどのChromeの設定画面に戻って、HTTPS/SSLの項目の「証明書の管理...」から先ほど書き出したファイルを読み込んでください。 2回くらいパスワードの入力を求められたり悲しい×を見たりしますが気にせず登録してください(勉強のとき以外は気にした方がいいし、外しましょう)。
Firefoxの場合
HTTP通信のプロキシについてのみです。
右上のメニューから設定を開いて、一番右の詳細タブを開き、その中のネットワークの項を開いてください。
「接続設定...」をクリックし、下図のように設定したらよいはずです。
勉強会の最中では、FirefoxのHTTPSがうまくいかなくて困りました。 鍵付きの証明書にしてみたりと試したのですが、HSTSが云云かんぬんと出てきて結局HTTPSのサイトにはアクセスできませんでした。
HTTPSとHSTS
https://ja.wikipedia.org/wiki/HTTP_Strict_Transport_Security
HTTPS試している最中に何度か出てきたので、勉強会の最中なんだろう、と思いつつ、ここまでこじつけるのにそれなりに時間を使ってしまったので、流してたんですが。
HSTSは、HTTP Strict Transport Securityの略称で、
WebサーバーがWebブラウザに対して、現在接続しているドメイン（サブドメインを含む場合もある）に対するアクセスにおいて、次回以降HTTPの代わりにHTTPSを使うように伝達するセキュリティ機構
とのことです。
つまり、たとえばforce_sslなどで、HTTPSで通信を行って欲しいパスにHTTPのURIが飛んできたらリダイレクトさせるようにしたとします。
このとき、リダイレクトさせるレスポンス(ステータスコード 301 Moved Permanently, Location: https:://xxx...)はHTTPで行われるので、
Webブラウザにレスポンスが届く前に、このレスポンスの内容が改ざんされたかどうかはWebブラウザ側では検出できないわけです。
なので、リダイレクトさせるURIを変えたり、HTTPSの内容をHTTPで中継(SSL Stripping)したとしても、Webブラウザでは気づけないし、防げない...
それだと困るので、リダイレクトする前に、サーバ側でWebブラウザがHTTPSでないと接続を許可しません。 と設定をしておいて、その設定を元にWebブラウザにHTTPSへの切り替えを強制する仕組みを入れます。
この仕組みがHSTSっぽい気がしますが...。
本当は、SSL Strinpingが分からないので、後者はいまいちよくわからないのですが、ぐぐったら、この動画見てね(1時間)ってでてきたのでおかわり案件ですね。 https://www.youtube.com/watch?v=MFol6IMbZ7Y
あ、もしかして、これ、証明書というよりやっぱりHTTPSが上手くいってないのでは...
HTTPリクエストメソッドを書き換える
Burpを使ってHTTPを書き換えてみます。
HTTP通信の様子を見る
Burp Suiteのプロキシの設定を確認します。
上記までの設定が正常に終了していれば、Proxy > Interceptのタブの「Intercept is on 」のボタンを一回押して、「Intercept is off」にすればHTTP Historyのタブに切り替えれば、多量のリクエストの流れが見えると思います。
本当は、Target/Site mapのタブで見るのがメインのようですが...。
なお、うっかりBurp Suiteを2つ以上立ち上げていると同じIPアドレス:ホストに対するプロキシが１つしか立てられないので焦ります。
Interceptする
HTTP通信の内容を覗きたいページへリクエストを送る直前に、Proxy > Interceptのタブの「Intercept is off」を押して、「Intercept is on 」にすれば、下記のように、リクエストの内容を見る事が出来ます。
リクエストを送信させたり、プロキシを通る通信を進めたい場合は、また「Intercept is on 」のボタンを一回押して、「Intercept is off」にすれば、押す前の状態に戻ります。
Interceptして書き換えたリクエストをForwardで送る
Interceptしたリクエストの内容を書き換えて、サーバからのレスポンスの内容が変わるかやってみましょう。
具体的には、リクエストヘッダのURLを書き換えて、ブラウザのアドレスバーに表示されているものとブラウザに表示されているものが違う、みたいなことをやりました。
たとえば、このページをリロードする前に「Intercept is off」を押してInterceptする状態にして...
こんな感じ。
動作的にはForwardでこのリクエストをサーバへ送ろうと待っているブラウザへ修正したリクエストの内容を転送してあげることが出来るのですが、 １つしか接続してないなら、Forwardでいいけど、大抵、いろいろ開きながらやっているので、Interceptの切り替えやったほうがやりやすいような気もしました...。
デコーダでBase64などで暗号化されている内容を復号する
下記のような画面のフォームに、一部の暗号化方式(この暗号がどういったものか、怖い人に怒られそうなレベルで分かってない)で暗号化されたパスワード等が復号できます。
それで、一部のシステムの暗号化されているパスワードを復号してみたりしました。
もうちょいそもそもな知識的なところや徳丸本の内容について思ったことや調べた方がいいところはあるけれど、それは明日、明後日にしよう...。
