Flux par code d’appareil : l’autorisation sur la télévision, et son hameçonnage

Un téléviseur n’a pas de clavier, et faire saisir un mot de passe avec une télécommande à quatre flèches relève de la punition. Le flux par code d’appareil, normalisé par la RFC 8628 en août 2019, règle le problème en déplaçant l’autorisation sur un second appareil : l’écran affiche une adresse et un code court, l’utilisateur les reporte sur son téléphone, et le téléviseur attend. C’est élégant, largement déployé, et c’est aussi le seul flux OAuth dont la spécification consacre une section entière à l’hameçonnage qu’il rend possible.

→ Lire l’explication complète de la marmotte

Pourquoi ce flux existe, et ce qu’il suppose

La RFC est précise sur son domaine : le flux est conçu pour les appareils connectés à Internet qui « soit n’ont pas de navigateur permettant une autorisation fondée sur un agent utilisateur, soit sont contraints en saisie au point que demander à l’utilisateur de taper du texte pour s’authentifier pendant le flux d’autorisation est impraticable ». Elle donne les exemples : téléviseurs connectés, consoles multimédias, cadres photo numériques, imprimantes. On y ajoutera, parce que c’est devenu le cas d’usage le plus répandu, les outils en ligne de commande et les clients d’interface de programmation, qui n’ont pas davantage de navigateur.

L’hypothèse de conception, énoncée à la fin de la section sur la réponse du point de jeton, explique toute la forme du protocole : « l’hypothèse de cette spécification est que l’appareil séparé sur lequel l’utilisateur autorise la requête n’a aucun moyen de communiquer en retour avec l’appareil portant le client OAuth. Ce protocole ne requiert qu’un canal unidirectionnel afin de maximiser la viabilité du protocole dans des environnements restreints, comme une application tournant sur un téléviseur qui n’est capable que de requêtes sortantes. » De là découle l’interrogation périodique, qui est le trait le plus caractéristique de ce flux et la source de ses défauts d’exploitation.

Autre caractéristique structurelle, et elle a des conséquences lourdes : « contrairement aux autres flux OAuth 2.0 d’applications natives, l’appareil qui demande l’autorisation n’est pas le même que celui depuis lequel l’utilisateur accorde l’accès. Ainsi, les signaux provenant de la session et de l’appareil de l’utilisateur qui approuve ne sont pas toujours pertinents pour la fiabilité de l’appareil client. » Tout ce que l’on sait d’ordinaire en évaluant un risque de connexion, la position, l’appareil, le comportement, concerne ici le mauvais appareil. On évalue le téléphone de l’utilisateur et l’on autorise la télévision.

Le déroulé, et les paramètres qui comptent

Le client appelle un point d’accès dédié et reçoit une réponse JSON portant six paramètres. Le device_code est le code de vérification de l’appareil, que le client garde pour lui ; la RFC insiste : il « n’est pas destiné à l’utilisateur final, et ne devrait donc pas être affiché pendant l’interaction, afin d’éviter de le confondre ». Le user_code est le code court destiné à l’utilisateur. Le verification_uri est l’adresse où l’utilisateur doit se rendre, et la RFC précise qu’elle « devrait être courte et facile à retenir, puisqu’il sera demandé aux utilisateurs finaux de la taper manuellement ». Le expires_in donne la durée de vie des deux codes, l’exemple de la RFC retenant mille huit cents secondes. Le interval donne le délai minimal entre deux interrogations, avec cinq secondes par défaut. Enfin, un verification_uri_complete optionnel contient le code déjà intégré dans l’adresse, pour les transmissions non textuelles.

L’interrogation périodique est régie par quatre codes d’erreur, dont deux sont des instructions de patience. authorization_pending signifie que l’utilisateur n’a pas fini et que le client doit réessayer, en attendant au moins l’intervalle annoncé. slow_down est sa variante punitive : l’intervalle « DOIT être augmenté de 5 secondes pour cette requête et toutes les suivantes ». access_denied et expired_token arrêtent le flux. La RFC ajoute une règle d’hygiène que peu de clients respectent : « en rencontrant un délai d’attente de connexion dépassé, les clients DOIVENT réduire unilatéralement leur fréquence d’interrogation avant de réessayer », et recommande un retrait exponentiel, par exemple en doublant l’intervalle. Et après une expiration, le client « PEUT entamer une nouvelle demande d’autorisation, mais DEVRAIT attendre une interaction de l’utilisateur avant de recommencer, pour éviter une interrogation inutile ».

Le format du code court fait l’objet d’une section de considérations d’ergonomie qui est, accessoirement, une leçon de conception. Pour réduire les erreurs de saisie sur un clavier mobile, la RFC suggère un jeu de caractères limité aux lettres A-Z sans chiffres, insensible à la casse, duquel on retire les voyelles pour éviter de former des mots au hasard, ce qui donne les vingt caractères BCDFGHJKLMNPQRSTVWXZ, agrémentés de tirets pour la lisibilité. Son exemple, WDJB-MJHT, porte huit caractères significatifs, soit vingt puissance huit. Les codes purement numériques sont un bon choix dans les régions où les claviers latins ne sont pas utilisés, à condition d’être plus longs ; l’exemple donné compte neuf chiffres. Le serveur doit retirer les tirets qu’il a ajoutés, mettre l’entrée en majuscules, et éliminer les caractères hors du jeu retenu « pour réduire les cas où un caractère tapé par erreur, comme une espace, invalide une saisie par ailleurs valide ». Il est enfin recommandé d’éviter les jeux contenant des caractères confondables, « comme 0 et O ou 1, l et I ».

L’hameçonnage à distance, et pourquoi il marche si bien

La RFC lui consacre sa section 5.4, et le mécanisme tient en deux phrases : « il est possible que le flux par code d’appareil soit initié sur un appareil en possession d’un attaquant. Par exemple, un attaquant pourrait envoyer un courriel instruisant l’utilisateur cible de visiter l’adresse de vérification et d’entrer le code. »

Il faut comprendre pourquoi cette attaque est redoutable, et la raison est que rien n’y est faux. L’adresse de vérification est la vraie adresse du fournisseur d’identité de la victime. Le certificat est valide, le nom de domaine est le bon, la page d’authentification est l’authentique. La victime s’authentifie avec son vrai mot de passe et, le cas échéant, son vrai second facteur, y compris un second facteur résistant à l’hameçonnage : il n’y a pas d’intermédiaire à détecter, puisque la victime parle directement à son fournisseur. Elle approuve ensuite une demande d’autorisation qui est, elle aussi, parfaitement légitime, à un détail près : l’appareil qui en bénéficie est celui de l’attaquant, et il récupère les jetons au bout de son interrogation périodique. Tous les réflexes enseignés en sensibilisation, vérifier l’adresse dans la barre, vérifier le cadenas, ne pas cliquer sur un lien suspect, échouent ici parce qu’ils cherchent un faux site et qu’il n’y en a pas. Le reste de l’arsenal de la manipulation, lui, fonctionne comme ailleurs, et il est décrit dans contrer le spear phishing.

Les atténuations recommandées par la RFC portent donc toutes sur la même idée : faire comprendre à l’utilisateur ce qu’il autorise. « Il est RECOMMANDÉ d’informer l’utilisateur qu’il autorise un appareil pendant l’étape d’interaction, et de confirmer que l’appareil est en sa possession. Le serveur d’autorisation DEVRAIT afficher des informations sur l’appareil, de sorte que l’utilisateur puisse remarquer si un client logiciel tentait de se faire passer pour un appareil matériel. » Autrement dit, l’écran d’approbation ne doit pas dire « autorisez-vous l’application X ? » mais « un appareil situé ailleurs demande l’accès à votre compte ; l’avez-vous devant vous ? ». La nuance est l’essentiel du sujet.

L’optimisation par adresse complète aggrave le problème, et la RFC le dit : pour les serveurs qui la prennent en charge, « il est particulièrement important de confirmer que l’appareil est en la possession de l’utilisateur, puisque celui-ci n’a plus à taper manuellement le code affiché ». Sa suggestion est astucieuse : afficher le code pendant le flux d’autorisation et demander à l’utilisateur de vérifier que le même code est affiché sur l’appareil qu’il configure. Cela transforme le code, qui était un identifiant de session, en élément de comparaison visuelle, et casse l’attaque par courriel.

Dernier point, et il est lucide : la durée de vie du code « doit être suffisamment longue pour être utilisable, et suffisamment courte pour limiter l’utilité d’un code obtenu pour de l’hameçonnage ». La RFC reconnaît aussitôt la limite de cette mesure : « cela n’empêche pas un hameçonneur de présenter un jeton frais, en particulier s’il interagit avec l’utilisateur en temps réel, mais cela limite la viabilité des codes envoyés par courriel ou par message texte ». Une campagne de masse est entravée ; un attaquant au téléphone avec sa victime ne l’est pas.

Les autres faiblesses, telles que la spécification les énumère

Force brute sur le code utilisateur. C’est le défaut structurel : le code est tapé par un humain, donc court, donc à faible entropie. La RFC recommande de limiter le débit des tentatives et donne le calcul à faire, qui mérite d’être reproduit parce qu’il est rarement fait : un code de huit caractères en base vingt porte environ 34,5 bits d’entropie, et « l’intervalle de limitation de débit et la période de validité ne devraient autoriser que cinq tentatives » pour atteindre la même probabilité de succès par devinette qu’une clé de 128 bits. Cinq tentatives, pas cinq cents. La conséquence d’un succès est inhabituelle et vaut d’être notée : l’attaquant « approuverait l’octroi d’autorisation avec ses propres identifiants, après quoi l’appareil recevrait un octroi lié au compte de l’attaquant », ce qui est « le scénario inverse d’un jeton au porteur cassé par force brute ». Le propriétaire de l’appareil se retrouve à utiliser le compte de quelqu’un d’autre, avec ce que cela implique de risque pour la vie privée des deux côtés. Les techniques de contournement d’une telle limitation sont décrites dans le contournement d’un rate limit, et leur mise en œuvre défensive dans la mise en place d’un rate limiting.

Force brute sur le code d’appareil. Comme il n’est pas affiché, aucune contrainte d’ergonomie ne pèse sur lui, et la RFC exige donc « un code à très haute entropie » ; les propriétés attendues de la source d’aléa sont celles de produire de l’aléa utilisable.

Fiabilité de l’appareil et du serveur. Si le serveur d’autorisation utilisé par l’appareil est malveillant, il peut jouer l’intermédiaire vers un autre serveur d’autorisation. La RFC note que cet intermédiaire « n’est pas complètement invisible, puisque l’utilisateur final se retrouverait sur la page d’autorisation du mauvais service », mais que pour en arriver là, « le fabricant de l’appareil doit soit être l’attaquant, soit utiliser un serveur d’autorisation contrôlé par un attaquant ». Et elle conclut par une phrase qu’on aimerait voir plus souvent dans une spécification technique : « en partie, la personne qui achète l’appareil compte sur le fabricant et ses partenaires commerciaux pour être dignes de confiance ».

Espionnage de session. Pendant que l’appareil attend, « un utilisateur malveillant peut physiquement espionner l’interface de l’appareil, par exemple en regardant l’écran sur lequel elle s’affiche, et détourner la session en complétant l’autorisation plus vite que l’utilisateur qui l’a initiée ». Un code affiché sur un écran dans un hall d’accueil n’est pas un secret. La RFC recommande de tenir compte de l’environnement d’exploitation dans le choix du canal de transmission, et pour les transmissions non visuelles, synthèse vocale ou liaison sans fil à courte portée, de n’utiliser qu’un canal « accessible seulement aux personnes à proximité immédiate, par exemple celles qui peuvent voir ou entendre l’appareil ».

Clients non confidentiels. Enfin, les clients de ce flux « sont généralement incapables de maintenir la confidentialité de leurs identifiants, puisque les utilisateurs en possession de l’appareil peuvent les extraire par rétro-ingénierie » ; ils doivent donc être traités comme des clients publics, susceptibles d’usurpation, ce qui renvoie aux précautions du flux d’autorisation ordinaire décrites dans les pièges OAuth 2.1.

Ce qu’il faut régler, et ce qu’il faut refuser

Côté serveur d’autorisation, quatre réglages ferment l’essentiel. Limiter sévèrement les tentatives de saisie du code utilisateur, au niveau que le calcul de la RFC indique et non à une valeur confortable. Fixer une durée de vie du code courte, de l’ordre de quelques minutes plutôt que de la demi-heure de l’exemple. Rédiger l’écran d’approbation autour de la question « avez-vous cet appareil devant vous ? », en affichant les informations disponibles sur l’appareil demandeur. Et, si l’adresse complète est proposée, afficher le code pour comparaison visuelle avec celui de l’appareil.

Côté organisation qui consomme des identités, deux décisions valent d’être prises explicitement. La première est de restreindre les clients autorisés à utiliser ce type d’octroi : il n’a de sens que pour des appareils réellement dépourvus de navigateur, et le laisser activé pour l’ensemble des applications d’un locataire offre un canal d’hameçonnage gratuit. La seconde est de surveiller les autorisations accordées par ce flux comme un signal à part entière, avec les méthodes de détection des connexions anormales : une approbation de code d’appareil pour un compte qui ne possède aucun appareil de ce genre est une anomalie exploitable, et c’est l’une des rares traces que cette attaque laisse. Enfin, puisque les jetons obtenus par ce flux sont ordinaires, les mesures qui limitent la valeur d’un jeton volé s’appliquent pleinement : durées courtes selon la durée de vie des jetons OAuth, et contrainte sur l’expéditeur selon DPoP.

Sources

RFC 8628 : OAuth 2.0 Device Authorization Grant, W. Denniss, J. Bradley, M. Jones, H. Tschofenig, IETF, août 2019.

🐝 Ce qui arrive si on s’en passe

Sans limitation stricte des tentatives de saisie, un code court de huit caractères se devine, et l’appareil d’un tiers se retrouve lié au compte de celui qui a devin. Sans durée de vie courte, un code transmis par courriel reste utilisable assez longtemps pour qu’une campagne de masse trouve une victime. Sans écran d’approbation posant la question de la possession de l’appareil, la victime autorise un équipement situé ailleurs en croyant autoriser une application, et aucun de ses réflexes de vigilance ne peut l’alerter puisque le site, le certificat et l’authentification sont authentiques. Sans affichage du code pour comparaison quand l’adresse complète est utilisée, la seule étape qui obligeait la victime à regarder l’appareil disparaît. Sans restriction des clients autorisés à utiliser ce flux, une organisation laisse ouvert un canal d’hameçonnage qu’aucun de ses appareils n’utilise. Et sans surveillance des autorisations accordées par ce flux, l’attaque ne laisse aucune trace distinguable d’une connexion légitime.

🦫 Explication de la marmotte 🍫

Pour connecter une application de télévision à un compte en ligne, taper un mot de passe avec une télécommande est pénible. On procède donc autrement : la télévision affiche une adresse internet et un code de huit caractères, l’utilisateur ouvre cette adresse sur son téléphone, se connecte normalement à son compte, saisit le code, et approuve. Pendant ce temps, la télévision interroge le service toutes les cinq secondes pour savoir si c’est fait, et récupère son autorisation quand elle l’est.

L’attaque est d’une simplicité désarmante. Un escroc démarre le processus depuis son propre ordinateur, obtient un code, et vous l’envoie par courriel en prétextant une vérification. Vous ouvrez l’adresse, qui est la véritable adresse de votre fournisseur de compte. Vous vous connectez avec votre vrai mot de passe et votre vrai second facteur. Vous saisissez le code et vous approuvez. Et l’escroc, à l’autre bout, récupère l’accès à votre compte.

Ce qui rend l’attaque efficace, c’est que rien n’est faux. Il n’y a pas de faux site à repérer, pas de certificat douteux, pas d’adresse bizarre : vous parlez bien à votre fournisseur, et c’est bien lui qui vous délivre l’autorisation. Les conseils habituels de vigilance ne servent donc à rien, parce qu’ils apprennent à reconnaître une imitation.

La seule défense qui fonctionne est de changer la question posée à l’écran. Au lieu de demander « autorisez-vous cette application ? », le service doit demander « un appareil situé ailleurs demande l’accès à votre compte, l’avez-vous devant vous ? », et afficher ce qu’il sait de cet appareil. Le document de référence recommande aussi d’afficher le code pendant l’approbation, pour que l’utilisateur vérifie qu’il est bien le même que celui affiché sur son téléviseur. Un code reçu par courriel ne passe pas ce test.

Du côté des entreprises, deux précautions simples : n’autoriser ce procédé que pour les applications qui en ont réellement besoin, et surveiller les autorisations qu’il produit, parce qu’une approbation de ce type pour quelqu’un qui n’a aucun appareil sans clavier est une anomalie facile à repérer.

Pages voisines

La citent

Flux par code d'appareil : l'autorisation sur la télévision, et son hameçonnage

Elle cite

: les deux pages se citent l’une l’autre.