Realizamos un pentest (prueba de penetración) a una máquina con sistema operativo Linux Ubuntu. Dicho equipo posee, a propósito, múltiples vulnerabilidades que pueden ser explotadas por un atacante. Explotaremos la vulnerabilidad de un servicio FTP, accediendo por SSH. Indicamos algunos métodos y consejos para mitigar estas vulnerabilidades FTP y SSH.

• Máquina virtual Linux Ubuntu diseñada para pentest.
• Requisitos para poder hacer el pentest.
• Iniciar pentest – Reconocimiento de red y escaneo de puertos abiertos.
• Explotar posible vulnerabilidad del puerto 21 FTP y 22 SSH.
• Mitigaciones, consejos de seguridad para evitar explotación de vulnerabilidad FTP y SSH.

Máquina virtual Linux Ubuntu diseñada para pentest

El equipo usado para el laboratorio de prueba de penetración (pentest) es un Linux Ubuntu 16.04.

Cuenta con un servicio web Apache y un sitio web accesible vía http (puerto 80):

En el test de penetración supondremos que no conocemos la dirección IP de esta máquina. Ni tampoco el sistema operativo. Mostraremos posibles métodos para obtener todos los datos posibles desde la red.

Requisitos para poder hacer el pentest

Necesitaremos disponer de un equipo con Kali Linux. Esta máquina se inicia en Live CD sin necesidad de instalar nada, como indicamos en este tutorial:

• Desplegar máquina virtual con Kali Linux – Hacking Ético Parte 1.

El equipo Kali debe estar en la misma red que el equipo al que le haremos el pentest. O bien, si no está en la misma red, al menos debe tener visibilidad con el equipo a realizar el ataque.

Iniciar pentest – Reconocimiento de red y escaneo de puertos abiertos

En primer lugar, realizaremos un reconocimiento de la red en busca de posibles dispositivos/equipos. Para ello usaremos una máquina virtual con Kali Linux, como hemos indicado en los requisitos. Accederemos a esta máquina mediante un cliente SSH (como PuTTY). Suponemos que la red donde está el equipo vulnerable es la 192.168.1.0 (la misma que tenemos para el equipo Kali Linux).

Usaremos el comando nmap de la máquina Kali Linux. Dado que aún no conocemos la IP del equipo vulnerable, con el siguiente comando escanearemos los dispositivos de la red, devolviéndonos los equipos activos:

Este primer escaneo es muy rápido, dado que únicamente escanea equipos activos y no puertos. Nos devolverá los posibles dispositivos de nuestra red activos:

Si detecta algún equipo/dispositivo activo, nos lo indicará con el siguiente mensaje, obteniendo su IP:

Nmap scan report for 192.168.1.1
Host is up (0.00070s latency).

Un ejemplo de salida de este comando:

Una vez obtenidos los equipos activos, podemos reducir la búsqueda y empezar ahora a hacer un análisis más profundo, de puertos abiertos. Podremos hacerlo para varias direcciones IP o bien para una única dirección IP. En este caso, para no alargar el tutorial, suponemos que la dirección IP a escanear es la 192.168.1.78. Para analizar los puertos de esta IP, usaremos el siguiente comando:

El resultado del escaneo lo habrá guardado en el fichero de texto puertos_78.txt. Una vez finalizada la ejecución del comando anterior. Hacemos un cat en el fichero para ver su contenido:

Y podemos observar que ha descubierto tres puertos abiertos, incluso nos devuelve (en algunos casos). Al haber añadido el parámetro -A al comando nmap, será más lento el escaneo pero puede obtener información valiosa para un posible atacante (software que abre el puerto, versiones, etc.). Para este caso, ha descubierto:

• Puerto 21: indica que podría tratarse de vsftpd 3.0.3. También obtiene que hay un posible acceso FTP de forma anónima. Incluso obtiene un listado de un par de ficheros que son visibles: id_rsa y notas.txt.
• Puerto 22: posiblemente se trate de OpenSSH 7.2p2 Ubuntu 4ubuntu2.10.
• Puerto 80: posiblemente Apache httpd 2.4.18, con fichero http-robots.txt.

No sabemos aún el sistema operativo del equipo susceptible de ser atacado, pero en la anterior información vemos que podría tratarse de un Linux Ubuntu (en el puerto 22 el comando nmap obtiene 22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.10 (Ubuntu Linux; protocol 2.0).

Vemos que podría tratarse de un equipo con Linux Ubuntu. Si hacemos un ping, nos obtiene un TTL de 64, por lo que refuerza el hecho de que podría ser un Linux :

Explotar posible vulnerabilidad del puerto 21 FTP y 22 SSH

Tras analizar los posibles puertos abiertos, como hemos indicado anteriormente, nos centraremos, en este caso, en el puerto 21 (FTP). Vamos a analizar este posible vector de ataque buscando posibles vulnerabilidades, para tratar de explotarlas.

En primer lugar, dado que nmap ha obtenido la versión del software servidor de FTP, en concreto vsftpd 3.0.3, haremos una verificación usando la herramienta msf de Kali Linux. Para ello ejecutaremos el comando:

Dentro de este comando, ejecutaremos estos otros comandos, para obtener más información sobre el puerto 21 y la aplicación que lo ha abierto:

Realizará el escaneo y obtendrá que la aplicación que abre el puerto 21 es vsFTPd 3.0.3:

Un atacante podría buscar información sobre exploits para esta versión. Por ejemplo, en la web exploit-db.com, nos indica que para esta versión hay un exploit para intento de denegación de servicio. Incluso nos muestra el script Python para explotarlo:

Aunque esta no es la forma de intrusión que explotaremos, es muy conveniente saber cómo los atacantes buscarán información, vulnerabilidades conocidas y posibles exploits para explotarlas, para las versiones de los aplicativos instalados que abren puertos. En muchos casos obtendrán toda la información, incluso scripts ya desarrollados para realizar la penetración.

Como msf también podríamos buscar vulnerabilidades conocidas para determinado software, con el comando search:

Seguimos investigando posibles vulnerabilidades en el puerto 21 de FTP. Como descubrió el comando nmap, hay acceso anónimo por FTP (en muchos servidores se permite este acceso anónimo) y, además, detectó dos ficheros que podrían ser un descuido de los desarrolladores o administradores del sistema.

Intentamos acceder por FTP, desde la máquina Kali Linux, con el comando:

Nos solicitará usuario y contraseña. El comando nmap descubrió que estaba activo el usuario «anonymous», sin contraseña, por lo que lo introduciremos para acceder. Una vez conectados por FTP, listaremos los posibles ficheros, con el comando:

Vemos que, efectivamente, hay dos ficheros:

id_rsa
notas.txt

Intentaremos descargar estos ficheros por si contienen información valiosa. A veces, por descuido o desconocimiento, o incluso a propósito (sin saber el alcance o el peligro) se dejan ficheros con información valiosa (para un posible atacante) accesibles desde la red. Para descargar los ficheros al equipo Kali Linux, activaremos el modo binario, con el comando:

Y ejecutaremos estos comandos para descargar los dos ficheros:

Una vez descargados, mostraremos su contenido con:

Comprobamos que el contenido es:

Usuario proyectoa

Esto puede no tener ningún valor o bien puede ser un mensaje para que las personas de la empresa que utilicen el FTP conecten con un posible usuario «proyectoa».

Seguimos investigando, mostraremos ahora el contenido del fichero id_rsa:

Y comprobamos que podría tratarse de una clave privada para acceso SSH. Con lo cual, podríamos tener un usuario «proyectoa» y una clave privada (private key) para un posible acceso SSH. Dado que anteriormente hemos comprobado con nmap que el equipo vulnerable tenía también el puerto SSH abierto, vamos a intentar conectar con por SSH con el usuario «proyectoa» y la clave privada descargada del FTP. Antes de conectar, cambiamos los permisos al fichero id_rsa, para poder usarlo en la conexión SSH:

Para ello ejecutaremos el siguiente comando:

En el comando anterior indicamos el fichero RSA con la clave privada, el nombre de usuario y la dirección IP del posible equipo vulnerable. Si la conexión es correcta, tendremos acceso a la shell del equipo. Podremos ejecutar comandos remotos, como por ejemplo:

O cualquier otro comando con los privilegios del usuario «proyectoa».

De esta forma, por un supuesto descuido de los administradores, hemos accedido al equipo de forma remota mediante SSH.

Mitigaciones, consejos de seguridad para evitar explotación de vulnerabilidad FTP y SSH

Para mitigar una posible vulnerabilidad mediante intrusión por FTP, estableceremos varias medidas. Como se ha comprobado, en el FTP había dos ficheros y, además, con acceso público sin usuario ni contraseña. Por ello, una medida es el evitar dejar servicios que abran puertos sin securizar. Menos aún servicios tipo FTP donde la información viaja sin cifrar.

Evitaremos el uso de FTP, que sustituiremos, en caso de ser estrictamente necesario, por SFTP (cifrado). Evitaremos usar accesos anónimos y usaremos contraseñas robustas. En este tipo de servicios, crearemos usuarios específicos para ellos que tengan todos los permisos limitados, evitando permitir usuarios tipo root para este acceso. De forma que si se explota alguna vulnerabilidad, el alcance sea limitado.

Evitaremos el uso de aplicaciones inseguras, con vulnerabilidades conocidas y evitaremos usar puestos estándar. Las aplicaciones que abren puertos deben estar actualizadas a la última versión, como en el caso de este tutorial, la aplicación vsFTPd.

Será conveniente también revisar los ficheros que se publican, que nunca contengan información sensible: usuarios, contraseñas, claves de certificados, claves privadas y cualquier otra información susceptible de ser usada por un atacante. Dejaremos públicos únicamente documentos bien revisados y anonimizados, y únicamente en caso estrictamente necesario.

Si se necesita disponer de un servicio SFTP, HTTP, SSH, etc., lo securizaremos al máximo, tanto desde el cortafuegos del equipo (limitando las IP que podrán acceder), como desde las propias aplicaciones (limitando los usuarios, obligando a usar contraseñas seguras, limitando los hosts de acceso, etc).

Formaremos y concienciaremos tanto a los usuarios como a los administradores sobre el uso de los equipos y las medidas de seguridad oportunas. Sobre el uso de contraseñas seguras (de fortaleza alta), sobre evitar dejar ficheros con claves (sean contraseñas o claves privadas de certificados) y cualquier otra información susceptible de ser usada por un atacante.

Se evitará permitir (por permisos del sistema operativo) a usuarios “normales” ejecutar comandos con sudo y, menos aún, sin contraseña y con privilegios de root.