Des failles de mise en œuvre dans les intégrations de Google Drive ont créé des vulnérabilités de falsification de requête côté serveur (SSRF) dans une variété d’applications, a révélé un chercheur en sécurité.

Cela incluait la plate-forme de signature numérique de Dropbox, HelloSign, mais « de loin le meilleur » SSRF a été réalisé via CRLF et demander la mise en pipeline dans une autre application sans nom, raconte le chasseur de primes de bogues Harsh Jaiswal dans un GitHub rédaction.

Prime HelloSign

Jaiswal a reçu une prime de 17 576 $ pour un SSRF « assez simple » mais essentiel lié à la fonction d’exportation Google Drive Docs de HelloSign.

« En utilisant un paramètre supplémentaire dans l’API Google Drive, il a été possible pour les chercheurs de forcer HelloSign à analyser les données JSON externes, ce qui conduit à une attaque SSRF », a déclaré l’équipe de sécurité de Dropbox dans un communiqué. fil de bogue sur Hacker One.

« Nous avons mis à jour l’analyseur pour effectuer en toute sécurité une requête qui atténue la vulnérabilité », ont-ils ajouté.

Contrôle de downloadUrl

Jaiswal a déclaré que les problèmes de mise en œuvre survenaient dans les intégrations qui récupéraient des fichiers de l’API Google Drive côté serveur.

Pour démontrer le concept, il a décrit un scénario dans lequel une application récupère et restitue un fichier image à partir de Google Drive d’une manière qui pourrait donner aux attaquants le contrôle de la requête HTTP adressée à googleapis.com via le id_fichier.

« Cela signifie que nous pouvons effectuer une traversée de chemin et ajouter des paramètres de requête », a expliqué le chercheur.

LIRE LA SUITE Un chercheur découvre un bogue SSRF dans le projet interne Google Cloud et remporte une prime de 10 000 $

Jaiswal a commencé la recherche en 2019 après avoir émis l’hypothèse qu’il pourrait être en mesure d’obtenir une redirection ouverte sur les API Google, mais cela s’est avéré non viable.

Cependant, il a trouvé une autre route vers SSRF.

Parce que le alt=média Le paramètre a servi le fichier entier plutôt que l’objet JSON, lorsque l’application a analysé le JSON et extrait downloadUrlles attaquants pourraient prendre le contrôle de downloadUrl.

Une charge utile contenant un objet JSON malveillant avec le downloadUrl défini sur une URL contrôlée par l’attaquant pourrait alors, selon la logique de l’application, déclencher une SSRF aveugle.

CRLF, pipeline de requêtes

Le SSRF via CRLF et le pipeline de requêtes ont été trouvés sur un programme privé de primes de bogues et liés à la façon dont les diapositives ont été importées depuis Google Drive.

La partie traversée de chemin de l’exploit de Jaiswal a fonctionné mais pas les paramètres de requête, a découvert le chercheur.

Cependant, CRLF – désignant les éléments de caractères spéciaux ‘retour chariot’ et ‘saut de ligne’ – s’appliquait au authToken propriété, lui permettant de contrôler une partie des en-têtes de la requête.

« Avec cela, j’ai pu créer une nouvelle demande à www.googleapis.com avec mes paramètres de requête contrôlés en utilisant le pipelining de demande », a déclaré Jaiswal.

Plus à trouver

Le chercheur a déclaré que la plupart des SSRF signalés ont maintenant été corrigés, mais que d’autres pourraient se cacher, non découverts, dans d’autres applications.

« S’il existe une implémentation personnalisée de [Google Drive] et aucune désinfection n’est effectuée, cela pourrait causer ce bogue », a-t-il déclaré La gorgée quotidienne. « Je suis presque sûr qu’il y a plus d’applications encore affectées par cette découverte.