11 de enero de 2011

Desactiva la función de autocompletar en los campos sensibles de los formularios.

Si bien la función de auto-completar los campos de formularios es una gran idea y está presente en todos los navegadores modernos, debemos tener mucho cuidado con recordar desactivarla en nuestras aplicaciones cuando los campos son sensibles, debido a que pudieran representar un riesgo de seguridad para el usuario que utiliza equipos compartidos o que permite que otras personas accedan a su equipo.

No hay que tener cuidado con los campos tipo <input type="password"> ya que lógicamente estos no utilizan esta función, pero si dejamos al descubierto el nombre o el login del usuario le dejamos el trabajo medio hecho al posible atacante. También hay que tener cuidado con los campos en que solicitamos repuestas específicas que solo el usuario debe saber y sobre todo en los campos en que el usuario debe introducir números de tarjetas. 

Desactivar la función de autocompletar puede hacerse de forma genérica o detallada por campo. Solo necesitamos incluir el atributo - autocomplete="off" - en el tag <form> si queremos que se desactive la función en todo el formulario, o incluirlo en cada uno de los campos en los cuales queremos evitar que se muestren datos sensibles.

Es un paso muy sencillo que puede evitarle al usuario dolores de cabeza, y sin embargo aún me sorprendo al ver cantidad de formularios de acceso que no desactivan esa función.

Hasta la próxima...

8 de enero de 2011

OWASP ESAPI - Enterprise Security API

Uno de los proyectos más interesantes de OWASP en referencia a la generación de código web seguro, es precisamente el que se denomina ESAPI o Enterprise Security API. Se trata de una librería de código que meneja objetos y métodos que permiten validaciones y controles eficientes para evitar XSS, CSRF y muchos otros tipos de ataques web.

OWASP ESAPI tiene puertos para la mayoría de entornos y lenguajes de programación web como por ejemplo ASP.NET, Java, PHP, ColdFusion, Javascript, Ruby y Python entre otros.

Entre algunas de las empresas y organizaciones que han empezado a adoptar ESAPI como plataforma de seguridad para aplicaciones web están American Express, Banco Mundial, US Navy y muchas más.

La librería incluye extensiones y utilidades que permiten homogeneizar el tratamiento de los procesos de seguridad para aplicaciones web, y documentación variada en formato "chm". Sin embargo una serie de artículos muy interesantes de John Melton, denominados "The OWASP Top Ten and ESAPI", nos podrán guiar de forma eficiente acerca de los diez tipos de vulnerabilidades más frecuentes según OWASP y cómo defenderse de estas usando ESAPI. Los ejemplos están en Java pero las clases, métodos y propiedades son básicamente los mismos para todos los lenguajes.

Espero que les sea de ayuda para homologar los procedimientos de seguridad y desarrollar alicaciones web mucho más seguras.

Hasta la próxima...

5 de enero de 2011

¿Qué hacer en caso de un ataque de phishing a nuestros usuarios?

Mi experiencia de años en este tema me ha demostrado que la mayoría de las empresas y entidades que reciben ataques de phishing, no reaccionan con la celeridad suficiente cuando sufren estos ataques. Además la mayoría solo toma medidas reactivas, pocas medidas preventivas y prácticamente ninguna medida de detección temprana.

Sí, ya sé que algunos estarán pensando que un ataque de phishing no se puede anticipar, pero eso en el 85% de los casos es falso, aunque dejaré para otra oportunidad ese tema. Lo que voy a explicar en este artículo son las medidas reactivas a tomar ante un ataque de phishing en curso por  parte de la administración de la aplicación afectada. La prevención y la detección temprana aunque son la mejor práctica no forman parte de este artículo.

Es impresionante ver en las empresas y entidades la poca preparación ante estos temas. En ocasiones me he visto rodeado de personal de seguridad, vicepresidentes, programadores y hasta policía al rededor de sendas mesas de reunión (más de 12 personas en una ocasión), solo para enterarme que mis servicios fueron solicitados pasadas más de 72 horas desde que se detectó el ataque, sin que ni siquiera se hubiera denunciado aún el sitio ofensivo mediante un procedimiento extremadamente básico que cualquier usuario pude hacer en menos de tres pasos desde su navegador.

Como primer punto, hay que entender que el atacante no necesariamente es un programador experimentado. Fíjense que ni siquiera le llamo con el término "hacker" ya que desarrollar un phishing es más un trabajo de "script-kiddies" o "lammers" (términos despectivos con los que los hackers llaman a los que atacan aplicaciones copiando código o exploits sin tener gran noción del proceso).

Otro detalle importante a tomar en cuenta, es que un ataque de phishing se realiza en casi la totalidad de los casos desde la plataforma de un servidor que ha sido vulnerado, para colocar las páginas falsas allí. El atacante tratará de que sus scripts y páginas falsas no sean detectadas, por lo cual dejará la menor huella posible (footprint), razón por la que sus páginas falsas llaman directamente las imágenes desde el servidor de la aplicación real, así como posiblemente a otros recursos.

Un tercer punto a tomar en cuenta es que las primeras horas de un ataque de phishing son las más peligrosas y en las que el ataque es más efectivo. En las primeras 24 horas el 60% del daño ya ha sido hecho. Por tanto las medidas a que expondré no deben aplicarse de forma secuencial sino dentro de lo posible  de forma simultánea por varias personas ya que algunas necesitan seguimiento.

Pasos a seguir ante un ataque de phishing:

Antes de tomar cualquier paso obtenga las direcciones de los servidores en los que se encuentran alojadas las pseudo-fachadas o páginas falsas. Aclaro este punto porque el ataque pudiera bien ser distribuido entre varios servidores tratando de aumentar el tiempo de vida y dándole más trabajo para denunciar más sitios, esperandoasí que se pasen algunos por alto. ¿Cómo hacerlo? Simple, usted debe tener al menos una dirección reportada, si no aún no sabría del ataque. Pues bien, fíjese qué imágenes de la páginas falsas son llamadas directamente desde su sitio y diríjase a archivo de registros de su servidor web para consultar por dichas imágenes. Una vez allí obtenga las direcciones de las que son solicitadas o   "referers". Recuerde hacer seguimiento permanente de este punto ya que pudieran aparecer nuevos sitios falsos a medida que usted bloquea otros. El ataque podría ser distribuido o por etapas, para darle atacante la capacidad de ir "quemando" los sitios a medida que usted los descubre y denuncia.

Simultáneamente usted deberá renombrar todas las imágenes utilizadas por los sitios falsos, para que estos ya no logren mostrarlas y el usuario vea como resultado al hacer clic en los enlaces forjados un sitio falso sin imágenes o al menos sin algunas de ellas (el logotipo y las imágenes que identifican la página son las más importantes).

Denuncie las direcciones falsas usandon las funciones de los navegadores Internet Explorer, Google Chrome y Opera . Si usa Firefox será igual que usar Chrome ya que acceden ambos a la misma base de datos de sitios ofensivos. Cada sitio debe ser denunciado en los tres navegadores ya que cada uno de ellos usa bases de datos diferentes. Si no tiene instalado Opera, puede hacer la denuncia directamente en https://www.phishtank.com/. Si tiene suficiente personal no olvide denunciar también las páginas en el APWG (Anti-Phishing Working Group) http://www.antiphishing.org/ .

Obtenga la información necesaria de los proveedores de hosting en los cuales se encuentran los sitios falsos mediante Reverse DNS Lookup de las direcciones asociadas al ataque, y ubique la cuenta de correo destinada a denuncias de abuso. Casi siempre tiene el formato "abuse@proveeedor.com". Denuncie el abuso con pruebas y direcciones a cada una de estas cuentas. Si logra ubicar números de teléfono con los cuales contactar a los proveedores no dude en usarlos. Este tipo de detalles se podrá obtener también mediante consultas WHOIS o nsLookup. Recuerde que este tipo de ataque es penado seriamente por la ley en muchos paises y el hecho de que un proveedor de hosting o ISP se niegue a ayudarlo puede ser causa de una denuncia por complicidad. También pueden ofrecerle direcciones en las que se hayan formularios para denuncias. Llénelos a la brevedad posible.

Llene el receptáculo de datos del atacante con información falsa. Hágalo llenando los datos solicitados como si fuera un usuario incauto, manualmente desde varios equipos mientras prepara un script para hacerlo de forma automatizada. Trate que la información que introduce en los formularios sea creíble. Esta técnica podrá ocultar a los usuarios incautos entre montones de datos falsos por un tiempo prudencial. Además con ella usted está comprando tiempo para que sus usuarios puedan cambiar de password si sospechan que han sido engañados. Por otro lado si ejecuta el script gran cantidad de veces pudiera lograr que alguno de los servicios del sitio falso dejen de funcionar. Algo parecido a una negación de servicio defensiva.

Todas estas técnicas deben ser implantadas por un tiempo prudencial de 24 horas sin parar, hasta que las denuncias en las listas de phishing se hagan efectivas y ya los navegadores protejan al usuario con la típica pantalla roja de seguridad.

Sin embargo si el ataque es distribuido, con un número muy alto de sitios falsos usted necesitará aplicar técnicas de defensa mucho más potentes y quizás no tan éticas. Generar un DoS mediante Loic o Hping puede ser una solución rápida, pero deberá estar muy seguro de a quien ataca y preferiblemente hacerlo desde una red externa a la entidad esperando un contraataque.

Recuerde que la idea es proteger a sus usuarios antes que nada, el resto son asuntos que puede dejar para otros departamentos cuando sus usuarios estén seguros.

Lógicamente, habrá podido apreciar que usted deberá en más de un caso tomar decisiones y saltar protocolos como control de calidad y otros. Su empresa debe tener un protocolo de seguridad para estos casos para que usted no se encuentre con las manos atadas por los procedimientos convencionales a seguir. Si todas las medidas anteriores suman más de 48 horas no habrán servido de mucho.

Por último, recuerde que antes de pasar por todo esto, usted puede evitar de forma casi definitiva los ataques de phishing mediante técnicas de prevención anti-phishing, sistemas de acceso seguros comprobados, factores de autenticación externos y sistemas de alerta temprana que pueden detectar a un atacante mientras aún se está instalando el phishing en el servidor vulnerado. En fin, toda una serie de técnicas de prevención y alerta que le ahorrarán muchas molestias a usted y a sus usuarios y mucho dinero a su entidad.

Hasta la próxima...

3 de enero de 2011

¿Que es un Honeypot? Tipos y usos.

La traducción al castellano del término es simple, "honeypot" significa "jarra de miel", y es básicamente un sistema o unidad de datos preparado como trampa para detectar ataques y aprender la metodología usada en estos, además de guardar rastro forense del atacante para efectos legales cuando sea posible.

Los tipos de honeypots son variados así como lo son las formas en que un intruso accede a la información de un sistema atacado. Un simple honeypot puede ser una dirección de e-mail utilizada únicamente con el fin de captar las listas de spam. En este caso se conoce como "honeytoken" y el término representa cualquier unidad de datos con la cual se permite acceso o uso de un sistema, pero que al ser utilizada levanta una alerta. Otro ejemplo puede ser un par  identificador/clave de acceso de un usuario que no existe pero que en caso de aparecer logueado en el sistema su presencia levante las alarmas de rastreo.

Existen lógicamente muchos tipos de servidores honeypots, que simplemente aparentan ser servidores descuidados y vulnerables, en los que se estudia el comportamiento de los atacantes o de una vez son utilizados para contraataque. Específicamente por ejemplo, los atacantes gustan mucho de los servidores proxy para efectos de esconder sus identidades en los ataques, por lo cual existen una serie de de servidores proxy que en vez de esconder la identidad de los que los utilizan, la divulgan a las autoridades encargadas de la protección de sistemas ¿Interesante no?

Existen muchos tipos de honeypots, también están los honeypots clients o "honeyclients", que son sistemas encargados de navegar la web cual arañas de buscadores pero con la intención de detectar código malicioso en las páginas que visitan y de esta forma erradicar el mal antes de que afecte a los usuarios.

Cuando dos o más honeypot se encuentran en una red suelen conformar una honeynet. Los honeypots y honeynets son usados básicamente en las redes para efectos de detección de intrusos. Típicamente las honeynets son usadas cuando un honeypot solo no es suficiente debido a lo amplio de la red.

Aunque son una herramienta muy eficiente pueden ser evitados por los atacantes mediante herramientas de detección y técnicas de evasión, pero ese es otro tema que trataremos a futuro.

Hasta la próxima!

¿Cómo se calcula un riesgo en base al modelo DREAD?

Es importante cuando se habla de amenazas en aplicaciones web y otras, establecer un sistema de cálculo estándar que permita a los interesados (programadores, técnicos de seguridad y otros) medir el riesgo que dicha amenaza representa, de manera de priorizar las posibles respuestas ante cada tipo de ataque así como el ajuste del código o la plataforma una vez descubierta la amenaza.


DREAD es un esquema de clasificación para cuantificar, comparar y dar prioridad a la cantidad de riesgo que presenta una amenaza específica. El acrónimo DREAD se forma a partir de la primera letra del nombre en inglés de cada una de las categorías evaluadas.

El algoritmo de cálculo de riesgo DREAD que se muestra a continuación, se fija en base a un promedio de las cinco categorías contempladas en el modelo de cálculo:

Riesgo_DREAD = (Daño Potencial + Reproductibilidad + Explotabilidad + Usuarios Afectados + Detectabilidad) / 5

El cálculo de cada una de las categorías de riesgo siempre produce un número entre 0 y 10; cuanto mayor sea el número, más grave es el riesgo.

Éstos son algunos ejemplos de cómo cuantificar las categorías de riesgo:

Daño potencial:
Si una amenaza fuese explotada, ¿Cuánto daño causaría?
0 = Nada
5 = Datos de los usuarios individuales comprometidos o afectados.
10 = Destrucción de datos del sistema comleto

Reproductibilidad:
¿Es fácil de reproducir la amenaza a explotar?
0 = Muy difícil o imposible, incluso para los administradores de la aplicación.
5 = Uno o dos pasos necesarios, puede ser necesario un usuario autorizado.
10 = Sólo un navegador web y la barra de direcciones es suficiente, sin necesidad de autenticación.

Explotabilidad:
Lo que se necesita para aprovechar esta amenaza.
0 = Conocimientos avanzados de programación y de redes, con herramientas de ataque personalizadas o avanzadas.
5 = Malware existente en el Internet, o un exploit fácil de realizar con las herramientas disponibles en la web.
10 = Sólo un navegador web.

Usuarios a los que afecta:
¿Cuántos usuarios se verán afectados?
0 = Ninguno
5 = Algunos usuarios, pero no todos.
10 = Todos los usuarios.
En esta categoría se aplica matemáticamente un punto por cada 10% de posibles usuarios afectados.

Detectabilidad:
¿Es fácil descubrir esta amenaza?
0 = Muy difícil o imposible, requiere el código fuente o acceso administrativo.
5 = ¿Se puede averiguar de adivinar o mediante el control de trazas de red?
9 = Detalles de fallas de este tipo son ya de dominio público y puede ser fácilmente descubierto usando un motor de búsqueda.

Información más detallada sobre DREAD:


Hasta la próxima...

Entradas populares