El error de subestimar las vulnerabilidades leves o hacerse presa del pánico.
Como dice el dicho, “ni tan calvo ni con dos pelucas”, con esto me refiero a que en ocasiones se crean alarmas innecesarias a raíz de algún malware, fallo o vulnerabilidad detectada ya sea en un software o hardware, hace poco comentaba sobre el fallo en Internet Explorer que podía ser explotado por atacantes y que no era razón para alarmarse al extremo aunque si era necesario conocer el problema y tomar los posibles correctivos para evitar problemas.
Por otra parte, es un error desestimar completamente ya sea por ignorancia o desconocimiento, las posibles amenazas y su nivel de incidencia sobre determinados sistemas. Constantemente me sorprendo al ver equipos de amigos, conocidos y empresas que a simple vista parecieran estar funcionando perfectamente pero mirándolos más en detalle, se aprecian ciertos indicadores de los que ya he comentado con anterioridad como movimientos erráticos en el puntero del mouse, la luz del disco duro parpadea sin cesar aun sin que el usuario este realizando alguna operación con el equipo, errores al cargar una pagina web y el más obvio de todos, que es ver como la luz indicadora del router o modem de Internet parpadea sin cesar indicando que se esta enviando o recibiendo datos sin que el usuario este enviando o descargando algo y con el tiempo aparecen barras de herramientas en el navegador, desaparecen archivos, cada vez la PC se vuelve más lenta y pare de contar y el colmo es que lo veo pasar a usuarios comunes como a profesionales del área de la tecnología.
El que pasen estas cosas en los PC de las casas no me extraña ya que la gran mayoría no se preocupan por estar al tanto de como es la tecnología, solo son simples usuarios y como tales, solo se dedican a utilizar o “mal utilizar” sus equipos, lo grave es que pase en empresas donde se tiene un departamento de informática con profesionales que se les paga para que en teoría eviten en lo posible estas cosas o por lo menos minimicen el impacto y corrijan el problema de manera eficiente.
Es un error subestimar un fallo o vulnerabilidad
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).
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).
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.
Cross-site Request Forgery, la vulnerabilidad incomprendida
Este tipo de vulnerabilidad permite a un atacante ejecutar funcionalidad de una web determinada a través de la sesión en esa web de otro usuario. Su mecanismo es sencillo, pero entender como funciona y su impacto no lo es y mucho menos para profesionales ajenos al mundo de la seguridad. Para ello necesitamos montar una prueba de concepto realista y detallar cada paso efectuado en el ataque. Si no se entiende este ataque y su impacto, la interpretación del mismo suele ser pobre y se tiende a infravalorar su peligrosidad.
En una ocasión uno de nuestros clientes nos pidió una prueba de concepto detallada para entender su impacto ya que con la descripción del ataque no percibía el peligro y descartaba una solución a corto plazo, incluso nos solicitaba cambiar su calificación a una más moderada. Cuando se efectuó dicho test observó como un simple correo con un enlace a una imagen, sin asociación ninguna a la marca, llevaba al usuario a una web de Hispasec sin relación con la suya. ¿Ya está? preguntó el cliente. Entonces le pedimos que accediera a la cuenta de pruebas de su aplicación web y observara los cambios. A partir de ese momento las piezas encajaron y pudo ver el peligro real que suponía.
CVSS, un estándar para medir la gravedad
Está claro que hay que dar un nivel de gravedad para cada problema. Aunque un cross-site scripting pueda llegar a ser grave, evidentemente sería mucho peor que la aplicación tuviera una vulnerabilidad de inyección SQL con capacidad para ejecutar volcar la base de datos completa. Para solucionar el "problema" de medir la gravedad de una vulnerabilidad se creó el estándar CVSS (Common Vulnerability Scoring System).
El CVSS es un sistema de puntuación de vulnerabilidades diseñado para proporcionar un método abierto y estandarizado para la clasificación de vulnerabilidades. CVSS pretende ayudar a las empresas a priorizar y coordinar una respuesta a los problemas de seguridad.
Las puntuaciones asignadas por el CVSS se derivan de la medición de tres grupos diferenciados: El grupo "base" representa las propiedades de una vulnerabilidad que son inmutables en el tiempo (como la complejidad, si es local o remota, o si se requiere autenticación, así como el grado en que compromete la confidencialidad, integridad y disponibilidad del sistema), el grupo "temporal" mide propiedades que pueden cambiar con el tiempo (como la existencia de parches o código para su explotación) y el grupo "medioambiental" que mide las propiedades de una vulnerabilidad que pueden depender del propio entorno de la organización en el que se usan los sistemas. De la métricas base se deriva una puntuación de 0 a 10, que puede verse reducido en función de los valores de las métricas "temporal" y "medioambiental".
El CVSS se ha convertido en un estándar y es plenamente utilizado por un gran número de organizaciones, que incluso en los propios avisos o boletines de seguridad ya notifican los valores del CVSS.
Al final, el CVSS nos da una puntuación entre 0 y 10 que permite categorizar la gravedad de una vulnerabilidad, a mayor valor, más gravedad. De esta forma una correcta aplicación del CVSS puede resultar de gran utilidad en las organizaciones, ya que puede ayudar a determinar la urgencia para instalar un determinado parche, o planificar el orden en que deben ser instaladas las actualizaciones.
Aunque también hay que tener cuidado en su aplicación, en ocasiones nos hemos encontrado con organizaciones que dentro de su política de actualización no parchean vulnerabilidades con un CVSS menor de un determinado valor. En definitiva, el CVSS puede ser de utilidad para determinar la prioridad a la hora de actualizar, pero no para establecer que una vulnerabilidad no merece ser parcheada.
Todas las vulnerabilidades tienen su importancia
Está claro que una vulnerabilidad 0-day, con un exploit público, que afecte a todos los Windows, fácilmente explotable es mucho más peligrosa que un simple cross-site scripting; pero también hay que tener claro que no hay que descuidar las vulnerabilidades de menor importancia, ya que también pueden conllevar graves consecuencias si son explotadas con éxito. Por eso, una vez más, es importante recordar la importancia de auditar y corregir cualquier tipo de fallo encontrado.
Más información:
No hay comentarios:
Publicar un comentario