miércoles, 28 de enero de 2009

¿Aún hardcodeas passwords?

Una pequeña muestra que he encontrado en SecurityTube (el Youtube de la seguridad informática) de por qué no se deben hardcodear contraseñas en un binario:


Algo que pensar para aquellos desarrolladores de software que aún utilicen estas prácticas.

Al final del video el autor dice que colgará próximamente videos utilizando herramientas un poco más avanzadas como el IDA para ver que se puede sacar.
Los esperamos con impaciencia.

viernes, 23 de enero de 2009

Regla Snort: Amplificación DNS

Tras leer en el ISC de SANS y en SecurityByDefault los últimos problemas de ataques de Denegación de Servicio utilizando una vulnerabilidad de amplificación DNS realizando una query para obtener los servidores de nombres raices, lo primero que he pensado es el peligro que supone que usen contra nuestras empresas este tipo de ataques y que nos hagan "complices" de este ataque contra otra máquina.

Por ello, analizando un poquito el paquete que se genera el realizar esta query:




Se ha desarrollado una regla de Snort para detectar el intento de usar nuestros propios DNSs para realizar el ataque contra otras infraestructuras.

La regla sería la siguiente:

alert udp $EXTERNAL_NET any -> $DNS_SERVERS 53 (msg:"DNS Amplification Attack - Root Servers"; content:"|00 00 02 00 01|"; threshold: type both, track by_src, count 10, seconds 60; reference:url,isc.sans.org/diary.html\?storyid=5713; classtype:attempted-dos; sid:2000001; rev:1;)

Esto detectaría rafagas de peticiones DNS solicitando los servidores raiz contra nuestros servidores (contenido "00 00 02 00 01" como podemos ver en la imñagen).

Si alguien quiere comprobar si es vulnerable que use la web que ha preparado SANS, y si quiere más información que acuda al artículo de SecurityByDefault, que lo explica muy bien.

Por cierto, a la regla le he añadido en el último momento el "threshold" y eso no lo tengo tan probado, estad alerta, y ya me comentais que tal os ha funcionado.

lunes, 19 de enero de 2009

In-Session Phishing


Recientemente ha sido publicado un nuevo vector de ataque de phishing de mayor complejidad que el clásico envío masivo de correos electrónicos y que podría permitir el robo de credenciales en aplicaciones bancarias, juegos-online, etc. El denominado In-session Phishing, se vale de una vulnerabilidad en la mayoría de los navegadores web, Internet Explorer, Firefox, Safari, o Chrome, al hacer uso de ciertas funciones javascript.

Para explotar con éxito este fallo de seguridad es necesario que se den las dos situaciones siguientes:

1. El usuario este autenticado en la aplicación objetivo del robo de credenciales.
2. Un segundo site que alberga cierto código malicioso sea visitado por el usuario, mientras en la web objetivo se esta todavía autenticado.

Al parecer el navegador procede a albergar una huella cuando una página web que utiliza ciertas funciones javaescript es visitada, funciones muy habituales según sus descubridores, Trusteer. De esta manera es posible desde una segunda página interrogar al cliente con preguntas binarias sobre si se está o no autenticado en un cierto dominio. Si la respuesta es afirmativa, el código malicioso presenta un sencillo pop-up que informa al usuario sobre una falsa caducidad de la sesión y la necesidad de reautenticarse en la aplicación. En ese momento el usuario no percibe ningún comportamiento extraño puesto que hasta el momento confía en que estaba logado en un site totalmente lícito.

El ataque aunque complejo, puede tener terribles consecuencias, dado que según Sophos una web es infectada cada cinco segundos. En cierta forma este tipo de ataque ya había sido discutido en otra variante por el blog ha.ckers.org, mediante el uso de imágenes de acceso restringido a tan solo a usuarios autenticados en la aplicación. Es decir, mediante el uso de un simple tag <.IMG> que haga referencia a una imagen, solo accesible en la parte privada de la aplicación, es posible determinar si el cliente web esta o no autenticado en cierto site.

<.img src="http://mibanco.com/privado/protegido.jpg" onerror="http://atacante.com/malware-noautenticado.js " />
<.script src="malware.js"> <./script>


De esta manera es posible saber si se esta o no autenticado, pero claro, este ataque depende de la aplicación desarrollada y con creces tiene un menor impacto que el detectado por el equipo de seguridad de Trusteer.

Así que se aconseja seguir las siguientes recomendaciones de seguridad:

1. Terminar siempre la sesión actual cuando se navegue a través de una zona privada de la aplicación.
2. Desconfiar completamente de pop-ups que no han sido generados por una acción del usuario.
3. Aplicar complementos de seguridad al navegador que permita controlar scripts no deseados.

martes, 13 de enero de 2009

Webcast: Seguridad en MacOS X

El próximo Jueves (15 de Enero) a las 22:00 hora peninsular Española, 13:00 PST/ 16:00 EST horas Estadounidenses, los fanáticos de la manzana están de enhorabuena. BlackHat ha organizado un Webcast gratuito sobre seguridad en MacOS X. Hago una pequeña traducción de lo que pone en la web:

Nuestro séptimo webcast llega con un vistazo fascinante y en profundidad al mundo de la seguridad en Mac. La popularidad de la plataforma Mac está creciendo tanto en entorno particular como empresarial, y de la misma manera se está observando un incremento tanto en los ataques como en la investigación de seguridad relacionada con OS X.

El ponente Jesse D’Aguanno va a presentar el tema "Crafting OS X Kernel Rootkits – Fundamentals." Además, también tenemos una presentación de Tiller Beauchamp cuyo tema será "OS X Security – A year in Review." Sin duda será una fascinante ponencia. Puedes registrarte de manera online aquí.

Registrarse es gratuito (yo ya lo he hecho) sólo teneis que pinchar aquí para acceder directamente a la web de registro. Lo único, evidentemente, es que el webcast tiene lugar exclusivamente en Inglés y sin ningún tipo de transcripción, por lo que se requiere cierto nivel de inglés, al menos el suficiente para entender lo que el ponente dice.

Sólo una pequeña anotación, a mi me ha dado tradicionalmente problemas con Firefox para ver los webcast, los que seais usuarios de este navegador (como yo) no apureis y testead vuestro sistema, y tened a mano un Windows + Internet Explorer por si acaso (un gallifante de penalización para los de BlackHat).

domingo, 4 de enero de 2009

Rogue CA: Solución Fallida

Hace unos días os comentaba la posibilidad de incluir en nuestra lista de certificados de servidores de nuestro navegador el certificado del host concreto para evitar que tras conseguir instalarlos el certificado de una RogueCA, un intruso pueda emitir certificados de cualquier host que sean confiables para nosotros.

Pues bien, como dice el título del post, la solución (que os dije que probaría) ha resultado fallida, parece ser que al menos el navegador testeado da más credibilidad a las CA que tiene instaladas que a las excepciones (algo que por cierto no entiendo, se supone que cuanto más "concreto" más credibilidad debería darle).

Las pruebas las realicé montándome una CA en mi equipo a la que denominé RogueCA. Depués de eso generé un certificado para www.banco.com y lo firmé con esta CA. Una vez con el certificado en la mano, lancé un webmitm (herramienta del paquete dsniff) utilizando este certificado y conectando hacia la IP de este banco, tras lo que edite mi propio fichero /etc/hosts para simular un ataque de envenenamiento DNS mediante el cual me hicieran dirigir las conexiones a www.banco.com contra el proxy formado por webmitm.

Efectivamente, conecto y me sale el aviso de que el certificado no está firmado por una CA reconocida. Esto sería lo que pasaría habitualmente si alguien nos quisiera hacer un ataque de MitM a través de HTTPS.

Para "simular" la realización del ataque de RogueCA, incluimos a mano en nuestro navegador la CA que acabamos de crear, haciendo como si, de alguna manera, el intruso consiguiera incluirla (que es lo que hace realmente el ataque), así podemos probar la solución sin tener que buscar ninguna colisión MD5.



Una vez incluida, visitamos de nuevo la web y podemos observar como ya no nos aparece el error, sino que entramos sin ningún tipo de aviso a la web de nuestro banco (como era de esperar). Mientras tanto, podriamos estar grabando todas las transacciones y contraseñas que está realizando el usuario contra su banco.

Ya está comprobado que de esta manera tenemos el mismo efecto que si nos realizaran el ataque. Ahora volvemos hacia atrás hasta el momento en el que aún no se había producido el ataque (eliminamos la línea del /etc/hosts y la entrada de la rogueCA en la lista de autoridades confiables).

Una vez tenemos de nuevo la web auténtica sin MitM de por medio en pantalla, accedemos a su certificado y lo guardamos:




Ya tenemos el certificado .pem de la web de nuestro banco, ahora incluimos este certificado como certificado de servidor aceptado en nuestro navegador:



Una vez hecho todo esto, volvemos a repetir los dos ataques anteriormente mencionados, y volvemos a probar a acceder a la web para comprobar si el certificado de host prevalece sobre el de la CA y estamos a salvo empleando este método.

Por desgracia, seguimos entrando sin ningún tipo de mensaje ni aviso a la web del banco. Observamos el certificado que estamos usando y efectivamente se trata del certificado malicioso.

Esto demuestra que esta solución que en principio parecía que iba a funcionar no lo hace, por lo que habrá que pensar otras soluciones.

Lo que sí funcionó es crearme otro usuario y eliminar absolutamente todos los certificados de las CAs y añadiendome a mano los certificados de los hosts críticos (mis bancos, el correo, etc). Es una solución incómoda pero al menos tenemos la certeza de que estaremos visitando lo que queremos visitar, al menos hasta que todas las CAs dejen de utilizar MD5 o los desarrolladores de navegadores implementen algún tipo de popup avisando que el certificado aceptado está utilizando hash MD5 (es una de las soluciones propuestas por los descubridores de la vulnerabilidad).

Por último, me gustaría comprobar en otros navegadores si esta solución funciona de la misma manera o si puede que resulte efectiva. Estoy pensando en Internet Explorer, Safari, Opera, Chrome, ...

Si alguien lo prueba con alguno de estos navegadores que lo deje como comentario o que nos mandé un correo y lo publicaré (o si lo publicas en tu propia web pondremos el enlace, claro).

jueves, 1 de enero de 2009

Rogue CA

El pasado día 30 de Diciembre en la 25th Chaos Communication Congress (25C3) en Berlín, un grupo internacional de investigadores (principalmente Estadounidenses, Holandeses y Suizos) anunciaron que habían conseguido explotar la conocida debilidad ante colisiones del algoritmo de Hash MD5 para realizar un ataque real contra la infraestructura de PKIs.

Para ello realizaron una búsqueda de aquellas CAs que en su funcionamiento aún no han substituido el uso de algoritmos MD5 por SHA-1, para ello buscaron en las webs presentes en Internet aquellos certificados que al ser firmados por la CA correspondiente habían sido marcados como "MD5 firmado con X", y de esta manera obtuvieron una lista de 6 CAs candidatas a ser vulnerables.

De entre ellas, seleccionaron la CA FreeSSL para realizar su prueba de concepto. Además de usar el algoritmo de hashing MD5, la generación del número de serie del certificado es secuencial, por lo que facilita enormemente la realización del ataque.

El ataque consiste en que, dado que lo que firma una CA con su clave privada (secreta a ojos de todos salvo a si misma) es un Hash de la información contenida en el certificado que firma, si conseguimos dos certificados cuyo contenido, al aplicarle el algoritmo de hash, tengan el mismo resultado, podriamos dar a firmar uno de ellos a la CA y automáticamente ese Hash firmado sería válido para el segundo certificado, aunque la CA no haya "visto" ni tenga ninguna constancia del contenido de este. Ahí es donde entra en juego la debilidad del algoritmo MD5.

De esta manera, este grupo de investigadores crearon dos pares de certificados, uno de una web que dieron a firmar a la CA elegida para la prueba de concepto y otro que se trata de un Rogue CA, es decir, un par de certificados que podrán usar posteriormente para firmar otros certificados.

Evidentemente, obtener dos pares de certificados coherentes y que sufran un colisión MD5 no es una tarea fácil, para ello tuvieron que utilizar el Playstation Lab, un cluster formado por 200 Playstations 3, lo cual les permitió disponer de una gran capacidad de cálculo, y con el que tardaron aproximadamente 3 días en obtener los certificados.

Una vez obtenido los certificados, dieron a firmar el certificado de la web a la CA vulnerable, esta utilizó MD5 y lo firmo. Ese MD5 firmado fue trasladado al certificado público del Rogue CA, con lo que a todos los efectos, todos los navegadores (por poner un ejemplo) que confien en la CA vulnerable van a confiar en esta Rogue CA, puesto que a sus ojos parece ser de su confianza (ha firmado su certificado, o no?...).

Esto va a permitir al poseedor de esta Rogue CA crear certificados para CUALQUIER WEB de Internet y firmarla, con lo que un intruso podría utilizarlo para suplantar la identidad de equipos y realizar ataques MitM.

Pondamos un ejemplo, acabo de conseguir hacerme con un Rogue CA como el que han obtenido este equipo de investigadores. Creo un par de certificados para www.banco.com y los firmo con esta Rogue CA (puedo hacerlo, tengo tanto su clave pública como su privada, lo he creado yo!). En ese momento estoy en disposición de hacer un ataque MitM de algún tipo contra el objetivo, de tal manera que cuando un usuario visite en su navegador https://www.banco.com este se traerá el certificado que he generado, y verá que está firmado por una CA que no reconoce. En una situación normal nos aparecería la típica ventana en nuestro navegador de "este certificado está firmado por una CA que no es de confianza". Sin embargo, en este caso, esta CA, aunque no sea de confianza, está firmada por una CA cuyo certificado sí que está entre los certificados de confianza de nuestro navegador (el de la CA vulnerable), con lo que reconoceremos esta CA como de confianza, y se añadirá a nuestra lista de certificados de confianza:



Una vez que el certificado de nuestro Rogue CA está añadido al navegador como una CA de confianza, cualquier certificado que firmemos con ella estará automáticamente aceptado por el nevagador, es decir, la persona que visita www.banco.com va a acceder a la web sin ningún tipo de aviso de suplantación de certificado, pero sin embargo va a estar aceptando este certificado creado por nosotros, por lo que toda su comunicación podrá ser descifrada y alterada por la persona que realiza el ataque.

Los descubridores de esta vulnerabilidad han desarrollado una prueba de concepto para la cual debereis configurar la fecha de vuestro equipo en Agosto del 2004, no porque sea una limitación del ataque, sino porque han publicado todos los certificados que han empleado, y si no utilizaran un certificado caducado estarian dandole a cualquier atacante todas las herramientas necesarias para realizar este tipo de ataques sin necesidad del cluster de PS3s. Después de acceder a esta web y sin que os dé ningún aviso, podeis revisar la lista de certificados de CAs de vuestro navegador y podreis ver como se ha añadido automáticamente a la lista (ver la imagen anterior).

El ataque, como supongo que estais pensando, parece sencillamente terrorifico, puesto que los certificados parecían la única manera de asegurar que estabamos accediendo a donde creiamos, y parecía la manera de superar ataques de MitM de todo tipo (DNS, ARP, cualquiera). El problema que tiene el modelo de autoridades de certificación es que se basa en la confianza, por lo tanto basta que uno de las CA sea vulnerable a un ataque como este para que la seguridad de todo el modelo se vea comprometida (como pasa en este caso).

Como contramedidas, en mi opinión tenemos dos posibilidades:
  1. Editar los certificados aceptados por nuestro navegador y eliminar todos aquellos que empleen el algoritmo de Hash MD5 para la firma. De esta manera impediremos que nuestro navegador confie en los certificados emitidos por esta CA, con lo que nunca reconocerá la autoridad del Rogue CA, con lo que evitaremos el ataque. Sin embargo, tiene un par de incomodidades, la primera es que requiere ir a nuestro navegador, revisar todos los certificados (que son muchos) y eliminar uno a uno (o montarnos algún sistema automático) los certificados de las CAs que puedan causarnos problemas. La segunda incomodidad es que no vamos a confiar en ningún certificado firmado por estas autoridades, sea legítimo o no, por lo que podemos encontrarnos con sitios que en principio debían estar autorizados pero que al acceder nos mostraré un mensaje de "el certificado está firmado por una autoridad no confiable" o similar. También corremos el riesgo de que el navegador actualice esta lista al aplicar parches y perdamos nuestra configuración. De esto último no estoy seguro, habría que probarlo.
  2. Aunque nuestro navegador puede verificar el certificado por medio de la confianza a las CAs, también podemos aceptar un certificado de un host individual y almacenarlo, aunque esto solo es habitual si no se ha podido verificar la validez del certificado por otros medios. De esta manera, otra posible solución sería incluir manualmente en nuestro navegador los certificados de sitios más críticos, de tal manera que tengamos ya almacenado y confiemos en el propio certificado del host, y no tengamos que irnos a las CAs a comprobar su validez, con lo que evitariamos este vector de ataque. Por supuesto, esto solo se puede hacer con un número limitado de hosts.
Las CAs vulnerables han sido avisadas, así que se preveee que en breve sustituyan sus algoritmos.

Voy a hacer algunas pruebas con la segunda solución a ver si sería realmente efectiva y espero poder poner un post en un par de días explicando que es lo que he hecho para evitar este tipo de ataques.