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-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
api_token field in the
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
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-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
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
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 :-)