Les serveurs de développement de Google pouvaient être amenés à exécuter du code sans que l’attaquant se connecte.
Le chercheur en sécurité Simon Köck a découvert une vulnérabilité dans la plate-forme DevSite de Google qui exposait un secret d’authentification et permettait aux attaquants de falsifier des sessions de confiance. Combinée à un traitement dangereux des données, cette faille pouvait permettre l’exécution de code à distance sur le serveur.
Google a depuis corrigé le problème et a récompensé Köck de 90 000 $ pour sa découverte. Cette affaire montre comment deux failles de sécurité peuvent se combiner et transformer un identifiant exposé en compromission bien plus grave.
Un cookie transportait la clé utilisée pour le vérifier
En examinant le processus de connexion OAuth sur developers.google.com, Köck a remarqué un cookie de session Flask d’environ 1 200 octets. Les visiteurs le recevaient avant d’être redirigés vers la page de connexion de Google.
Selon Köck, le cookie décodé contenait un identifiant client OAuth et un secret client. Dans l’implémentation de DevSite, le secret exposé pouvait également servir à signer des cookies de session Flask, permettant à un attaquant de créer des cookies que l’application accepterait comme valides.
Une autre faille existait dans le rappel OAuth. Celui-ci utilisait pickle.loads() de Python pour reconstruire un objet stocké dans la session, un processus capable d’exécuter des instructions contrôlées par l’attaquant via une désérialisation non sécurisée. Les cookies falsifiés pouvaient donc transmettre des instructions malveillantes à la fonction.
Pour tester la vulnérabilité sans exécuter de commandes du système d’exploitation, le chercheur a préparé des charges utiles time.sleep(). Les réponses du serveur ont été retardées d’environ trois, cinq et huit secondes, conformément aux délais demandés. Les cookies dont les signatures avaient été modifiées ont été rejetés, ce qui étayait sa conclusion : le serveur avait bien exécuté les fonctions de test.
Quatre autres sites de développement ont accepté des sessions falsifiées
Des tests supplémentaires ont montré que la clé récupérée fonctionnait sur quatre autres propriétés. Des sessions valides ont été acceptées sur firebase.google.com, developer.android.com, source.android.com et docs.partner.android.com. Köck n’a pas documenté de tests d’exécution de code distincts pour chacun de ces hôtes.
Google a récompensé Köck de 90 000 $ après avoir classé la vulnérabilité comme un problème S0 d’exécution de code à distance. Les ingénieurs de DevSite ont terminé le correctif le 7 octobre, avant sa divulgation publique.
Köck a indiqué que le secret client OAuth exposé était toujours actif lorsqu’il a préparé sa divulgation, bien qu’il en ait gardé la valeur confidentielle.
Google n’a pas détaillé publiquement les mesures correctives décrites dans son récit. Il n’est donc pas certain que le correctif ait consisté à modifier la gestion des sessions, à supprimer la désérialisation non sécurisée ou à prendre d’autres mesures. Le statut rapporté de l’identifiant ne permet pas d’établir que l’attaque initiale restait exploitable.
Les équipes de sécurité devraient revoir leur gestion des sessions
La vulnérabilité était spécifique à l’implémentation de DevSite de Google, mais elle met en évidence des risques de sécurité qui peuvent toucher d’autres applications web.
Les développeurs devraient vérifier comment leurs applications stockent les données de session et traitent les informations reçues des navigateurs. Les cookies signés peuvent empêcher toute modification non autorisée, mais ils ne chiffrent pas nécessairement leur contenu et ne rendent pas sûre une désérialisation dangereuse.
Les équipes de sécurité devraient donner la priorité à plusieurs vérifications :
- Inspecter les cookies de session à la recherche d’identifiants exposés. Vérifiez quelles informations vos applications rendent accessibles aux navigateurs et supprimez les secrets intégrés. Intégrez ces vérifications à vos revues régulières de la sécurité des applications, en particulier pour les services exposés à Internet.
- Rechercher les traitements dangereux des données. Examinez le code qui reconstruit des objets à partir d’informations susceptibles d’être contrôlées par les utilisateurs, notamment les fonctions telles que pickle.loads(). Remplacez les chemins de désérialisation risqués par des formats de données validés ou des enregistrements côté serveur.
- Examiner les identifiants d’authentification partagés. Identifiez les sites web qui réutilisent des clés de signature ou d’autres identifiants sensibles pour la sécurité. Utilisez des clés distinctes lorsque c’est nécessaire et établissez des procédures pour faire tourner les secrets exposés et invalider les sessions concernées.
- Tester les points de terminaison exposés et limiter les privilèges de l’application. Incluez les requêtes effectuées avant la connexion dans vos tests de sécurité des applications web, parallèlement aux revues de code. Limitez les autorisations accordées aux processus applicatifs afin de réduire leur accès potentiel aux informations commerciales sensibles ou aux systèmes connectés.
L’affaire DevSite montre comment des faiblesses qui semblent gérables lorsqu’elles sont prises isolément peuvent devenir bien plus dangereuses lorsqu’elles se combinent. Pour les développeurs, sécuriser l’authentification ne consiste pas seulement à protéger le processus de connexion, mais aussi les données auxquelles les applications font confiance une fois la session établie.
Plus d’actualités sur la cybersécurité : les clients de SonicWall ont disposé d’un délai réduit pour appliquer le correctif après que des attaquants ont commencé à exploiter une faille critique dans les 48 heures suivant sa divulgation.