web-dev-qa-db-fra.com

Insécurité vagabonde par défaut?

EDIT 2 : TL; DR: la réponse était oui en 2013, mais cette faille a été corrigée

En suivant les instructions de démarrage sur vagrantup.com, il me semble que je me retrouve avec une machine virtuelle qui accepte les connexions SSH sur le port 2222 afin que n'importe qui puisse obtenir un accès root à mon VM et lire mon Hébergez le répertoire de travail en utilisant les informations d'identification par défaut (nom d'utilisateur = mot de passe = vagrant ou vagrant_insecure_private_key).

Est-ce vrai? Si oui, pourquoi n'est-il pas considéré comme une vulnérabilité de sécurité béante? Et si j'avais copié des données sensibles sur la machine virtuelle?

[~ # ~] éditez [~ # ~] : et pour ceux qui pensent que n'importe qui sur Internet peut lire vos sources et exécuter du code arbitraire sur votre VM n'est pas si mal que ça, je vous recommande de lire la section "Breaking out" dans ce billet de blog http://blog.ontoillogical.com/blog/2012/10/31/entrée et sortie du vagabond /

En bref: exécuter Vagrant "comme prévu" peut également permettre à quiconque de pénétrer dans votre machine hôte/développement (par exemple, en utilisant un hook git post-commit malveillant).

securityvagrant
70
oseiskar

La réponse courte est [~ # ~] oui [~ # ~] .

Pourquoi?

Lors de la construction de boîtes de base Vagrant (manuellement ou en utilisant des outils comme Veewee pour automatiser), les constructeurs suivent les spécifications des boîtes de base vagantes qui définissent ce qui suit:

  1. L'utilisateur root et vagrant utilise vagrant comme mot de passe
  2. Authentification par clé publique (sans mot de passe) pour l'utilisateur vagrant.

Le projet Vagrant fournit une paire de clés non sécurisée pour l'authentification par clé publique SSH afin que vagrant ssh travaux.

Parce que tout le monde a accès à la clé privée, tout le monde peut utiliser la clé privée pour se connecter à vos machines virtuelles (supposons qu'ils connaissent votre IP de la machine hôte, le port est par défaut 2222 comme règles de transfert en place.)

Ce n'est PAS un OOTB sécurisé. Cependant, vous pouvez supprimer la clé de confiance de ~vagrant/.ssh/authorized_keys et ajoutez le vôtre, changez le mot de passe pour vagrant et root, il est alors considéré comme relativement sûr.

Mise à jour

Depuis Vagrant 1.2.3, par défaut le port transféré SSH se lie à 127.0.0.1 donc seules les connexions locales sont autorisées [GH-1785].

Mise à jour IMPORTANTE

Depuis Vagrant 1.7.0 ( PR # 4707 ) Vagrant remplacera la paire de clés ssh non sécurisée par défaut avec une paire de clés générée aléatoirement le premier vagrant up.

Voir dans le CHANGELOG : la paire de clés non sécurisée par défaut est utilisée, Vagrant la remplacera automatiquement par une paire de clés générée aléatoirement le premier vagrant up. GH-2608

96
Terry Wang

J'ai soulevé cela comme un problème sur le référentiel github pour vagrant. Le développeur a déclaré qu'il résoudrait le problème avec les ports redirigés disponibles en externe. Le développeur n'accepte cependant pas le problème de compromis de l'environnement Host à partir de la VM. Je pense qu'ils ont dangereusement tort.

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

Sortir de la VM est plus facile que ne le suggère le billet de blog lié. Vous n'avez pas à dépendre des hooks git pour compromettre l'hôte, vous mettez simplement du code arbitraire Ruby dans le fichier Vagrant.

Je courrais vagabond dans un VM bac à sable si je le pouvais. Comme je ne peux pas, je me contente d'un pare-feu.

C'est une bonne idée d'avoir des règles de provisioning pour ajouter une clé ssh sécurisée, et pour supprimer la clé non sécurisée et le mot de passe par défaut.

10
mc0e

J'ai écrit ce provisionneur Shell en ligne simple pour échanger les authorized_keys avec mon id_rsa.pub. Une fois provisionnée, l'insecure_private_key ne peut pas être utilisée pour s'authentifier.

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
9
donnoman

Depuis Vagrant 1.2.3, la valeur par défaut est de se lier à localhost au lieu de l'interface publique, évitant ainsi le problème de connexion externe.

7
jerm

Je voulais juste ajouter qu'il existe un plugin Vagrant qui résout ce problème: vagrant-rekey-ssh . Il modifie le mot de passe par défaut de la machine virtuelle et supprime la clé SSH non sécurisée.

1
Luca Invernizzi

Je voudrais expliquer pourquoi Vagrant n'est pas nécessairement aussi peu sûr que vous pourriez le penser.

Je voudrais commencer par dire que, comme je suis sûr que la plupart d'entre vous le savent déjà, il est nécessaire de maintenir un accès ouvert à la boîte Vagrant en raison de la façon dont ces boîtes sont partagées. Pour cette raison, je pense que le principal problème de sécurité ne change pas les informations d'identification par défaut après le téléchargement de la boîte. L'exécution d'une telle machine en mode ponté permettrait à quelqu'un sur le réseau de se connecter avec des informations d'identification par défaut.

Il me semble que l'idée derrière ces boîtes est que n'importe qui peut la télécharger et la sécuriser une fois qu'elle est en sa possession. Mon installation vagabonde remplace les clés par défaut par une nouvelle clé ssh générée de manière aléatoire. Je ne sais pas si cela se fait avec un plugin, mais je suis curieux de savoir si le Sudo sans mot de passe et le mot de passe par défaut présentent également un risque pour la sécurité.

0
Coffee123