Nuevamente OWASP toma la delantera en lo referente a Seguridad de aplicaciones web. A continuación les referiré al primer episodio de la nueva serie de tutoriales de Seguridad de Aplicaciones Web, puesto en línea recientemente por Jerry Hoff, lider del proyecto.
La idea de estos tutoriales es ir presentando uno a la vez los más importantes proyectos de OWASP de forma amena e interesante. El próximo capítulo tratará del proyecto del que mucho hemos hablado en este blog OWASP Top 10 List. Estén pendientes.
A medida que vayan saliendo los capítulos se los iré presentando por este medio, pero pueden obtenerlos directamente desde la página del proyecto.
Hasta la próxima!
30 de enero de 2011
23 de enero de 2011
Nuevo tipo de DoS: HTTP POST Denial of Service.
Un nuevo tiepo de ataque de DoS fue presentado en la Black Hat DC Security Conference por dos desarrolladores de Truswave y SpiderLabs. Se trata de lo que podría denominarse Ataque de DoS en la séptima capa del modelo OSI.
Mientras la mayoría de los ataques de DoS actuan en la cuarta capa del modelo OSI, específicamente sobre protocolos de identificación y comunicación, otros recursos de ataque se basan en atacar al protocolo de la aplicación (Octava capa OSI), ya hemos mencionado muchas razones por las cuales una falla o un uso inocente de los recursos pueden generar que un ataque de DoS de este tipo pueda causar efectos impredecibles y aunque la mayoría de los ataques pueden solventarse manejando la forma en que la aplicación accede a los recursos y liberándolos eficientemente, en el caso que vamos a estudiar mitigar el ataque es mucho más difícil.
Sin embargo el ataque del que queremos hablar se coloca una capa más arriba. Se trata específicamente del HTTP POST DoS. La idea principal del ataque es la de solicitar conexiones con el servidor web (HTTP) y una vez realizado el "handshake" enviar datos de solicitud a una velocidad muy baja, de forma que el servidor se vea obligado a mantener la comunicación abierta esperando que se complete la solicitud (request). Si al mismo tiempo se abren cantidades de conexiones simultáneas con el mismo propósito, se llegará a obstruir las comunicaciones con el servidor ya que este en algún momento podría quedar sin recursos de comunicación disponibles.
Tom Brennan director de Trustware, involucrado también con OWASP (Open Web Application Security Project) desarrolló una herramienta de Pen-Testing para ayudar a los programadores a conocer si sus servidores están en capacidad de soportar este tipo de ataque y por supuesto resolver las fallas que pudieran dar cabida al mismo. La herramienta forma parte de uno de los proyectos de OWASP llamado HTTP POST Tool y pueden encontrarla en este enlace.
A diferencia de los ataques generados por métodos que atacan la cuarta capa del modelo OSI, o ataques directos a la aplicación, este tipo de ataques de la séptima capa OSI son más difíciles de limitar ya que no dependen directamente del protocolo de red. Por otro lado son muy fáciles de crear. El siguiente ejemplo de un simple archivo bash es concluyente:
Mientras la mayoría de los ataques de DoS actuan en la cuarta capa del modelo OSI, específicamente sobre protocolos de identificación y comunicación, otros recursos de ataque se basan en atacar al protocolo de la aplicación (Octava capa OSI), ya hemos mencionado muchas razones por las cuales una falla o un uso inocente de los recursos pueden generar que un ataque de DoS de este tipo pueda causar efectos impredecibles y aunque la mayoría de los ataques pueden solventarse manejando la forma en que la aplicación accede a los recursos y liberándolos eficientemente, en el caso que vamos a estudiar mitigar el ataque es mucho más difícil.
Sin embargo el ataque del que queremos hablar se coloca una capa más arriba. Se trata específicamente del HTTP POST DoS. La idea principal del ataque es la de solicitar conexiones con el servidor web (HTTP) y una vez realizado el "handshake" enviar datos de solicitud a una velocidad muy baja, de forma que el servidor se vea obligado a mantener la comunicación abierta esperando que se complete la solicitud (request). Si al mismo tiempo se abren cantidades de conexiones simultáneas con el mismo propósito, se llegará a obstruir las comunicaciones con el servidor ya que este en algún momento podría quedar sin recursos de comunicación disponibles.
Tom Brennan director de Trustware, involucrado también con OWASP (Open Web Application Security Project) desarrolló una herramienta de Pen-Testing para ayudar a los programadores a conocer si sus servidores están en capacidad de soportar este tipo de ataque y por supuesto resolver las fallas que pudieran dar cabida al mismo. La herramienta forma parte de uno de los proyectos de OWASP llamado HTTP POST Tool y pueden encontrarla en este enlace.
A diferencia de los ataques generados por métodos que atacan la cuarta capa del modelo OSI, o ataques directos a la aplicación, este tipo de ataques de la séptima capa OSI son más difíciles de limitar ya que no dependen directamente del protocolo de red. Por otro lado son muy fáciles de crear. El siguiente ejemplo de un simple archivo bash es concluyente:
Mitigar este tipo de ataques es mucho más complejo, ya que no dependen ni del protocolo de comunicación ni de la aplicación. Para cada servidor (IIS, Apache, Nginx...) y versión existen soluciones diferentes que iremos analizando en futuros artículos.
Hasta la próxima...
Limitaciones de los Escaners de Vulnerabilidades para Aplicaciones Web.
Un típico error de las empresas con sus propios equipos de desarrollo o las empresas de desarrollo específicamente, es la tendencia a creer que las aplicaciones web pueden ser convertidas en fortalezas impenetrables con un simple Pen-testing realizado mediante el uso de un programa de escaneo de vulnerabilidades especializado para la web.
Programas como Acunetix, W3af, Netsparker, N-Stalker, Burp y otros, si bien han conseguido convertirse en excelentes herramientas, dependen en mayor o menor grado para desempeñar su trabajo de forma exitosa de los conocimientos de un experto en seguridad web.
Existen muchos de estos programas en formatos diferentes y la intención de estos (al menos la mayoría) es ayudar al experto en seguridad a realizar una serie de pruebas que permitirán conseguir vulnerabilidades para pasar de inmediato a corregirlas. Sin embargo estos programas, tienen muchas limitaciones:
- Debido a la gran cantidad de vulnerabilidades posibles, y a sus cientos de variantes toman horas en realizar un análisis exhaustivo de la aplicación web, consumen una gran cantidad de recursos y someten a la misma a un "stress" indebido para entornos de producción. Aunque la práctica recomienda tener un entornos independientes de desarrollo y control de calidad, en muchos casos estos no existen.
- Cualquiera que los haya utilizado sabe que producen una gran cantidad de "falsos negativos" y "falsos positivos".
- Necesitan de constante actualización, cada día se descubren nuevas formas de penetrar aplicaciones y por tanto nuevas vulnerabilidades afloran.
- Producen un falso sentido de seguridad web.
- Normalmente no explican la razón por la cual se considera una vulnerabilidad como tal, y menos aún dan al programador y su equipo tips para corregirla, por lo que las vulnerabilidades tienden a quedar sin arreglo.
Programas como Acunetix, W3af, Netsparker, N-Stalker, Burp y otros, si bien han conseguido convertirse en excelentes herramientas, dependen en mayor o menor grado para desempeñar su trabajo de forma exitosa de los conocimientos de un experto en seguridad web.
En un estudio realizado por David Shelly, Randy Marchany, Joseph Tront - Closing the Gap: Analyzing the Limitations of Web Application Vulnerability Scanners - que fue presentado en el evento OWASP AppSec DC 2010, utilizando una aplicación en la que se implementaron una serie de vulnerabilidades premeditamente, demostraron que 6 diferentes escaners de vulnerabilidades detectaron entre todos de la serie de vulnerabilidades implantadas los siguientes porcentajes:
Para obtener los falsos negativos simplemente hay que restar el porcentaje al 100%. Lo anterior significa que usted tendría que escanear su aplicación con 6 diferentes herramientas y seguiría teniendo un nivel muy alto de vulnerabilidades latentes, inclusive en algunos casos todas ellas seguirían sin detectarse.
Por otro lado el estudio demostró, que las diferentes herramientas utilizadas arrojaron las siguientes cantidades de falsos positivos:
Entonces: ¿Son acaso como los malos periodistas? ¡Solo dicen una parte de lo que hay e inventan otra parte de lo que dicen!
- 59.7% de las vulnerabilidades de SQL Injection por formulario.
- 6.3% de las vulnerabilidades de SQL Injection por Cookies
- 43.3% de las vulnerabilidades por Reflected XSS
- 11.1% de las vulnerabilidades por Stored XSS
- 0% de las vulnerabilidades por DOM based XSS
- 20% de las vulnerabilidades de Predictable SID en manejo de Sesión.
- 4.4% de variables de Sesión Inseguras por Cookies.
Para obtener los falsos negativos simplemente hay que restar el porcentaje al 100%. Lo anterior significa que usted tendría que escanear su aplicación con 6 diferentes herramientas y seguiría teniendo un nivel muy alto de vulnerabilidades latentes, inclusive en algunos casos todas ellas seguirían sin detectarse.
Por otro lado el estudio demostró, que las diferentes herramientas utilizadas arrojaron las siguientes cantidades de falsos positivos:
- 12% en SQL Injection.
- 13.9% en XSS
Entonces: ¿Son acaso como los malos periodistas? ¡Solo dicen una parte de lo que hay e inventan otra parte de lo que dicen!
Esto no significa que los escaners de vulnerabilidades para aplicaciones web no sean útiles, claro que lo son y mucho, pero lo son solamente en manos de personal especializado que tenga la capacidad de dicernir entre la realidad y lo que reportan. Si el personal que los va a utilizar no tiene bases sólidas de Seguridad de Aplicaciones Web no podrá obtener de ellos una gran parte lo que pueden ofrecer. En definitiva, son las herramientas de pen-testing que nos dan indicios sobre "como abrir la lata" pero hacerlo y obtener su contenido son asuntos más complejos.
20 de enero de 2011
Emulación de librerías Javascript externas mediante pharming u otras técnicas de ataque.
Actualmente los frameworks de Javascript como jQuery, Mootools, YUI, Google Web Toolkit y otros, se han convertido más que en un accesorio en una necesidad. Son impresionantes los plugins pre-elaborados y las mejoras que podemos aplicar en las interfaces de usuarios con estas librerías, y un desarrollo web que no las contemple puede cargar a cuestas un serio "handicap" en relación con sus competidores.
No me opongo para nada al uso de las mismas, si bien como todo desarrollo pueden tener problemas de seguridad, estos son evaluados por profesionales expertos y en caso de descubrirse una vulnerabilidad sabemos que automáticamente estarían corrigiéndola. Sin embargo a lo que me opongo es a la moda muy peligrosa de incluir estas librerías directamente desde la fuente, o lo que es lo mismo sin utilizar una copia local, llamando a la librería correspondiente desde la fuente directa. Esto se suele hacer para poder tener a mano siempre la versión más actualizada, lo cual en principio no es una mala idea.
El problema con esta idea es puede ser más grave el daño que el beneficio que aporta, ya que bastaría con infectar el archivo "hosts" del equipo de la víctima mediante "pharming local" con una dirección que sustituya la dirección en la que se puede obtener el código de la librería de javascript usada en nuestra aplicación y así la victima estaría descargando una copia con código adicional infectado.
Se podría obtener mucha información con solo colocar al final del código de una de estas librerías funciones adicionales que capturen la información delicada y la hagan llegar al atacante mediante AJAX usando inclusive funciones de la librería que se está emulando. Todo esto sin que el usuario detecte absolutamente nada extraño. Para mostrar mi punto solo pregúntense si el usuaruio sabe o no si una página determinada está siendo evaluada por Google Analytics. Este es un caso legal, pero solo necesitan extrapolar la idea.
Lo peligroso de este ataque es que no existe forma práctica por parte de la víctima de detectarlo, el estaría accediendo a las páginas de sus aplicaciones preferidas sin que se emulara ningún componente (excepto las librerías que para el son transparentes).
Si bien existe una política de seguridad en los navegadores para el control de llamada a funciones y componentes del DOM desde sitios cruzados, es importante recordar que en este caso puede no ser muy útil, ya que lo que esta política evita es el llamar a una función o componentes del DOM desde otro página de otro dominio o sub-dominio, la librería de conexión está en capacidad de enviar cualquier cosa si es llamada desde la misma página.
Si esto último no fuera cierto siempre se podría hacer una llamada con parámetros desde un "tag" de imagen, una llamada javascript o un simple enlace. En HTML5 inclusive se pueden utilizar "websockets" para enviar los datos. Y aunque lográramos por políticas de seguridad que simplemente fuera imposible enviar datos, siempre podríamos generar una redirección no deseada a otra página.
Por tanto la recomendación a seguir para evitar este problema es muy sencilla:
No cargar librerías Javascript, plugins u otro tipo de scripts, desde sitios externos independientes en páginas donde se trate con información delicada. En estos casos es siempre preferible tener copia de dicha librería o plugin en nuestro servidor y cargarlos desde allí.
Hasta la próxima!
No me opongo para nada al uso de las mismas, si bien como todo desarrollo pueden tener problemas de seguridad, estos son evaluados por profesionales expertos y en caso de descubrirse una vulnerabilidad sabemos que automáticamente estarían corrigiéndola. Sin embargo a lo que me opongo es a la moda muy peligrosa de incluir estas librerías directamente desde la fuente, o lo que es lo mismo sin utilizar una copia local, llamando a la librería correspondiente desde la fuente directa. Esto se suele hacer para poder tener a mano siempre la versión más actualizada, lo cual en principio no es una mala idea.
El problema con esta idea es puede ser más grave el daño que el beneficio que aporta, ya que bastaría con infectar el archivo "hosts" del equipo de la víctima mediante "pharming local" con una dirección que sustituya la dirección en la que se puede obtener el código de la librería de javascript usada en nuestra aplicación y así la victima estaría descargando una copia con código adicional infectado.
Se podría obtener mucha información con solo colocar al final del código de una de estas librerías funciones adicionales que capturen la información delicada y la hagan llegar al atacante mediante AJAX usando inclusive funciones de la librería que se está emulando. Todo esto sin que el usuario detecte absolutamente nada extraño. Para mostrar mi punto solo pregúntense si el usuaruio sabe o no si una página determinada está siendo evaluada por Google Analytics. Este es un caso legal, pero solo necesitan extrapolar la idea.
Lo peligroso de este ataque es que no existe forma práctica por parte de la víctima de detectarlo, el estaría accediendo a las páginas de sus aplicaciones preferidas sin que se emulara ningún componente (excepto las librerías que para el son transparentes).Si bien existe una política de seguridad en los navegadores para el control de llamada a funciones y componentes del DOM desde sitios cruzados, es importante recordar que en este caso puede no ser muy útil, ya que lo que esta política evita es el llamar a una función o componentes del DOM desde otro página de otro dominio o sub-dominio, la librería de conexión está en capacidad de enviar cualquier cosa si es llamada desde la misma página.
Si esto último no fuera cierto siempre se podría hacer una llamada con parámetros desde un "tag" de imagen, una llamada javascript o un simple enlace. En HTML5 inclusive se pueden utilizar "websockets" para enviar los datos. Y aunque lográramos por políticas de seguridad que simplemente fuera imposible enviar datos, siempre podríamos generar una redirección no deseada a otra página.
Por tanto la recomendación a seguir para evitar este problema es muy sencilla:
No cargar librerías Javascript, plugins u otro tipo de scripts, desde sitios externos independientes en páginas donde se trate con información delicada. En estos casos es siempre preferible tener copia de dicha librería o plugin en nuestro servidor y cargarlos desde allí.
Hasta la próxima!
18 de enero de 2011
Skipfish: Escanner de Seguridad Web de Google
Si bien realmente Skipfish promete ser una herramienta interesante como Nikto o Nessus, uno de los principales problemas que podemos tener es que para empezar tenemos que compilarla. En el sitio no se ofrecen versiones en binario para los diferentes sistemas operativos. La ventaja de compilarla es que este proceso puede ser desarrollado para Linux, MacOS, FreeBSD y Windows (Cygwin).
Luego de varios intentos logré compilarla bajo Ubuntu 10.04 Lucid Lynx, luego de navegar un buen rato por la web ya que necesitaba tener instaladas algunas librerías de las que no se menciona absolutamente nada en el "readme" que provee el paquete de instalación.
Skipfish al igual que Nikto, no tiene una interfaz gráfica amigable y todo el proceso de escaneo debe ser desarrollado desde la ventana de terminal. Sin embargo, una de las virtudes que manifiestamente hacen a esta utilidad de seguridad de Google un muy interesante prospecto es su velocidad, que le permite ejecutar hasta 2000 solicitudes por segundo sobre servidores con capacidad de respuesta, lo que se redujo a unas 500 solicitudes sobre el tipo de conexión que yo tengo ( aprox.1.5 Mbits/sec).
Quizás lo impresionante son los diccionarios que utiliza para escanear todo tipo de posible directorio o archivo ubicado en el servidor, ya que al parecer estos han sido creados utilizando los conocimientos de escaneo de Googlebot (la araña de rastreo de Google) por lo que al combinar los nombres con cada uno de los tipos de archivos, hay una amplia posibilidad de ubicar archivos no indexados en los servidores a escanear.
El desarrollo según sus creadores ofrece las siguientes características:
- Alta velocidad: Al ser desarrollada completamente en C deja una huella menor de uso de CPU, lo cual luego de haberla probado en condiciones convencionales nos parece cierto, si bien los escaneos fueron más largos de los de otras aplicaciones debido a lo extenso de los diccionarios.
- Fácil de usar: La verdad nos gustaría saber exactamente que entienden algunos programadores al usar el término "fácil". Su interfaz como ya dijimos es completamente en consola y hay que compilar la aplicación para poder usarla. Si bien una vez que se han instalado las librerías necesarias solo hay que llamar al comando "make", sería interesante que se explicara en alguna parte acerca de la necesidad de las mismas. Además la interfaz de comando tiene tal cantidad de diferentes opciones con las que bien se podría redactar un libro de cierta extensión.
- Usa una lógica de seguridad de primera: No tenemos mucho que objetar a este punto, ya que el simple hecho de que los diccionarios provengan de Googlebot es ya un avance radical. Sin embargo obtuvimos una cantidad de falsos positivos superior a lo esperado, pero entendemos que la aplicación está aún en proceso de desarrollo y como todo lo que hace Google terminará corrigiendo sus hasta ahora pocas debilidades.
Hasta la próxima!
Suscribirse a:
Entradas (Atom)
Suscribirse a
Entradas
Todos los comentarios