Presque chaque semaine, une nouvelle vulnérabilité est découverte dans un plugin ou un thème WordPress populaire, laissant les développeurs se démener pour la corriger avant qu’elle ne soit largement exploitée. Étonnamment, presque toutes les vulnérabilités critiques se résument à quelques erreurs courantes. Dans cette présentation de WordCamp Phoenix, Ramuel Gall passe en revue ces erreurs courantes et fournit des conseils sur la création de plugins sécurisés.

Retrouvez-nous sur votre application ou plateforme préférée, y compris iTunes, Podcasts Google, Spotify, Youtube, SoundCloud et Couvert.

Cliquez ici pour télécharger une version MP3 de ce podcast. Abonnez-vous à notre flux RSS.

Vous pouvez trouver Ram sur Twitter en tant que @ramuelgall.

N’hésitez pas à poster vos commentaires dans les commentaires ci-dessous.

Transcription pour l’épisode 67

Kathy Zant:
Salut tout le monde. Voici Kathy Zant et voici Think Like a Hacker, le podcast sur WordPress, la sécurité et l’innovation. Il s’agit de l’épisode 67. Cette semaine, nous aurons deux épisodes, 67, qui est celui-ci, et un épisode séparé plus tard cette semaine avec les dernières nouvelles de WordPress et de WordPress sur la sécurité. Nous avons quelques histoires en préparation, mais aujourd’hui, nous voulions présenter le discours de Ramuel Gall à WordCamp Phoenix plus tôt ce mois-ci en février 2020. Ram est l’un de nos principaux professionnels de l’assurance qualité. Il s’assure que tout ce qui se passe chez Wordfence est de la plus haute qualité. Des signatures de logiciels malveillants aux règles de pare-feu en passant par la relecture d’un article de blog, Ram est l’un de ces gars qui fait tout simplement avancer les choses et peut faire beaucoup de choses différentes. Ram est également un testeur de stylo d’application Web ou un testeur de pénétration certifié GIAC. Cela signifie qu’il trouve des vulnérabilités dans les applications Web, et peu importe ce que je dois faire à tout moment, Ram est là pour vous aider. Il est certainement l’un de ces joueurs d’équipe par excellence que vous voulez toujours de votre côté. Il est aussi très amusant à travailler.

J’ai encouragé Ram l’année dernière à lancer son nom dans le ring et à partager son amour de la sécurité des applications avec la communauté WordPress. Il a relevé le défi. Ceci est sa deuxième conférence WordCamp. Son premier était au WordCamp Long Beach l’automne dernier. Cette conférence est intitulée Fermez la porte d’entrée, Comment éviter les vulnérabilités critiques les plus courantes lors du développement de votre plug-in. Ram parlera des différents types de vulnérabilités et de la façon dont ces failles se retrouvent dans les plugins WordPress. Si vous songez à écrire un plugin WordPress, ou peut-être que vous l’avez déjà fait, Ram vous explique les pièges courants rencontrés par les développeurs de plugins et comment vous pouvez écrire du code plus sécurisé. Cette conférence est également disponible sur notre chaîne YouTube où vous pouvez également voir les diapositives de Ram. Sans plus tarder, voici l’un de mes membres préférés de l’équipe Defiant / Wordfence. Qui je plaisante… J’ai tellement de membres préférés de notre équipe. Nous espérons que vous apprécierez.

Ramuel Gall:
Bienvenue à Shut the Front Door. Je m’appelle Ramuel Gall. Je suis ingénieur QA chez Wordfence. Je suis un testeur de pénétration d’applications Web certifié par le GIAC, également un enquêteur légiste certifié par EC-Council Hacking Forensic Investigator, mais je n’ai pas mis cela sur le diaporama parce que ce n’est pas aussi pertinent. Si vous les mettez ensemble, je passe beaucoup de temps à regarder nos règles de pare-feu et les vulnérabilités qui sont couramment ciblées. Voici ce que nous allons couvrir. Nous allons d’abord passer en revue certaines définitions, les scripts intersites, la falsification de requêtes intersites, l’injection SQL et l’exécution de code à distance. Je viens de vous montrer les acronymes. Nous allons couvrir ce que les attaques réussies ont en commun. Nous allons couvrir ce que les attaquants font une fois qu’ils sont entrés. Nous allons couvrir ce qui pourrait mal se passer, ce qui se révèle être principalement un contrôle d’accès brisé. Je vais fournir quelques détails et exemples. Nous allons couvrir quoi faire à la place.

Commençons par les définitions. Le premier est XSS, le cross site scripting. Il s’agit simplement d’exécuter du code dans le navigateur de quelqu’un d’autre, généralement JavaScript, presque toujours JavaScript. CSRF, falsification de demande intersite, utilise la session de quelqu’un d’autre, effectuant une action en tant que quelqu’un d’autre parce que vous lui avez fait cliquer sur un lien. Maintenant, injection SQL, SQLi, qui exécute des commandes sur la base de données de quelqu’un d’autre. RCE, exécution de code à distance, qui exécute du code sur le serveur de quelqu’un d’autre.

Scriptage intersite, il en existe deux types. Il existe des scripts intersites reflétés. Il est généralement utilisé dans les attaques ciblées. Cela nécessite généralement une interaction de l’utilisateur. Vous devez obliger quelqu’un à cliquer sur un lien spécialisé. Il est utile pour une ingénierie sociale et il est généralement fait pour exploiter CSRF, ou du moins c’est ce pour quoi il est principalement utilisé dans les attaques ciblées. Ensuite, il y a des scripts intersites stockés, qui sont le type que nous voyons le plus souvent dans les attaques à grande échelle non ciblées. Il utilise des attaques au volant généralisées. Il est utilisé pour insérer de manière permanente des scripts malveillants. Il est beaucoup plus courant dans les attaques contre les plugins WordPress.

Contrefaçon de demande intersite, c’est-à-dire essentiellement une action en tant qu’utilisateur ciblé en détournant sa session. Il nécessite généralement, mais pas toujours, une interaction avec l’utilisateur. Il est souvent utilisé avec les scripts intersites car si vous pouvez demander à quelqu’un de cliquer sur un lien, disons que quelqu’un est connecté en tant qu’administrateur sur le site WordPress, vous lui demandez de cliquer sur un lien qui soumet un formulaire qui crée un nouvel administrateur … vous. C’est un bon exemple de cela. Lorsque les scripts intersites interviennent, eh bien, cela est généralement utile pour obtenir une protection nonce passée. Les nonces aident à empêcher cela s’il n’y a aucune vulnérabilité de script intersite présente.

Injection SQL, elle se produit généralement lorsque l’entrée n’est pas validée correctement. Cela a été moins courant ces dernières années. WordPress facilite la préparation des instructions afin que vous n’injectiez pas seulement du SQL brut dans vos requêtes de base de données. Ensuite, il y a l’exécution de code à distance. Habituellement, PHP ou du code shell sont utilisés lorsque WordPress est ciblé car tout WordPress s’exécute sur PHP et la plupart des WordPress s’exécute sur Linux. La gravité est généralement très élevée, car quiconque parvient à retirer cela peut essentiellement prendre n’importe quelle action en tant que propriétaire du processus PHP. Il peut être utilisé pour établir des portes arrière permanentes.

Qu’ont en commun les attaques réussies? Eh bien, tout d’abord, ils ont tendance à profiter de multiples défauts. Il s’agit très rarement d’une vulnérabilité de script intersite. Il s’agit de scripts intersites, et nous avons également oublié de vérifier que cette personne est autorisée à insérer un script, car les administrateurs devraient généralement être autorisés à faire des choses comme insérer des scripts. Ils ont tendance à être de faible complexité. C’est-à-dire que quelqu’un peut simplement rechercher un exploit et le copier et y mettre sa propre charge utile. Ils nécessitent généralement des privilèges minimaux. Une vulnérabilité qu’un utilisateur non authentifié peut exploiter ou qu’une personne qui ne dispose que des autorisations d’abonné peut exploiter sera beaucoup plus fréquemment attaquée que celle où seul un éditeur ou une personne disposant d’autorisations de publication peut la supprimer.

Ils nécessitent généralement une interaction utilisateur minimale. L’ingénierie sociale demande des efforts, pas toujours beaucoup, mais cela demande des efforts. S’il s’agit d’une attaque qui se produit lorsque quelqu’un visite le site ou accède à une page spécifique du site qu’ils allaient visiter de toute façon, elle sera beaucoup plus fréquemment attaquée que tout ce qui oblige quelqu’un à cliquer sur un lien spécifique. Ils ont tendance à avoir un impact élevé ou une gravité élevée. La plupart des attaquants ne s’attaqueront pas à une vulnérabilité qui leur donne simplement des informations générales sur la configuration de votre serveur, à moins qu’ils ne vous ciblent spécifiquement. Dernière chose, et peut-être la plus importante, les attaques réussies ont tendance à être monétisables. Les pirates aiment gagner de l’argent. C’est pourquoi ils font tout cela.

Que font les attaquants lorsqu’ils entrent? Eh bien, généralement l’une des trois choses. Ils ont tendance à insérer du JavaScript malveillant, qui compte comme un script intersite stocké. Ils ont tendance à mettre à jour les options ou à télécharger une porte dérobée s’ils le peuvent. Passons à l’insertion de JavaScript malveillant. Habituellement, cela sera utilisé pour rediriger les visiteurs vers un site de publicité malveillante, ce qui est comme de la publicité, sauf qu’il vous emmène vers un jeu en ligne ou quelque chose de moins bénin. Nous voyons également du JavaScript malveillant utilisé pour gratter les informations de paiement. Quelqu’un a entendu parler de Magecart? Nous avons vu au moins une campagne dans laquelle le code JavaScript stocké malveillant a été utilisé pour insérer un utilisateur administrateur via AJAX. Il apparaîtrait en fait sur le panneau d’administration et lorsqu’un administrateur se connectait, il supprimait littéralement le nonce utilisé pour apporter des modifications. À ce stade, il s’agit essentiellement de scripts intersites stockés plus CSRF stockés, sauf qu’il n’est plus intersite non plus.

Nous voyons beaucoup d’attaques tentant de mettre à jour les options. La plupart du temps, ils modifient les valeurs d’URL de la maison ou du site pour rediriger les visiteurs et, encore une fois, vers des sites malvertis où ils peuvent gagner de l’argent. Les deux suivants vont généralement de pair et ils changent généralement «les utilisateurs peuvent s’inscrire» à 1 si les utilisateurs ne peuvent pas déjà s’inscrire. Ils changeront le rôle par défaut en administrateur. Par conséquent, la prochaine fois qu’ils créeront un utilisateur, ils seront administrateurs et ils seront propriétaires de votre site maintenant. Nous voyons également des vulnérabilités de mise à jour des options utilisées pour ajouter du JavaScript malveillant.

Encore une fois, la plupart du temps, cela se fait via des champs CSS personnalisés ou des champs d’ID utilisateur de médias sociaux, tout ce dont la sortie n’est pas filtrée. S’ils le peuvent, ils essaieront de télécharger une porte dérobée. L’une des grandes utilisations de ce type d’hébergement est le spam ou le contenu de phishing. Le spam SEO est une grande entreprise, créant des liens de retour sales et du phishing. Je veux dire, si vous pouvez obtenir les informations d’identification d’un compte en utilisant le phishing sur un site qui n’est pas encore sur liste noire, les gens ne recevront pas cet avertissement Google Chrome. Nous voyons essentiellement des portes dérobées utilisées pour ajouter des redirections malveillantes vers des sites malveillants. Vous verrez que cela se produit souvent. Nous verrons également cela utilisé pour gratter les informations de paiement via un code côté serveur au lieu de Javascript. Enfin et surtout, si quelqu’un a une porte dérobée sur votre site, il peut l’utiliser pour attaquer les sites d’autres personnes, ce qui n’est pas une bonne idée.

Qu’est-ce qui pourrait mal se passer? Eh bien, c’est surtout un contrôle d’accès cassé. Je devrais dire que l’une des choses numéro un que nous voyons réellement brisées est de ne pas ajouter le contrôle d’accès aux paramètres ou la fonctionnalité d’importation et un contrôle d’accès suffisant. Habituellement, cela signifie utiliser une petite fonction appelée is_admin pour le contrôle d’accès, qui ne fait pas ce que cela ressemble. Nous voyons également des plugins utiliser une fonction appelée admin_init pour le contrôle d’accès, qui ne fait pas exactement ce que cela ressemble. Nous voyons également des crochets admin_action pour le contrôle d’accès, et ceux-ci ne font pas non plus ce qu’ils semblent faire. Enfin, nous voyons des plugins utilisant des hooks ajax_nopriv pour les fonctions administratives, et ceux-ci font exactement ce qu’ils sonnent comme ils le font. Ils permettent à un utilisateur non privilégié de prendre une action.

Nous voyons également que ne pas vérifier les nonces est beaucoup. Maintenant, ceux-ci sont généralement un peu moins critiques car, encore une fois, si un nonce est la seule chose qui vous gêne, alors, vous avez de plus gros problèmes, mais ne pas avoir un nonce entraînera une vulnérabilité CSRF et, alors que ceux doivent généralement être des attaques ciblées, elles sont toujours problématiques. Et enfin et surtout, mettre les nonces à la disposition des utilisateurs non autorisés. C’est en fait pire car cela ne nécessite pas d’ingénierie sociale ou quelque chose comme ça. Si quelqu’un peut se connecter en tant qu’abonné et voir le nonce qui, selon vous, se situe entre lui et une fonction administrative, il pourra alors faire cette fonction administrative.

J’ai donc apporté quelques détails et exemples aujourd’hui. Commençons donc avec is_admin. Désormais, il vérifie uniquement si une page administrative tente d’être affichée. Il ne vérifie pas si vous êtes administrateur. Un abonné connecté passera donc cette vérification et une demande non authentifiée à admin-ajax.php ou admin-post.php passera également cette vérification. Et l’exemple que j’ai choisi pour cela est le plugin Social Warfare. Il a utilisé la fonction is_admin pour protéger une fonction de débogage et de migration des paramètres. Il pourrait s’agir d’un document de configuration spécialement conçu. Vous pouvez simplement lui donner un getParameter à une URL que vous avez configurée à l’avance et y coller un script malveillant, ou y coller du code et il sera exécuté.

La plupart des attaques antérieures modifient donc l’identifiant Twitter, car il s’agit d’un plugin social, et elles n’ont pas non plus désinfecté la sortie de l’identifiant Twitter. Comme je l’ai dit, contrôle d’accès cassé et autres choses. Nous nous concentrons principalement sur le contrôle d’accès, car c’est l’erreur que vous voyez le plus souvent. Mais oui, la plupart des attaques [on Social Warfare] changé l’identifiant Twitter en un script malveillant et l’utiliser pour rediriger les visiteurs vers des sites malveillants, ou ils l’ont utilisé pour ajouter une porte dérobée. Pas l’identifiant Twitter, ils ont juste mis du code PHP qui a saisi un autre fichier et l’a écrit sur le serveur. Il manquait également une vérification de nonce, non pas que cela aurait été suffisant, mais cela aurait aidé.

Et la bonne nouvelle est que le développeur de ce plugin a agi très rapidement pour résoudre ce problème. Je pense que c’était dans un jour ou deux. L’une des grandes leçons à en tirer est que si vous avez un problème, c’est la façon dont vous y répondez qui est le plus important. Je coupe. Et voilà. J’ai apporté des captures d’écran de code. Si vous regardez vers le haut, il y a une fonction is_admin, et regardez, ils essaient de l’utiliser pour empêcher les gens d’entrer. Et cela ne fonctionne clairement pas. Et vous remarquerez à quel point la prochaine chose est, il essaie d’attribuer file_get_contents de l’URL qu’il vous donne, ou vous y passez, et le met dans le tableau d’options. Ensuite, il n’est pas évalué sur cette baie. Mais s’ils décident de ne pas opter pour la vulnérabilité d’exécution de code à distance, il mettra alors à jour les options de paramètres de Social Warfare. Vous voyez, nous avons obtenu une vulnérabilité de mise à jour d’options et de code à distance. Et cela peut sembler un peu limité, à l’exception du fait que, encore une fois, l’ID utilisateur Twitter n’a pas été filtré, donc cross-scripting.

La prochaine fonction moins sûre que nous allons couvrir est admin_init, et elle s’exécute lorsqu’un écran ou script administratif est initialisé. Un abonné connecté réussira cette vérification, et une demande non authentifiée à admin-post.php ou admin-ajax.php passera également cette vérification, tout comme la dernière fonction. La principale différence est que celui-ci est censé ne s’exécuter ou passer que lorsque vous essayez de charger un écran d’administration. Celui-ci exécute réellement des choses lorsque vous essayez de charger dans l’écran d’administration. La vulnérabilité Easy WP SMTP est celle que nous allons couvrir pour cela. Il utilisait admin_init pour protéger une fonction d’importation de paramètres qui permettait de mettre à jour des options arbitraires. Certaines attaques ont mis à jour l’URL de la maison ou du site vers un site malvertisant. D’autres ont modifié users_can_register à 1 et mis à jour le rôle par défaut administrateur, et les utilisateurs ont fini par trouver des administrateurs voyous sur leurs sites.

Encore une fois, le développeur du plugin a publié un patch très rapidement. Je pense que c’était à nouveau dans quelques jours. Bravo à eux. Et voici quelques captures d’écran. J’ai sauté un peu dans le code, mais voyez comment ils ajoutent une action sur admin_init, et ils nomment littéralement la fonction qu’ils exécutent sur admin_init, «admin_init». Ce qui est très créatif. Quoi qu’il en soit. Il suffit de lui passer quelque chose dans le tableau des fichiers et il désérialise tout ce qui se trouve dans ce fichier, ce qui pourrait également être une vulnérabilité d’injection d’objets, selon ce qui est installé. Mais ceux-ci sont assez rares de nos jours. Eh bien, assez rarement exploitable de nos jours, je dois dire. Mais si cela n’est pas exploitable, il suffit de mettre à jour les options de votre site avec tout ce qui se trouvait dans les données sérialisées du fichier que vous avez transmis.

Ensuite, nous allons couvrir les hooks admin_action. Maintenant, ceux-ci sont enregistrés sur la plupart des pages de l’interface d’administration. Ils peuvent à nouveau être déclenchés par les abonnés. La vulnérabilité Duplicate Page est celle que nous allons couvrir pour cela. J’ai utilisé un hook admin_action pour déclencher une fonctionnalité de publication en double, ce qui a entraîné une vulnérabilité d’injection SQL. Vous le verrez probablement, espérons-le, dès qu’il sera mis en évidence. Et l’auteur du plugin a répondu assez rapidement. Il leur a fallu environ une semaine pour sortir une version mise à jour. Il y avait quelques problèmes, mais ils ont quand même réussi à s’en occuper et ont eu une réponse décente.

J’ai souligné que admin_action_dt_duplicate_post_as_draft, et une fois cette action exécutée, il prend tout ce que vous mettez dans le getParameter, le getParameter appelé post, oui, c’est déroutant, et l’assigne à la variable ID du post. Et puis, si vous regardez tout en bas, cela fait littéralement une requête SQL avec tout ce que vous venez de l’alimenter à partir de ce getParameter, et cela peut conduire à une injection SQL. Maintenant, la bonne chose à propos de l’injection SQL moderne est la plupart du temps que vous ne pouvez pas l’utiliser pour changer les choses dans une base de données, au moins la façon dont WordPress est configuré, mais cela peut toujours conduire à une exfiltration de données.

Je ne sais pas vraiment pourquoi ils utilisent celui-ci pour beaucoup. Je pensais juste que c’était un bon exemple. Maintenant, c’était en fait l’un de mes préférés, ou le moins préféré, car il devient en fait un peu moins courant. Mais quand cela arrive, c’est généralement très mauvais. Cela utilise des crochets ajax_nopriv. Cela ne veut pas dire que vous ne devriez pas les utiliser, mais ne les utilisez pas pour tout ce qui devrait nécessiter des privilèges, car un utilisateur non authentifié peut utiliser l’action enregistrée. L’ajout de vérifications de capacité et d’une protection nonce les rend plus sûres. Si vous voulez avoir une fonction AJAX pour les gouverner toutes, vous pouvez toujours le faire et utiliser des crochets AJAX et des crochets ajax_nopriv réguliers, et faites simplement vérifier vos capacités si vous voulez faire quelque chose d’administration. Mais il est probablement plus sûr de le diviser. Oui, vous ne devriez probablement les utiliser que pour les actions que vous souhaitez rendre accessibles au public.

L’exemple ici est le plugin Total Donations. Il a utilisé un hook ajax_nopriv non protégé, ce qui a permis des mises à jour d’options arbitraires. Ainsi, certaines attaques ont ajouté du JavaScript malveillant via une option CSS personnalisée, d’autres attaques, une fois de plus, ont changé users_can_register à 1 et changé le rôle par défaut en administrateur. Nous voyons toujours des gens essayer d’attaquer cela même si… Eh bien, des spoilers. Pire encore, le plugin avait un point de terminaison AJAX alternatif qui signifiait qu’il était vulnérable même s’il était désactivé. Vous avez dû supprimer complètement ce plugin afin de le rendre non vulnérable.

Pire que tout, et c’est de cela que je parlais, les spoilers, le développeur du plugin n’a pas répondu quand les gens ont essayé de les avertir. CodeCanyon, Envato, a eu une merveilleuse réponse. Ils l’ont supprimé dès qu’il a été clairement indiqué que le développeur ne le corrigerait pas. Au moins, quelqu’un n’a pas laissé tomber le ballon. Si vous regardez cela, il ajoute une add_action à miglaA_update_me (), et il saisit simplement tout ce qui se trouve dans le POST[‘key’] et POST[‘value’] paramètres et met à jour ces options à tout ce que vous voulez, ce qui est assez terrifiant. Pas de chèques, pas de soldes, juste, “Oh oui, je vais mettre à jour toutes vos options.”

Les deux exemples suivants que je vais couvrir sont … Eh bien, je ne dirais pas que celui-ci n’est pas aussi grave. Nonce disponible pour les utilisateurs non autorisés. Parce que celui-ci pourrait en fait être assez grave et nous avons encore vu des attaques pour cela. Fondamentalement, le problème est qu’il rend les vérifications de nonce non pertinentes si quelqu’un peut saisir votre nonce. Il ne nécessite pas d’ingénierie sociale, il suffit d’accéder à un emplacement où le nonce est affiché. Maintenant, c’est généralement une zone accessible aux abonnés, donc elle sera un peu moins attaquée que quelque chose qui ne nécessite pas d’authentification du tout, mais il y a une tonne de sites qui autorisent l’enregistrement ouvert. Cela aurait été un problème sur ces sites. La bonne nouvelle pour ceux-ci est que les contrôles d’accès fonctionnent toujours. Ce n’est pas non plus disponible, mais ils n’ont pas non plus vérifié si la personne qui entreprenait l’action était un administrateur.

L’exemple que j’utilise pour cela est le plugin Ad Inserter. Les attaquants pourraient utiliser la fonctionnalité de prévisualisation des annonces pour exécuter du code arbitraire. Un attaquant pourrait en principe définir un cookie pour une certaine valeur, et une fois qu’il a défini ce cookie, il pourrait obtenir un nonce qui lui permettrait de prévisualiser le code sur la page d’accueil s’il était connecté en tant qu’abonné. Ils ont utilisé un check_admin_referer pour vérifier le nonce, ce qui est bien si vous ne faites que vous protéger contre CSRF. Il n’est pas suffisant d’effectuer réellement le contrôle d’accès. La bonne nouvelle est que le développeur du plugin a publié un patch le lendemain, donc une excellente réponse de sa part. C’était en fait l’un des membres de notre équipe qui a découvert celui-ci. Voici juste une capture d’écran de, hé, il y a le nonce qui vient de refroidir le code source de la page d’accueil après avoir défini ce cookie.

D’accord, c’est un écran assez occupé, et il se passe beaucoup de choses ici. Mais en gros, il fait un check_admin_referer, saisit l’aperçu du post, l’envoie à une fonction appelée générer l’aperçu du code. Après avoir sauté un tas d’étapes, cela évoque tout ce que vous mettez dans le POST[‘code’] paramètre.

Enfin, et probablement le moins fréquemment attaqué mais toujours important si vous développez des plugins et que vous souhaitez suivre les meilleures pratiques, ne pas vérifier les nonces est une mauvaise idée. Ils sont beaucoup moins fréquemment attaqués. Ils nécessitent généralement une ingénierie sociale, mais les attaques CSRF POST, vous pouvez essentiellement envoyer à quelqu’un un lien vers un site que vous contrôlez, et il aura un formulaire qui se soumet automatiquement si vous souhaitez envoyer une demande de publication au lieu, disons, OBTENEZ une demande sur leur site. Comme je l’ai dit, les nonces couvrent la plupart des fonctionnalités vraiment importantes de WordPress de base ces jours-ci, ou un ensemble, je devrais dire, très probablement, mais si votre plugin fait quelque chose d’intéressant, alors vous devriez toujours les avoir. Ne pas vérifier les nonces autorisera les attaques CSRF, même si vous avez d’autres contrôles d’accès en place, donc même si vous vérifiez réellement que quelqu’un a les autorisations pour faire quelque chose. Il permet essentiellement à l’attaquant d’utiliser la fonction non protégée en tant qu’utilisateur ciblé. C’est plus difficile à exploiter, mais si vous pouvez l’exploiter, cela peut devenir très mauvais.

Le pire, c’est que les pare-feu n’offrent aucune protection contre le CSRF. Ils peuvent offrir une protection contre certaines charges utiles, comme si vous essayez d’inciter quelqu’un via CSRF à insérer du code JavaScript malveillant sur son propre site, un pare-feu pourrait l’attraper. Mais si vous essayez de les inciter à créer un nouvel utilisateur administrateur et que votre plugin leur permet de le faire, ce ne sera probablement pas le cas.

L’exemple que j’ai ici est le plugin WP Maintenance. Je pense que Chloé a découvert cela. Salut Chloé. Fondamentalement, le plugin n’a pas réussi à vérifier le nonce pour mettre à jour ses propres paramètres, et les attaquants pourraient ajouter un script malveillant aux titres des newsletters. Si pour une raison quelconque, il avait une fonctionnalité de newsletter, chaque fois qu’il envoyait une newsletter, vous pouviez essentiellement envoyer un JavaScript malveillant avec cette newsletter. Ou chaque fois qu’un administrateur vérifiait ses newsletters, il le ferait… le script s’exécuterait.

Les attaquants pouvaient également activer le mode de maintenance, ce qui signifiait qu’ils pouvaient, temporairement au moins, supprimer votre site. La bonne nouvelle est que le développeur du plugin a publié un patch en une journée. Encore une fois, une excellente réponse. La plupart des réponses que nous voyons sont en fait assez bonnes. Les développeurs de plugins s’en sortent beaucoup mieux qu’ils ne l’ont peut-être été par le passé.

Capture d’écran du code, je n’ai rien mis en évidence, car cela montre simplement qu’ils peuvent mettre à jour les options pour cela. Cette page entière est cachée derrière, enfin, des contrôles d’accès au menu administrateur WordPress plus typiques, tout comme lorsque vous vous connectez … en tant qu’abonné, vous ne pouvez pas voir la page du menu administrateur pour les plugins. Ceci est l’une de ces pages.

La question devient: “Que dois-je faire à la place?” C’est assez simple. Si vous allez vérifier le contrôle d’accès, utilisez current_user_can. Il permet un contrôle plus fin si vous ne souhaitez autoriser l’accès qu’aux personnes qui peuvent dire, publier des articles ou modifier les paramètres du plugin, vous pouvez également le définir. Vous pouvez également utiliser is_super_admin ou is_network_admin si vous prévoyez que votre plugin s’exécute correctement sur une installation multisite qui peut entraîner des complications, où seuls les administrateurs réseau ou super peuvent faire la chose et vous voudrez peut-être que les administrateurs locaux le fassent.

Utilisez wp_create_nonce et wp_verify_nonce pour le protéger contre CSRF. Ce n’est pas un substitut au contrôle d’accès, mais il peut quand même aider. Il vaut mieux avoir un nonce en place qu’autrement, et ajouter plus de friction à une attaque est toujours une bonne chose. Ils préfèrent toujours les fruits bas, comme on dit. Faites attention aux pages qui affichent votre nonce car les nonces peuvent être grattés ou autrement compromis. En outre, check_admin_refer fonctionne également pour vérifier les nonces. Je sais que nous avons en fait couvert une vulnérabilité où c’est ce qu’ils ont fait, mais ne faites pas que ce soit la seule chose que vous fassiez pour vérifier le contrôle d’accès.

Enfin, sachez qui peut accéder à quoi. Ce n’est pas parce qu’une fonctionnalité n’est pas exposée dans l’interface utilisateur qu’elle n’est pas accessible. Je suppose que c’est l’une de ces véritables leçons fondamentales, car c’est pourquoi il s’agit toujours d’importations de paramètres, de trucs comme ça, de mises à jour des options. C’est ce qui peut être ajouté en tant que fonctionnalité supplémentaire, et peut-être même pas complètement développé, mais ils ont la fonctionnalité en place. Envoyez-lui simplement les bons paramètres et quelqu’un peut modifier vos paramètres. Ajoutez des contrôles d’accès à tout ce qui modifie les paramètres ou les options.

Enfin, considérez tout ce qu’un utilisateur peut changer comme entrée utilisateur, car j’ai vu toutes sortes de choses étranges utilisées comme entrée utilisateur. Les scripts intersites via les en-têtes de référents HTTP sont une chose.

Oui?

Question du public:
Cela fonctionne-t-il avec les booléens?

Ram Gall:
Avec quoi?

Question du public:
Est-ce que cela s’applique également aux booléens?

Ram Gall:
Des booléens? Il vous demande si cela s’applique aux booléens. Habituellement, la conversion de quelque chose en booléen ou en entier fournit une certaine défense, mais j’ai vu au moins une vulnérabilité de mise à jour des options où elle vous permettait de mettre à jour la clé d’option à votre guise, mais cela ne vous permettait que de mettre à jour la valeur de l’option en une valeur booléenne. Cela signifie que vous pouvez mettre à jour l’URL de la maison ou du site sur false et que le site de quelqu’un sera également supprimé. Cela peut limiter la quantité de dégâts que quelqu’un peut faire. Encore une fois, la conversion en un entier ou booléen aidera à limiter la quantité de dommages que quelqu’un peut faire avec, par exemple, une injection SQL, mais il existe des techniques comme l’injection SQL aveugle qui peuvent parfois surmonter cela.

Ram Gall:
Je vais juste laisser ce diaporama pour rester en contact. Voici mes coordonnées et maintenant, je répondrai à plus de questions si quelqu’un en a. D’accord.

Question du public:
D’accord. Donc, la plupart de ces attaques, si je comprends bien, proviennent de personnes grattant les référentiels GitHub et des trucs comme ça. Si vous avez votre code dans un référentiel privé, combien de protection cela vous donnera-t-il?

Ram Gall:
Donc, la question était que la plupart de ces attaques semblaient provenir de personnes grattant les référentiels GitHub et si le fait d’avoir du code dans un référentiel privé vous protégerait ou non? La réponse est que si le code de votre plugin n’est pas dans un référentiel ouvert… Ai-je raison de demander cela? Eh bien, le seul moyen de vraiment protéger le code du plugin PHP comme celui-ci est l’obfuscation. La vérité est que tout ce qui peut être obscurci peut être désobscurci. Même si vous n’avez pas votre plugin sur GitHub, si vous le publiez et que les gens l’utilisent, quelqu’un peut le désosser ou peut simplement tomber sur une vulnérabilité par accident. De nombreux attaquants découvrent des vulnérabilités par le biais essentiellement de tests de boîte noire. Ils ne savent même pas à quoi ressemble le code du plugin, ils lancent simplement Burp Suite et testent par lots un tas de contournements de script intersites communs sur tous les paramètres qu’ils peuvent trouver.

Ram Gall:
Oui?

Question du public:
Pouvez-vous être clair? Votre conviction concernant les nonces est d’essayer de ne pas les rendre disponibles, mais si nous avons un forum public, il y aura un nonce sur les forums publics. Il doit être en plus de vous… tant que cela est utilisé avec un accès public ou un contrôle d’accès approprié? Ai-je raison?

Ram Gall:
La question est de savoir si les nonces sur les forums publics doivent être utilisés pour un contrôle d’accès approprié?

Ram Gall:
J’ai l’impression que c’est là que j’ai fait un peu court dans ma description, car vous n’utilisez pas un nonce singulier pour tout. De plus, pour chaque type d’action que vous souhaitez entreprendre, vous devez disposer d’un nonce distinct. Ce forum accessible au public aura un nonce juste pour empêcher quelqu’un d’autre de soumettre le formulaire comme eux, alors que … et vous voudrez rendre ce nonce disponible uniquement sur le site Web principal. Alors qu’un formulaire que seul un administrateur devrait pouvoir voir pour effectuer des modifications de plugin aura également un nonce qui est un nonce très différent qui ne doit être affiché que sur cette page à laquelle un administrateur peut accéder.

Ram Gall:
Oui?

Question du public:
J’ai un plugin qui ne fait rien sur le front-end et ça … mais votre dernier point sur la contribution des utilisateurs me fait réfléchir. Il vérifie simplement certaines conditions et envoie une alerte par e-mail si cette condition se produit, mais il existe une zone de saisie où l’utilisateur peut insérer son propre e-mail. Il ne fait rien sur les paramètres WordPress standard, il ne fait rien sur le front-end, mais cela pourrait-il être utilisé d’une manière ou d’une autre…

Ram Gall:
La question est, si vous avez un e-mail, si je ne me trompe pas, un plug-in de messagerie qui n’a pas d’interface utilisateur, il ne sera qu’administratif, mais tout ce qu’il fait est essentiellement de vérifier les informations de configuration et d’envoyer des e-mails. Eh bien, si vous n’avez pas de contrôle d’accès, un attaquant pourrait envoyer les informations pour récupérer les informations de configuration de votre site et envoyer un e-mail de la configuration de votre site à lui-même, et cela dépend de la sensibilité de ces informations de configuration. Comme je l’ai dit, les attaques par capture de configuration ne sont pas aussi courantes, mais si quelqu’un cible spécifiquement votre site, vous ne voulez vraiment pas qu’il dispose de ces informations. En outre, ils pourraient potentiellement utiliser la même fonctionnalité pour envoyer un tas d’e-mails aux personnes qui n’en veulent pas et obtenir l’IP de votre site sur une liste noire d’e-mails.

Question du public:
D’accord merci.

Ram Gall:
D’autres questions? Oh oui?

Question du public:
Je l’ai demandé lors de plusieurs discussions sur la sécurité. Même si je crois que je respecte les meilleures pratiques, je me suis demandé s’il existe une sorte de tierce partie qui pourrait lire mon code et me donner des commentaires. En connaissez-vous?

Ram Gall:
Il demande si… désolé?

Question du public:
Oui, la rétroaction sur la sécurité est la chose principale.

Ram Gall:
Il demande s’il existe un tiers qui examinera votre code et vous fournira des commentaires sur la sécurité. D’après ce que je comprends, il existe un certain nombre de consultants qui offrent ce type de service. Certains utilisent l’automatisation, d’autres font une revue manuelle. Je ne peux cependant pas vous donner de recommandations particulières. Nous essayons de rechercher les vulnérabilités dans les plugins open source courants, mais c’est quelque chose que vous pouvez avoir fait, oui.

Question du public:
Mais pas de recommandations?

Ram Gall:
Aucune recommandation pour le moment.

Question du public:
Chaque fois que je reçois des recommandations, c’est l’automatisation, et ce n’est pas ce que je veux.

Ram Gall:
Ouais. I mean, if you are going to have that, at least half the time, a vulnerability might not be obvious just from reading the code, which is, again, another reason why just having your plugin open source, which is a great thing, isn’t necessarily going to make it more or less vulnerable than having closed-source plugins.

Ram Gall:
I think we may be done. Last call?

[Applause.]

Kathy Zant:
We hope you enjoyed Ram’s talk and that you learned something about secure plugin development. If you’d like to get in touch with Ram, you can follow him on Twitter @RamuelGall. We’ll have a link to his Twitter profile in the show notes. And we will talk to you next time on Think Like a Hacker. Thanks for listening.



Source link