El libro de la bruja‘ es como llama mi hija al libro ‘The tangled web‘ de Michal Zalewski (también conocido como lcamtuf).

Por fin he terminado este magnifico libro sobre seguridad en aplicaciones web modernas y voy a escribir algunos comentarios al respecto.

Para empezar, os recomiendo encarecidamente este libro si queréis comprender cómo funcionan las aplicaciones web y sus mecanismos de seguridad tanto actuales como los que están por venir.

Dicho esto, debo advertiros de que no se trata de un libro sobre programación segura ni se tratan problemas típicos como la inyección SQL.

Realmente, lo que hace este hombre es explicar la relación existente entre  los componentes de las aplicaciones web (servidor web, protocolo HTTP, navegador) y, sobre todo, se centra en las formas de explotar esa relación.

Así mismo, explica las diferencias de implementación de las medidas de protección en los navegadores. Es fascinante ver lo diferente que se comportan. De hecho, parte del libro surge de su estudio de los distintos navegadores reflejado en el browser security handbook.

Partiendo de la idea de que para poder gestionar la seguridad de un entorno, hay que conocerlo bien (el diablo está en los detalles), el mundo de los navegadores es engañosamente sencillo y, en muchos casos, anti-intuitivo.

Por ejemplo, algo tan sencillo como una URL da para un capítulo completo donde te vas a enterar de cosas que no sabías sobre este aparentemente trillado tema. Desde diferentes modos de codificación de los nombres de dominio a los distintos tipos de ‘scheme‘ (la parte que indica el ‘protocolo’ al principio de la URL) tales como ‘data:‘ Zalewski nos cuenta aquello que nos puede hacer pupita y las diferentes formas en las que gestionan los navegadores la URL cuando se construyen pensando en confundirlos.

Lo más importante del libro quizás sea la explicación de las técnicas de aislamiento que mantienen los navegadores. Principalmente el famoso y mal entendido Same Origin Policy (SOP). Aunque su formulación es muy sencilla, hay un conjunto de detalles a tener en cuenta en función de qué elementos estén implicados.

Zalewski también valora las recientes técnicas empleadas por desarrolladores precisamente para escapar al SOP e intercambiar información entre dominios.

Otro aspecto que me gustó mucho es el tratamiento de frames y contenidos insertados de otros dominios. El libro detalla qué medidas de protección frente a scripts insertados en tu página que provengan de otro dominio y cómo implementarlo de forma segura.

En todo el libro, Zalewski incluye su opinión (en muchos casos cínica y realista) y da una perspectiva de cómo han ido evolucionando los distintos navegadores, qué decisiones han tomado ante determinadas situaciones y cuales se plantean en el futuro.

El epílogo es ciertamente sorprendente y revelador ya que plantea hasta qué punto necesitamos más seguridad en el mundo digital que en el mundo real, mediante analogías de la vida cotidiana donde ‘confiamos’ en muchísimas actividades que realizamos y donde nuestros mecanismos de seguridad son, por así decirlo, imperfectos.

Tampoco quiero extenderme mucho más que no os quiero quitar tiempo de leerlo. Os dejo algunas perlas que me gustaron y que fui registrando en twitter.

All signs point to security being largely a nonalgorithmic problem for now

But despite claims to the contrary, such products are no substitute for street smarts and technical prowess—at least not today

Too often, “by keeping your fingers crossed” is the best response we can give

A whole new class of security vulnerabilities that a taxonomy buff might call a failure to account for undocumented diversity

Inquisitive readers are advised to grab Web Application Obfuscation (…) and then weep about the fate of humanity

If it comes to this, cookies will probably have to be redesigned from scratch” hablando de los TLDs genéricos

Instead, additional, sometimes hopelessly imperfect security boundaries need to be created from scratch

La EFF ha comenzado una serie de artículos sobre la seguridad de HTTPS y SSL/TLS en su blog.

En la primera entrega analizan las causas de revocación de certificados HTTPS de un conjunto de CA’s para comprender hasta qué punto la revocación ha sido provocada por un ‘ataque’.

Es muy interesante el conjunto de posibles medios para comprometer la seguridad de tu conexión HTTPS y que completa lo que ya contamos en su día en el artículo HTTPS Tampoco Te Protege Siempre. Un resumen breve:

  • Comprometer la CA o sus aplicaciones web
  • Comprometer routers cercanos a la CA o cercanos a la víctima
  • Comprometer DNS recursivo usado por la CA o generar entradas DNS falsas para la víctima
  • Atacar protocolos que permitan tener acceso a los correos enviados a la víctima
  • Por último, el gobierno del país donde está la CA puede ordenarle que genere certificados o pueden efectuar cualquiera de los ataques anteriores

Los datos del artículo hacen ver que hay un número considerable de certificados que han sido revocados por ‘CA compromise’, que parecen haber aumentado recientemente.

Hemos sido testigos hace poco de otra CA comprometida en Malasia. Y mucho me temo que no va a ser la última.

Y los certificados de la FNMT sin ser reconocidos por los navegadores, para acostumbrar a la gente a ignorar los warnings.

Dicho todo esto, sin embargo, siempre será mejor usar HTTPS que el fatídico plaintext. Por lo que la EFF ha lanzado su plugin de Firefox HTTPS Everywhere para preferir el uso de HTTPS cuando estéis ahí fuera.

Hay que ser absolutamente moderno” — Arthur Rimbaud

Últimamente he estado jugando un poco con IPv6, como pudisteis comprobar en mi post anterior. Ya hace muchos años solía tener el equipo que hacía de router en mi casa conectado con un túnel a la ya extinta 6bone.

El otro día me picó la curiosidad por saber si había alguna forma sencilla de conectarse por IPv6 al ‘mundo exterior’. La característica que buscaba era que el túnel soportara NAT para poder ejecutarlo desde mi equipo en ‘cualquier sitio’.

Por ahora, la mejor forma que he encontrado de hacerlo es usando gogoCLIENT. Un cliente que establece un túnel con la red de gogo6.

Su instalación es muy sencilla y puedes lanzarlo sin configurar nada y funciona perfectamente. Para descargarlo hay que darse de alta en la ‘red social’ de gogo6. Es posible hacer el túnel de forma anónima o bien usando tus credenciales de acceso a su web.

Una vez instalado, debido a que los navegadores solicitan siempre registros AAAA a los DNS… por si acaso pueden usar IPv6, sólo tienes que navegar normalmente y estarás usando IPv6 si el destino ofrece sus servicios por este protocolo.

Un listado de servicios IPv6 en España puede encontrarse en la web www.ipv6es.es. Algunas direcciones IPv6 curiosas, aprovechando que las direcciones pueden tener las 6 primeras letras del alfabeto, también se pueden encontrar en esta página.

Lamentablemente me da que nuestro proveedor no ofrece direcciones IPv6, por lo que no sé si podremos unirnos al World IPv6 day desde este blog, pero al menos podré participar desde el lado de cliente.

Y vosotros ¿os interesa conectaros por IPv6? ¿Vais a participar del World IPv6 day? ¿Pensáis que hay que ser ‘absolutamente moderno’?

Coincidiendo con las noticias del World IPv6 Day (el próximo 8 de junio, reservad vuestras agendas) el otro día me decidí a desempolvar mis limitados conocimientos en el nuevo protocolo que sustentará la Internet del futuro.

Un momento… ¿del futuro?

Si consideramos el uso de IPv6 a escala global pues sí, aún no está (aunque sigue avanzando poco a poco). Pero si consideramos el soporte de sistemas operativos, ya todos lo traen… activado por defecto.

Disponer de funcionalidad que realmente no usas tiene siempre implicaciones de seguridad, claro.

Haced un ip a o un ifconfig y buscad inet6. Lo más seguro es que tengáis ya asignada una dirección IPv6.

No voy a entrar a comentar nada sobre los cambios que supone el IPv6 sobre la versión 4 ni nada que ya bastante podéis encontrar por ahí. Sí quiero incidir en los siguientes puntos interesantes que he podido extraer del vídeo que os empotro al final de este post.

  • Las medidas de filtrado o limitaciones que hayáis puesto para servicios sobre IPv4 no van a ser efectivas en IPv6, lo que significa que es posible que sea posible acceder a servicios limitados a determinados rangos de direcciones IP.
  • Es posible que no encuentres los mismos servicios corriendo en uno y otro protocolo, por lo que la exposición de dichos servicios será diferente.
  • Es bastante probable que tu monitor de red y/o IDS no registre tráfico IPv6, por lo que un intento de explotación usando este protocolo puede pasar más desapercibido.
  • Las herramientas de seguridad suelen tener limitaciones cuando se utiliza IPv6.
  • Normalmente no vas a ser capaz de salir de tu red interna por IPv6 (ya que, a diferencia de equipos y servidores, necesitarías un esfuerzo para conseguirlo. Tendría que estar soportado por tu ISP o emplear algunos de los servicios de túneles disponibles gratuitamente por ahí.

Si tenéis activado IPv6 en algún equipo sobre el que tengáis acceso podéis probar a ejecutar los siguientes comandos:

  • ping6 ff02::1%eth0 para identificar otros equipos con IPv6 activado (y que respondan a ping)
  • ping6 ff02::2%eth0 para identificar equipos con funciones de rutado sobre IPv6 en vuestra red

Sustituid eth0 por la interfaz que queráis usar. Para profesionalizar un poco más el asunto, podéis hacer lo siguiente:

ping6 -c 5 ff02::1%eth0 | cut -d' ' -f4 | grep ^fe80 | sort | uniq | sed -e 's/:$//' > ipv6_addr
nmap -6 -sT -iL ipv6_addr

nmap es una de esas herramientas con limitaciones en el uso de funcionalidad sobre IPv6.

Debido a que la dirección IPv6 autoconfigurada se compone de elementos de la MAC de la interfaz, es posible, mediante un <code>arp -a</code> identificar visualmente a qué equipos (identificados por su dirección IPv4) corresponden las direcciones IPv6 que has encontrado.

Algo así hace automáticamente metasploit con el plugin auxiliary/scanner/discovery/ipv6_neighbor.

Por favor, ved el vídeo porque tiene muchas ideas interesantes desde el punto de vista de seguridad sobre IPv6:

  • Frameworks específicos para análisis y explotación de redes IPv6
  • Uso de socat para pasar de IPv4 a IPv6 y poder ejecutar herramientas que no tienen soporte nativo
  • Servidores de túneles para conectarse a la red mundial de IPv6 y poder participar del World IPv6 Day.
  • etc.

¿Has probado cuántos equipos tienen direcciones IPv6? ¿Has visto si difieren los servicios que ofrecen? Si lo haces no olvides comentarnos tus hallazgos aquí o en el próximo Sec&Beer.

Ah, y si consigues conectarte a Internet con IPv6 no olvides ir a ver a la tortuga bailando.

Por último, el vídeo prometido.

Rick Hayes – Assessing and Pen-Testing IPv6 Networks from Adrian Crenshaw on Vimeo.

HTTPS Tampoco Te Protege Siempre, más conocido por sus siglas: HTTPS (por fín he creado un acrónimo recursivo y, además, ambiguo, jajaja). Bueno, espero que así lo recordéis la próxima vez que os sintáis seguros al ver el candadito o el https:// resaltado o cualquiera de esas formas en las que el navegador te indica que estás usando HTTPS.

El motivo de este post viene debido a que la EFF (Electronic Frontier Foundation) ha iniciado una campaña contra el status quo de la autenticación y cifrado en el mundo de las aplicaciones y sitios web: el uso de HTTPS. Bajo el lema ‘It’s time to fix HTTPS’ han presentado en varios sitios su opinión sobre la situación actual y cómo proponen que se resuelva.

A continuación os dejo la presentación para que la veáis y, además, añado algunas consideraciones que he estado pensando desde que la vi.

El problema

La verdad es que la situación del uso de HTTPS tiene múltiples problemas a la hora de determinar si la página a la que nos conectamos es o no auténtica. Quizá uno de los mayores sea de concepto y se trata de la confianza. HTTPS es, en el fondo, una PKI y como sabréis, estos sistemas se basan en la confianza.

Como dice Marcus Ranum en sus ‘leyes físicas de la seguridad de la información‘ (slide 12): “la cantidad de confianza que ponemos en un sistema puede no tener nada que ver con si se lo merece o no”.

En el caso de la PKI que es el HTTPS, ¿dónde confiamos? Pues principalmente en tres elementos fundamentales:

  • En la CA: La autoridad de certificación es la que firma los certificados (más o menos).
  • En la RA: La autoridad de registro es la que comprueba la identidad de los firmantes (más o menos).
  • En el navegador: Los certificados de las autoridades de certificación en las que ‘confiamos’ por defecto se encuentran en el navegador.

Vamos a ver cada caso por separado.

Autoridad de certificación

La CA es dónde están ‘las joyas de la corona’ de este asunto. Todos nos imaginamos el típico búnquer con guardas donde hacen falta dos llaves que llevan al cuello dos personas distintas y que deben ser giradas al unísono para que se encienda.

Y lo mismo es cierto y todo. El problema es que esa es la CA última (raíz) en la ‘cadena de confianza’. Es probable que con ella se hayan firmado otras CAs delegadas que están en sistemas más ‘accesibles’. Para que cada vez que compras un certificado on-line, no tengan que bajar dos tíos a un búnquer con guardas y girar las llaves que llevan al cuello al unísono, proceder a la firma y tal.

Eso ayuda a que, si una CA delegada es comprometida, se revoca y punto. Pero no hay que generar una nueva CA raíz. Si te das cuenta, claro. Recientes incidentes en RSA o Comodo hacen pensar en la tragedia que supondría una intrusión de alguien creativo en algunas de las empresas que firman certificados.

Porque, una vez generado, nos fiamos plenamente del certificado de un sitio siempre que haya sido firmado por una cadena de CAs que lleve a alguna de las CAs de las que tenemos certificados en nuestro navegador.

O, de lo contrario (y según el navegador que usemos) habrá que aceptar el certificado del sitio como válido… o no podremos verlo y disfrutar de su contenido. Por ejemplo, todas las webs gubernamentales que no tienen la CA raíz de la FNMT… pues hala, a aceptar el certificado. Eso o seguir el cansino proceso de instalar tú mismo la CA raíz de la FNMT en todos tus ordenadores y/o navegadores.

Autoridad de registro

La RA es dónde se valida la identidad de la entidad a la que se emite el certificado. En teoría se comprueba que los datos que se firman realmente pertenecen al que envía la petición. En la práctica esta validación no es tampoco muy exhaustiva (puede serlo más si compras un EV).

Lo cual significa que se podrían conseguir que se tramitaran certificados con datos de otro si se consiguen cumplir los requisitos de la RA. Esto ya ha ocurrido en alguna ocasión. La CA confía en la validación de la RA, por lo que una intrusión en la RA (que está disponible on-line para poder hacer negocio rápido por web) podría dar como resultado solicitudes de certificación falsas.

Navegador

En el navegador (o en el almacén de certificados del sistema operativo) es dónde se mantiene la larga lista de certificados de CA en las que confiamos ciegamente. Porque… ¿cuándo fue la última vez que miraste esa lista? Y, en caso de querer comprobar si los certificados son válidos… ¿cómo lo harías?

En la presentación presentan la posibilidad de insertar certificados de CA en el navegador de forma fraudulenta empleando CSRF. En tal caso, debe ser difícil que nos diéramos cuenta.

La solución propuesta

La presentación analiza diversos factores (incentivos perversos) que hacen que actualmente la situación sea tan negativa.

La solución que proponen la llaman jocosamente TOFU/POP (Trust On First Use; Persistence of Pseudonym). La idea es similar a la confianza que depositamos en el acceso ssh a servidores. Cada servidor tendrá su ‘pseudónimo’ o certificado, confiamos en él la primera vez que nos conectamos y luego, si cambia, seremos informados. Además comenta la posibilidad de diversos métodos para aportar confianza en la primera conexión o cuando haya algún cambio (DNSSEC, redes de confianza, etc.).

¿Qué os parece la idea? ¿ Creéis que nos desharemos del HTTPS tipo PKI para ir hacia un modelo distinto? ¿Os convence esta idea? ¿Cómo crees que afectará al usuario normal? ¿Y cómo se adaptarán los ‘cybercriminales’?

Actualización: No os perdáis este post en Security by default sobre mitos en HTTPS.