RCE sur Google DevSite : comment un secret divulgué a permis l'exécution de code à distance

Le chercheur en sécurité Simon Koeck a découvert une vulnérabilité critique d'exécution de code à distance (RCE) sur la plateforme partagée DevSite de Google en août 2026. Ce défaut permettait à un attaquant d'exécuter du code arbitraire sur les serveurs hébergeant la documentation développeur de services comme Firebase et Android, en exploitant un cookie de session Flask mal configuré. Google a récompensé Koeck avec 90 000 $ pour son rapport après avoir confirmé que le problème affectait plusieurs sous-domaines de premier plan.

Que s'est-il passé ?

Koeck cartographiait le flux d'authentification OAuth utilisé sur les sites de documentation développeur de Google, y compris developers.google.com. Il a remarqué que le cookie de session Flask émis lors de l'échange OAuth était anormalement volumineux, environ 1 200 octets. Comme les cookies Flask sont signés mais non chiffrés, il a décodé la charge utile pour inspecter son contenu. Il y a trouvé un objet sérialisé via pickle contenant une instance oauth2client.client.OAuth2WebServerFlow. Crucialement, cet objet contenait le client_id et le client_secret de Google OAuth en clair.

La présence du secret client dans un cookie côté client constituait déjà une faille de sécurité majeure. Cependant, Koeck a réalisé que les implications allaient plus loin lorsqu'il a testé si ce secret était également utilisé comme SECRET_KEY Flask pour signer le cookie lui-même. En dérivant la clé de signature à partir du secret client exposé en utilisant la logique standard de la bibliothèque itsdangerous de Flask, il a réussi à reproduire la signature du cookie hors ligne. Cela signifiait que le serveur utilisait un secret stocké à l'intérieur même des données qu'il tentait de protéger pour vérifier l'intégrité de ces données.

Avec la capacité de forger des signatures de session valides, Koeck pouvait contourner les contrôles de sécurité prévus. La logique de l'application récupérait l'objet de flux OAuth depuis la session et le désérialisait en utilisant pickle.loads(). Parce que le module pickle de Python peut exécuter du code arbitraire lors de la désérialisation s'il rencontre certains opcodes, et parce que Koeck pouvait désormais créer des cookies correctement signés, il avait atteint une exécution de code à distance sans authentification. Il l'a démontré en injectant des charges utiles qui forçaient le serveur à dormir pendant des durées spécifiques, prouvant que le code s'exécutait sur le backend sans accéder aux données sensibles de production.

Comment cela fonctionne

La vulnérabilité reposait sur une chaîne de trois mauvaises configurations spécifiques. Premièrement, l'application stockait des identifiants sensibles (le secret client OAuth) directement dans le cookie de session de l'utilisateur. Deuxièmement, elle utilisait ce même secret client comme clé cryptographique pour signer le cookie de session, créant une dépendance circulaire où la clé était publique pour quiconque inspectait le cookie. Troisièmement, l'application désérialisait des données contrôlées par l'utilisateur provenant du cookie en utilisant le module pickle de Python, qui est intrinsèquement dangereux pour les entrées non fiables car il permet l'instanciation d'objets et les appels de méthodes durant le processus de chargement.

Flask utilise la bibliothèque itsdangerous pour signer les cookies, dérivant généralement une clé de signature spécifique à partir du SECRET_KEY principal en utilisant HMAC-SHA1. Koeck a répliqué cette dérivation localement en utilisant le secret client divulgué. Une fois la correspondance de signature confirmée, il a fabriqué un nouveau cookie de session. Il a inséré une charge utile pickle malveillante sous la clé de session attendue, l'a signée avec la clé dérivée et l'a envoyée au serveur. Le serveur a vérifié la signature avec succès, a extrait le pickle et a exécuté les instructions intégrées, telles que l'appel à time.sleep().

Détails clés

• La vulnérabilité existait sur la plateforme partagée DevSite, affectant developers.google.com, firebase.google.com, developer.android.com, source.android.com et docs.partner.android.com.
• Le cookie de session Flask contenait un objet OAuth2WebServerFlow sérialisé via pickle avec le client_secret OAuth actif en clair.
• Le client_secret OAuth était utilisé comme SECRET_KEY Flask pour signer le cookie de session, permettant aux attaquants de forger des sessions valides.
• L'exécution de code à distance a été prouvée en utilisant des charges utiles time.sleep(N), où les temps de réponse du serveur correspondaient exactement à la durée de sommeil injectée.
• Google a classifié le problème comme RCE S0 (critique) et a accordé une prime de 90 000 $, calculée comme une base de 75 000 $ plus un multiplicateur de 1,2x pour la qualité du rapport.
• La correction impliquait la rotation des secrets, la séparation des clés de signature des identifiants OAuth, le stockage des objets de flux côté serveur et le remplacement de pickle par un format de données sûr.

Pourquoi c'est important

Cet incident met en évidence les dangers liés à l'utilisation de formats de sérialisation complexes comme pickle pour les données traversant les limites de confiance. Bien que pickle soit pratique pour préserver l'état des objets Python, il ne fournit aucun mécanisme pour restreindre quelles classes ou fonctions peuvent être invoquées lors de la désérialisation. Combiné à une clé de signature compromise, il devient un chemin direct vers l'exécution de code à distance. Les développeurs supposent souvent que les cookies signés sont inviolables, mais si la clé de signature est divulguée ou mal gérée, cette garantie disparaît entièrement.

Pour les équipes d'ingénierie, cela sert de rappel pour auditer la gestion et la rotation des secrets. Utiliser un identifiant à plusieurs fins—comme l'authentification API et la signature de session—augmente la surface d'attaque d'une seule fuite. Cela souligne également l'importance de conserver l'état sensible côté serveur. Les cookies ne doivent contenir que des références opaques ou des données minimales non sensibles, surtout lorsqu'il s'agit de flux d'authentification impliquant des fournisseurs tiers comme Google OAuth.

Ce que vous pouvez faire

• Auditez la gestion des sessions de votre application pour vous assurer que les clés de signature sont distinctes des autres identifiants tels que les secrets API ou les jetons OAuth.
• Remplacez pickle par un format de données sûr pour toute donnée traversant les limites de confiance.