新たなセキュリティテスト手法、バグバウンティプログラムのすすめ（中編）

こんにちは。マネージド&セキュリティサービス部セキュリティサービス部門の閏間です。総合リスクマネジメントサービス「WideAngle」の新サービスの企画を担当しています。本記事では、私がセキュリティの知識・技術向上のために業務外で取り組んでいるバグバウンティプログラムについて、3回にわたって紹介します。本記事により、バグバウンティプログラムの有効性と、脆弱性探しのおもしろさの両方を伝えられれば幸いです。

なお、バグバウンティに関する記事としては、NTT Com社内バグバウンティのご紹介もありますので、ぜひそちらもご覧ください。

脆弱性探しはおもしろい

本記事では、バグハンターとしての経験を振り返りつつ、脆弱性探しの魅力をお伝えしたいと思います。

脆弱性探しに取り組み始めたきっかけは、NTT Comの前に勤務していた会社で、セキュリティ機能の開発担当になったことです。知識向上だけでなく、実践を通した技術力向上も目指したいと考えていたところに、サイボウズの脆弱性報奨金制度のことを知り、取り組み始めました。3ヶ月くらい取り組み続けていたところで初めて脆弱性が認定され、達成感が感じられたので、以来ずっと続けています。

ちなみに私は脆弱性診断を業務として実施したことはなく、脆弱性探しはあくまで趣味として取り組んでいます。ただ趣味といっても、楽しいだけの趣味とは異なり、しんどい思いをする場面も多いです。とくに、長期間脆弱性が見つからないときは気持ちが沈みがちです。しかしうまくいけば後述するような達成感や充実感が得られるので今も続けられています。これまでに見つけた脆弱性は8年間で100件ほどです。トップクラスのバグハンターになるとひと月に20件くらいのペースで脆弱性を発見し認定されているので、私はそれほどハイペースではありません。細く長く続けているといった感じです。

脆弱性探しによりさまざまな達成感が得られる

私の場合、以下のような点で達成感や充実感が得られるのがうれしいので、脆弱性探しに取り組んでいます。

力試し
知的好奇心を満たす
本来できないはずのことができてしまうのが楽しい
品質向上への貢献
報奨金を得る

バグバウンティプラットフォームが公開するレポートで、バグハンターがバグバウンティプログラムに参加する目的についてのアンケート結果が載っていることがありますが、私の目的もおおむねそれらと同じです。もちろんNTT Com社内バグバウンティプログラムにも参加しました。こちらは入社してまだ間もなかったこともあり、話題作りを狙った面もありました。

脆弱性探しに対する心構えとして、私は脆弱性が見つかればいいなという希望的観測ではなく、脆弱性は必ずあるという確信にもとづいて脆弱性探しに臨んでいます。脆弱性を探しても見つからないときは、脆弱性が存在しないのではなく存在してるけれど自分が見つけられていないだけだ、と考えます。言い換えれば最後は執着心や執念で脆弱性を見つけているのですが、その気持ちを維持できるのは、過去に他社でソフトウェア開発をしていた経験によるものです。開発当初に作りこんでしまった潜在バグが数年後に見つかる、という経験を何度も繰り返した結果、ある程度の規模のソフトウェアのバグを0にするのは極めて困難である、と考えるに至りました。このような考えを持っているため、あきらめずに脆弱性を探し続けることができます。

カジュアルな手法でも脆弱性は見つけられる

脆弱性を探す方法としては、例えばWebアプリケーションを構成するJavaScriptやOSS(Open Source Software)ライブラリのソースコードを読んだり、見つけたあやしい箇所に対して攻撃するためのツールを作って実行したりする方法があります。しかし私はそのような高い技術力を必要とする方法ではなく、WebブラウザーでいろいろなURLにアクセスしてみたり、ローカルプロキシーツールを使ってHTTPリクエストのパラメータを書き換えてみたりするといった、比較的カジュアルな方法で脆弱性探しをすることが多いです。意外に思われるかもしれませんが、そのようなカジュアルな方法でも、結構脆弱性は見つかります。

大まかには、以下のような手順で脆弱性を探しています。

何が資産かを考える。
- ユーザーが保存するデータ、設定値、ユーザーアカウント情報、ログデータ、機能を利用できる権利、etc...
資産に対し、情報セキュリティの3要素（機密性、完全性、可用性）のいずれかの点で問題を起こすことを考える。
- 一般的に、機密性、完全性、可用性のいずれとも関係ない事象は、脆弱性であると認定されないため。
アプリケーションへの入力を、通常とは異なる形に変化させ、処理された結果問題が起きることを目指す。
- コンピューターの動作の仕組みは、ものすごく単純化すると、入力→処理→出力、となるが、これをふまえると、おかしな出力を得るにはおかしな入力を与えればよいため。

ひと口にアプリケーションといっても、Webアプリケーションやネイティブアプリケーションなどいろいろなタイプのものがあります。例えばサイボウズOfficeはWebアプリケーションの一例ですし、ネイティブアプリケーションの例としてはGoogle Chromeなどが挙げられます。WebアプリケーションはWebサーバーとの通信がHTTPとして規格化されており、後述するローカルプロキシーツールで簡単に通信に介入できるといった特徴があるため、入力をいじりやすいです。その意味で、Webアプリケーションは脆弱性を探索しやすいタイプのアプリケーションともいえます。

もちろん、アプリケーションがとり得る入力をすべて網羅的に調査するのはあまりに非効率です。そのため典型的な脆弱性をまとめたドキュメントを読んで、脆弱性のパターンを理解したうえで調査するようにしています。例えば以下のドキュメントです。

安全なウェブサイトの作り方（IPAが制作、公開）
Web Hacking 101（Peter Yaworski著）

「Web Hacking 101」はHackerOneにユーザー登録すると無償でPDF版をもらえます（少なくとも私が登録した時はもらえました）。「Web Hacking 101」には実際に発見された脆弱性の実例について詳細が書かれており、SSRF(Server Side Request Forgery)やXXE(XML External Entity)といった、比較的新しい種類の脆弱性についての記載もあります。脆弱性の実例に関する情報はHacktivity（HackerOneのバグハンターの活動記録）などでも得ることができますが、ここで挙げたようなドキュメントで全体像を把握することもよいことだと思います。

典型的な脆弱性を探す調査のほか、セキュリティ機能の基本であるAAAも定番の調査対象です。AAAとはAuthentication（認証）、Authorization（認可）、Accounting（アカウンティング）の3つの機能のことを指します。もしこれらのセキュリティ機能が正しく動作していなければ、直接的な機密性/完全性/可用性の問題がなくとも、それだけで脆弱性といえる場合が多いからです。例えば、パスワード変更してもログインセッションが有効な状態で残っていたり、本来アクセス権のないデータを参照できたり、監査ログの改ざんができたりするといった類のものです。

そのほかには機能が複雑になればその分脆弱性が入りこむ可能性が高まると考え、機能的に複雑な部分を狙って調査することもあります。また、長くバグバウンティプログラムが実施されているソフトウェアは新たな脆弱性が見つかりにくくなる傾向があります（これを「枯れた」状態と呼びます）。そのようなケースでは、アップデート時に追加された機能に絞って調査する、という方法も有効です。

ローカルプロキシーツールを使用することは超基本

調査にあたっては、ローカルプロキシーツールと呼ばれる、WebブラウザーとWebサーバーの間のデータのやりとりを仲介するツールをよく使います。このツールを使うと、WebブラウザーとWebサーバーの間の通信の中身を見たり、Webサーバーに送信するデータを書き換えたりすることが可能です（実際にはほかにももっと豊富な機能が備わっています）。また、よく使われているローカルプロキシーツールの多くはHTTPS通信にも対応しています。「Webブラウザー - ローカルプロキシーツール」、「ローカルプロキシーツール - Webサーバー」という2つのセッションに分離し、仲介するローカルプロキシーツール上で一度HTTPSを復号することで、データの参照・書き換えを実現しています。

代表的なローカルプロキシーツールとしては以下のものがあります。

Fiddlerは、起動しただけでWindowsのプロキシー設定をFiddlerの待ち受けポートに自動的に変更しますが、この点が便利なのでお気に入りでした。しかし後継のFiddler Everywhereは旧版（Fiddler Classic）の全機能を引き継いでおらず、脆弱性探しには欠かせない「HTTPリクエスト送出をインターセプトしてパラメータを書き換える機能」すら備えていないので、最近は別のツールに浮気中です。もともとFiddlerは脆弱性調査を目的としたツールではなく、Webアプリケーションのデバッグが目的なので仕方ないのかもしれません。

また、最近調査したWebアプリケーションではWebSocketを使用していたのですが、FiddlerだとWebSocketのメッセージ書き換えができないことも、Fiddlerから気持ちが離れ気味なもう1つの理由です。OWASP ZAPであればWebSocketのメッセージ書き換えに対応しているため、最近はもっぱらOWASP ZAPを使うことが多いです。私は試したことはないのですが、Burp SuiteでもWebSocketのメッセージ書き換えができるようです。

脆弱性探しに興味を持たれた方は、まずはOWASP ZAPかBurp Suiteをインストールして、WebブラウザーとWebサーバーの間でどのような通信が行われているかを眺めるところから始めてみるとよいと思います。

なお、「ローカルプロキシー」という呼称ですが、Webブラウザーと同じPCで動作させるという意味で「ローカル」という言葉が使われているのだと思われます。しかしリモート（Webブラウザーとは別のPC）でローカルプロキシーツールを動作させることももちろん可能です。例えばこのことを利用して、スマホアプリの調査をするときは、「スマホ上のWebブラウザー - PC上のローカルプロキシーツール - Webサーバー」という構成で調査できます。