[RÉGLÉ] Vulnérabilité

[RobertG]

Bonjour,

Dans une ligne de code "exec" utilisant un mot de passe défini dans le paramétrage d'un plugin, l'utilisation du mot de passe tel que saisi pourrait constituer une vulnérabilité.

Dans la mesure où il faut déjà accéder aux paramétrages du plugin pour tenter d'insérer une commande en guise de mot de passe, je ne suis pas certain que cette vulnérabilité soit importante, puisque l'auteur aurait déjà accès à l'administration, mais autant l'éviter.

Pouvez-vous me dire si ce traitement élimine le risque ?

$password= preg_replace('`(?<!^) `', '^ ', escapeshellcmd($password)) ;

Merci d'avance !

[cavo789]

Hello

Rapido, j'aurais tendance à faire l'inverse càd à appliquer une expression régulière (regex) sur la valeur introduite.

Rapido, voici un exemple de regex https://regex101.com/library/0bH043

L'idée est donc p.ex. d'interdire des caractères tels que "<", "?", un espace, ... et donc avoir une suite de caractères consécutifs et d'une longueur définie (ne pas permettre une chaîne de 250 caractères p.ex.).

Rapido parce que j'imagine qu'il devrait être possible de trouver une regex "standard" càd quelque chose d'éprouver par la communauté; je ne sais pas si c'est le cas de la regex que je propose; cela semble en tout cas correspondre.

Bonne journée.

(tiens, sur le site owasp, tu peux trouver quelque chose de sympa : https://owasp.org/www-community/OWAS...gex_Repository)

[daneel]

L'un des points de sécurité recommandé pour Joomla est de desactiver : exec,passthru,shell_exec,system, proc_open,proc_close,proc_terminate,popen,curl_exe c,curl_multi_exec, show_source,posix_kill,posix_getpwuid,posix_mkfifo ,posix_setpgid,posix_setsid,posix_setuid,posix_set uid,posix_uname,php_uname,syslog

En pratique, le firewall du serveur devrait gérer cela sans nécessiter d'extension particulière pour Joomla. Si votre hébergeur ne propose pas une sécurité adéquate même en mutualisé, il serait judicieux d'en changer (parfois le firewal n'est pas activé par défaut... ce qui peut être regrettable)

Pour clarifier, lors de l'analyse, on compare une valeur à un hash bcrypt. Le mot de passe lui-même n'est pas interprété, car on ne fait que vérifier si le résultat correspond à celui stocké en ligne. Il est important de noter que Joomla ne conserve pas les mots de passe, mais seulement les résultats de hachage, ce qui est similaire à une empreinte digitale du mot de passe. Une analogie pourrait être les derniers chiffres d'une série qui permettent de vérifier l'exactitude de la saisie, bien que le processus de hachage soit beaucoup plus complexe.

Perso, mon firewall de mon serveur agit directement en bloquant les tentatives malveillantes... en premier par un captcha puis par un bannissement par l'ip à durée limité puis totale en cas de récidive.
A défaut d'avoir ce niveau de sécurité suffisant, tu peux utiliser celui de cloudflare.

Si tu devais développer un plugin, il faudrait agir également en temps réel donc de desactiver le bouton de soumission pour analyser préalablement avant de valider l'envoi.
gérer le scoring, les bannissement temporaires, etc... ce qui n'est si pas simple.

[RobertG]

Merci Christophe et Yann,

La vulnérabilité m'a été signalée par Prim Infosec à propos des guillemets pouvant encadrer un pseudo mot de passe et donc autoriser l'exécution d'une commande ( soit ` <system_command> ` with backticks ), et escapeshellcmd m'a été conseillé pour bloquer cette "autorisation".
J'ai utilisé la doc PHP pour cette ligne.
Dans la mesure où le plugin est utilisé partout dans le monde, la question du serveur est à oublier.
Et la question est pour moi de savoir par quoi je pourrais remplacer exec :

exec("$zipcmd -j -P $password \"$backupfile.zip\" \"$backupfile\"");

[RobertG]

Pour compléter ma réponse, je précise que la vulnérabilité citée par Prism Infosec est représentée par l'encadrement d'une éventuelle commande par ces "backticks".
J'avais proposé de les supprimer simplement, mais la réponse a été qu'un utilisateur ne pourrait alors pas en utiliser au sein de son mot de passe.

Par ailleurs, puisqu'il s'agit de lancer une commande, le pirate n'aurait rien à faire du mot de passe du fichier généré pour l'extraire, alors qu'un utilisateur lambda ne pourrait alors plus décrypter cette sauvegarde si un traitement de ce mot de passe survenait sans qu'il le sache.

[cavo789]

Il m'avait semblé que tu souhaitais protéger password et là je comprends que tu souhaites exécuter un exec() en php. Ma première réponse est, logiquement, toujours valide pour ton problème.

Vient ensuite la question du exec (), là je rejoins Yann, ce serait vraiment très étrange que cette fonction soit autorisée par l'hébergeur puisqu'elle est potentiellement très dangereuse.

[RobertG]

Je veux interdire au password d'être considéré comme une commande à exécuter, en raison de la présence des backticks en début et fin de chaîne, et qui permettrait à un pirate déjà rentré dans l'administration (à moins qu'il soit possible par code php de modifier les paramètres du plugin, mais dans ce cas, peu importe la protection, elle n'existe plus) de lancer une commande indésirable.
C'est pourquoi il m'a été demandé de ne pas autoriser ces caractères encadrant ce qui pourrait être une commande.
exec() est utilisé depuis des lustres dans ce code et je n'ai jamais eu de remarque sur un blocage par l'hébergeur, ou alors j'ai oublié, et j'ignore comment le remplacer.

[daneel]

Je veux interdire au password d'être considéré comme une commande à exécuter, en raison de la présence des backticks en début et fin de chaîne, et qui permettrait à un pirate déjà rentré dans l'administration

? désolé je ne comprends pas le sens? C'est un lundi un peu difficile donc je te prie de m'excuser. Tu sais que la saisie des mots de passe joomla sont déjà bien protégés et la saisie de l'authentification est déjà filtrée tout comme la plupart des champs jform (je crois qu'il y a de nombreux filtres disponibles utilisable dans la déclaration du manifeste xml.

Si c'est une extension tierce, je serai étonné qu'une erreur passe le jedchecker tu indique que c'est le paramètre d'une extension ? tu as plus de précision ?
il me semble que les backticks sont exclus depuis plus d'une décennie... Si c'est une extension existante disponible sur la jed alors il faut signaler à la VEL : https://extensions.joomla.org/vulner...ensions/about/

[cavo789]

(bien compris maintenant, rien à voir avec l'introduction du mot de passe)

[RobertG]

Il s'agit d'un mot de passe paramétré dans les options du plugin et destiné à crypter un fichier, cryptage optionnel.
D'après Prism Infosec, si un visiteur indésirable de l'administration encadre une commande par des backsticks, elle pourra être exécutée (si le serveur ne la bloque pas) et ce visiteur pourrait obtenir des infos sensibles, d'où leur demande d'interdire cette exécution en supprimant ces guillemets obliques.
Depuis que le plugin est disponible sur le JED (13 ans pour moi, plusieurs années pour l'auteur initial), il n'y a jamais eu d'alerte sur ce point.

Donc logiquement, l'utilisation de escapeshellcmd () ne devrait pas permettre qu'une commande insérée en guise de mot de passe soit exécutée, puisque plus reconnue comme telle mais seulement comme mot de passe.

[daneel]

oui tu peux donc modifier comme tu veux, mais tu auras compris l'intérêt d'informer de l'existence d'une faille auprès de l'équipe et de l'auteur.

Tu as testé avec la dernière version de jedchecker ? Ton extension est pour la version 3 ou compatible version 4 ?

Si une telle faille était présente, l'extension aurait du être retiré le temps du patch... et toute aide est la bienvenue surtout en ce moment :

https://forum.joomla.fr/forum/th%C3%A8mes-communautaires/tout-et-rien/2054639-la-fin-de-l-annuaire-des-extensions-jed-joomla-extensions-directory

[RobertG]

Mises à part des broutilles, le JED Checker ne relève rien d'anormal.

[Tortue Genial 69]

petit complément : il ne faut pas désactiver la fonction PHP curl_exec sinon le check des extensions ne se fait pas quand on se connecte au backend.

[Fred2FR3]

Moi je comprend pas le raisonnement sauf si le mot de passe est conservé en BDD auquel cas ce n'est pas escapeshellcmd qu'il faut utiliser et j'ai envie de dire que si ce n'est pas le cas $password ne présente aucun danger dans la commande exécutée. Je ne suis même pas certain que "zip" accepte n'importe quels caractères dans son $password, le moindre espace (par exemple) mettrai la commande en carafe...

Enfin, pour remplacer exec, PHP peut très bien le faire : https://www.php.net/manual/fr/book.zip.php