Multiple remote command injection vulnerabilities in the Veil-Evasion framework's RPC have been discovered by Cylance’s security researchers.
Veil-Evasion is a tool used to generate payloads that bypass traditional antivirus (AV) products during offensive security engagements, simulating a genuine attack. If a malicious actor manages to compromise a Veil-Evasion instance, they could potentially gain access to client networks being accessed and tested by the offensive security professional, with disastrous results.
Ensuring the security of offensive security tools is an imperative to developers and security professionals alike. Please note that all vulnerabilities discovered here were privately disclosed to the developers of Veil-Evasion, who responded in a highly responsible and effective manner.
What is Veil-Evasion?
Figure 1. Veil-Evasion V2.25
Veil-Evasion is a tool designed for penetration testers and red teams to simulate bypasses of common AV products. Tools like this are of high value to offensive security professionals, as they can be used to emulate a more persistent attacker who will try to bypass an AV system through trial and error. Without a tool such as Veil-Evasion, offensive security engagements would take longer and cost a good deal more.
Veil-Evasion can work on existing executables, or simply create a wide range of payloads with shellcode added to them. The majority of cases use a shellcode-based method, as the resulting payload has a better chance of evading antivirus systems.
Considering that a tool like this is used by professional organizations to simulate an attack by adversaries, it would make sense to allow a user to automate the generation of a payload from a central location. This allows it to be integrated into attack workflows, which lets offensive security professionals work more efficiently.
One feature made available by Veil-Evasion is a remote procedure call (RPC) for automating the generation of payloads. Those creating the malware use this RPC, though it is not accessed during the actual use of the malware, and the malware itself does not contact this RPC.
Veil-Evasion Vulnerabilities Discovered
Figure 2: Veil-Evasion starting remote procedure call
During research for an upcoming talk on man-in-the-middle attacks (where an attacker intercepts and/or alters communication between two parties who believe they are directly communicating with each other), I found myself testing out the Veil-Evasion RPC. This RPC is not enabled by default, but can be invoked with the call ‘veil-evasion –rpc’. During my testing, I noticed that this RPC listens in on 0.0.0.0:4242, allowing remote connections.
With this level of exposure and no form of authentication, I was compelled to start looking for ways to abuse this RPC. While it was already clear to me that a remote attacker could potentially leverage this exposure to force the Veil-Evasion server to generate payloads, which uses a good deal of computing resources and could likely cause a denial of service, there was undoubtedly so much more an attacker could do with this level of access.
Figure 3: Veil Evasion listening in on 0.0.0.0:4242
Given that Veil-Evasion is open source and written in one of my preferred languages (Python), I started analyzing the code. When auditing Python for security, I often start by attempting to identify ‘dangerous’ functions. These are essentially functions/classes which, if an attacker controls the input, can be used to gain access to the system running the Python code.
Here is a sample list of such ‘dangerous’ functions (some require additional functions to be considered dangerous):
- • commands.getoutput
- • commands.getstatus
- • commands.getstatusouput
- • compile
- • cPickle.load
- • cPickle.loads
- • eval
- • exec
- • execfile
- • marshal.load
- • marshal.loads
- • os.execl
- • os.execle
- • os.execlp
- • os.execlpe
- • os.execv
- • os.execve
- • os.execvp
- • os.execvpe
- • os.popen
- • os.popen2
- • os.popen3
- • os.popen4
- • os.spawnl
- • os.spawnle
- • os.spawnlp
- • os.spawnlpe
- • os.spawnv
- • os.spawnve
- • os.spawnvp
- • os.spawnvpe
- • os.startfile
- • os.system
- • pickle.load
- • pickle.loads
- • popen2.popen2
- • popen2.popen3
- • popen2.popen4
- • shelve.open
- • subprocess.call
- • subprocess.check_call
- • subprocess.check_output
- • subprocess.Popen
- • yaml.load
In Veil-Evasion itself, there were many uses of functions which make calls to the command line, such as ‘os.system’ and ‘subprocess.Popen’. If input is not sanitized, an attacker could potentially abuse these calls with some form of arbitrary input. After a short search, I found three instances where an attacker could do this through a remote connection to the RPC.
As part of the patch to resolve these issues, the Veil-Evasion developers made the RPC only available to a localhost connection. Additionally, the Veil-Evasion developers noted that a new RPC interface was in the works which aims to not only provide authentication, but to additionally protect against man-in-the-middle attacks.
Hyperion Module Vulnerability
The Hyperion module allows for obfuscation of an executable with the Hyperion crypter. This tool encrypts PE/ELF binaries to assist in evading AV detections. In Veil-Evasion, the Hyperion tool is called on the command line, supplying the file to encrypt as a parameter. At the time of discovery of the vulnerability, the file path was not being verified before being added to the command, and the command was being called in a way that would allow for more than one command to be executed.
The vulnerable call being made on Hyperion
Figure 4: Call being made on Hyperion
To resolve this issue, two changes were made to the Hyperion module. The first one ensured that the original_exe is actually a file path on disk that exists. The other utilizes subprocess.Popen's ability to be called with a list of arguments, which handles the escaping of arguments itself, thwarting command injection attacks.
An attacker could attack this call (before it was fixed) by setting the original_exe option to a string which allows a nested command call such as ‘$(rm -rf /)’. A proof of concept developed in Python 2.7 can be found here
PEScrambler Module Vulnerability
The PEScrambler module provides similar functionality to the Hyperion module, except it uses the PEScrambler obfuscation tool instead. Due to the high similarity to the Hyperion module, the attack and resolution are essentially the same.
Figure 5: PEScrambler module
A proof of concept
MSFVenom Shellcode Generation Vulnerability
MSFVenom is part of the Metasploit framework. In the context of Veil-Evasion, it generates shellcode with a variety of encoding options. MSFVenom can be called by a wide variety of modules to generate the necessary shellcode, and accepts options from the user to allow customization of the generated shellcode.
Unfortunately, the input for the options was not being sanitized, and allowed for an attacker to inject commands into the MSFVenom call. The vulnerable addition to the msfvenom commandcan be found here. This com mand is later called here.
An attacker can abuse this by setting the ‘msfvenom’ parameter in the request to the RPC to a nested command call, so long as the module being invoked supports shellcode generation. I have had difficulty exploiting this issue (although present) on certain older versions due to a bug where no modules tested supported shellcode generation.
A proof of concept can be found here.
Figure 6: Shellcode generation via Veil-Evasion
Unfortunately, this functionality allowed a user to modify msfvenom calls; the simple checks against them to ensure they are safe did not suffice. In order to resolve this issue, I supplied the developers with a method which will resolve this issue without a decrease in functionality.
Essentially, the options being input are parsed as if they were a shell script by the Python module ‘shlex’. Once parsed, each token is checked for gadgets which could be used to execute nested commands. This method can be found here.
Impact
Given that the Veil-Evasion tool is used by offensive security professionals to simulate AV bypasses, it is a high-value target for a malicious actor. This value, which I personally refer to as "backward propagating target value," is not based on what Veil-Evasion has to offer by itself, but a diminished value of what it potentially could be leveraged to access.
A simplified example of backward propagating target value could be used to describe the serial vulnerability of ‘Internet of Things’ devices. If an attacker is able to abuse a vulnerability in a networked home appliance, for example, a wirelessly-connected toaster, they could use that access as a gateway to launch man-in-the-middle attacks on the home network of a user (home networks rarely defend against man-in-the-middle attacks such as ARP cache poisoning), and could potentially infect the user’s personal computer by downloading an executable via the compromised network.
Once the home computer of the user is compromised, the attack could spread internally until it reaches the ‘crown jewels’ of the home, such as a work laptop being used at home. Once infected, the laptop would then be taken to work and connected to the company network, with potentially devastating results. So, while a vulnerability in an internet-wired toaster might not be considered a grave threat, it has a higher backwards propagating target value because of the leverage it could allow an attacker.
For a security professional, the consequences of such a compromise would be far more grave. Imagine an attacker manages to compromise a Veil-Evasion RPC server being used by a single penetration tester. This attacker could then start adding additional backdoors to the payloads being generated for use on the penetration tester's client sites. The attacker would then obtain access to the client networks that were being successfully (and deliberately) infected with these AV evasion payloads. Not only would the attacker then have direct access to the client network, but their further operations inside that network would be considered the 'safe' actions of the penetration tester, and not treated as an uncontrolled external compromise.
This could result in data theft from customers of the penetration testing firm and negative hits on the reputation of the testing firm, all while providing additional resources to the malicious actor which in turn could lead to unknown amounts of destruction.
Conclusion
Vulnerabilities in security tools, offensive or defensive, can have broad and far-reaching implications on those who use them. Ensuring the security of these tools is an imperative to provide the maximum level of security as an industry. When these vulnerabilities are identified, expedient resolutions are needed to reduce the impact on those affected. In this case, once notified, the developers of Veil-Evasion were quick and efficient at resolving the vulnerabilities.
