Webサービスの脆弱性と
報奨金制度

2018-06-13 TSG 第2回脆弱性ハンティング分科会 発表資料

@hakatashi

※博多市はWebセキュリティの素人です!

このスライドは適当に調べながら書いたので
鵜呑みにしないでください

TL;DR

Kinugawaさんのブログ/スライドを読もう!!!

脆弱性報奨金制度

(Vulnerability Reward / Bug Bounty)

  • サービスの管理者が主催する制度の1つ
  • Webサービスやソフトウェアの脆弱性を報告すると、
    内容に応じた報奨金を受け取ることができる
  • 報奨金の額は$100,000単位になることも
  • 国内だと主にサイボウズが首魁となって始めた

脆弱性を探す場所

弊社でもやってます

BugBounty対応側から
見た知見など

CTFとかでよく見る
Webサービスの脆弱性

  • XSS
  • SQLi
  • CSRF
  • Timing Attack
  • Race Condition

実際に報告されることが多い
Webサービスの脆弱性

  • Cross-domain Referer leakage
  • Open Redirect
  • Click Jacking
  • Insecure Direct Object Reference

実際に報奨金が出た例

  • 投稿された画像に位置情報が残っている
  • 一度発行されたセッションが永久に破棄されない
    • セッションハイジャックされると、
      ずっとハイジャックされたままになる
  • パスワードを変更しても
    他のセッションが無効化されない
  • セッションのクッキーが http only になっていない
  • IDN homograph 攻撃が可能
  • クリックジャッキング

もっと複雑で
面白い脆弱性を見つけたい!

もっと複雑で
面白い脆弱性の例

https://github.com/ngalongc/bug-bounty-reference

に実際に見つかった脆弱性がいっぱい載ってるので参考に

ユーザ入力を使った
正規表現から生じる
DOM based XSS

LINE Bug Bounty Program: $500

var template = '<img src="https://hoge.com/{{id}}.png">';
var re = new RegExp('{{' + key + '}}', 'gm');
var safe = escapeHTML(value);
template = template.replace(re, safe);
document.body.innerHTML = template;

key, value に任意の文字列をURLから入力可能

PoC

key = '|(.)h|';
value = '$1a$1onerror%3Dalert(1)//';

var re = new RegExp('{{' + key + '}}', 'gm');
//=> /{{|(.)h|}}/gm

'<img src="https://hoge.com/{{id}}.png">'
  .replace(re, '$1a$1onerror=alert(1)//');
//=> '<img src="a"onerror=alert(1)//ttps://hoge.com/{{id}}.png">'
  • 正規表現の | を用いることで{{}}以外の部分にマッチ
  • テンプレートの "h の部分を置換
  • $1 を用いることでHTMLエスケープを回避

Google Issue Tracker
における複数の脆弱性

Google Vulnerability Reward Program: $15,600

脆弱性1

Google Issue Tracker の機能の1つとして、

buganizer-system+<componentID>+<issueID>@google.com

にメールを送ることでスレッドに投稿できる

→ @google.com に送信されたメールを閲覧できる

脆弱性1

  • GoogleのSlackチームへのRegist
    • なぜか失敗

脆弱性1

  • Googleアカウントの作成
    • そのまま登録しようとしたら弾かれるので、
      別のアドレスで登録したあとアドレスを変更することで回避
    • 成功!
      • Google社員の特権を持ったアカウントを作成できた

脆弱性2

  • 権限を持たないIssueをスターすることができる
    • そのIssueに関する通知をメール経由で閲覧可能

脆弱性3

  • 権限を持たないIssueを指定することで、
    Response Body からIssueの詳細を閲覧できる
  • JSファイルに記述されているAPIエンドポイントを
    地道に調べていってみつc
POST /action/issues/bulk_edit HTTP/1.1
{
   "issueIds":[
      67111111,
      67111112
   ],
   "actions":[
      {
         "fieldName":"ccs",
         "value":"test@example.com",
         "actionType":"REMOVE"
      }
   ]
}

不適切なブラックリスト
検査による
CRLFインジェクション

Twitter Vulnerability Report on HackerOne: $3,500

脆弱性

  • ?reported_tweet_id=hoge なる
    パラメーターを渡すことでレスポンスに
    Set-Cookie: reported_tweet_id=hoge が反映される
  • ただしhogeの部分はフィルタがかけられており、
    CRやLF, ASCII外の文字などは除去される

脆弱性

  • Unicode文字を利用して、CRLFをインジェクション可能
    • UTF-8の入力に対してフィルタを適用したあと、
      (なぜか) UTF-16に変換してからさらに除去フィルタを
      実行するという仕組みだったらしい

脆弱性報告の際のTips

  • PoCの動画があるとよりよさそう
    • Google VRP では動画でのPoCの撮影を推奨している

便利リンク

END

脆弱性は
どうやって見つかるか

参考資料: https://www.ipa.go.jp/files/000064918.pdf

Made with Slides.com