G DATA discovered a critical security flaw in the famous malware analysis framework „Cuckoo Sandbox“ this week. The open source program is a worldwide common tool that is used by many anti-virus researchers to analyze malware. The vulnerability is classified by Ralf Benzmueller, head of G DATA Security Labs, as extremely critical, since this could allow computer malware to break out of the safe analysis environment.

G DATA contacted the Cuckoo Sandbox developers immediately – an update of the tool is available since Wednesday.

“Cuckoo Sandbox is used by many AV researchers around the world. The bug discovered by our team may result in malware breaking out of the protected analysis environment. Worst case scenario: an infection of the host computer itself would be possible”, said Ralf Benzmueller, head of G DATA Security Labs. “We contacted the developer immediately and advise research institutions to immediately install the program update that is provided by Cuckoo Sandbox since Wednesday.”

Technical description

On the host side the handler for the TCP/IP protocol contains a class for handling the file uploads that is called when the client sends a line with the string “FILE“. The FileUpload-class then reads the next line where it expects to find a relative path. Comments in the source code of Cuckoo Sandbox hint that expected strings would be “shots/0001.jpg or files/9498687557/libcurl-4.dll.bin”. These strings are split up into their relative directory part and filename for further sanitation.

The expected relative path is sanitized in a way that no path traversal is possible: The whole path must not contain a ‘./’, which could be used to traverse the folders upwards.

A list of blacklisted paths can be defined, which will be matched against the relative folder part. Yet it contains only the string “reports/”.

If those checks are passed, the absolute base path of the storage where all reports are saved (e.g. “/home/cuckoo/Desktop/output/”), as well as the relative folder part are given to a function which will create the folders, if they do not already exist.

As a next step the absolute target path of the file that is about to be uploaded is built by using Python’s built-in os.path.join-function. The paths to be joined are the absolute base path and the assumed relative file path that was sent by the client:

Although security checks are in place, it is still possible to sneak by these checks: The function os.path.join does join the path properly, if the second argument is a relative path. But what happens if we manage to supply an absolute path instead? The documentation covers this case, but it is not necessarily the behavior expected by the programmer:
“[…]If any component is an absolute path, all previous components […] are thrown away, and joining continues[…]” https://docs.python.org/2/library/os.path.html
This effectively means in our case, that the first argument is completely ignored, if the second argument is an absolute path – now remember that the second argument is the string sent by the client-system.
When the path which the sandbox client sends matches the following criteria, an attacker can write the file to any absolute path on the system, given that Cuckoo Sandbox has the appropriate rights:

• Absolute path
• Does not contain the string “reports/”
• Does not contain the string “./”

Given the circumstance that the malware running on the analysis system can take control of the whole system, it can easily parse the “analysis.conf” of Cuckoo Sandbox to get the IP and Port where the Host is listening. It can then connect to the host and send it an arbitrary file which is written to an arbitrary path, given the above mentioned restrictions.

Exploitation

The “analysis.conf” file does not only supply the port and IP to the client system, but also contains additional information about the sample. One part of this is the path of the malware on the host system. In our proof-of-concept for a host machine running Ubuntu we assume that the malware is located in the user’s home folder. We will then try to write over the user’s .bash_aliases in order to turn the exploit into a command execution, which will trigger the next time a shell is started on the host.

The following code shows one way of exploiting the vulnerability:

Download PoC code as text file.

This exploit obviously only works if the malware on the host system is located in the user’s home folder, so the path is “leaked” into the analysis client. But as the mentioned bug allows you to write as many files to as many locations on the host as you want, you can even brute force the locations.
One good assumption of the Cuckoo Sandbox user name can be taken from the installation manual of Cuckoo Sandbox:
sudo adduser cuckoo

Probably there are even more effective solutions for what file to write to which location in order to turn this into a command execution, but as a proof-of-concept it should suffice to show the severity of this bug.
The actual effects imposed by this sandbox evasion may depend on several factors, primarily the separation of networks, hosts and users. If the Cuckoo sandbox host process is run by a low privileged user, and if the host is used for no other work and is located in a separate network you are less troubled than the other way around. But especially for small companies and independent researchers, this is less likely the case.
You might extract some mitigation strategies from the description above. But our recommendation is: If you use Cuckoo Sandbox and did not yet upgrade your systems, do it now!!!

For more technical information please visit the G-Data security blog :

https://blog.gdatasoftware.com/blog/article/cuckoo-sandbox-evasion-poc-available.html