The Future of SamuraiWTF

Samurai Web Testing Framework, if you’re not familiar with it, it’s a linux environment that is primarily now used for teaching web application penetration testing. It has a number of target web applications to train against, and a curated collection of attack tools.

For the newest major version, we have made some changes to how its built, mostly to facilitate better, easier community collaboration. I did a show-and-tell of that in a recorded webcast on Feb 13, 2018. You can find that at the bottom of this page, and it covers essentially the ground as the summary below.

The Old Way

SamuraiWTF has been passed around a large VM. The normal process for contributing it has been to unpack the VM, update it, repack it, and upload it to Sourceforge – https://sourceforge.net/projects/samurai/

Version 3.3.2 was uploaded on January 22, 2016. This is the most recent version in the Sourceforge project. This version was built on Kubuntu (the KDE mix of Ubuntu), with a variety of tools and targets.

Maintenance was done by passing downloading the VM, doing stuff (updating packages, installing things, changing config) and then exporting and uploading the new version of the VM.

The Problems

While it was a very handy teaching tool, it presented a few points of frustration for me.

Passing around a big omnibus VM doesn’t facilitate collaboration. People can’t work on it simultaneously, full-stop. But the problems extend beyond that.
- If you and I both download the same release, I add a new tool, and you fix a couple bugs, we’re in a race condition. Whoever’s new version gets uploaded second will clobber the changes by whoever did it first.
- There’s no mechanism for diffing between versions – information about what changed is only as good as the release notes we write.
Keeping it up-to-date is a manual process. It gets updated when someone updates and re-uploads it.
It’s a big distributable. In the first place, Ubuntu is often criticized for being bloated. There are certainly packages installed that I never use when teaching defensive coding or web pen-testing classes. One example is LibreOffice. KDE adds a bunch of additional weight. Add the tools and targets on top, and the current version on SourceForge is 3.8GB zipped.
Getting newer stuff to work is painful. The older, battle-tested LAMP-stack targets work fine. I was preparing it, at one point, for a client that had seen the class several times before. I wanted to give them some new exercises, so I started cooking up a new target in Node on Docker. I worked on it for a couple days, then tried to putting it into the SamuraiWTF VM. And it didn’t work. Docker couldn’t run on that version of Kubuntu. Node didn’t install smoothly. The VM bloated up. The whole process was so painful that I salvaged one or two exercises and threw out most of the new material.

The New Beginning

Secure Ideas’ Jason Gillam, who had contributed to Samurai 3.x, did some ground work on building Samurai with Vagrant. The short explanation is that I forked Jason’s work, built on it to make a Samurai fork that was the way I wanted it to be. Once I had the barebones basic desktop environment and targets in place, I took it to Jason and Kevin for show & tell. That experimental fork of an experimental fork became foundation for Samurai 4. There’s a bunch of stuff that’s useful to know if you want to work with it – but I think you will find it pretty easy to pick up.

What is Vagrant?

HashiCorp is a commercial entity that has several products built around the infrastructure-as-code concept. Vagrant is one of their popular tools, and is open-source. It essentially allows you to define a Virtual Machine in a code file. It’s Ruby syntax, but don’t get hung-up on that if you don’t know Ruby. Its popular use is for web developers to run local servers as VMs for development. For example, the popular, modern PHP-framework Laravel has their dev VM, Homestead, which is defined in Vagrant. A simple CLI command of vagrant up can stand-up the VM. But it can be more than just a bare-bones server, because it supports provisioning with, for example, bash, puppet, or Ansible.

What issues does using Vagrant solve?

For one thing, the VM configuration in the Vagrantfile is code. We can diff versions of it. If two people work on it simultaneously, their changes can be merged as appropriate.

Along with the vagrant file, there are several bash files used for provisioning. Those can also be maintained in source control with all the usual benefits. The same goes for several config files that are copied into the VM when it’s provisioned. This also means that we can link code changes to specific issues in the new GitHub repo.

As a matter of fact, we’re using a minimal Debian image maintained as part of the Bento project as the starting point. Everything we do it from there is in those provisioning scripts and config files, which provides a certain degree of transparency that previously wasn’t there.

Another advantage is that the project distributable is currently less than 1.5MB on disk.

What else has Changed?

Base distro changed from Kubuntu to Debian (currently Stretch)
- The built and exported OVA is 2.57GB as of the time of this post – more than 30% smaller than its zipped predecessor.
Switched from KDE to OpenBox + Tint2
Primarily tested on VirtualBox rather than VMWare
- There’s a commercial VMware provider for Vagrant, that we haven’t tested.
- We have successfully exported from VBox and imported into VMWare Fusion, but it won’t have VMware tools baked in (shared folders, clipboard sharing, etc)
- This is more a side-effect of switching to VirtualBox than it is a choice, however it has the advantage of price. VirtualBox is free. This means that using it for training at a public event, like a Security B-Sides, the students don’t need to buy a commercial VMware license to participate.
Targets are now setup in Docker containers behind an Nginx reverse proxy.
- Docker wrapper has been created for the Samurai Dojo project.
- The OWASP Juice Shop is included as well – which is a fantastic vulnerable modern web app project led by Björn Kimminich.
For most of the tools, it fetches the latest version during the vagrant up process.
The default Vagrant machine is the combined targets + desktop environment, but either one can be individually built
- Desktop with tools to attack targets that are hosted somewhere
- Target server to attack with tools installed on the host machine
  - This use case hasn’t been tested to any significant degree

How Can You Contribute?

Here’s the GitHub repo: https://github.com/SamuraiWTF/samuraiwtf

It’s not perfect. There will be bugs. Submit issues.
- Provide adequate detail to reproduce.
- Even better if you can suggest a solution.
- Expect that a bug report may become a conversation.
Check out the issues.
- See something you can fix? Fork the project, fix it up, send a pull request.