ご挨拶
皆様はじめまして。21新卒インフラストラクチャーディビジョンに配属されました田口と申します。 6月に配属されてからはGitLabの運用やクラウドのセキュリティ向上などの業務を行ってます。
冬の寒さも本番を迎え、12月下旬という時期的に身も心も冷え冷えとしておりますが皆様いかがお過ごしでしょうか。
今回の記事は「己のエンジニアリング技術を用いて新しい技術とお金を得る」というエンジニアにとって一石二鳥なバグバウンティについてご紹介します。
- ご挨拶
- バグバウンティとはなんぞや
- プラットフォームについて
- バグバウンティを行うに当たっての注意点
- バグバウンティを始める人への最初の指針
- 実際にバグバウンティを行うに当たって
- 効率化を図ろう
- 締めの言葉
バグバウンティとはなんぞや
企業が管理しているプラットフォームの脆弱性を報告して報酬を得る活動のことです。
ざっくりとした流れとしては
- バグハンターが企業のWebサイトで脆弱性(バグや設定ミス)を見つける
- バグハンターが見つけた脆弱性について、「こういう悪影響あるよ」「こうやれば直せるよ」「報酬はこのぐらいください」といったレポートを作成し企業に送る
- レポートをもらった企業が報告された脆弱性について確認し、認められる場合は、脆弱性と認められること、直すのにかかる時間、報奨金を報告者に伝える。再現性がない場合や、スコープから外れている、そもそも仕様である等、レポートを受け入れない場合はその旨を報告者に伝え、やり取りを打ち切る。
- 企業が修正し終わったら報告者に伝え、報奨金が支払われる
企業、プラットフォーム等によって差はあれ、大まかな流れは同じはずです。
要するに企業は脆弱性が見つかって嬉しい、バグハンターはお金をもらえて嬉しい！というシステムです。
プラットフォームについて
マイクロソフト、Google等の大企業はバグハンターと直接やり取りをする窓口がありますが、一部の企業以外は企業とバグハンターを仲介するプラットフォームを利用している場合が多いです。
プラットフォームは「HackerOne」「Bugcloud」あたりが世界的な有名所、日本国内では「BugBounty.jp」が存在します。
バグバウンティを行うに当たっての注意点
実際にバグバウンティはどうやるのかを説明する前に注意点について説明します。
規約は守ろう
プラットフォームや企業によって、独自の規約が設けられています。
例えば自動スキャンの制限、スコープの指定等、登録に用いるメールアドレスの指定がこれに当たります。
企業に対して悪影響を与えてはいけない
データの破壊
SQL injection等の脆弱性を引きあてると、どの程度の操作を行えるかを調査したくなりますね。
特定の操作から別の脆弱性の発見につながったら見込める報奨金も増えますからね。
とは言え DELETE関連の操作等、データの操作は絶対に行わないようにしましょう。
機密データの閲覧
許可されていないデータの閲覧権限を取得できた場合、どの程度のデータを取れるかが脆弱性の重大さに関わってきます。
筆者の主観ですが多くの場合は他ユーザーのデータが閲覧できると重大性が高いバグとして扱われることが多いようですので、これが実現できるかまでは確認したいところです。
しかし他人の情報を閲覧するのはだいぶお行儀が悪いので、自分でもう一つユーザー登録を行い、自分が管理する別アカウントのデータを取得する等の対策を行いましょう。
レポートについて
企業へのバグはレポートと言われる文章で報告します。
このレポートは脆弱性の内容や重大さ、再現方法等を記述するのですが、これを読むのは企業のセキュリティ担当の人です。
彼らがレポートを読みバグの重大さや再現性を確認し、報奨金が確定します。
よってこのレポートがあまりにも粗雑だとレポートを受け取った企業側に労力がかかってしまったり、それによりやりとりが増えるという事態が発生します。
企業側にも迷惑になってしまいますし、上手く伝わらないと報奨金が減ったり脆弱性の重大さが伝わらなかったりするので、お互いにとってメリットはありません。
できるだけわかりやすく、簡潔に書くようにしたほうがバグハンターにとっても企業にとっても有益です。
多くのプラットフォームは他者のレポートを読むことができるので、それらを読みレポートの書き方を勉強するのもバグの発見と同じぐらい重要だと思います。
バグバウンティを始める人への最初の指針
この章ではHackerOneを利用する前提で話をすすめます。
大前提として、バグバウンティは企業のリソースに対して多くのバグハンターが同時に調査を行い、同じ脆弱性を報告した時はより早く見つけた人が得をする仕組みになっています。
よってバグバウンティは競合が少ないほど報告しやすくなります。
HackerOneではバグバウンティプログラムには誰でも参加できる「パブリックプログラム」と招待された人だけ参加できる「プライベートプログラム」があり、それぞれ報奨金が発生するものと発生しないものがあります。
これらのメリット、デメリットをまとめたものが以下の表になります。
登録時点ではパブリックプログラムに参加し、最終的にプライベートプログラムに参加していくのが報奨金を得るという点では近道かなと思います。
方針は見えたので、具体的にどの様なバウンティプログラムに参加するべきかの考え方の一例を書いていきます。
調査対象の決定
バグバウンティでは様々な企業がバグ報告を待っていますが、初心者が最初に狙うべき企業のポイントは以下の3つだと考えています。
- 報奨金が出ない
- スコープが広い
- 自分の得意分野の知識を活かせる
報奨金が出ない
報奨金がでないバウンティプログラムに参加するに当たってのメリットは3つあります。
- 調査人数が少ない
- 脆弱性が残っている可能性が高い
- プライベートプログラムに招待されやすくなる
調査人数が少なく未発見の脆弱性が存在する可能性が高いのは、報奨金度外視でとにかくバグを発見したいという目的なら明確にメリットです。
更にHackerOneではレーティングというシステムが存在します。
これは報奨金が発生しないバウンティプログラムでもレポートが受理されると上昇し、レーティングが上がるにつれて企業側からバウンティプログラムへのオファーが届くようになります。
企業側からのオファーによって参加できるバウンティプログラムはプライベートプログラムと呼ばれ、招待されたバグハンターのみが参加でき、報奨金が発生するものも存在します。
よって、報奨金が発生するプライベートプログラムで悠々自適にお金を稼ぐために、最初は報奨金がでないバウンティプログラムに参加し、レーティングを稼ぐのが初心者にとってはいいのかなと思います。
スコープが広い
この記事の中でも度々「スコープ」という言葉を使っていますが、バグバウンティにおけるスコープは「調査範囲」という意味で用いられます。
スコープには企業が脆弱性を探してほしいドメインやソースコード、バイナリ等が記述されています。
このスコープが広ければ広いほど他の人が手をつけていない部分がある可能性が高いため、独自の脆弱性を発見できる可能性が上がります。
自分の得意分野の知識を活かせる
セキュリティと一口に言っても範囲が広いので、ネットワーク、バイナリ解析、コンテナ技術、ペネトレーションテスト等様々な分野があります。
バグバウンティの入門ブログや本などではネットワーク、特にXSSがおすすめと書いてありますが、いろいろなところでおすすめされるだけあって調査人口が多いようです。(レポートを読んで感じた筆者の主観なのでデータはありませんが…)
なので、自分の得意分野がある人はそれを活かした調査を行ったほうが、脆弱性も見つかりやすく、調査に当たって新しい知識を得ることができるため、モチベーションの維持にもつながると思います。
もしセキュリティについては勉強を始めたばかりで得意分野がないという人は、ネットワーク調査について勉強するのをおすすめします。
ワイルドカードが含まれるドメインがスコープに含まれている場合、サブドメイン探索によってテスト環境が公開されているのを発見できたり、サーバーソフトが古く重大な脆弱性が含まれているバージョンだった場合、それを報告するだけでもレポートが受理される場合があります。
知識をつけるという意味においてもネットワーク関連の知識は汎用性が高いため、実用性も高いと思います。
実際にバグバウンティを行うに当たって
バグバウンティで報奨金やレーティングをたくさん稼ぐためには効率化がかかせません。
しかしバグバウンティを始めたばかりのタイミングでいきなりツールを自作するのは時間も知識もかかるためあまり効率的では無いかも知れません。
よって本章では前章の最後でおすすめしたネットワーク調査について既存のツールを紹介します。
僕が初めてAcceptされたレポートは以下のツールを利用して、CRITICALなCVEが存在する古いバージョンのサーバー稼働の報告でしたので、実用性については保証できます。
他にもバグバウンティで有用なツールは数多く存在しますのでいろいろと探してみるのもおすすめです。
大前提ですが、許可されていない外部のネットワークに調査ツールを実行するの絶対にはやめてください。
ツール紹介
- Wappalyzer
- subfinder
- gowitness
- スクリーンショットツール
- https://github.com/sensepost/gowitness
- nslookup, dig
- IP逆引き
- nmap
- ポートスキャン
Wappalyzer
Wappalyzer は、閲覧しているWebサイトのサーバーやJavaScriptフレームワーク等を確認できるGoogle Chrome の拡張機能です。
Webサイトがスコープに存在するときに、まずアクセスしてWappalyzerで利用技術とバージョンの確認を行います。
AWSのドキュメントページで実行すると以下の様に利用技術が確認できます。
AWSのドキュメントページでは jQuery 1.0.603 と RequireJS が用いられているようですね。
ここで確認できたリソースとバージョンにCVEが存在するならそれだけでレポートになる可能性があります。
CVEは存在せずとも、フロントで古いバージョンを利用している企業はアップデートの意識が低いかアップデートできない事情があると考えられるため、バックエンドも古いバージョンで動作している可能性があり、調査する価値があると言えます。
逆に最新のバージョンを利用していたり、そもそもWappalyzerに情報が表示されない場合はソフトウェアアップデートの意識や秘匿性への意識が高いため、バグを探すのが難しいと考えられます。
subfinder
subfinder はスコープにワイルドカードが含まれるドメインが存在するときに、サブドメイン探索に利用します。
以下に紹介する nslookup, dig, gowitness に渡す具体的な調査対象を収集するために用いるのが目的となります。
nslookup, dig
言わずと知れたIP逆引きコマンドですね。
サブドメインをこれらのコマンドにわたすことでIPアドレスを収集し nmap 等のポートスキャンツールに渡します。
単純な収集以外にも脆弱性の発見へのヒントが存在することがあります。
例えば多くのIPアドレスは近い数字を持つのに一つだけ離れたアドレスだった場合、このアドレスはサブドメインハイジャックの被害にあっていたり、被害は受けていないものの忘れ去られて管理されていない状態になっている可能性があるため、調査する価値があります。
nmap
これまた言わずと知れたポートスキャンツールです。
IPアドレスを収集したらやることは一つ。ポートスキャンで開放ポートの情報収集ですね。
明らかに不要なポートが開放されていたり、動作しているOS、バージョンが古いものだった場合、動作しているソフトウェアが怪しいものだった場合はレポート報告のチャンスですね。
(注釈：「規約は守ろう」の項でも書きましたが自動スキャンは企業によっては禁止されている場合もあります。許可されている場合でもオプションでスキャン速度を調整し、企業のリソースに影響を与えないようにしましょう。)
gowitness
gowitnessはオプションでURLやIPアドレスを渡すと自動的に80, 443ポートにアクセスし稼働しているWebサイトのスクリーンショットを撮影してくれるツールです。
コマンドラインでサーバーの稼働状況を確認するのも重要ですが、実際にWebサーバーにアクセスし、どの様な状態になっているのか確認するのも大事な作業です。
例えばnmapではどのWebサーバーがどのバージョンで稼働しているかまではわかりますが、コンテンツまでは把握できません。
もし撮影したスクリーンショットにWebサーバーのデフォルトページが設定されていたり、テスト用と思わしきサーバーでのコンテンツ稼働が見つかる可能性があり、テスト用サーバーやコンテンツがおいていないサーバーを公開すること事態が設定ミスなのでレポートに記載できるかもしれません。
効率化を図ろう
ツールを組み合わせる
前項ではネットワーク調査で有用なツールの紹介をしましたが、これらのツールを一々手で呼び出して取得したデータを調整してまた別のツールを呼び出すなんてしていたら探索だけで日が暮れます。
上記で紹介したツールは Wappalyzer 以外全てコマンドラインツールなのでシェルスクリプトやPythonで連動させることができます。
スコープが広ければ広いほど調査対象は増えますが、その分調査時間も増えます。
うまいこと自動化して寝ている間に初期調査は終わらせてしまいましょう。
ツールを自作する
先程紹介したgowitness等のスクリーンショット撮影ツールはレスポンスが返ってきた時点で撮影を行うので、ページのロードが完了していない状態のWebサイトが画像として残ってしまいます。
静的なページなら問題ないのですが、動的なページや配置に時間がかかるWebサイトの利用には向いていません。
なので「seleniumとchromium driverを使ってページのロードが完了したらスクリーンショットを撮影するツールを作ってみる」といった様に不満点を改善した自作ツールを作ってみてください。
IaCで検証環境を作る
検証環境が必要になるのはネットワーク調査から少し進んだ話になります。
ネットワーク調査で外部からアクセスできるサーバーと稼働しているソフトウェアが見つかり、それらの組み合わせで動作するバグが一般に知られているとします。
これはレポートに書ける内容なのですが、実際にどの様に動作し、それがどの様な影響を与えるかを記載すると企業の担当者にとっても親切です。
しかし企業のサーバーにバグを試すのは当然NGですので、検証環境で同様の環境を再現しましょう。
でも手作業で一々OSインストールしてサーバーソフトインストールしてなんてやってられませんね。
そこでおすすめなのが Infrastructure as Code (IaC)という技術です。
これはインフラをコードで表現、管理を使用という発想なのですが、これを使えばテンプレートを作成からインストールするOSやサーバーソフトの種類やバージョンを指定するだけで簡単に検証環境を作ることができます。
IaCで主に用いられるメジャーなツールはTerraform, Ansible, Vagrantというものが存在します。
TerraformでAWS等のクラウドプラットフォームにコンピューティングリソースをデプロイ、もしくはVagrantでローカルVirtualMachineにOSをインストールし、それらにAnsibleでサーバーソフトウェアのインストールや設定を行うといった手順で検証環境を作成することができます。
手作業で環境構築するのは管理も含めて大変なのでIaCを身につけるのは本当におすすめです。
まぁ僕も勉強中なのですが。
締めの言葉
いかがでしたか？(定型文)
最近僕が所属するインフラDivでもセキュリティに対する取り組みが増えてきたのでセキュリティに関する記事を書いてみました。
久しぶりに長い文章を書いたので読みづらい部分もあるだろうなぁとは思いますが、バグバウンティやセキュリティに関して興味を持っていただけた方がいれば幸いです。
もしバグバウンティに興味をもっていただけたなら、オライリー社から発売されている「リアルワールドバグハンティング」という本を読んでみてください。
今回の記事の作成や僕がバグバウンティを始めるに当たってとても参考にさせていただいた本です。
この記事の様なバグバウンティの触りの部分の詳しい内容や、脆弱性ごとのレポートの紹介があり、間違いなく身になる本です。
それでは長くなりましたが読んでいただきありがとうございました。
