Daniel Vigueras

Cuando un atacante explota un fallo en un servidor y logra acceso, lo primero que suele hacer es cubrir sus huellas mediante la instalación de un rootkit. Esto puede implicar modificar binarios o librerías del sistema con versiones creadas especialmente para el caso; por ejemplo se podría sustituir el binario /bin/ls del sistema con una versión que no mostrase los ficheros que empiecen por una cadena en especial, así el atacante podría dejar ficheros en el sistema cuyo nombre comenzasen por esa cadena y nadie más podría ver que existen usando el comando ls.

Aunque existen mecanismos más complejos y eficientes para ocultar ficheros en el sistema (como por ejemplo modificando la syscall table del kernel con una versión alternativa de una llamada al sistema), este método es bastante común. El problema radica en que el administrador no se ha dado cuenta de que un binario ha sido reemplazado por una versión alternativa troyanizada, si tuviera algún método de realizar una comprobación automática podría detectar a tiempo este tipo de intrusiones.

Para conseguir detectar estas modificaciones de forma automática existe una estupenda herramienta denominada Tripwire, que genera una base de datos con un hash digital de los ficheros del sistema. Lo ideal es generar esta base de datos con el sistema recien instalado, antes de conectarlo a la red, así estaremos seguros de que está totalmente limpio. Una vez generada la base de datos podremos realizar chequeos periódicos de forma automática añadiendolo en el crontab, pudiendo configurar el software para que envíe un email al administrador en caso de detectar modificaciones en algún fichero.

Normalmente en los procesos de autenticación interviene lo que denomicamos un único factor, entendiendo como factor cualquier método de autenticación en el sistema, como podría ser una contraseña, un código PIN, una huella dactilar, una secuencia de ADN… Sin embargo si queremos que este proceso de autenticación en el sistema sea más robusto lo ideal es hacer que intervengan dos factores (tres sería mejor, pero el proceso sería demasiado tedioso) siendo a esto a lo que denominamos autenticación multifactor.

Al comienzo de este artículo se puede ver la imágen de un RSA SecurID, un pequeño aparato con forma de llavero que únicamente posee una pantalla LCD en la cual es muestra un número, lo primero de todo hay que destacar que este aparato no posee ningún método de comunicación con el exterior, ni puerto USB, ni Wi-Fi, ni bluetooth, ni infrarrojos ni nada parecido, funciona aislado del mundo exterior. Cada 30 segundos el número que aparece en pantalla cambia por otro generado aleatoriamente, es decir, incorpora un generador de números pseudoaleatorios en su interior y una semilla que permite que esta secuencia sea diferente en cada SecurID. Esta semilla también está almacenada en el servidor de autenticación y por tanto haciendo una serie de cálculos rápidos puede saber en cada momento que número muestra nuestro aparato por pantalla.

Cuando vamos a autenticarnos en el sistema introducimos nuestro nombre de usuario y un número PIN que sólo nosotros conocemos seguido del número que aparezca en ese mismo instante en la pantalla del SecurID, a continuación si esta primera fase de autenticación se realiza correctamente el sistema procede a solicitarnos nuestra contraseña de usuario para acceder al sistema.

¿ Por qué ganamos seguridad usando este sistema ? Sencillamente porque si usamos un método tradicional de usuario y contraseña un atacante que por fuerza bruta logre adivinar la contraseña tendrá acceso al sistema, sin embargo con este método si el atacante conoce el nombre de usuario y contraseña no concerá ni el PIN necesario ni tendrá el RSA SecurID en su posesión para ver el número que aparece en pantalla. El caso de que el usuario pierda el RSA SecurID tampoco es problema ya que un atacante no conocerá el PIN necesario aunque pueda ver en pantalla el número que aparece en el momento de la autenticación.

Este tipo de medidas se han de tomar debido a que no podemos dejar que toda la seguridad asociada al proceso de autenticación recaiga en el usuario del sistema ya que se convertiría en la mayor brecha potencial.