アラフォーのためのバグバウンティの話２


# はじめに

こんにちは。自称ホワイトハッカーの人すごいですね。
日本だと他人の管理するサーバーから想定されていない操作でデータを抜き取ることは犯罪ですのでやめましょうね。一円の得にもならないですし。

前回書いた原稿は思った以上の反応があったみたいですが、特にこの後知りたいことなどはこちらに伝わっていません。アラフォーの人は特にお金に興味はないのかもしれませんが、想像力を膨らまして書くことにします。基本的に自分の知ってることなのでWebサイト・Webアプリケーションのバグバウンティに関する話が中心になります。

これまで流れについては以下を参照してください
[アラフォーのためのバグバウンティの話](https://qiita.com/yousukezan/items/815208a78f4579bc97f5)

# どんな脆弱性でお金をもらえるの？
報奨金ってどのくらいのレベルの脆弱性でもらえるのか気になる人も多いと思います。ニュースになるようなゼロデイを見つける必要があるくらい難易度が高いとやる気が起きないのではないでしょうか。私もそうです。

ですが、現在は私がやる気が出るレベルの脆弱性で報奨金がもらえます。つまり人に説明できないような難しい脆弱性でお金をもらっているわけではなく、説明を読めば誰でも見つけられるような名前くらいは聞いたことのあるような脆弱性で報奨金をもらえるということです。報奨金の稼ぎ方としては報奨金の高い脆弱性をじっくり探すやり方と小さな脆弱性をたくさん報告して数をこなすやり方があると思いますが、このあたりはやり方と運によるとは思います。

## 数を見つけた脆弱性
あまりクリティカルではない小さな脆弱性はがんばって探せばわりと見つかるような気がします。報告件数でいうとこちらが圧倒的ですが、実績を積むことに意義を感じなくなってきているので、以前のように微妙な事象を無理して報告することはなくなっています。実績と報奨金を積みたい人はサーバーのバージョン情報が漏れてるとか`ClickJacking`とか`401 Injection`とか微妙な事象をがんばって報告するのもいいかもしれません。古いバージョンのJQueryを使っているというだけで報奨金をもらった例は残念ながら見たことがないので報告しても無駄だとは思いますが。
以下に個人的にお世話になった脆弱性の例を挙げます。

### DOM based XSS
件数が多いのはXSSです。とはいえ脆弱性診断ツールで見つかるような単純なXSSは少なく、DOM based XSSが多かったです。たぶん、単純な反射型XSSとかSQLインジェクションなどのわかりやすい脆弱性は、バグバウンティが始まる前に修正されているか始まった時点で見つかってるかだと思います。件数が多いのは見つかりやすいだけでなくバグバウンティを始めた当初はXSSしか探し方がよくわからなかったということもあります。

### FlashのXSS
人とちょっと違うかもしれないところは、もう終わりを告げつつあるFlashのXSSを割と見つけていたところでしょうか。これもDOM based XSSと同じように通常の脆弱性診断では探されないところだと思います。以前のYahoo!（グローバルの方）のようにほぼ無限（そのサブドメインのFlash広告全部）にあったところもありましたが、サブドメイン全体で1件とかにされて泣きそうになりました。

### オープンリダイレクト
あと、オープンリダイレクトも見つけた数は多いと思います。XSSだとWAFがあったりするとバイパスするのが面倒だったりしますが、それがないので探す心理的なハードルが低いのでいいです（個人の感想です）。Googleなどサイトによっては脆弱性扱いされないので注意が必要です。ですが、場合によってはクエリストリングやフラグメントにクレデンシャルが付いてリダイレクトされる事象もあり、そうなるとどこでも脆弱性として扱われて一気に報奨金も上がります。

Flashも終わりを迎え、DOM based XSSもChromeの仕様が変わり、独自のEdgeが終わりを迎え、IEが終わりを迎えつつある今では脆弱性として攻撃が成功する範囲がどんどん範囲が狭まっている気がします。新たな稼ぎ方を探したいですね。

## 報奨金が高い脆弱性

実は1件で100万円を超えるような高い報奨金をもらったことはないです。夢がないですね。そういう高額で税務署が黙っていないようなおいしい話は[時給100万円の人](https://twitter.com/mage_1868)に聞くのがいいのではないかと思います。

少ない中でも気付いたことはCVSSスコアが高そうな脆弱性は高い報奨金が出る傾向にはあるようです。あくまで自分の中ですが、1件あたりの報奨金が高かったのはディレクトリトラバーサルでした。RCEやSQLインジェクションとかSSRFとかもわりと報奨金が高かったと思います。DLLの問題で報奨金がそれなりに出たときは申し訳ない気持ちでいっぱいになりました。残念ながらかっこいいRCEで報奨金をもらったことはないです。

# 報奨金のもらい方
皆さん気になる脆弱性を報告してから報奨金がもらえるまでの流れを書こうと思います。見つけてから報奨金が決まるまでドキドキできて、それから振り込まれるまでもドキドキできます。パチスロでフラグが立つとか競馬のゴール前のような気分になれますね。

## 基本的な流れ
1. 脆弱性を見つける
1. 見つけた脆弱性がどう攻撃につながるのか報告を書く
1. 脆弱性だと認められtriageされる
1. 報奨金支払いが決まる
1. 振込先を教える
1. 振り込まれる

このあたりでがっつり個人情報を聞かれるので、匿名でお金が欲しいという人はやめておいた方がいいです。サイトによってはビットコインでもらえたりもするようですが、ビットコインで受け取ったことはないのでよくわかりません。

## 知っておくといい用語
バグバウンティで障壁になるのが英語だと思います。お金が欲しいという強い気持ちで乗り越えましょう。とはいえ単純なXSSのような脆弱性は定型文でなんとかなるので以下の用語くらい知っておけばそれっぽいやり取りができるのではないかと思います。あとは翻訳サイトがどんどん頭がよくなってるのでそのあたりを駆使してください。

### Vulnerability
脆弱性。`ぜいじゃくせい` と読みます。`きじゃくせい`でも`ひんじゃくせい`でもないです。
### Reproduce
報告を受けた側が脆弱性を試す方法です。`Step to reproduce`（再現方法）とかよく使います。
### PoC
Proof of Conceptです。これも脆弱性を実証する方法という意味で使われます。
### Triaged
脆弱性が認められて、修正対象になるということです。救急医療で使われるトリアージと同意だと思います。このタイミングで報奨金がもらえるかもしれません。
### Infomative
参考になったよ、ということで脆弱性ではない、残念ながら報奨金対象ではないということです。`X-Frame-Options`とか微妙な脆弱性を報告するときはこの覚悟が必要です。
### Duplicate
誰か他の人が先に同じバグを報告しているということです。バグハンターが嫌いな言葉1位です（ぼく調べ）。他の人が報奨金をもらえるかもしれませんが、自分はもらえません。
### Resolved
解決したということです。報奨金がもらえるタイミングが解決した後になる会社もあります。
### Reputation
バグバウンティプラットフォームによってはポイントが付くところもあります。変な報告ばかりすると下がります。Reputationが下がるとどうなるかはちょっとわかりません。

# 脆弱性の探し方
報奨金をもらうには脆弱性を見つけて報告する必要があるのですが、報告する脆弱性を見つけられるようになるにはどうすればいいの？という疑問があると思います。
実際には以下のような流れになると思います。

1. 脆弱性に関する知識を増やす
1. 脆弱性に対応した攻撃方法を知る
1. 脆弱性のある場所の探し方を知る
1. 実際に脆弱性を突いて脆弱性の存在を実証する方法を知る

ここからはこれらについて書こうと思ったのですが、長くなってきたのでこのくらいで。結局アラフォーに特化した話はまだ書けてないですね。

Let's バグハンティング！（続くかも）