De la mano de los españoles J.J.F./Hackers Team, autodenominados como "grupo de hackers blancos", nos llega este nuevo aviso de seguridad. Afecta a los sistemas Unix que tengan instalados sshd2 versión 2.0.11 con las opciones por defecto, las cuales permiten, sin dejar ningún rastro, un ataque por fuerza bruta.
Ssh (Secure Shell) es un programa de login remoto que viene a reemplazar a rlogin, rsh y rpc, permitiendo la comunicación con otra máquina para administrarla remotamente, ejecutar comandos, transferir ficheros, etc. En todo momento, Ssh, utiliza métodos
de cifrado (RSA, IDEA, triple-DES, DES, Blowfish,...) para proveer autentificación y comunicaciones seguras a través de canales inseguros, como puede ser Internet.
En el aviso de J.J.F./Hackers Team describen como "en la instalacion por defecto del sshd2 (hasta la version 2.0.11), se deja una puerta libre a un ataque de brute force sin loguear la ip atacante por parte del sshd. A partir de la versión 2.0.12 ya se loguea la conexión."
Prosiguen explicando como se puede llevar acabo el proceso evitando en todo momento el que se registre la IP del atacante: "el demonio sshd al conectar con un cliente ssh tiene un numero definido de intentos para que le envíen la password correcta antes de desconectar. En la instalación por defecto este numero de intentos es 3. Si antes de agotar los intentos rompemos la conexión, el sshd no logueara los intentos de conexión, y es mas, tampoco logueará la ip del cliente que conecto con el demonio."
Por último, recomiendan actualizarse a la versión 2.0.12 o superior, donde se corrige este problema. También proporcionan la solución en la versión afectada, que pasa por "editar el fichero sshd2_config (normalmente en /etc/ssh2) ajustar el campo PasswordGuesses con el valor 1. De este modo cada vez que se intente una password y se falle el sistema logueara via syslog".
Más información:
J.J.F./Hackers Team
SSH Communications Security
Veamos un ejemplo:Supongamos que el usuario alfonso NO existe en la máquina 192.168.0.1, pues bien, podríamos saberlo simplemente tratando de conectarnos a la máquina vía ssh utilizando el nombre de usuario alfonso. Después de esto, cuando introduzcamos la password, nos dirá que no es la correcta y nos desconectará inmediatamente sin darnos opción a intentarlo de nuevo con otra password. Algo así:
$ssh 192.168.0.1 -l alfonso
alfonso's password: <>
Disconnected; authentication error
(Authentication method disabled.
Sin embargo, después de ver que alfonso NO es un usuario autorizado en la máquina, podemos tratar de probar suerte con otras posibilidades para el nombre de usuario, como por ejemplo altellez. Algo así:
$ssh 192.168.0.1 -l altellez
altellez's password: <>
altellez's password:
En este momento, se dispone de un nombre de usuario correcto. Esto supone una grave vulnerabilidad, que podría ser explotada por un atacante remoto para generar un ataque de diccionario.
La solución más rápida para el bug, y que curiosamente también resuelve el bug anunciado por J.J.F./Hackers Team es, simplemente, editar el fichero de configuración del servidor de SSH (habitualmente el sshd2_config, en /etc/ssh2) y cambiar el valor de "PasswordGuesses" a 1.
No hay comentarios:
Publicar un comentario