Introduction
The recent VMware VMSA describes four new CVEs affecting VMware vRealize Log Insight. Three of these CVEs can be combined to give an attacker remote code execution as root. This vulnerability is exploitable in the default configuration for VMware vRealize Log Insight.
- CVE-2022-31704: VMware vRealize Log Insight broken access control Vulnerability
- CVE-2022-31711: VMware vRealize Log Insight contains an Information Disclosure Vulnerability
- CVE-2022-31706: VMware vRealize Log Insight Directory Traversal Vulnerability
VMware vRealize Log Insight is used across enterprises to collect logs and provide analytics. This vulnerability poses moderate risk to organizations, allowing attackers initial access, if exposed to the internet, and the ability for lateral movement with any stored credentials.
We have successfully reproduced this exploit and would like to provide additional insight into the vulnerability so users can determine if they have been compromised. In this post we discuss the following indicators of compromise:
- Log entries on the Log Insight server
- Network traffic to or from the Log Insight server
Additionally, we will be releasing a technical deep dive describing the inner workings of this vulnerability in the near future.
Log Entries IOCs
The Log Insight server stores a logs in /var/log/loginsight/runtime.log. Evidence of exploitation can be found by searching for log entires with the following format:
[2023-01-27 16:51:32.784+0000] ["Thread-73075"/192.168.4.133 INFO] [com.vmware.loginsight.daemon.commands.SystemCommands] [Downloading http://192.168.4.60:8080/exploit.tar to /tmp/exploit.pak]
The URL, and filename will likely be different, however the filename will always have the format /tmp/<fiilename>.pak. Also note that this log may be legitimate. To determine if an attack has occurred, an administrator should evaluate the URL to determine if it is a legitimate download URL.
Log Entries
Network Traffic IOCs
See below for a packet capture of the exploit traffic. In this example, 192.168.4.60 is the attacker’s machine and the 192.168.4.133 is the Log insight server. This attack involves two network protocols Apache Thrift and HTTP(S).
Exploit pcap
Inbound Traffic to Ports 16520 – 16580
This attack exploits the Thrift services that typically run on ports 16520 through 16580 on the Log Insight instance. Any unrecognized traffic to these ports should be cause for concern.
Outbound Traffic to Suspicious IP addresses
This attack requires that the Log Insight instance makes an outbound connection to an external server to download a malicious payload. Any connections from the Log Insight instance to unrecognized IP addresses should be further investigated to determine if an attack has occurred.
Attacker Mindset
This vulnerability is easy to exploit however, it requires the attacker to have some infrastructure setup to serve malicious payloads. Additionally, since this product is unlikely to be exposed to the internet, the attacker likely has already established a foothold somewhere else on the network. This vulnerability allows for remote code execution as root, essentially giving an attacker complete control over the system. If a user determines they have been compromised, additional investigation is required to determine any damage an attacker has done.
Gaining access to the Log Insight host provides some interesting possibilities to an attacker depending on the type of applications that are integrated with it. Often logs ingested may contain sensitive data from other services and may allow an attack to gather session tokens, API keys, and PII. Those keys and sessions may allow the attacker to pivot to other systems and further compromise the environment.
Shodan data shows that there are 45 instances publicly exposed on the internet. This is unsurprising as this product is intended for use in an internal network.
Patch Now
VMware has released patches and workarounds for these vulnerabilities. We expect some VMware clients to have already patched, but given how slow enterprise patch cycles can be, we expect that there are many who have not yet patched.
We encourage all VMware users to heed the VMWare advisory and patch or apply the workaround immediately.
