La vulnérabilité présente dans le logiciel de chat : « Livezilla server » était issue d’une erreur dans la gestion des tokens, nous permettant ainsi de déterminer facilement un token qui sera toujours valide.

C’est quoi Livezilla ?

Livezilla est un service d’assistance en ligne permettant de dialoguer instantanément avec vos clients. Il accélère les échanges entre le support technique, marketing, les clients etc. De plus, c’est une solution gratuite. Elle évite donc les surcoûts au niveau des échanges téléphonique, par exemple.

Cette vulnérabilité a été découverte par l’un de nos collaborateur certifié (OSCP). Elle touchait toutes les versions supérieures à 7.0.

Un correctif a été appliqué à la dernière version 8.0.0.6. Vous trouverez les explications de la vulnérabilité ci-dessous.

Versions testées

Version actuelle : 8.0.0.6

Version initialement testée : 8.0.0.4

Anciennes versions testées : Version 8.0.0.0, Version 7.1.0.6, Version 7.0.9.1, Version 7.0.0.0

Explication

L’erreur venait de la fonction IsValidToken présente dans le fichier objects.global.users.inc.php

Code informatique sur fond blanc de la faille Livezilla

Nous avons ici une comparaison entre une entrée utilisateur ($_token) et un hash généré à partir de la variable Token.

Dans un premier temps, lorsqu’un utilisateur se connecte à Livezilla dans la partie administrateur du logiciel et non utilisateur, il génère un Token qui est un hash (une chaîne de caractère générée aléatoirement). Ainsi, chaque administrateur, lorsqu’il tape son mot de passe, se voit générer un hash unique équivalent à son mot de passe. De plus, il faut savoir que chaque mot de passe a un hash différent, et que même si deux mots de passe sont proches (abcd et abcde par exemple), les hashs générés seront totalement différents. Il est impossible de connaître les hashs générés pour chaque personne, de manière à rendre toute usurpation impossible.

Ainsi, si l’on veut accéder à l’interface administrative de Livezilla, on nous demande un hash (qui est donc impossible à trouver, comme vu précédemment). Cependant, un problème survient lorsqu’il n’y a aucune connexion sur cette interface administrateur. Dans ce cas-là, la variable demandée est égale à une chaîne de caractère vide. Elle correspond à un sha256 d’une chaîne de caractère vide.

Nous savons donc que le token attendu sera : e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Récupérer les logs

La seule méthode qui utilise la fonction ValidateToken (qui exploite la fonction IsValidToken) était celle présente dans le fichier log.php, nous permettant de récupérer les différents logs générés par Livezilla. On pouvait ainsi récupérer les erreurs php, mysql, mail, ldap en effectuant une requête GET comme ci-dessous :

http://serveur-livezilla-test.com/log.php?v= e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855&t=php

Récupérer ces informations permettait d’avoir potentiellement accès à des identifiants de connexion, des échanges de mail avec les clients, des échanges écrits et des informations personnelles. Il ne faut donc pas sous-estimer les risques potentiels de cette vulnérabilité pour le client comme l’administrateur.

La fonction IsValidToken s’utilise aussi dans la fonction d’authentification ValidateLoginAuthentication, mais il n’y a ici aucun moyen d’exploiter la vulnérabilité grâce à la présence de la condition :

Code informatique sur fond blanc de la faille Livezilla

Ici, si la chaîne de caractère est vide, la condition sera réfutée et le retour de la fonction sera par conséquent False.

Correction

Voici la correction que nous avons proposé et qui a été mise en place avec la mise à jour 8.0.0.6.

Il suffit de vérifier que la variable Token dans la fonction IsValidToken ne soit pas une chaîne de caractère vide, ainsi il n’est pas possible de déterminer à l’avance le hash.

Code informatique sur fond blanc de la faille Livezilla

Timeline

Première notification à Livezilla restée sans réponse : 30/11/2018

Relance auprès de Livezilla : 05/12/2018

Réponse de Livezilla le 06/12/2018

Communication de la vulnérabilité à Livezilla le 06/12/2018

Demande d’informations supplémentaires de la part de Livezilla le 10/12/2018

Envoi des informations supplémentaires le 12/12/2018

Réponse expliquant que la vulnérabilité sera corrigée dans la version 8.0.0.6 le 12/12/2018

Vulnérabilité patchée avec la version actuelle 8.0.0.6

Write A Comment