Je ne vais vous rabâcher la faille OpenSSL heartbleed mais un billet s'impose pour parler de VMware vSphere, et plus particulièrement de ESXi (nom de code vSphere Hypervisor pour la version gratuite).
Je ne sais pas si vous avez pris le temps de patcher vos serveurs ESXi, mais si ce n'est pas le cas j'espère que ce billet vous fera changer d'avis.
On pense parfois qu'il est compliqué de mettre en oeuvre une faille, et à ce titre on tarde à combler la faille. Voilà qui va vous montrer qu'il est très simple d'exploiter heatbleed ! Nombreux sont les serveurs encore faillibles, 40% des sociétés ayant une infra VMware seraient encore impactées.
Le VLAN de management, c'est pas du flan
Premièrement si le réseau management de vos serveurs ESXi n'est pas dans un vlan dédié, et donc dans un plan IP dédié et indépendant du LAN, c'est la première erreur.
C'est d'ailleurs sur ce point que VMware s'est appuyé au moment de l'annonce d'heartbleed : vos serveurs ne sont pas censés être accessibles depuis le réseau local. Il n'est donc pas urgent de les protéger. Selon VMware :
By deploying vSphere 5.5 (and other relevant VMware products) on an isolated management network, the exposure to CVE-2014-0160 is reduced. Hosting vSphere components directly on the Internet is strongly discouraged. Virtual machines that are exposed to the Internet should be updated in case they are affected.
De quoi rigoler un bon coup, même si dans le fond ils n'ont pas tord. Que ce soit via VPN ou via un tunnel... c'est comme vous voulez mais ne laissez pas l'accès management sur un réseau publique, que ce soit le LAN ou Internet (WAN).
Démo : et paf le mot de passe
C'est parti pour une démo sur une infra labo volontairement non patchée pour le billet.
Pour vérifier si un serveur est faillible il existe de nombreuses versions de scripts python. Nous allons utiliser une version légèrement modifiée et créée par @pyrou, fidèle lecteur étant le premier à m'avoir alerté sur heartbleed (alors même que j'assistais à une conférence de Richard Stallman sur les logiciels libres, oui ça ne s'invente pas !). Cette version modifiée permet d'afficher les chaines de caractère contenues dans les bribes de mémoire vive récupérées à la volée.
Nous utiliserons une machine sous GNU/Linux Debian pour disposer d'un terminal ciblant l'IP management d'un serveur ESXi. Une petite boucle pour attendre le premier login qui se présentera. Nous lançons le script depuis une machine située sur le réseau management (ou sur le LAN si vos ESXi peuvent être gérés depuis le LAN) :
while sleep 1; do /tmp/hbp.py IP_ESXI | grep -Ei "password|username"; done
(hbp.py => heartbleed pyrou, notre script python. Je passe l'étape chmod +x)
Laissons le terminal ouvert, il exécute le script python toutes les secondes (vous pouvez aussi envoyer la sortie dans un fichier pour le laisser tourner en fond). Notre serveur ESXi a pour IP 192.168.10.200.
Tentons une connexion via vSphere Client (web ou lourd cela ne change rien) à partir d'un ordinateur ayant accès au réseau management :
Revenons sur le terminal Debian :
Résultat alarmant : l'identifiant et le mot de passe sont affichés en clair.
Vous pouvez dire au revoir à vos VM si l'attaquant s'amuse avec, voir à votre cluster si vous utiliser vCenter.
Vous allez me dire que tout dépend des droits rattachés au compte utilisé, toto dans notre exemple. Et bien non ! Car en pratique même les identifiants tapés il y a quelques semaines (voir plus) peuvent ressortir. Le vol d'identifiant peut faire très mal, surtout que le root y sera si quelqu'un l'a utilisé récemment (ou moins récemment, tout dépend si la RAM de votre serveur elle est sollicitée ou non). Si vous aviez perdu le mot de passe root, vous venez de le retrouver...
Et puis vous n'allez pas me dire que vous avez pris la peine de gérer correctement les droits utilisateurs alors que le réseau management est sur le LAN, héhé !
Patchez, et vite !
Si vous êtes arrivés à cette étape, ça craint pour votre infra, ou celle que vous gérez...
Si vous utilisez VMware Update Manager (VUM), c'est assez facile de patcher et vous devriez l'avoir déjà fait depuis longtemps. Profitez pour mettre à jour vers la dernière version d'ESXi (5.5 Update 1 actuellement).
Si vous utilisez la version gratuite, c'est moins drôle car il faut patcher les serveurs à la main un par un. Et il faudra recommencer à chaque sortie de patch.
Procédure de patch manuelle
Pour un serveur en version 5.5 :
- Télécharger le patch : ESXi550-201404001.zip
- Envoyez le patch dans le datastore du serveur (ou dans /tmp). Dans mon cas il est ici :
# ls /vmfs/volumes/datastore1/*.zip /vmfs/volumes/datastore1/ESXi550-201404001.zip
- Activez SSH sur l’ESXi (dans vSphere Client > Configuration > Profil de sécurité > Services > SSH > start)
- Mettez l'hôte ESXi en mode maintenance via vSphere Client, sinon en terminal :
vim-cmd hostsvc/maintenance_mode_enter
- Connectez-vous en SSH à l'hôte ESXi et entrez les commandes qui suivent
- Installez le patch (modifiez le chemin du patch) :
esxcli software vib update -d "/vmfs/volumes/datastore1/ESXi550-201404001.zip" Installation Result Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective. Reboot Required: true VIBs Installed: …
- Rédémarrez le serveur, la commande reboot suffit
- Quittez le mode maintenance :
vim-cmd hostsvc/maintenance_mode_exit
Je vous conseille d'en profiter pour installer d'autres patchs, il y a eu d'autre failles OpenSSL. A la suite de l'application du patch heartbleed et de celui qui a suivi j'étais en release 5.5.0 release 1881737. Autrement dit si votre version est inférieure ce n'est pas bon !
Il est aussi fortement conseiller de régénérer vos certificats : ESXi et vCenter puisqu'ils ont potentiellement été aussi récupérés.
Si vous souhaitez obtenir la liste des VIB et patchs installés avec la date associée :
esxcli software vib list
Et voilà ! Votre serveur ne craint plus rien, jusqu'à la prochaine faille. Honnêtement ce n'est pas un luxe d'utiliser VUM, vous gagnez en temps et en sécurité. Si le prix des licences vous rebute passez par les kits essentials plus qui sont très abordables pour quelques centaines d'euros.
ps : pour patcher via esxcli depuis Windows, voici un exemple générique.
Auteur : Mr Xhark
Fondateur du blog et passionné par les nouvelles techno, suivez-moi sur twitter
5 commentaires
Ça me fait penser à SynoLocker qui utilise une faille patchée en décembre 2013 !
Les gens qui ne mettent pas à jour leurs logiciels sont aussi coupables que les "hackers" qui utilisent les failles.
Impressionnant... sur certains sites il y a même des "_DB_PASSWD_" qui trainent !!!
Notez toutefois, que la faille permet de révéler 64k de la mémoire RAM
Donc en principe, plus le serveur a de la RAM, plus la botte de fois est énorme. sur 64Go de RAM, il n'y a en principe que 0.0001% de chance donc de récupérer l'information précise que l'on souhaite.
Cela même sans tenir compte du swap
@pyrou: je pense que ces 64k de RAM sont toujours les même si le serveur est peu utilisé, c'est à dire si la RAM n'est que très peu sollicitée. En tout cas c'est ce que j'ai constaté, mais sur les serveurs de Yahoo ça semblait être bien différent d'après ta capture =D