VirtualBox Web Service machinery

[ilyaglow]

Hey there!

Thank you for open sourcing Cuckoo and all efforts you put in to maintain it!

This PR introduces new machinery for a remote VirtualBox instance and operates
it's virtual machines over SOAP using remotevbox library which is written especially for this purpose.

Virtual Web Service can be run using vboxwebsrv binary on Linux/Mac and VBoxWebSrv on Windows. It is recommended to run it over SSL, because user credentials will be sent in a plaintext over the wire. You can specify cert and key to a daemon or use a reverse proxy with SSL termination in a front of the service.

My initial goal was to run dockerized cuckoo (thanks @blacktop!) in a specific environment constraints where VirtualBox is the only option.

25.12.2017 Update:
I've made a branch of docker-cuckoo that has a manual how to deploy this PR dockerized.

30.12.2017 Update:
@blacktop has merged my branch so you can read the docs here:
https://github.com/blacktop/docker-cuckoo/blob/master/docs/virtualbox.md

Machinery configuration example

Configuration file virtualbox_websrv.conf is pretty simple and almost the same as for an existing virtualbox.conf.

[virtualbox_websrv]
# Run mode, could be 'gui' or 'headless'
mode = headless

# VirtualBox Web Service URL
url = https://VIRTUALBOX-WEBSERVICE:18083

# Unix credentials of the user on a VirtualBox host,
# who has imported virtual machines to use with a Cuckoo Sandbox
user = vbox
password = YOUR-LONG-PASSPHRASE

# VirtualBox host directory shared with a Cuckoo Sandbox
remote_storage = /tmp/cuckoostorage

# Debug mode for machinery, affecting basically the zeep SOAP library
debug = False

# Specify a comma-separated list of available machines to be used
# Same as for a default VirtualBox machinery
machines = cuckoo1

[cuckoo1]
# Same parameters as for a default local VirtualBox machinery
# ...

Any feedback for this PR or a remotevbox library is appreciated.

Cheers.

[ilyaglow]

Working on fixing tests part :)

[coveralls]

Coverage decreased (-0.2%) to 61.682% when pulling 14b4508 on ilyaglow:remotevbox-machinery into 3846eb6 on cuckoosandbox:master.

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@ca525fe). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1998   +/-   ##
=========================================
  Coverage          ?   61.67%           
=========================================
  Files             ?      150           
  Lines             ?    14927           
  Branches          ?        0           
=========================================
  Hits              ?     9206           
  Misses            ?     5721           
  Partials          ?        0

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ca525fe...af197fe. Read the comment docs.

[coveralls]

Coverage decreased (-0.2%) to 61.682% when pulling f494cb3 on ilyaglow:remotevbox-machinery into 3846eb6 on cuckoosandbox:master.

[coveralls]

Coverage decreased (-0.2%) to 61.682% when pulling f494cb3 on ilyaglow:remotevbox-machinery into 3846eb6 on cuckoosandbox:master.

[coveralls]

Coverage decreased (-0.2%) to 61.682% when pulling 6d01644 on ilyaglow:remotevbox-machinery into 0d8cd9e on cuckoosandbox:master.

[coveralls]

Coverage decreased (-0.2%) to 61.673% when pulling 21a9c3e on ilyaglow:remotevbox-machinery into 0d8cd9e on cuckoosandbox:master.

[jbremer]

Hi. Thanks for your contribution, however, having implemented pretty much the same earlier (a few years ago), I'm not too included to merge it. There's a number of non-trivial issues that come with it and overall just complicate Cuckoo, IMO.

[ilyaglow]

It would be helpful for me to know about the issues you mentioned, could you elaborate?

It’s just an additional machinery after all, but if there are ways to improve this PR to make it better and more acceptable, I’m all for it.

[jbremer]

Well, fair enough, your approach is better than what I wrote back then - which was based on my own RPC daemon on the Host, basically executing a limited set of vboxmanage commands - provided that you're using the actual VirtualBox SOAP thing.
Other than that my biggest annoyance would be the usage of a shared folder, but I suppose that's also acceptable provided proper documentation exists.
With some minor changes here and there I'd be up for merging this if:

• accurate & thorough documentation is provided
• we write a blogpost detailing all steps (on top of the documentation) on setting up 2 VMs: one analysis (Guest) and one Host VM.

Together this would provide for a ready-made solution for all of those people requesting "nested analysis" with VirtualBox. Needs to be well-tested though, as I imagine lots of users will somehow get it wrong.. ;-)

[ilyaglow]

Sounds great, lets start from something :) @blacktop kindly helped me and wrote a walkthrough.
It is a bit docker specific, but definitely can be used to figure out the basics.

I’ll setup 2 VMs in a couple of days (and probably catch some bugs early ;)) and document the process in detail so you can repeat and validate.

[ilyaglow]

Sorry for the delay guys, I finally made it to work as @jbremer requested: one analysis vm and one Cuckoo vm, which could be a dockerized version by @blacktop or a regular installation with remotevbox-machinery added manuallly.

Some restrictions I faced:

• Both vms should run on the same host-only network
• I struggled to make a shared folder work properly with Virtualbox Shared Folders (weird permissions issue...), so ended up with sshfs mounted from the host to Cuckoo vm.

Now I'm working on documentation for this specific case here https://github.com/ilyaglow/remotevbox-machinery-docs

[CrimsonGlory]

Any news on this?