Logo Openminded

Fr

En

Le leak d’informations personnelles par l’exploitation des partenaires

Article - 29 septembre 2020

Dans le cadre de campagnes de pentests ou programmes de bug bounty, un effort particulier est mis en oeuvre pour sécuriser les requêtes des API en elles-mêmes. Mais qu’en est il de la transmission d’informations personnelles aux partenaires ?

 

Afin de permettre aux utilisateurs de s’authentifier auprès de partenaires, les API OAuth sont un moyen privilégié pouvant mener à une fuite d’informations sensibles. C’est le cas rencontré récemment dans le cadre d’un programme de « Bug Bounty » d’une API OAuth.

Les API Oauth : qu'est-ce que c'est ?

OAuth permet aux utilisateurs de donner, au site ou logiciel « consommateur », l’accès à des informations personnelles provenant du site « fournisseur » de service ou de données, ceci tout en protégeant le pseudonyme et le mot de passe des utilisateurs.
Elles sont aujourd’hui très largement utilisées au travers des fonctionnalités « Sign in with Facebook », « Sign in with Google », etc..

 

Afin de donner l’accès aux ressources du fournisseur, il est nécessaire de fournir plusieurs paramètres à l’API :

Le client id : Le paramètre déterminant vers quelle application tierce l’API doit nous rediriger

Le response type : Détermine le type d’authentification (« code » pour l’utilisation d’un parametre et « token » pour l’utilisation d’un header)

Le redirect uri : Détermine l’URL vers laquelle l’utilisateur sera redirigé (l’url doit correspondre aux redirect uri enregistrés pour le client_id)

L’url pour accèder à l’application partenaire ressemble alors à ceci :

  • https://apioauth.domain.com/v1/oauth2/authorize?response_type=code&client_id=application1&redirect_uri=https://www.monsite.com/partners/your_account.php

Un certain nombre de vérifications sont effectuées par l’API OAuth, dont le domaine spécifié dans le paramètre redirect_uri. Cependant, en modifiant le path du domaine sur lequel s’effectue la redirection, j’ai réalisé que l’API pouvait rediriger sur le path modifié de www.monsite.com.

 

Par conséquent, l’URL :

  • https://apioauth.domain.com/v1/oauth2/authorize?response_type=code&client_id=application1&redirect_uri=https://www.monsite.com/path/modified/

Redirige vers :

  • https://www.monsite.com/modified/

A noter la présence d’un token positionné par l’API OAuth dans l’URL à la valeur du paramètre state de « monsite.com » permettant de rendre l’URL accessible.

 

 

On peut rediriger vers un path arbitraire du site, mais quel est le risque ?

C’est ici que prend l’importance de l’articulation de plusieurs vulnérabilités entre elles. Si l’on peut rediriger vers un path arbitraire, peut-être peut-on rediriger vers une vulnérabilité de www.monsite.com ?

 

Après quelques recherches j’ai observé que l’URL de déconnexion était vulnérable à une « Reflected XSS » (injection de code JS client-side). Mes investigations m’ont aussi amené à constater que la page « signin.php » du site « www.monsite.com » retournait l’adresse e-mail de l’utilisateur connecté à https://apioauth.domain.com.

 

Un attaquant peut alors rediriger la victime vers la « Reflected XSS » et lui faire exécuter une requête AJAX récupérant cette adresse email, et l’envoyant vers un serveur sous le contrôle de l’attaquant.

 

Exemple de payload JS le permettant :

L’exploitation de cette vulnérabilité aurait donc permis la fuite d’une donnée à caractère personnel, i.e l’e-mail, vers l’attaquant.

 

Mais malheureusement pour « monsite.com », il y avait encore plus simple : le cookie de session PHPSESSID n’était pas protégé par le flag « HTTPOnly » prévenant l’accès aux cookies par le Javascript. Par conséquent, il est possible de réaliser un vol de cookie de session, via l’exploitation de la vulnérabilité « Reflected XSS ». L’exemple ci-dessous le permet :

 

  • https://www.monsite.com/api_user.php?action=signout%26return_page=%2527%2522%253e%253c%2573%2563%2572%2569%2570%2574%253e%2561%256c%2565%2572%2574%2528%2564%256f%2563%2575%256d%2565%256e%2574%252e%2563%256f%256f%256b%2569%2565%2529%253c%252f%2573%2563%2572%2569%2570%2574%253e

 

Enfin, il est donc possible à partir de l’API OAuth de positionner une URL vulnérable dans le paramètre redirect_uri, qui positionnera le token nécessaire à l’accès à l’URL de « monsite.com », afin de rediriger vers la « Reflected XSS », et réussir in fine à voler le cookie de session de l’utilisateur (ou tout autre attaque client side, comme par exemple injecter un keylogger JS dans le navigateur de la victime) :

 

  • https://apioauth.domain.com/v1/oauth2/authorize?response_type=code&client_id=application1&redirect_uri=https://www.monsite.com/api_user.php?action=signout%26return_page=%2527%2522%253e%253c%2573%2563%2572%2569%2570%2574%253e%2561%256c%2565%2572%2574%2528%2564%256f%2563%2575%256d%2565%256e%2574%252e%2563%256f%256f%256b%2569%2565%2529%253c%252f%2573%2563%2572%2569%2570%2574%253e

Conclusion

S’interfacer avec les partenaires avec les API Oauth n’est sécurisé qu’en fonction de la confiance que l’on apporte au système d’informations avec lequel on s’interface. Plus le degré de confiance avec le partenaire est faible, plus la configuration doit être stricte.

 

Ici, si le path ne pouvait être modifié il n’aurait pas été possible de faire fuiter des informations de l’application principale à partir de l’application partenaire.

 

La vulnérabilité a été découverte et immédiatement déclarée auprès du programme sur Hackerone. Elle fut remédiée en l’espace de quelques heures.

 

A. DJEMAI