こんにちは、ひろかずです。
1日目:前半に続き、CODE BLUE 2015のレポートします。
ライブで書いているので、多少の誤字脱字、表記揺れはご容赦ください。
お昼出ました。松花堂弁当でした。
エネルギー充填して、いざ後半へ。
お品書き
0.挨拶
東京電機大学教授 佐々木良一(実行委員長)
1.基調講演：シンギュラリティがやってくる
神戸大学名誉教授 松本卓也
2.医療機器のセキュリティ
フローリアン・グルーノ
[Medical][IoT]
=== 以上は前半 ===
3.Firefox の倒し方
西村 宗晃 （にしむねあ）
[Web][Firefox][OSS][CORS]
4.中国における情報セキュリティの新たな免疫システム
シャオドゥン・ファン
[bug report][Community][Zero-day market]
5.日本の組織をターゲットにした攻撃キャンペーンの詳細
朝長 秀誠 & 中村 祐
[APT][reverse engineering]
6.現実世界での機械学習によるアノマリ検知システムの構築と回避
クラレンス・チオ
[Machine Learning][IDS]
3.Firefox の倒し方
西村 宗晃 （にしむねあ）
[Web][Firefox][OSS][CORS]
西村さんは、ブラウザのバグハンターだそうです。
ブラウザの脆弱性がどのようなものがあって、どのように効率的に見つけるかという内容
実績(本業の他に)は、23件/年の脆弱性を報告している(700万くらいの報奨金)
脆弱性の発生パターンに共通点がある。
開発者にもフィードバックされておらず、同じような脆弱性が再び作りこまれる。
パターン1.仕様の実装漏れ
IETFやW3Cの標準化団体が策定していて、機能の実装要件が記載されている。
- 仕様書は誰でもダウンロード可能
- 仕様書には機能実装によるセキュリティリスクと対処方法が記載される
- WebRPCは悪用すると、マイクやカメラでのぞき見できてしまう。
仕様書に書かれている要件がたまに実装されていない
- テスト不足(異常系が不十分)
- 仕様書に沿ってテストをかけば脆弱性を見つけられる(120万くらいはこれ)
実例1
Fetch API(HTTPによる非同期通信)
- 仕様書には各パラメータに禁則事項が指定されている
- メソッドはTRACE禁止とか、HostやCookieなどの指定禁止とか
脆弱性を見つけたい人は、新しい機能について、仕様書に基づいたテストをしてみると良い。
実例2
HTTPリダイレクトの実装不備は、ブラウザ脆弱性の温床
- リクエストに指定したオリジンと、応答を返すオリジンが異なる場合がある。
- セキュリティサンドボックスを回避
Service workersにおけるcacheデータのオリジンの取り扱い不備
- Service workersは、ブラウザのバックグラウンドで動くブラウザ~オリジン間の中継機能(cacheを制御)
- 攻撃サイトにアクセスした後、FaceBookとかにリダイレクションされると、攻撃サイトの内容としてcacheされる。
- キャッシュされたdom情報をリダイレクション元とリダイレクション先で同じものとして扱ってしまう。
リダイレクト後のURLは、Sensitiveな情報(どこを閲覧した)を含むので、表示されてはいけない。
エラーMSGにも表示されてはいけないことが仕様書に定められている。
パターン2.CSPの取り扱い
すみません＞＜
詳細はアップロードされた講演資料を参照してください。
パターン3.
ブラウザは、セキュリティ検証をDOM/Web APIでオリジンの検証と、Networkモジュールはサーバの検証とそれぞれ別に行う。
この性質を利用する。
実例
日和見暗号のハンドリング不備を突く
日和見暗号とは
- http:の通信をTLSで暗号化する(国家による大規模な盗聴の対策)
- サーバ認証せずにTLSで暗号化(しないよりマシ)
内容とシーケンスはちょっと複雑なので、資料を直接参照してください＞＜
脆弱性の見つけ方
新しい機能で、過去の脆弱性を確認すること
- mozillaのセキュリティアドバイザリ(過去脆弱性)
- Firefox開発者向けリリースノート(新機能の通知)
- コミットログを参考に脆弱性探し(書き方に癖がある。Bugzilla詳細情報にアクセス出来ないものはセキュリティ脆弱性と見做せる)
- Mozillaセキュリティチームの行動を追跡する(バグ情報の開示は彼らがハンドリングしているので、Activityを見て、過去に隠蔽された情報の開示を追跡することで、報奨金が支払われた情報がトレースできる。これをパターン化する)
Firefoxの脆弱性対応の特徴
- 対応が早い(早いものは1ヶ月、遅くても2〜3ヶ月で修正。緊急アップデートもある)
- 透明性が高い(報告から修正されるまでの過程をBugzillaで閲覧できる。説明もきちんとなされる)
最後に
本発表は、米国Mozillaチームと調整の上で実現しています。
4.中国における情報セキュリティの新たな免疫システム
シャオドゥン・ファン
[bug report][Community][Zero-day market]
中国以外で、このようなトピックを話すのは初めて。
日本と中国で考え方も違うかもしれない。
中国のIT発展とバックグラウンドをなるべくはっきりと伝えたい。
百度のセキュリティチームの元リーダー
Wooyunのセキュリティコミュニティの創設者
ホワイトハッカー(思想は理想主義、ハッキングは実用主義)
考え方のベース：セキュリティをどのように見るか(企業として、コミュニティとして、大規模インターネットとして)
共有するAPT、ハッキング技術はない(あまり重要ではない)
重要なのは、ハッキングで破壊して、理想なものと作ること
- 自動車はハッキングできる
- だが、人は脆弱なパスワードを止めることはできない。
中国のインターネット環境
10億人以上のユーザが、朝から晩まですべてのActivityがインターネットを流れている(ニュース、買い物...etc)
この中にブラックハッカー(黒い産業)が存在し、膨大なユーザ、通信、オープンな環境から、多額の利益を上げている。
超短期間で、Service、Applicationが爆発的に増加しており、会社も毎月2000社以上のペースで増えている。
政府は、すべての人のイノベーションを推奨している。
企業は、先ず生き残ることを考える(セキュリティを考えない)
ユーザ数が大きくなった時に初めてセキュリティを考える。
爆発的普及に対して、規格とメカニズムが相対的に不足している。
整備された管理の方法がないことが中国の現状。
家の鍵でさえネットワークに繋がるが、インターネットに対するセキュリティへの投資に十分に考えない。
ホワイトハットは、十分な給料を得られない。
企業の顧客は、セキュリティを理解していないので、企業は注意を払わない。
セキュリティは目に見えない。(水の安全と同じ)
民間セキュリティコミュニティの共有や議論の不足している。
貧しく、収入が少ない人間が、ブラックハットを志す。
ブラックハットは、コミュニティの繋がりが強い傾向がある。
敵は多くなって、仲間が少なくなる。
セキュリティは、一つの企業の問題ではなく、全体の問題である。
一人が努力しても企業は良くはならない。
インターネットは制御不能
一つの技術で完結しない。
一つ二つの企業が完璧に対応しても解決しない。
別のやり方
- 技術は重要であるが、解決の手段ではない。
問題の核心（閉鎖的な環境）
- ユーザ(閉鎖的で本当のリスクに気づかない：メディアの情報を理解できない：コンピュータスキルの問題ではない)
- 企業(ユーザが気づかない領域に投資しない)
脆弱性公表の従来のプロセス
情報は公開されない。
- 最初に脆弱性が企業に伝えられる → 企業は確認して修正 → 情報は公表しない
情報公開の責任が必要
変化
MS/Apple/adobe
- 閉鎖システム、端末セキュリティ(個人が責任、個人の所有権)
Google/Amazon/Apple
- 公開システム、公開セキュリティ(企業の責任)
希望
データの所在を企業にすることで、企業の責任にてセキュリティを守ることになる。
ユーザは自分のデータに関心を払う。
→ 企業にセキュリティを守る動機を与えるということ。
情報公開プロセス(改)
- 最初に脆弱性が企業に伝えられる → 企業は確認して修正 → 企業は迅速に公表 → 情報は共有される → 各企業は共有された情報を基により多くの潜在的な問題を回避できる → ユーザは、公開情報を基に潜在的なリスクを見つけるかもしれない。
現在の環境下での業界のセキュリティ訴求に従う。
ユーザーが自分のセキュリティを認識することで、生態としてセキュリティを確保するサイクルに進んでいける。
成果(wooyun)
セキュリティにおけるGitHub
脆弱性を見つけたことを公表する場の提供(個人のレジュメになり、共有できる)
インセンティブは報酬ではない。
ホワイトハットの訓練センターのようである(講師のいない学校)
10,000人以上のホワイトハットが100,000個以上の脆弱性を見つけている、
重要セキュリティ脆弱性の修正サイクルが2〜3年から2週間に短縮(企業単位ではもっと短くなった)
高いリスクを負うユーザは、その理解をし、企業に修正を促す。
ユーザーの声は企業より大きい。
結局何をしてきたか
健全なホワイトハットシステムの構築(ホワイトハット＋ユーザ＋企業＋政府)
直接声の届かない企業には、政府が仲介する。
生態として、セキュリティを保護できる形
質疑応答
生態の構築には、ユーザへの教育が必要だと思うがどうしたか？
- 多くのユーザは何も感じていない。膨大なユーザの中から、必要と感じるユーザに参加してもらっている。
- 我々は、常に情報発信を行っていく。
脆弱性の発見が、取り締まりにつながったことはあるか？
- 特にない。
- ネットの発展は早く、法律が追いついていない。
- 実際に脆弱性を使って窃取したということが分かっていないので、公表した脆弱性を基に取り締まられたことはない。
人民解放軍はグレートファイアウォールを有しているが、関係あるか？
- 関係性はない。偏見があると思うが、取り払って欲しい。
- 百度、アリババ、中国版Facebook等大きな価値を提供している。そのようなことにこだわるべきではない。
ホワイトハットと給与(社会的地位)が結びつかないという点は？
- 業績に貢献(発展)することが前提となっている。
- 社会の発展が、ホワイトハットの給与向上の前提になっている。
- ホワイトハットは、マスコミやネットユーザを通じて認知されている。
この取組は斬新だが、大変だったことは？
- ブラックハットからの攻撃で3日間インターネットが見れなかった事があった。
5.日本の組織をターゲットにした攻撃キャンペーンの詳細
JPCERT/CC 朝長 秀誠 & 中村 祐
[APT][reverse engineering]
標的型攻撃が題材。
実際にどのような攻撃を行うのか事例を紹介。
※ 詳細な攻撃手法や使用されるコマンドなどは講演資料を参照してください。
発表者の方は、マルウェア解析、フォレンジックがバックグラウンドとのこと。
2015年4-9月の対応件数(総数130件)
- キャンペーンA：93組織：Emdiviを用いた攻撃
- キャンペーンB：4組織：ハイレベルな攻撃グループからの攻撃
キャンペーンA
マルウェア型(標的型メール、医療費メール、水飲み場型)
初期感染活動
アイコン偽装：医療費、健康保険：通年発生
文書ファイル脆弱性下悪用：CVE-2014-7247：脆弱性対応で終息
FlashのDrive by Downloadを悪用：活発
傾向としては、MSの標準機能を使用する。
メールアカウント情報の収集を行う(フリーメールアカウントを使っている)
ネットワークドライブ、ファイルサーバの探索
- netuse, netstat, nbtstat,dir(再帰的、日付別でソート)...
感染端末が、アクセス権で目的情報に到達できない場合、MS14-058を悪用して権限昇格した後、パスワードダンプ → MS14-068を悪用してドメインadminのパスワードダンプ → ファイルサーバにマルウェアを配布
SYSVOL内のスクリプト調査(ログインスクリプトにパスワードが書いてある場合)
パスワードリスト攻撃
- 10-30程度のパスワードリストとDomain Adminのユーザリストを用いてログオン試行
- 意外と成功する。
Builtin Administratorのパスワードが同じ場合
- ドメイン環境の悪用ができない場合に有効な手段
- パスワードハッシュorパスワードをダンプする
ファイルサーバにマルウェアを置く
- ほかに手段がない場合に効果的
- 回覧板や当番表を狙う
- 小規模、非ドメイン環境で有効
WPADの悪用
- デフォルトで有効
- 自動構成スクリプトをDHCPサーバからDownloadするか所定のURL(※講演資料参照)からDownload
- WPADを構成していない環境で有効
色々なEmdivi(一部抜粋)
- Emdivi(t17)が搭載しているコマンドは10程度だがアップデートされる
- Emdivi(t20)は、コマンドが最大41搭載しているものがあった。
- usp10jpg：一日に一回通信するDownloader：感染していない端末に感染する傾向：殆ど通信しないので検出し難い
- BetinX：インターネットに接続できない端末に有効：コマンドをプロキシーする
- FStatus：あまり見かけない。何らかの理由で選ばれたもの。：ボット機能を有する
分析ツール
emdivi_strign_decryptor.py
- T17,19,20に対応
- Emdiviの文字列を復号化して検出
分析ツールは、Githubに公開されてます。
キャンペーンB
ATP17
- ネットワークに侵入する際に用いる手法
- 標的型メールは使わない
Drive by Download（水飲み場攻撃）
- 攻撃サイトに改ざんされたサイトにアクセスすると、攻撃サイトにリダイレクトされて、Downloadさせられる。
- 攻撃サイトには、対象企業のIPアドレスを許可するよう.htaccessに記載されていた。
- この攻撃サイトは、ゼロデイ攻撃が仕込まれていた。
アップデートハイジャッキング
自動アップデート情報を改ざんする手法
- アップデートサーバのアップデート情報を改ざん
- 偽アップデート情報を受け取ったアプリは、偽サーバからマルウェアをDownloadする。
アップデートサーバのファイルを改ざんしない方法
- iptablesを改ざんして、攻撃サーバへアクセスを向けてしまう
- 通信先ポートは53(TCP)を狙う
- iptablesは保存しないので、痕跡が残らない。
ドメイン名ハイジャッキング
- NSレコードを書き換えてしまう
- レジストラ、レジストリ、DNSサーバを書き換えてしまう。
- iptableで特敵クエリのみDNSサーバへ転送する
- 特定のサブドメインを含む通信のみ処理し、その他のDNSクエリは正規サーバに転送してしまう。
マルウェアの特徴
- 侵入と潜伏で別のマルウェアを使用する
- 証明書で証明されている場合もある(日本や韓国の組織)
- 詳しい名称と使用するコマンドについては、講演資料を参照してください。
mod_rootme
- apacheのモジュール。キーワードを送ることで起動する。
分析ツール
atp17scan.py
- Volatility Plugin
- メモリダンプからマルウェアを検知
- マルウェアの設定情報を抽出
分析ツールは、Githubに公開されてます。
分析センターだより で検索
質疑応答
atp19ってどんなの？
- HTTPボット
- 侵入で使われたことがないので、侵入後に使われるものと思われる。
6.現実世界での機械学習によるアノマリ検知システムの構築と回避
クラレンス・チオ
[Machine Learning][IDS]
機械学習は使いやすくなってきている。
その問題を明らかにしていく。
適切な知識がないと、セキュリティの落とし穴(無用の長物)になる。
アノマリ検知 vs 機械学習
ヒューリスティック/ルールベース：予測学習：機械学習
侵入検知は、気づきたいということ。
Gmailは、優れた機械学習を持っていて、スパムを検知している。
クレジットカードが盗まれた時に、機械学習で異常を検知する。
アクセスログの出力傾向を分析する。
デバイスの入出力状況を機械学習で見て、BOTか人間かを区別する。
機械学習の技術は閾値/ルールベースのヒューリスティックと比べてなぜ魅力的？
攻撃者はスロットルがかかるポイントを見ていて、回避しようとする。
機械学習は、時系列的にトラフィック・パターンをみて判断していく。
モデルを動かしておいて、人の介在を減らせる。
でも、銀の弾丸にはならない。
閾値/ルールベースのヒューリスティックの魅力
理由が明確で理解しやすい。
シンプル
ある程度動的にしていくこともできる。
機械学習は、ビジネスの支援ツールとして好評(ECサイトのレコメンドエンジン)
モデルに近ければ、効率的におすすめできる。
期待値を設定する
機械学習＋アノマリ検知の大問題点
たくさん研究されているのに、現実世界で成功したシステムはあまり多くないのはなぜ？？？
アノマリ検知：新規の攻撃を発見(見たことないものを見分ける)
従来の機械学習：パターンを学習して、似たものを見分ける。
→ アノマリ検知は、アノマリであるもの/ないものを両方学習する必要がある。
アノマリ検知と機械学習の相違点
- 他の学習Applicationと較べて誤検知が多い
- システムが間違えたら
本当に困ったことになる。 - アノマリ検知は、間違えるもの。偽陽性偽陰性が高過ぎるとoperatorは信用しなくなってしまう。
訓練データが不足していて、クリーンな入力データを作ることが難しい。
学習状況(モデル)は常に変化しているので、警告が出た理由の解釈が困難。
静的なモデルは、緩やかな変化では破綻してしまう。
評価の問題
- しっかりした評価体系を考案することはシステムそのものを構築するより難しい
- 機械学習は文脈に依存する。表面的に似ていても解決策は異なる。
攻撃者の影響
- 高度な攻撃者は、システム回避のために時間と労力をかけられる。
失敗するパターン
- 偽陽性が多すぎる
- 攻撃がない訓練データを見つけるのが難しい
- 深く考えないで使っていることでのミスリード(誤った学習)
- パラメータを変えると結果が逆転することを知らない
- モデルのポイズニング(チャフをばらまいて、誤判定に導く)
希望はないの？
- Applicationを理解して、何を使うのが正しいのかを考える必要がある。
- 時系列を生成
- 代表的な特徴の選出
- 正常モデルの訓練と調整
- 入力がモデルから外れたら警告
共通技術：クラスタリング
- モデルは重心(送信元IP等の集団)
- 値の集団の距離を見る
- どのように特徴を選ぶか(パラメータの最適化ではない難しさがある)
- 測長が少ないほうが効率的(分散は80~90%)がいい
どのように落とし穴を回避するか
- 脅威モデルを理解する
- 検知の範囲を狭める
アノマリ検知器
- 本当のポジティブ評価することが良いか？
- モデルの本日を見誤ると別の結果がでてしまう(形のつもりが色味で判定してた)
モデルを攻撃
- 偽陽性を多くすることでシステムを騙す
- 無意味なトラフィックを大量に流すことで決定境界を動かしていく。
- ゆっくり増やすことで茹で蛙にする
今日のアノマリ
- 改良されている
- 何をアノマリしたいのか
- 特徴や閾値を機械学習で出して、そこからアノマリに繋いでいく
- 他人のデータで更にアノマリしていくといいのでは
質疑応答
アノマリデータが不足していることが問題とのことであったが、ペネトレーションベンダーに提供してもらうのはどうか
- 本当にポジティブなデータであるか不明
- ネカティブデータだけでは不十分
- 正常性は狭く、異常性は広すぎる傾向がある
1日目は以上です。
お疲れ様でした。