mcorybillington/suitecrm-rceAnalyse de CVE-2020-28328 : SuiteCRM Log File Remote Code Execution ainsi qu'un bonus de Cross-Site Scripting
J'ai récemment découvert deux vulnérabilités dans SuiteCRM qui fournissent une chaîne d'attaque permettant à un utilisateur à faible privilège d'exécuter du code sur le système d'exploitation sous-jacent. La chaîne d'attaque est une Cross-Site Scripting, qui peut être utilisée pour effectuer une Cross-Site Request Forgery, menant à une exécution de code à distance en modifiant la configuration de l'application et en empoisonnant un fichier journal. Tout cela est réalisé via un téléchargement de fichier contenant du JavaScript malveillant qu'un utilisateur à faible privilège peut amener un utilisateur disposant de privilèges administratifs à exécuter. Les fichiers de preuve de concept et la vidéo que j'ai jointes montrent un utilisateur à faible privilège effectuant cette attaque et obtenant un reverse shell sur le système hébergeant SuiteCRM.
Ceci a été corrigé dans la version 7.11.17 de SuiteCRM.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Je ne suis pas entièrement d'accord avec cette évaluation car l'exploit nécessite un accès administratif, ce qui changerait PR:L en PR:H, ajustant le score final de 8,8 à 7,2.
Je le noterais comme : CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Réf. : https://nvd.nist.gov/vuln/detail/CVE-2020-28328
SuiteCRM Version 7.11.15
La Cross-Site Scripting stockée existe dans le téléchargement de fichiers 'Create Documents'. Un utilisateur à faible privilège peut télécharger un fichier avec n'importe quel contenu. L'utilisateur peut ensuite examiner le lien fourni pour télécharger ce document et déterminer l'emplacement du fichier sur le système de fichiers en localisant le paramètre id. Cette longue valeur aléatoire est le nom du fichier dans le répertoire /uploads/. L'utilisateur peut placer du JavaScript arbitraire dans ce fichier, puis envoyer le lien à un autre utilisateur. Cela peut être utilisé pour détourner la session d'un autre utilisateur et/ou effectuer des actions en son nom, comme le montre la vidéo de la preuve de concept.
Après avoir découvert que je pouvais devenir administrateur par détournement de session via la Cross-Site Scripting, j'ai ensuite découvert que je pouvais contrôler les propriétés système sous 'Admin → System Settings', notamment la propriété du fichier journal. Les extensions de fichier journal étaient assez bien bloquées, mais j'ai pu utiliser BurpSuite pour mettre à jour la valeur 'Log File Name' avec n'importe quelle valeur arbitraire, y compris des extensions .php. Pour ce faire, j'ai soumis une requête sans rien modifier et capturé la requête POST qui met à jour les valeurs. J'ai modifié le nom du fichier via le paramètre logger_file_name en shell.php et simplement rendu le champ 'Extension' vide. Cela a fourni un fichier php que je pouvais accéder dans le navigateur à la racine web, mais j'avais besoin de code php à l'intérieur du fichier pour l'exécuter.
Ensuite, j'ai examiné la sortie dans le fichier et remarqué que je pouvais contrôler l'entrée dans le fichier via les propriétés de l'utilisateur si je mettais à jour un utilisateur (comme le prénom ou le nom de famille), si la journalisation était réglée sur info (je crois que c'était par défaut...). J'ai donc capturé une requête dans burp et inséré du code php <?php $id =id; echo $id; ?> dans le champ du formulaire last_name. Cela a entraîné la sortie de la commande id sur Linux dans le contexte de l'utilisateur du serveur web, www-data. Les seuls caractères qui, d'après le fichier journal, étaient échappés sont les guillemets simples, les guillemets doubles et les antislashs. Vous pouvez vérifier cela en exécutant tail sur le fichier journal SQL sur le backend.
J'ai pu effectuer tout cela en tant qu'utilisateur administrateur car j'ai pu obtenir les cookies de session, mais pour avoir une chaîne fonctionnelle, je devais que cela s'exécute via JavaScript dans le contexte de l'utilisateur administrateur. J'ai pu scripté cela à l'aide de quelques requêtes fetch pour effectuer chacune de ces requêtes POST. La première mettait à jour les propriétés système, la seconde mettait à jour le champ 'Last Name' de l'utilisateur administrateur, et la dernière effectuait une requête GET sur le fichier journal nouvellement créé avec du code php malveillant. Le code php malveillant effectuait une requête curl vers ma machine, téléchargeait un reverse shell bash, puis redirigeait la sortie de cette requête curl directement vers bash, exécutant le code. J'ai ensuite téléchargé cela en utilisant la même méthode que celle discutée dans la section XSS et revisité le nouveau lien en tant qu'utilisateur administrateur. Avec un serveur web hébergeant mon fichier bash et un écouteur netcat en cours d'exécution, j'ai pu obtenir un reverse shell.
Assurez-vous d'avoir AllowOveride All défini dans Apache. nginx n'a pas ce paramètre et je ne l'ai pas testé sur nginx.
Mettez à jour vers la dernière version de SuiteCRM, ou au moins la version 7.11.17.
C'est le correctif spécifique. Commit 1618af16eaa494c4551bac961e5ac8fc3d87ab8c
SuiteCRM a été très réactif tout au long du processus de signalement. Ils ont reconnu la RCE, qui a été corrigée. La XSS était le résultat d'une configuration de serveur web, ils ne l'ont donc pas reconnue comme une vulnérabilité. Ils ont cependant noté qu'ils mettraient à jour la documentation à la lumière de cela.
06 AUG 2020 -> Les deux problèmes signalés à [email protected]
07 AUG 2020 <- SuiteCRM confirme la réception du rapport et soulève le problème auprès de l'équipe de sécurité interne
21 AUG 2020 -> J'ai contacté [email protected] pour un suivi
25 AUG 2020 <- SuiteCRM répond concernant la configuration du serveur web/XSS
26 AUG 2020 -> Je réponds pour dire que la suggestion de AllowOveride All atténue la XSS
16 SEP 2020 -> J'ai contacté [email protected] pour un suivi
17 SEP 2020 <- SuiteCRM répond pour confirmer le problème comme partiel
29 OCT 2020 Mise à jour publiée
03 NOV 2020 -> Je contacte [email protected] pour m'assurer que rien d'autre n'est nécessaire de leur côté avant de publier l'analyse
05 NOV 2020 <- SuiteCRM répond
Maintenant que nous avons publié un correctif pour ce problème et qu'il est dans le domaine public, il n'y a aucun problème pour que vous fassiez un article de blog sur les vulnérabilités de notre point de vue.
05 NOV 2020 -> CVE demandé par moi
06 NOV 2020 <- CVE-2020-28328 publié
https://www.exploit-db.com/exploits/49001
Ils ont été très faciles à travailler et je prévois certainement de continuer à rechercher et signaler des vulnérabilités dans ce logiciel !
