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.
"Siii amo se puede tener una maquina dentro de una maquina...¿que dice? que si dentro de esa se puede otra?? conecte mas potencia a esta patata y probamos a hacer una MAQUICEPTION cenutrio! ... ."
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.
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:
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:
"Bien... amo es un linux... no la patata calentorra que tiene usted con WINDOWS... que dice?? que le actualice al 10?? esta usted de broma no?? que se lo ha pedido la maquina?? compruebe que no pida que usted se suicide jijijijij"
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:
"mire amo... este programa es la cosa mas malvada jamas vista! permite atacar todo tipo de dispositivos! ... no la verja del redil de ovejas del aldeano no... So guarro! bueno... quien sabe si este hombre tiene mas luces que usted (cosa fácil...)... ya miraremos por shodan... a ver si vemos algún PLC"
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.
"no no y no no me pegue! no quiero bromas con algo llamado "finger" ... ya que por mi ese suyo se lo puede meter por .... donde se rompen los sacos..."
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.
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:
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:
"si yo tuviera permisos administrador.... ai amo... que seria de usted... 1º le arrearia con patas de silla en los deditos pequeños de los pies... 2º con los bordes de una mesa en los codos...MIERDA! me ha oido... trae un bate de beisbol!!!! ehh amo no era para usted... ehhhh era para..... ayyyy ayyyy!"
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)
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 :
Generamos con
ssh-keygen una clave RSA para nuestro usuario VULNIX que nos permitira autenticarnos en la maquina original.
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:
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.
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
|
Estando dentro de la maquina accedemos a la carpeta donde se aloja Bash y la ejecutamos con el comando -p para que nos coja las credenciales RSA que hemos creado dentro de la carpeta compartida:
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.
"Amo tenemos el trofeo pero creo que no le va a gustar... es algo mas feo que su jeto.... jijijij y es decir eh... fiese de mi que desde que rompió el ultimo espejo al mirarse... no no me castigue dentro del armario colgado de los meñiques! maldito humano de seso liviano! "
FINAL!
CONCLUSIÓN
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
