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 avanzados
sin 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ía
nos 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
Fuente:
http://unaaldia.hispasec.com/2013/10/no-te-dejes-enganar-por-las.html
Comentarios
Publicar un comentario