Les plugins maintenus doivent-ils être suspendus du référentiel WordPress en cas de problème de sécurité ?

Le 27 février 2020, à 21h34 (CET), nous avons reçu un e-mail nous informant que notre plugin WP Activity Log était " temporairement retiré du répertoire des plugins WordPress.org en raison d'un exploit" .

Nous avons soumis un correctif le vendredi 28 février 2020 à 16h08. Il ne nous a fallu que 16,5 heures pour publier le correctif. Nous aurions résolu le problème beaucoup plus tôt si cela s'était produit pendant nos heures normales de travail (nous sommes basés en Europe), car nous avons un très bon temps de réponse du support (référence).

Notre plugin a été rétabli le lundi 2 mars 2020 à 13h00. C'est 69 heures après que nous ayons soumis le correctif. Il est important de noter qu'il a fallu si longtemps à l'équipe pour rétablir le plugin à cause du week-end.

Pourquoi est-ce que j'écris ceci ?

Je tiens à souligner que je pense que les plugins non maintenus qui ont des problèmes de sécurité devraient être suspendus du référentiel WordPress. De plus, j'ai un immense respect pour le travail effectué par les bénévoles de l'équipe de révision des plugins, et j'assume également l'entière responsabilité du problème de sécurité signalé.

Cependant, je pense que les problèmes de sécurité signalés dans les plugins maintenus pourraient être mieux gérés. En raison de la façon dont ils sont gérés actuellement, la réputation du plugin en pâtit, et ses utilisateurs et leurs sites Web sont mis en danger. Par conséquent, à la fin de cet article, je mets en évidence quelques améliorations possibles qui peuvent aider, et je pense qu'elles devraient être prises en compte. L'idée est de toujours mettre moins d'utilisateurs en danger et de réduire l'impact sur le plugin et les développeurs.

Dans cet article, je documente également tous les détails de ce qui s'est passé et j'explique la vulnérabilité de cas marginal de faible gravité signalée dans notre plugin.

Quelle est la procédure pour signaler un problème de sécurité du plugin WordPress ?

D'après les directives officielles du Plugin Handbook :

Toute tentative de contacter directement le développeur doit être faite avant de nous signaler le plugin (bien que nous comprenions que cela peut être difficile - vérifiez d'abord le code source du plugin, de nombreux développeurs répertorient leurs e-mails). Si vous ne pouvez pas les contacter en privé, veuillez nous contacter directement et nous vous aiderons.

Que s'est-il passé dans notre cas ?

Nous indiquons très clairement dans le plugin qui développe le plugin. Il suffit de regarder la page du plugin sur le référentiel et vous aurez une idée ! Nous facilitons également la prise de contact.

Cependant, personne ne nous a signalé le problème de sécurité avant que le plugin ne soit temporairement retiré du référentiel de plugins. Quelqu'un a donc signalé le problème à l'équipe de révision des plugins WordPress et ils ont temporairement retiré notre plugin du référentiel sans aucune notification préalable.

Avant de plonger dans le pourquoi et le quoi, et ce qui est bon, mauvais et ce qui peut être amélioré, examinons la vulnérabilité du plugin et une brève explication de qui nous sommes.

Quelle était la vulnérabilité du plugin ?

Nous avons un assistant d'installation dans WP Activity Log pour aider les utilisateurs à configurer le plugin. L'un des paramètres de l'assistant vous permet d'autoriser les utilisateurs non administrateurs à lire les journaux d'activité.

Cependant, nous avons fait une erreur; nous n'avons pas vérifié si l'utilisateur exécutant l'assistant était authentifié. Par conséquent, les utilisateurs non authentifiés pourraient exécuter l'assistant et permettre à un autre utilisateur ou rôle d'accéder aux paramètres du plug-in. Cependant, il s'agit d'un problème de faible gravité.

Pourquoi s'agit-il d'un problème de sécurité lié aux cas périphériques de faible gravité ?

Les attaquants ne pourraient exploiter cela que si :

• l'assistant d'installation n'a jamais été terminé par l'installateur,
• les attaquants avaient déjà un utilisateur / avaient accès à un utilisateur sur le site Web,
• Les attaquants ne peuvent accéder qu'aux paramètres et au journal d'activité du plugin.

En exploitant ces problèmes de sécurité, les attaquants n'ont pas accès à d'autres privilèges sur le site Web WordPress. Par conséquent, cet exploit n'a aucun effet négatif sur le comportement et la fonctionnalité du site Web lui-même.

Preuve de concept

Le COP est très simple. Visitez cette page en tant qu'utilisateur non authentifié :

http://example.com/wp-admin/admin-post.php?page=wsal-setup&current-step=access

Il s'agit de l'étape de l'assistant qui vous permet de spécifier qui peut voir les journaux. Recherchez le nonce '_wpnonce' dans le source de la page HTML, copiez-le et insérez-le dans la commande curl suivante :

$ curl 'http://example.com/wp-admin/admin-post.php?page=wsal-setup&current-step=access' -d '_wpnonce=INSERT-NONCE-HERE&wsal-access=yes&editors%5B%5D= abonné&save_step=Suivant'

Une fois que vous vous connectez en tant qu'abonné, vous aurez un accès complet aux paramètres du plugin.

Pourquoi pensons-nous que cette affaire a été mal gérée ?

Dans le mail qui nous a été envoyé, il y avait ceci :

Nous ne fermons pas les plugins à la légère, et en ce qui concerne les problèmes de sécurité, nous essayons d'équilibrer le volume d'utilisateurs et l'historique des développeurs avec la gravité et le potentiel de dommages du rapport.

Cependant, je pense que notre plugin a été retiré trop tôt. Jusqu'à présent;

1. Lorsque nous avons eu des problèmes dans le passé, nous les avons toujours résolus en quelques heures. Nous avons fait la même chose cette fois.
2. Nous avons toujours répondu à temps lorsque l'équipe de révision des plugins est entrée en contact.
3. Le problème de sécurité n'affectait que notre plugin (faible gravité) et c'était un cas marginal.
4. Le problème de sécurité n'a pas pu être exploité automatiquement.
5. Le seul dommage que l'attaquant pouvait faire était de modifier les paramètres du plug-in, de lire les journaux d'activité ou de les purger.

Que pensent les autres développeurs de telles situations ?

La plupart d'entre nous ont déjà lu un article, un tweet ou un message sur les réseaux sociaux à propos de problèmes similaires. Cependant, je voulais savoir par moi-même ce que les autres, en particulier les développeurs, en pensaient. Je pense que c'est important parce qu'il y a peut-être des choses que je ne vois pas.

Pour commencer, j'ai envoyé un e-mail à la personne qui a identifié le problème, le remerciant pour la divulgation responsable. Sa réponse a été :

« Heureux de voir que vous avez rapidement résolu le problème dans le plugin. BTW, j'ai remarqué que les gens de wordpress.org l'ont fermé pendant quelques jours, c'était un peu dur et ce n'était pas vraiment nécessaire. »- Jérôme Bruandet.

J'ai également fait un petit sondage sur le groupe Facebook Selling WordPress Products. Bien que ce groupe soit petit, la majorité de ses membres sont des développeurs de plugins et de thèmes. D'après le sondage, nous pouvons voir que les développeurs conviennent à l'unanimité qu'en cas de problèmes de gravité faible à moyenne, les développeurs doivent être contactés et avoir la possibilité de fournir un correctif et de ne pas retirer le plugin :

Comment ces procédures peuvent-elles être améliorées ?

À ma connaissance, il n'y a pas de procédures documentées en place lorsque quelqu'un signale un problème de sécurité dans un plugin. Si tel est le cas, des procédures telles que celles décrites ci-dessous pourraient aider les développeurs et également mettre moins de personnes en danger.

Contactez les développeurs et convenez d'un plan d'action avant de fermer le plugin

L'équipe de révision des plugins peut essayer de contacter les développeurs et confirmer la vulnérabilité avant de fermer le plugin. Les développeurs doivent répondre avec un plan d'action, y compris une date raisonnable pour le correctif.

Si nécessaire, l'équipe de révision des plugins peut fixer un délai. Par exemple, les développeurs doivent avoir entre 12 et 24 heures pour résoudre le problème. Cependant, dans certains cas, ils peuvent avoir besoin de plus de temps, en fonction du fuseau horaire dans lequel ils se trouvent, etc. Si les développeurs ne répondent pas, le plugin doit être retiré du référentiel.

Déterminer la gravité et le type du problème de sécurité

Cela pourrait faire l'objet d'un débat. Cependant, une personne ayant un peu d'expérience en matière de sécurité peut facilement savoir si un problème de sécurité signalé peut être automatiquement exploité, s'il s'agit d'un cas marginal ou non, et quel est son impact à partir de la preuve de concept (POC) signalée.

Vérifier que les développeurs respectent le plan d'action

Il devrait y avoir une sorte de vérification en place pour confirmer que les développeurs soumettent le correctif à temps et s'en tiennent à toutes les autres tâches incluses dans le plan d'action.

Le retrait des plugins maintenus du référentiel n'aide pas

Dans le cas des plugins maintenus, les retirer du référentiel fait plus de mal que de bien. Par example;

1. Vous rendez public le fait que le plugin a un problème, très probablement un problème de sécurité. Cela déclenche de nombreuses alarmes et met en lumière le plugin. C'est aussi comme inviter des attaquants, leur dire que quelque chose dans le plugin est peut-être exploitable.
2. Il expose la base d'utilisateurs actuelle du plugin car tout d'un coup, leurs sites Web sont devenus une cible. La plupart des utilisateurs n'ont aucune idée de ce qu'ils doivent faire, surtout si la fonctionnalité du plugin est au cœur de leur site Web et de leur entreprise.
3. Vous augmentez les chances de retarder le correctif. Cela est généralement causé par un manque de communication ou à cause des vacances et des week-ends.

On pourrait dire qu'en retirant un plugin du référentiel, vous empêchez l'infection de se propager . Cependant, si le problème de sécurité est de faible gravité, l'exploitation ne peut pas être automatisée, et la divulgation est responsable, il n'y a pas de risques impliqués, ou les risques sont extrêmement faibles.

Avis de non-responsabilité : ceci n'est pas une attaque

Je tiens à souligner qu'il ne s'agit pas d'une attaque contre l'équipe de révision des plugins WordPress ou toute personne impliquée dans ces processus. Honnêtement, je respecte leur travail et je sais que ce qu'ils font est fait de bonne foi. Cependant, il y a certainement place à l'amélioration, comme dans tout autre système et processus.

Beaucoup me diront probablement que si je veux un changement, je devrais me porter volontaire au lieu d'écrire ce post.

J'ai essayé de rejoindre pendant un certain temps; J'ai parlé à plusieurs personnes de différents WordCamps pour m'impliquer, et j'ai également surveillé la page Make WordPress plugins pour les appels à volontaires. Cependant, ces dernières années, il n'y avait pas de postes vacants. Lorsqu'ils avaient besoin d'aide, ils ajoutaient de nouveaux membres sur invitation uniquement.