淺談企業虛擬化的安全風險
2018年 第4篇 本文共4080字 預計閱讀時間12分鐘
作者簡介
Line"/>
opop，中通快遞資訊保安工程師，主要負責中通快遞資訊保安事件的分析和應急處理，參與資訊保安測評和安全加固，開展日常的風險評估工作和滲透測試工作。
企業虛擬化技術的運用，幫助企業系統管理者擺脫了繁重的物理伺服器、OS及相容性的管理工作，也幫助企業節約了電力和冷卻裝置成本，同時也減少了空間佔用，具有高利用率、高應用相容性、高靈活性。有些公司大部分業務系統已經變成虛擬機器+Docker形式的組合，作業系統和Docker本身採用虛擬機器映象方式部署，軟體、業務依賴元件，業務定義等與業務相關屬性採用容器映象，既實現安全隔離又提升資源的高利用率。
在享受著虛擬化的諸多好處的同時，我們可能還沒有意識到，隨著虛擬化技術的大規模應用，所面臨的安全風險也已不同於往日了，虛擬化安全對於普通安全從業者往往顯得晦澀難懂，但又隨著網路攻防愈演愈烈而愈發重要。本篇文章會簡單介紹虛擬化技術，梳理虛擬化技術在企業運維過程中存在的安全風險，並通過實踐發現、解決這些安全風險。
1.企業虛擬化介紹
企業虛擬化大多是使用四種虛擬機器管理程式（Hypervisor 又稱Vmm）Xen、Kvm、Hyper-v、Vmware以及近幾年很火的容器， 無論虛擬機器還是容器，只是在不同的層面進行了虛擬化。其中Xen、Kvm、Docker是開源專案，Hyper-v屬於微軟，Vmware屬於VMware公司，各種虛擬化機器管理程式所使用的虛擬化技術也有所不同，為了能幫助我們更好的瞭解企業虛擬化安全下面會簡單介紹下虛擬化的幾種技術。
1.1
虛擬化的幾種技術
1.1.1 全虛擬化
全虛擬化（full virtualization）無需修改作業系統，如 vmware workstation、vmware esxi，全虛擬化在處理虛擬機器作業系統中執行的特殊指令時進行攔截和模擬操作，保證相關操作被攔截在當前虛擬機器中，缺點也出現在這裡，所有特權指令都需要攔截和模擬消耗是很大的。圖1展示了全虛擬化技術的結構。
圖1.全虛擬化技術結構
1.1.2 半虛擬化
半虛擬化(para virtualization)需要對虛擬作業系統進行修改的稱為半虛擬化，如 hyper-v，xen。
半虛擬化需要對GuestOS核心程式碼做一定的修改，加入與hypervisor協同的程式碼，通過這種方式半虛擬化無須進行捕獲異常、翻譯、模擬操作，進而彌補上述全虛擬化過多消耗資源的缺陷。圖2展示了半虛擬化技術的結構。
圖2.半虛擬化技術結構
1.1.3 硬體虛擬化 （CPU虛擬化）
簡單的來說CPU廠商直接在晶片上提供了對虛擬化的支援，增加了新的執行模式讓Hypervervisor(Vmm)執行在Root模式(Ring-1)，GuestOs執行在Non-Root模式（Ring0）， VMM通過一個位於記憶體的資料結構(Intel稱為VMCS，AMD稱為VMCB)來控制Guest OS與Host OS的互動，以完成整個平臺的虛擬化，通過引入硬體技術，將使虛擬化技術更接近物理機的速度。
1.1.4 容器虛擬化
容器技術主要利用了Linux下的LXC技術來實現的，LXC主要是利用Linux的核心特性：名稱空間和cgroups子系統。LXC在資源管理方面依賴與Linux核心的cgroups子系統，cgroups子系統是Linux核心提供的一個基於程序組的資源管理的框架，可以為特定的程序組限定可以使用的資源。LXC在隔離控制方面依賴於Linux核心的namespace特性，namespace感覺像C++的namespace，就是在核心中可以擁有不同namespace的相同的程序id。容器相比與上面的那些虛擬化的主要區別在於容器提供的是執行環境，上面的那些提供的是作業系統，所以容器適用於Paas而上面的適合Iaas。效率上，容器比作業系統虛擬化要快。部署上，容器可以快速部署。現在主流的容器Docker的組成公式是 LXC+AUFS;LXC=cgroup+namespace+chroot。圖3展示了Docker的構成。
圖3. Docker的構成
2.企業虛擬化中的安全風險
我們將分層梳理虛擬化中的安全風險，從硬體介面，底層虛擬化技術，到虛擬化產品再到容器。圖4展示了企業虛擬化中不同層面的安全風險。
圖4.企業虛擬化中不同層面的安全風險
2.1
硬體介面層面
要有效管理和監控大量的物理伺服器，管理員必須藉助伺服器提供的硬體管理介面和帶外管理網路才能實現。例如，惠普的iLO介面，Dell和浪潮的IPMI介面，通過一個Web或Ssh介面，使用者可以監視伺服器的物理健康特徵，如溫度、電壓、風扇工作狀態、電源狀態等，更重要的是可以裝系統、開關機、檢視操作伺服器螢幕輸出，就好比站在伺服器面前。同樣如果硬體介面層面出現安全問題其後果不堪設想，一臺物理機上可能是N個業務虛擬機器，入侵者在關鍵時間點關閉幾臺物理機可造成大面積業務癱瘓。
2.1.1
介面預設口令運維可能並不使用硬體管理介面導致仍是預設口令，常見產品預設口令見表1。
表1.常見硬體產品預設口令
| 產品名稱 |
預設使用者名稱 |
預設密碼 |
| Supermicro IPMI (2.0) |
ADMIN |
ADMIN |
| Oracle/Sun Integrated Lights Out Manager (ILOM) |
root |
changeme |
| BM Integrated Management Module (IMM) |
USERID |
PASSW0RD (with a zero) |
| HP Integrated Lights Out (iLO) |
Administrator |
(null) |
| Fujitsu Integrated Remote Management Controller |
admin |
admin |
| Dell Remote Access Card (iDRAC ， DRAC) |
root |
calvin |
| ASUS iKVM BMC |
admin |
admin |
防護方法:
(1) 告知運維相關風險並設定強口令。
(2) 將以上密碼納到弱口令檢測的列表中，週期性的進行安全巡檢。
2.1.2 硬體介面漏洞
硬體介面是程式寫的，同樣會出現安全漏洞。如: HPE Integrated Lights-Out 4遠端程式碼執行 (CVE-2017-12542)，漏洞產生在逐行解析Header的函式中，處理Connection時使用了不安全的sscanf函式導致溢位(圖:5、圖6展示了相關溢位程式碼)。
圖5.將引數str的字串根據引數format字串來轉換並格式化資料
圖6.Connection大小為16bytes
主機系統可以通過共享記憶體與iLO通訊，且從主機系統請求Redfish API是不需要認證的，web伺服器通過localConnection的布林值來判斷主機來源。利用該漏洞在headers中的'Connection'欄位增加29個A即可偽造成localConnection從而繞過身份驗證。
圖7.利用該漏洞新增管理員賬戶
圖8.利用新增的管理員賬戶登入web管理平臺
防護方法：
(1)使用指令碼對內網主機進行漏洞掃描（漏洞檢測&利用的po c：https://github.com/skelsec/CVE-2017-12542/)。
(2)類似管理埠做好訪問控制，限制內網訪問許可權。
(3)及時升級打補丁？在大部分企業都行不通，對於企業資料中心來說，保證可用性是第一位的。每個虛擬主機上都跑著幾十上百個的虛擬客戶機，使得管理員輕易不敢對虛擬主機任何變更操作。
2.2
底層虛擬化技術層面
Hypervisor（VMM）層面漏洞的殺傷力還是不容小覷的，如前幾年Xen”破天”漏洞， 該漏洞存在於Xen Hypervisor的記憶體管理機制中， 漏洞利用簡單危害巨大影響眾多家雲平臺，具體漏洞細節可以檢視阿里安全團隊的文章:http://www.freebuf.com/vuls/83403.html。
圖9.利用exploit獲取HostOs root許可權
防護方法：
(1)檢查自身版本是否受影響 POC：https://blog.quarkslab.com/resources/2016-07-12_xsa-148/code/xsa148_exploit.tar.gz
(2)類似Hypervisor層面的漏洞可以考慮部署agent監控cpu指令的變化，發現從虛擬化穿透到宿主機的攻擊行為。
2.3
虛擬化產品層面
如企業常用的VMware ESX/ESXI、VCenter也有不少值得關注的安全問題。至於如何發現企業中的VMware產品有兩種方式，一種是通過埠掃描通過返回的banner判斷是否為VMware服務，另一種是通過企業已有的cmdb匯出相關資產列表。
2.3.1 openssl TLS/DTLS心跳資訊洩露漏洞
Vmware產品的部分版本中的使用openssl 1.0.1，受Openssl心臟出血漏洞的影響。
受影響的版本列表如下:
| ESXi 5.5 | VMware Horizon Workspace 1.0 |
| NSX for Multi-Hypervisor Manager 4.0.x and 4.1.x | VMware Horizon Workspace 1.5 |
| NSX 6.0.x for vSphere | VMware Horizon Workspace 1.8 |
| NVP 3.x | VMware Horizon Workspace Client for Macintosh 1.5.1 |
| vFabric Web Server 5.0.x – 5.3.x | VMware Horizon Workspace Client for Macintosh 1.5.2 |
| VMware Client Integration Plug-In | VMware Horizon Workspace Client for Windows 1.5.1 |
| VMware Fusion 6.0.x | VMware Horizon Workspace Client for Windows 1.5.2 |
| VMware Player 6.0.x | VMware Horizon Workspace for Macintosh 1.8 |
| VMware Workstation 10.x | VMware Horizon Workspace for Windows 1.8 |
| VMware Horizon Mirage Edge Gateway 4.4.x | VMware OVF Tool 3.5.0 |
| VMware Horizon View 5.3 Feature Pack 1 | VMware vRealize Automation (formerly known as vCloud Automation Center) 6.x |
| VMware Horizon View Client for Android 2.1.x， 2.2.x， 2.3.x | VMware vCloud Networking and Security (vCNS) 5.1.3 |
| VMware Horizon View Client for iOS 2.1.x， 2.2.x， 2.3.x | VMware Horizon View Client for Windows 2.3.x |
防護方法:
(1)檢查自身版本是否在影響範圍內。
(2)使用指令碼進行漏洞掃描 如：nmap -p 443 --script ssl-heartbleed，ssl-known-key。
2.3.2 Vmware Java RMI遠端程式碼執行漏洞
VMware vCenter Server的JMX遠端介面配置中存在安全漏洞，遠端攻擊者通過該介面可註冊受控的mbean，在system上下文中執行遠端程式碼。可以使用Metasploit中的exploit/multi/misc/java_jmx_server載荷進行攻擊。表2展示了受影響的版本。
表2.存在Vmware Java Rmi遠端程式碼執行的版本
| VMware Product | Version | Platform | Fixed Version |
| VMware vCenter Server | 6 | Any | 6.0 u1 |
| VMware vCenter Server | 5.5 | Any | 5.5 u3 |
| VMware vCenter Server | 5.1 | Any | 5.1 u3b |
| VMware vCenter Server | 5 | Any | 5.0 u3e |
防護方法：
(1) 檢查自身版本是否在影響範圍內。
(2) 使用指令碼對內網主機進行漏洞掃描(漏洞檢測&利用的poc https://github.com/penoxcn/VMware/tree/master/rmi)。
(3)評審是否需要開啟jmx遠端介面功能，如非必要可關閉jmx遠端接功能。
2.4
容器層面
2.4.1 對映目錄
Docker允許使用者在Host和Container之間共享資料夾，同時不需要限制容器的訪問許可權，這就容易讓容器突破資源限制。例如，假設有使用者啟動容器時將主機的根目錄/對映到容器的/host目錄中，那麼理論上在容器中就可以對主機的系統進行任意修改。
防護方法：
(1) 檢查需要對映的目錄是否敏感，是否可以被利用。
(2) 對於需要對映但不需要修改的檔案可以指定為只讀用ro，docker run -it -v xxx:xxx:ro 。
2.4.2 未授權訪問(web/api)
Docker Swarm 是一個將Docker叢集變成單一虛擬的Docker Host工具，使用標準的Docker API，能夠方便Docker叢集的管理和擴充套件，由Docker官方提供。當Docker Swarm Manager執行時，預設監聽2375埠，並等待外部連線使用Docker API來操縱Docker，類似的還有Kubernetes的API介面。通過此類介面未授權訪問的安全問題，我們可以新建 container，刪除已有 container，通過啟動容器並掛載敏感目錄甚至可以獲取宿主機的 shell。圖10展示了公司在用的”某企業級Kubernetes管理平臺”web及API均未授權訪問。
圖10.在用的”某企業級Kubernetes管理平臺”web及API均未授權訪問
防護方法：
(1) 限制API/WEB的訪問許可權
(2)增加API/WEB認證
2.4.3 Breakout
Docker專案的核心技術和Linux Kernel息息相關，而Linux Kernel軟體一直受安全漏洞影響，那麼Docker容器同樣會被Linux Kernel的安全漏洞所影響，並且使用一個高威脅的Linux Kernel安全漏洞，攻擊者甚至可以從Docker容器上下文進入宿主機上下文。這種上下文的切換稱為Breakout，當切換完成後，攻擊者可以在宿主機中執行任意命令。
Docker容器可以被Breakout攻擊並不能說明Docker產品有缺陷，因為Linux Kernel的安全漏洞可以影響Linux生態中的方方面面，不單是Docker產品。
防護方法：
(1) 及時修復Linux Kernel的安全漏洞。
3.總結
虛擬化給企業的資料中心帶來了高效的運維和不錯的經濟效益，但是也引入了與以往不一樣的安全威脅與風險。本篇主要帶大家瞭解了企業虛擬化中各個環節中的安全風險，硬體介面、底層虛擬化、虛擬化產品、容器每個環節的安全問題都非常致命，希望運維、安全工程師看了本篇文章後能有所啟發。
參考資料：
-
https://www.synacktiv.com/ressources/recon_bx_2018_ilo4_perigaud_gazet_czarny.pdf Subverting your server through its BMC: the HPE iLO4 case
-
http://www.freebuf.com/vuls/83403.html “破天”：Xen虛擬化平臺虛擬機器逃逸漏洞分析
-
https://www.cnblogs.com/IvanChen/p/5038306.html 理解全虛擬、半虛擬以及硬體輔助的虛擬化
-
http://www.freebuf.com/articles/es/164792.html 淺談企業虛擬化環境的安全風險與滲透測試方法
-
《雲虛擬化安全攻防實踐》
中通安全應急響應中心
團隊介紹
中通訊息安全團隊是一個年輕、向上、踏實以及為夢想而奮鬥的大家庭，我們的目標是構建一個基於海量資料的全自動資訊保安智慧感知響應系統及管理運營平臺。我們致力於支撐中通快遞集團生態鏈全線業務（快遞、快運、電商、傳媒、金融、航空等）的安全發展。我們的技術棧緊跟業界發展，前有 React、Vue，後到 Golang、Hadoop、Spark、TiDB、AI 等。全球日均件量最大快遞公司的資料規模也將是一個非常大的挑戰。我們關注的方向除了國內一線網際網路公司外，也關注 Google、Facebook、Amazon 等在基礎安全、資料安全等方面的實踐。
加入我們
如果您對我們的團隊或者我們做的事有興趣，也希望在工程技術領域有所成就，非常歡迎加入我們，我們需要資訊保安、分散式平臺開發、大資料、風控、產品、運營等方面的人才，Base上海，工作地點任選虹橋萬科中心及中通總部。簡歷投遞地址：[email protected]。
