Le mois dernier, le PDG d’Uber a rapporté que l’entreprise avait été victime d’un piratage qui a permis à des hackers de s’emparer des données personnelles de 57 millions de clients et chauffeurs de la société. Et pour acheter le silence des pirates, Uber a déboursé la somme de 100 000 dollars, histoire de s’assurer également que les données ont bien été supprimées des machines des pirates. Le plus drôle c’est que cette somme aurait été versée sous forme de prime à travers le programme de bug bounty organisé par l’entreprise. C’est donc surprenant d’apprendre aujourd’hui qu’Uber userait de ruse pour ne pas payer de primes à des chercheurs en sécurité qui prennent soin de communiquer à l’entreprise des failles de sécurité critiques dans les règles de l’éthique.C’est en fait le cas de Gregory Perry, consultant en sécurité et hacker éthique. Il explique comment il a été payé 0 $ via le programme de bug bounty d’Uber après avoir signalé des failles de sécurité, dont certaines qui sont critiques, à la société de transport.
Uber s'associe à HackerOne pour offrir un programme de chasse aux bogues, communément appelé bug bounty. À travers ce programme, Uber a promis un paiement minimum garanti de 500 $ si une faille de sécurité est détectée dans une application Uber ou est relative à des informations. Précisons que Gregory Perry n'est pas un novice dans le domaine. Il dit avoir mené de nombreux tests d'intrusion au cours des années en plus de fournir une formation avancée en tests d'intrusion pour des clients corporate.
Uber connaît déjà ce problème, nous allons le corriger à l'avenir. Donc pas de paiement.
Intéressé par le programme d'Uber, il a donc passé quelques jours à rassembler des ressources pour l'analyse et pour construire une carte assez complète des différents points d'entrée (endpoints) au service d'Uber. Son travail lui a ensuite permis de découvrir une première série de quatre failles dans le système d'Uber. Les deux premières concernent l'endpoint de code promo d'Uber qui, par exemple, n'implémente pas d'authentification multifacteurs. Cela a permis au chercheur en sécurité d'énumérer des millions de jetons OAuth2 en quelques minutes.
Le troisième concerne l'application Uber pour Microsoft Surface/Phone. Celle-ci n'implémente pas l'épinglage de certificats, qui vise à empêcher toute attaque de type man-in-the-middle. Le dernier problème est que les applications mobiles Uber ne traitent les événements de déconnexion que localement, ce qui fait que les jetons OAuth2 n'arrivent jamais à expiration et donne la possibilité d'accéder aux informations sur les chauffeurs et les clients après la déconnexion d'un utilisateur de son application mobile Uber.
Il a soumis la première série de problèmes à HackerOne pour paiement. Les tickets ont été assignés à Rob Fletcher de l'équipe de sécurité d'Uber. Pour chacun des trois premiers problèmes, notre chercheur en sécurité a reçu comme réponse : « Uber connaît ce problème, nous allons le corriger à l'avenir. Pas de paiement. » Pour le dernier, Uber a répondu : « Uber n'a actuellement pas la possibilité de faire expirer les jetons émis. Nous allons résoudre ce problème avec notre framework d'authentification de prochaine génération. Pas de paiement. »
À ce stade, Gregory Perry avait passé plus d'une semaine de son temps sur ce bug bounty qui a clairement indiqué une politique de paiement minimum de 500 $ et il ne comprenait pas pourquoi il n’avait droit à aucune prime alors qu’aucun de ces problèmes n'a été publiquement documenté, chez Uber ou chez HackerOne, comme étant hors du champ du programme de bug bounty. « Je dépose donc une requête de médiation auprès de HackerOne. Elle est assignée à Kevin Rosenbaum », dit-il, avant d’indiquer la réponse qui lui est revenue :
« Je suis désolé que vous ayez une expérience négative avec ce problème, mais nous avons contacté l'équipe de sécurité de l'application Uber et ils nous ont confirmé que ce ne sont pas des problèmes de sécurité qui sont inclus dans leur programme. Peut-être une déception, mais je peux vous assurer qu'ils ont regardé ce rapport et lui ont accordé toute l'attention qu'il méritait, j'espère que vous pourrez continuer à travailler sur notre site et je vous souhaite bonne chance. »
Nouvelles tentatives de trouver des failles critiques, mais Uber n'est toujours pas convaincu de leur pertinence
M. Perry se dit alors qu'il n'a pas trouvé les bonnes failles, mais il est désormais plus motivé. « Maintenant, je suis déterminé à démontrer une vulnérabilité de gravité critique qu'Uber ne peut pas nier », se dit-il. Un autre jour, alors qu'il cherchait des failles au niveau de l'endpoint mobile https://m.uber.com, il découvre que leur CSP (Content Security Policy) inclut une liste blanche pour *.cloudfront.net. Il peut activer Cloudfront dans sa console Amazon Web Services et héberger n'importe quel code JavaScript arbitraire qu'il veut là-bas, pour qu'il soit exécuté par https://m.uber.com. « Il s'agit de deux problèmes distincts considérés comme des problèmes de gravité critique en vertu de CSP 3 », précise-t-il. Gregory Perry démontre également une faille de type XSS réfléchi et soumet le rapport à Uber.
Il se trouve aussi en mesure de contourner le portail SSO OneLogin d’Uber, ce qui entraîne la divulgation du code source de leur système de messagerie interne uChat. Ce n'est pas aussi grave que le problème précédent (XSS/CSP), mais il le soumet également à Uber. Rob Fletcher reçoit encore une fois le ticket et lui envoie une réponse : « Nous jetterons un coup d'oeil dans ceci encore une fois, mais jusqu'ici ceci n'est pas un bogue de sécurité qui est dans la portée [du programme] - vous avez manqué de démontrer l'exécution de JavaScript dans un navigateur moderne », explique l'ingénieur d'Uber à propos de la faille CSP/XSS.
M. Perry découvre toutefois que le problème qu'il a rapporté est « presque mot à mot identique » à un exemple de rapport de vulnérabilité présenté par Uber comme étant dans la portée de son programme de bug bounty : une faille de type XSS réfléchi au niveau de l’endpoint partners.uber.com. Il envoie donc le rapport d'exemple d'Uber à Rob Fletcher, en demandant des explications : « Ce problème est presque mot à mot identique à votre exemple de rapport de vulnérabilité, avec un POC qui exécute HTML arbitrairement à partir d'un site Web Uber protégé par SSL, donc je ne sais pas comment vous pourriez dire que ce n'est pas dans la portée ... »
Mais dans sa réponse, l'ingénieur d'Uber réplique que « ce n'est pas une faille de type XSS si vous ne parvenez pas à exécuter JavaScript - nous vérifions vos charges utiles les plus récentes pour voir si elles utilisent JavaScript et vont partir de là », dit-il. Autrement dit, Uber demande de fournir un exploit complet pour prouver qu'une application ou un service est vulnérable aux attaques, explique le chercheur en sécurité. « Mais si je dois aller jusqu'à ces efforts, alors pourquoi ne pas vendre légitimement l'exploit sur l'un des nombreux services de vente d'exploit ? », s’interroge-t-il.
Cette fois est la bonne. Mais Uber ne paie pas de prime. HackerOne est-il complice ?
Quoi qu'il en soit, il est déjà beaucoup investi dans sa recherche de bogues, et a construit cette fois une charge utile qui remplit les exigences d'Uber. Il parvient à injecter un formulaire HTML qui demande aux utilisateurs d'entrer leur nom utilisateur et mot de passe ; lequel formulaire est parfaitement rendu depuis l'endpoint mobile https://m.uber.com.
« Il s'agit donc maintenant d'une vulnérabilité de sécurité critique complètement vérifiée, avec un POC qui va récupérer les noms d'utilisateur et mots de passe à partir d'un endpoint mobile Uber, protégé par SSL avec un certificat signé Uber », explique le chercheur. « L'équipe de développement d’Uber est impliquée, et vérifie en outre que oui, ils peuvent exécuter du code JavaScript arbitraire à partir de n'importe quel hôte *.cloudfront.net. Ce sont donc trois problèmes de sécurité critiques distincts : XSS réfléchi, injection de contenu HTML et un CSP qui permet une exécution de JavaScript arbitraire depuis n'importe quel hôte *.cloudfront.net. »
Que fait donc la société de transport ? « Uber retire l'endpoint https://m.uber.com, et commence à rediriger les différentes applications incriminées vers leur portail SSO OneLogin. Suivi par le verrouillage puis la fermeture sans paiement de tous mes rapports de sécurité soumis, de sorte qu'ils ne peuvent pas être consultés ou divulgués publiquement », explique Gregory Perry. Pour couronner le tout, le bouton de soumission de rapport HackerOne/Uber Bug Bounty bogue maintenant, comme le montre l'image suivante.
En résumé, Gregory Perry retient donc que toute la mauvaise presse récente sur la culture d'entreprise chez Uber est vraiment réelle. Il dit également qu'Uber « n'est pas sérieux au sujet de ses efforts de sécurité, et son Bug Bounty HackerOne est complètement faux ». Si vous investissez du temps et des efforts dans les programmes de bug bounty HackerOne, il avertit également que « HackerOne n'honore pas sa garantie de prime de bogue minimum, et ne va pas se battre pour vous si vous avez un différend avec l'une des entreprises bien placées comme Uber. »
Source : Gregory Perry
Et vous ?
Que pensez-vous d'Uber et des revendications de Gregory Perry ? Avez-vous déjà vécu cette expérience ? Si oui, partagez-la En dehors du domaine de la sécurité, avez-vous déjà travaillé pour un client qui a refusé de vous payer en trouvant des prétextes farfelus ? Si oui, partagez votre expérience 
Envoyé par Lolo78
