miércoles, 10 de febrero de 2010

Algunos artículos

Se pueden encontrar algunas notricias sobre SSH en el siguiente link:

http://www.openbsd.org/openssh/es/press.html

Seguridad en OpenSSH

Seguridad en OpenSSH:

  • OpenSSH eliminó el soporte para RC4 porque se usaba de forma incorrecta en SSH 1 y lo hacía vulnerable a los ataques password cracking, replay o modification sobre el cifrado RC4.
  • No era vulnerable a los ataques a clientes de reenvío en conexiones no cifradas porque este soporte se eliminó del proyecto desde el principio.
  • Puesto que no hay soporte para el algoritmo IDEA no era vulnerable a los ataques en el último paquete de éste cifrado. El estado de la patente de IDEA hace que su inclusión en OpenSSh sea inapropiada.
  • Para OpenSSH el anfitrión local no está exento de la verificación de claves, por lo que no es vulnerable al ataque de circunvalación de la autenticación de la clave anfitriona.
  • Tampoco era vulnerable a los ataques de reenvío en X11 incontrolable porque está desactivado de forma predefinida y el usuario puede denegar el permiso.
  • OpenSSH está afectado por la deficiencia del protocolo SSH 1, en la que un ataque de inserción sería difícil pero posible, El mecanismo de desataque de CORE-SDI se usa para eliminar el caso común. Se sigue investigando cómo resolverlo, porque el protocolo sigue en uso.
  • En las versiones de OpenSSH 2.1.0 y posteriores no se permiten que un atacante remoto ejecute órdenes de forma arbitraria con los privilegios de SSHD si UseLogin está activado por el administrador.
    OpenSSH 2.3.0 y versiones posteriores no permiten que servidores maliciosos accedan a ssh-agent o al X11 del cliente.
  • En las versiones de OpenSSH 2.9.9 y posteriores no se permite que los usuarios borren ficheros con el nombre de "cookies" si se encuentra activado el reenvío por X11, éste se encuentra desactivado de forma predeterminda. En estas versiones tampoco hay vulnerabilidad a la alerta de seguridad de OpenSSh del 26 de septiembre de 2001: "vulnerabilidad en el código fuente de control de acceso basado en IP para la autenticación de clave pública del protocolo v2 de SSH de OpenSSH".
  • Para las versiones de 3.0.2 de OpenSSh y posteriroes no se permite que un usuario pase variables de entorno a login(1) cuando UseLogin está activado. Dicha opción está desactivada de forma predeterminada en todas las versiones.
  • OpenSSh 3.1 y posteriores no hay vulnerabilidad a la alerta de seguridad de OpenSSH del 7 de marzo de 2002: "March 7, 2002: error Off-by-one en el código del canal".
  • La versión portable de OpenSSh 3.7.1p2 y posteriores no son vulnerables a la alerta de seguridad de OpenSSH del 23 de septiembre de 2003: "portable OpenSSH Multiple PAM vulnerabilities".

miércoles, 3 de febrero de 2010

Vulnerabilidades SSH

Aunque el protocolo SSH ha sido diseñado como ya hemos comentado, para proporcionar un canal seguro de comunicación entre un usuario y un host remoto, se han descubierto la existendia de diversos problemas de seguridad en varias de sus implementaciones. Algunas de estas vulnerabilidades pueden ser utilizadas principalmente para la ejecución de código arbitrario con los privilegios del proceso SSH y afectar indistintamente tanto a un servidor como a un cliente SSH.

Estas vulnerabilidades se encuentran en el código responsable de la inicialización de las comunicaciones y en el intercambio de claves. Se centran en un tratamiento incorrecto de paquetes que tienen diversos campos con una longitud no válida, vacíos o bien con cadenas de tecxto a NULL.

Las implementaciones de SSH susceptibles de ser vulnerables son:
  • Pragma Systems (Pragma SecureShell 2.0)
  • PuTTY (versiones anteriores a la 0.53b)
  • F-Secure para Windows (versiones anteriores a la 5.2)
  • SSH para Windows y Unix (versiones anteriores a la 3.2.2)
  • FiSSH 1.0A y anteriores
  • SecureNetTerm v5.4.1 y anteriores
  • ShellGuard 3.4.6 y anteriores
  • WinSCP v2.0 y anteriores

Rapid7 ha publicado un banco de pruebas, denominado SSHredder, que permite comprobar si una implementación es vulnerable a los ataques. Se trata de diversos paquetes que deben enviarse al cliente o servidor SSH, utilizando netcat o una herramienta equivalente.

Otros dos agujeros del protocolo han sido descubiertos por un grupo de científicos de la universidad de California. El primero de ellos está relacionado con el bloqueo de las cifras. El sistema actual permite adivinar a un hacker si un conjunto de datos consta de más de siete caracteres. Ésto, no es suficiente para que el pirata ataque al sistema pero puede ayudarle a calcular la longitud aproximada del password.

El segundo agujero de seguridad está relacionado con el tiempo transcurrido entre dos pulsaciones de teclado consecutivas mientras se escribe la contraseña, ya que puede revelar información muy importante. Cada carácter que el usuario pulsa en el teclado se envía inmediantamente a un servidor remoto en paquetes IP independientes. Según los investigadores, este hecho deja al descubierto información sobre la contraseña utilizada.

Con los resultados obtenidos, los científicos realizaron un sistema de ataque denominado Herbivore, que demostraba la posibilidad de conocer las contraseñas de los usuario vigilando sesiones bajo protocolo SSH. Además, advierten que recogiendo la información de la sincronización en la red, Hervibore puede aumentar la velocidad de una búsqueda exhaustiva de la contraseña en un 50%. Cabe destacar que estos resultados no sólo son aplicables a SSH sino que se extienden en general a todos los protocolos de encriptación.