バグハンターに入門しようぜ

公開:2020/10/06
更新:2020/10/17
3 min読了の目安(約2700字IDEAアイデア記事
Likes15

1. バグバウンティって何

バグバウンティプログラム(脆弱性報奨金制度)とは、製品やサービスの脆弱性報告を外部のユーザーから受け付け、その対価に報奨金を支払う制度です。このプログラムで報奨金やオリジナルのグッズ、政府機関のセキュリティ向上に貢献した名誉を目的にホワイトハッキングを行う人をバグハンターと呼びます。

2. まずはお勉強

大半のバグバウンティプログラムでは、参加者はソースコードを確認することはできません。これは「ブラックボックステスト」と呼ばれ、ここで脆弱性をヤミクモに探すのは大変な作業です。そのため、事前に脆弱性がありそうなポイントを知っておくと、効率的に探す事ができます。

● Twitterで情報収集

「#infosec」「#bugbounty」「#bugbountytips」などのハッシュタグ検索や、海外の有名なバグハンターのFFからフォローを増やすと良質な情報が流れてきます。

● SlackやDiscordでコミュニティを探す

残念ながら日本では、バグバウンティについて話している巨大なコミュニティは見かけません。海外のコミュニティでは、collaborate(一緒に脆弱性を探して報奨金を分割したりする)が盛んで、活発に情報共有をしているため、英語が苦手な場合でも参加した方が良いです。

良かったらこちらも見てください〜!
https://japan-bugbounty-forums.web.app/

● 他の人がどのような報告をしているのか学ぶ

HackerOne等のプラットフォームで公開されているレポート読んだり、脆弱性の研究している人のブログを読むと良いと思います。多くの記事で「4桁ドルの報奨金をもらった!」と書かれているのを見て自信をなくすこともありますが、脆弱性を見つけて正しく報告した行為に優劣はありません。

HackerOne Hacktivity(Hacker Activity)
公開されているレポートの報奨金の額や内容を読めます。
https://hackerone.com/hacktivity

Pentester Land - List of bug bounty writeups
バグハンターが自身の見つけた脆弱性を解説しているブログ記事をまとめているサイトです。
https://pentester.land/list-of-bug-bounty-writeups.html

3. バグの探し方

ブラックボックステストでは、実際に動いているソースコードを確認できないので、使える手法は以下のようなものに限られます。

● プロキシを使って流れてくるHTTP通信を再現する

WebアプリケーションやAPIの脆弱性を探す最も一般的な方法です。Brup suiteなどのソフトウェアを使い、サーバーとの通信を監視します。気になるリクエストが流れてきた場合に、jsonや値、HTTPヘッダーをいじることでバグが発見できる可能性があります。

関連ワード

GraphQL, WebSocket, XSS, SQL injection, IDOR, Path traversal等

● 許可されている場合はリバースエンジニアリングでコードの解析を行う

モバイルアプリ、PCアプリはリバースエンジニアリングを行うことで、APIのパス(Path)やある程度の処理の流れを推測することができます。

● プログラム中の変数や関数がどのような動作をしているか解析を行う

セキュリティ意識の高いモバイルアプリやプロキシに通らない通信をリアルタイムに監視するために役に立ちます。(参考:SSLピンのバイパス、HTTP以外の通信など)
また、クライアントサイドのSQLiやRCEを発見する手がかりにもなります。

4. 脆弱性を見つけたら

脆弱性を見つける事ができたら、次はレポートを作成します。ここがバグを見つけるより重要な手順となります。今後も色々なレポートを作成するため、あらかじめテンプレを用意しておくと便利かもしれません。

● Summary(概要)

このセクションはレポートの内容を把握しやすいように1番上に書きます。

  • どこで(ドメイン・URL・使っているアプリケーションの名前など)
  • どの種類の脆弱性が見つかったのか(XSS,IDORなどの分類)
  • どのような悪用ケースが考えられるか

といったことを1~3文で簡潔にまとめます。

● Vulnerability details(脆弱性の説明)

ここには見つけた脆弱性をなるべく詳しく解説します。トリアージチームが脆弱性を再現できない場合は受け付けてもらえないため、手順を丁寧に書きます。WebアプリやWebAPIの脆弱性の場合は、RAW HTTPを載せるなどします。

● Impact(影響)

この脆弱性がアプリケーションやユーザーにどのような影響を与えるか説明します。

● Proof of concept

Impact・Vulnerability detailsで説明した脆弱性が本当に実現性のあるものかを証明します。内容によっては実演する動画を作ると理解されやすいと思います。

例) このリンクをクリックするとXSSが起きます! https://〇〇.com/~~~
例) このスクリプトを使います...

● Mitigation(解決策/緩和/修正案)

見つけた脆弱性をどのように修正するべきかを説明します。セキュリティチームが問題を迅速に解決するために必要です。

● Verification environment(環境)

モバイルアプリケーションのバージョンや、ブラウザーの種類などにより脆弱性の有無が変わる場合には必ず必要です。また、IPアドレスや、特徴のあるヘッダーを記載するとセキュリティチームの調査に役に立つ場合があります。

5.さいごに

見つけた脆弱性を悪用するとプログラムの参加資格や報奨金の対象外になる可能性があります。最悪の場合は、法律による処罰を受けるので注意してください...。

サポートありがとうございます。
これからも記事を書き続けたいと思います。