Aggregator

Between April and July 2024, Microsoft observed Iranian state-sponsored threat actor Peach Sandstorm deploying a new custom multi-stage backdoor, which we named Tickler. Tickler has been used in attacks against targets in the satellite, communications equipment, oil and gas, as well as federal and state government sectors in the United States and the United Arab […]

The post Peach Sandstorm deploys new custom Tickler malware in long-running intelligence gathering operations appeared first on Microsoft Security Blog.

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Grigory Dorodnov and Guy Lederfein of the Trend Micro Research Team detail a recently patched code execution vulnerability in the VMware vCenter Server. This bug was originally discovered by Hao Zheng and Zibo Li from TianGong Team of Legendsec at Qi'anxin Group. Successfully exploiting this vulnerability could lead to a heap buffer overflow, which could result in the execution of arbitrary code in the context of the vulnerable service. The following is a portion of their write-up covering CVE-2024-37079, with a few minimal modifications.

An integer underflow vulnerability has been reported for VMware vCenter Server. The vulnerability is due to a lack of validation of the calculated response header size used in subtraction.

A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted DCERPC packet to the target server. Successfully exploiting this vulnerability could lead to a heap buffer overflow, which could result in the execution of arbitrary code in the context of the vulnerable service.

The Vulnerability

VMware vCenter Server is a data center management server application developed by VMware Inc. VMware vCenter Server is designed primarily for vSphere, VMware's platform for building virtualized cloud infrastructures. vCenter Server relies on VMware's fork of the Likewise Open project to support DCERPC or, more specifically, MSRPC protocol needed for interaction with Microsoft services and products like, for example, Active Directory. Specifically, vCenter uses the `libdcerpc.so` library from Likewise Open in VMware Certificate Management Service (vmcad), VMware Directory Service (vmdird) and VMware Authentication Framework (vmafdd), accessible from the external network on TCP ports 2014, 2012, and 2020 respectively.

DCERPC

DCERPC (Distributed Computing Environment/Remote Procedure Call) with Microsoft extensions (MSRPC) is used to transparently execute functions on remote servers. To facilitate this process, interfaces are defined using an interface definition language (IDL). IDL code is shared between the server and the client and defines the data structures used for network communications. Each interface is identified by a UUID and contains abstract data types and function declarations. To call a function on a remote server via DCERPC, the client establishes a context by sending a Bind request (RPC_C_CN_PKT_BIND, 0x0b) containing the interface UUID of the interface to which the function belongs. Once the context is established, the client sends the desired RPC calls, or modifies the context by sending an Alter Context (RPC_C_CN_PKT_ALTER_CONTEXT, 0x0e) request. Other RPC request and response types of interest to this report are:

— Bind Acknowledgement (RPC_C_CN_PKT_BIND_ACK, 0x0c) - an acknowledgment of successful completion of the Bind request
— Bind Negative Acknowledgement (RPC_C_CN_PKT_BIND_NAK, 0x0d) - a notification of rejection of the Bind request
— Alter Context Response (RPC_C_CN_PKT_ALTER_CONTEXT_RESP, 0x0f) - a response to the Alter Context request

A DCERPC message common header has the following structure:

The four most significant bits of the Data Representation field (i.e., ones obtained by ANDing with the big-endian 0xF0000000) contain information about byte order. If these bits are all zero, then the DCERPC message is big-endian encoded; otherwise, it is little-endian encoded.

Of importance to this report is the lastfrag flag (0x02) in the Packet Flags field. If set, the given fragment is the last one of a multi-fragment transmission.

DCERPC Request Packets

In the request packets, the common header is followed by the packet type-specific fields. For Bind and Alter Context the Type Specific Data field will be set to the following structure:

Of importance to this report is the Presentation Context List, which has the following structure:

where each Presentation Context Element is defined as:

and syntax as:

DCERPC packets may include an optional authentication trailer (also known as an authentication verifier) that contains authentication and/or authorization data. The trailer is present if and only if the auth_len header field is non-zero and set to the length of the trailer in bytes. The common authentication trailer has the following format:

Note, that auth_len in the common header only indicates the length of the auth_value, not the entire trailer, which has 8 additional bytes for static fields.

libdcerpc.so supports the following authentication types with their corresponding IDs:

— GSS-API with SPNEGO mechanism (0x09)
— NTLMSSP (0x0a)
— GSS-API with Kerberos mechanism (0x10)
— Netlogon secure channel (0x44)

This report relies on the first mechanism (0x09) in the following explanation and vulnerability demonstration. Note, that the selected type is not part of the vulnerability itself and is only used to demonstrate its impact.

GSS-API, SPNEGO, and SRP

When the auth_type field of the authentication trailer is set to GSS-API with SPNEGO mechanism (0x09), the auth_value field holds the ASN.1 encoded GSS-API data payload with the following structure:

When the mech field has a value of Object Identifier (OID) “1.3.6.1.5.5.2”, the GSS-API data represents a Simple and Protected GSS-API Negotiation (SPNEGO) message., which allows the client to negotiate the specific authentication mechanism with the server. mechTypes holds a list of OIDs of the authentication mechanisms supported by the client (e.g., Kerberos, NTLM, etc), and mechToken is the initial token for the first mechanism in the list.

One of the mechanisms that can be negotiated with vCenter's services is Secure Remote Password (SRP). The use of this mechanism with GSS-API is not well defined, but references to it can be found in VMware's Project Lightwave. A “made up” (i.e., not officially registered) OID “1.2.840.113554.1.2.10” is used for this mechanism, and the mechToken for it has the following pseudo-ASN.1 definition, reconstructed from the Lightwave source code:

where mechType is set to OID “1.2.840.113554.1.2.10”, ver_maj and ver_min are set to 1 and 0 respectively, userName is a valid User Principal Name (UPN), for example, "[email protected]", and publicValue is a large client's public value (referred to as A in RFC 2945).

The SPNEGO SRP response token can be defined as follows:

Here, publicValue is a large server's public value (referred to as B in RFC 2945).

DCERPC Response Packets

DCERPC response packets (i.e. those sent from the server back to the client) have a structure similar to the request packets. They start with the common header followed by packet-type specific data fields. The response packet types corresponding to the Bind and Alter Context request packets are Bind Acknowledgement, Bind Negative Acknowledgement, and Alter Context Response. Of these three, this report is only concerned with Bind Acknowledgement and Alter Context Response: Bind Negative Acknowledgement is only generated in case of an error, which should be avoided.

Both Bind Acknowledgement and Alter Context Response have the same structure:

The fields of importance here are Secondary Address, Presentation Result List, and Authentication Trailer. Secondary Address, in this case, is the target service's port, for example, "2012" for vmdird, including the null-terminator and prefixed by a 2-byte length integer. Presentation Result List, for each element in the request's Presentation Context List, contains a 24-byte result, plus 4 bytes for static fields. The authentication trailer's structure is the same as in the request. Note, that for the SPNEGO SRP mechanism described above the trailer contains a large authentication value.

Further Details on the Vulnerability

An integer underflow vulnerability has been reported for VMware vCenter Server. The vulnerability is due to a lack of validation of the calculated response header size used in subtraction.

Two types of request packets lead to this vulnerability being triggered: Bind Acknowledgement and Alter Context Response. As opposed to other packets (and, consequently, fragment buffers) there is no size restriction on these packets: while all other types can have up to 4096 bytes of data (which makes the fragment buffer go up to 4158 bytes), these packets have no such limit. This behavior can be observed in the receive_packet() function.

libdcerpc.so's operation is based on protocol state machines. When a packet is received, for the state machine corresponding to the given client, and event is generated. That event indicates what action has to be taken next to proceed with the protocol flow. Depending on the event, the received packet is passed to one of the handlers. In normal operation, for Bind packets, the handler is do_assoc_action_rtn(), and for Alter Context - incr_do_alter_action_rtn(). Both functions, eventually, call the actual packet processors responsible for the construction of the response: do_assoc_req_action_rtn() and do_alter_cont_req_action_rtn(), respectively. For the former to be reached, there is a restriction: either the lastfrag flag must be set or the minor RPC version must be 0.

From this point, we will focus on the do_assoc_req_action_rtn(); do_alter_cont_req_action_rtn() has an almost identical flow with some minor changes.

This gives us a restriction on the number of the Presentation Context List elements. If set to maximum, 169, the returned size of the Presentation Result List is 4060 bytes, which, together with the prior contents of the response buffer, takes 4092 bytes.

Assuming no error was returned, the vulnerable rpc__cn_assoc_process_auth_tlr() function, responsible for processing the request's authentication trailer and filling in one for the response, is called next, with its header_size parameter set to 4092, and auth_len parameter set to 4096 - 4092 = 4.

To reach the vulnerable part of the function, the following conditions must be met.

First, the request's auth_len must not be zero and the authentication trailer must not span beyond the beginning or the end of the packet.

Second, RPC_CN_AUTH_CVT_ID_WIRE_TO_API() must not return an error. This function converts the authentication type taken from the packet into the internal representation; so, using a valid type, for example, 0x9 for SPNEGO, is sufficient to pass this check.

Next, RPC_CN_AUTH_INQ_SUPPORTED() must return a positive result for the selected protocol. This function ensures the selected authentication type is supported by the runtime. Again, SPNEGO is allowed.

After that, a call to the RPC_CN_AUTH_VFY_CLIENT_REQ() function, responsible for verifying the request's authentication trailer, is made. This function is dynamic: the actual function being called depends on the selected authentication type. For SPNEGO, for example, it is rpc__gssauth_cn_vfy_client_req(). While this function does verify the authentication trailer, the credentials do not have to be valid, since an authentication rejection would also have to be placed in the response. Furthermore, for some protocols, for example, SPNEGO, multiple exchanges are necessary before completing credentials verification.

Finally, the response authentication trailer is being filled in. To do so, 8 bytes (trailer without auth_value) are added to the header_size, setting it to 4092 + 8 = 4100 and leaving no place for the auth_value. When the remaining space is calculated, however, an unsigned subtraction of 4100 from the maximum response size (4096) is performed, resulting in a large positive value 0xfffffffc, which is later passed into the RPC_CN_AUTH_FMT_SRVR_RESP() function. Same as RPC_CN_AUTH_VFY_CLIENT_REQ(), this function is dynamic, and the actual function being called depends on the selected authentication type.

Note, that the number of the Presentation Context List elements leading to a heap overflow is strictly 169: the upper bound has already been established above, and the lower bound can be determined from the fact that the resulting header_size is underflowing the maximum response packet size by only 4 bytes. Reducing the number of Presentation Context List elements even by one would cause the Presentation Result List to be 24 bytes less in length and, consequently, the header_size being 24 less, thus not leading to an underflow.

A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted DCERPC packet to the target server. Successfully exploiting this vulnerability could lead to a heap buffer overflow, which could result in the execution of arbitrary code in the context of the vulnerable service.

What follows is an explanation of how this vulnerability leads to a heap overflow, using the SPNEGO SRP authentication protocol as an example.

For SPNEGO, the RPC_CN_AUTH_VFY_CLIENT_REQ() function call results in control being passed to the rpc__gssauth_cn_vfy_client_req() function. This function, in its turn, calls the gss_accept_sec_context() library function which returns an output_token containing a response auth_value. If any error occurs, the length of the output_token is set zero. This token is then saved into the krb_message field in the security context associated with the client.

While for other protocols the token may be small, for SPNEGO SRP it contains, as described above, a large server's public value.

When, eventually, the RPC_CN_AUTH_FMT_SRVR_RESP() function is called, control is passed to the rpc__gssauth_cn_fmt_srvr_resp() function with auth_value_len pointing at a large positive value 0xfffffffc, and auth_value pointing at the end of the response buffer. This function is responsible for copying the contents of the krb_message field to the auth_value, but only if there is enough space. To ensure this, the function first compares the length of the krb_message to the value at auth_value_len. Given that auth_value_len points to a value resulting from an integer underflow, and the comparison is unsigned, this check always passes. Next, the krb_message's contents are copied to auth_value, which, again, does not have any free space left. For SPNEGO SRP, which has a large response token in krb_message, this leads to heap buffer overflow and heap corruption.

Generic Attack Detection

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic over ports 2012/TCP, 2014/TCP, and 2020/TCP (DCE/RPC).

The detection device must monitor DCE/RPC traffic looking for the messages with Packet type set to Bind (RPC_C_CN_PKT_BIND, 0x0b) or Alter Context (RPC_C_CN_PKT_ALTER_CONTEXT, 0x0e). If found, the detection device should check the auth_len field to be greater than zero. If so, the Number of Context Elements (n_context_elem) byte must be inspected. If it is greater than or equal to 169, the traffic should be considered suspicious; an attack exploiting this vulnerability is likely underway.

Conclusion

This vulnerability was patched by the vendor in June. At the time of the patch release, there was a fair amount of attention paid to this vulnerability. However, to date, there have been no attacks detected in the wild. As seen above, exploitation will not be straightforward. Still, this is a critical vulnerability and should be addressed by applying the vendor-supplied patch. If you are not able to apply the update, you can also filter malicious traffic using the information provided in the section entitled Attack Detection.

Special thanks to Grigory Dorodnov and Guy Lederfein of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

Reading Time: 4 min Discover how automation has revolutionized email security. Learn about the benefits of AI, threat intelligence, and tools like PowerDMARC in safeguarding your inbox from phishing, spam, and malware.

The post The Role of Automation in Protecting Email Systems appeared first on Security Boulevard.

为深化情报学领域的人才培养战略，激发学生对开源情报分析的热情，强化学生在数据采集、深度分析及情报应用等方面的综合技能，特举办“第二届全国大学生开源情报数据采集与分析大赛”（OSINTDCAC 2024）。

The company has assessed four of the five disclosed vulnerabilities as being of high to critical severity.

六重技术手段构建以“数据”为中心的综合防泄漏解决方案。

BlackByte ransomware operators are exploiting a recently patched VMware ESXi hypervisors vulnerability in recent attacks. Cisco Talos observed the BlackByte ransomware group exploiting the recently patched security flaw CVE-2024-37085 in VMware ESXi hypervisors in recent attacks. The flaw CVE-2024-37085 (CVSS score of 6.8) is an authentication bypass vulnerability in VMware ESXi. At the end of July, […]

Discover the key differences between SOC 2 and SAS 70, and learn why SOC 2 is the modern standard for ensuring data security and compliance.

The post SOC 2 vs. SAS 70: A Comprehensive Comparison appeared first on Scytale.

The post SOC 2 vs. SAS 70: A Comprehensive Comparison appeared first on Security Boulevard.

The emails impersonate well-known companies in the industry, fooling the victim into thinking they are communicating with a legitimate entity.

当今社会，随着互联网和移动通信技术的飞速发展，电信网络诈骗犯罪活动呈现出高发态势，诈骗手法层出不穷，给公众的财产安全带来极大威胁。

27日，公安部在新闻发布会上表示，近年来，公安机关积极践行全球安全倡议，加大与世界各国执法部门的合作力度，与外国执法部门建立了一系列合作机制，开展了一系列打击跨国犯罪联合行动，强化我海外利益保护，坚决维护我国家主权、安全和发展利益。

近年来，人工智能技术快速发展，在赋能人类社会经济进步的同时也带来安全隐患和风险挑战。既要促进人工智能技术发展和应用，又要确保其发展过程中的安全性、可靠性和可控性，构建人工智能治理体系的紧迫性日益凸显。

当前，信息技术革命日新月异，互联网为人民群众生产生活、交流交往、创新创造提供了新平台、新空间，也为推动文明继承和发展、促进文化弘扬与繁荣提供了新载体、新机遇。

8月27日，中欧数据跨境流动交流机制第一次会议以视频方式举行。中国国家互联网信息办公室副主任王京涛和欧盟委员会贸易总司总司长萨宾·韦恩德出席开幕式并致辞，正式宣布建立中欧数据跨境流动交流机制。

8月28日，2024年中国网络文明大会在成都举行。中共中央政治局委员、中宣部部长李书磊出席论坛开幕式并发表主旨演讲。

8月28日，由国家数据局主办，贵州省人民政府承办的2024中国国际大数据产业博览会（简称“数博会”）在贵州省贵阳市隆重开幕。