CODE BLUE 2015に行ってきました(2日目:後半)

こんにちは、ひろかずです。

2日目:前半に続き、CODE BLUE 2015のレポートします。
ライブで書いているので、多少の誤字脱字、表記揺れはご容赦ください。

お品書き

1.MS Office ファイル暗号化のマスター鍵を利用したバックドアとその対策
光成 滋生 & 竹迫 良範
[Encryption][MS Office]

2.過去10年間のセキュリティ業界の失敗 -‐‑‒ 数百のサイバースパイ侵害から学んだこと
スンティン・サイ(TT) & チーエン・シェン(Ashley)
[APT] [Community]

=== ここまで前半 ===
=== ここから後半 ===

3.X-XSS-Nightmare: 1; mode=attack ～XSSフィルターを利用したXSS攻撃～
キヌガワ マサト
[short][Web][IE][XSS]

4.Windows 10 IoT Coreに対する脅威分析と実施するべきセキュリティ対策
和栗 直英
[short][Windows][IoT]

5.PANDEMONIUM: 動的バイナリ計測とファジーハッシュを使用した暗号アルゴリズムの⾃動識別
黒米 祐馬
[U-25][fuzzy hash][binary][dynamic analysis]

6.Master Canary Forging: 新しいスタックカナリア回避手法の提案
小池 悠生
[U-25][binary]

7.実⽤的な大規模ネットワークのディフェンスあるいは「Eierlegende Wollmichsau」の保護
トラヴィス・ケアロック
[Network][DevOps]

3.X-XSS-Nightmare: 1; mode=attack ～XSSフィルターを利用したXSS攻撃～

キヌガワ マサト
[short][Web][IE][XSS]

WebApplicationの脆弱性(特にXSS)を探すことが好き。
バグハンターで生計を立てている。
2014年でも登壇

IEのXSSフィルターを使ってXSSする手法とバイパスする手法を話す予定だったが、MSから待ったがかかって自重することにしたとのこと。

IEのXSSフィルターとは何か

• IE8から導入2009年
• Chrome、firefoxにも同様の機能がある

XSSフィルターとは

• リクエストの値とレスポンスから、危険条件にマッチすれば書き換える
• 例えば、レスポンスにスクリプトタグが含まれていれば、#を挿入する
• 条件にマッチすればユーザの動的生成部分を書き換えるので、正規のコードが破壊されることもある

# の挿入を考える

• <script>タグが破壊されると、スクリプトタグ中のXSS防止措置を適切に施した文字リテラルがそのまま実行される...とか
• その他のタグも破壊されると動作が大きく異なってしまう。
• XSSのない普通の構造ページが、XSSの脆弱性を持つようになってしまう

DEMO

<a hr#f の場合
http://hoge.com/?<a hr#fにすると、HTML内のリンク <a hraf が壊れてしまう。
<meta ch#set や <li#n hraf や <script>も同様

XSSフィルタは、誤動作し易い(最大限配慮はされているが)
ブラウザ側も承知の上で導入している。

X-XSS-Protectionヘッダ

保護機能を制御できるレスポンスヘッダ

• 0：無効：対応ができているので、フィルタは不要
• 1：有効(部分書き換え)：推奨しない
• 1;mode=block：有効(表示させない)：念の為に保護を受けたい

1;mode=blockは安全？

• 内容が推測できる（スクリプトを使用しているページだと判る）
• が、直接スクリプトが実行されることはないので、有用

0にするのはどう?

• 製品動作を優先して不適切に切っていると思われてしまう可能性

1は危険箇所だけ直してくれるように見えるので、魅力的に考えられる

• が、それ自体が罠

最後に

XSSフィルターの改善に期待するが、安全に倒す必要があるので、デフォルトで行くのは考えもの

4.Windows 10 IoT Coreに対する脅威分析と実施するべきセキュリティ対策

株式会社FFRI 和栗 直英
[short][Windows][IoT]

現在は自動車Securityの研究を担当されてるとのこと。
強面にみえるが、紳士だそうです。

WIndowsはEmbeddedからIoT Coreへ

IoT Coreの標準的なSecurity

• メモリ破壊系は対応している
• Windows Update、Defenderは対応していない
• IEとedgeは入っていない
• .NET Frameworkのサブセットをサポートしているがデスクトップとは異なる
• タスク管理機能はあるが、デスクトップとアーキテクチャが違うので既存の影響を受けにくい

ネットワークサービスの調査

21:FTP

• スタートアップファイルに記述。
• 認証不要。ftpd.exe内に認証ロジックそのものがない。後から認証させることもできない
• スタートアップに入っているので、起動時に必ず動く)

4020:tcp

• NMAPヴィジュアルスタジオ2015のリモートデバッグができるようになってる。
• デフォルトで認証不要

WebUI標準搭載

• ベーシック認証
• REST APIによる一部操作も可能
• アプリのデプロイやデバイスの一部設定はできるけど、Securityに関する設定はできない
• WebからOSコードが実行できない対策はなされている

攻撃シナリオの調査

機密性

• 盗聴、パスワードクラック窃取
• WebUIはデフォルトでHTTPベーシック認証

完全性

• スタートアップファイルの改ざん
• FTPからアップができてしまう(事実上何でも実行できる)

可用性

• DoS攻撃
• 連続的なRESTAPIの実行

これらの脅威はワーム型のマルウェアの影響が高い
ポートスキャンやICMPによるネットワーク上のデバイス探索でデバイスを発見できる

対策

脅威の相関から機密性と完全性を担保することで軽減できる。

• インストール後にパスワードを複雑なものに変更すること
• HTTPS通信の有効化(ネットワークに既に侵入されている場合、HTTP通信だとパスワードを窃取される)
• スタートアップファイルを編集し、FTPを起動させないようにするorルート・ディレクトリを変更する（デフォルトはCドライブ直下）
• リモートデバッグ時の認証を有効化する
• ファイアウォールのカスタムでインバウンド、アウトバウンドを設定する
• ファイアウォール設定はスタートアップにも書ける。
• ファイアウォール設定は、デスクトップ版WindowsのCLIと同じやり方で設定可能

まとめ

IoTプラットフォームとして期待できるが、Security設定のカスタム対応が前提(ファイアウォールは手間がかかる)
現在はWindowsUpdateに対応してないので脆弱性の対応が大変

最低限のSecurityはプラットフォームで担保すべきでは？

• ラズパイはホビー用途。すべてのユーザがSecurityを理解しているか？
• 無償、ラズパイ2、Embeddedの後継なんだから

質疑応答

パスワード変更を効率的に変更してデプロイするには？

• PowerShellに対応しているので、それを使うことになると思う。

ロギング(出方や転送)に癖はあるか？

• ロギング機能があることは判っているが、詳しくは調査していない。

5.PANDEMONIUM: 動的バイナリ計測とファジーハッシュを使用した暗号アルゴリズムの⾃動識別

黒米 祐馬
[U-25][fuzzy hash][binary][dynamic analysis]

学生やってます
Securityキャンプの講師
ブラックハットパイソンの査読協力
AVTOKYOのスピーカー

マルウェアが用いる暗号アルゴリズム

• バンキングトロイ：設定ファイルが暗号化（鍵は本体にハードコード）今回の対象
• ランサムウェア：感染hostsのファイルを暗号化（鍵はサーバからDownload）

バンキングトロイによる暗号化の利用

• Zeus流出から亜種が発生。最近は別種も発生。

算術・ビット演算に着目して暗号化処理が含まれる箇所を抽出する
ループ構造に着目して暗号化処理が含まれる箇所を抽出する

LLVMを用いて解析妨害機能の回避する

解析妨害機能

• サンドボックス環境を検出して、停止・自己消滅する
• 難読化による隠蔽
• マルウェアの目的は限られているが、手段は多様化。計算爆発がやってくる。
• 既存の確認手法が使えなくなっていく。

解析プラットフォームPANDAはQEMU上で動作
OS~マルウェア間との1対1の中間LLVMを見ることができる。

• 難読化コードの除去：無意味なコードの羅列も、実際にやり取りされている内容をLLVMにて見ることができる。
• QEMU低速だが、仮想化環境なので微妙に変えることで、サンドボックス回避機能を回避する。
• 微妙に環境が異なることでの解析の揺れは、ファジーファッシュで吸収する。

解析妨害機能の回避

• マルウェアが期待する待ち時間をsleepで待つ等して、サンドボックス環境だと悟らせない。
• マルウェアが期待するクロックを消費しているように見せかけて、サンドボックス環境だと悟らせない。
• 条件分岐の際は、スナップショットを取って、作ったクローンでそれぞれの分岐を試す。

テイントタグ途切れによる解析妨害の回避

• LLVM最適化で回避

課題

暗号鍵の抽出ができていない
未知のマルウェアに対応できていない
LLVMではcode virtualizerに対応できない(マルウェア自体が仮想環境で動いている)

6.Master Canary Forging: 新しいスタックカナリア回避手法の提案

小池 悠生
[U-25][binary]

16歳。もっと凄い16歳もいるので驚かないで。
exploit大好き
CTFにハマってたが飽きてきたのでそろそろ引退

動機

ROP大好きでStack based buffer over flow大好き
Stack canary大嫌い

Stack canary

• BOFに因る攻撃阻止が目的
• リターンアドレスがStack canary領域に書き込まれたことに反応してプロセスを殺す。

種類

ランダムcanary

• 基となる値がわからないように、プロセス起動時に値をランダムに決める

Terminator

• \0等を含まれるようにすると、元の値が推測し辛い(null文字を使ったBOFに有効)

これまでの回避手法

_stack_shk_failを避ける
canaryをリークする(canary値を知ってれば回避)

回避方法の提案

そもそも、マスターcanaryを書き換えてしまう

攻撃手法は、講演資料を参照してください。

評価

使いづらい(2つの脆弱性を使用する必要がある)
Heap Based BOFできるなら、これだけで攻撃可能
Stack canaryがまだ完全でないことを示すことができた。

対策

ランダムXOR canary(Windowsで実装済み：乱数を使ってエントロピーを高めている)
ガードページを設けてしまう(書き込めない領域)

7.実⽤的な大規模ネットワークのディフェンスあるいは「Eierlegende Wollmichsau」の保護

トラヴィス・ケアロック
[Network][DevOps]

SOUNDCLOUDのSecurityエンジニア
テクニックをポジティブに使うことを話したい
ネットワークディフェンスについて語る

万能の解決策はない。
組織のニーズによる。
どのように構築していくのかを考えていく

何がしたいのか？

• ハッカーの侵入を止めたい
• 現実的ではない

先ず、インフラをより詳しく理解することから始める。

• リスク分析を完全な形で行っていることが大事。

ノード同士がフラットにつながったネットワークを想定してみる。
ノードには何があるか

• PC、NW機器、クラウドコンポーネント、VPN、マイクロサービス、DBクラスタ、スケジュールタスククラスタ、DNS、LB...
• これらのノードは悪意があるものではない(ないものにしなければならない)

これまでは、サーバはペットのように手間がかかるもので、常に稼働させることを是としてきた。

• パッチを当てて動かなくなることを恐れてきた。

今のサーバは、家畜のように考えられている。

• 何か問題があっても切り捨ててビジネスを続けていけばいい。
• 家畜は表現として正しくない(「Eierlegende Wollmichsau」「羽毛を持ち・卵を生む豚」ものと表現が正しい)
• 様々な処理を行う変化し続けるものということ。

ゴール

ネットワークトラフィックの探索
フォレンジック敵祥子と長時間解析

ネットワークトラフィックの探索

どういうIPがあり、どのポートが開いていて、どの程度のワークロードを流すか
トラフィック規制(必要な通信のみを通信許可するIN/Out)
DBはインターネットからアクセスできるべきではない

フォレンジック的要素と長時間解析

様々なログがある

• ネットワークlog、IPS/IDSlog、ファイアウォールlog、DHCP・DNSlog
• ローカルlog、auditd等のアプリケーションログも必要
• cloudtrail,s3logも必要

データの完全性が求められる

• 矛盾はない？
• 独立性
• 簡単に壊せるか
• 信頼性
• 保持ポリシー：物によって異なる(個人データは一定期間しか持てない法律もある：ドイツ)

様々な形があるのでlogの正規化が必要

• タイムスタンプは重要だが、タイムゾーンとフォーマットが異なるので合わせる必要がある。
• 送信内容：どのような内容であるかを判るようにする
• タグ付け：送信元IP等が判るようにする
• タイプ分け：ポート番号は整数なので計算できる。演算できるもの、文字列とタイプ分けする

log→ElasticSearch(分散型データストレージ：形を変える)→kibanaで分析(ダッシュボードを作る)

• ElasticSearchは強力でパワフル
• ポイントは様々なソースをパイプラインの終端まで届ける事が必要
• 今はコーディングが必要だが、ライブラリがたくさん出てるので活用して欲しい。

何をtargetとするか

• 組織の中で最も大事なものを定めないといけない。(DBクラスタ,財務データ...)

正しい状態は、何が何につながって居るべきであるのかを知る必要がある

• DevOpsエンジン(Chef、Puppet、Ansible)から情報は集められる
• DNSを参照するクエリー
• ソースコードを管理するリポジトリ(Git)

スタートアップは、構成管理が難しい

• マニュフェストファイルを用いることで、それぞれの要素間でのマッピングができていく。
• はじめは、手動で見ていくことになるが、最終的には自動化していく。

logライン(IP:ポートのSource/Destinationの紐付け)が見えてくることで、その範囲から外れたものを異常と捉える。

• 誤検知・過剰検知：よりよいクエリをデザインすることを考える。(and,or,ホワイトリスト,チューニング)
• ポリシーとガイドライン(アクセス権限：Read/Write権)を整備して、クエリしやすいデータにしていく。

アラートアクションのガイドラインを作る必要がある（メールのみ、PD通知、電話かける）

• アラートはデータとして捉える。
• 5分以内に複数起きたら別のアラートにするような仕掛けが必要。
• 攻撃者のKillチェーンを考慮する。(データベースアクセス、深夜のアクセス、外国からのアクセス)
• 外部サービス(所在地情報)へアクセスすることで、アラートであるか否かの判定の助けにする。

アラートが多すぎるとoperatorはアクションが取れなくなる。

• どういうアラートをoperatorに出すかを検討することが大事。
• ダッシュボードをカスタムして見せるべきものを選定する必要がある。

何を異常とするかを定める

• アラート管理
• 調査を簡単にするクエリツール
• ヘルプの整備

これらがきちんと動作するのか、テストを自動化する。

• 異常を想定通りに検知するかのテストを行う必要がある。

システムそのものが堅牢であるか、再構築ができるのか

データの活用方法

• 次のステップは機械学習(異常を見つける。アノマリを見つける)
• ネットワークへの
• logは何が起こったのかを得ることができる。

まとめ

防御するのは大変だが、環境をコントロールできるのはあなた自身である。
ハッカーが侵入してきても、あなたがゲームマスターである。
あなたの環境を構築するべきで、使われるものは新しいものであるほうがいい。

質疑応答

logはデバッグからSecurityのよるような重要なものまで大量にある。
優先順位を付ける必要があると思うが、知見はあるか

• すべては必要ではない。何を入れるかを選別する必要がある。
• DNSログは、ノイズが多く扱いづらい。
• たくさんあることが望ましいが、大量に出るので処理しきれるようにする必要がある。

ログ収集分析基盤は、OSSを作るべきか、自分で作るべきであるか

• OSSには素晴らしいものglobe等のNW解析ツールや良いライブラリがたくさんあるので活用すべき。
• カスタムコードは、必要最低限にするべき

SOUNDCLOUD内でログ解析するにあたって、良い組み合わせはありますか

• 機械学習は、Scalaのカスタムコードを使っている。
• 現時点では、STPライブラリを勧めることはできない
• 機械学習は、まだ実用段階ではない。十分な信憑性はない。検証が必要
• 先ずは、守るべきものを特定することが必要。

内部犯行について早期検知、追跡はどのようにしていけばよいか

• Securityの人間は誰も信用しない。
• SSHアクセスは注目するべき。
• 実際のテクニック：一般的な転送量を把握しておき、閾値を超えることを検知する
• AWSではVPC Flow Logsをリリースした。これを使って先ほどのテクニックを使える
• EUではsafe haber条項がある(個人情報は、発生国から持ち出せない)
• 個人情報の取り扱いは国ごとに違う。クラウドサービスを使用するにあたっては、どのデータがどこにあるのかを把握して、法務部門と相談する必要がある。

おわりに

事務所不在の間、フォローしてくれたメンバーと、快く行かせてくれた上司と会社・周辺チームの皆に感謝です！

2日目後半は以上です。
お疲れ様でした。