Programme Bug Bounty chez Uber

La Société Uber a l’habitude de faire parler d’elle dans l’actualité cybersécurité.

Des identifiants volés qui réapparaissent sur le dark net, à la polémique de l’historique de voyage d’une journaliste piraté car elle était arrivée en retard à une réunion, en passant par la fuite au niveau d’une base de données exposées ensuite sur le net, Uber a eu sa part de déboires au niveau cybersécurité.

Cependant Uber a aussi fait des efforts pour améliorer son niveau de sécurité, en débauchant le fameux CSO de Facebook, Joe Sullivan, et en se payant en plus les services de deux car hackers, afin de travailler sur les voitures sans chauffeur, et initier ainsi un programme bug bounty officiel.

Un trio de chasseurs de bugs portugais a récemment décidé de voir ce qu’il pourrait faire avec le programme bug bounty d’Uber, tout en restant dans les limites de la légalité, et le résultat est plutôt intéressant.

Ils ont raconté leur propre histoire de façon chronologique, et ils ont inclus les zones où ils ont trouvé des bugs au sein du site web, dont Uber connaissait déjà l’existence, et qui par conséquent ne rentraient pas en ligne de compte dans le cadre du programme bug bounty.

Ces derniers ont rendu l’histoire encore plus intéressante, car ils nous ont rappelés que les tests de pénétration vont au-delà de la simple recherche de failles de sécurité et de leur signalement, et que d’anciennes failles peuvent avoir de nouvelles utilisations.

En rassemblant toutes les fuites de données partielles

Beaucoup d’attaques se basent sur des fuites de données partielles, qui à un moment viennent s’ajouter entre elles, augmentant ainsi le potentiel au fur et à mesure, et produisant ainsi un bien meilleur retour sur investissement à la fin.

Par “meilleur retour sur investissement”, nous parlons de la quantité de données personnelles que les cybercriminels peuvent récupérer au sein du système, en comparaison à la récompense d’un programme bug bounty officiel, quel que soit son ampleur.

Si vous êtes un programmeur, vous êtes certainement familier avec l’idée de “test unitaire“, une discipline au sein dans l’univers de développement de logiciels, qui dit qu’il ne sert à rien de mettre ensemble des éléments indépendants d’un système, si ces derniers échouent individuellement.

Cependant les tests unitaires ne représentent rien de plus que le point de départ d’un point de vue approche qualitative : le standard minimum qui vous empêche de construire un édifice entier à partir de parties individuelles, elles-mêmes défectueuses.

Vous aurez encore à prendre en compte comment toutes ces parties interagissent entre elles, qui s’avère être un problème bien plus compliqué, et qui en général se développe géométriquement plutôt que linéairement.

[vc_row][vc_column width=”1/1″][vc_message color=”alert-info”]

Si vous avez besoin de prendre en compte la manière avec laquelle 5 composants différents se comportement lorsque chacun d’entre eux peut avoir 6 états différents, il existe alors 6x6x6x6x6 combinaisons possibles (6⁵ = 7776), et pas seulement 6+6+6+6+6 (30).

[/vc_message][/vc_column][/vc_row]

Comment pensent les chasseurs de bug

Voici un exemple qui illustre comment les chasseurs de bug bounty pensent.

Les experts ont décidé de se promener au sein de diverses applications Uber, en recherchant des pages web qu’ils pourraient utiliser pour interagir avec les serveurs Uber, en partant du principe que des formulaires moins utilisés étaient certainement moins bien testés, au niveau de leurs interactions avec le système dans son ensemble :

Ils ont enregistré la requête HTTP qu’ils ont vu être envoyée à Uber, et l’ont étudiée.

Vous pouvez voir un champ d’en-tête particulier dénommé x-uber-token, que vous vous imaginez être un cookie de session qui est unique et rattaché à son utilisateur pour cette session en question, auquel est ajouté un élément appelé x-uber-uuid :

La réponse inclus l’adresse email de l’utilisateur connecté, une donnée personnelle qui ne constitue pas en soi une faille de sécurité, dans la mesure où l’utilisateur est déjà connecté.

Pour faire simple, x-uber-token agit comme un mot de passe valide pour cette session seulement, alors que x-uber-uuid (UUID est l’acronyme de Universally Unique Identifier, une séquence binaire de 128 octets choisie de manière aléatoire), fait plutôt office d’identifiant.

Les pentesters se sont alors demandés si x-uber-token servait vraiment de mot de passe d’authentification, ainsi ils ont changé la valeur de x-uber-uuid, en la remplaçant par une autre valeur UUID connue et correspondant à un autre utilisateur, et ils ont essayé de nouveau.

Normalement, vous vous attendez à ce que la requête soir rejetée : le serveur a l’obligation de signaler que l’UUID et le token ne correspondent pas.

Cependant les testeurs ont reçu la même réponse qu’auparavant : l’adresse email renvoyée correspondait au premier UUID, même si ce dernier n’était plus dans la requête.

En d’autres termes, le serveur semblait ignorer complètement l’en-tête x-uber-uuid, car la réponse était en réalité déterminée par x-uber-token.

Ainsi, sur un coup de tête, ils ont essayé de mettre l’UUID du deuxième utilisateur dans le champ x-uber-token parce que …

… eh bien, pourquoi pas ?

Et voilà, l’email du deuxième utilisateur est renvoyé.

Il s’agit ici déjà d’un résultat intéressant, car vous ne devriez pas pouvoir obtenir mon adresse email juste à partir de mon UUID et sans savoir mon mot de passe.

Comment trouver mon UUID

Cependant comment trouver mon UUID si je ne co-opère pas.

Pour cela, ils ont trouvé une deuxième fuite de données, en essayant d’autres formulaires car …

… eh bien pourquoi pas ?

Ils ont essayé une fonctionnalité de l’application Uber Rider qui vous permet de partager le prix de la course si vous voyagez avec une autre personne.

Pour ce faire, vous saisissez tout simplement leur numéro de téléphone, et Uber leur envoie une notification, leur demandant s’ils veulent faire moitié-moitié.

Cependant, cette “demande de partage”, que vous pouvez intercepter, inclus les UUIDs des autres utilisateurs, qu’ils décident de partager la course ou non.

Cela ne semble pas être un bug sérieux, excepté qu’il fournit une fuite de données inattendue, à savoir une manière assez fiable pour faire le lien entre un numéro de téléphone et une adresse email en utilisant la base de données Uber comme moteur de recherche.

Votre numéro de téléphone me donne votre UUID, et dans une partie du système sans rapport à priori, votre UUID me donne votre adresse email.

Il s’agit ici du genre de faille de sécurité que les tests unitaires seuls ne peuvent pas détecter.

Il existe d’autres exemples dans le rapport rédigé par les experts portugais, que nous vous recommandons de consulter, car il est terriblement éloquent, et vous donne une vision réaliste de leur manière de progresser (légalement) durant leurs tests d’Uber.

La bonne nouvelle est que les problèmes qu’ils ont trouvés ont été pris sérieusement par Uber, qui a déjà payé les compensations liées au programme bug bounty.

Quoi faire ?

Gardez à l’esprit ceci, si vous voulez vous mettre aux tests de pénétration et à la chasse au bug bounty :

• Lisez les conditions générales d’utilisation. Soyez fidèles à la fois à l’état d’esprit du programme bug bounty en question.
• Divulguer avec le sens des responsabilités : Publier vos résultats de manière appropriée et au moment convenu.
• Ne soyez pas hors la loi pour faire une quelconque démonstration. N’attendez surtout aucun remerciement si vous le faites.

Les recherches en sécurité informatique peuvent s’avérer palpitantes, cependant assurez-vous de rester dans la légalité !

Follow @SophosFrance
//
Partagez Progamme Bug Bounty chez Uber avec : http://wp.me/p2YJS1-2N1
Billet inspiré de Uber under attack – how penetration testers turn bugs into breaches par Paul Ducklin, Sophos NakedSecurity.