Google a versé une prime de 90 000 dollars au chercheur en sécurité Simon Köck après la découverte d’une vulnérabilité non documentée d’exécution de commandes à distance dans DevSite, la plateforme commune qui prend en charge developers.google.com et d’autres sites de documentation. Köck a signalé le problème le 6 août, Google a accepté le rapport le lendemain et a approuvé la prime le 27 août, mais le correctif n’a été déployé sur les serveurs que le 7 octobre.
Google a classé la vulnérabilité au niveau S0, le niveau le plus élevé de son échelle de gravité, et a accordé à Köck un montant de base de 75 000 dollars pour une vulnérabilité RCE dans la couche applicative classique, avec une majoration de 20 % en raison de la qualité exceptionnelle du rapport.
Trois erreurs ont formé la chaîne d’exploitation
DevSite stockait un objet OAuth2WebServerFlow sérialisé de la bibliothèque obsolète oauth2client dans un cookie de session Flask. Cela a exposé un secret client OAuth, mais le problème est devenu plus grave parce que ce même secret était également utilisé comme clé de signature des sessions Flask.
Köck a pu reproduire localement la signature des cookies et créer des sessions falsifiées acceptées par le serveur. Comme le flux OAuth utilisait pickle pour désérialiser les données de session, il a pu remplacer l’objet par une charge utile pickle malveillante signée, puis démontrer l’exécution de code Python à distance.
Le chercheur a confirmé l’exécution au moyen d’une charge utile qui retardait la réponse à l’aide de la commande sleep, en s’arrêtant délibérément avant l’exécution de commandes réelles ou l’accès aux fichiers, aux identifiants ou aux services internes. Selon son récit, les sessions falsifiées étaient acceptées sur les sept domaines concernés, tandis que le test de preuve de concept a été effectué sur trois domaines : developers.google.com, docs.partner.android.com et web.dev.
L’étendue de l’impact n’a pas été entièrement déterminée
Köck n’a pas établi si le serveur pouvait modifier le contenu de la documentation de Google ou remplacer les commandes d’installation et les liens de téléchargement, un scénario qui aurait pu ouvrir la voie à une attaque contre la chaîne d’approvisionnement logicielle. Il n’a pas non plus testé si les sessions falsifiées permettaient d’usurper l’identité d’utilisateurs ou d’accéder à leurs données.
Le chercheur Arvin Shivram, connu sous le nom de @brutecat, a indiqué que les applications internes App Engine pouvaient généralement accéder à Stubby, le système interne de Google destiné à la communication entre services. Köck a déclaré que cet accès, s’il était disponible pour ce processus, pourrait considérablement élargir l’impact, mais il n’a pas vérifié les autorisations de DevSite ni l’étendue de son accès aux services backend.
Pourquoi cette information est-elle importante ?
Ce cas montre que le risque ne résultait pas d’une seule erreur, mais de la combinaison de trois pratiques : l’exposition d’un secret sensible dans un cookie, sa réutilisation comme clé de signature et l’utilisation d’une désérialisation non sécurisée de données non fiables. Corriger n’importe quel maillon de cette chaîne aurait suffi à interrompre le chemin d’exploitation, ce qui fait de la séparation des secrets et du rejet de pickle pour les données de session des contrôles essentiels, et non des améliorations facultatives.
En revanche, le délai de correction, qui s’est étendu sur environ deux mois, soulève des questions opérationnelles auxquelles Google n’a pas répondu. L’entreprise n’a pas précisé si elle avait mis en place des mesures d’atténuation temporaires, changé les deux clés de signature distinctes que, selon Köck, les sept domaines utilisaient, ou invalidé les sessions existantes. Elle n’a pas non plus révélé le résultat d’une analyse forensique concernant une éventuelle exploitation de la vulnérabilité avant la publication du correctif, et n’avait pas répondu à la demande de commentaire de The New Stack au moment de la mise à jour de l’article.