agent.py allows a Privilege Escalation through XMLRPC methods

[remi-armature]

Methods Agent.add_analyzer() and Agent.execute() can be triggered together by an analyzed sample in order to leverage its privileges by uploading a malicious analyzer.py

They shouldn't be callable after the sample status changed to STATUS_RUNNING

[jbremer]

So.. malware can run more malware in the same VM?

[remi-armature]

Yes, then trick the guest VM into not behaving as a normal environment (Killing the Agent, sending false report information), or using the guest for illegitimate traffic (proxy for attacking sensitive equipment).

[botherder]

I am really amused by this. I'm sorry if I'm being blunt, but I just can't act any differently in the light of this: https://www.exploit-db.com/exploits/40043/ Those are not vulnerabilities, and that's most definitely not a "Privileged Remote Code Execution" exploit.

Let me just break it out:

1. Firstly, agent.py has no particular reason to be run as Administrator.
2. Secondly, in my vocabulary it isn't any "Privileged Remote Code Execution" to be able to run additional code locally. In a disposable VM. Supposed to be infected. With malware.
3. Even if agent.py would be run as Administrator, you'd gain "privileged" execution inside the VM you're already running in, to what benefit? Have you got a virtual machine escape?
4. If you configure your virtual machines (that are supposed to be infected with malware) to be able to access other parts of a sensitive network, then it's your fault really.
5. As for your "Optional true Remote Code Execution", other computers on the network would be able to execute code on a disposable VM intended to be infected with malware, and?
6. The virtual machines are forcibly shutdown regardless of what happens in the guest after some minutes anyway.

If this is a marketing stunt, it's a poorly executed one.

[remi-armature]

Hello botherder! According to my point of view (which is quite personal), the aim of a malware analysis sandbox is to get the most realistic report from the behavior of a processed sample. So when it is bypassed, screws up the system. Furthermore, several security vendors rely on Cuckoo Sandbox for industrial queued sample controlling. This is, in my humble opinion, an error. My company also plans to implement Cuckoo Sandbox for the same purpose, and I am rather against that.

Here, the problem is the Sandbox itself can knowingly be used (+targeted) for malicious actions, such as shadow pivoting. I also believe it is an error to rely on a process which has the exact same privileges as the sample for logging. How then can it be sure to keep logging without biases?

Concerning the marketing thing, it is not in my intention at all to make some noise about this. My purpose was first to create an issue for you could fix it in no time (controlling the status before calling xmlrpc registered methods), and then to disclose a small PoC, instead of keeping an exploit secret.

FYI I have got a few other vulnerabilities (DoS on supervisor) that I plan to share as soon as I am achieving a reliable PoC.

If you really want to stay informed before exploits are released, just tell me and I'll do my best to provide you with the required fix-time.

Kind Regards, Rémi

[botherder]

You can kill the agent. You can terminate your process. You can shutdown the virtual machine. You can detect the virtualized environment and launch a fork bomb. You can also spawn 5000 image viewers displaying pictures of kittens, if you wish. If you intend to fuck around with the guest system, you have 1000 ways to do so. None of them will have any permanent effect on the sandbox, and none of the ones you described represent any threat to the security or the stability of the sandbox.

When you openly express that it's wrong for people to rely on Cuckoo, and at the same time go public with a fear-mongering "Proof of Concept" that isn't really proving any real security issue, it's a deliberate reputational attack in my opinion.

Again, I'm sorry, but you got no exploit. If in the future you will have any, I would invite you to follow standard responsible disclosure procedures instead.

[remi-armature]

I fear you still don't get the real problem on this issue: we basically don't care about how compromised the Guest Machine can be, as long as everything gets recorded. Nonetheless, the interest of such attack would be, in my opinion, that the malware sample can access a fully privileged environment instead of a limited one. If we suppose the Agent is running as Administrator, we have to agree that it WILL:

• Close the Agent, or lie about the analysis
• Modify local firewall settings
• Pivot for third party equipment attacks - Sensitive targets? - (you may assume there's no internet access, and a hardened environment, but is it mandatory?)
• Duplicate into parallel Sandbox Guests to screw everything up. The critical timeout will be the only limit (but you know an attack can last a few nanoseconds), so if we find ourselves into an expensive blocking appliance running many simultaneous analyses, it may cause some... trouble!

On the contrary, if the Agent is not supposed to run as Administrator, my opinion is that you should make a clear statement inside the Cuckoo Documentation. Still, it means the supervisor is relying on a non-privileged process to trace and manage an Admin or at least equally privileged process. A novice sysadmin would immediately find out the structural problem it implies. However and for the record, I was brought to operate a few security audits on scopes including Cuckoo Sandboxes. No need to say the Agent was running as Administrator on all of them. So to be very clear on this question, two cases: 1) agent has admin rights : a Privilege Escalation will be working smoothly... 2) agent has no admin rights : ANY malware could kill pythonw.exe first to escape further detection, making cuckoo completely useless...

Your first answer was lying on the assumption that sandbox systems are located in strongly hardened environment, which is absolutely not obvious: If, for a moment, we suppose it is not the case, or that Cuckoo Sandbox can be used by private researchers (which I support), we must admit a malware specifically targeting Cuckoo Guest Machines represents a real threat to its very home network at least. Your argument recalls me the one used by data specialists, saying Remote Code Execution on ElasticSearch nodes are stupid, as nodes are supposed to run inside compartmentalized clusters...

Now, if we assume the sandbox has no access to the internet nor any local network, you admit staged malware are condemned not to raise any accurate alert.

You seem not to care at all about easy bypasses while the entire solution has only one aim: Logging operations and possibly evaluating a dangerous sample. Sorry if I cannot understand your position there, but spending that amount of energy on Twitter and right here, just for a vulnerability you are judging yourself as non-existing appears kind of obscure to me.

We don't care about the "people relying on cuckoo" fact. Just fix this bug and improve the solution if it really matters that people rely on your project.

[doomedraven]

omg, you can do that on any sandbox, just figurate how they communicate and kill communication, fake data, whatever, about "escalation", pivoting or whatever you mentioned, is so easy as "learn how to use tool correctly or don't use it" if you have proper configuration you don't have any of this problems.

is like leave a child with metasploit with old plugin autopwn, set host 0.0.0.0 and pwn internet, and then say it wasn't me when police will come to your home

[xdanx]

Hi Rémi,

My 2 cents:

Pivot for third party equipment attacks - Sensitive targets? - (you may assume there's no internet >access, and a hardened environment, but is it mandatory?) Duplicate into parallel Sandbox Guests to screw everything up. The critical timeout will be the only limit >(but you know an attack can last a few nanoseconds), so if we find ourselves into an expensive >blocking appliance running many simultaneous analyses, it may cause some... trouble!

I am pretty sure the Cuckoo docs mention to run each separate Sandbox Guests within their own host-only network connection, so they cannot interfere with each other. Not to mention that Sandbox internet access should be only through Tor.

Now, if we assume the sandbox has no access to the internet nor any local network, you admit >staged malware are condemned not to raise any accurate alert.

Wrong here: you can give VM access only through Tor, limiting access to any "local" networks.

We don't care about the "people relying on cuckoo" fact. Just fix this bug and improve the solution if > it really matters that people rely on your project.

I think it is absolutely obvious that whatever mode you are running agent.py module in (Administrator or local user) the malware could get root access to your machine and then mangle the analysis.

[botherder]

If the agent.py is running as administrator, both the analyzer and the subsequent malware process should already be launched with administrator privileges. It is up to the user to configure the Guest system in whichever way he pleases.

You can kill pythonw.exe. You can also ExitProcess(). Or shutdown the virtual machine. Or whatever else. That's how it goes with sandbox detection/evasion.

And look, Cuckoo doesn't come prepackaged in an appliance as a commercial solution. You are supposed to set it up and configure it. If you are running a malware analysis sandbox and have no understanding of the involved risks of running malicious code in a network, it isn't fault of the software.

The documentation does recommend to run the guest in host-only network properly filtered and configured: http://docs.cuckoosandbox.org/en/latest/installation/guest/network/

The bottom-line being, there is no Remote Code Execution vulnerability. You are already executing malicious code with the privileges the Guests are configured with, in a network ecosystem you configured.

[remi-armature]

Okay then <3

[mrheinen]

The agent can be modified / reconfigured by the malware and this is not considered an issue because:

• this will be detected in all cases ?
• the agent is considered "untrusted" anyway ? Or from the moment malware is executed ?

I read through this issue and those questions stuck with me. Maybe you can clarify for completeness (and/or people like me ;p)

[sanderfoobar]

Look, there are 10000 ways to mess with the agent; Remi found one (and proudly posted it as an exploit - hilarious) - fact remains that cuckoo or any other sandbox software is by heart a tool that helps with the analysis of malware, it is up to analyst to 1) correctly setup the tools 2) interpret and check the integrity of the results.

Perhaps Remi mistakes malware analysis for a anti-virus scanner.

[botherder]

There's nothing significant you can do to the agent, besides causing an analysis to terminate. That is a well known possibility.

We made the engineering choice of instrumenting the Guest for simplicity and flexibility. Obviously that opens avenues for detection and evasion. Everything that executes inside an infected virtual machine is obviously not trusted. However, events are recorded on-the-fly, and if something interferes with the instrumentation, it should be noticed.

If the problem is that the instrumentation can be too easily spotted, that's a whole different matter. But it is not a security issue, executing code in the Guest is not an attack surface (it is rather intended behavior), and we should discuss it elsewhere.

If you guys want something to audit, then it should be the ResultServer in guest.py, cause that could seriously lead to potential security issues, as it did in the past: https://cuckoosandbox.org/2014-10-07-cuckoo-sandbox-111.html

That being said, @remi-armature, I apologize if I have been offensive anywhere. I do believe however that you mischaracterized (and/or misunderstood) the nature of your finding. I believe processes inherit privileges, and that being able to execute code in the Guest is expected behavior of the analyzed malware. If we want to open discussions instead on potential detection (which I concur, the open agent server provides) and evasion methods and improvements in the documentation related to hardening, I'm happy to do so in appropriate separate tickets.

To everybody: vulnerability reports are very welcome, but you're invited to follow standard responsible disclosure procedures, so that critical issues can be analyzed and managed with the appropriate care instead of being just dumped online.

[gregtampa]

it also allows malware to detect it is running in a sandbox env. and can be set to run differently. since apparently no f are given, thus is why cuckoo won't be used by me and others, 2017 and still not fixed... please uninstall cuckoo

[doomedraven]

LOL instead of come with boring comments, come with solution, ideas, whatever

[xdanx]

it also allows malware to detect it is running in a sandbox env. and can be set to run differently.

Think of this in another way: From the malware point of view, maybe sometimes it's not a good idea to detect if you are running in a sandbox env and then just sys.exit(), because then legit people could set their operating systems to "look" like sandbox environments.

[jbremer]

First of all, this is not a real vulnerability. Secondly, we are actually working on a fix in this regard - but it takes quite some as we'll be hiding this and similar exposed elements from within our upcoming zer0m0n-based kernel driver.