Dans la nuit du mercredi 19 au jeudi 20 août, peu après minuit (heure française), Google a réparé un bug, plutôt dangereux, qui affectait son service Gmail. Il permettait à n’importe qui d’envoyer des emails avec le nom de n’importe quel client de Gmail ou G Suite.
Concrètement, un malfaiteur aurait pu vous envoyer des emails avec l’adresse de votre dirigeant ou dirigeante d’entreprise, dans l’objectif de vous extorquer des informations confidentielles sur l’entreprise, de vous faire payer une fausse facture ou de vous faire cliquer sur une pièce jointe contenant un malware.
Ce bug de Gmail est un outil rêvé pour les opérateurs de phishing. // Source : Claire Braikeh pour Numerama
La vulnérabilité permet de tromper les utilisateurs de Gmail mais elle permet surtout de passer outre les protections automatiques censées protéger contre ces abus. L’usurpation d’identité aurait été particulièrement compliquée à détecter.
Ce bug, idéal pour des opérateurs de phishing, a été découvert par la chercheuse Allison Husain, qui a contacté Google dès le 1er avril. Malgré l’échange régulier entre les deux partis, Google n’avait toujours pas réparé la vulnérabilité le 19 août. Husain a donc décidé de publier une preuve de concept de l’exploitation de cette vulnérabilité. Google a finalement déployé une réparation temporaire 7 heures plus tard.
Tromper les standards de sécurité des emails
Pour sécuriser les échanges d’emails, de nombreux standards se sont empilés en même temps que la croissance d’Internet. Aujourd’hui, deux des plus connus sont le SPF et le DMARC, des méthodes d’authentification chargées de déceler si l’expéditeur n’usurpe pas son identité. Par exemple, Google va présenter un ensemble de règles et d’indicateurs (les adresses IP utilisées, la façon dont est construit l’email, des signatures cryptographiques…) à son SPF et à son DMARC.
Les serveurs destinataires des messages envoyés par Gmail pourront utiliser ces critères pour déceler si l’expéditeur Gmail est bien qui il affirme être. De même pour tous les serveurs par lequel transitera le message.
Une bonne redirection, et le tour est joué
Pourquoi est-ce que nous vous parlons de ces standards ? Eh bien, parce que Allison Husain a trouvé une méthode pour que ses emails truqués les déjouent. Dans un premier temps, elle a découvert une erreur qui lui permettait d’envoyer des emails trafiqués à une passerelle de messagerie entrante dans le backend de Gmail. Autrement dit, elle a trouvé un serveur de Google qui ne filtrait pas correctement les emails malveillants.
Ensuite, elle a constaté qu’elle pouvait régler elle-même le routage des emails qu’elle envoyait, c’est-à-dire le chemin de serveurs par lesquelles ses emails vont passer. Grâce à l’option « modifier le destinataire de l’enveloppe », elle pouvait faire passer son email sur le serveur situé dans le backend de Google puis le rediriger vers sa victime. En utilisant cet itinéraire, son email valide les standards SPF et DMARC de Google, ce qui lui permet de se présenter comme un message Gmail auprès des autres services d’email. Non seulement l’email respecte les standards de Google, mais en plus il aura vraisemblablement un haut score de confiance auprès des autres serveurs chargés de filtrer les messages à la réception, puisqu’il provient d’un serveur de l’entreprise.
Allison Husain a résumé l’attaque dans un schéma. // Source : Allison Husain
137 jours et une publication avant que Google ne répare le bug
Avec ce schéma d’attaque, Allison Husain pensait tenir un bug de premier plan, lorsqu’elle a contacté Google, le 3 avril 2020. Elle explique dans son blog que l’entreprise lui a répondu le 16 avril, et défini la dangerosité du bug comme haute, mais pas critique. Sauf que 5 jours plus tard, son bug était classé comme un duplicata, une façon pour Google d’indiquer qu’il était déjà au courant du problème et travaillait déjà dessus.
Problème : le 1er août, soit 120 jours après sa première prise de contact, la chercheuse a constaté que son scénario d’attaque fonctionnait toujours. Elle aurait alors contacté Google pour leur indiquer qu’elle publierait un billet de blog sur le bug le 17 août. D’après la chercheuse, l’entreprise a répondu qu’un patch destiné à réparer le bug serait prêt avant le 14 août, avant de finalement repousser sa sortie au mois de septembre.
Allison Husain a tout de même publié son billet de blog, et Google a finalement déployé des réparations dans les 7 heures qui ont suivies.
Pas de prime pour la chercheuse
Publier au sujet d’un bug avant qu’il soit résolu est une pratique relativement courante dans le milieu, lorsqu’un ou une chercheur estime que l’entreprise ne prend pas la faille suffisamment au sérieux. Puisque le problème n’est pas corrigé, les chercheurs alertent les personnes concernées de son existence, afin qu’ils puissent prendre des mesures pour s’en protéger. Mais en alertant les potentielles victimes, ils mettent également les malfaiteurs au courant du problème, et vont attiser leur intérêt. De quoi tirer la sonnette d’alarme chez l’entreprise concernée.
D’ailleurs, Google Project Zero, une des unités de recherche réputée du groupe californien, est une grande défenseur du délai de 90 jours. Si l’entreprise concernée ne prend pas le problème en charge 90 jours après avoir été prévenue, Google publie ses travaux et ses méthodologies.
Allison Husain explique sur son compte Twitter qu’elle n’a pas reçu de prime pour sa découverte. « Je n’en attendais pas une de toute manière, puisque le dossier avait été classé comme duplicata. Je ne pense pas que Google paie habituellement pour ce genre de bugs, puisqu’il s’agit — techniquement — d’une attaque d’ingénierie sociale, qui sort du champ du bug bounty », ajoute-t-elle.
Abonnez-vous à Numerama sur Google News pour ne manquer aucune info !
