"Exploit 0" day de Css3. Grave vulnerabilidad content-injection attacks

Css representa en estos momentos un gran riesgo y peligro por ser una vía fácil para los ataques por inyección de contenido (content-injection attacks) al utilizar las hojas de estilo como vector de ataque.

"Exploit 0" day de Css3. Grave vulnerabilidad content-injection attacks

Por Kseso ✎ 2

css content injectionLa llegada del fin del año no viene con buenas noticias para la seguridad y el anonimato de los usuarios de navegadores modernos al concurrir ciertas propiedades Css con las últimas novedades introducidas en los motores o máquinas de js y Css de esos navegadores.

Pese a que este es un tema que viene debatiéndose de forma cuasi secreta en las listas de discusión del W3c y los desarrolladores de los navegadores, no ha sido hasta hace pocas fechas que explotó y ha salido de ellas siendo difundido templadamente.

Hace unos días, inocentes de nosotros, todos nos echamos unas risas tras el tuit de @HugoGiraudel que incluía la imagen lateral y decía:

A French TV channel using CSS as an illustration for cyber-terrorism.
CSS is scary. And dangerous.
Hide your kids.

Yo también me hice eco en las redes de lo que parecía una gracia fruto del desconocimiento de ese canal de Tv francés.

Pero como te decía al inicio, de desconocimiento o gracieta de ese canal de tv no tiene nada. De hecho es bastante la información que se encuentra en la red alertando sobre este grave fallo de seguridad de Css, toda ella publicada muy recientemente, incluido el consorcio W3c.

El uso de Css representa en estos momentos un gran riesgo y peligro por ser una vía fácil para los ataques por inyección de contenido (content-injection attacks). Este tipo de ataque se ha demostrado posible no sólo usando los scripts, que también, sino, y repito, utilizando como vector de ataque nuestras hojas de estilo.


El W3c ha publicado este mismo mes una actualización de su documento "Content Security Policy 1.0" incluyendo un capítulo especial (el 6) dedicado a las políticas de seguridad y su análisis en las hojas de estilo.

Así mismo, expertos en seguridad web de reconocido prestigio, como Mike West, están advirtiendo de este riesgo en foros de discusión con reputación de seriedad y fiabilidad y nada alarmistas o sensacionalistas como CSSConf EU 2013:

I had the distinct pleasure of talking with folks at this year’s CSSConf EU about the dangers of content-injection attacks.
They’re not just for JavaScripters, you see: CSS is dangerous too!

A continuación intentaré explicar en qué consiste el problema, cuándo o en que circunstancias se puede dar y una demo para que tú mismo puedas ver en acción en este blog un uso del Exploit "0 day" de Css

Descripción de la vulnerabilidad de seguridad

Este exploit ha sido clasificado como muy grave, hay quien lo etiqueta incluso como "0 day", ya que el atacante puede conseguir los permisos y tomar el control de los dispositivos multimeda del visitante de una página web. Esto es, puede controlar y activar a voluntad la cámara y el micrófono de tu ordenador o de tu teléfono sin que tú seas consciente de que estás siendo grabado y con total desconocimiento del dueño de la página.

Demo exploit "0 day" de Css

Cuándo ocurre el fallo de seguridad

Este es un aspecto que o bien no está del todo claro o los descubridores del fallo han preferido no hacer públicos los detalles concretos y específicos.

Todo indica, hasta donde se conoce, que sólo ocurre con navegadores modernos en sus últimas versiones al coincidir que se utilizan una serie de propiedades Css, que ahora detallaré, con alguna de las novedades o mejoras que estos navegadores han introducido en sus motores o máquinas que interpretan js (o cualquiera de sus librerías como jQuery) y la de Css.

Su potencialidad aumenta en aquellos prefabricados o CMS como Blogger, WP y similares especialmente si se utilizan recursos de terceros (como pluggins o widgets) de dudoso origen y fiabilidad y con escaso o nulo control y conocimiento de los códigos y recursos (incluido los estilos) que utilizan e incrustan en nuestra página.

Propiedades Css presuntas culpables

css vulnerableA las ya conocidas y potencialmente usables para el Css Cross-site scripting como las que hacen una llamada a recursos u objetos ajenos a la propia hoja de estilos vía, por ejemplo, url o src como son las imágenes o vídeos para los fondos (background-image) o las tipografías incluidas con la regla @font-face, a estas se ha descubierto que se suman aquellas propiedades que admiten múltiples valores como border-radius, box-shadow, transformaciones o animaciones, gradientes css... étc, cuando en la declaración de la propiedad se incluye, ademas de la forma estándar, la propiedad con prefijos privativos.

Si además en la sintaxis de la declaración se utilizan estos prefijos privativos (-moz-, -webkit-, -o-, -ms-) con alguna versión obsoleta de la propiedad o sus valores el riesgo aumenta. Por ejemplo, si declaras un gradiente css e incluyes la forma antigua con sus prefijos.

Especialmente peligroso es el uso de incluir imágenes codificadas en base64 en las hojas de estilos así como el uso de caracteres especiales o según qué símbolos en la propiedad 'content' si no se emplea la codificación propia de css.

Resumiendo: La vulnerabilidad de Css descubierta ahora no es la ya conocida, advertida y prohibida por las especificaciones del cross-domain, que también se ha visto agravada, sino la derivada de utilizar propiedades nuevas de Css3 conjuntamente con prefijos privativos. Riesgo que aumenta si se usa la forma antigua u obsoleta y "deprecated" en el nombre de la propiedad (como el viejo flexblox) o en sus valores (como border-radius, gradientes, étc).

Siendo terríblemente preocupante todo lo anterior, se ve elevado a la enésima potencia si la página usa estilos declarados en línea. Esto es, dentro de las etiquetas de apertura de los elementos en el html. Esto es así porque bastaría con usar poco más que una instrucción 'unsafe-inline' para explotar la vulnerabilidad de Css.

Demostración del exploit "0 day" de Css

A continuación podrás ver un ejemplo de esta vulnerabilidad de Css. La demostración consiste en acceder a la cámara de tu equipo, necesitas tener una para verlo en acción, para activar el vídeo e incluso tomar imágenes de lo que con ella se ve.

Por razones obvias la simulación no está lograda utilizando totalmente este exploit "0 day" de Css, por lo tanto la señal del su uso de la cámara (luz indicadora) se encenderá y además la página al cargarse te pedirá permiso para acceder a ella.

También, como es lógico, para tomar una captura (imagen) desde ella es necesario que pulses el botón que incluyo a tal efecto.

Por supuesto que en ningún momento nada, absolutamente nada, de lo que la cámara muestre será guardado, tampoco la imagen si decides hacer click. En última instancia, si lo prefieres y así quedas más tranquilo siempre puedes poner cualquier objeto, como un libro o revista, delante de ella.

Demo exploit "0 day" de Css

Soluciones al exploit "0 day" de Css

Lamentablemente a día de hoy poco está en tus manos y menos podrás hacer para que tus páginas, si cumplen con los condicionantes que hacen posible este grave fallo de seguridad de las hojas de estilo, o tu equipo o teléfono no sean vulnerables a él.

Al ser provocados por los motores de interpretación de js y Css de los propios navegadores lo drástico sería navegar con las opciones "Disable all js" y "Disable all Css" activadas.

En cuanto a impedir que sean tus webs las infectadas sólo cabe vigilar atentamente el contenido de tus estilos (de todos: tanto los incluidos en el head, como en el body, alojados en archivos .css como los en línea) para asegurarte que no hay código extraño o que notes comportamientos o estilos no habituales.

Especialmente conveniente la vigilancia exhaustiva si estás utilizando las propiedades y/o valores de la forma indicada anteriormente.

No obstante, los desarrolladores de los navegadores, especialmente Chrome y Firefox, ya han indicado estar trabajando para incluir a la mayor brevedad posible solucciones a este gran problema de Css.

En última instancia siempre puedes recurrir a pegar un sello para tapar la lente de la cámara y el micrófono. Las pruebas han demostrado mayor efectividad si utilizas un sello timbrado (FNMT Clase 2CA) expedido por la FNMT-RCM en su página web.

Ramajero Argonauta, Enredique Amanuense de CSS.
#impoCSSible inside
Dicen que, en español, EsCss es el mejor blog de CSS. Posíblemente exageren.
@Kseso EsCss Don Kseso Kseso

Comentarios: 2

  1. Te fuiste al c#☠⛈✗✴o con lo del sello, pero estuvo muy bien, me divertí un rato.
    XD

    ResponderEliminar
  2. dia de los inocentes?
    jaja buen artículo XD

    ResponderEliminar

EsCss RSS del Blog RSSS Comentarios Humans.txt ᛯ Diseno por Kseso SiteMap