miércoles, 31 de julio de 2019

Buscando la dirección lP real detrás de Cloudflare





¡Buenas lectores!


En esta entrada os quiero hablar sobre cómo encontrar la IP real del servidor detrás de Cloudflare.

Cuando se realiza una auditoria denominada Black Box o Caja Negra, la información que se nos proporciona para poder llevar a cabo esta, es mínima, es por eso que tenemos que desplegar nuestro arsenal de herramientas para poder encontrar información útil que nos pueda servir para realizar el Pentest.

En este caso, la dirección IP real utilizando la primera etapa de la auditoría o pentest “Footprinting”.

Para ponernos en contexto, vamos a comentar de forma resumida que es Cloudflare.


¿Qué es y cómo actúa Cloudflare?


Cloudflare es un servicio que realiza la labor de intermediario entre los sitios web en línea y los usuarios finales o visitantes que intenten acceder a estos sitios web. Esto permite la protección ante ataques web, protección ante ataques DDoS, protección frente a inyección de código, protección perimetral, etc. 

Para entendernos, cuando un usuario intenta acceder a un sitio web, la solicitud no llega directamente al servidor web donde está alojado el sitio web, si no que intervienen los CDN de Cloudflare, que no son más que servidores DNS y Proxy Inverso los que reenvían el tráfico al servidor donde esté alojado el sitio web. 

De esta manera, la dirección IP que se muestra no es la auténtica del servidor web, si no la de los servidores intermediarios. 

Cloudflare permite proteger el sitio web mediante transferencia de los DNS originales del sitio, al DNS asignado por el servicio de Cloudflare.


Esquema de funcionamiento Cloudflare


¿Cómo saber si está detrás de Cloudflare?


Bueno, pero ¿cómo sabemos si realmente este servidor se encuentra detrás de la red de Cloudflare? 

Una forma rápida sería con la ejecución de Ping al sitio web a auditar y acceder a la dirección IP que nos resuelve: 


Ejecución de ping al sitio web a auditar

Como se puede observar al intentar acceder, nos devuelve código de Error 1003 de Cloudflare:

Error 1003 de Cloudflare al intentar acceder


Otra de las formas sería a través de herramientas web Checkforcloudflare, esta nos indica visualmente si pertenece el sitio web está utilizando Cloudflare o no:


Buscando la dirección IP real


Para buscar la dirección IP que se esconde detrás de Cloudflare, tenemos varias posibilidades que mostraré a continuación, en este caso mostraré la forma manual y en proximas entradas me centraré en herramientas automatizadas.


Certificados SSL


Si queremos obtener datos relacionados con los certificados que se encuentran en sitios web en línea, no podemos hablar de otra herramienta mejor que Censys, esta nos permite comprobar todos los certificados que se encuentran en Internet gracias a su base de datos, a parte también nos proporciona otros datos de interés relacionados.

Censys nos permite realizar búsquedas con operadores lógicos Booleanos, de esta forma podemos relacionar campos de una manera sencilla. (Uso de Queries Censys)

Una vez estemos en la web de Censys, seleccionaremos en la barra de búsqueda “Certificates”.


Para realizar una búsqueda correcta, añadiremos la siguiente query:

  • Certificados para el sitio a auditar: 
    • parsed.names: “Dominio”
  • Solo mostrar certificados válidos: 
    • tags.raw: trusted
Si esto lo juntamos con lógica booleana, nos devolverá los resultados que tengan el dominio indicado y un certificado válido: 

  • parsed.names: “dominio” and tags.raw: trusted

Resultado de búsqueda en Censys

Una vez que nos ha devuelto resultado, tendremos que entrar en cada uno de estos y seleccionar "Explore" en la esquina superior derecha y a su vez en "IPv4 Hosts".

De esta forma, se realizará la búsqueda de direcciones IPv4 a través del hash-256 del certificado.

Información de Sitio Web en Censys

Obtención de IP real a través de Censys
Podría ser la IP real del servidor, podemos probar a navegar directamente con la dirección IP y comprobar que nos muestra ¿redirige al sitio web? ¿muestra el sitio web correctamente con la dirección IP? 


Sitio Web y Cabeceras de correo


Aunque no lo creas, desde el propio sitio web del que queremos obtener la dirección IP, podemos obtener mucha información.

Si tenemos la oportunidad de inicializar el envío de un correo electrónico desde la página web (confirmación de registro, pedidos, suscripciones, tickets de soporte, contraseña olvidada, etc) hasta nuestro correo, existe la posibilidad de poder extraer la dirección IP real del servidor.

Para que la dirección IP sea correcta, hay que tener en cuenta que el servidor de correo de origen debe ser interno, es decir, que salga con la misma dirección IP que el sitio web, en el caso que sea un servidor de terceros o esté montado sobre otro servidor con otra dirección IP, no va a ser exactamente la dirección que buscamos... aunque nunca viene mal tenerlas para más investigación.

En el caso de la imagen siguiente, las direcciones IP son del mismo rango pero no exactamente la que quería, con lo cual tuve que subir/bajar el último octeto para conseguir la dirección IP real del sitio web.


Cabecera de correo con direcciones IP

Es posible que a la hora de intentar acceder a dichas direcciones IP con la barra de direcciones del navegador no podamos acceder.

Este método es posible que no funcione porque el servidor web estará configurado para ignorar las solicitudes que no contienen el nombre del host correspondiente o porque varios sitios están alojados en el mismo sitio web.


Podemos evadirlo con la herramienta CURL, esta nos permite enviar solicitudes con un encabezado personalizado con la opción –H:

  • curl -H "Host: HOST NAME" http://IP

Si queremos conectar a través HTTPS, tendremos que agregar la opción –K antes de la dirección IP, esta opción nos permite saltarnos el certificado.

  • curl -H "Host: HOST NAME" -k https://IP

Comprobaremos el código fuente HTML que nos devuelve y quien sabe, igual obtenemos algo más interesante…

Un truquillo para este método es enviar un correo a un destinatario falso pero que contenga el dominio correcto. Si el destinatario no existe, recibiremos un correo indicándonos que ha fallado la entrega, con lo cual tendremos un correo para investigar =P


Registros DNS y DIG


Los registros DNS también nos pueden aportar información muy valiosa, para eso tenemos la herramienta de SecurityTrails, la cual nos permite comprobar los históricos de los registros DNS antes de añadirse a la red Cloudflare. 


Tenemos 2 opciones:

Búsqueda por registros de tipo A


Buscamos el sitio web a auditar y nos dirigimos en el panel de la izquierda a “Historical Data”, de esta manera nos mostrará los registros de Tipo A y nos dirá directamente cual es la dirección IP real en caso de que esté almacenada.

Registros Tipo A con SecurityTrails


Búsqueda por registros NS


Como anteriormente, pero una vez estemos en “Historical Data”, hacemos click en “NS”.

Registros Tipo NS con SecurityTrails

Con los registros NS a mano, utilizaremos la herramienta DIG para que nos devuelva la dirección IP real del servidor:

  • dig @ns1.targetnameservers.com targetdomain.com

Netcraft


Netcraft es una herramienta web muy útil, la cual nos brinda información del sitio web que queremos auditar. Podemos visualizar el histórico de los servidores donde se ha ido alojando el Sitio Web, así como los Nameserver, Site Rank, etc. Como he comentado, información muy útil. 

De esta manera, podemos comprobar también el histórico de las direcciones IP antes de ser añadido al servicio de Cloudflare.

Para ello accedemos a Netcraft e introducimos el sitio web a auditar, directamente nos mostrará información relacionada con el sitio como se puede ver en la siguiente imagen.


Información útil del Sitio Web a auditar


Probando y confirmando


Cuando hemos obtenido la dirección IP pública real del servidor donde está alojado el sitio web, tenemos que probar que verdaderamente funciona, para ello tenemos 2 opciones de saltarnos los servidores de la red de Cloudflare:

Opción 1

Añadir directamente el domino/subdominio y la dirección IP al archivo hosts:

Añadir dirección IP y dominio al archivo Hosts


Opción 2

Si vamos a utilizar Burpsuite para la auditoria o pentest, es recomendable asignar una resolución de nombre manual, de esta forma anularemos el reenvío hacia los servidores de Cloudflare y resolverá con la dirección IP añadida. Para ello:

Resolución de nombre en Burpsuite


Conclusiones


Hay que tener en cuenta que ninguno de los métodos mostrados aquí es 100% fiable, es posible que a mi me sirva, pero a alguno de vosotros no. Lo mejor que se puede hacer es probar todos los métodos e investigar hasta conseguir la dirección IP correcta.

Cabe mencionar que la exposición de la direccion IP real del servidor, no se trata de ninguna vulnerabilidad de Cloudflare, más bien son fallos de configuración de los administradores del Sitio Web, exponiendo dominios o subdominios que no han sido añadidos correctamente al servicio de Cloudflare.

Como hemos podido observar, lo más importante en la primera fase de auditoría o Pentest, es la recolección de información, obtener direcciones IP de todo tipo para más tarde ir comprobando y descartando. 

Los servidores DNS siempre deben estar en el punto de mira ya que nos pueden mostrar información histórica y que siempre estará disponible en Internet.

Aquí abajo os dejo unas cuantas herramientas para la recopilación de información de Sitios Web, así como enumeración de subdominios, servicios, etc:


Existen muchos otros métodos de detección, si alguno de vosotros quiere dejar un comentario con el que mejor le sirve en su día a día se lo agradecería =D

Nos vemos en el próximo artículo.

Saludos!

rekkatz


Referencias:

viernes, 26 de julio de 2019

Ataque Man in the Middle en APT < 1.4.9




Buenas lectores! 

En esta primera entrada, quiero mostrar un tipo de ataque que se basa en Man in the Middle APT, el cual descubrí realizando una de las máquinas de la plataforma Hackthebox. 

Para ponernos un poco en contexto, se trata de una vulnerabilidad en el gestor de paquetes de alto nivel en los sistemas GNU/Linux, que se encuentra en versiones inferiores a la 1.4.9 de APT, esta vulnerabilidad nos permite saltarnos el proceso de verificación de los paquetes que son solicitados para actualizarse o instalarse.

La vulnerabilidad en cuestión se trata de: CVE-2019-3462 , esta nos permite redireccionar las peticiones de APT a un servidor atacante en el cual podremos gestionar los paquetes que tratará de solicitar la máquina vulnerable al ejecutar "apt-get update && apt-get upgrade", estos paquetes estarán manipulados aumentado su versión y añadiendo en los scripts de instalación el código de la shell inversa.

Como veréis a continuación, he intentado replicar el escenario que me encontré al realizar el CTF, sinceramente me gustó la manera de manipular paquetes Debian el cual me trajo bastante dolor de cabeza, hasta que al final se obtiene la querida inverse shell root y el dolor se convierte en satisfacción.

Punto importante a comentar: este tipo de ataque se realiza una vez se ha obtenido usuario en la máquina vulnerable y nos disponemos a realizar Privesc (escalada de privilegios). 

Sin más dilación, vamos allá:

Direcciones IP:
- Kali Linux 2019.2: 192.168.17.142
- Debian Server 7.10: 192.168.17.143

Lo primero que me encontré fue que el user obtenido, poseía permisos de SUDO NOPASSWD para "apt-get update && apt-get upgrade" y permisos para poder cambiar redirecciones de tráfico "ftp_proxy, http_proxy y https_proxy", a partir de aquí empieza la diversión.

Realizamos redirección sobre la variable "http_proxy" hacia nuestra máquina y puerto:

Modificación de variable "http_proxy"

Podemos comprobar que funciona ejecutando un servidor web temporal con PHP y ejecutar el comando "sudo apt-get update" en la máquina vulnerable.

Prueba de conexiones entrantes al servidor web temporal.

Como vemos, al no encontrar archivos de los cuales realizar llamada, nos muestra error 404 en todas las peticiones.

Como ya tenemos la redirección aplicada en la variable de entorno, lo siguiente que se me pasó por la cabeza fue...si tengo que "engañar" al servidor para que actualice un paquete manipulado, tendré que tener un paquete real ¿no?. 

Listamos los paquetes que tiene el servidor y elegimos uno, en este caso elegí el paquete "tar" y mostramos detalles del paquete instalado en el servidor:

Búsqueda del paquete "tar" y detalles de este.

Creamos los directorios temporales donde estará nuestro pequeño repositorio y descargamos el paquete "tar" del repositorio oficial.

Creación de directorios y descarga de paquete "tar" original.

Una vez tengamos el paquete ya en nuestra posesión, vamos a desempaquetarlo para poder listar y manipular:

Desempaquetado de archivo .deb descargado.

El primer archivo que tendremos que modificar, será "control", este archivo lleva como su propio nombre indica, un control sobre el paquete que lo tiene: versión, arquitectura, paquete, paquetes sugeridos, etc. A nosotros nos interesa modificar la versión del paquete para aumentarla y que el servidor vulnerable crea que hay una versión nueva de este y realice la petición para actualizar e instalar.

Archivo control sin modificar versión
Archivo control con versión modificada

En este punto vamos a realizar un pequeño inciso. Cuando tenemos que manipular paquetes de tipo .deb y añadir nuestro pequeño código para la shell inversa, nos tenemos que centrar en 2 tipos de scripts que contienen estos paquetes (puede contenerlo si lo requiere o no), los cuales son: "preinst y postinst"

  • PREINST: Este script se ejecuta antes de que el paquete al que pertenece se descomprima.
  • POSTINST: Este script se ejecuta después de la instalación del paquete.

Una vez entendido esto, vamos a modificar el archivo "postinst" para añadir nuestra shell-inversa. En el caso de que hayáis elegido un paquete que no contenga un archivo de "preinst" o "postinst", se puede crear manualmente y otorgarle permisos de ejecución (755).

Cambiar tipo de shell a utilizar (bash) y añadir código de reverse shell

Cuando ya tenemos manipulado el paquete,  volvemos a empaquetar y aumentar la versión en el nombre:

Importante: la versión del paquete DPKG en la máquina de Kali y en Debian, son distintas, por lo tanto pueden surgir problemas a la hora de intentar desempaquetar al realizar "upgrade" y que no reconozca el formato de compresión (gz y xz) o permisos con los cuales se ha empaquetado, por eso tenemos que engañar el empaquetado con fakeroot.

Empaquetado con fakeroot

Una vez empaquetado, podemos eliminar el directorio "modif_tar" y el paquete tar con la versión anterior.

Otro de los archivos importantes a la hora de realizar una actualización a través de APT, es el archivo "Packages", este contiene la ruta de donde se encuentra el paquete a instalar y los hashes (md5, sha1, sha256 y sha512), los cuales verifican que ningún archivo ha sido manipulado...o si =P.

Es importante obtener los hashes del paquete manipulado, para ello utilizamos las herramientas de generación de hashes de Kali:

Obtención de Hashes para paquete "deb" manipulado.

Podemos crear el archivo y almacenar la salida que hemos obtenido en uno de los pasos anteriores con el comando de "apt-cache show tar", recordar añadir los checksum del paso anterior, cambiar la versión y el tamaño del paquete .deb, si no muestra como he comentado en el paso anterior los campos de Filename (Ubicación del archivo a instalar), Size (tamaño del archivo a instalar) y Hashes, lo podemos introducir manualmente:

Creación de archivo "Packages"

Comprimimos el archivo Packages y también tenemos que obtener los hashes de estos dos archivos... sé lo que estás pensando, pesado no? Al final obtendremos la recompensa 😜

Obtención de Hashes de archivos "Packages" y "Packages.gz"

En este punto, tendremos que crear otro archivo más, que es el "Release"... no desesperes! Este archivo contiene la información y ubicación los archivos "Packages" y "Packages.gz", así como sus hashes y tamaño de estos. 

Importante que la Versión del servidor Debian, Arquitectura, Tamaño y Hashes sean los correctos.

Creación de archivo "Release"

Hasta el momento, nuestro pequeño repositorio contendrá estos archivos:

Listado de archivos hasta el momento.

Como estáis pensando y si no, ya lo digo yo, los archivos creados no están en sus ubicaciones correctas, así que tendremos que crear las rutas de los directorios temporales del repositorio, en las cuales tendrá que buscar la máquina vulnerable al realizar la petición a través de APT. 

Los directorios temporales, se han dejado por defecto, pero en los archivos de Release y Packages, podemos indicarle directorios distintos para que sea más llevadero. 

Nos podemos basar en las peticiones que ha realizado la máquina Debian al ejecutar el comando "apt-get update" y que hemos podido observar en nuestro servidor web temporal.

Las peticiones estaban realizando la solicitud de los archivos creados pero en rutas distintas, estas rutas serán las que tendremos que crear:

  •     http://192.168.17.142/dists/wheezy/Release
  •     http://192.168.17.142/dists/wheezy/main/binary-amd64/Packages
  •     http://192.168.17.142/dists/wheezy/main/binary-amd64/Packages.gz
  •     http://192.168.17.142/pool/main/t/tar/tar_1.27+dfsg-0.1_amd64.deb
Dejo por aquí un esquema que he creado para que se entienda mejor:

Esquema de directorios

Y pasamos a crear los directorios con sus rutas correctas y mover los archivos:

Creamos directorios y nos movemos a carpeta "debian".

Ya tenemos todo lo necesario, ahora nos falta lo más importante:

  • Ejecutamos servidor Web con PHP por si no lo hemos dejado ejecutándose en la carpeta padre, que es "debian".
    • php -S 0.0.0.0:666
  • Ejecutamos netcat para escuchar la conexión inversa de la máquina Debian, acordarse el puerto que hemos indicado al añadir el código de la shell en el archivo "Postinst" (9999)
    • nc -lvp 9999
  • Ejecutar "sudo apt-get update && sudo apt-get upgrade" en la máquina Debian y cuando nos indique si estamos de acuerdo en saltar la verificación/autenticación...presionamos "Y".

Dejo por aquí un pequeño vídeo con el resultado final y las solicitudes que realiza la máquina Debian solicitando la nueva versión del paquete "tar" para actualizar:



Y aquí la imagen con las solicitudes y los códigos 200 del servidor web temporal:

Solicitudes entrantes

Como opinión personal, es cierto que se tienen que dar algunas coincidencias para poder realizar este tipo de ataque, pero sabemos que existen usuarios que no tienen permisos 100% y solo se le otorgan permisos "mínimos" para llevar a cabo ciertas acciones en los sistemas que manejan. 

También conocemos compañeros, amigos, familiares, etc, que siguen obcecados con versiones anteriores de alguna distribución por su sencillez o simplemente por que es la versión de distribución que mejor conoce.

Recordar actualizar el paquete APT a la última versión para corregir de este tipo de vulnerabilidades.

Nos vemos en el próximo artículo.

Saludos!

rekkatz