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
pip install cuckoo==2.0.7a1) such that upgrading is
already possible while we finalize some other changes for the official 2.0.7
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-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
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
.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.
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
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
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 (email@example.com) or us (firstname.lastname@example.org). Keep in mind that while there's no official bug bounty, we do have stickers & t-shirts and other swag :-)