Descubriendo los días cero
Hace dos décadas, los días cero a menudo se hicieron ampliamente conocidos muy rápidamente, generalmente por una (o ambas) de dos razones:
- Se lanzó un virus o gusano autopropagante para explotar el error. Esto tendía no solo a llamar la atención sobre el agujero de seguridad y cómo se estaba abusando de él, sino también para garantizar que las copias de trabajo autónomas del código malicioso se enviaran por todas partes para que los investigadores las analizaran.
- Un cazador de errores que no estaba motivado por ganar dinero lanzó un código de muestra y se jactó de ello. Paradójicamente, tal vez, esto perjudicó simultáneamente la seguridad al entregar un «regalo gratis» a los ciberdelincuentes para que lo usaran en ataques de inmediato, y ayudó a la seguridad al atraer a investigadores y proveedores para que lo arreglaran o encontraran una solución alternativa rápidamente.
En estos días, el juego de día cero es bastante diferente, porque las defensas contemporáneas tienden a hacer que las vulnerabilidades del software sean más difíciles de explotar.
Las capas defensivas actuales incluyen: protecciones adicionales integradas en los propios sistemas operativos; herramientas de desarrollo de software más seguras; lenguajes de programación y estilos de codificación más seguros; y herramientas de prevención de ciberamenazas más potentes.
A principios de la década de 2000, por ejemplo, la era de los virus de propagación súper rápida como Code Red y SQL Slammer, casi cualquier desbordamiento del búfer de pila, y muchos, si no la mayoría, desbordamientos del búfer de pila, podrían convertirse de vulnerabilidades teóricas en explotaciones practicables en orden rapida
En otras palabras, encontrar exploits y «eliminar» los días 0 a veces era casi tan simple como encontrar el error subyacente en primer lugar.
Y dado que muchos usuarios se ejecutan con Administratorprivilegios todo el tiempo, tanto en el trabajo como en el hogar, los atacantes rara vez necesitaban encontrar formas de encadenar vulnerabilidades para apoderarse por completo de una computadora infectada.
Pero en la década de 2020, los exploits viables de ejecución remota de código (errores (o cadenas de errores) que un atacante puede usar de manera confiable para implantar malware en su computadora simplemente atrayéndolo para que vea una sola página en un sitio web con trampas explosivas, por ejemplo) son generalmente es mucho más difícil de encontrar y, como resultado, vale mucho más dinero en el cyberunderground.
En pocas palabras, aquellos que se apoderan de las hazañas de día cero en estos días tienden a no presumir más de ellas.
Tampoco tienden a usarlos en ataques que harían obvio el «cómo y por qué» de la intrusión, o que llevarían a que las muestras de trabajo del código de explotación estuvieran disponibles para el análisis y la investigación.
Como resultado, los días cero a menudo se notan en estos días solo después de que se llama a un equipo de respuesta a amenazas para que investigue un ataque que ya tuvo éxito, pero donde los métodos de intrusión comunes (por ejemplo, contraseñas suplantadas de identidad, parches perdidos o servidores olvidados) no parecen funcionar. haber sido la causa.
Desbordamiento de búfer expuesto
En este caso, ahora designado oficialmente como CVE-2022-4135 , el error fue informado por el propio Grupo de análisis de amenazas de Google, pero no se encontró de manera proactiva, dado que Google admite que es «consciente de que existe un exploit […] en la naturaleza». .”
A la vulnerabilidad se le ha asignado una gravedad Alta y se describe simplemente como: Desbordamiento de búfer de almacenamiento dinámico en GPU .
Los desbordamientos de búfer generalmente significan que el código de una parte de un programa escribe fuera de los bloques de memoria asignados oficialmente y pisotea los datos en los que luego se confiará (y, por lo tanto, se confiará implícitamente) en otra parte del programa.
Como puede imaginar, hay muchas cosas que pueden salir mal si se puede desencadenar un desbordamiento de búfer de una manera tortuosa que evite un bloqueo inmediato del programa.
El desbordamiento podría usarse, por ejemplo, para envenenar un nombre de archivo que alguna otra parte del programa está a punto de usar, haciendo que escriba datos donde no debería; o para alterar el destino de una conexión de red; o incluso para cambiar la ubicación en la memoria desde la cual el programa ejecutará el código a continuación.
Google no dice explícitamente cómo se podría (o se ha explotado) este error, pero es prudente suponer que es posible algún tipo de ejecución remota de código, que es en gran medida sinónimo de «implantación subrepticia de malware», dado que el error Implica un mal manejo de la memoria.
¿Qué hacer?
Chrome y Chromium se actualizan a 107.0.5304.121 en Mac y Linux, y a 107.0.5304.121 o 107.0.5304.122 en Windows (no, no sabemos por qué hay dos versiones diferentes), así que asegúrese de comprobar que tiene la versión números iguales o más recientes que esos.
Para verificar su versión de Chrome y forzar una actualización si está atrasado, vaya al menú de tres puntos (⋮) y seleccione Ayuda > Acerca de Chrome .
Microsoft Edge, como probablemente sepa, se basa en el código Chromium (el núcleo de código abierto de Chrome), pero no ha tenido una actualización oficial desde el día anterior a que los investigadores de amenazas de Google registraran este error (y no ha tenido una actualización que enumera explícitamente las correcciones de seguridad desde el 2022-11-10).
Por lo tanto, no podemos decirle si Edge se ve afectado o si debe esperar una actualización para este error, pero le recomendamos que esté atento a las notas de lanzamiento oficiales de Microsoft por si acaso.
Fuente:Sophos Security News
