En los últimos días, tanto Apple como Adobe han publicado actualizaciones para solucionar agujeros de seguridad de día cero que ya estaban siendo explotados por los atacantes.
Recuerda que un exploit de día cero es un fallo de seguridad (normalmente, uno que permite a los ciberdelincuentes entrar y ejecutar o implantar el software que deseen) que ha sido descubierto y aprovechado por los atacantes antes de que exista un parche disponible.
En otras palabras, no importa lo rápido que se actualice contra un día cero una vez que se anuncia el parche, ya se sabe que alguien (esperamos que no seas tú) ya ha sido atacado, incluso si se parchea rápidamente.
En pocas palabras, la parte cero de la jerga te recuerda que hubo cero días durante los cuales podrías haber parcheado proactivamente, sin importar lo mucho que lo intentaras, porque los atacantes llegaron primero.
De forma molesta, pero quizás comprensible, tanto Apple como Adobe sólo admitieron brevemente los días cero que solucionaron.
Apple se limitó a decir que era “consciente de un informe de que [CVE-2022-22620] podría haber sido explotado activamente”. Abobe fue un poco más comunicativa, admitiendo que era “consciente de que CVE-2022-24086 ha sido explotado en ataques muy limitados”:
No hay pistas sobre cómo o dónde se llevaron a cabo los ataques, qué buscaban los atacantes, qué consiguieron, qué indicadores de compromiso (IoC) puedes buscar en tus propios registros, cómo evaluar tu riesgo, o si hay alguna solución o mitigación que puedas aplicar hasta que estés seguro de que todo ha sido parcheado.
Ahora es el turno de Google de levantar la mano ante un fallo de día cero recién parcheado: la empresa ha publicado la última actualización de Chrome, con un comentario de lo más decepcionante estilo Apple, en el que afirma ser “consciente de los informes de que existe un exploit para CVE-2022-0609 que está siendo utilizado”.
Tormenta de errores use-after-free
Curiosamente, el CVE-2022-0609 fue sólo uno de los cinco errores use-after-free corregidos en esta actualización.
Un error use-after-free ocurre cuando una parte de un programa solicita que se reserve un bloque de memoria para su propio acceso exclusivo, utiliza esa memoria durante un tiempo y luego renuncia a su derecho sobre ese bloque de memoria, sólo para continuar accediendo a esa memoria de todos modos, incluso después de que haya sido reasignada a alguna otra parte del programa, o quizás incluso a otro programa totalmente distinto.
Imagina que estás en medio de una presentación de PowerPoint que has revisado cuidadosamente y ensayado mucho, pero justo antes de pasar de la diapositiva 4 a la 5, alguien que cree que está actualizando la diapositiva 5 de tu presentación se las arregla para escribir sus nuevos datos en tu presentación. Acabarías presentando alegremente el contenido de otra persona como si fuera tuyo, sin darte cuenta del inminente desastre. Incluso si esto ocurriera por accidente, debido a un error genuino de un colega de confianza, el resultado sería probablemente molesto, e incluso podría ser embarazoso. Pero si la otra persona sabía perfectamente lo que estaba haciendo, y cómo orquestarlo, y si programó su “intervención” de forma deliberada y maliciosa, el resultado podría ser desastroso. Esta es una analogía de la crisis de contenido que pueden causar los fallos use-after-free, siendo a menudo la implantación de malware el efecto secundario inesperado y no deseado de un agujero use-after-free explotable.
Por qué son importantes los días cero en los navegadores
Los días cero provocados por una mala gestión de la memoria mientras el navegador renderiza una página son siempre preocupantes.
Esto se debe a que los agujeros de ejecución remota de código (RCE) en un navegador a menudo conducen a los llamados drive-by downloads, donde el simple hecho de visitar una página web maliciosa podría implementar malware en tu ordenador o tu teléfono.
Este tipo de infección también se denomina “ataque sin clic”, porque los atacantes no necesitan convencerte (o convencer a tu ordenador) de que hagas algo más que ver su contenido, algo que generalmente se supone que es seguro porque ocurre dentro de la ventana del navegador.
La mayoría de los ataques de phishing, por ejemplo, necesitan persuadirte para que rellenes y envíes un formulario web fraudulento, para que abras un archivo adjunto malicioso o para que aceptes descargar e iniciar un archivo que no esperabas y que no pediste.
Eso da a los usuarios bien informados una buena oportunidad de evitar el ataque, porque generalmente no puede ocurrir por defecto, o por error.
Sin embargo, un ataque “cero-clic” o “drive-by” puede producirse “por defecto”, sin dar al usuario mejor formado la oportunidad de decir “¡no!” y evitar el peligro.
¿Qué hacer?
Comprueba que tienes Chrome (o Chromium) 98.0.4758.102 o posterior. Puedes ver el número de versión visitando la URL especial chrome://version en tu navegador Chrome (o basado en Chromium): el número de versión de cuatro partes debería aparecer en la primera línea de la salida, así:
No podemos decirte si Edge, probablemente el siguiente navegador más utilizado basado en Chromium, está afectado por este fallo, y los números de versión de Edge no se corresponden con la numeración de Chrome después del par inicial de números “mayor/menor” (en este caso, 98.0).
La versión estable de Edge aún no tiene una actualización [2022-02-15T16:10Z], al menos en su repositorio oficial de Linux, desde donde actualizamos, pero sospechamos que habrá una pronto.
Para comprobar si ya estás ejecutando la última versión tanto en Chrome como en Edge, haz clic en los tres puntos (el menú Más) en la parte superior derecha, y luego utiliza Ayuda y Acerca de para acceder al cuadro de diálogo de la versión más la actualización.
Actualización. El repositorio de Edge enlazado arriba fue actualizado el 2022-02-16 con Edge 98.0.1108.55. La URL edge://version (o, para el caso, chrome://version) reportará el número de versión de cuatro partes que estás usando.
Dejar un comentario