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

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日目後半は以上です。
お疲れ様でした。