#Disclosure
Buenos días amigos de lo imposible, lo que vengo hoy a contaros en realidad es un public disclosure de lo que considero un fallo de seguridad del chrome (ellos no lo consideran tal). Previamente a este disclosure el día 20 de marzo me puse en contacto con ellos para comunicárselo, y aunque reconocen el ataque e incluso le pusieron nombre, decidieron que no era fallo del navegador (y por supuesto que para mi lo es).
Antes de que lo arreglen diciendo que no lo van a hacer, no sería mi primera vez (google es muy de eso). Prefiero hacer el public disclosure.
Does this fall into the category of "working as intended"? Have the reporters invented "printjacking?"
En realidad, ellos se escudan/defienden en la mala configuración del servidor atacado. Pero entonces ¿por qué existe el XSS auditor de chrome? Si es una mala programación de la web, tampoco es del navegador, ¿por qué existe el bloqueo de contenido mixto http/https? Es otra mala configuración por parte de la web visitada, y así cada una de las protecciones existentes en el navegador.
El enlace de la conversación es el siguiente: https://bugs.chromium.org/p/chromium/issues/detail?id=703262 aunque es privado y no tendréis acceso.
Cabe decir que el fallo no es reproducible en FireFox, y se trata de un fallo que requiere de algo de ingeniería social. Sin mas dilación, paso a detallar su funcionamiento, paso a liberar el «Printjacking».
#Breve introducción
Para entender el fallo primero hay que tener unos conocimientos breves del CORS. El estándar de CORS es un mecanismo mediante el cual se definen si una petición web tiene que ser o no bloqueada según que criterios, el bloqueo se realiza por medio de las siguientes cabeceras:
- Access-Control-Allow-Origin
- Access-Control-Allow-Credentials
- Access-Control-Expose-Headers
- Access-Control-Max-Age
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
También existe una cabecera que es ‘X-Frame-Options‘ que impide poner una página dentro de un iframe. Os animo a estudiar dichas cabeceras http.
Que se puede hacer con toda esta ristra de cabeceras, pues bloquear por ejemplo, que una página web se pueda incrustar en un iframe (al igual que se haría en un CSRF) o que no se pueda hacer si el origen no es del mismo host o de otro en concreto (a grandes rasgos). Hasta ahí bien, ¿no?
#Liberando al kraken
Vale pues supongamos el siguiente escenario tan común.
Un router o una web tiene una llamada api, mediante la cual sacas datos del usuario (incluso la contraseña he llegado a ver), básicamente cualquier tipo de información sensible que el atacante quiere obtener. ¿Cómo podría enviarse el atacante el contenido de esa web?
Estamos pensando en que crearíamos una web maliciosa (al estilo de un CSRF cualquiera) y en un iframe, cargaríamos la página que no está protegida con las cabeceras anteriormente descritas. Pero, ¿qué maneras tengo de enviarme esa información o de robarle los credenciales? Las ideas que se me ocurrieron para esta tarea fueron las siguientes:
Acceder por el dom, vía javascript y enviármelo por una petición AJAX(el navegador lo bloquea)Utilizar las funciones de captura de pantalla de Html5 para hacer una captura del iframe, ocultarlo e enviármelo(el navegador lo bloquea nuevamente, curiosamente la zona capturada del iframe, viene en blanco)- Pedirle amablemente al señor que envíe el contenido de la página (veamos de que manera podemos hacerlo sin que se de cuenta)
Estuve estudiando la manera hasta que dí con una forma 100% efectiva. El «Printjacking«.
Consiste en engañar al usuario para que imprima una página, que secretamente tiene el iframe oculto detrás de una imagen, con la información sensible. A modo de «imprima su billete de avión», «gane un iphone 7» o cualquier otro engaño.
Si conseguimos que ese usuario nos envíe el pdf resultante o el xps de esa impresión, tendremos en nuestro poder la información sensible (ya que irá incrustada dentro del documento), ¿easy no? El equipo de chrome, dice que sería igual que convencerlo de que me envíen la página web dando a «guardar como». Pero seamos serios, la gente está acostumbrada a trabajar con pdf o xps, un html no saben ni lo que es, y además por javascript no podemos invocar dicha opción y darlos el trabajo hecho.
Tenéis todo el código de la prueba de concepto en mi github https://github.com/shargon/Fwhibbit/tree/master/ChromePrintjackingExploit
Como el comportamiento es diferente para pdf y xps, os enseño las poc correspondientes.
#POC en PDF
#POC en XPS
¿Estamos asistiendo al nacimiento de una nueva técnica de phising debido a la despreocupación del equipo de chrome?
Espero que os haya gustado, no seáis malos y disfrutéis de unas maravillosas y merecidas fiestas. ¡Hasta la próxima!