Listado de cursos gratuitos de Ciberseguridad 2021

HTB {CARRIER}

Durante los últimos meses he estado preparándome para presentar la certificación de OSCP y recorriendo varias opciones para practicar es inevitable no toparse con un recurso tan valioso como Hack The Box, cabe mencionar que ha sido la mejor decisión el realizar los retos que contiene este sitio, ya que contempla varios conceptos que no vienen en el material básico de preparación para esta certificación, además del ámbito de colaboración que existe entre los integrantes de esta comunidad, a quienes agradezco la paciencia y tiempo de explicarme, conceptos que hace mucho no practicaba. 

Dicho lo cual, presento lo que será mi primer "Write Up" o reseña de como resolver uno de los desafíos conocido como Carrier, espero progresivamente ir incorporando los mismos conforme vaya resolviendo cada uno de ellos y respetando el reglamento de HTB de no publicar una solución hasta que el equipo no haya sido dado de baja. 

Así que comencemos.... 

DATOS GENERALES

Nombre: Carrier
IP: 10.10.10.105
S.O.: Linux
Dificultad: Media

Durante el primer reconocimiento de puertos encontramos los siguientes: 

El siguiente paso es explorar cada uno de los servicios que tiene disponible, comenzamos con el puerto 80. 

Vemos tras navegar en la página que se trata del portal de administración de un ruteador, eso lo supimos con una simple búsqueda de Google acerca de "Lyghtspeed", así mismo, buscamos las credenciales por defecto de dicho dispositivo, pero no fueron de utilidad. 

Así que para obtener un poco más de información, exploramos un poco mas de los directorios de la aplicación web, por medio de un gobuster...

El resultado de la herramienta nos arroja 3 directorios más adicionales a la carpeta raíz de nuestra aplicación web... 

Revisemos la última "doc"

El contenido de esta carpeta nos muestra una imagen, que es un diagrama de red, que involucra a 3 ruteadores conectados entre si (esta información tomará relevancia mas adelante).

Así como un documento en formato PDF con códigos de error y su significado.... 

Si ponemos mucha atención en nuestra página inicial, notaremos 2 rectángulos de color naranja y con los siguientes números: 

Cruzando la información de estos números y el documento que acabamos de encontrar tenemos los siguientes indicios: 

Error 45007: Licencia inválida o expirada
Error 45009: System Credentials has not been set (es decir, tiene las de default) ;)

Sin embargo, este último mensaje de error, nos indica que la contraseña es igual al número de serie que está en el chassis del ruteador, pero .... es un equipo virtual y por lo tanto no tiene HW, donde lo encontramos entonces?

Si nos regresamos un poco a nuestro escaneo inicial, recordaremos que uno de los puertos que tiene abiertos es el 161 udp (snmp), con lo cual podríamos obtener algo de información de este dispositivo.

Así que ejecutamos la siguiente linea de comandos para extraer un poco mas de información: 

Y efectivamente pudimos obtener el número de serie NET_45JDX23 mismo que, de acuerdo a la documentación, debe ser el password por defecto de nuestra consola de administración.

Así que ingresamos como usuario Admin y como password el número de serie.

Y ya pudimos entrar :)

Tenemos varias opciones dentro de la consola de administración, pero tomaré las mas relevantes; en la pantalla anterior, se pueden observar varios mensajes de tickets de usuarios de soporte, uno de ellos es de vital relevancia, ya que nos revela problemas con un servidor ftp y nos proporciona tres segmentos de red, mismos que serán alcanzables desde el equipo, mas adelante retomaremos esta información de utilidad. 

Por lo pronto, seguiremos con otra opción importante "Diagnostics", al dar click en esta opción nos muestra la siguiente pantalla 

Si damos click en el botón de "Verify Status" nos desplegará tres lineas muy similares a cuando ejecutamos un comando "ps -fea" en una caja linux.

Así que el siguiente paso es analizar un poco mas a fondo esta solicitud, para esto pondremos el Burp Suite como un proxy que intercepte esta solicitud.

Al interceptar la solicitud, vemos que ésta solicitud hace un POST de un valor codificado en BASE64. 

Si decodificamos este valor, nos da como resultado la palabra quagga mismo que parecería ser un usuario, basándonos en los resultados arrojados por la página de diagnóstico. (Recuerde que la salida es muy similar a ejecutar un ps -fea). 

Así que lo siguiente a realizar es experimentar con este valor, codificamos la palabra root y lo mandamos como parámetro de la solicitud de POST de la página.

Tal y como esperábamos, nos arrojó mas resultados, mismos que al parecer se ejecutan de igual forma bajo el contexto del nombre del usuario que se le pasó como argumento, en este caso, root. 

Jugando un poco mas con las peticiones, encontramos que se puede realizar un RCE (remote command execution), simplemente concatenando el nombre del usuario que mandamos en el POST junto con una instrucción de Linux, la cual, como ya mencionamos, se ejecuta bajo los permisos del usuario pasado como argumento. 

En este caso, y después de probar con varios comandos, decidí concatenar una instrucción de bash, para ejecutar un reverse shell en mi equipo. La referencia utilizada para este fin, la puede encontrar en éste sitio. 

Antes de enviar la solicitud de POST con nuestra instrucción de shell inverso, dejamos nuestro equipo atacante a la escucha de la solicitud del mismo. 

Ya que el equipo está en escucha, enviamos nuestra solicitud de POST modificada y con ello nuestro código se ejecutará. 

Como resultado, tenemos un shell inverso y con privilegios de root. :o

Así mismo, tenemos a la mano la primer bandera de nuestro reto (user.txt). 

Sin embargo y a pesar de que contamos con privilegios de root no tenemos dentro de este equipo la bandera correspondiente a este nivel de privilegios.. 

Y entonces.... ¿Donde está? 


Si recordamos algo de la información que hemos estado recopilando durante el transcurso del reto, tenemos lo siguiente: Un diagrama de interconexión de red, tres segmentos de red y además la información de que existe un servidor FTP que no ha estado funcionando correctamente. 

Después de un poco de investigación el resto del reto se resuelve con un ataque del tipo BGP Hijacking, esta es la referencia que utilice y que explica mas a detalle como funciona este método.  De hecho plantea el mismo escenario que tenemos enfrente. 

Trataré de ser breve en la explicación antes de dar paso a la siguiente fase del ataque: 

BGP es un protocolo que sirve para intercambiar información entre sistemas autónomos (ruteadores) acerca de la ruta mas corta para alcanzar un destino determinado (servidor o host). 

Imaginemos que tenemos 3 ciudades interconectadas por carreteras todas ellas, y que pretendo ir de la ciudad AS100 a la ciudad AS300 para llegar a la casa AS300_1, si retomamos el diagrama obtenido anteriormente: 

Vemos que hay una ruta directa entre ambas ciudades y que por ende si quiero llegar a la casa con número AS300_1 tengo que ir de AS100 a AS300, esta información vive en cada una de las ciudades (ruteadores) y que en caso de actualizarse por que se agregue una casa más en una ciudad (host) el protocolo BGP se encarga de actualizar y homologar la información entre cada una de los sistemas autónomos. 

Bajo este contexto el ataque de BGP Hijacking en palabras simples es la de "engañar" esta información, por ejemplo, indicando que la casa con número AS300_1 se encuentra ubicada en la ciudad AS100, lo cual, no es cierto, pues previamente sabemos que dicha casa está ubicada en la ciudad AS300, sin embargo, si este ataque se logra concretar será direccionado a una casa falsa (servidor o host), dentro de la misma ciudad.

Para efectos de este reto, tenemos que lograr lo mismo, tenemos que engañar al proceso que va y busca al servidor FTP defectuoso, haciéndolo creer que nuestro equipo atacante es dicho servidor y por lo tanto interceptando la información que vaya hacia él. 

Dejando un poco la teoría, y regresando a los efectos técnicos de nuestro reto, vemos que en la caja está instalado un sofware de ruteo con el nombre de QUAGGA mismo que para ser configurado necesita un archivo con el nombre de bgpd.conf que no es otra cosa que el archivo que indica los sistemas autónomos interconectados (ciudades) y el rango de direcciones IPs que viven dentro de cada uno de ellos (el simil al número de casas en cad ciudad ;) )

Dentro de la información que obtuvimos dentro de los tickets se mencionaron 3 segmentos de red, uno de ellos, el 10.120.15.x es donde se encuentra ubicado nuestro servidor FTP con ip 10.120.15.10, esta dirección IP vive en otro ruteador externo al que nosotros tenemos alcance, por lo cual, como primera fase del ataque, tenemos que decir que ese equipo vive en este ruteador, para lo cual agregamos la siguiente linea de configuración: 

network 10.120.15.10/32

Con esta línea lo que hacemos es indicarle al resto de los ruteadores que la ip 10.120.15.10 puede ser encontrada en el ruteador que ya tenemos en nuestro poder. 

El siguiente paso, es dar de alta esta IP en una de las interfaces de nuestro ruteador, para lo cual, tomamos la primera disponible, en el caso del reto, será la eth2

Ya que tenemos dada de alta nuestra ip, tenemos que asegurarnos que en esa ip conteste un servicio de FTP, puesto que para que nuestro engaño sea efectivo, tenemos que contestar el mismo servicio que estamos suplantando. 

Para eso, descargué un script en python que levanta un servidor de FTP en la dirección ip que yo le especifique. 

Y ya que tenemos el servicio levantado, sólo basta esperar a que alguien o algún proceso busque a ese servidor FTP y sea direccionado al nuestro. 

Pocos segundos después.... 

Tenemos un usuario y contraseña de root, mismos que fueron capturados por nuestro servidor falso de ftp. 

Con esta información podemos intentar iniciar sesión en el puerto 22 (SSH) que vimos en el descubrimiento inicial.

Y después de iniciar sesión con esas credenciales, tenemos al alcance la bandera final de nuestro reto. 

Cabe mencionar que hace un mes comencé a practicar en los laboratorios de HTB y ésta fue la primer máquina con la que tuve que lidiar... Sin lugar a dudas mucho aprendizaje en el tema de networking, protocolos de ruteo y a no desperdiciar cualquier indicio proporcionado en los retos....

Espero esta guía les sea de utilidad.

NOT BAD FOR A LAB RAT!!