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.

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:

• 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.

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!

Skipfish: Escanner de Seguridad Web de Google

Estuve probando la herramienta que desarrolló Google con el fin de realizar escaneos de seguridad a nuestras aplicaciones web. Su nombre es Skipfish y pueden encontrarla en su versión 1.84b en esta dirección: http://code.google.com/p/skipfish/downloads/list.

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.

Para finalizar mi opinión es que esta herramienta como todo lo que tiene que ver con Google, es un muy buen comienzo en el campo de las aplicaciones de rastreo de vulnerabilidades y sabemos que mejorará considerablemente a medida que las versiones se hagan cada vez más solidas. Recomiendo mayor y mejor ayuda al usuario y de ser posible una interfaz gráfica. Yo no le quitaría el ojo de encima.

Hasta la próxima!

URLs amigables a los buscadores - SEO friendly URLs - Convertir títulos a URL

Es un pequeño dolor de cabeza convertir en tiempo real los URLs de una aplicación al formato que actualmente se utiliza para lograr una mayor visibilidad en Google.

Este proceso tiene sus ventajas y desventajas: La ventaja principal en lo referente a seguridad es que esconden los parámetros y los nombres de las variables utilizadas en la aplicación, sin embargo en cuanto a desventajas, al hacer los URLs más largos, el usuario se ve forzado a utilizar recortadores de URL como goo.gl y otros para usar las direcciones en sus aplicaciones sociales, y de esta forma tendremos muchos menos presencia de enlaces directos que fortalezcan nuestro Page Rank en Google. Una va por otra.

Sin embargo son muy útiles también para que el usuario reconozca el contenido de una página desde su enlace, y además repiten el título en el URL lo que aumenta la posibilidad de que nuestras páginas aparezcan indexadas mejor.

Pero cuando uno va a tratar de aplicar este truco de SEO, se encuentra con que los scripts para hacerlo están todos adaptados para páginas con títulos en inglés, por lo cual no toman en cuenta los acentos y los caracteres como la "ñ" y la "ü" (u con dieresis).

Por tanto decidí realizar mi propia función en C# que convierte una cadena de texto de un título en otra cadena de texto utilizable por un URL y amigable con los métodos SEO.

A continuación una función adaptada al español que se basa en convertir caracteres acentuados, con tilde o con diéresis, en sus correspondientes sin agregado (es decir á se convierte en a y ñ en n). También convierte todos los caracteres en blanco en guiones luego de eliminar cualquiera de estos delante o detrás de la cadena. Cualquier otro caracter que no se encuentre en la lista o no sea letra, número o guión, es eliminado.

Espero les sea útil:

/// <summary>
/// Convierte cadenas convencionales de títulos 
/// en cadenas SEO URL amigables.
/// </summary>
/// <param name="strTitle">La cadena a convertir.</param>
/// <returns> El string en formato SEO amigable</returns>
public static string titleToSeoURL(string strTitle)
{
    char[] allChars;
 
    //cadena de caracteres a ser reemplazados    
    string sCharsToReplace = "áéíóúüñç_";
    //cadena de caracteres para reemplazar, en el mismo orden
    string sCharsForReplace = "aeiouunz-"; 
    string seoURL = string.Empty;
    int charPos = 0;
 
    // decodifica cualquier entidad HTML antes de empezar.
    strTitle = Server.HtmlDecode(strTitle);
    strTitle = strTitle.ToLower();
    strTitle = strTitle.Trim();
 
    // reemplaza todos los caracteres transparentes.
    strTitle = Regex.Replace(strTitle, @"\s+", "-");
 
    // El siguiente bucle reemplaza todos los caracteres
    // encontrados en sCharsToReplace por los de sCharsForReplace 
    allChars = strTitle.ToCharArray();
    for (int i = 0; i < allChars.Length; i++)
    {
        charPos = sCharsToReplace.IndexOf(allChars[i]);
        if (charPos != -1)
        {  allChars[i] = sCharsForReplace[charPos]; }
        seoURL += allChars[i];
    }
 
    // Remueve cualquier caracter no reemplazado que no
    // esté entre a y z, que no sea número o que no sea un guión (-)

    seoURL = new Regex("[^a-z0-9-]").Replace(seoURL, "");
    // remueve cualquier guión solitario al final o principio
    // de la cadena resultante
    seoURL = seoURL.Trim('-');
 
    // Limita el resultado a 80 caracteres.

    if(seoURL.Lenght > 80)
        seoURL = seoURL.Substring(0, 80);
 
    return seoURL;
}

Hasta la próxima.

¡El phishing se renueva! Phishing móvil

 

El ya conocido tipo de estafa que se basa en la simulación de un sitio en Internet para robar los datos de acceso a los usuarios con propósitos nada éticos conocido como "phishing" está permanentemente renovándose. Hemos visto a lo largo de los últimos cuatro a cinco años como además de combinarse con otros tipos de ataque como el "pharming" y el "XSS", el phishing se reinventa como por ejemplo con el "tab-nabbing".

Sin embargo la principal preocupación de los expertos en seguridad en los próximos meses es que este conocido flagelo pase de forma imperceptible al ámbito de la web móvil, específicamente a atacar a aquellos usuarios que usan smart phones y otro tipo de componentes como iPod, iPad, Playbooks y muchos otros dispositivos para los cuales sus usuarios asumen que la navegación en Internet es ya un servicio obligatorio y no una utilidad adicional.

Hay muchos puntos a tomar en cuenta:

• Los vectores de ataque son mucho más variados que el simple SPAM utilizado convencionalmente por los ataque de phishing dirigidos a PCs y computadores de escritorio o laptops.Ahora el atacante no solo dispone del SPAM sino de la mensajeria SMS, MMS, VoIP y hasta Twitter.
  
• En segundo lugar, el usuario de estos dispositivos está acostumbrándose de muy mal modo a los "short URLs" o direcciones recortadas por servicios de recorte de URL, los cuales han crecido de forma incontrolada, y no existirá control visual de las direcciones a ser visitadas antes de solicitarlas.
  
• Una gran parte de la plataforma de usuario de Internet a través de los dispositivos móviles, no tiene acceso permanente a otra forma de navegar en la Red, por lo cual si bien puede haber escuchado del phishing, nunca se han topado cara a cara con un ataque de este tipo.
  
• Los problemas ya conocidos de las redes sociales en lo referente a seguridad personal solo agravarán la situación ante un enemigo que se perfecciona cada vez más con el tiempo.
  
• La intercepción de los ataques por parte delos navegadores de los dispositivos móviles no será tan eficiente como lo es la intercepción de los navegadores tradicionales, ya que se ha comprobado que en algunos casos no es tan buena y en otros aún no existe. Tampoco son eficientes o no existen los formatos para reportar sitios sospechosos.
  
• Los sitios desarrollados para plataforma móvil en su mayoría aún no contienen sistemas de prevención y/o control, en muy escasos sitios se aprecia una política al respecto.

Luego de lo anterior me permito advertir sin ánimos de "Cassandra" que el phishing móvil, va a agarrar a desprevenidos a muchos usuarios  si no se hace algo a tiempo, empezando por educarlos y no usar URLs recortadas cuando se trate de direcciones seguras, esto solo para empezar.

Hasta la próxima...