Ajout de l’obfuscation du timing des frappes à ssh(1)

 (undeadly.org)
3 points par GN⁺ 2023-08-30 | 1 commentaires | Partager sur WhatsApp
  • Damien Miller a validé dans le client ssh(1) une fonctionnalité d’obfuscation qui masque les informations de timing entre les frappes au clavier
  • Elle utilise un envoi à intervalle fixe lorsque peu de données sont envoyées dans le trafic interactif, avec un intervalle par défaut de 20 ms
  • Après la dernière frappe réelle, elle envoie de fausses frappes chaff pendant une durée aléatoire afin de brouiller davantage les motifs de timing
  • Le comportement est contrôlé par le nouveau mot-clé ssh_config ObscureKeystrokeTiming
  • L’implémentation s’appuie sur une nouvelle extension PING/PONG de la couche de transport SSH, et pourrait ensuite être portée sur d’autres systèmes via openssh-portable

Masquage du timing des frappes dans le client ssh(1)

  • Damien Miller a validé la prise en charge de l’obfuscation du timing des frappes dans ssh(1)
  • Cette fonctionnalité tente d’envoyer le trafic interactif, lorsque peu de données sont transmises, à intervalle fixe afin de masquer le temps écoulé entre les frappes
    • L’intervalle d’envoi par défaut est de 20 ms
    • Après la dernière frappe réelle, de fausses frappes chaff sont envoyées pendant une durée aléatoire
  • Le fonctionnement est contrôlé par le nouveau mot-clé ssh_config ObscureKeystrokeTiming

Extension du protocole SSH et voie de déploiement

  • L’implémentation utilise deux nouveaux messages de couche de transport ajoutés au protocole SSH
    • SSH2_MSG_PING
    • SSH2_MSG_PONG
  • Ces messages utilisent l’espace de numérotation des extensions locales et sont annoncés avec le message ext-info "ping@openssh.com" et la version de chaîne "0"
  • Ce changement est présenté comme un exemple de « sécurité par la ruse » et comme une raison d’attendre avec intérêt la prochaine version d’OpenBSD
  • Les autres systèmes pourraient voir cette fonctionnalité arriver bientôt via openssh-portable

À lire aussi

1 commentaires

 
GN⁺ 2023-08-30
Avis de Hacker News

  • Le timing des frappes était déjà un sujet de préoccupation pour les entrées/sorties de terminal dès les années 1980, et on y faisait déjà attention dans les premiers environnements chiffrés comme stelnet ou Kerberos.
    La plupart des applications de terminal utilisent des entrées/sorties mises en tampon pour la saisie des mots de passe, et cela reste une fonction de sécurité importante.
    Dans ce mode, rien n’est envoyé à l’autre extrémité tant que l’utilisateur n’a pas appuyé sur Entrée ; avec du padding, un attaquant en homme du milieu a donc du mal à déduire même la longueur du mot de passe.
    Pendant un temps, les applications qui demandaient le mot de passe en mode non tamponné pour afficher un * à chaque frappe étaient de bonnes cibles.
    C’est joli et cela donne un retour visuel, mais cela divulgue la vitesse de frappe, précisément ce qu’il faut le plus cacher lors de la saisie d’un mot de passe.
    J’aimerais qu’on continue à utiliser les entrées/sorties mises en tampon pour les mots de passe, et je pense que cette approche reste meilleure au point d’être difficile à égaler, même avec l’obfuscation de SSH.
    Cela dit, c’est une bonne chose que SSH ajoute cette fonction, et elle aide à protéger ce qui ne peut pas être mis en tampon, comme les saisies dans le shell ou dans un éditeur.

    • La méthode actuellement utilisée, qui affiche un nombre fixe d’astérisques indépendamment de la longueur du mot de passe, est assez déroutante pour l’utilisateur.
      Il peut se dire « la longueur n’est pas la bonne, donc ça doit être incorrect » et annuler ainsi l’intérêt d’un mot de passe enregistré, en essayant de retaper lui-même le « bon » mot de passe.
      Par le passé, il me semble qu’il existait aussi des approches affichant un hachage visuel, comme un hash à 2 chiffres et un smiley, mais cela peut au contraire aider les attaques par observation par-dessus l’épaule.
    • Dans les années 1990, avec un add-on d’IA basé sur Visual Basic, quelques minutes de frappe suffisaient pour reconnaître qui tapait au clavier uniquement à partir des schémas de frappe, ce qui rendait alors le processus de connexion pratiquement inutile.
      Aujourd’hui, on pourrait aussi appliquer cela aux connexions sur écran tactile, en associant à un utilisateur la pression du doigt, la surface de contact et la forme.
      Si l’on inclut les balayages et les mouvements de souris dans le contexte d’un OS desktop, on pourrait même imaginer une application de sécurité capable de verrouiller le système lorsqu’il est utilisé par quelqu’un qui n’est pas le propriétaire de l’appareil ou du compte.
      À tout le moins, on pourrait enregistrer le moment où mon ou ma partenaire a fouillé dans mon téléphone.
    • L’authentification SSH par mot de passe est quelque chose qu’il ne faut presque jamais utiliser.
    • Je me demande s’il existe des clients SSH qui mettent l’entrée en tampon ligne par ligne.
      Autrement dit, rien de ce qui est saisi n’est envoyé tant qu’on n’a pas appuyé sur Entrée ou sur un bouton d’envoi.
      À l’époque où je jouais beaucoup aux MUD, j’utilisais des clients Telnet de ce genre, mais je n’ai jamais vu cela dans les clients SSH que j’ai essayés depuis.
      Cela me semble être une défense correcte contre les fuites de timing des frappes SSH, et dans certains scénarios d’usage cela pourrait même être préférable à l’approche avec délai de 20 ms décrite dans l’article.
      Mais en y repensant, ce serait encore plus idéal si la touche Tab était aussi envoyée pour l’autocomplétion du shell Linux.
    • Si « la plupart des applications de terminal utilisent des entrées/sorties mises en tampon pour la saisie des mots de passe », le fait que ce patch existe signifie-t-il qu’OpenSSH ne se comporte pas ainsi ?

  • Cela me fait penser au bridge professionnel.
    Les équipes sont séparées par un écran et passent les cartes simultanément par une ouverture, afin d’empêcher la communication par le timing.
    https://youtube.com/watch?v=RVZLNRmO3vo

    • Malgré tout, il y a eu de la triche via les écrans.
      https://en.wikipedia.org/wiki/Blue_Team_(bridge)#Cheating_an...
      https://en.wikipedia.org/wiki/Fantoni_and_Nunes_cheating_sca...
      https://en.wikipedia.org/wiki/Fisher_and_Schwartz_cheating_s...
      Et ce ne sont que les cas que nous connaissons.
      J’ai déjà appliqué le bridge dans un entretien.
      Au bridge, il existe une règle d’Active Ethics selon laquelle, si votre partenaire vous donne un indice autrement que par les enchères, vous devez obligatoirement choisir l’option opposée lorsque c’est logiquement possible.
      Lors d’un entretien de débogage, l’intervieweur essayait de m’amener beaucoup trop explicitement vers la réponse ; avant de faire ce qu’il disait, je m’arrêtais donc pour vérifier tout ce qui me venait à l’esprit.
      Après l’entretien, j’ai expliqué pourquoi j’avais fait cela, et je lui ai dit de chercher Active Ethics s’il voulait plus d’explications.
      Et j’ai été pris.
    • Si les gens doivent simplement exécuter un automate prédéfini comme une machine à états humaine, avec des pénalités dès qu’ils s’en écartent, autant tirer le vainqueur à pile ou face et se passer du jeu.
      C’est un peu comme dire qu’un receveur ne devrait pas envoyer de signaux au lanceur.
      La transmission d’information est une compétence humaine qui ajoute une dimension au jeu ; autant laisser gagner ceux qui la maîtrisent le mieux.
    • Du point de vue d’une red team, il y a ici beaucoup trop d’irrégularités humaines exploitables.
      Transmettre 1 ou 2 bits d’information ne semble pas si difficile.
    • Le bridge est vraiment un jeu étrange.
      La communication secrète avec son partenaire en est le cœur, mais cette communication ne doit pas être secrète.
      On peut communiquer, mais on ne doit pas communiquer : c’est très particulier.
    • Il semble encore possible de transmettre des informations.
      Par exemple, on pourrait indiquer quelque chose en poussant brusquement une petite table au-delà de la barrière, ou en la poussant lentement.
      La personne en haut à droite de la vidéo l’a passée ainsi la première et la deuxième fois.

  • Il existe un article de 2008 présentant un papier de 2001 sur ce type d’attaques par timing : https://lwn.net/Articles/298833/
    L’article cité s’intitule « Timing analysis of keystrokes and timing attacks on SSH » et analyse le fait que les informations de timing des frappes divulguent des informations sur la séquence de touches saisie.
    Une analyse plus détaillée indique qu’environ 1 bit d’information sur le contenu fuit pour chaque paire de frappes, et que l’entropie d’un mot de passe étant d’environ 4 à 8 bits par caractère, cette information peut être assez significative.
    Je pensais que cela avait été corrigé depuis longtemps, et j’avais en tête qu’une correction avait été apportée vers 2012 ; je suis donc assez surpris que ce ne soit toujours pas résolu.

  • Un jour, il faudra peut-être utiliser des paquets préremplis avec des données aléatoires pour masquer les frappes clavier.
    Ce n’est pas de la stéganographie, mais on n’en est pas très loin, et cela pourrait aussi servir à rendre l’analyse du trafic plus difficile, voire impossible.

    • La NSA et d’autres utilisent ce genre de méthode depuis des décennies.
      Sur une ligne dédiée, il n’est pas très difficile de faire circuler en permanence un flux entièrement chiffré au débit maximal de la ligne, puis d’y superposer de vraies données seulement quand c’est nécessaire.
    • Cette approche permet aussi de faire de la stéganographie.
      Il existe des travaux où un modèle de langage réécrit un texte de couverture anodin, mais où la distribution de probabilité utilisée pour échantillonner les mots est modifiée par une distorsion d’entropie minimale dérivée de la clé.
      Côté réception, avec le même modèle et la même clé, on peut décoder le texte de couverture pour retrouver le texte chiffré, et cela s’applique aussi aux images.
      https://openreview.net/forum?id=HQ67mj5rJdR
    • Cela fait penser aux stations de nombres.
      Elles diffusent continuellement des nombres dans le monde entier, et ces nombres ne prennent sens que lorsqu’ils en ont pour quelqu’un.
      Elles le font tout en sachant parfaitement que les services de renseignement du monde entier écoutent.
    • Certains protocoles de messagerie fonctionnent ainsi.
    • Le trafic SSH étant chiffré, les paquets ressemblent déjà à des données aléatoires pour un observateur.

  • Cela me fait penser aux émulateurs de terminal modernes comme Warp sur macOS.
    Par exemple, je me demande s’ils reçoivent toutes les entrées en local avant de les envoyer d’un seul bloc à l’hôte distant.
    Dans ce cas, certaines entrées en mode raw exécutées sur l’hôte distant pourraient casser, mais on pourrait imaginer détecter ces situations et basculer vers un flux brut de frappes clavier.
    [1] : https://warp.dev

    • En général, quand on se connecte en SSH, la connexion elle-même est toujours en mode raw, et l’hôte distant gère le pty de manière classique.
      Le pty distant peut être en mode ligne ou en mode raw.
      Les terminaux dotés d’une intégration spéciale avec le shell nécessitent généralement que cette intégration soit aussi installée sur l’hôte distant, et certains le gèrent de façon assez transparente.
      C’est pourquoi mosh peut mieux se comporter que du SSH pur sur des connexions à forte latence.
      Cela dit, cette fonctionnalité ne s’appliquera pas à mosh.
    • Il est difficile d’imaginer qu’une application qui se présente comme de « l’IA pour le terminal » soit plus sûre et plus privée que les outils Unix standard.
      Pour certaines fonctionnalités de sécurité précises, comme la protection contre les attaques par analyse temporelle, un nouvel outil peut mieux s’en sortir, alors qu’un vieil outil standard peut ne pas en disposer.
      Mais il est beaucoup plus probable que d’autres fonctions de sécurité manquent dans le nouvel outil, et ajouter de « l’IA » augmente fortement la surface d’attaque.
      Honnêtement, les affirmations de Warp en matière de confidentialité sont difficiles à croire.
      Les outils de traitement du langage naturel actuels penchent presque tous vers des solutions cloud, et dans ce cas la possibilité de préserver la vie privée tombe presque immédiatement à zéro.
    • Si quelque chose est conçu pour recevoir des données à un certain débit en bauds, des entrées envoyées d’un seul bloc ne seraient-elles pas quand même injectées à ce débit ?

  • Je me demande quelle menace cela atténue.

    • Un espion ne peut pas voir le contenu des frappes, mais auparavant il pouvait voir quand chaque frappe était envoyée.
      Si l’on connaît les schémas de frappe de la cible, ces données permettent de reconstituer le contenu.
      On peut collecter ces schémas en faisant taper la cible sur un site web que l’on contrôle dans un navigateur avec JavaScript activé, ou en enregistrant le son de sa frappe au clavier.
      Récemment, certains streamers en ligne ont même subi des attaques où des modèles d’IA entraînés sur le son de leur clavier servaient à voler leurs mots de passe.
    • Si ma mémoire est bonne, il y avait un article vers 2005 qui permettait de découvrir ce qui était tapé dans une session SSH chiffrée en corrélant le timing des paquets avec des statistiques de frappe humaine collectées.
      Cette fonctionnalité semble ajouter du bruit pour empêcher cela.
    • La préoccupation initiale autour de la vulnérabilité concernait l’utilisation de l’algorithme de Viterbi.
      http://www.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf [2001]
      Avec l’ajout du machine learning, la précision du décodage audio s’est beaucoup améliorée ; dans les lieux qui ne sont pas physiquement sûrs, mieux vaut donc utiliser un clavier silencieux.
      https://arstechnica.com/gadgets/2023/08/type-softly-research...
    • En gros, on peut analyser la vitesse de frappe pour faire quelques déductions.
      Par exemple, les utilisateurs tapent généralement leur mot de passe plus vite que le reste, donc pour une action comme sudo, on peut estimer la longueur du mot de passe en observant le nombre de frappes envoyées d’un coup.
    • Des travaux récents utilisent le timing des frappes et le deep learning pour identifier les utilisateurs comme par empreinte, et cet article étudie son usage pour l’authentification : https://www.usenix.org/system/files/usenixsecurity23-piet.pd...
      Le cas d’usage de l’article lui-même n’est pas une menace de sécurité, mais on peut l’interpréter comme une fuite d’information.

  • Je me demande quelle latence cela ajoute.
    En particulier, une latence imprévisible est l’un des plus grands facteurs de stress dans le travail de développement logiciel.

    • C’est indiqué directement dans le texte.
      Quand seules de petites quantités de données sont envoyées, le trafic interactif est transmis à intervalle fixe, avec une valeur par défaut de 20 ms.
    • La remarque ci-dessus sur la latence semble parler de la latence dans l’expérience utilisateur, c’est-à-dire le délai entre l’appui sur une touche et l’affichage du résultat.
      [1]
      Des outils comme Mosh aident pas mal à réduire la latence perçue.
      Mosh affiche la frappe de l’utilisateur dès qu’elle est enregistrée localement, dans une couleur estompée pour indiquer que l’aller-retour n’est pas terminé.
      C’était comme ça la dernière fois que j’ai regardé, ou c’était peut-être souligné.
      Une fois l’aller-retour terminé, le caractère s’affiche normalement.
      [1] Si la latence des frappes clavier est le plus grand facteur de stress en développement logiciel, cela ressemble plutôt à une chance.
      [2] : https://mosh.org
    • Cette latence n’est-elle pas prévisible par conception ?

  • Lien du commit réel : https://github.com/openssh/openssh-portable/commit/7603ba712...

  • Certains semblent détecter sur le réseau les shells hands-on-keyboard en mesurant le timing des paquets ; je me demande dans quelle mesure ce changement va gêner ce type de détection

    • J’aimerais que ce genre de méthode prenne le même chemin que d’autres tentatives d’entreprise visant à casser le chiffrement ou à ajouter des backdoors au nom de la « sécurité »
      Je trouve que c’est vraiment une mauvaise façon d’aborder la sécurité
      Ce serait utile de savoir si un script d’automatisation se connecte à un équipement, mais une meilleure conception pourrait rendre cette information sans importance
    • Quels seraient les cas d’usage non malveillants de cela ?