Embed Size (px)
DESCRIPTION
平成 23年度 大学情報セキュリティ研究講習会資料
Citation preview
私立大学情報教育協会平成 23年度 大学情報セキュリティ研究講習会
VM/Cloud Systemの（技術的な）セキュリティ
産業技術総合研究所
情報セキュリティ研究センター
須崎有康 (Kuniyasu Suzaki)
Research Center for Information Security
本日のテーマ
• クラウドコンピューティングのセキュリティについて
– IaaSで使われている仮想化技術を中心にしたセキュリティの話
– 実習
• 仮想マシン上のメモリの覗き見– 動いているアプリケーションの推定
• 本日の話の素– 日経コンピュータ 2010/March/31
• 「護るが勝ち 仮想マシンに潜むセキュリティ問題」
• 情報処理学会誌 2010/12号 クラウドセキュリティ小特集• 「IaaS型クラウドにおける仮想マシンのセキュリティ」
アウトライン
• クラウドの仮想化技術の役割• 仮想化に対する各種の脆弱性/攻撃
– VM内(VM Internal)の脆弱性/攻撃• VM内の脆弱性をついてクラウドを攻撃する。
– VM間(Cross VM)の脆弱性/攻撃• VM間の脆弱性をついて他のVMを攻撃する。
• クラウド特有の問題• まとめ
Data Management•Lost (消去) provider’s matter •Leak (漏えい)•Erasure (削除) provider’s matter
Client•Key management
login, data, application•personal Identification•Software vulnerability •Component Integrity
Verified Boot by “ChromeOS”
Software Vulnerability・Hypervisor・Manage OS・System Configuration
User’s Responsibility
Security Guideline • CSA (Cloud Security Alliance)• Open Cloud Manifesto
Auditing Standard • SAS70• HIPAA
OS1
App1
OS2
App2
OS3
App3
MemCPU
MemCPU
MemCPU
MemoryCPU
Virtual Machine Monitor
Auditing•Digital Forensic•Log
Provider’s Responsibility
Internetman in the middle attack
Cross Site Scriptingphishing
Authentication
Formal VerificationIn the future
IaaS型クラウドコンピューティングセキュリティ概観
Cross VM・VM Isolation
VM InternalVunerability
& Attack
仮想化への流れ
Linux Windows BSD
Web CGI DB分散化：Distributed Computing2000年初頭
•マシンは安価で追加が容易(‘99 Pentimum IIIで1GHz)•サーバ毎に機能分割•メモリもCPUも固定
メモリ メモリ メモリ
CPU CPU CPU レガシーシステム
仮想マシンモニタ
Linux
Web
Windows
CGI
BSD
DB
仮想マシンモニタ
BSD
DB
仮想マシンモニタ
Linux
Web
Windows
CGI
BSD
DB
自動化： Autonomics System2008年以降•ライブマイグレーションにより負荷分散、障害時の移動が仮想マシン単位で可能•仮想マシンの複製も容易 移動 複製
・VMI (Virtual Machine Image)によりOSのインストールをせず
にコピーのみでインスタンスが増やせる
仮想化： Virtualization2006年以降
Intel-VT/AMD-SVMの出現 (‘06)OpenVZ(‘05-), Xen (‘03-)KVM (‘06-,Feb’07にLinux6.20統合)
•仮想マシンにより複数サーバを１台の物理マシンに集約
Linux
Web
Windows
CGI
BSD
DB
メモリ
CPUメモリ
CPUメモリ
CPU
メモリ
CPU
•プロビジョニングにより仮想化したメモリ、CPUに物理能力を動的に分配
•仮想化した総メモリサイズが物理メモリを超えるメモリオーバーコミット機能により柔軟に管理
仮想マシンモニタ
仮想マシン導入のガイドライン
• NIST Guideline, “Guide to Security for Full Virtualization Technologies”, Karen Scarfone, Murugiah Souppaya, Pual Hoffman– ガイドラインであり、技術的な問題点の指摘が
少ない。
• 仮想化の技術的問題点を中心に話します
NIST近くのレストランで2010/08撮影
アウトライン
• クラウドの仮想化技術の役割• 仮想化に対する各種の脆弱性/攻撃
– VM内(VM Internal)の脆弱性/攻撃• VM内の脆弱性をついてクラウドを攻撃する。
– VM間(Cross VM)の脆弱性/攻撃• VM間の脆弱性をついて他のVMを攻撃する。
• クラウド特有の問題• まとめ
仮想化に対する各種の脆弱性/攻撃
– VM内(VM Internal)脆弱性をついた攻撃1. 仮想マシン上のOS管理2. I/O Fuzzing攻撃3. メモリエラーが引き金になる脆弱性4. ランダムにならない乱数
– VM間(Cross VM)のVM間の脆弱性をついた攻撃1. 物理キャッシュを通した覗き見2. 仮想メモリの覗き見 (実習内容)3. 仮想ネットワークによるセキュリティ障害4. LiveMigration時のRootKit混入
注：ここでは発生確率・影響度は加味していません
仮想マシン上のOS管理 (VM Internal 1)
• 現在のクラウドではOSのインストール作業が無い！– ダッシュボード機能からメニューで作成
• VMI(Virtual Machine Image), AMI (Amazon Machine Image)
• （基本的に）インストール後は管理者権限譲渡やプライバーの問題があり、ユーザが管理– 長い間使われなかったVMIではセキュリティパッチなどの脆弱性対処が
行われておらず、攻撃対象となる
• クラウド＆仮想化ベンダーでもこの問題は認識しており、対策を提供
• VMIを直接扱うツール
– VMware Update Manager（VUM）
– Microsoft Offline Virtual Machine Servicing Tool
I/O Fuzzing攻撃 (VM Internal 2-1)• 仮想マシンの脆弱性を突いた攻撃
– 仮想マシンのデバイスを過剰に叩き、管理OS乗っ取りや悪意あるコードの挿入を行う
• Tavis Ormandy, “An Empirical Study into the Security Exposure to Hosts of Hostile Virtual Environments”, Google Report
• Peter Ferrie,“Attacks on Virtual Machine Emulators”, Symantec Report– ツール
• CRASHME: Random input testing • I/O fuzzing
– VMware, Xen での報告あり
– 対策は不要なデバイスを付けない
Hypervisor
CPU (Real Device)
VM (Virtual Device)
ManagementOS
Guest OS
Device DriverDevice Driver
smash!
I/O Fuzzing攻撃 (VM Internal 2-2)• VMWareのビデオデバイスの脆弱性 (Black Hat 2009の発表)
– CLOUDBURST A VMware Guest to Host Escape Story, Kostya Kortchinsky (Immunity, Inc.)
• SVGA_CMD_RECT_COPY バグ– フレームバッファはホストのメモリにmapされていた
• これでアドレスが判明する
• SVGA_CMD_DRAW_GLYPH バグ– バウンダリチェックをしていないので、 SVGA_CMD_RECT_COPY から得たアドレス
相対でホストのメモリが読み書きできた
Memory Leak
OverWrite memoryNormal behavior
メモリエラーが引き金になる脆弱性 (VM Internal 3-1)
• クラウドコンピューティングでは数万台を超える大規模なサーバ群から構成されるため、各デバイスの障害も半端でない
• ” DRAM Errors in the Wild: A Large-Scale Field Study” [SIGMETICS09]においてGoogleのサーバ群におけるメモリのエラーレートを報告
– 通常考えられている以上に物理的なメモリエラーが起こる
– クラウドコンピューティングではメモリ上の処理が多い
• メモリエラーを狙った攻撃
– “Using Memory Errors to Attack a Virtual Machine”, [IEEE Symposium on Security and Privacy’03]
• 悪意のあるコードにジャンプする仕組みをメモリ内に敷き詰め(スプレー攻撃)、メモリエラーを待つ
• この論文自体はJavaVMを想定しているが、仮想マシンでも同じ
メモリエラーが引き金になる脆弱性 (VM Internal 3-2)
• 対処
– AMD のNXビットやIntel CPUのDXビットのようなデータ領域のコードを実行できない機能(DEP: Data Execution Prevention)を有効にする
Program
通常はOSがこのメモリ空間をプロテクト
0x0804000 0x0804000
Program
Malware
Jump to MJump to MJump to M
Jump to M
M
障害があり、制御がどこに行くか不明
どこに飛んでもMalwareに行くようにJumpを敷き詰める
通常の動作 スプレイ攻撃
ランダムにならない乱数 (VM Internal 4)• 仮想マシンモニタは仮想マシンの実行途中を保存するスナッ
プショット機能を提供
• スナップショットイメージを複数回使うと前の疑似乱数生成を繰り返すことになる
• 更に問題なのは、疑似乱数のシードは時計などの物理的要因から取られるが、スナップショット再開後に外部の時計と同期せずに時間が繰り返される仮想マシンがある– When Good Randomness Goes Bad [NDSS10]
• 対処– Hedged cryptography– 暗号化レベルで仮想マシンの乱数生成の問題を意識して回避する
仮想化に対する各種の脆弱性/攻撃
– VM内(VM Internal)脆弱性をついた攻撃1. 仮想マシン上のOS管理2. I/O Fuzzing攻撃3. メモリエラーが引き金になる脆弱性4. ランダムにならない乱数
– VM間(Cross VM)のVM間の脆弱性をついた攻撃1. 物理キャッシュを通した覗き見2. 仮想メモリの覗き見 (実習内容)3. 仮想ネットワークによるセキュリティ障害4. LiveMigration時のRootKit混入
物理キャッシュによるサイドチャネル攻撃(CrossVM-1-1)
• “Hey, You, Get Off of My Cloud”[CCS’09]• セットアソシアティブキャッシュを共有している「悪意のあるVM」が連続して
キャッシュを叩く。キャッシュの反応が遅れると他のVMでアクセスしていることが判る– 限定した環境だが鍵漏洩の恐れがある
• 2005に話題になった Hyper Threading の脆弱性と同じ– http://journal.mycom.co.jp/articles/2005/05/17/ht/index.html
• 対策はVMのIsolation、排他制御
Set Associative Cache
Main Memory
AttackerVM
Cache Line64 byte
2 way
Log of Cache delay
NormalVM
仮想マシンモニタ
Core1 Core2
物理キャッシュによるサイドチャネル攻撃の対処“VM排他制御 ”(CrossVM-1-2)
• 利害の異なるVMは同時に実行させない、他のサーバに割当て排他制御が必要– XenはXSM(Xen Security Module)のACM(Access Control Module)では可能
• [XenSummit07]• これにより実行時デバイス共有によるCross VM Attackは防げる…
Timeslot
ポリシー利害関係有り
仮想マシンメモリの覗き見(CrossVM-2-1)• 既存の物理メモリへの覗き見攻撃
– IEEE1394(FireWire)によるメモリ覗き見
– メモリを冷やして解析。Cold Boot Attack [USENIX Security08]
• 仮想マシンでは同様の攻撃がソフトウェアのみで出来る– 管理OSを乗っ取られればVM Introspection機能から可能
– 管理OSを乗っ取らなくても、重複除外の機能を使って他のVMのメモリが覗ける[EuroSec’11, suzaki]
• メモリ重複除外– 仮想マシンが使うメモリで同じ内容のブロックは共有する技術
– 多くの仮想マシンモニタ(Vmware ESX, Xen, KVM)で利用可能
VM1 VM2 VM(n)
Real Physical Memory
Guest Pseudo Memory
仮想マシンメモリの覗き見(CrossVM-2-2)• 問題点：メモリ重複除外では共有したメモリブロックに書き込みを
行う場合にコピーを生成するため、通常の書き込みより遅い。
VM1(victim)
VM2(attacker)
Real Physical Memory
Guest Pseudo Memory
Write Access
コピーを作ってから書き込むので遅い
VM1(victim)
VM2(attacker)
• 攻撃者は見つけたい内容のメモリブロックを重複させて検出できる
• 多くの条件はあるが、アプリケーションの実行やホームページを見たことが検出できた。(実際の攻撃まではまだ問題あり)
• SSL/TLSなどの通信の暗号化は意味がない。SLAに違反していない。
仮想マシンメモリの覗き見(CrossVM-2-3)• 対策
– VMメモリの暗号化。他のVMからのぞき見られても情報漏えいしない
– Overshadow [ASPLOS08], SP3[Vee08]
SP3[Vee08]よりSID: SP3 Domain ID
– 欠点として、この対策法ではメモリ重複除外の効果を無効にして、メモリの有効活用が出来ない
仮想ネットワークによるセキュリティ障害(CrossVM-3)
• 仮想マシンモニタでは、同一物理マシン上の仮想マシン間を高速な仮想ネットワークで繋ぐ– XenSocket[Middleware07], XWAY[Vee08], XenLoop[Cluster
Computing09]
• 全通信が仮想マシンモニタ内に閉じ込められ、表に出てこない– フィルタリング、ネットワーク型IDSなど既存のツールを利用できない
• 対策– 日本IBM「Virtual Server Security for VMware（VSS）」
• VMWareのVMSafeを利用し、各仮想マシンの通信内容をチェック
Live Migration (CrossVM-４-1)• OSを起動させたまま、VMの他のサーバ移動
– サービスを継続しつつ、ハードウェアを停止するために必要
• スケールアウトには必須
“Exploiting live virtual machine migration” [BlackHat DC 2008]
LiveMigration時のRootKit混入(CrossVM-４-2)
• VM移動中にRootkitを仕込まれてしまう– Virtual Machine Based Rootkits
• “Exploiting live virtual machine migration”, [BlackHat DC 2008]
• VMイメージの完全性を検証することでRootkit混入は防げるが、
• 完全性のみでは覗き見による鍵漏洩は防げない。暗号化による秘匿性も必要
OS
メモリ
CPU
メモリ
CPU
仮想マシンモニタ
OS アプリ
メモリ
CPU
仮想マシンモニタ
VMBROSアプリ
VMBR
AttachedBy Attacker
Live Migration
メモリ
CPU
アプリ
アウトライン
• クラウドの仮想化技術の役割• 仮想化に対する各種の脆弱性/攻撃
– VM内(VM Internal)の脆弱性/攻撃• VM内の脆弱性をついてクラウドを攻撃する。
– VM間(Cross VM)の脆弱性/攻撃• VM間の脆弱性をついて他のVMを攻撃する。
• クラウド特有の問題• まとめ
Cloud Computing特有の問題 1/2スケールアウトするために
– CAP定理• Consistency（データの一貫性）、Availability (システムの可用性)、Partitions (ネ
ットワーク分断への耐性)のすべては成り立たない。
– 結果整合性（Eventual Consistency)• アトミックな整合性はない。いずれ整合することのみ保証
• エラー忘却型コンピューティング(Failure Oblivious Computing)などのエラーを無視する技術への対処– 楽天技術研究所の森正弥所長のコメント
• 「エラー忘却型コンピューティングは，データの完全性や保全性を犠牲にしてでも，分散処理の大規模化や高速化を実現しようとする考え方だ。このような考え方を，世界で初めて大規模に実用化した点が，Googleと他社の最大の差だろう」
Cloud Computing特有の問題 2/2データについて
• サービス終了後に預けたデータを確実に消すこと– J-SaaS利用規約
• http://www.j-saas.jp/service/download/pdf/kiyaku.pdf• データ消去の要件： サービス解約後１か月以内にデータ及び外部保管媒体を破棄
• Key-Value Storageではありえない！– Key-Value Storageの代表例: Amazon S3– 複数のサーバに分散することでロバストにするが、どこにデータがある
のか不明
– ロサンゼルス警察がGovCloudに対してGoogleに求めたセキュリティ要件「データサーバの特定」に対する回答
• 「データは北米大陸のみに保管」することを保証
– SNIAのCDMI(Cloud Data Management Interface)内では定義していないが、消去はガイドラインとして出したい。By Eric A. Hibbard 2010/6/29 at SNIA-J主催 「第１回最新技術動向講演会」
まとめ
• 仮想化は計算資源の共有、動的移動など可用性を高めるが、新たな脅威を招くものでもある– 脆弱性が増え、そこを叩く攻撃の増加
• 新たな防御技術(VM排他制御、メモリ暗号化、VMイメージ完全性検証、VM Introspection)の導入の必要がある
• 資料– 日経コンピュータ 2010/March/31
• 「護るが勝ち 仮想マシンに潜むセキュリティ問題」• http://bizboard.nikkeibp.co.jp/kijiken/summary/20100407/NC0753H_1735146a.html
• 情報処理学会誌 2010/12号 クラウドセキュリティ小特集• 「IaaS型クラウドにおける仮想マシンのセキュリティ」• http://fw8.bookpark.ne.jp/cm/ipsj/search.asp?flag=6&keyword=IPSJ-MGN511213&mode=PRT
まとめ 各種VMの対応脆弱性対応
(コード検証)ゲストの
DEP対応
排他制御 暗号化・
完全性検証
VM Introspection
メモリ重複除外
VMware vSphere 4.0とvCenter Server 4.0
EAL4+あり VMSafe Content-
Based Page Sharing
XenXenServer 5.6
EAL2
XSM(sHype)
OverShadowSP3
XenAccess Satori, Differential
EngineHyper-V EAL4 デフォルト
KVM Libvrit+SELinux
KSM(Kernel
SamePageMerging)
勝手に考えるIaaSのSLA (Service Level Agreement)
• 仮想マシンモニタはセキュリティ評価基準(ex: EAL)取得か
• ゲストOSはDEP(Data Execution Prevention)対応をインストールできるのか
• Live Migrationの有無の確認
– 転送イメージの暗号化・完全性検証の確認
– 乱数シードの初期化は確実か
• VM Isolationは確実か
– 利害が絡むVMが同時に動かないか。キャッシュの共有はないのか。重複除外で共有しているものはないのか
• ゲストOSの振舞い監視(VM Introspection)はあるのか。どこまでか。ログはあるか
• ハードウェアおよび仮想マシンモニタのエラー処理は適切に/即時に行っているのか。タイミングを狙った攻撃を防げるのか
• データの所在
– どこにあるのか確認できるのか。国単位か
– 災害があった際にバックアップは地政学的に問題ないか
• サービス停止後のデータ消去の条件
– 消したことをどこまで検証可能にしているのか
実習結果(覗き見)
sshd ELF file 438,852B (107*4KB)Average (us) zero random sshdBefore invocation 6.60 0.55 0.45
After invocation 6.51 0.42 7.50
Apache2 ELF file 365,308B (89*4KB)
Before invocation After invocation
Before invocation After invocation
Average (us) zero Random Apache2
Before invocation 6.45 0.37 0.53After invocation 6.24 0.40 7.56
