Web Vulnlab VM

This repo provides a free and open-source security training environment focused on web security. It packages 10+ intentionally vulnerable web apps with a Kali Linux Vagrant VM. Use it to:

• Better understand vulnerabilities by analyzing and exploiting them
• Practice penetration testing safely and easily
• Create security trainings/workshops

Big thanks to the authors and contributors of these vulnerable apps! This repo packages their work in a convenient-to-use way.

Watch this video to quickly understand how to use this repo.

🛑⚠️Security Warning⚠️🛑

This VM contains lots of vulnerable software! You're responsible for your own security, don't get yourself or your organization pwned! Get permission from your IT team if you're running this on a machine or network you don't control.

This project takes the following security precautions:

• Uses a private network with no port forwarding. This way, vulnerable services aren't exposed to the VM host or it's network (unless you edit network config in the Vagrantfile).
• Vulnerable applications are configured to listen on 127.0.0.1 rather than 0.0.0.0. Exception: CI/CD Goat uses Docker-in-Docker, so when you enable it some services will listen on 0.0.0.0 in the VM

For another layer of protection, you can disconnect the VM host from its network while running vulnerable apps (an internet connection is needed for initial setup).

Usage

Summary

1. Clone/fork this repo
2. vagrant plugin install vagrant-reload to enable automatic VM provisioning.
3. Edit vars/vulnerable-app-config.yaml to enable individual vulnerable applications. Each time you run vagrant up --provision these settings are applied. By default, Juice Shop will be provisioned (though not automatically started).
4. cd vm-vulnlab && vagrant up. Provisioning takes a few minutes depending on your internet speed and enabled apps. You'll be prompted to install the vagrant-reload plugin if you don't have it already.
5. Open the VM's Virtualbox window, log in with vagrant/vagrant, open a terminal and run ./start-app-name.sh. The per-app startup scripts print URLs for the running app and its documentation (control-click them to open from a terminal).
6. When you're done using the app run $HOME/stop-app-name.sh from a shell in the VM. Changes to the app are saved (if the app supports it). Then run vagrant halt from VM host shell.

More detailed instructions below.

Requirements

Software

You'll need these free tools:

• Install Vagrant instructions
• Install Virtualbox instructions
• Install Git instructions

Hardware

You'll need at least 4GB of physical RAM on the VM host system (8GB+ is better).

By default the VM uses 4GB of RAM. You can adjust this via the v.memory variable in the Vagrantfile (specified in MB). For example:

config.vm.provider "virtualbox" do |v|
    v.memory = 6144 # VM gets 6GB of RAM

RAM requirements change depending which tools and vulnerable applications you use in the Kali VM.

Initial VM Setup

On a machine meeting the prerequisites listed above:

git clone https://github.com/dachiefjustice/vm-vulnlab.git # or https://gitlab.com/johnroberts/vm-vulnlab.git
cd vm-vulnlab
vagrant plugin install vagrant-reload # for VM provisioning
vagrant up

VM provisioning uses the vagrant-reload plugin. You'll be prompted to install this plugin if you don't have it already. Accept the installation prompt, then continue VM provisioning: vagrant up --provision

Using Vulnerable Applications (NodeGoat Example)

You can enable applications by editing vars/vulnerable-app-config.yaml and applying the changes with vagrant up --provision.

Example: Enabling NodeGoat

1. Enable NodeGoat: set use_app_name: true in vars/vulnerable-app-config.yaml and save the file.

##### NodeGoat #####
use_owasp_nodegoat:     true # https://github.com/OWASP/NodeGoat
# nodegoat_host_port:     '3005'

# <other apps>

2. Deploy NodeGoat: run vagrant up --provision. This will:
   • Create the application's directory in the VM (/home/vagrant/nodegoat in this case)
   • Prepare the application to be launched.
   • Create application start/stop scripts (/home/vagrant/start-nodegoat.sh and /home/vagrant/stop-nodegoat.sh in this case).
3. Launch NodeGoat: log into the VM's Virtualbox window (with vagrant/vagrant username/password), open a terminal and run ./start-nodegoat.sh. This start script displays URLs to the running application and application's documentation, control-click to open them in the browser. Some applications might take a minute or two to finish setup the first time you launch them.
4. Use NodeGoat: in the Kali VM, launch Firefox/Burp Suite/whatever tool and point it at the running application.
5. Stop NodeGoat: when you're done using NodeGoat, open a terminal in the VM and run $HOME/stop-nodegoat.sh. Changes to the app are saved (if the app supports it). Then run vagrant halt from VM host shell.

Remove Vulnerable Applications

You can also disable applications to reclaim VM disk space. Note that this will destroy all changes to the application, such as progress you've made hacking the app so far!

Example: Removing NodeGoat

1. Disable the application: set use_app_name: false in vars/vulnerable-app-config.yaml and save the file.

##### NodeGoat #####
use_owasp_nodegoat:     false # https://github.com/OWASP/NodeGoat
# nodegoat_host_port:     '3005'

# <other apps>

2. Deploy the changes: run vagrant up --provision to remove the now-disabled application from the VM. This will delete its containers, images, networks, volumes, directory, and start/stop scripts.

Lab Environment Details

Included Vulnerable Apps

The vulnerable applications cover a range of programming languages, vulnerability types (including OWASP top 10), and difficulty levels. By default Juice Shop is deployed (but not automatically launched for security reasons).

App Code + Docs	Default Port(s)
Juice Shop	3000 (web)
Yavuzlar Vulnlab	3001 (web)
RailsGoat	3002 (web)
Damn Vulnerable Web App (DVWA)	3003 (web)
Damn Vulnerable GraphQL App (DVGA)	3004 (web)
NodeGoat	3005 (web)
SSRF Vulnerable Lab	3006 (web)
WebGoat	4080 (WebGoat), 4090 (WebWolf)
Mutillidae	5080 (HTTP), 5443 (HTTPS), 5081 (DB Admin), 5389 (LDAP), 5082 (LDAP admin), 8888 (for StackHawk)
VAmPI	6001 (secure), 6002 (vulnerable)
Damn Vulnerable Web Services (DVWS)	7080 (web), 7081 (GraphQL), 7090 (XML-RPC)
Security Shepherd	9080 (HTTP), 9443 (HTTPS)
crAPI	See docs, run without other concurrent apps to avoid resource conflicts
CI/CD Goat	See docs, run without other concurrent apps to avoid resource conflicts

Tips

• VM default credentials: vagrant/vagrant
• VM provisioning is idempotent. Provision the VM anytime with vagrant up --provision. Or you can destroy and re-create the VM:

vagrant destroy -f
vagrant up

• After initial provisioning, you can disable the Vagrantfile's first two provisioners for faster provisioning:

  ##### PROVISIONING VIA ANSIBLE ######
  # config.vm.provision "ansible_local" do |ansible|
  #   ansible.playbook = "playbooks/vulnlab-prereqs-playbook.yml"
  # end

  # # Reboot to add vagrant to docker group
  # config.vm.provision :reload
  
  config.vm.provision "ansible_local" do |ansible|
    ansible.playbook = "playbooks/vulnlab-playbook.yml"
  end

• Run crAPI and CI/CD Goat without any other apps enabled to avoid port conflicts and running out of disk/RAM. CI/CD Goat has a lot of components; if you use it, give the VM additional RAM for solid performance (8GB worked nicely during my testing).

Ports

You can change the ports for each application by uncommenting and editing variables named like appname_host_port* in vars/vulnerable-app-config.yaml. Most vulnerable applications use a single port, some use multiple ports/services.

The default ports are non-conflicting, except for crAPI and CI/CD Goat (which use the ports listed in their documentation).

Tech Stack

• Vagrant, Virtualbox, and kalilinux/rolling
• Ansible for automated provisioning. Vulnerable application deployment logic is in this Ansible role.
• Docker and Docker Compose for building/running the vulnerable applications
• The programming languages, frameworks, and other components of the vulnerable applications

Credits & Inspiration

Special thanks to all the authors and contributors for these vulnerable applications, and to the authors of the OWASP Vulnerable Web Applications Directory.

Thanks also to:

• Jeff Geerling for his geerlingguy.docker and geerlingguy.git roles.
• Parsia for inspiring me to up my automation game, turning me onto Manual Work is a Bug