BlueKeep : les hostilités sont lancées ?

La nouvelle est tombée vendredi 6 septembre en début de soirée, Brent Cook de l’équipe Rapid7 annonçait qu’un exploit pour la vulnérabilité CVE-2019-0708, dite BlueKeep, permettant une exécution de code arbitraire à distance sans authentification sur un serveur Windows vulnérable dont le service RDS (protocole RDP) est activé, a été ajouté au framework Metasploit1.
Cette intégration fait suite au travail de zerosum0x02 qui œuvre sur l’exploit depuis quelques mois, après la réalisation du scanner pour cette même vulnérabilité précédemment intégrée à Metasploit.

Nous savions depuis fin juillet qu’un exploit était disponible dans l’outil Canvas3, destiné aux auditeurs en sécurité disposant d’un budget conséquent, mais son intégration dans Metasploit, un outil libre et accessible à tous, risque bien de changer la donne.

N’importe qui serait donc susceptible d’attaquer l’ensemble des serveurs Windows vulnérables ?
Ce n’est pas si simple, il faut tout de même relativiser… mais pas trop longtemps quand même, il risque de très vite se peaufiner et devenir vraiment accessible à tous.

Pour avoir un petit peu suivi les commentaires de la page GitHub relative à cet ajout dans Metasploit4, l’exploitation ne peut se faire pour le moment, que dans des conditions bien particulières.
Seuls les systèmes 64 bits Windows 7 et 2008 R2 sont pour le moment exploitables à partir de ce POC.
Pour Windows 2008 R2, il faut également modifier une clé de registre par rapport à la configuration par défaut.
Ensuite, il faut spécifier manuellement si la machine est physique ou virtuelle, et choisir parmi la liste des hyperviseurs disponibles.
Il semblerait qu’il faille également que les hyperviseurs proposés soient dans des versions bien précises afin que l’exploit fonctionne.

Pour avoir brièvement testé cette première version de l’exploit, comme beaucoup d’utilisateurs, je n’ai pas réussi obtenir un shell sur la machine ciblée.

En revanche, la machine attaquée s’est arrêtée sur un joli écran bleu, le célèbre « blue screen of death » :

Ce qui veut déjà dire, que réaliser un déni de service est à la portée de n’importe qui, ce qui est déjà très inquiétant…

Alors pourquoi l’exploit fonctionne chez certains5, mais pas chez d’autres ?
Il semblerait que selon le type de machine physique ou la version de l’hyperviseur, l’adresse de départ du Non Paged Pool6 de la mémoire vive (RAM) diffère.
En réalisant un export du contenu de la RAM, il est possible de retrouver l’adresse de départ avec l’outil rekall par exemple, qu’il ne reste plus qu’à copier comme valeur GROOMBASE pour la cible choisie dans le script Metasploit7. Si le copié / collé est loin d’être une opération compliquée, obtenir cette valeur nécessite d’avoir déjà un accès à la machine ou à l’hyperviseur ce qui peut être intéressant et facile à réaliser en labo, mais pas lors d’une attaque réelle.

Vu l’émulation créée par cette publication, nous devrions rapidement voir arriver des améliorations permettant de rendre cet exploit à la portée de tous.
Et se dire qu’obtenir aussi facilement un shell Meterpreter avec des droits systèmes pourrait rapidement être à la portée de tous, n’a vraiment pas de quoi nous rassurer !

Alors comment se protéger ?
Désactiver les services RDS sur l’ensemble des machines ou cela n’est pas nécessaire.
Ne pas ouvrir des services RDS sur Internet.
Appliquer les correctifs de sécurité disponibles depuis le mois de mai.
Activer l’authentification préalable NLA afin d’empêcher l’établissement d’une connexion à un utilisateur non authentifié, si cela ne pourrait pas empêcher l’exploitation de cette vulnérabilité par un vers exécuté par un utilisateur authentifié, cela limite grandement la surface d’attaque.

Si ce n’est pas déjà fait, agissez vite, les hostilités semblent bien être lancées !

Partager ce document sur les réseaux

?>