Añaden ofuscación del timing de pulsaciones a ssh(1)

 (undeadly.org)
3 puntos por GN⁺ 2023-08-30 | 1 comentarios | Compartir por WhatsApp
  • Damien Miller hizo commit de una función de ofuscación para ocultar la información de tiempo entre pulsaciones en el cliente ssh(1)
  • Cuando hay pocos datos enviados en tráfico interactivo, usa envío a intervalos fijos, con un intervalo predeterminado de 20 ms
  • Después de la última pulsación real, envía durante un tiempo aleatorio pulsaciones falsas de chaff para difuminar aún más el patrón temporal
  • El comportamiento se controla con la nueva palabra clave de ssh_config: ObscureKeystrokeTiming
  • La implementación usa una nueva extensión PING/PONG de la capa de transporte SSH, y más adelante podría llegar también a otros sistemas mediante openssh-portable

Ocultar el timing de pulsaciones en el cliente ssh(1)

  • Damien Miller hizo commit de soporte para ofuscación del timing de pulsaciones en ssh(1)
  • Esta función intenta enviar el tráfico interactivo con pocos datos a intervalos fijos para ocultar los intervalos de tiempo entre pulsaciones
    • El intervalo de envío predeterminado es de 20 ms
    • Después de la última pulsación real, envía pulsaciones falsas de chaff durante un tiempo aleatorio
  • El comportamiento se controla con la nueva palabra clave de ssh_config: ObscureKeystrokeTiming

Extensión del protocolo SSH y ruta de despliegue

  • La implementación usa dos nuevos mensajes de la capa de transporte añadidos al protocolo SSH
    • SSH2_MSG_PING
    • SSH2_MSG_PONG
  • Estos mensajes usan el espacio de numeración de extensiones locales y se anuncian con el mensaje ext-info "ping@openssh.com" y la cadena de versión "0"
  • Este cambio se presenta como un ejemplo de “security by trickery” y se menciona como una razón para esperar la próxima versión de OpenBSD
  • Es probable que otros sistemas vean pronto esta función a través de openssh-portable

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-08-30
Opiniones en Hacker News

  • El timing de las pulsaciones de teclas era una preocupación en la entrada/salida de terminales desde la década de 1980, y ya en ese entonces era algo que se tenía en cuenta en entornos tempranos de cifrado como stelnet o Kerberos.
    La mayoría de las apps de terminal usan entrada/salida con búfer para ingresar contraseñas, y eso sigue siendo una función de seguridad importante.
    En este modo, no se envía nada al otro extremo hasta que el usuario presiona Enter, así que, si hay padding, a un atacante de intermediario le cuesta incluso inferir la longitud de la contraseña.
    Durante un tiempo, las apps que recibían contraseñas en modo sin búfer para mostrar un * cada vez que el usuario escribía fueron un buen blanco.
    Se ve bien y da feedback, pero filtra la velocidad de tecleo, que es justo lo que más debería ocultarse al ingresar una contraseña.
    Me gustaría que se siguiera usando entrada/salida con búfer para ingresar contraseñas, y creo que este método es tan superior que sería difícil de igualar incluso con la ofuscación de SSH.
    Aun así, está bueno que SSH haya agregado esta función, y ayuda a proteger cosas que no se pueden bufferizar, como la entrada en shells o editores.

    • El método que se usa actualmente, de mostrar una cantidad fija de asteriscos sin relación con la longitud de la contraseña, resulta bastante confuso para el usuario.
      Puede pensar “como la longitud está mal, seguro es incorrecta” y terminar anulando la ventaja de una contraseña guardada al intentar escribir manualmente la contraseña “correcta”.
      Creo que en el pasado también había métodos que mostraban un hash visual, como un hash de 2 dígitos y un smiley, pero eso podría ayudar más bien a ataques de espionaje por encima del hombro.
    • En la década de 1990, con un addon de IA basado en Visual Basic, bastaban unos minutos de tipeo para identificar quién estaba usando el teclado solo por sus patrones de escritura, lo que hacía que el proceso de login fuera prácticamente inútil.
      Hoy eso también podría aplicarse a logins en pantallas táctiles, vinculando presión del dedo, área de contacto y forma con el usuario.
      Si se incluyen swipes o movimientos del mouse en el contexto de un sistema operativo de escritorio, también sería posible una app de seguridad que bloquee el sistema cuando lo está usando alguien que no es el dueño del dispositivo o de la cuenta.
      Como mínimo, podría registrar el momento en que mi pareja revisó mi teléfono.
    • Lo correcto es casi nunca usar autenticación SSH basada en contraseña.
    • Me pregunto si existen clientes SSH que buffericen la entrada por líneas.
      Es decir, que no envíen lo escrito hasta que se presione Enter o un botón de enviar.
      En la época en que jugaba mucho MUD usaba clientes Telnet así, pero no lo vi en los clientes SSH que probé después.
      Parece una defensa razonable contra la filtración del timing de las pulsaciones en SSH, y en algunos escenarios de uso incluso podría ser mejor que el método de retraso de 20 ms mencionado en el artículo.
      Aunque, pensándolo bien, lo ideal sería que también se enviara cuando se presiona Tab para el autocompletado del shell de Linux.
    • Si “la mayoría de las apps de terminal usan entrada/salida con búfer para ingresar contraseñas”, me pregunto si el hecho de que exista este parche significa que OpenSSH no se comporta así.

  • Me hizo pensar en el bridge profesional.
    Separan a los equipos con una pared y pasan las cartas simultáneamente por una ventanilla para impedir la comunicación mediante timing.
    https://youtube.com/watch?v=RVZLNRmO3vo

    • Aun así hacen trampa mediante pantallas.
      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...
      Y esos son solo los casos que conocemos.
      Una vez usé bridge en una entrevista.
      En bridge existe una regla de Active Ethics según la cual, si tu compañero te da una pista por un medio distinto de la subasta, cuando sea lógicamente posible debes elegir obligatoriamente la dirección contraria.
      En una entrevista de debugging, el entrevistador intentaba llevarme de forma demasiado obvia hacia la respuesta, así que antes de hacer lo que él decía me detuve a verificar todo lo que se me ocurría.
      Después de la entrevista le expliqué por qué lo había hecho y le dije que, si necesitaba más explicación, buscara Active Ethics.
      Y me aceptaron.
    • Si las personas solo tuvieran que ejecutar un autómata predefinido, como si fueran máquinas de estados humanas, y recibieran penalizaciones al desviarse, entonces mejor determinar al ganador lanzando una moneda y saltarse el juego.
      Es parecido a decir que el catcher no debería poder hacerle señas al pitcher.
      La transmisión de información es una habilidad humana que agrega una dimensión al juego, y debería dejarse ganar a quien mejor la domine.
    • Desde una perspectiva de red team, aquí hay demasiadas irregularidades humanas que se pueden explotar.
      No parece tan difícil transmitir 1 o 2 bits de información.
    • El bridge es un juego realmente extraño.
      La comunicación secreta con tu compañero es central, pero esa comunicación no puede ser secreta.
      Es muy raro, como si estuviera permitido comunicarse, pero a la vez no se pudiera comunicar.
    • Todavía parece haber posibilidades de transmitir información.
      Por ejemplo, se podría empujar una mesita al otro lado de la barrera con un golpecito o hacerlo lentamente para indicar algo.
      La persona de la parte superior derecha del video la pasó así en la primera y la segunda vez.

  • Hay un artículo de 2008 que presenta un paper de 2001 sobre estos ataques de timing: https://lwn.net/Articles/298833/
    El paper citado se llama “Timing analysis of keystrokes and timing attacks on SSH” y analiza cómo la información de timing de las pulsaciones filtra información sobre la secuencia de teclas ingresada.
    En un análisis más detallado, se dice que por cada par de pulsaciones se filtra alrededor de 1 bit de información sobre el contenido, y que, como la entropía de una contraseña ronda los 4 a 8 bits por carácter, esa información puede ser bastante significativa.
    Pensé que esto se había corregido hace mucho, y creía que se había incorporado una corrección alrededor de 2012, así que me sorprende bastante que todavía no esté resuelto.

  • Algún día quizá haya que usar paquetes rellenados previamente con datos aleatorios para ocultar las pulsaciones de teclas.
    No es esteganografía, pero se le parece bastante, y también podría servir para hacer que el análisis de tráfico sea más difícil o imposible.

    • La NSA y otros llevan décadas usando métodos así.
      Si se trata de una línea dedicada, no es tan difícil mantenerla siempre a su máxima utilización, completamente cifrada, y superponer los datos reales solo cuando sea necesario.
    • Con este método también es posible la esteganografía.
      Hay investigaciones donde se hace que un modelo de lenguaje reescriba un texto de cobertura inocuo, pero cambiando la distribución de probabilidad usada para el muestreo de palabras por una distorsión de entropía mínima derivada de una clave.
      En el lado receptor, usando el mismo modelo y la misma clave, se puede volver a descifrar el texto de cobertura como texto cifrado, y también se aplica a imágenes.
      https://openreview.net/forum?id=HQ67mj5rJdR
    • Me recuerda a las emisoras de números.
      Transmiten números continuamente a todo el mundo, y solo adquieren significado cuando esos números significan algo para alguien.
      Lo hacen aun sabiendo perfectamente que las agencias de inteligencia del mundo están escuchando todo el tiempo.
    • Algunos protocolos de mensajería funcionan así.
    • El tráfico SSH está cifrado, así que para un observador los paquetes ya parecen datos aleatorios.

  • Me vienen a la mente emuladores de terminal modernos como Warp en macOS.
    Por ejemplo, me pregunto si reciben toda la entrada localmente y luego la envían al host remoto en un solo bloque.
    Eso podría romper ciertas entradas en modo raw que se ejecutan en el host remoto, pero quizá podrían detectar esas situaciones y cambiar a un flujo de pulsaciones sin procesar.
    [1]: https://warp.dev

    • Por lo general, cuando te conectas por SSH, la conexión en sí siempre está en modo raw, y el host remoto maneja la pty de la forma habitual.
      La pty remota puede estar en modo por líneas o en modo raw.
      Las terminales con integraciones especiales de shell normalmente requieren que esa integración también esté instalada en el host remoto, y algunas lo manejan de forma bastante transparente.
      Por eso mosh puede comportarse mejor que SSH puro en conexiones con mucha latencia.
      Sin embargo, esta función no se aplicaría a mosh.
    • Es difícil imaginar que una app que se promociona como “IA para la terminal” vaya a ser más segura y privada que las herramientas estándar de Unix.
      Es posible que una herramienta nueva proteja mejor contra funciones de seguridad específicas, como defensas contra ataques de temporización, y que las herramientas estándar antiguas no las tengan.
      Pero es mucho más probable que a una herramienta nueva le falten otras funciones de seguridad, y al agregar “IA” también aumenta mucho la superficie de ataque.
      Francamente, las afirmaciones de privacidad de Warp también son difíciles de creer.
      Hoy en día las herramientas de procesamiento de lenguaje natural tienden casi siempre a soluciones en la nube, y entonces la posibilidad de privacidad cae casi de inmediato a cerca de cero.
    • Si algo está diseñado para recibir datos a una determinada velocidad en baudios, ¿no terminaría entrando también la entrada enviada en bloque a esa misma velocidad?

  • Me pregunto qué amenaza mitiga esto.

    • Un espía no puede ver el contenido de las pulsaciones, pero antes sí podía ver cuándo se transmitía cada pulsación.
      Si conoce el patrón de tipeo del objetivo, con esos datos puede reconstruir el contenido.
      Puede hacer que el objetivo escriba en un sitio web bajo su control con JavaScript habilitado, o grabar el sonido del tecleo para recolectar el patrón.
      Recientemente, algunos streamers en línea también han sufrido ataques en los que les roban contraseñas con modelos de IA entrenados con el sonido de su teclado.
    • Si mal no recuerdo, alrededor de 2005 hubo un paper que podía inferir lo escrito correlacionando el timing de paquetes de una sesión SSH cifrada con estadísticas recopiladas de tecleo humano.
      Esta función parece agregar ruido para impedir eso.
    • La preocupación original por la vulnerabilidad era el uso del algoritmo de Viterbi.
      http://www.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf [2001]
      Con la incorporación de aprendizaje automático, la precisión para descifrar audio mejoró mucho, así que conviene usar un teclado silencioso en lugares físicamente inseguros.
      https://arstechnica.com/gadgets/2023/08/type-softly-research...
    • Básicamente, analizando la velocidad de tipeo se pueden hacer algunas estimaciones.
      Por ejemplo, los usuarios suelen escribir las contraseñas más rápido que otros textos, así que en operaciones como sudo se puede inferir la longitud de la contraseña mirando cuántas pulsaciones se transmitieron juntas de una vez.
    • Recientemente aparecieron trabajos que usan el timing de pulsaciones y deep learning para identificar a usuarios como con una huella digital; este paper lo usa para autenticación: https://www.usenix.org/system/files/usenixsecurity23-piet.pd...
      El caso de uso de ese paper en sí no es una amenaza de seguridad, pero puede interpretarse como una fuga de información.

  • Me pregunto cuánta latencia agrega.
    En particular, la latencia impredecible es uno de los mayores factores de estrés en el trabajo de desarrollo de software.

    • Está dicho directamente en el texto.
      Cuando solo se transmite una pequeña cantidad de datos, el tráfico interactivo se envía a intervalos fijos, y el valor predeterminado es 20 ms.
    • La mención anterior a la latencia parece referirse a la latencia en la experiencia de usuario, es decir, el tiempo entre presionar una tecla y ver el resultado.
      [1]
      Herramientas como Mosh ayudan bastante a reducir la latencia percibida.
      Mosh muestra la tecla del usuario en cuanto se registra localmente, y la muestra en un color tenue para indicar que el ida y vuelta aún no terminó.
      Así era la última vez que lo vi, aunque tal vez era subrayado.
      Cuando termina el ida y vuelta, el carácter se muestra normalmente.
      [1] Si el mayor factor de estrés en el desarrollo de software es la latencia de las teclas, suena a que tienes bastante suerte.
      [2]: https://mosh.org
    • ¿Esta latencia no es predecible por diseño?

  • Enlace al commit real: https://github.com/openssh/openssh-portable/commit/7603ba712...

  • Parece que algunos detectan en la red shells hands-on-keyboard midiendo el timing de los paquetes, y me pregunto cuánto dificultará esta detección este cambio

    • Ojalá ese tipo de enfoques siga el mismo camino que otros intentos corporativos de romper el cifrado o meter backdoors en nombre de la “seguridad”
      Me parece una forma realmente equivocada de abordar la seguridad
      Puede ser útil saber si un script de automatización está iniciando sesión en un equipo, pero con un mejor diseño se podría hacer que esa información dejara de ser importante
    • ¿Cuáles serían los casos de uso no maliciosos para esto?