Développeurs de plugins et de thèmes : voici ce que vous pouvez apprendre de la vulnérabilité de sécurité de notre SDK

Cette semaine a été assez intense pour notre équipe car nous avons dû faire face à une faille de sécurité. La sécurité est notre priorité absolue et il s'agit de la première vulnérabilité majeure détectée dans notre SDK en quatre ans. Malheureusement, comme pour tout logiciel, les développeurs sont aussi des humains, donc des erreurs se produisent, que vous soyez un développeur indépendant, un magasin de thèmes de 20 personnes ou Google. Le but de cet article est avant tout la transparence, mais aussi de vous donner un aperçu de la façon dont nous avons géré l'incident et ce que vous pouvez en apprendre.

Le lundi 25 février 2019, nous avons reçu un e-mail d'assistance d'un développeur utile qui est tombé sur un problème GitHub sur le référentiel WooCommerce. Le problème a été créé par un représentant d'une petite société d'hébergement qui a remarqué une activité suspecte sur ses serveurs. Le représentant a inclus les journaux d'activité pertinents qui indiquaient deux attaques potentielles, et l'une d'entre elles ciblait un plugin exécutant le SDK Freemius.

Comme nous prenons la sécurité très au sérieux, nous avons immédiatement mené une enquête approfondie et confirmé que la vulnérabilité se trouvait bien dans notre SDK.

En raison de la gravité de la vulnérabilité, nous avons immédiatement commencé à travailler sur un correctif. Après seulement quelques heures, nous avons publié une balise corrigée et informé tous les développeurs qui utilisaient une version SDK vulnérable de mettre à jour le SDK sur tous leurs produits dès que possible. Nous avons également mis à jour le problème GitHub d'origine pour en informer l'équipe WooCommerce (le problème GH que nous avons supprimé après quelques heures pour réduire l'exposition).

Pour atténuer l'exposition et donner à chacun un délai de "grâce" pour mettre à jour vers la version corrigée, nous avons demandé deux choses aux développeurs :
(a) Si cette mise à niveau de sécurité sera incluse dans votre journal des modifications, veuillez n'utiliser qu'un libellé générique tel que « Correctif de sécurité ».
(b) Même après la mise à jour et la publication des versions corrigées, veuillez ne pas divulguer ce problème au cours des 30 prochains jours, en laissant suffisamment de temps à tous nos partenaires et à leurs utilisateurs pour se mettre à jour.

Juste un jour après, un site Web qui couvre les vulnérabilités des plugins (intentionnellement sans lien vers eux ou sans mentionner leur nom) a publié un article sur la vulnérabilité, y compris des informations sur la façon de l'exploiter tout en nommant quelques-uns des plugins concernés. Cela nous a pris par surprise car nous venons d'informer les développeurs de plugins et de thèmes du problème moins de 24 heures auparavant. Ils ne nous ont pas contactés ni n'ont suivi la pratique du marché de la divulgation responsable , que nous trouvons tout à fait irresponsable et contraire à l'éthique.

Je les ai contactés pour leur demander de dépublier temporairement le rapport afin de réduire l'exposition et de donner à nos développeurs et à leurs utilisateurs une chance de mettre à jour les versions corrigées avant qu'il n'attire l'attention indésirable de plus de pirates. Mais la personne avec qui j'ai communiqué, qui n'a jamais révélé son nom (je lui ai demandé), a sa propre idéologie juste et semble que le bon sens ne lui plaît pas vraiment. J'ai essayé d'expliquer la situation problématique et le risque accru qu'ils exposent à de nombreux développeurs et utilisateurs, mais mes efforts sont tombés dans l'oreille d'un sourd et j'ai réalisé que mon échange d'e-mails n'était qu'une perte de temps.

Alors que notre communauté de développeurs mettait à jour leurs plugins et thèmes vers le SDK récemment corrigé que nous avons publié, nous avons découvert deux problèmes :

1. Plusieurs développeurs n'ont pas reçu notre e-mail d'alerte car ils se sont inscrits sur Freemius avec une adresse e-mail qu'ils ne vérifient pas.
2. Nous n'avons intentionnellement pas signalé la balise GitHub corrigée comme une version officielle pour éviter d'attirer l'attention. Cependant, nous avons appris que les développeurs qui utilisaient Composer pour mettre à jour leurs bibliothèques n'obtenaient pas la dernière mise à jour car packgist ne récupère que les versions, à moins de spécifier explicitement une balise.

Pour surmonter ces problèmes :

1. Étant donné que la vulnérabilité a déjà été publiée publiquement, il y a deux jours, nous avons signalé la version corrigée comme une version officielle afin que les développeurs qui s'appuient sur packgist puissent mettre à jour.
2. Plus tôt ce matin, nous avons envoyé un autre lot de messages aux développeurs qui n'ont pas encore mis à jour le SDK sur tous leurs produits. Cette fois, nous avons envoyé les messages à leurs canaux d'assistance officiels pour augmenter les chances que tout le monde reçoive correctement les e-mails.

Même si nous voulions reporter la publication de cette vulnérabilité d'au moins deux semaines, nous avons reçu une autre demande de WP Tavern demandant notre avis avant qu'ils ne publient leur propre article sur le sujet, qui était la goutte qui a fait déborder le vase du développeur.

Les erreurs que nous avons commises et ce que vous pouvez en tirer

En repensant à l'incident, nous avons commis plusieurs erreurs que nous pouvions facilement éviter et qui auraient rendu la vie de tout le monde beaucoup plus facile.

Passez en mode silencieux et n'alertez que ceux qui ont besoin de savoir

Étant donné que nous étions si désireux de résoudre le problème dès que possible, j'ai personnellement commis une erreur de « débutant » qui a attiré trop tôt une attention indésirable. Je suis allé de l'avant et j'ai validé le correctif dans le référentiel GitHub que nous utilisons pour gérer le SDK. Non seulement le référentiel est public, mais j'ai expliqué le correctif et y ai utilisé le mot "sécurité".

La meilleure approche consistait à créer une version privée/fermée du référentiel, à y corriger le problème de sécurité et à ne l'exposer qu'aux développeurs concernés au lieu de le rendre public. Cela n'attirerait pas l'attention des « chasseurs de vulnérabilités ».

Ne gaspillez pas votre énergie avec des "trolls de sécurité"

La deuxième erreur a été d'essayer d'interagir avec la société derrière le site qui a publié la vulnérabilité. C'était une perte totale de temps et d'énergie, et n'a déclenché que plus d'antagonisme qui s'est terminé par un autre message sur la vulnérabilité. Je dirais qu'un bon indicateur pour décider s'il vaut la peine de contacter un auteur d'un article qui risque de mettre en danger les utilisateurs de votre plugin ou de votre thème, c'est s'il y a un nom derrière l'article/le site Web/la société. S'ils se cachent derrière des mandataires et agissent de manière irrationnelle, la chance que vous puissiez leur parler raisonnablement est pratiquement nulle.

Voici donc mon conseil - passez en mode silencieux et informez uniquement les personnes qui doivent être au courant de la vulnérabilité. Dans le cas d'un plugin/thème, ce sont vos utilisateurs. C'est aussi l'occasion de souligner l'importance de collecter les emails de vos utilisateurs. Si vous ne disposez d'aucun moyen de communiquer en privé avec vos utilisateurs, vous ne disposez d'aucun moyen efficace pour les informer en privé des problèmes de sécurité.

L'état actuel de l'incident

Plus de 60 % des développeurs qui utilisent notre SDK ont déjà effectué la mise à niveau vers la version corrigée. De plus, le SDK est livré avec un mécanisme spécial qui permet à plusieurs plugins ou thèmes pris en charge par Freemius installés sur le même site Web WordPress d'utiliser la dernière version du SDK si l'un des produits est déjà mis à jour. Alors c'est bien.

Cela dit, il existe encore de nombreux sites vulnérables. C'est pourquoi je n'ai mentionné aucun détail technique sur la vulnérabilité elle-même, ni sur les produits concernés. Nous voulons toujours offrir à nos développeurs la possibilité de patcher leurs produits et de permettre à leurs utilisateurs de mettre à jour les versions sécurisées.

Comment réduire les risques de sécurité dans votre plugin/thème WordPress ?

Si vous n'avez aucune expérience en matière de sécurité, Google "meilleures pratiques de sécurité Web" et vous trouverez des tonnes d'articles et de pratiques. Lisez-en quelques-uns pour être conscient des risques et des erreurs potentiels modernes et typiques. Gardez-les à l'esprit pendant les processus de développement et de test. Une autre bonne pratique consiste à effectuer des audits de sécurité périodiques en embauchant un chercheur en sécurité. Cela vous coûtera quelques centaines de dollars, mais si vous comptez sur votre produit comme principale source de revenus, c'est une évidence.

Malheureusement, comme dans notre cas, de mauvaises choses peuvent encore arriver. Même si nous avons une solide expérience en matière de sécurité, nous effectuons des examens approfondis du code et travaillons avec un chercheur en sécurité expérimenté de la communauté HackerOne, mais cette vulnérabilité est toujours passée entre les mailles du filet. 😔

Je pense que l'une des raisons pour lesquelles cela s'est produit est que le code vulnérable a en fait été ajouté pour déboguer les cas extrêmes et ne fait pas partie des fonctionnalités de base du SDK. Donc, s'il y a une leçon ici, traitez n'importe quel morceau de code de votre produit de la même manière, qu'il fasse partie de la logique métier réelle ou de toute autre chose.

résumer

Les problèmes de sécurité sont inévitables dans le monde du logiciel. Que cela nous plaise ou non, un jour votre plugin ou votre thème aura un problème de sécurité. Le problème peut provenir de votre code, d'une bibliothèque/framework que vous utilisez, d'une méthode de base WordPress qui fournit des résultats inattendus et de nombreux autres scénarios.

Lorsque cela se produira (j'espère que ce ne sera pas le cas), ne vous stressez pas (nous l'avons certainement fait) et agissez de manière impulsive - cela ne fera que causer plus de dégâts. Rédigez un plan de redressement méthodologique, informez les parties concernées et soyez là pour aider vos utilisateurs à sécuriser leurs sites. Tout le monde sait que des problèmes de sécurité se produisent, ce qui est plus important, c'est la façon dont vous gérez la situation.

Cela dit, au nom de toute l'équipe Freemius, nous sommes vraiment désolés pour la gêne occasionnée et serons là tout au long du week-end pour offrir un soutien, des conseils ou toute autre aide liée au problème. Et pour nos nouveaux utilisateurs, je sais à quel point la première impression est importante, et ce n'est certainement pas la bonne. J'espère que vous donnerez une autre chance à Freemius, et avec le temps, vous verrez les fonctionnalités incroyables que nous proposons pour vos plugins et thèmes WordPress.