LINE Security
Bug Bounty Program の紹介
@tomofumi, Security Dept / LINE Corp
Tomofumi Nakamuraで検索
+ 正岡子規さんっぽい写真
Bounty 立上げして、現在は後方支援
普段は
脆弱性診断、Phishing 対策、調達、育成、
、、、いろいろ
こんなひと
Self Intro
登壇した背景
 日本からの報告を盛り上げたい。
 ケチってないことを知って欲しい。
 ついでに内製のセキュリティ組織があるって知って欲しい。
 セキュリティのエンジニアいます。
会場提供したからってだけじゃない
• Bug Bounty の一般的な話
• LINE の Bug Bounty の話
• 報奨金を提供できた事例
• 報告のコツ
Agenda
Bug Bounty の一般的な話
Bug Bounty とは
 製品やサービスには脆弱性が潜在する。
 潜在する脆弱性を発見した社外の報告者へ御礼で報いる活動。
 御礼は、金銭、Tシャツ、 食事、名誉、いろいろある。
 企業側の思惑はいろいろある。
今日は常設についてお話します
パターン1 : 直接運営
報告者 企業
脆弱性
御礼
LINE はこちら
報告者 企業
脆弱性
御礼
パターン2 : 間接運営
代行事業
窓口代行、
脆弱性
代行費+御礼費、
情報買い取り費
内部にセキュリティの人がいないとこちらが多い
日本と海外の比較
BugBounty.jp HackerOne
Bugcrowd
Synack
買い取って転売する組織 ... etc
Google
Microsoft
Facebook
Mozilla ... etc
日本 海外
直接
間接
サイボウズ
LINE
(昔はもう少しあった)
(HackerOneを使う企業も有る)
私見ですけど、日本はまだ黎明期と普及期の間くらい、海外は普及期と成熟期の間くらい
LINE の Bug Bounty の話
おおまかな流れ
内容の審査
御礼をお届け御礼の審査
対象外Web から報告
平均して2ヶ月くらい ( 案外、御礼の手続きに時間がかかります )
修正
影響調査や各所調整
運営
手続き
報告者
手続き
 https://bugbounty.linecorp.com/
 報告用のフォームを常設。
 金額や対象範囲など詳細が全部わかる。
Web に全部ある
 2017年は年間総額 76,500 USD 。
 審査員はセキュリティエンジニア。
 報告内容次第で参考金額に上乗せある。
 2017年の振り返り記事
 https://engineering.linecorp.com/j
a/blog/detail/255
結構もらえます
御礼について補足
 御礼はお金だけじゃない。
 就業規則や税金関連で報奨金を受け取りたくない人などを想定して、寄付も用意。
 Apache Software Foundation
 Linux Foundation
 OWASP
 Electronic Frontier Foundation (EFF)
 Let’s Encrypt
 Tシャツが人気あるって聞いたので、弊社もTシャツを作成した。
(イケてるかどうかは今後の課題)
 Hall of Fame (超意訳:ツワモノたち)
 誰がどの分野で何件かわかる。
 利用規約上の対象外でも載ることある。
 https://bugbounty.linecorp.com/ja/hall
offame/
功績を公開
報奨金を提供できた事例
金額が低いものから
500 USD
DOM based XSS by Regx Filter Misuse
 500 USD
 正規表現にユーザーの入力値を使う設計。
 報告者の詳細な解説記事がある。
 http://masatokinugawa.l0.cm/2018/01/regex-domxss.html
 新作Tシャツも送った。
1,000 USD
LINE Nearby User Tracking
 1,000 USD
 Indonesia 限定で提供している位置情報を扱う LINE Nearby というサービス。
 GPS 偽装 + 三角測量 = 標的にしたユーザーの正確な位置を特定できた。
6,000 USD
Open Redirect > Account Takeover
 6,000 USD
 LINE Login の OAuth の Redirect 処理の設計不備。
 Redirect 先の URL 指定において、https://user@example.com を指定可能だった。
 user@ に悪意ある誘導先を指定した場合、example.com より優先されてしまう。
 その結果 Account Takeover まで発展。
20,000 USD
Remote Code Execution
 20,000 USD
 SIP の Server 側の処理で Buffer Overflow が可能だった。
 これを利用して Remote Code Execution まで発展。
報告のコツ
残念ながらよく見る報告
 画面がバグってます。
 脆弱性ではないため「お問い合わせ」へ誘導。
 X-Frame-Option がないです。
 ありがたいですが、残念ながら利用規約上の対象外。
 それがないことによる具体的な Risk を指摘してもらえたら ... 。
 Scanner を実行した結果を送ります。赤い部分がたぶん問題。
 Scanner の report 機能で出力した pdf だな ... 全部誤検知だった。
 そもそも Scanner は利用規約上は禁止してる。
報告のコツ
1. 概要として「どこ」で「なに」を見つけたか書いてある。
2. 再現手順が箇条書きなどで見やすい。
3. PoC や payload が書いてある。
4. 脆弱性を悪用したことで発生する Risk が書いてある。
5. 修正案が書いてある。
報告で入れるべき要素、トップ5
なぜコツが必要なのか
 報告者
 早く処理して欲しい。
 運営
 早く処理して報告者に応えたい。
実は同じ方向を向いている、でもしんどい現実がある
なぜコツが必要なのか
 報告者
 早く処理して欲しい。
 運営
 早く処理して報告者に応えたい。
 でも現実は結構手間がかかる。( ここを改善するためにコツが必要 )
 報告内容の読解。
 PoC 作成。
 影響範囲調査や Risk 検討。
 影響ある開発者を説得。
 修正方法の検討と案内。
 修正確認。... などなどなど。
実は同じ方向を向いている、でもしんどい現実がある
コツをふまえた効果
 報告者
 早く処理して欲しい。
 運営
 早く処理して報告者に応えたい。
 でも現実は結構手間がかかる。( ここを改善するためにコツが必要 )
 報告内容の読解。
 PoC 作成。
 影響範囲調査や Risk 検討。
 影響ある開発者を説得。
 修正方法の検討と案内。
 修正確認。... などなどなど。
打ち消し線の部分やいろんな工数が軽くなる = 処理が早くなる
もう一度、報告のコツ
1. 概要として「どこ」で「なに」を見つけたか書いてある。
2. 再現手順が箇条書きなどで見やすい。
3. PoC や payload が書いてある。
4. 脆弱性を悪用したことで発生する Risk が書いてある。
5. 修正案が書いてある。
大事なことなので2回目
Thank you

LINE Security Bug Bounty Program の紹介