VirtualMachine Image scanning PoC with Molysis

Transcript

1. 仮想マシンの静的解析による脆弱性検知ツールの開発
2. 自己紹介 基本情報 名前: 藤村 匡弘( masahiro331 ) 会社ではセキュリティエンジニアをしている 2
3. 背景 • 昨今のインフラ環境は仮想マシン環境で構築 • 多くの事業者が、プライベートクラウドもしく はクラウドサービス上にアプリケーションをデ プロイしている • 管理している環境が本当に安全なのか不安 3 Infrastructure Hypervisor Guest OS Docker Engine Container Guest OS App A App B
4. 安全ではない仮想マシン環境とは？ • カーネルやOSのセキュリティ機構が働いていない • 外部に公開してはいけないプロセスが公開されている • 公開されているミドルウェア, アプリケーションライブラリが脆弱 • 公開されているミドルウェア, アプリケーションの設定が安全ではない • 公開されているアプリケーションの実装に脆弱性が存在する • 悪意あるユーザによる改竄もしくはイメージの配布 4 Infrastructure Hypervisor Guest OS Docker Engine App A App B
5. 安全ではない仮想マシン環境とは？ • カーネルやOSのセキュリティ機構が働いていない • 外部に公開してはいけないプロセスが公開されている • 公開されているミドルウェア, アプリケーションライブラリが脆弱 • 公開されているミドルウェア, アプリケーションの設定が安全ではない • 公開されているアプリケーションの実装に脆弱性が存在する • 悪意あるユーザによる改竄もしくはイメージの配布 5 Infrastructure Hypervisor Guest OS Docker Engine App A App B SecHack365のテーマとして、 まずはここから開発する
6. 実現したい世界 6 ・システム運用者がデプロイ時に脆弱性検査 Packerなどを用いて仮想マシンイメージを構築し、Public CloudもしくはPrivate Cloudに デプロイする際に脆弱性を検知し、リリース時判定を実施
7. 実現したい世界 7 ・プラットフォーマが利用 AWSやさくらインターネットなどの仮想マシンイメージを保管提供する事業者が、 仮想マシンイメージを解析するプラットフォームを提供
8. コンテナセキュリティについて 8 • コンテナイメージはデプロイ前に静的解析する流れになっている • 仮想マシンイメージはデプロイ前に静的解析ツールが存在しない
9. そもそも既存ツールで解決できないの？ 9 ・競合ツールとしてVulsなどが存在するが、実行中のサーバに しか利用できない ssh install 仮にvulsで仮想イメージを100個検査するとなると 個別にサーバにデプロイして検査する必要がある
10. テーマ ・ 作るもの 仮想マシンイメージを静的に解析し脆弱性検知ができる ・ 想定利⽤者 インフラセキュリティチーム, アプリケーション開発者, クラウド基盤運⽤者 ・ 要件 モジュール化 環境依存の排除 計算資源の効率化 10
11. 方針 ・モジュール化 成果物のツールはあくまでも基礎技術開発の副産物であり、このプロジェクトでは利活⽤ 可能な各機能のモジュール開発を優先的に実施 (利活⽤例: 信頼できないイメージのフォレンジックなど) ・環境依存の排除 C⾔語などのプラットフォームに依存する実装を排除し、クロスプラットフォームで動作す るように実装 ・計算資源の効率化 仮想マシンイメージを展開すると数⼗GB ~ 数TBのバイナリデータになるため 全ての処理においてストリームで処理できるように実装 11
12. 概念図 • VHDやVMDKといった仮想マシンイメージから各OSのパッケージ情報を取得 • パッケージ情報をもとに既知の脆弱性を検知 Vulnerability DB VMDK VHD 仮想マシンイメージ Install Software ・Install Packages ・Libraries Matching Security Advisory ・OVAL ・NVD ・Vendor Advisory 12 レポート OS ・OS version ・Kernel Box
13. 仮想マシンイメージのパース 13 VMDK FileSystem FileSystemが入った独自フォーマット 任意のファイルシステム • 全てをメモリ上に展開できないためStreamでパースできるよう実装 • 各ユーザのクライアントで動作するよう外部依存をなくすため、 全てGolangで実装 パッケージDB RPMDBなどのパッケージ情報を含むDB
14. デモ 14
17. 方針の再確認 ・モジュール化 成果物のツールはあくまでも基礎技術開発の副産物であり、このプロジェクトでは再利⽤ 可能な各機能のモジュール開発を優先的に実施 ・環境依存の排除 C⾔語などのプラットフォームに依存する実装を排除し、クロスプラットフォームで動作す るように実装 ・計算資源の効率化 仮想マシンイメージを展開すると数⼗GB ~ 数TBのバイナリデータになるため 全ての処理においてストリームで処理できるように実装 17
18. • プラグインアーキテクチャで実装している • 機能を追加する場合はInterfaceに合わせて実装するだけでよい モジュール化について 18 molycis go-rpm-version trivy-db go-ext4- filesystem Vulnerability DB Version compare go-vmdk-parser filesystem Virtual image Extractor ImageExtractor FileSystemExtractor Interface Module Detector RPMAnalyzer AlpineAnalyzer Package OS Analyzer OSAnalyzer PkgAnalyzer ・・・・ ・・・・ ・・・・ ・・・・
19. 環境依存の排除 • Windows環境で動作することを確認 • Mac環境で動作することを確認 • Linux環境で動作することを確認
20. 計算資源の効率化 20 Box, VMDK, VHD 圧縮データ 圧縮データ 圧縮データ ・・・ ・・・ 100MB ~ 1GB Partition 1 ・・・ EXT4, XFS 10G ~ 数TB 任意のファイル ・・・ 1k ~ 1G • これらの処理を任意のバッファサイズで読み込み処理できるように実装 Install Software ・Install Packages ・Libraries OS ・OS version ・Kernel
21. ここから技術的な話 21
22. VMDKのパース 22 圧縮アルゴリズムやVMDK内のデータサイズが記載 (512バイト) マーカーとオブジェクトの集合 • VMDKは、VMwareWorkstationやVirtualBoxなどの仮想マシンで使用されるファイル形式
23. VMDKのパース 23 ・必要なのはCompressed Grain Dataのみ 8 byte 4 byte 500 byte Compressed Grain Data Sector Index Data Size Compressed Data (Deflate) decompress Filesystem Decompressed Data Master Boot Record or GUID Partitions Table Partision 0 (boot partition) Partision 1 (file system)
24. Partitionのパース 24 • Filesystemをパースする前にPartitionを解析 Decompressed Data Master Boot Record or GUID Partitions Table Partition 0 (boot partition) Partition 1 (Filesystem) Boot partitionは無視し、 実データが格納されているpartition1を解析
25. Filesystemのパース 25 • FilesystemのSuperBlockを解析しFilesystemを識別 • 現状ではext4 Filesystemを対応 Partition 1 (Filesystem) Super block Data(Ext4, XFS or etc… )
26. EXT4のパース 26 • Streamで処理するためファイルのSeekなどが利用できない • メモリ上に必要なInodeを保持するように実装 Super Block Group Descriptor Block Reserved Group Descriptor Table Block Data Block Bitmap Block Inode Bitmap Block Inode Table Block Data Blocks • Headerのようなもの • 各ブロックの位置情報が入っている • 拡張用の空き領域(利用しない) • Data Blockの使用状況を管理（利用しない) • Inode Tableの利用状況（利用しない） • Inode情報が入っている • 実際のデータが入っている
27. EXT4のパース 27 • Streamで処理するためファイルのSeekなどが利用できない • メモリ上に必要なInodeを保持するように実装 Super Block Group Descriptor Block Reserved Group Descriptor Table Block Data Block Bitmap Block Inode Bitmap Block Inode Table Block Data Blocks SuperBlockとGroupDescriptorは順番が保証されている これらのデータは順番が保証されていない
28. Filesystemの解析における制約について 28 • Inode情報が格納されているInodeTableが実データより後に来る場合はパース できない • 複数のパーティションに分割されてファイルデータが存在する場合はパースでき ない
29. OSの識別とパッケージの取得 29 • FilesystemからOSを識別し、パッケージ情報を取得 /etc/os-releaseからOSのバージョンを特定
30. OSの識別とパッケージの取得 30 • RedHat系列の場合はrpmをパッケージ管理として利用している • /var/lib/rpm/Packagesを解析することによってパッケージの取得が可能 https://knqyf263.hatenablog.com/entry/2020/10/28/124040 https://masahiro331.hatenablog.com/entry/2020/12/20/052234
31. 脆弱性の検知 31 • パッケージ名とバージョンをもとに脆弱性の検知 • バージョンの比較にはOS毎に仕様が異なるため個別に実装 https://github.com/knqyf263/go-rpm-version • データベースとして AquaSecurity社が開発しているものを利用 https://github.com/aquasecurity/vuln-list-update https://github.com/aquasecurity/vuln-list https://github.com/aquasecurity/trivy-db (藤村も開発に参加している) • 脆弱性の検知率はAquaSecurityのTrivyと同等
32. 今後の課題 • 複数のOSに対応する必要がある 現状ではRedHat系列とAlpine Linuxのみ • 複数のファイルシステムに対応する必要がある LVMやXFSなど • より多くのイメージを収集しエッジケースの洗い出し 32
33. 仮想マシンも実行前の脆弱性検査を当たり前に 33 https://github.com/molysis/molysis