¿Cuáles son los riesgos de SSHing para un host no confiable?

17

Cuando un atacante con permisos de root ha hecho SSH a un host que ha sido comprometido (o ha sido reemplazado por completo con las claves de servidor robadas), ¿qué es lo peor que le puede pasar al cliente?

Es bien sabido que el reenvío X presenta algunos riesgos y agente el reenvío es obviamente una mala idea en ese escenario, pero son hay mas problemas?

  • ¿Qué información se puede obtener sobre el cliente, además de las variables de entorno establecidas por ssh (SSH_CONNECTION, todo desde ~ / .ssh / environment)?
  • ¿Qué se puede lograr con las secuencias de escape del terminal?
  • ¿Qué tan difícil es falsificar un cierre de sesión (en respuesta a CTRL + D, cierre de sesión, etc.) para el cliente, lo que provoca que un usuario ejecute comandos adicionales con entradas potencialmente sensibles en el host remoto, como sudo con una entrada de contraseña? ? ¿Se puede leer el mensaje del cliente de forma remota para hacer más convincente este engaño?
  • ¿Hay formas efectivas de prevenir este engaño, como alias ssh con "ssh; echo somesecret"?
pregunta lxgr 28.06.2013 - 14:52
fuente

1 respuesta

12

Interceptar los comandos de "cierre de sesión" es fácil en el servidor hostil. Interceptar el "Ctrl-D" requiere tomar el control del terminal en modo raw, pero eso no es un gran problema.

Volver a leer el contenido del terminal puede ser difícil. Diferentes terminales implementan su propio conjunto de secuencias de control; xterm es conocido por implementar muchos de ellos . No veo ninguna secuencia que permita volver a leer el contenido del terminal; sin embargo, aún se pueden hacer algunos errores considerables con las secuencias, como mover la ventana, cambiar de fuente, etc. En días anteriores, era posible hacer que xterm creara archivos locales, aunque sin mucho control sobre el nombre del archivo (no recuerdo los detalles, pero probablemente fue con la función de "archivos de registro" que se puede desactivar en la compilación). hora). Además del baile, también se puede hacer un xterm para cantar, con el "carácter de campana", aunque es más una molestia que un vector de ataque.

Hablando de molestias: dependiendo del sistema cliente y su configuración y controladores gráficos, un texto de desplazamiento de terminal a gran velocidad puede congelar la consola de la víctima (según mi experiencia, gnome-terminal y un administrador de ventanas de composición pueden convertirse en una mala combinación para eso).

Aún en xterm, hay secuencias para manipular el portapapeles (busque "manipular selección" en la página de referencia vinculada arriba). Esto puede ser desagradable, tanto para leer como para escribir. Consulte esta página para obtener una discusión sobre los posibles problemas (una lista de comentarios de seguimiento de problemas). , de personas que discuten la posibilidad de importar ese mecanismo en un emulador de terminal llamado mintty).

La conclusión general es: no SSH en hosts inseguros. Si lo hace, puede hacerlo desde rxvt-unicode , una bifurcación de rxvt donde el autor hizo (entre otras características) algún esfuerzo para desactivar las secuencias de control "inseguras" de forma predeterminada (se pueden recuperar con el parámetro de línea de comando "-insecure").

    
respondido por el Tom Leek 28.06.2013 - 18:08
fuente

Lea otras preguntas en las etiquetas