2019-08-29

バグハンターmageに聞くバグハンティングの方法とセキュアなサービス作りに必要なこと

バグハンターとは、Webサービスやソフトウェアなどに含まれる脆弱性を、システム改善のために探し出す人々です。バグハントの方法は非常に多岐にわたりますが、具体的な手法、使用ツール、ハントのマナーを凄腕のバグハンターに聞きました。mageの名で知られる馬場将次さんが語り下ろす実践的なノウハウは、サービスをセキュアなものにしたいエンジニアのみなさんにとっても重要な知見になるでしょう。

バグハンターmageに聞くバグハンティングの方法とセキュアなサービス作りに必要なこと

バグハンティングを犯罪にしないために必ず知っておきたいこと
馬場流バグハント手法「調査」「解析」「実証」。そして「普通はやらない」を無数に試す
防御のために、言語やフレームワークの実装を学ぼう。コード読解から、違和感を見つけ出す方法を実践してみる
XSSの現在。技術の進化と並走する攻撃手法の進化
セキュリティを理解するためにまずはトライしてみる

なんらかのサービスの脆弱性を探り出し、サービス運用主に報告する。ときに、発見の対価として報酬を獲得するバグハンティングというカルチャーがあります。セキュリティへの意識は高まり続ける中、脆弱性発見を“組織の外にある目”であるバグハンターを頼りにする事例が生まれつつあります。

システムやソフトウェアが抱える脆弱性やセキュリティ施策に精通したバグハンターたちは、様々な手段を使い、思いもよらない脆弱性を見つけ出します。ならば、その手段はサービス運用にあたるエンジニアにとって有効な防御策として活用できるはずです。本稿では、バグハンターとして膨大な脆弱性発見実績を持つ馬場将次（ばば・しょうじ／ @mage_1868 ）さんに、脆弱性を発見する手順やコツをお聞きしました。

馬場将次さん: 専門学校を卒業後、印刷会社に入社しIT部門で研究開発を担当。自身が作ったWebサイトが攻撃を受けたことがきっかけとなり、セキュリティや脆弱性に関心を持つ。2013年にセキュリティ競技大会に参加し、本格的にバグハンターとして活動を開始した。その後、株式会社神戸デジタル・ラボに入社し業務としてセキュリティに携わるように。現在はセキュリティ診断・検査専門企業であるイエラエセキュリティに在籍する。世界的なCTF（Capture The Flag）競技会「DEF CON CTF」の常連チーム「binja」に所属し活動を続けている。

バグハンティングを犯罪にしないために必ず知っておきたいこと

──まず、バグを探すという行為の前提をお聞きします。好き勝手にバグ探しをすることは、ときとして犯罪と同一行為にも感じられます。バグハントにおける「犯罪」と「調査」の境界はあるのでしょうか。

馬場　個人で「犯罪」と「調査」を線引きするのは非常に困難です。そのため、好き勝手にWebサイトの脆弱性を探すのは避けるべきです。今はバグハントを支援するWebサイトがあるので、そこを利用するべきでしょう。例えば、HackerOneというサイトは、脆弱性を探してほしい企業とバグハンターのマッチングサイトとしての機能を持っています。実際にHackerOne内を探ってみれば、Twitterなどの大手企業が依頼を出しているのが確認できるでしょう。

また、HackerOneでは企業とバグハンターの脆弱性報告のやりとりが公開されています。さまざまな報告を読むのは非常に勉強になります。バグの種類や発見方法も分かりますし、バグ報告の書き方も参考になります。バグハントに興味がある人は、まずこういった報告を読んでみることをおすすめします。

──バグハント / バグバウンティにはHackerOneのようなサービスが欠かせない、と。

馬場　企業とバグハンターの間にHackerOneのようなバグバウンティのプラットフォームが存在することで、企業の「バグを探してください」という意思が明確になりますし、バグ探しのルールや報酬金額も提示されています。ルールを守る限り、問題になることはまずないでしょう。近年、バグバウンティに関するWebサイトが増えたことで、企業側の理解度も上がってきた印象があります。検証環境を用意してくれる企業も以前より増えてきていますので、バグハンター、企業の両者が安心してバグハントができるようになってきています。

バグバウンティに積極的に取り組んでいるのは、サイボウズ社です。サイボウズ社は先に挙げたバグバウンティのプラットフォームを使わず、独自にバグハンターと直接やり取りしています。こうした取り組みはもっと評価されていいと思いますね。

──企業とルールをきっちり決めておけば安心してバグハントができそうですね。

馬場　それでも、企業とバグハンターのコミュニケーションは慎重に行うべきです。企業側はバグハントを受け入れた結果、生じるリスクを把握しきれていない場合もあります。調査目的で本番環境へのハッキングを依頼されるケースもあるのですが、意図せず機密情報データを取得してしまい、バグハンターは不正アクセスの罪に問われるリスクも想定されます。もちろん、企業にとっては情報漏えいリスクです。

また、バグハンターは調査目的でのハッキング行為による副作用や、意図とは異なるシステムへの影響を理解しておくべきです。ある調査のためにSQLインジェクションを試したところ、本番環境の全ユーザのパスワードが初期化された、という例も聞きます。

パスワードリマインダ機能に対してSQLインジェクションの試行が原因で、データ破壊が起きてしまったのです。認証周りの脆弱性調査がデータ破壊に繋がると想定できていなかったことに起因します。

SQLインジェクションとは？

外部から入力された値をSQLとして組み立てるプログラムに対して、悪意のあるSQL文を入力してデータの破壊や機密情報の取得を行う手法。以下の例では上段のコードに「--」を加えることによって「AND password」という条件をコメントアウトして無効化している。さらに「OR 1=1」という条件の追加によってどんな条件がついていても「すべて真になる」という結果になってしまう。

SELECT * FROM users WHERE name='名前' AND password='パスワード'

SELECT * FROM users WHERE name='' OR 1=1--' AND password='パスワード'

馬場　あるWebサイトがどのようなソースコードで動作していて、裏側でどんなSQLが組まれているのかはバグハンターは見ることができません。実装が分からないものに対して、攻撃のリクエストを安易に送るようなことはしてはなりません。

例示のようにどんな副作用が起き、データ破壊につながるか見通しがききませんから。ともすれば訴訟につながることもあるので、バグハンティングの手法だけを知り、安易に試すと大きなリスクを負ってしまう可能性があることは、強く認識するべきです。

──調査行為と犯罪行為の境界、またリスクに関してはどのように勉強すればいいでしょうか。

馬場　経験を積むしかない、というのが正直なところですが、まずはガイドラインを読むことをおすすめします。ガイドラインはいくつかあり、どれが最も影響力を持つかには議論があり決められませんが、以下のIPAの資料は一度目を通しておくといいでしょう。

情報セキュリティ早期警戒パートナーシップガイドライン（PDF）

例えばガイドラインには「不正アクセス禁止法に抵触しないと推察される行為の例」として以下のような文言があります。

アクセス制御による制限を免れる目的ではなく、通常の自由なページ閲覧を目的として、日付やページ番号等を表すと推察される URL 中の数字列を、別の数字に差し替えてアクセスしてみたところ、社会通念上、本来は利用できてはならないはずと推定される結果が、偶発的に起きてしまった場合。（ただし、積極的に多数の数字列を変えて試す行為等は、制限を免れる目的とみなされる可能性があります。）
『情報セキュリティ早期警戒パートナーシップガイドライン2019年版』より抜粋。

つまり、URLのパスを /2019/04/01 から /2999/94/34 という風に変更してバグを引き起こしたとしても、不正アクセス禁止法には抵触しないと“推察される”と。このように、ガイドラインを読めば、意図せぬ犯罪行為を防ぐための、一つの指標にはなります。しかし、“推察される”の記述の通り、ガイドラインは絶対のものではないことは強調しておきたいところです。

──バグバウンティのルールを統一して定めることはできないのでしょうか。

馬場　それは難しいでしょう。企業によってセキュリティに対するルールや考え方も違いますし、バグには無数のパターンがあるからです。

明確なルールがないからこそ、バグハントを行うときは企業とのコミュニケーションが大切です。企業とのコンセンサスなしにバグハントを始めてしまうと、ただの攻撃者として見られてしまうこともあります。バグハントと犯罪行為の境界を設定するのは非常に困難であることは、まず認識しておくべきですね。

馬場流バグハント手法「調査」「解析」「実証」。そして「普通はやらない」を無数に試す

──馬場さんは普段どのような手順でバグハントを行っているのでしょうか。

馬場　私の場合、基本的には「調査」「解析」「実証」という流れでバグハンティングを行います。聞いたら拍子抜けするかもしれませんが、実はバグハントはエンジニアなら誰でもできるような簡単なことから行っています。

まず「調査」ですが、Webサービスの場合はHTTPのレスポンスやリクエストを観察します。プログラミング言語やフレームワークにはクセのようなものがあって、レスポンスやリクエストを見ればある程度は特定することができます。

例えばURLのパラメータが ?name=value という値だったとします。パラメータを書き換えて ?name[]=value としたときに、 value を適当な値に書き換えた場合と異なるレスポンスが返ってくれば「このサービスの使用言語はPHPかもしれないな」と、あたりをつけることができます。

また、例外が発生するようにパラメータを書き換えたり、通常ではありえないリクエストを送ったときにフレームワーク固有のエラーメッセージがそのまま返ってくることもあります。そうなれば一発でフレームワークを特定できるので、少し作業が楽になりますね。言語固有のレスポンスやリクエストのクセなどは開発するときに使わない知識かもしれませんが、バグハンターにとっては最高の手がかりです。

言語やフレームワークが分かり、それらがOSSならばソースコードが公開されているので、それを隅々まで読み解く努力をすれば、バグを見つけられるかもしれません。バグを見つけるチャンスは誰にだってあるのです。

──バグハントでよく使うツールはありますか。

馬場　Burpなどのローカルプロキシツールを使います。こうしたツールを使えば、誰でも容易にリクエスト内容を変更でき、調査はできます。しかし、闇雲にリクエストを送っているだけでは何も分かりません。言語やフレームワークの知識を網羅的に持ち、初めて「脆弱性を見つけるためのリクエスト」の傾向が見えてきます。バグをつかむためには経験や知識が大事なのです。

ローカルプロキシツールのBurpを使うとレスポンスやリクエストをローカルコンピュータ上でキャプチャでき、リクエストを自由に書き換えることができる。

馬場　もうひとつ、HTTPのプロトコルが理解できていれば、そこから脆弱性を探ることもできます。例えばファイルアクセスをするリクエストを書き換えることで、本来見えてはいけないファイルにアクセスできてしまうケースがあります。ディレクトリトラバーサルという定番の攻撃手法ですね。

ディレクトリトラバーサルは一般的なセキュリティの教本にも載っていますが、実際に試したことはない、という方もいるでしょう。バグハンターの本質とは、こうした「普通はやらないこと」を実際に試してみることにあると考えています。

「User agentを変えてみたらどうなるのか？」「HTTPのリクエストヘッダを追加してみたら、どうなるだろうか？」など、試すべき「普通はやらないこと」は山ほどあります。そして試行してみて、おかしなレスポンスが返ってくればこちらのものです。

上のキャプチャは単純な例であるが「リクエストのURLパスを変更してサーバのホスト名が保存されているファイルにアクセスできるかどうか試してみる」など、HTTPを理解していると調査できることも増えてくる。

──バグハントは地道な作業の連続なのですね。

馬場　Burpのスキャン機能等を利用できればもっと調査がしやすいのですが、多くの場合はサーバに負荷がかかるような脆弱性スキャンツールの使用は禁止されています。

Webサイトのソースコードや構成が見えないときは、地道に一つずつ持っている知識を試してあたりをつけていくしかありません。たどり着くまでにリクエストを何百パターンか試すこともあります。

──ツールを使わずブラウザから脆弱性を調査することもあるかと思いますが、こういった場合がどのようなアプローチをとるのでしょうか。

馬場　ここでも大事になってくるのは、「普通はやらない」を試すことです。ECサイトを調査するときを例にして考えてみましょう。ECサイトには商品の購入や決済が必ずあります。

商品を選ぶ
個数を入力する
購入する

これが通常の大まかなフローだと思います。ここで、例えば「購入数をマイナスにしてみる」という「普通はやらない入力」をすることがバグ調査の基本になります。

また、UIのインタフェースを注意深く見るのも重要です。あえて入力制限を強くしているような部分はバグが発生しやすいから塞いでいるとも考えられます。

──そうやって「調査」で得たものをどのように「解析」していくのでしょうか。

馬場　解析は調査と重なる部分が大きいのですが、フレームワークや言語が分かればソースコードを読むだけで脆弱性に繋がる挙動の見当がつきます。他にもHTTPレスポンスを見て分かったことを解析し、得られた情報によって様々なアプローチを取っていきます。解析では引き出しが多ければ多いほど有利になるので、初心者と経験者の差は「解析」で顕著に現れるかもしれません。

解析の結果、使っているアプリケーションやツールが分かれば過去に発見された脆弱性を試すこともできます。例えば画像のリサイズのためにサーバでImageMagickを使っていることが調査で分かったとします。ImageMagickには、過去「特定の画像フォーマットでOSコマンドを含ませたファイルを処理させることによって、そのコマンドを強制的に実行させることができる」という危険な脆弱性がありました。

この脆弱性を試しに使ってみるだけでもサーバのImageMagickのバージョンの見当がつきます。また、どの程度セキュリティ対策をしているのかもレスポンスによって分かってきます。使っているアプリケーションやツールのバージョンに関する情報も、バグハンターにとっては重要なヒントになるのです。

──バージョンアップは疎かになりがちなので、非常に身が引き締まる思いです。

馬場　油断した部分から脆弱性というのは生まれます。ツールやライブラリの過去の脆弱性は検索すれば多数出てきますし、仮にモダンな技術を取り入れていたとしても、古いコードが残っているとそこを攻められてしまう。いわゆる「秘伝のタレコード」なども危ういんです。

──「調査」「解析」に続く、「実証」とはどのような作業なのでしょうか。

馬場　「調査」「解析」はバグを探す作業ですが、「実証」はサービスの運用主に向けた作業です。報告をする企業に見つけた脆弱性がどれほど危険で、どんな驚異があるのかを理解してもらわなければなりません。

口頭の説明や資料だけではたいてい理解してもらえないので、バグハンティングのルールを逸脱しない範囲で攻撃コードをこちらで作り、実践して説明します。バグは再現性があって初めて信じてもらえることが多いので。