Articulo tomado de la página Iacix, y autorizado por el admin de la misma. Todos los derechos reservados a dicha web. Buenos comentarios en esta web, quejas en Iacix, jajaja (es broma).
Una de las responsabilidades de los administradores de sistemas es limitar el acceso a aquellos usuarios con autorización para entrar en el mismo. Con el fin de bloquear el acceso a terceros se crearon las contraseñas. Cada usuario posee un ‘nombre de usuario’ y una contraseña. Cada vez que un usuario quiere acceder al sistema se le piden dichos datos. Si el nombre de usuario y la contraseña coinciden con los almacenados en el servidor le permitimos el acceso, si no, se lo denegamos.
Uno de los problemas de este sistema surge cuando una tercera persona se hace pasar por uno de nuestros usuarios. Siempre y cuando conozca el nombre de usuario y su password se le permitirá el acceso, independientemente de que la persona no sea quien dice ser.
Otro problema es que si el acceso a sido denegado, el usuario puede volver a intentar acceso n numero de veces (normalmente n es infinito). Por lo general, limitar el número de intentos puede bloquearnos el acceso, haciendo del remedio peor que la enfermedad.
Un ataque muy común que se hace uso de dichas ‘vulnerabilidades’ son los ‘ataques basados en diccionarios’ (dictionary-based attack). El ataque consiste en bombardear al servidor con nombres de usuarios y contraseñas aleatorios. Es algo parecido a intentar abrir una caja fuerte introduciendo números al azar. Si alguna vez te has encargado de algún servidor ssh o ftp seguramente los hayas sufrido.
Ya que el número de posibles combinaciones de usuarios y passwords posibles es demasiado alto, en este tipo de ataque normalmente se usan diccionarios. Un diccionario (de passwords y/o usuarios) es un fichero de texto con nombres de usuario y passwords frecuentemente usados. Por ejemplo, en la mayor parte de sistemas nos solemos encontrar un usuario ‘root‘, y, estadísticamente hablando, passwords como ‘1234‘ o ‘qwerty‘ son usadas mas frecuentemente que ‘a\/gW1~3|23‘. Como te podrás imaginar, para diferentes idiomas se usan diferentes diccionarios.
Pero entonces…? SI!, La única manera de que este ataque funcione es que la combinación usuario-password este en tu diccionario, o en otras palabras, una mala gestión de usuarios/passwords.
El motivo por el que este tipo de ataques están tan extendidos es porque con un simple script podemos testear cientos o miles de servidores de forma automática sin necesidad de intervenir en el proceso. Otro motivo es que los ‘chicos malos’ necesitan ordenadores desde los que realizar sus ataques.
En un ataque real conseguir acceso al sistema es solo el primer paso. Una vez dentro se suele instalar como mínimo algún troyano con el cual garantizar el acceso en caso de que se cambie la password. Hay ocasiones en el que el atacante simplemente cambia la password para levantar sospecha y darle a conocer al usuario que su password es débil.
En este video tutorial os muestro un ejemplo práctico de cómo realizar este tipo de ataques y por supuesto como detectar su presencia.
Detalles técnicos
- La distro usada para realizar el ataque es Backtrack 2, versión Live.
- Para escanear la red y localizar posibles víctimas se uso nmap.
- Para el ataque en si utilizamos medusa (~# man medusa).
- El diccionario usado pertenece a ‘john the ripper‘ (Incluido por defecto en Backtrack 2).
- El servidor de ssh en la víctima es una instalación estándar de OpenSSH.
Ver video tutorial
Pulsa aquí o sobre la imagen para acceder al vídeo tutorial.
Detección y prevención
La mejor forma de detectar este y cualquier tipo de ataque es comprobando los logs y analizando cualquier anomalía. En su día escribí un post llamado ‘Navegando entre los logs’ donde hable de cómo el servidor en el que se encuentra alojado esta web, Fujiyama, estaba en constante estado de alerta.
En ‘Consejos básicos: Mantener un servidor del ssh’ menciono las practicas mas habituales para evitar este tipo de ataques sobre servidores de ssh. En esa época decidí cambiar el puerto de escucha del servidor de ssh y desde entonces no he recibido ningún ataque en los dos últimos meses.
