Esta es la última entrada del ciclo de Entrenando con Metasploitable, y como de costumbre vamos a dar otra vuelta de tuerca. Empezaremos vulnerando Postgres con un ataque de diccionario gracia a un módulo de Metasploit, para obtener el archivo /etc/passwd y la clave rsa almacenada en /root/.ssh/authorized_keys. Finalmente veremos otra manera de explotar la aplicación web tikiwiki de una manera más automatizada desde Metasploit.
Comenzamos!!
Vulnerando Postgres con Metasploit
PostgreSQL es un sistema de gestión de base de datos relacional orientada a objetos y libre (como la versión no comercial de MySQL), publicado bajo la licencia BSD, y postgres es el nombre del servicio que utilizamos para controlar la base de datos de PostgreSQL.
Arrancamos como de costumbre Metasploit con el comando msfconsole y buscamos modulos de Metasploit relacionados con Postgres con search postgres
En nuestro caso seleccionaremos auxiliary/scanner/postgres/postgres_login y mostraremos sus opciones:
use auxiliary/scanner/postgres/postgres_login show options
Tenemos que cambiar RHOSTS e indicar la ip de nuestro Metasploitable, en mi caso 192.168.0.2, pero además podemos cambiar las siguientes opciones:
- PASS_FILE: nos permite indicar cual es el archivo de contraseñas
- USER_FILE: nos permite indicar cual es el archivo de nombres de usuario
- USERPASS_FILE: nos permite indicar cual es el archivo de nombres de usuario – contraseñas
- STOP_ON_SUCESS: si marcamos esta opción el nos permite indicar cual es el archivo de contraseñas
- RPORT: podemos cambiar el puerto en el que está corriendo postgres si nuestra víctima no lo tiene en un puerto estandar
Ahora lanzamos el módulo con exploit y si todo va bien deberiamos ver algo así:
¿Porque pasa esto? Ocurre por no cambiar las credenciales por defecto de las aplicaciones, si administras un sistema, por favor cambia los datos de acceso por defecto y además en este caso habría venido bien borrar la base de datos de ejemplo template1
Bien, ya conocemos las credenciales de acceso a postgres, ya solo falta loguearnos desde Metasploit con:
psql -h 192.168.0.2 -p 5432 -U postgres -W
Ahora aprovecharemos que ya estamos en postgres (y que el usuario/grupo postgres puede acceder a /root ) para obtener el archivo que contiene la clave pública de SSH.
Claves ssh que no son todo lo aleatorias que debieran
Una vez hemos llegado a este punto podemos ejecutar las siguientes consultas, para aprovechando que postgres no tiene restricción de permisos acceder a /root/.ssh/authorized_keys:
create table clavessh (input TEXT); copy clavessh from '/root/.ssh/authorized_keys'; select input from clavessh;
Y el resultado será algo parecido a esto:
Bueno pensarás…esta simplemente es la clave pública del ssh, lo cual es cierto. Pero en ciertas versiones de Debian (y en el resto de distribuciones basadas en Debian) concretamente entre septiembre de 2006 y mayo de 2008 la manera de generar las claves públicas no era todo lo aleatoria que debiera. Es decir, utilizaban el número de proceso para generar la clave, lo cual nos reduce bastante el numero, concretamente a 65536 parejas de clave pública-privada.
Ha habido gente que se ha dedicado a generar las 65536 claves…guardando la relación entre las 2 claves (pública y privada) así que si contrastamos la clave que hemos obtenido con las 65536, obtendremos la clave privada sin más esfuerzo:
Descomprimimos el archivo y dentro de rsa/2048/ hacemos lo siguiente para comparar la clave:
grep -lr [la clave que hemos obtenido anteriormente] *.pub
Pues esto ya está hecho solo nos queda conectarnos, en nuestro caso con:
ssh -i 57c3115d77c56390332dc5c49978627a-5429 root@192.168.0.2
Ya estamos dentro de una shell root, gracias a dicha vulnerabilidad:
Pues eso es todo amigos, aquí termina la serie de entradas de Metasploitable, espero que os haya servido para algo y que os hayais concienciado el porque no mantener los datos por defecto en las aplicaciones (y más si tienen salida a internet)
Happy training 