VMWARE ARIA OPERATIONS VULNERABLE TO COMMAND INJECTION

VMware aria operations have been reported to be vulnerable to command injection. CISA reported it amongst a list of vulnerabilities CVE’s, on the 22-June-2023.

The vulnerability, which has been assigned a CVE-2023-20887, contains a command injection vulnerability that allows a malicious actor with network access (on the network), to conduct malicious actions on the network. 

vmware_aria_operations.png

Image source: fixitgearware.

The malicious action which a command injection attack, will give the threat actor the power to gain access to the system remotely.

It is known that VMware Aria operations for network comprises of both SaaS (Software as a Service), and on-premises solution (software that runs in in-house infrastructure, powered by servers within the local network).

When the command is injected, the product (VMware), constructs all part of the command using an external-entity input from an upstream component (the server of the attacker), however it does little to no code neutralization, which allows special elements that could modify the intended command when it is received to be part of the system that it can affect (downstream).

How does command injection work on the vulnerable VMware?

The question that comes to mind, is how does command injection works on the vulnerable VMware.  Firstly;

  1. The attacker codes send data from an untrusted source into the application.
  2. The data is a part of a string that is called and executed as command by the application.
  3. On successfully executing the command, the attacker obtains a super privilege (super administrator), which they would not have had or should not be possible.

It is known that various protocols (e.g., tcp/ip, https, smtp, pop3 etc.), are built on their own custom command language. However, various os shell commands, are constantly discovered and as well targeted by threat actors.  Developers who often most time do not practise secure coding, may not realise that these custom codes built by them are also vulnerable to attacks.  

Over the years, command injection has been discovered to be common with wrapper programs (programs or code that literally wrap around other program components).

According to CWE-1000, the nature of the attack, and the name of the attack, was properly defined in accordance to the type-ID (class associated with it). The class C describes the attack to be independent of any specific language or technology, also makes it more specific than a pillar weakness, and general in a base weakness, which describes the behavior, property, and resource.

While the class B which is mostly independent of the resource or technology, but with sufficient details to provide specific methods for detection and prevention. It is also described in terms of behavior, property, technology, language (code), and resource.

The likelihood of Exploit:

The likelihood of exploit, is considered high, as the exploit which allows the program to accept a filename as a command line argument, and display the contents of the file back to the user.  The program which is installed to setuid root which is intended for the use of a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system.

code-exploit.png

Image source: cwe.mitre.org

Code Explanation:

  • The main function receives:
  1. int argc: an argument count.
  2. char** argv: receives a double pointer argument vector.
  3. char cmd [CMD_MAX] = “/usr/bin/cat “; here the code receives an array CMD_MAX of object cmd in characters reason for char, and execute “/usr/bin/cat”;
  4. strcat concatenates two functions first the array of the object cmd, and then the argument vector array of 1 reason for: argv [1];
  5. The system, then returns the object cmd, in this case the attacker gains access to the shell command

This will allow the attacker to run a series of other commands to carry out their task. Take for example, if a user specifies a standard file-name, the call works as expected. However, when an attacker passes a string argument in the form of “; rm -rf /”; the call to the system () fails to execute cat due to lack of arguments and then plows on to recursively delete the contents of the root partition. argv [1]; is a very long argument, which also might lead to a buffer overflow.

The CWE-1003 describes the relevant view in terms of weakness for simplified mapping of published vulnerabilities, in the improper neutralization of special elements of output that is used by a downstream component (Injection).

The architectural concepts are described in the CWE-1008, on how the inputs are validated.

The weakness and high-level categories that are related to this weakness is described in the CISQ quality of measures (2020) of number CWE-1305, and the CISQ Data Protection Measures of CWE-1340.

The Implementation phase:

“The realization that the weakness is caused during implementation of an architectural security tactic. “– cwe.mitre.org

AFFECTED PLATFORMS:

As at the time of detecting the security flaws, the vulnerability hasn’t been tied down to mode of program exploit. There is no specific programming language or technology that the weakness appears on an instance.

The Scope:

 The exploit is said to undermine confidentiality, Integrity, and availability.

The Impact:

When an attacker successfully injects a character, for example a “;”, it delimits the end of one command and the beginning of another. This makes it possible for an attacker, to insert an entirely new and unrelated command that was not intended to be executed.

There are various demonstrative examples of what the harm the exploitation might cause if executed, as described further on cwe.mitre.org

Potential mitigation:

CWE proposed a list of potential mitigation as described below:

  1. Architecture and Design: suggested that if it is possible that using library calls than external processes to recreate the desired functionality.
  2. Implementation: Making sure that all external commands called from the program are statically created.
  3. Input validation strategy: The programmer should assume that all inputs are malicious, and hence should adopt the use of “accept known good” input validation strategy, whereby a list of inputs are defined and must conform to the specifications, or transform it into something that does.

The programmer should consider proper sanitization when performing input validation, and consider all relevant properties such as type of input, length, acceptable range of values, missing of extra inputs, syntax, and consistency across related fields, while conforming to business rules.

Example a business rule logic, “Aircon1” may be valid in terms of the syntax, as it only contains alpha numeric characters. However, it might not be valid if the input is expected to accept only products models such as Hisense, Panasonic, Thermacool.

Programmers should not rely solely looking out for malicious inputs, as they might likely miss at least one unacceptable input, if the code environment changes in the future, which in turn will give threat actors, enough room to bypass the intended validation.  Setting up a deny-lists can be very useful in detecting potential attacks or determining the inputs that are malformed and allowing them to be rejected outrightly.   

  1. The Operation of Run time: Run time policy enforcement may be used in an allow-list method which will prevent the use of any non-sanctioned commands (commands that are not allowed to be executed as stated in the run-time policy).
  1. System Configuration: Setting up rules and permissions on files stored on the system, preventing the user from accessing/opening privileged files.

How is the vulnerability detected?

The vulnerability can be detected using automated static analysis, which is also known as SAST (Static Application Security Testing), commonly used before a code is deployed. This will allow the detection of instances of the weakness by analyzing the source code or binary compiled code.

This is achieved by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that links “sources” (origin of the input), with sinks (destinations where the data interacts with external components, a lower later such as the OS, etc.).

 

 

 

Put your comments below in the comment section on your thoughts about this.

Find this article and information helpful? Show some love and support  “Click-Here”
0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments