As usual, because of vendor decision, vendor not going to release the details of design weakness. From my opinion that understand the details will be enhanced your system and infrastructure defense mechanism. Below is my personal comment according to this specifics vulnerability.

Vulnerability details: CVE-2021-21481 – The MigrationService, which is part of SAP NetWeaver, does not perform an authorization check allowing an unauthorized attacker to access configuration objects, including such that grant administrative privileges.

Since SAP uses an explicit authorization model, an authority checks must be coded in order to be executed. If an explicit check is not coded, all users have access.

Reference: Explicit authentication bypass (whitelist). The filter architecture will, by default, provide an “always-on” authentication approach. This sets up the system for an explicit whitelist.

Impact: Since the failure is related to incorrect authorization, the risk will depend on the environment.

Official announcement: Please refer to link – https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=573801649

Preface: A named pipe is just a file on the filesystem used for I/O through SMB.

Background: Outlook Web App is hosted on the Client Access Server role for Exchange Server and integrated with IIS. An Internet Information Services (IIS) worker process is a Windows process (w3wp.exe) which runs web applications, and is responsible for handling requests sent to a web Server for a specific application pool. Suppose an attacker uses a web application, uploads a web shell, and executes a simple ping command.
– The execution process should be as follows:
– Services.exe – spawn svchost.exe (with -k iissvcs)
– Svchost.exe – spawn w3wp.exe (with parameters calling the application pool, config file, etc)
– W3wp.exe – spawn cmd.exe

Direction v2 – Remediation of MS exchange vulnerabilities:
On April 13, 2021, Microsoft released a software update to mitigate significant vulnerabilities that affect on-premises Exchange Servers 2013, 2016, and 2019. These vulnerabilities are different from the ones disclosed and fixed in March 2021 – the security updates released in March 2021 will not remediate against these vulnerabilities. So you should pay attention of Microsoft announcement. When patch release, it is recommend to do this patching.

Official details: https://cyber.dhs.gov/ed/21-02/#supplemental-direction-v2

Status update: Released: April 2021 Exchange Server Security Updates – https://techcommunity.microsoft.com/t5/exchange-team-blog/released-april-2021-exchange-server-security-updates/ba-p/2254617

Preface: RIOT is a low-memory operating system suitable for IoT devices. It is an open source software released under LGPLv2.

Background: RPL (Routing Protocol for Low-Power and Lossy Networks) is a routing protocol for wireless networks with low power consumption and generally susceptible to packet loss. It is a proactive protocol based on distance vectors and operates on IEEE 802.15.

Vulnerability details: RPL is a distance vector routing protocol based on the construction of a directed acyclic graph (DAG). Existing Routing Protocols for Low Power and Lossy Networks (RPL) are considered lightweight and secure routing protocols for IoT devices, which offer a slight safeguard against innumerable forms of RPL routing attacks. Unfortunately of design weakness. There are total of 3 potential risk of vulnerabilities was found in RPL function. All the vulnerability will be trigger buffer overflow. For more details, please refer to the link below:

CVE-2021-27697 RIOT-OS 2021.01 contains a buffer overflow vulnerability in sys/net/gnrc/routing/rpl/gnrc_rpl_validation.c
through the gnrc_rpl_validation_options() function. – https://nvd.nist.gov/vuln/detail/CVE-2021-27697

CVE-2021-27698 RIOT-OS 2021.01 contains a buffer overflow vulnerability in /sys/net/gnrc/routing/rpl/gnrc_rpl_control_messages.c
through the _parse_options() function – https://nvd.nist.gov/vuln/detail/CVE-2021-27698

CVE-2020-27357 RIOT-OS 2020.01 contains a buffer overflow vulnerability in /sys/net/gnrc/routing/rpl/gnrc_rpl_control_messages.c – https://nvd.nist.gov/vuln/detail/CVE-2021-27357

Preface: ezXML – XML Parsing C Library version 0.8.5 ezXML is a C library for parsing XML documents inspired by simpleXML for PHP.
According to the statistis by W3Techs, PHP is use by 79.2% of all websites primary server-side programming language.

Background: In an XML file, there are both tags and text. The tags provide the structure to the data. The text in the file that you wish to store is surrounded by these tags, which adhere to specific syntax guidelines. XML parser is a software library or a package that provides interface for client applications to work with XML documents. It checks for proper format of the XML document and may also validate the XML documents.

Vulnerability details: An issue was discovered in libezxml.a in ezXML 0.8.6. The function ezxml_internal_dtd(), while parsing a crafted XML file, performs incorrect memory handling, leading to a NULL pointer dereference while running strcmp() on a NULL pointer.

Consequences: Running a program that contains a NULL pointer dereference generates an immediate segmentation fault error. This defect may manifest itself as a program crash, or be transformed into a software exception that can be caught by program code.

For more details, please refer to link https://nvd.nist.gov/vuln/detail/CVE-2021-30485

Preface: The two main changes to the CONNACK message between MQTTv3.1.1 and MQTTv5 are the enhanced reason codes and the properties field.

Background: MQTT is an OASIS standard messaging protocol for the Internet of Things (IoT). It is designed as an extremely lightweight publish/subscribe messaging transport that is ideal for connecting remote devices with a small code footprint and minimal network bandwidth. Furthermore, the MQTT CONNECT and response messages (CONNACK) have been greatly enhanced in MQTTv5 with the addition of the properties field. The properties field allows for a large increase in the information that can be exchanged between client and server on connection establishment compared to MQTT v3.1.1.

Vulnerability details: In Eclipse Mosquitto version 2.0.0 to 2.0.9, if an authenticated client that had connected with MQTT v5 sent a crafted CONNACK message to the broker, a NULL pointer dereference would occur. Null-pointer dereferences result in the crash of the process. But if an attacker can intentionally trigger a null pointer dereference, the attacker might be able to use the resulting exception to bypass security logic.

Official announcement: Please refer to link – https://bugs.eclipse.org/bugs/show_bug.cgi?id=572608

Preface: Many industry standards still rely on XML to describe and exchange data between business partners in a way that guarantee interoperability even with legacy systems running on mainframes. SOAP enable developers to create and use APIs based on XML payloads.

Background: Apache CXF™ is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI.

Vulnerability Details: A set of malicious client can launch a DoS attack to the authorization server by pointing the “request_uri” to a URI that returns extremely large content or extremely slow to respond. Under such an attack, the server may use up its resource and start failing. Official details shown in follow link – https://lists.apache.org/thread.html/r6445001cc5f9a2bb1e6316993753306e054bdd1d702656b7cbe59045@%3Cannounce.apache.org%3E

Workaround: To prevent such attack to succeed, the server should:

(a) check that the value of “request_uri” parameter does not point to an unexpected location.
(b) check the content type of the response is “application/oauth-authz-req+jwt”.
(c) implement a time-out for obtaining the content of “request_uri”.
(d) not perform recursive GET on the “request_uri”.

Preface: From developing anti-virus till today. The trend is Analyse attackers’ behaviour patterns to detect and conducting defence.

Product background: Carbon Black Cloud Workload is a data center security product that protects your workloads running in a virtualized environment. Carbon Black Cloud Workload ensures that security is intrinsic to the virtualization environment by providing a built-in protection for virtual machines.

Vulnerability details: For more details, please refer to link – https://www.vmware.com/security/advisories/VMSA-2021-0005.html

Supplement: The technical details not announce by vendor yet.
Maybe the attached picture will provide you with hints. Apart from that when you finish the software patching or workaround. I would recommend that conduct a review of alert logging in your VMware carbon black environment. But what is the coverage (period). The way is do a review on the monthly virus detection log, find out the victim workstation which have connectivity to carbon black network segment. But the next step all depends on what you find out in the 1st step. This audit check should covered 3 month log activities.

Preface: If attacker dexterous to use Server Side Request Forgery and Arbitrary file write vulnerability. It will boots up their risk impact.

Background: Photon OS, a lightweight Linux distribution created and maintained by VMware, is designed specifically to run as a container host and has been optimized for cloud-native applications and cloud platforms, and has been optimized to run on VMware infrastructure and in public clouds.

Vulnerability Details: On March 31, 2021, VMware officially released the risk notice of vmsa-2021-0004. The vulnerability numbers are cve-2021-21975 and cve-2021-21983. The vulnerability level is high risk and the vulnerability score is 8.6.

Remedy: For official announcement, please refer to link – https://www.vmware.com/security/advisories/VMSA-2021-0004.html

Supplement: If you have interested of the scenario on exploit those vulnerabilities. Please refer to attached diagram.

Preface: Once upon a time, Citrix Hypervisor was known as XenServer. “Xen” is the name of the hypervisor technology first developed by the University of Cambridge and eventually improved by Citrix.

Background:

Recommendation 1: It is recommended to use paravirtualized devices instead of emulated devices for virtual machines running I/O intensive applications.

Recommendation 2: Persistent grants feature provides high scalability. On some small systems, however, it could incur data copy overheads and thus it is required to be disabled.

Vulnerability details:

CVE-2021-28688 An attacker with the ability to execute privileged mode code in a guest can perform a denial of service attack against the host. Avoiding the use of persistent grants will also avoid the vulnerability. This can be achieved by passing the “feature_persistent=0” module option to the xen-blkback driver.

CVE-2021-28038 An attacker with the ability to execute privileged mode code in a guest can perform a denial of service attack against the host. Linux versions from at least 2.6.39 onwards are vulnerable, when run in PV mode. Earlier versions differ significantly in behavior and may
therefore instead surface other issues under the same conditions. Linux
run in HVM / PVH modes is not vulnerable.

Official details: Two security issues have been identified in Citrix Hypervisor – https://support.citrix.com/article/CTX306565