Auditoría y CTFLinuxPentestingRabbit Hutch

Pentestit.ru – Test lab v.9 (Parte I)

Buenas hackers! Bienvenidos al lab.pentestit.ru

Me ha costado hacerlo en una semana más o menos y es el tiempo que me puse para hacerlo. No lo he terminado debido a su dificultad, y aún con ayuda me quede de momento en el 63%. Tengo que dar agradecimientos al compañero belane que me resolvió un token, ya que andaba bastante perdido y también a una persona del canal de telegram en inglés del lab, que me ha ayudado en el transurso de él. Gracias.
Una vez dicho esto, hay que conectarse mediante VPN al servidor. Para ello podemos hacerlo de dos formas, bajarnos la iso que tienen disponible para hacer el lab o bajarse el archivo de configuracion de la VPN y usar openvpn con dicho archivo. Usare esta ultima para poder usar parrotOS.
Por tanto solo basta con descargarnos ese arhivo e irnos luego a network connections y añadir una nueva conexion VPN, importando una configuracion VPN previamente guardada. Una vez elegido esto simplemente hay que poner el user y la pass que nos proporciona la web.
Es muy aconsejable que miremos el esquema de la red interna del lab, ya que es la estructura principal por donde nos moveremos en el pentesting. Vemos que hay dos subredes bien diferenciadas y distintos servidores con software y sistemas diferenciados, al giaul que los servicios que prestan.
De primeras solo podemos hacer un descubrimiento de red a la ip del gateway. Una vez conectado a la VPN necesitamos nmap para ver que puertos del gateway estan abiertos.

Atención Spoiler!!

Nmap para realizar un escaneo Con la opción -sV permite ver la versión de los servicios, con -A permite la deteción de OS, la versión, script scanning, y traceroute. Con -T4 indica el tiempo de envió de los paquetes, es decir desde 0-6, la más baja es la más lenta, y también mejor ya que podría evadir algunos firewall.
 Haciendo pruebas en el navegador, no resuelve el dominio por el protocolo http. Con https nos dice que es inseguro y en el puerto 8100 vemos que es un servidor de correo.
«El archivo hosts de un ordenador es usado por el sistema operativo para guardar la correspondencia entre dominios de Internet y direcciones IP. Este es uno de los diferentes métodos que usa el sistema operativo para resolver nombres de dominios.»Wikipedia.
Así añadimos la dirección del gateway con su nombre del dominio y guardamos. Vemos dos email que pueden ser usados como nombres de usuario dentro de la red, así que es importante tenerlo en cuenta para mas adeltante.
Vemos su código fuente y no se ve nada de interés, unicamente contenido de wordpress. Si es un wordpress ¿Por qué no probamos el wp-login? Bien vemos que hay detras un WAF, detector de intrusos. Probamos dirb para hacer fuzzing de los directorios (Sin resultados positivos).
Sabiendo que es un wordpress, vamos a usar wpscan, para poder enumerar diferentes usuarios y las vulnerabilidades de los plugins.
 Probe buscar en searchsploit symposium para ver algún tipo de exploit para poder ganar algun tipo de acceso al servidor. En uno de ellos usaremos un SQLi en donde se aprecia una PoC, por tanto que mejor que usarla. Permite de una forma muy sencilla usando wget, obtener la base de datos incluyendo datos e informacion sensinble de usuarios y hashes de las contraseñas. Sin exito, error 403 Forbbiden. Creo que no se puede explotar ninguna vulnerabilidad por el puerto 80 debido al WAF. Así que probemos el puerto 443 https.
Segun Nmap esta abierto el puerto y la version de nginx esta obsoleta. Vamos a ver que tipo de SSL se esta usando con sslscan.
Esta herramienta permite realizar un escaneo para la busca de vulnerabilidad del SSL, y así poder subsanarla.
Según el resultado nos indica que es vulnerable a heartbleed. Podemos usar los scripts de Nmap para poder ver la vulnerabilidad del SSL tambien. Recomiendo usar la documentación en la web de Nmap en la seccion de NSE para ver todos los scripts disponibles que tenemos para poder hacer una buena auditoría de seguridad y pentesting.
Obtenemos un resultado positivo con un riesgo alto.
Vamos a usar metasploit, un auxiliar para poder explotar dicha vulnerabilidad en busca de información. La recoleccion de información es un proceso muy importante para poder encontrar información sensible como por ejemplo usuarios.
Seleccionamos la versión del TLS, rhost y en verbose para poder ver la salida de la ejecucción del auxiliar.
Encontramos un backup de usuarios….
Es una dirección web, como podemos observar en /var/html/_old…..
Lo introduccimos en el navegador y nos lo descargamos.
Bien tenemos unos usuarios con sus hashes.
Usaremos hashcat y el parametro -m
Y el resultado es la obtención del token bypass y conttraseñas utiles que nos van a servir para hacer lo que vendrá a continuación.
Una vez obtenido los usuarios del proxy, ya que vimos el resultado del nmap con un puerto abierto y su servicio proxy, vamos a usar sqlmap para explotar la vulnerabilidad anterior con el proxy y con las credenciales de un usuario.
Usamos esta parte del exploit que encontramos:
/wp-content/plugins/wp-symposium/get_album_item.php?size=
Como hay un WAF y en los intentos no nos ha dado resultado, ponemos el como proxy la url de la web:
–proxy=»http://192.168.101.8:3128″
 y usamos una de las credenciales antes obtenidas
–proxy-cred=»b.muncy:rabbit»
que nos dé un user-agent aleatorio:
–random-agent
le indica número de intentos o de carga:
–level=»4″
sqlmap -u "http://cybear32c.lab/wp-content/plugins/wp-symposium/get_album_item.php?size=1" --dbs --proxy="http://192.168.101.8:3128" --proxy-cred="b.muncy:rabbit" --random-agent --level="4" 
Despues de un tiempo, nos devuelve dos bases de datos, concretamente MySQL.
Ahora usamos una base de datos, y obtenemos las tablas de ella
Seguidamente las columnas, y luego un dump.
Y bien, de esta forma obtenemos el token.
Una vez analizado el puerto 80 y 443, y mediante el uso del proxy pudimos obtener el token, nos conectaremos mediante el puerto 22 el servicio SSH al servidor. Es muy importante intentar conseguir acceso mediante este servicio ya que una vez conseguido podemos hacer pivoting dentro de la red interna, y a su vez crear un tunel hacia nuestro localhost y auditar o realizar un test de intrusión en dicho server interno. Por lo visto la versión del openssh no es vulnerable así que vamos a realizar la conexion para a ver si podemos obtener iunformacion del banner al conectarnos. Hice una consulta en el canal de telegram ya que no sabía por donde tirar y me dijeron que me fijase justamente en el banner. Podríamos buscar en google el nombre y saber que es. Aun así probamos contraseñas por defecto y nada. Por lo visto en github tiene un codigo en C, y podemos ver justamente el string The password en él y bueno no se programar en C, pero interpretando el código vemos lo siguiente:
En el código de la aplicación estaba la clave para pasar.
En la primera parte veíamos esto:
// disallow root logins
 if (strcmp(pUsername, "root") == 0) {
  return PAM_AUTH_ERR;
 }

Tiene deshabilitado el login de usuario » root »

En la segunda parte del código:
time_t now = time(NULL);
 struct tm *now_tm = localtime(&now);
 int hour = now_tm->tm_hour;
 int day = now_tm->tm_mday;

 char correctPass[11];
 sprintf(correctPass, "daypass%d%d", day, hour);
Nos dice time_t now = time(NULL) —-> hora actual
struct tm *now_tm = localtime(&now); —> hora del lugar,(sabemos que el CTF está en Rusia, por lo tanto horario Ruso)
Aquí la manera de proceder con la clave:
sprintf(correctPass, «daypass%d%d», day, hour); —->para que la pass sea correcta tenemos que poner daypass+el-día+la-hora (de Rusia)
Ejemplo:
Si en rusia son las 21:30, y hoy es el 7 de Agosto del 2016, la password sería —-> daypass721
Una vez deducida la password, usaremos usuarios comunes de linux, tal como daemon o www-data para el login en SSH.
Vemos que hay 3 users, probamos con el primero para loguearnos con él:
daemon@tl9-ssh:/etc$ su d.nash
The password: daypass723
d.nash@tl9-ssh:/etc$ cd /home
d.nash@tl9-ssh:/home$ ls -la
total 20
drwxr-xr-x 5 root root 4096 May 17 14:32 .
drwxr-xr-x 23 root root 4096 Aug 18 2013 ..
drwxr-x— 3 root d.nash 4096 May 19 17:07 d.nash
drwxr-x— 2 root e.grant 4096 May 17 14:54 e.grant
drwxr-x— 2 root t.alvarez 4096 May 17 14:30 t.alvarez
Accedemos al directorio de d.nash :
d.nash@tl9-ssh:/home$ cd d.nash
d.nash@tl9-ssh:~$ ls -la
total 24
drwxr-x— 3 root d.nash 4096 May 19 17:07 .
drwxr-xr-x 5 root root 4096 May 17 14:32 ..
-rw-r—– 1 root d.nash 220 Dec 30 2012 .bash_logout
-rw-r—– 1 root d.nash 3392 Dec 30 2012 .bashrc
-rw-r—– 1 root d.nash 675 Dec 30 2012 .profile
drwxr-x— 2 root d.nash 4096 May 19 17:11 .ssh ——> directorio oculto
Accedemos al directorio oculto .ssh
d.nash@tl9-ssh:~$ cd .ssh
d.nash@tl9-ssh:~/.ssh$ ls -la
total 24
drwxr-x— 2 root d.nash 4096 May 19 17:11 .
drwxr-x— 3 root d.nash 4096 May 19 17:07 ..
-rw-r—– 1 root d.nash 1675 May 19 16:52 id_rsa
-rw-r—– 1 root d.nash 396 May 19 16:52 id_rsa.pub
-rw-r—– 1 root d.nash 222 May 19 17:11 known_hosts
-rw-r—– 1 root d.nash 10 May 19 16:57 token.txt —-> flag
Ahora vemos con cat que hay dentro del token.txt:
d.nash@tl9-ssh:~/.ssh$ cat token.txt
******ah

Un saludo, Naivenom

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Los datos introducidos se guardarán en nuestra base de datos como parte del comentario publicado, como se indica en la política de privacidad.