zero day es un término ámplio que describe vulnerabilidades de seguridad que son desconocidas para los usuarios y para el fabricante o desarrollador

Hace pocos días el equipo de Google Security dio a conocer mediante una publicación de blog, un informe sobre toda la recopilación del año pasado (2022) relacionado con las vulnerabilidades 0 day en las que aparecieron exploits antes de que se desarrollaran parches para software vulnerable relacionado.

En su informe presentado, mencionan que durante el 2022, el equipo de Project Zero identificó 41 vulnerabilidades 0 day (un 40 % menos que las encontradas en 2021) y que a pesar de una disminución notable en el número de vulnerabilidades, el numero continúa siendo mayor al promedio de los 6 años anteriores.

Esta es la cuarta revisión anual de Google de 0 días explotados en estado salvaje [ 2021 , 2020 , 2019 ] y se basa en la revisión de mediados de año 2022. El objetivo de este informe no es detallar cada hazaña individual , sino analizar las hazañas del año en su conjunto, buscando tendencias, brechas, lecciones aprendidas y éxitos.

Grafica de numero de vulnerabilidades zero day de los ultimos años

Se menciona que la aparición de una gran cantidad de vulnerabilidades del tipo zero day se ve potencialmente facilitada por factores como la necesidad continua de que los atacantes utilicen exploits para llevar a cabo ataques y la simplificación de los métodos para encontrar tales vulnerabilidades, ademas de que el aumento de la velocidad de aplicación de parches obliga a buscar vulnerabilidades este tipo en lugar de utilizar problemas ya conocidos. Este tambien es factor, ya que el desarrollo deficiente de parches permite a los autores de exploits encontrar nuevos vectores de ataque para vulnerabilidades ya conocidas.

Por ejemplo, más del 40 % (17 de 41) de los exploits de día cero identificados en 2022 estaban relacionados con vulnerabilidades previamente reparadas y divulgadas públicamente. Tal oportunidad surge debido a correcciones de vulnerabilidades insuficientemente completas o de baja calidad: los desarrolladores de programas vulnerables a menudo corrigen solo un caso especial o simplemente crean la apariencia de una solución sin llegar a la raíz del problema. Dichas vulnerabilidades de día cero podrían haberse evitado potencialmente con una investigación más exhaustiva y la corrección de las vulnerabilidades.

La disminución en el número de vulnerabilidades 0 day en comparación con 2021 se puede explicar por el hecho de que se necesita más tiempo, conocimiento y dinero para crear exploits, el número de vulnerabilidades explotables disminuye debido al uso más activo de métodos de protección, para cada exploit, a menudo se desarrollan nuevas técnicas operativas.

La disminución de las vulnerabilidades 0 day también puede deberse al uso de métodos de ataque más simples, como el phishing y la distribución de malware. También puede verse afectado por la capacidad de prescindir de exploits para vulnerabilidades ya conocidas debido a que los usuarios retrasan la aplicación de correcciones.

El informe concluye que los exploits para vulnerabilidades parcheadas de día N en Android no son menos efectivos que las vulnerabilidades 0 day debido a la demora de los proveedores en generar actualizaciones. Por ejemplo, incluso si Google corrige rápidamente una vulnerabilidad en la plataforma central de Android, es posible que la solución para esta vulnerabilidad no esté disponible para la mayoría de los usuarios hasta meses después, ya que los fabricantes de dispositivos finales a menudo tardan en trasladar las correcciones a sus revisiones de firmware.

Un ejemplo es la vulnerabilidad CVE-2022-3038 identificada en el motor del navegador Chrome 105 y corregida en junio de 2022. Esta vulnerabilidad permaneció sin parches durante mucho tiempo en navegadores específicos de proveedores como Samsung Internet. En diciembre de 2022, se revelaron hechos de ataques a usuarios de Samsung utilizando un exploit para esta vulnerabilidad (en diciembre, la versión actual del navegador de Internet de Samsung continuó usando el motor Chromium 102, lanzado en mayo de 2022).

Al mismo tiempo, para los navegadores, también hay un cambio en los intereses de los creadores de exploits a favor de las vulnerabilidades de 0-click en lugar de las vulnerabilidades de 1-click. 0-clic se refiere a las vulnerabilidades que no requieren la acción del usuario, por lo general afectan a otros componentes además del código del navegador en sí.

Se menciona que las vulnerabilidades 0-click son difíciles de detectar porque:

• son de corta duración
• A menudo no tienen un indicador visible de su presencia.
• Puede apuntar a muchos componentes diferentes y los proveedores ni siquiera siempre se dan cuenta de todos los componentes a los que se puede acceder de forma remota
• Entregado directamente al objetivo en lugar de ampliamente disponible como en un ataque de abrevadero
• A menudo no está alojado en un sitio web o servidor navegable

Mientras que con los 1-click, hay un enlace visible en el que el objetivo debe hacer clic para entregar el exploit. Esto significa que el objetivo o las herramientas de seguridad pueden detectar el enlace. Luego, los exploits se alojan en un servidor navegable en ese enlace.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/PBvhJQ3
via IFTTT

LXD, un administrador de contenedores del sistema, una herramienta para LXC

Ante la noticia que fue dada a conocer hace algunas semanas por parte de Canonical, sobre cambiar el modelo de desarrollo de LXD como un proyecto empresarial, en lugar de un proyecto comunitario independiente, se ha creado en respuesta a ello Incus.

Para quienes desconocen de LXD, deben saber que este proporciona herramientas para la gestión centralizada de contenedores implementados en un clúster de varios servidores. El kit de herramientas LXC se utiliza como tiempo de ejecución para ejecutar contenedores y LXD se implementa como un proceso en segundo plano que acepta solicitudes a través de la red a través de una API REST y admite varios backends de almacenamiento, instantáneas de estado, migración en vivo de contenedores en ejecución de una máquina a otra y herramientas para contenedores de almacenamiento de imágenes.

Y es que después de 8 años de desarrollo como parte de Linux Containers, Canonical, que es el creador y principal desarrollador de LXD, decidió que era lo más óptimo para el desarrollo de LXD. Esta decisión llevó a mover el código LXD del repositorio lxc/lxd a canonical/lxd , y la página principal del proyecto se convirtió en ubuntu.com/lxd, ademas de que la integración continua para LXD se migrará a los servidores de Canonical.

Este movimiento ha generado muchas preocupaciones a los desarrolladores, ya que uno de los problemas que más preocupa es el código adicional agregado a LXD, que se requiere para ejecutarse en formato snap y haga que LXD sea más difícil de usar y probar.

Sobre esto, Mark Shuttleworth, afirmó que Canonical no tiene la intención de dejar de admitir otras distribuciones en LXD, y que el proyecto continúa desarrollándose públicamente en GitHub y acepta correcciones y cambios de otros colaboradores.

Es por ello que en respuesta a ello se crearon los «Forks», Incus, que curiosamente son dos y coinciden en el mismo nombre, pero que fueron creados por personas diferentes, uno por Alexa Sarai, que trabaja para SUSE y mantiene los paquetes LXD en el proyecto openSUSE y el otro por Stéphane Graber, ex líder del proyecto LXD.

Sobre este último, Stéphane Graber, me gustaría mencionar que renuncio a su puesto de líder del proyecto LXD, una semana después de que Canonical se hiciera cargo de LXD, ya que no tiene la intención de firmar un acuerdo CLA con Canonical. Stefan creó una bifurcación de LXD, también bajo el nombre de Incus y que en su comentario sobre el anuncio de la nueva bifurcación, de Alexa Sarai, Stefan confirmó que el repositorio de la segunda bifurcación debería considerarse el principal.

Sobre el nuevo fork de Alexa Sarai se menciona que se pretende desarrollar una bifurcación del sistema de gestión de contenedores LXD.  La bifurcación se creó debido a la preocupación de que Canonical dejará de admitir correctamente otras distribuciones en LXD, ya que como se menciono los dentro de los planes de Canonical está el centrarse en entregar LXD en formato snap, que se posiciona como el formato principal para instalar LXD.

Y es que en particular, la mayor cantidad de usuarios de LXD no están en Ubuntu, sino en la plataforma ChromeOS, que utiliza la herramienta de compilación ebuild/portage de Gentoo Linux.

Incus (de Alexa Sarai) está trabajando actualmente para eliminar las dependencias redundantes y deshabilitar los enlaces a herramientas y tecnologías específicas de los productos de Canonical. El desarrollo de la bifurcación se realizará con la participación de la comunidad y teniendo en cuenta los intereses de proyectos de terceros.

Se menciona que la bifurcación se realizó en la versión LXD 5.16, lo que hace posible actualizar desde versiones LXD hasta LXD 5.16 inclusive. Es posible que la actualización desde una versión posterior de LXD no funcione, ya que es probable que los dos proyectos comiencen a divergir a partir de este punto.

Incus seguirá monitoreando e importando los cambios relevantes de LXD a lo largo del tiempo, aunque es poco probable que los cambios y características que son específicos de los productos de Ubuntu o Canonical se trasladen.

Finalmente, si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/ax95ekj
via IFTTT