Selon des chercheurs en sécurité, les attaquants auraient pu faire des ravages dans l’écosystème PHP en exploitant une paire de vulnérabilités de longue date qui n’ont été corrigées que récemment dans le gestionnaire de packages PEAR.
Les comptes des développeurs PEAR ont été exposés au risque d’une prise de contrôle malveillante par une faille résultant d’une faible entropie sur la fonction de réinitialisation du mot de passe, a révélé Thomas Chauchefoin, chercheur en vulnérabilités à la société de sécurité suisse SonarSource, dans un article de blog.
Les attaquants pourraient alors sécuriser un accès persistant au serveur PEAR central en abusant d’une vulnérabilité distincte dans une version obsolète d’une dépendance groupée.
Les défauts sont restés inconnus pendant plus de 15 ans. Chauchefoin dit La gorgée quotidienne que le fait que des chercheurs, et non des attaquants, aient découvert les failles était « une échappatoire heureuse », étant donné qu' »une compromission du référentiel PEAR aurait permis aux attaquants de détourner n’importe quel paquet hébergé sur la plate-forme » et de publier des versions malveillantes.
SonarSource a publié un vidéo expliquant le scénario d’attaque à deux volets.
« Expertise technique minimale »
PEAR est tombé en disgrâce au milieu de la montée en puissance du gestionnaire de packages PHP concurrent Composer, dans le référentiel principal duquel SonarSource a révélé une vulnérabilité tout aussi grave l’année dernière.
Cependant, PEAR est encore largement utilisé, les packages Net_SMTP et Mail enregistrant à eux seuls 100 000 téléchargements par mois via le programme d’installation PHP.
Les vulnérabilités de la chaîne d’approvisionnement « auraient pu être facilement identifiées et exploitées par des acteurs de la menace avec seulement une expertise technique minimale, provoquant d’importantes perturbations et des failles de sécurité à travers le monde », selon Chauchefoin.
PRNG faible
Fonction de réinitialisation du mot de passe de PEAR utilisée mt_rand() pour générer des valeurs aléatoires, même si la technique est obsolète et inapproprié pour générer des valeurs cryptographiquement sécurisées.
Une fois les valeurs concaténées et hachées avec md5()« la valeur finale est uniquement basée sur deux inconnues, qui sont la sortie de mt_rand() et temps()», a déclaré Chauchefoin.
« Le premier ne peut pas donner beaucoup de valeurs (10), et le second peut facilement être approximé par l’attaquant. De plus, le serveur HTTP de pear.php.net ajoute un en-tête Date à ses réponses, le réduisant à seulement quelques valeurs (< 5).
Les chercheurs ont conclu que les attaquants pouvaient sécuriser un jeton de réinitialisation de mot de passe valide en 50 tentatives.
L’autre bogue fournissait une porte dérobée pour continuer les attaques même si le premier bogue avait été corrigé. « Cela pourrait également les aider à cacher leurs traces en modifiant les journaux d’accès », a déclaré Chauchefoin.
La faille est survenue parce que pearweb a extrait la version 1.4.7 de Archive_Tarqui était vulnérable à CVE-2020-36193un problème de traversée de répertoire pouvant entraîner l’exécution de code à distance (RCE) sur PEAR.
SonarSource a averti les responsables de PEAR des bogues le 30 juillet 2021.
Ils ont été corrigés dans la version 1.32 de pearweb, publiée le 13 mars, avec toutes les versions précédentes affectées.
Cependant, Chauchefoin a conseillé aux utilisateurs de PEAR « d’envisager de migrer vers Composer, où la communauté des contributeurs est plus active et où les mêmes packages sont disponibles ».
Trop de confiance
Les attaques de la chaîne d’approvisionnement logicielle ciblant PEAR et des outils de développement similaires ont un impact particulièrement important étant donné que les développeurs les exécutent souvent sur leurs ordinateurs avant de les déployer sur des serveurs de production, « créant une opportunité pour les attaquants de pivoter vers les réseaux internes des entreprises », a déclaré Chauchefoin.
La persistance des failles PEAR pendant tant d’années montre à quel point les entreprises bien dotées en ressources qui s’appuient sur des gestionnaires de packages ne font pas assez pour les sécuriser. « Les services backend des gestionnaires de paquets ne reçoivent que peu d’attention de la part des contributeurs à la sécurité, alors qu’ils sont un élément central de l’écosystème de chaque langage », explique le chercheur.
Citant des failles comparables trouvées dans Composer, CocoaPods et RubyGems, Chauchefoin prévient que « des vulnérabilités similaires seront retrouvées, il est donc très important d’essayer de réduire leur impact en supprimant la confiance que nous accordons aux services backend ; des initiatives comme sigstore sont une bonne réponse à cela et nous devrions pousser à leur adoption ».
