En date du 26 juin 2015, je découvre le plugin WP Rollback. Ce plugin permet d’installer une version antérieure d’un de vos plugins provenant du dépôt officiel.
Comme j’ai eu envie d’utiliser ce plugin, je me devais d’abord de vérifier sa sécurité. Rappelons que si je ne fais pas ça, alors je ne dois pas oublier qu’installer un plugin reviens à inclure du code PHP provenant d’une personne que je ne connais pas, sans vérifier son code, impossible pour moi.
XSS
J’ai rapidement trouvé une faille de type XSS qui me permettait d’afficher n’importe quel contenu non filtré depuis une simple URL à cliquer, très facile alors d’y inclure un fichier javascript distant malicieux et de faire cliquer un administrateur.
[pastacode lang=”php” message=”XSS : Code vulnérable” highlight=”” provider=”manual”]
$args = wp_parse_args( $_GET, $defaults );
?>
‘ . ( $theme_rollback == true ? ‘theme’ : ‘plugin’ ) . ‘‘, ‘‘ . $args[‘current_version’] . ‘‘, ‘‘ . $args[‘rollback_name’] . ‘‘ ) ); ?>
[/pastacode]
Aucun argument n’a été désinfecté ni échapé, on affiche alors tout le contenu de ce qui est passé via l’URL en paramètre $_GET
.
Cette vulnérabilité XSS a un score DREAD de 4.4/10, critique.
CSRF
Viens ensuite pour moi l’idée de tester si je peux forcer un admin à mettre à jour un plugin en 1.0. Et malheureusement oui on peut car il n’y a aucun jeton de sécurité (nonce) sur le lien qui installe le plugin.
Pire encore, il est même possible de forcer l’installation d’un nouveau plugin provenant du dépôt, avec n’importe quelle version.
[pastacode lang=”php” message=”CSRF : Code vulnérable” highlight=”” provider=”manual” manual=”%24url%20%20%20%20%20%3D%20’index.php%3Fpage%3Dwp-rollback%26plugin_file%3D’%20.%20%24args%5B’plugin_file’%5D%20.%20’action%3Dupgrade-plugin’%3Bphp”/]
Cette vulnérabilité XSS a un score DREAD de 4.4/10, critique.
Mea culpa
Les développeurs on réagit très rapidement et le patch est déjà sorti, il vous faut la version 1.2.3 minimum pour ne pas être touché.