Siempre que hablamos de conexión segura en internet solemos hablar de HTTPS, la diferencia básica entre HTTP y HTTPS es que mediante el protocolo HTTP la información viaja en plano por lo que cualquier intermediario puede husmear nuestra información cosa que no nos interesa, a raíz de la necesidad de mayor seguridad nació HTTPS que añade una capa de cifrado en la comunicación de nuestros datos en la capa de transporte, este cifrado se realiza a través del estándar SSL/TLS. Netscape desarrolló en 1996 SSLv3 que más tarde sirvió para asentar las bases del desarrollo del estándar TLSv1.0, la versión actual es TLSv1.1. En el post de hoy intentaremos explicar como realizar un ataque de denegación de servicio aprovechando que un sitio acepte la renegociación SSL/TLS.

Normalmente cuando alguien desarrolla una web en la que se necesita un nivel de seguridad, ya sea por un login, o por que se realizan tareas delicadas como operaciones bancarias, intranet de una empresa o compras online; es necesario implementar HTTPS, como ya hemos comentado hay diferentes versiones de SSL/TLS y muchas veces las versiones antiguas de los navegadores no son compatibles con las versiones más nuevas de los protocolos de cifrado que HTTPS puede implementar, estas versiones antiguas tienen problemas como niveles de cifrado débiles para la actualidad, menores de 128bits o como en el caso que nos ocupa, tener activada la renegociación de la conexión puede hacer que seamos víctimas de un ataque DoS. En muchas ocasiones esto es permitido por las webs para que sus clientes no tengan problemas de acceso, y puedan navegar aunque estén usan un protocolo de cifrado de hace 10 años. O simplemente por un despiste del desarrollador del sitio.

Para poder explicar como funciona este ataque D.o.S. es importante primero entender como funciona el handshake de HTTPS:

En la primera parte se establece la versión del protocolo sobre la que se trabajará; se establece un id de sesión; el servidor envía su cipher suite que es una lista de protocolos, versiones y métodos de cifrados que acepta; se decide el método de compresión y se intercambian una serie de valores aleatorios.

• Este paso es opcional, el servidor envía su certificado y la verificación del mismo.

• Este paso va de la mano del paso 2, el cliente responde al servidor con su certificado y la verificación del mismo.

• En este paso se produce el intercambio final de los certificados del cliente y servidor y de sus espeficaciónes correspondientes. A partir de ahora la comunicación cliente-servidor es cifrada.

La base de este ataque se encuentra en el consumo de recursos que le supone al servidor en relación con el cliente, para que nos hagamos una idea un servidor puede negociar entre 150-300 handshakes por segundo (según la potencia del mismo), mientras que un cliente puede solicitar hasta 1000 handshakes por segundo, por lo que no es necesario una botnet ni un súper ordenador para realizar este ataque. Pero para que este ataque surta el efecto deseado el servidor tiene que tener habilitada la renegociación de SSL/TLS. Como podemos observar, es fácil darse cuenta de por donde van los tiros en este ataque, pedir N peticiones de renegociación de cifrado a nuestro servidor víctima.

Hay varia formas de detectar esta vulnerabilidad, si usamos Nessus existe un plugin (ID53491), aunque también se puede comprobar de forma manual con el comando openssl:

openssl s_client -connect IP:PUERTO
HEAD / HTTP/1.0
R
RENEGOTIATING

Si nos devuelve RENEGOTIATING podemos tener claro que el servidor es vulnerable:

Los chicos de www.thc.org The Hackers Choice< han desarrollado una herramienta para poder explotar esta vulnerabilidad a fondo, la podeis encontrar aqui.

Para prevenir este tipo de ataques y otros como MiTM es muy importante tener siempre desactivadas las versiones mas desfasadas de los protocolos de cifrado, tener el software siempre actualizado, las últimas versiones de Apache no son vulnerables y tiene la renegociación SSL desactivada, al igual que las últimas versiones de Microsoft IIS. Por otro lado también es interesante implementar reglas de forma que una determinada IP tenga un número máximo de renegociaciones SSL por segundo, por ejemplo 5, ya que muchas veces como en el caso de querer que los clientes tengan que autenticarse en ciertas paginas con certificados X509 es necesaria tener activada la renegociación.

Es importante comentar que el fallo no está en el protocolo en si, sino en la opción de renegociación de la conexión cifrada.

Fuentes:

• Especificaciones de cifrado
• Protocolo SSL/TLS
• Protocolo HTTPS
• www.orchilles.com
• RFC’s: RFC2818, RFC4346, RF5746

Desde hace un tiempo me he estado pegando con distintos clientes para OpenVPN en MacOS X y la verdad he probado varios como Tunnelblick que es el cliente recomendado por OpenVPN en MacOS X con interfaz gráfica. Pero la verdad es que últimamente me estoy aficionando más a la terminal así que en este post pasaré a explicar de una forma muy sencilla la instalación y conexión contra un servidor OpenVPN desde un MacOS X.

Primero comentar que hay dos formas de instalar el cliente. Por un lado podemos descargar el código fuente de OpenVPN desde aquí y posteriormente necesitaremos instalar TUNTAP, que es una extensión del kernel que se comporta como un demonio que permite la creación de interfaces virtuales de red, podéis descargar el código fuente desde aquí. Luego habría que compilar los programas y crear nuestra VPN. Pero hay una forma más sencilla que es la que pasaré a contar. Para ello previamente necesitaremos tener instalado en nuestro sistema MacPorts.

Lo primero es instalar con MacPorts los dos paquetes necesarios, para ello simplemente abrimos un terminal y escribimos:

$ sudo port install openvpn2  #instalamos el primer paquete
$ sudo port install tuntaposx  #instalamos el segundo paquete

Una vez instalados los dos paquetes primero deberemos arrancar el demonio tuntaposx para que openvpn2 pueda crear las interfaces tun, para ello:

sudo port load tuntaposx #cargamos el modulo del kernel

Llegados a este punto es necesario tener los archivos de configuración de la VPN a la que queramos conectar, para ello debemos contar con un archivo de configuración y una serie de keys que nos debe de generar previamente el administrador de la red, para cargar la VPN, tan fácil como:

sudo openvpn2 MiConf.conf & #arrancamos la VPN

Si el proceso se realizo correctamente ya deberíamos tener levantada nuestra conexión OpenVPN (podemos comprobarlo escribiendo en el terminal sudo ifconfig y ver si existe alguna red del tipo tunX.

Si tuviéramos que crear alguna ruta para llegar algún equipo de la VPN ahora seria el momento, para ello utilizaríamos el comando route -n.

Por último una vez queramos acabar con la conexión OpenVPN simplemente debemos matar el proceso (con un sudo kill -9 [PID-openvpn2] devuelto al ejecutar el openvpn2) y bajamos el demonio tuntap, para ello simplemente escribimos:

sudo port unload tuntaposx #bajamos el modulo

RFI (Remote File Inclusion) y LFI (Local File Inclusion) son de las vulnerabilidades más altas que nos podemos encontrar en un aplicativo, esto supone poder ejecutar en la aplicación código externo a la misma, ya sea habiendo conseguido subir un fichero malicioso a la misma (LFI) o ejecutando código malicioso en la aplicación alojado en otro servidor (RFI). A continuación no trataremos de enseñar a localizar este tipo de vulnerabilidades, sino de una vez encontradas poder explotarlas de la forma más eficiente posible.

Como hemos dicho anteriormente, no nos interesa saber como conseguimos ejecutar el código, si embebido en una foto, subiendo un archivo o remotamente, sino saber qué hacer después de haberlo conseguido para ello partiremos simplemente de un dominio www.owned.com en el que hemos conseguido subir un fichero con código malicioso (nos da lo mismo la extensión) por sencillez imaginaremos que la ruta del fichero malicioso es www.owned.com/imag/shell.php. El fichero shell.php puede contener una shell potente y compleja tipo C99, pero lo que nos interesa es tener claro el concepto por lo que nuestra “shell” contendrá simplemente: <? system($cmd); ?> rápidamente podemos ver que simplemente recibe un valor de entrada que recoge la variable cmd y es ejecutado en el sistema mediante la llamada system de PHP. Tenemos que tener en cuenta que para poder continuar crearemos un entorno “ideal”,en el que PHP no tiene deshabitado la realización de la llamada al sistema system. Dicho lo anterior podemos ejecutar comandos en el servidor llamando a nuestro archivo shell.php e indicando el valor de la variable cmd (comando a ejecutar).

Por ejemplo:

http://www.owned.com/imag/shell.php?cmd=ls

Nos podría mostrar en pantalla:

autor.jpg banner.jpg prueba.jpg shell.php

Los resultados se mostrarían de un forma muy incomodos, y para verlos bien tendríamos que ver el código HTML, una buena solución es realizar un pequeño script, en este caso en perl, para poder ver los resultados más cómodos desde nuestra consola, el script podría ser algo como:

Codigo en perl de nuestra mini-shell:

Tenemos que tener en cuenta que el archivo siempre estará en la misma ruta si no lo movemos, por lo que comandos como cd no tendrían mucho sentido en este caso.

Una vez aclarado esto podemos decir que tenemos cierto control sobre la maquina, en este caso tenemos las credenciales del usuario definido para el usuario PHP, si este fuera root cosa bastante improbable, el resto del post no tendría sentido, porque podríamos hacer lo que quisiéramos.

Pasemos a otras posibilidades dentro de la configuración del servidor (entendemos que al ser PHP lo idóneo sería un servidor Apache y un linux por supuesto ;)). Las posibilidades pueden variar, si es un servidor con hosting compartido, es muy raro (sería una cagada) que el usuario de PHP pudiera listar y recorrer toda la maquina, ya que se verían afectados no solo el aplicativo web vulnerable sino el resto de dominios. Para analizar si estamos en un chroot podríamos comprobarlo por ejemplo:

Visitando la web www.robtex.com/ y comprobar la ip del servidor “auditado”, allí podemos ver si hay más dominios en esa ip, si es así y no estamos en un chroot podríamos listar el resto de dominios existentes la carpeta destinada a ello en apache, normalmente /var/www/html/. Si por el contrario nos encontramos algo del tipo /var/www/vhost/ podemos deducir que estamos en un chroot.

• Si ejecutamos cat /etc/passwd y vemos cosas anormales, como si estuviera incompleto, cosas incoherentes, pocos usuarios, entonces podemos decir que estamos en un chroot.

• Si ejecutamos el comando d y vemos que solo aparece un número de usuario, o la información que muestra da signos de ser incompleta o poco previsible seguramente estemos bajo un chroot.

• En definitiva, tenemos que investigar y usar un poco la intuición, si ejecutamos uname -a y vemos el sistema que corre la maquina podemos intentar buscar archivos que sabemos que tienen que existir en la maquina, si por ejemplo estamos en un Debian podemos buscar el ´/etc/network/interfaces´, si no existe podríamos estar en un chroot, al igual que si hacemos un ´ls /bin/´ y vemos muy pocos comandos.

Llegados a este punto, si no estuvieramos en un chroot podemos intentar ver hasta que punto tenemos permisos para leer ciertos archivos críticos como claves de ssh, la configuración de ssh en ´/etc/ssh/sshd_config´, el archivo ´/etc/passwd´, y todo lo que se nos ocurra. También podemos ver que comandos podemos ejecutar sin ser root, aprovecharnos de comandos sensibles como ´wget´, ´netcat´ o ´curl´ para poder explotar al máximo la vulnerabilidad.

En caso de estar en un ´chroot´ también debemos ver que comandos tenemos habilitados para ejecutar, porque aunque no podamos salir de nuestra “jaula” tendremos habilitados una serie de comandos y quizás por algún despiste del admin tengamos habilitado algún comando sensible que nos pueda interesar para poder seguir “tirando de la cuerda”.

En cualquier caso la meta es conseguir credenciales de root por lo que debemos de ver la versión de sistema operativo y buscar en paginas como exploitdb.com alguna vulnerabilidad que este sin parchear y poder explotarla mediante algún exploit o cualquier otro método, si lo conseguimos perfecto, hemos owneado la maquina y ya sabéis que un gran poder conlleva una gran responsabilidad, así que sed buenos ;)

Bola Extra:

Normalmente un aplicativo basado en PHP va conectado a una BBDD normalmente MySQL, cuando se instala MySQL en la maquina al igual que pasa con apache, el sistema crea un usuario con unos privilegios y podemos intentar usar este usuario para recoger información del sistema o si mysql se ejecuta como root (bastante improbable) podemos leer directamente ficheros muy jugosos como /etc/shadow, puede que aun existiendo un chroot el usuario de MySQL este fuera del mismo, por alguna razón (aunque esto implique una vulnerabilidad evidente). Llegados a este punto y aprovechando nuestra vulnerabilidad inicial FI (File Inclusion) vamos a subir otro archivo en PHP que use las credenciales del usuario de MySQL para acceder a los recursos del sistema, para ello necesitamos el nombre de la BBDD, el usuario y la contraseña, por suerte para nosotros debido a la lógica de PHP en algún archivo con extensión php del aplicativo se encuentran estos datos, basta con navegar la web y ver sitios clave que se conectan a la BBDD como puede ser alta.php, feed.php, etc; ejecutando el comando cat, con nuestra shell, del contenido hasta dar con los que buscamos, una vez hecho un código como este nos valdría para poder mostrar por pantalla archivos del servidor:

MySQL:

Sobra decir que si tenemos las credenciales de la BBDD podemos hacer lo que queramos con ella ^_^, aunque ya que estamos no deberíamos contentarnos solo con la base de datos.

Nuestra nueva “shell” la hemos subido en: http://www.owned.com/imag/shellSQL.php e indicando el archivo a listar en la variable link si este existe nos lo mostrara por pantalla, el formato seria: http://www.owned.com/imag/shellSQL.php?file=%2fetc%2fnetwork%2finterfaces cabe indicar que la barra es sustituida por su código URL %2f. Podriamos ver algo como esto:

Contenido de un supuesto archivo /etc/network/interfaces:

Podeis obtener mas información de chrootaqui.

También teneis un cheat sheet de MySQL muy útil para estas tareas aquí.

Como veis entre este post y el anterior hay una gran distancia, tanto técnica como de tiempo, espero poder volver a escribir con la frecuencia que me gustaría y no dejar esto tan sumamente abandonado.

Bueno debido a mi nuevo oficio, tengo menos tiempo del que me gustaria para dedicarle al blog, pero últimamente lo que más ando haciendo es aprendiendo y dándome cuenta de lo poquito que sé, el post de hoy va a tratar de los proxys webs, este tipo de aplicaciones se usan mucho a la hora de hacer auditorias webs para ver que hay “por debajo”, con ellos podemos monitorizar todos los datos que se envían y que recibimos a la hora de realizar una navegación web, hay varios proxys; esta Webscarab que es uno de los más complejos en cuanto a opciones y usabilidad y de los más potentes; tenemos también Paros, que es un proyecto ya abandonado pero muy intuitivo y fácil de usar; y el que hasta ahora es mi favorito: ZAP (Zed Attack Proxy) que es un fork de Paros que sigue actualizándose, este será el que usaré, para este post. ZAP esta corriendo bajo Fedora14 y con un Firefox con el Addons FoxyProxy para poder gestionar rápidamente los proxys.

Este es el aspecto que presenta este proxy, primero tenemos que configurar la dirección del mismo que será a la que apunte el navegador para conectarse a internet. Para ellos simplemente Tools -> Options -> Local Proxy (yo lo tengo puesto por defecto 127.0.0.1:8080).

Después tendríamos que configurar el navegador (en este caso Firefox y su plugin FoxyProxy), para ello añadimos la dirección del proxy a la lista de nuestro complemento, una vez configurado y guardado podemos empezar a navegar por cualquier web. Recordad que tenemos que seleccionar el perfil del nuevo proxy en el Firefox para poder ver lo que hacemos.

Vamos a comprobar que todo funciona, para ello vamos a realizar una navegación simple por Google por ejemplo y comprobar que nos enseña ZAP:

Como vemos en el ejemplo se ha realizado la búsqueda de la palabra “hola” en Google, esto se ha producido mediante un método GET, y estos son los datos que podemos ver que se han enviado en uno de los 11 envíos/recibos de datos:

En esa petición podemos ver como enviá el navegador los datos solicitados a Google y de que forma este predefine el envió de los mismos, como dijimos más arriba es mediante un método GET, eso significa que si copiamos la petición veríamos la búsqueda y si en el campo q= podemos “adiós” y lo enviamos por nuestro navegador podemos ver como Google busca el dato nuevo, es decir mediante un proxy web podemos modificar TODA la información que nuestro ordenador enviá al servidor web y muchas veces saltarnos las verificaciones que realiza el navegador del formato de nuestros datos mediante por ejemplo un JavaScript que se ejecuta en nuestros navegadores de forma local (cosa insegura por esta razón). Como podemos ver en la siguiente captura podemos ver y modificar todos los parámetros que vemos, como el nombre del navegador, el site de donde venimos, etc.

Como hemos comentado este envió se realiza mediante un método GET, otro método más “seguro o invisible” sería enviarlo mediante un método POST, una forma de localizarlos es cuando realizamos por ejemplo una búsqueda en un campo y en el navegador solo vemos algo del tipo http://www.dominio.com/busqueda.php podríamos deducir que se trata de un POST.

Aquí podemos ver otra característica de ZAP, mediante el botón Break podemos crear un punto de interrupción a partir del cual podemos controlar, modificar y analizar los datos que se envían desde el navegador hasta el servidor destino:

Dentro del rectángulo rojo encontramos tres botones, el primero en verde es el que crea el Break, el siguiente confirmaría el envío actual y daría paso a la siguiente interrupción y el botón Play cancelaría el Break y haría que la comunicación vuelva a ser fluida y sin espera ni interrupciones, entre envío y envío de datos.

Esta es la explicación básica de como funciona un proxy web y como se crearía un Break o Trap, estos programas tienen otras funcionalidades como escaneres de puertos, de vulnerabilidades, spiders que analizan el site listando todos los directorios, etc.

Hace relativamente poco entre en contacto a raíz de un paper publicado en hackxcrack con una potentísima aplicación llamada scapy. Scapy es una herramienta escrita en python que nos permite desde crear paquetes UDP o TCP, hasta realizar un montón de cosas más con la potencia implícita que nos da python, escaneos de puertos, ataques DDoS, como herramienta didactica, etc. Tengo preparado otro post más de scapy y me gustaria poder dedicarle el tiempo que se merece para poder hacer una serie de ellos y poder explicar y entender ciertas cosas. En este primer post vamos a aprender como se genera un paquete TCP y como se vería en Wireshark y si lo recibimos con ncat.

Como sabemos UDP es un protocolo de red en el nivel de transporte que permite el envío de datos sin haber establecido previamente una conexión. Por lo que en este primer post de introducción veremos la facilidad de crear y enviar un paquete.

Las herramientas que yo he usado fueron, un linux con scapy y un mac con ncat y wireshark.

Entramos en materia, lo primero es tener claro cuales son las ip’s origen y destino y el puerto por el que queremos conectarnos.

Ejecutamos Scapy y si hacemos ls(IP()) vemos lo siguiente:

Son todos los campos de un paquete en la capa IP, vienen definidos de la siguiente forma: nombreDato : tipoDato = ValorActual. Para nuestro ejemplo solo nos valdría dst (ip destino) y src (ip origen). Por lo que tecleamos: (en mi caso)

c_IP=IP(dst="47.69.69.22" , src="47.69.69.55")

Hemos creado un objeto llamado c_IP que contiene los valores por defecto de la capa IP excepto los moficicados (src y dst). Podemos listar la parte modificada de la capa con el comando c_IP.

Ahora vamos con la capa UDP, si la listamos ls(UDP()) vemos lo siguiente:

Al igual que en el resultado anterior, en este caso podemos ver los campos de un paquete en su capa UDP. Para nuestro caso solo nos valdría dport (puerto destino) y sport (puerto origen). Por lo que tecleamos: (en mi caso)

c_UDP=UDP(dport=5005 , sport=1024)

Hemos creado un objeto llamado c_UDP que contiene los valores por defecto de la capa UDP excepto los modificados (dport y sport). Podemos listar la parte modificada de la capa con el comando c_UDP.

Lo siguiente seria añadir un payload, es decir la información contenida en el paquete, en nuestro caso será un mensaje pero podría ser streaming de video, VoIP o cualquier otro formato que viaje en UDP. Tecleamos:

payload="Hola mundo -> UDP

Una vez rellenado el payload procedemos a ensamblar el paquete creado de la siguiente forma:

pqt=c_IP/c_UDP/payload 		#El paquete recibe el nombre "pqt"

Si lanzamos pqt podemos ver como quedaría nuestro paquete ensamblado:

Ahora solo tendríamos que enviarlo, esto se hace con el comando send(nombrePaquete) en nuestro caso: send(pqt)

Pero antes de enviarlo vamos a abrir nuestro wireshark para ver como se vería. Para poder localizarlo mejor podemos poner el filtro:

ip.src_host==47.69.69.55 || udp.port ==5005

Este filtro haría que solo se mostrara los paquetes que salen de la ip 47.69.69.55 (donde ejecutamos scapy) y que vayan destinados al puerto 5005 y mediante UDP.

Aquí tenéis la captura del wireshark y la información del paquete, este paquete es  es rechazado por el host destino porque tiene el puerto cerrado y no espera nada.

Sin embargo si ejecutamos el ncat de esta forma:

ncat -v -u -l -p 1024

-v : modo verbose activo
-u : modo UDP
-l : indicamos que lo ponemos en escucha
-p 1024 : especificamos puerto

Estaríamos diciendo con este comando que dejamos el puerto 1024 UDP a la escucha de cualquier conexión entrante y al indicar modo verbo que nos especifique todo, al enviar el paquete con scapy veríamos lo siguiente:

Y aquí os pongo la captura completa de lo hecho con scapy, como veréis, muy sencillo:

Y hasta aquí el post de hoy, espero poder volver a subir la frecuencia de publicación próximamente.