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.

viernes, 29 de enero de 2010

Demostración

A continuación se muestran dos videos demostrativos sobre el uso de este protocolo, uno de ellos orientado a linux y el otro a windows:



domingo, 24 de enero de 2010

Características del protocolo SSH (II)

La otra característica que presenta el protocolo SSH es la transferencia de ficheros mediante SCP. SCP es un programa que permite la transferencia de archivos a través del canal seguro establecido en una sesión SSH previa al envío. Se trata de una alternativa muy buena a programas como la copia de archivos en máquinas UNIX, o el inseguro rcp.
Su sintaxis es la siguiente:
$ scp nombre_fichero_origen nombre_fichero_destino
De este modo, el archivo local se copia en el host remoto con el nombre indicado en el fichero destino. Si no se indica el directorio, scp por defecto lo copia en el directorio local.

jueves, 21 de enero de 2010

Características del protocolo SSH

Las principales características del protocolo SSH son:
  • Redireccionamiento de puertos (Port-Forwarding)
  • Transferencia de ficheros mediante SCP

Hoy haremos una breve introducción teórica sobre la primera de ellas. El redireccionamiento de puertos consiste en una forma de guiar tráfico TCP inseguro sobre el protocolo seguro SSH. Cuando se inicia una sesión SSH, puede hacerse que ciertas aplicaciones pasen por un túnel encriptado.

El establecimiento de un canal SSH seguro, sólo permite ejecutar conexiones TCP, que son las que están orientadas a conexión. Al contrario que UDP, que está orientado a datagramas por lo que este sistema no funciona para servicios como DHCP, NFS, NEtBIOS etc...

Este redireccionamiento se consigue mediante el mapeo del puerto TCP del cliento con el puerto del servidor. Es decir, toda la información generada por la aplicación cliente se dirigirá por el puerto TCP de dicha aplicación hacia el servidor.

Algunas de las aplicaciones que permiten el redireccionamiento de puertos seguro mediante el ptrotocolo SSH son: HTTP, SMTP, HTTPS, POP, IMAP y FTP.
En la figura siguiente se muestra un esquema teórico del port-forwarding:



lunes, 18 de enero de 2010

ARQUITECTURA DEL PROTOCOLO

La arquitectura del protocolo está definida en el documento RFC4251, donde se pueden distinguir varias capas:

  1. Capa de transporte RFC4253: Gestiona el intercambio inicial de claves para la autenticación del servidor, configura el cifrado, la comprensión, la integridad y la verificación. Transmite a su capa superior inmediata un interfaz para el envío y receptión de paquetes de texto plano de unos 33kB cada uno pudiendo aumentar dicha cifra al implementar el protocolo. La capa de transporte también llega a acuerdos para el intercambio de claves. Fases que se implementan en esta capa: autenticación del servidor (RSA,DSA); gestión de intercambio de clave inicial (Diffie-Hellman); negociación de algoritmos (encriptado simétrico); compresión de datos (opcional).
  2. Capa de autenticación de usuario RFC4252: En esta capa se gestiona la autenticación del cliente proveyendo de varios métodos para ello. Cuando la petición de una contraseña se muestra, puede ser el cliente el que realiza la petición y no el servidor. El servidor únicamente responde a las peticiones de autenticación del cliente. Los métodos más usados de autenticación son: 1.- Autenticación por contraseña: donde el cliente accede al servidor mediante contraseña. Incluye facilidades para cambiar la contraseña y por tanto mantener la seguridad. No es un método implementado por todos los programas cliente de SSH. 2.- Clave pública: método que normalmente soporta el menos pares de claves cifradas mediante algoritmos RSA oDSA con otras implementaciones que permiten el soporte de certificados digitales. 3.- Teclado interactivo: el servidor envia uno o más mensajes para la adquisición de información, el cliente los muestra y envía la respuesta al servidor. Es una autenticación por contraseña en un único paso. Esta imlpementado en algunos servidores OpenSSH.
  3. Capa de conexión RFC4254: Finalmente en ésta se definen los canales. Una única conexión SSH puede alojar múltiples canales SSH simultáneamente, transdiriendo datos cada uno en ambas direcciones. Las peticiones de canal son usadas para la implementación de datos específicos. Puede ocurrir que la petición del cliente para redireccionar un puerto en el servidor remotor, por lo que los canales concluyen: 1.- Ejecución de Shell para terminales remotos que permitan comandos de SSH o envío de ficheros SCP. 2.- Redirección de conexiones TCP/IP para redirigir la información de aplicaciones entre cliente y servidor.
Esta arquitectura proporciona una considerable flexibilidad, permitiendo a los usuarios de SSH una gran variedad de utilidades sobre el propio protocolo. La capa de autenticación del cliente es muy extensa y soporta numerosos métodos de autenticación con distintas configuraciones. Por último la capa de conexión permite multiplexar varias sesiones en una única conexión.