Vagrant insecure by default?

SecurityVagrant

Security Problem Overview


EDIT 2: TL;DR: the answer was yes in 2013, but this flaw has been fixed

By following the Getting Started instructions on vagrantup.com, I seem to end up with a virtual machine that is accepting SSH connections on port 2222 so that anyone can get root access to my VM and read my host working directory using the default credentials (username=password=vagrant or vagrant_insecure_private_key).

Is this true? If yes, why is it not considered a gaping security vulnerability? What if I had copied sensitive data to the VM?

EDIT: and for those who think anyone on the internet being able to read your sources and executing arbitrary code on your VM is not that bad, I recommend reading the "Breaking out" section in this blog post http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/

In a nutshell: running Vagrant "as intended" can also enable anyone to break into your host/development machine (e.g., by using a malicious git post-commit hook).

Security Solutions


Solution 1 - Security

The short answer is YES.

Why?

When building Vagrant base boxes (manually or using tools like Veewee to automate), builders follow the vagrant base boxes specifications which defines the following:

  1. User root and vagrant use vagrant as password
  2. Public key authentication (password-less) for the user vagrant.

Vagrant project provides an insecure key pair for SSH Public Key Authentication so that vagrant ssh works.

Because everyone has access to the private key, anyone can use the private key to login to your VMs (suppose they know your IP of the host machine, port is by default 2222 as forwarding rules in place.)

It is NOT secure OOTB. However, you can remove the trusted key from ~vagrant/.ssh/authorized_keys and add your own, change password for vagrant and root, then it's considered relatively safe.

Update

Since Vagrant 1.2.3, by default SSH forwarded port binds to 127.0.0.1 so only local connections are allowed [GH-1785].

IMPORTANT Update

Since Vagrant 1.7.0 (PR #4707) Vagrant will replace the default insecure ssh keypair with randomly generated keypair on first vagrant up.

See in the CHANGELOG: the default insecure keypair is used, Vagrant will automatically replace it with a randomly generated keypair on first vagrant up. GH-2608

Solution 2 - Security

I've raised this as an issue on the github repository for vagrant. The developer has said they'll fix the issue with the forwarded ports being externally available. The developer does not however accept the issue regarding compromise of the host environment from the VM. I think they're dangerously wrong.

https://github.com/mitchellh/vagrant/issues/1785

Breaking out of the vm is easier than the linked blog post suggests. You don't have to depend on git hooks to compromise the host, you just put arbitrary ruby code into the Vagrant file.

I'd run vagrant in a VM sandbox if I could. Since I can't, I make do with a firewall.

It's a good idea to have provisioning rules to add a secure ssh key, and to remove the insecure key and the default password.

Solution 3 - Security

I wrote this simple inline shell provisioner to swap out the authorized_keys with my id_rsa.pub. Once provisioned the insecure_private_key cannot be used to authenticate.

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

# ...

  config.ssh.shell = "bash -c 'BASH_ENV=/etc/profile exec bash'" # avoids 'stdin: is not a tty' error.

  config.ssh.private_key_path = ["#{ENV['HOME']}/.ssh/id_rsa","#{ENV['HOME']}/.vagrant.d/insecure_private_key"]

  config.vm.provision "shell", inline: <<-SCRIPT
    printf "%s\n" "#{File.read("#{ENV['HOME']}/.ssh/id_rsa.pub")}" > /home/vagrant/.ssh/authorized_keys
    chown -R vagrant:vagrant /home/vagrant/.ssh
  SCRIPT

end

Solution 4 - Security

As of Vagrant 1.2.3 the default is to bind to localhost instead of the public interface, avoiding the external connection issue.

Solution 5 - Security

Just wanted to add that there is a Vagrant plugin that solves this problem:vagrant-rekey-ssh. It changes the default password of the VM, and removes the insecure SSH key.

Solution 6 - Security

I would like to explain why Vagrant is not necessarily as insecure as you might think.

I would like to start off by saying that as I am sure most of you are already aware, it is necessary to maintain open access to the Vagrant box because of the way these boxes are being shared. For that reason, I believe the main security concern is not changing the default credentials after the box is downloaded. Running such a machine in bridged mode would allow someone on the network to ssh in with default credentials.

It appears to me that the idea behind these boxes is that anyone can download it, and secure it once it is in their possession. My vagrant installation replaces default keys with a new, randomly generated ssh key. I am not sure if this is being done with a plugin, however I am curious to know if the password-less sudo and default password also present a security risk.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionoseiskarView Question on Stackoverflow
Solution 1 - SecurityTerry WangView Answer on Stackoverflow
Solution 2 - Securitymc0eView Answer on Stackoverflow
Solution 3 - SecuritydonnomanView Answer on Stackoverflow
Solution 4 - SecurityjermView Answer on Stackoverflow
Solution 5 - SecurityLuca InvernizziView Answer on Stackoverflow
Solution 6 - SecurityCoffee123View Answer on Stackoverflow