Le 4 janvier surgissait sur l’internet une vidéo montrant un exploit tournant avec le framework CANVAS d’Immunity permettant l’ouverture d’un shell en remote sur MySQL 5.x selon la description de l’exploit montrée pendant cette vidéo.

Outre le fait que ce dernier est un 0day, cet exploit risque de faire très mal tant pour l’image de la firme MySQL que pour les millions de serveurs faisant tourner ce service ouvertement sur l’internet sans aucune protection particulière dans les restrictions d’accès ou le cloisonnement du processus.

Bref, qu’en est-il vraiment ? A mon avis, je pense de plus en plus à une vraie vidéo, mais je doute de plus en plus d’un vrai exploit. Quelques les éléments ci-dessous me sifflent dans l’oreille :

- Le site internet est très -trop – basique, le blog aussi pour tout vous avouer. Cependant, un whois sur ce dernier montre que le nom de domaine n’est pas récent comme on pourrait le penser. Mais un internet archive ne trouve rien.

- La société qui possède 5000 résultats de recherches sur Google prétend sur le forum d’Immunity vendre un de ses packs d’exploits 250$, cela fait très – trop – peu pour des possibles 0 Days, surtout de cette envergue. Elle a semble-il découverte la vulnérabilité en Aout, pourquoi pendant tout ce temps, elle n’a (semble-t-il – là encore) prévenu MySQL de cette brèche ?

- Nous connaissions déjà certaines possibilités de mise en place de portes dérobées sur des serveurs MySQL telles que le tool Raptor qui permettait d’ouvrir un shell sur un MySQL disposé sur Windows – ou par l’intermédiaire d’SQL injections sur un serveur web, encore fallait-il que le serveur MySQL tourne sur ce précédent serveur et que les droits UNIX soient bafoués pour que cela marche. Cependant, avec cette vidéo, on peut penser que l’exploit ne requiert pas d’authentification sur le serveur visé ou même un support/module de MySQL installé. D’ailleurs, j’aime le « Note – the exploit has been edited to be less verbose. » #WTF.

- Vous avez entendu parler un week of data base bugs prochainement ? Perso NaN. Dans les commentaires du blog ils prétendent démontrer la vulnérabilité durant cette semaine… j’aimerai bien savoir si quelqu’un à des infos, bizarrement, Google n’en a pas non plus. Normal, ce sont « eux » qui « les » organisent (sachant qu’il y a qu’un russe dernière cette société)…

Bref, je reste très septique sur cette vulnérabilité et je pense que – si elle existe – elle n’est pas effective sur une installation par défaut de MySQL. Entre 0 et 10 sur le point de la crédibilité, je mettrai 3, pas plus. Cependant, si elle existe bien et qu’elle est possible sur une installation par défaut – il y en a qui voient la vierge partout depuis que des vulnz en remote ont été découvertes sur OBSD ; il faudra faire quelques mises à jour ou appliquer quelques sécurités supplémentaires telles que :

- La définition des droits d’accès à MySQL afin que seuls certains hosts puissent s’y connecter (ce qui d’ailleurs devrait être toujours fait). Non seulement au point de vue de l’authentification de certains l’ensemble des utilisateurs dans la configuration des users de MySQL que de l’accès au serveur devant être régit par un FW.

- Chrooter de processus afin qu’une possible ouverture de shell ne puisse pas aboutir à de plus amples dégâts tels que de rooting de la Box ou la découverte de la topologie du réseau (de la DMZ) distant(e).

- Et enfin, le changement du port par défaut de MySQL (3306) afin d’éviter les bots et diverses attaques automatisées sur des comptes si ce serveur est accessible à partir de l’Internet. Cependant, cette protection ne sert à rien si le pirate a déjà sous son emprise le client se connectant sur le serveur. #FAIL

Bref, l’attente est la conclusion de cet article. Dans quelques jours nous serons fixés sur cette affaire même si à mon avis, nous aurons déjà oublié cet épisode dont la véritable finalité était de vendre quelques packs d’exploits exploitant des vulnérabilités se revendiquant critiques alors qu’il n’en est rien.

NB : Après la re-visualisation de la vidéo, je me suis aperçu d’un « req #1, req #2″ pendant l’exécution de l’exploit. Cela laisserait donc suggérer qu’il faut être authentifié auprès du serveur MySQL afin d’ouvrir un shell sur la BOX.