Hay fallos que generalmente suelen ser pasados por alto a la hora de corregir problemas o hacer una valoración de la seguridad, problemas como cross-site scripting o denegación de servicio suelen pasar desapercibidos y no se les presta gran atención. Sin embargo pueden causar graves perjuicios o permitir la realización de ataques más avanzadossi son combinados o encadenados con otras vulnerabilidades, incluso aunque también estas últimas sean de impacto moderado.
En muchas ocasiones en nuestros trabajos de auditoríanos planteamos cómo calificar la gravedad de un cross-site scripting o una denegación de servicio; desde luego, no permite «entrar» en el servidor o volcar la base de datos (al menos, no directamente), pero el alcance que puede provocar puede ser igual de serio.
En las revisiones realizadas una vez que el cliente ha implantado las medidas recomendadas, o en posteriores auditorías periódicas, comprobamos como problemas como cross-site scripting o denegaciones de servicio no se corrigen, a pesar de que la solución suele ser sencilla.
La experiencia nos dicta que no se presta la suficiente atención en corregir este tipo de problemas, incluso podemos oír que estos problemas no se consideran graves y se da carpetazo al asunto con un «este fallo no permite entrar en el servidor«.
Un caso clásico de cross-site scripting
Recordamos que 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 principalmente hay dos tipos, el persistente y el no persistente (o reflejado).
 |
| Página de la «Presidencia Española de la Unión Europea« supuestamente «hackeada» |
Con el XSS reflejado se consigue que, mediante una URL especialmente modificada, en la web afectada se obtenga otro resultado. Un claro ejemplo, que tuvo una gran repercusión, es el que se realizó hace tres años sobre la página web de la «Presidencia Española de la Unión Europea«, cambiando el vídeo de bienvenida del entonces presidente, por una foto de Mr. Bean.
Si se entraba a la página a través de la URL real, se veía la página en perfecto estado, pero el atacante en este caso publicitó una URL manipulada a través de las redes sociales que cargaba la imagen de Mr. Bean desde otro punto. En muchos medios se publicó la noticia de que un «hacker» había modificado la web. Evidentemente ningún hacker había modificado la web ni mucho menos había entrado en ella; pero el daño, la mala publicidad, la pérdida de imagen, ya estaba hecha.
Ni que decir tiene que el otro tipo de cross-site scripting (XSS persistente) puede resultar aun bastante más peligroso. Este tipo de ataques se producen igualmente al no comprobar los datos de entrada en una web, normalmente formularios, con la diferencia de que 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, se cargará ese código malicioso (en esta ocasión sí se cargará desde la web legítima).
Un ejemplo de la utilización de una vulnerabilidad de cross-site scripting (del tipo permanente) y de la encadenación de vulnerabilidades para realizar un ataque exitoso, se pudo ver recientemente en la intrusión en el servidor de los foros de la comunidad Ubuntu.
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 hay casos en que deben considerarse otro tipo de «impactos«, como el impacto mediático, imagen de la compañía, etc. por tanto, también debe valorarse el daño potencial a la imagen de este tipo de vulnerabilidades.
Estos ataques pueden usarse para inyectar iframes que conduzcan a infecciones o phishing elaborados. El visitante verá el dominio legítimo en la URL e incluso, evidentemente y en su caso, el certificado válido, pero la capacidad de inyectar código permite que la página «amiga» se comporte de manera maliciosa.
También existen casos en que las vulnerabilidades de XSS deben ser 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, ya que podrían permitir la realización de ataques de phishings, distribución de malware desde fuentes teóricamente confiables, suplantación de sesiones, robos de cookies, etc.
Denegaciones de servicio
El caso de las denegaciones de servicio (o «DoS» por sus siglas en inglés) no es muy diferente, en muchos casos estos problemas suelen ser aun más ignorados que los cross-site scripting. No se valora el potencial peligro que puede suponer una denegación de servicio, ya que tampoco llegan a suponer un compromiso de la seguridad de las máquinas. No modifica páginas web ni obtiene listados de claves o de números de tarjetas de crédito. Se trata, sencillamente, de entorpecer el acceso de los usuarios a los servicios de la máquina, pero sin comprometer estos directamente.
En ese sentido, estos ataques acostumbran a ser poco sofisticados y se basan en fallos de diseño inherentes a Internet o a la aplicación. Por otro lado los ataques de denegación de servicio son una constante en Internet desde sus comienzos (sin ir más lejos, el célebre gusano de Morris desencadenó un ataque DoS por un error de programación).
El problema no debe ser pasado por alto, la caída de un servidor puede provocar graves pérdidas a una compañía. En muchos casos un ataque de denegación de servicio puede durar algunas horas, pero en algunos casos puede prolongarse durante días. Pero para una mediana empresa, la caída del servicio durante unas horas puede suponer unas pérdidas de miles de euros en ingresos, publicidad, operaciones no realizadas, pérdida de imagen, posicionamiento web, etc.
Por no hablar de perdidas millonarias como las que puede sufrir una gran empresa, por ejemplo una entidad bancaria, o una empresa de comercio electrónico. Una empresa como Amazon factura 160.000 dólares por minuto (de media), unos 118.600 euros, según RetailNet. Se pueden calcular fácilmente las pérdidas directas que pueden suponer por una caída del servicio. Por no decir de las pérdidas a nivel de reputación, imagen, etc.
En la siguiente entrega analizaremos otros problemas que suelen ser ignorados en las auditorías y que pueden conllevar graves consecuencias.
Más información:
una-al-dia (04/01/2010) El falso «hackeo» de la web de la presidencia española, XSS y lecciones para aprender
una-al-dia (13/02/2000) Ataques masivos. ¿Es tan fiero el león como lo pintan?
una-al-dia (31/07/2013) Crónica del ataque a los foros de Ubuntu
una-al-dia (21/10/2013) No te dejes engañar por las vulnerabilidades leves (y II)
http://unaaldia.hispasec.com/2013/10/no-te-dejes-enganar-por-las_21.html
Antonio Ropero
Los técnicos de seguridad tienden a minimizar demasiado muchos riesgos potenciales, mas que nada para no complicarse la vida…. hasta que llega el desastre.