Continuamos las entradas del blog aprovechando algunas de mis prácticas que realicé recientemente para una curso de seguridad y hacking ético.
En este caso concreto se trata de una de las máquina vulnerable Kioptrix, más concretamente al cuarto nivel, y antes de nada decir al igual que en las anteriores que no hay un "único camino bueno" y este es solo uno de los muchos que puedes seguir; pero siempre hay mas de un modo de "jugar" con estas máquina y sus vulnerabilidades...
Manos a la obra!! Una vez descargada la máquina virtual desde su propia web y arrancada la misma nos ponemos al lio!
Como siempre hacemos, analizamos en primera instancia con nMap los servicios y
versiones que ofrece la máquina, obteniendo como resultado que se trata de OS
Linux
Lanzamos un segundo escaneo más completo con nMap para obtener más
información sobre las versiones de los servicios que están corriendo en la
máquina.
Lanzamos un tercer escaneo con un script (smb-enum-users)que me ofrece
información sobre los usuarios de samba, puede sernos muy útil y es mas recopilación
de información
Podemos observar que, además de tratarse de un Linux 2.6, tiene un
servidor web Apache corriendo (http en el puerto 80) y decidimos acceder desde el
navegador a la dirección IP de la máquina; parece una ventana de LOGIN para
miembros ofrecido por "algo" llamado “LigGoat secure Login”
Utilizamos wfuzz para tratar de sacar más directorios
accesibles del servicio web. También utilizamos NIKTO para detectar posibles
vulnerabilidades del servicio Apache que está ejecutándose
De vuelta al navegador tratamos de probar nuestra “sentencia
mágica” (‘or ‘1’=’1) para ver si el portal de login es susceptible de SQLi.
Introducimos la sentencia tanto en el usuario solamente e inmediatamente nos dice
que el usuario no es válido, probamos suerte introduciendo la sentencia en el box
de la contraseña y al menos obtenemos un comportamiento distinto…
Interpretamos que si que acepta la contraseña “mágica” pero no así el usuario, de modo que
trato de usar el usuario root y los usuarios del sistema que nMap con el script
smb-enum-user nos ofreció (john, root, nobody, loneferret y robert). Tan solo
john y robert parecen tener acceso a esta web pues son los únicos password que
no dan error, y me muestra su contraseña en texto plano
Teniendo
estas dos credenciales me aventuro a tratar de probar el acceso al sistema con
ellas, y funciona!!!
Pero la
alegría dura poco en casa del pobre… se ha comido el pasword y parece habernos iniciado sesión por ssh pero no nos deja hacer absolutamente nada, no funciona
pwd, ni ls, ni id, y parece muy limitado
Investigamos un poco por la red y San Google nos ofrece algo sobre un comando que permite abrir una sesión
Bash en una terminal, se trata de ejecutar el comando “echo os.system(‘/bin/bash’)” probamos suerte y para nuestra sorpresa funciona y tenemos una sesión mas
completa que ahora SI nos permite movernos por todos los directorios y el sistema de archivos.
Hemos obtenido más libertad de movimiento pero los permisos
siguen siendo bastante escasos, por lo que investigo en busca de algún exploit
existente para el kernel Linux que tiene la máquina objetivo y, una vez más,
Exploit-db tiene la respuesta!
Al igual que con otra de las máquinas, el exploit debe ser
descargado desde la máquina víctima, por lo que volvemos a repetir lo que hicimos en
la Kioptrix 2 (“servir” el archivo desde mi propio KALI levantando el
servicio Apache).
A pesar de descargarlo en la carpeta “tmp” done el usuario que tenemos supuestamente puede hacer cosas y tiene permisos... desafortunadamente no termina de realizarse la descarga del
archivo sin un motivo aparente, es como si las maquinas no estuvieran en la
misma red o no se vieran entre ellas
Nos volvemos locos lanzando pings a la maquina objetivo desde
KALI, lanzando ping a KALI desde la maquina objetivo, comprobamos la
configuración de los adaptadores de red de las VMs pero no encontramos nada raro,
de modo que solo se nos ocurre comprobar si hay funcionando algún firewall o
algo que filtre el tráfico de red… y encuentro en la configuración de las
iptables que está bloqueando por el puerto 80.
Intento modificar el archivo pero, indudablemente mis escaso
permisos no me lo permiten
Nos encontramos bastante estancados en este punto, solo se nos ocurre buscar alternativas para utilizar cualquier otro puerto. Se nos ocurre
editar la configuración por defecto de apache2 en su directiva Listen para que Apache escuche
en el puerto 8000 en vez de por el 80.
Pruebo suerte de nuevo especificando en la sintaxis del
comando wget que la dirección debe dirigirla al puerto 8000… y funciona!!!!
Descomprimimos el fichero y entramos dentro del directorio
creado, allí abrimos el archivo run que según hemos podido leer por internet nos da las
instrucciones necesarias para la compilación ejecución del exploit
Lo compilo siguiendo las indicaciones para la arquitectura
de la máquina (i686) desde KALI (en la maquina objetivo faltan librerías) y lo
descargo la mismo directorio de trabajo tmp
Lo ejecutamos y quedamos a la expectativa ante el misterioso # que
queda en la línea de comandos…
Pasados unos segundos sin que nos muestre ningún mensaje
decidimos interactuar con una mezcla de estupefacción y confusión y…
Ha funcionado!!! Somos
root en este mismo instante!!!!! Cambiamos la password del usuario root por
la de CPHE1234 e iniciamos sesión en la máquina con esas credenciales en busca
de nuestra flag.
RETO SUPERADO!!!!!!!!!!!!!!!!!!
0 comentarios:
Publicar un comentario