Sobre el ataque a la web de la Presidencia española

De todos los artículos que he leido sobre el ataque a la web de la Presidencia española, el de Hispasec me parece el más completo de todos.

No sólo aclara cómo es el ataque, sino que además nos habla de que los XSS no son tan livianos, ya que pueden derivar en robo de cookies, phising, introducción de troyanos…

Por lo tanto, no es de recibo que un proveedor que se le ha contratado para, entre otras cosas, llevar la seguridad de la web de Presidencia, deje a los usuarios de esta expuestos a estos problemas. Y, sobre todo, con un error de principiantes como comenté sobre este ataque en elmundo.es

También con este artículo se aclara que no se hackeó los navegadores de los usuarios. Primero, porque no se accedió tampoco a estos. Y, segundo, porque el ataque no residía en ellos.

Os dejo con el fantástico artículo de Hispasec:

“A estas horas ya todo el mundo debe saber lo ocurrido durante el día de ayer con la web de la Presidencia española de la Unión Europea (www.eu2010.es). De este “supuesto ataque” se pueden sacar conclusiones y tratar de aprender algo.

Durante el día de ayer saltó a los medios más generalistas la noticia de que un “hacker” (no se podía emplear otro término) había entrado en la recién inaugurada web de la Presidencia española de la Unión Europea (www.eu2010.es) y había incrustado en ella una imagen del conocido humorista británico Rowan Atkinson en su papel de Mr. Bean.

La noticia está causando un gran revuelo, incluso más después de conocer el dato de que el proyecto había costado más de 11 millones de euros, si bien este presupuesto no solo cubre el alojamiento, desarrollo y seguridad del sitio. También se incluyen otros asuntos relacionados con la instalación y funcionamiento de los medios de telecomunicaciones, sistemas informáticos y servicios de videostreaming de los centros de prensa que se habilitarán en las cumbres internacionales.

Pero realmente el sitio no ha sido vulnerado, en el sentido de que nadie ha tomado su control. En esta ocasión se volvió a cumplir aquello de “no dejar que la realidad estropee una buena noticia”. El problema radicaba en un cross-site scripting (XSS) que a través de una petición especialmente manipulada, había circulado en forma de URL por redes sociales, mensajería, etc. Alguien pulsó sobre el enlace del XSS y la noticia ya estaba creada.

La petición real que circuló tenía la forma:
http://www.eu2010.es/en/resultadoBusqueda.html?query=%3Cscript%3Edocument.write%28%27%3Cimg%20src%3D%22http%3A%2F%2Fblog.tmcnet.com%2Fblog%2Ftom-keating%2Fimages%2Fmr-bean.jpg%22%20%2F%3E%27%29%3C%2Fscript%3E&index=buscadorGeneral_en

Se trata de un XSS tradicional no persistente. Es decir, si no se accede a través de ese enlace, en realidad no se puede ver ningún ataque. No deja de ser un problema de seguridad en el desarrollo de la web, pero no tiene nada que ver con el hecho de que alguien entre y tome el control de unos servidores.

En el blog Security By Default, lo han explicado de una forma muy
instructiva en:
http://www.securitybydefault.com/2010/01/eu2010es-el-fail-es-para.html

Por otra parte, tampoco se puede considerar totalmente correcta la explicación dada por el gobierno español para negar el supuesto “hackeo”:

“El supuesto ataque -señala Moncloa en un comunicado- ha consistido en que se ha empleado una captura de una página de búsqueda del sitio para hacer un fotomontaje al que se ha asignado una dirección (url o enlace) que luego se ha distribuido en Internet, a través de redes sociales y blogs”.

En un fallido intento de restar importancia al asunto, se ha usado la palabra “fotomontaje”, pero la verdad es que la imagen capturada y el fallo de seguridad eran reales, no producto del “PhotoShop”. La explicación certera hubiese sido que la imagen de Mr. Bean, debido a un problema de seguridad, se mostraba “interpretada en” la página, pero no “desde” ella. No hubiese estado de más aclarar que mostrar una imagen es el menos grave los daños que se podrían haber causado. En cualquiera de los casos, el daño a la reputación está hecho, y es quizás el problema más serio a los que se enfrentan los responsables de la página en estos momentos.

Con esto, está claro que la web no fue “hackeada”, pero está igual de claro que contenía un problema de seguridad en su buscador. O bien no se había realizado una auditoría de seguridad o no se había prestado atención a los problemas de cross-site scripting encontrados. Ambas circunstancias suelen ser habituales.

En muchas ocasiones en nuestros trabajos de auditoría nos planteamos cómo calificar la gravedad de un cross-site scripting; desde luego, no permite “entrar” en el servidor, pero el alcance que puede provocar (y aquí tenemos un claro ejemplo) puede ser igual de serio. No se presta la suficiente atención en corregirlo (dado que no se considera un problema grave) y se da carpetazo al asunto con un “este fallo no permite entrar en el servidor”.

En una página sin control de sesión y sin datos que robar, el riesgo de un error como el que nos ocupa actualmente (“de libro” y más habitual de lo que parece) puede ser considerado como de riesgo medio desde el punto de vista técnico, si bien ya hemos visto que el impacto mediático ha sido alto y por tanto también debe valorarse el daño potencial a la imagen de este tipo de vulnerabilidades.

También existen casos en que las vulnerabilidades por XSS son consideradas de riesgo alto por criterios técnicos. Debemos pensar que los vectores de ataques de las vulnerabilidades XSS son variados y dependen del contexto, pudiendo ser utilizados en casos de phishings, distribución de malware desde fuentes teóricamente confiables, suplantación de sesiones, robos de cookies, etc.

Aunque en este caso no llegaron a entrar en el servidor (tal como múltiples medios aseguraban), a efectos prácticos el resultado final que se ha transmitido a la conciencia colectiva es equivalente a si hubieran tomado el control. La imagen que se ha transmitido sobre el gobierno español y sobre Telefónica como encargada del proyecto, tanto en España como en Europa (donde el incidente también ha transcendido), no es nada positiva. Por eso, una vez más es importante recordar la importancia de auditar y corregir cualquier tipo de fallo encontrado, aunque sea un cross-site-scripting que no permita “entrar” en el servidor.”

Fuente: Hispasec