Blog.

Our friends at PolySwarm sponsored a Cure53 pentest of the latest version of Cuckoo Sandbox (at the time of writing version 2.0.6). While Cure53 didn’t identify any critical issues within the analysis aspects of Cuckoo, they did point out a few security issues in the overall architecture of it. Furthermore, they identified a couple of potential evasion techniques and related issues.

We’ve released an alpha candidate for version 2.0.7 of Cuckoo (which may be installed through pip install cuckoo==2.0.7a1) such that upgrading is already possible while we finalize some other changes for the official 2.0.7 release.

Furthermore, it should be noted that simply upgrading sflock in an existing Cuckoo 2.0.6 environment (by running pip install -U sflock) and restarting Cuckoo will already mitigate issues CSB-01-001, CSB-01-004, CSB-01-005, CSB-01-008, and CSB-01-010 - for more information on these issues, please read further.

The remainder of this blog post shows how we have tackled the issues, assuring our users that Hatching and PolySwarm are very serious about security within Cuckoo Sandbox and related open source projects.

The entire report may be found here: cure53-cuckoo.pdf.

A total of ten issues were found by Cure53, here goes:

CSB-01-009: Unauthorized access to Web & API

As Cuckoo Sandbox up until version 2.0.6 didn’t have any form of authentication, anyone could access a Cuckoo instance provided he or she can reach it through the internet. As an example, one may find various Cuckoo instances through Server: Machete Server @ Shodan - what is found within these search results may result in an entire blogpost on its own though.

We’ve implemented Bearer token support to the Cuckoo API. Users that upgrade their Cuckoo instance will not require a Bearer token for backwards compatibility reasons. New installations of Cuckoo automatically generate a random Bearer token which can be found in $CWD/conf/cuckoo.conf under the api_token field in the [cuckoo] section.

For the Cuckoo Web Interface we’ve implemented a secret page where a shared secret is used to authenticate & get access to the Cuckoo instance. By default a secret isn’t required - to remain backwards compatible - but one may easily enable it by setting the web_secret field in [cuckoo] of $CWD/conf/cuckoo.conf.

CSB-01-003: Webif reachable from inside a VM

On a default Cuckoo setup using VirtualBox (and a VM with IP address 192.168.56.101) the malware that’s being analyzed can reach 192.168.56.1, also known as the Cuckoo host. Therefore any services that aren’t listening to localhost or a specific network interface, but instead to 0.0.0.0 can be reached from within the VM - it should be noted that on a default Cuckoo instance, this is not the case.

This can be problematic depending on the exact configuration of the Cuckoo machine. While other software installed on the machine (e.g., database-related software such as MySQL/PostgreSQL and MongoDB - often used in Cuckoo setups) should normally listen only to localhost and therefore not reachable by the VM, this is not the case for the Cuckoo Web Interface itself.

Currently we have two mitigations for this problem: the Bearer API tokens for the Cuckoo API & authentication page for the Cuckoo Web Interface (see also CSB-01-009 above) and drop routing using the Cuckoo Rooter.

In a nutshell, the Cuckoo Rooter allows one to perform per-analysis network routing, i.e., one analysis a VM may be routed through Tor and the next analysis all of its traffic may be dropped (using drop routing). This last routing option also affects all non-Cuckoo traffic towards 192.168.56.1, effectively resolving issue CSB-01-003.

CSB-01-004 & CSB-01-010: Zip bombs as DoS

These two issues specifically target Denial of Service problems related to automatically unpacking potentially unsafe files and/or file formats. Especially for blackbox file formats such as .7z / .rar / .cab we as-is can’t predict the final filesize of a file. Therefore it may be possible to upload a small file which extracts to many gigabytes, essentially using up all server resources - CPU / memory / diskspace.

We have resolved these issues by imposing limits on CPU time and the amount of data that can be written to disk - by default two minutes of processing time may be used and 1GB of data may be written. These changes have been implemented in dbb5cd..47c02c @ zipjail and 5d511c @ sflock and may be obtained by upgrading sflock to version 0.3.6.

Miscellaneous issues

CSB-01-001: Analysis evasion via special characters, resolved in in f7b3ff @ sflock by not allowing files with said filenames to be passed on for analysis. This is not a complete solution, but it should suffice our purposes.

CSB-01-002: CSRF protection within the Cuckoo Web Interface. This has been resolved in 5493be..178e58 @ cuckoo by actually implementing CSRF.

CSB-01-005: PDF documents are not properly detected. This issue is a combination of a bug in sflock and a bug in peepdf. While the sflock issue has been resolved in 0d7547 @ sflock, the peepdf issue is still on our roadmap provided it’s not a highly critical issue (our opinion) and it requires properly delving into the peepdf codebase, which is not daily routine for us.

CSB-01-008: File enumeration bypass in RAR archive via symlink. While this is not strictly a bypass, it is something where more error reporting to the end user is better. We’re now passing error messages from zipjail through sflock to the end user of the library, Cuckoo in this case. While not a complete fix - any archive with embedded symlinks is currently discarded

• the error propagation is a good step forward. See also d55f6a @ sflock.

CSB-01-006: File dropping detection bypass via ADS. This issue has not yet been resolved and is on our TODO list for the upcoming release of zer0m0n, as has been announced earlier, i.e., during the version 2.1 release.

CSB-01-007: Detection bypass on Windows startup folder installation. Same as for CSB-01-006, this issue will be released as part of our 2.1 release.

Conclusions

While the pentest performed by Cure53 highlights some interesting issues, some of which needing proper attention for quite a while now, we’re happy to see that overall the open source development efforts have proven to be secure. Even more so after a few issues that were reported and fixed over the years.

We’d like to thank PolySwarm and Cure53 once again for funding & performing this pentest, respectively, and hope that these results are a good showcase for the "many eyes" principle which people sometimes put in a good or bad daylight when it comes to the security of open source software.

If you (!) find a security issue within Cuckoo Sandbox or one of its components in the future, don’t hesitate to reach to the Cuckoo Sandbox team (cuckoo@cuckoofoundation.org) or us (security@hatching.io). Keep in mind that while there’s no official bug bounty, we do have stickers & t-shirts and other swag :-)