El miércoles, investigadores informaron sobre vulnerabilidades críticas en un dispositivo de red ampliamente utilizado que deja algunas de las redes más grandes del mundo abiertas a la intrusión.

Las vulnerabilidades residen en BIG-IP Next Central Manager, un componente de la última generación de la línea de dispositivos BIG-IP que las organizaciones utilizan para gestionar el tráfico que entra y sale de sus redes. F5, con sede en Seattle, que vende el producto, dice que su equipo se utiliza en 48 de las 50 corporaciones más importantes según Fortune. F5 describe el Next Central Manager como un “punto de control único y centralizado” para gestionar flotas completas de dispositivos BIG-IP.

Como dispositivos que realizan equilibrio de carga, mitigación de DDoS e inspección y cifrado de datos que ingresan y salen de grandes redes, el equipo BIG-IP se ubica en su perímetro y actúa como una importante tubería hacia algunos de los recursos más críticos para la seguridad alojados en su interior. Esas características han hecho que los dispositivos BIG-IP sean ideales para la piratería. En 2021 y 2022, los piratas informáticos comprometieron activamente los dispositivos BIG-IP explotando vulnerabilidades con clasificaciones de gravedad de 9,8 sobre 10.

El miércoles, investigadores de la firma de seguridad Eclypsium informaron haber encontrado lo que dijeron eran cinco vulnerabilidades en la última versión de BIG-IP. F5 confirmó dos de las vulnerabilidades y lanzó actualizaciones de seguridad que las solucionan. Eclypsium dijo que tres vulnerabilidades restantes no han sido reconocidas y no está claro si sus correcciones están incluidas en la última versión. Mientras que las vulnerabilidades explotadas de 2021 y 2022 afectaron a versiones anteriores de BIG-IP, las nuevas residen en la última versión, conocida como BIG-IP Next. La gravedad de ambas vulnerabilidades tiene una calificación de 7,5.

«BIG-IP Next marca una encarnación completamente nueva de la línea de productos BIG-IP que promociona seguridad, gestión y rendimiento mejorados», escribieron los investigadores de Eclypsium. «Y es por eso que estas nuevas vulnerabilidades son particularmente significativas: no sólo afectan al nuevo buque insignia del código F5, sino que también afectan al Administrador Central en el corazón del sistema».

Las vulnerabilidades permiten a los atacantes obtener control administrativo total de un dispositivo y luego crear cuentas en sistemas administrados por el Administrador Central. «Estas cuentas controladas por atacantes no serían visibles desde el propio Next Central Manager, lo que permitiría una persistencia maliciosa continua dentro del entorno», dijo Eclypsium. Los investigadores dijeron que no tienen indicios de que alguna de las vulnerabilidades esté bajo explotación activa.

Ambas vulnerabilidades solucionadas se pueden explotar para extraer hashes de contraseñas u otros datos confidenciales que permitan comprometer cuentas administrativas en sistemas BIG-IP. F5 describió uno de ellos, rastreado como CVE-2024-21793, como una falla de inyección de Odata, una clase de vulnerabilidad que permite a los atacantes inyectar datos maliciosos en consultas de Odata. La otra vulnerabilidad, CVE-2024-26026, es una falla de inyección SQL que puede ejecutar sentencias SQL maliciosas.

Eclypsium dijo que informó tres vulnerabilidades adicionales. Una es una interfaz de programación no documentada que permite falsificaciones de solicitudes del lado del servidor, una clase de ataque que obtiene acceso a recursos internos sensibles que se supone que están fuera del alcance de personas externas. Otra es la posibilidad de que los administradores no autenticados restablezcan su contraseña incluso sin saber cuál es. Los atacantes que obtuvieron el control de una cuenta administrativa podrían aprovechar esta última falla para bloquear todo acceso legítimo a un dispositivo vulnerable.

La tercera es una configuración en el algoritmo de hash de contraseñas de bcrypt que permite realizar ataques de fuerza bruta contra millones de contraseñas por segundo. El Proyecto Abierto de Seguridad de Aplicaciones Web dice que el “factor de trabajo” de bcrypt, es decir, la cantidad de recursos necesarios para convertir texto sin formato en hashes criptográficos, debe establecerse en un nivel no inferior a 10. Cuando Eclypsium realizó su análisis, el Administrador Central lo configuró. a las seis.

Los investigadores de Eclypsium escribieron:

Las vulnerabilidades que hemos encontrado permitirían a un adversario aprovechar el poder de Next Central Manager con fines maliciosos. En primer lugar, cualquier atacante que pueda acceder a la interfaz de usuario administrativa a través de CVE 2024-21793 o CVE 2024-26026 puede explotar de forma remota la consola de administración del Administrador central. Esto daría como resultado un control administrativo total del propio gestor. Luego, los atacantes pueden aprovechar otras vulnerabilidades para crear nuevas cuentas en cualquier activo de BIG-IP Next administrado por el Administrador Central. En particular, estas nuevas cuentas maliciosas no serían visibles desde el propio Administrador Central.

Las 5 vulnerabilidades se revelaron a F5 en un lote, pero F5 solo asignó formalmente CVE a las 2 vulnerabilidades no autenticadas. No hemos confirmado si los otros 3 estaban solucionados en el momento de la publicación.

Los representantes de F5 no tuvieron una respuesta inmediata al informe. Eclypsium continuó diciendo:

Estas debilidades se pueden utilizar en una variedad de posibles rutas de ataque. En un nivel alto, los atacantes pueden explotar de forma remota la interfaz de usuario para obtener el control administrativo del Administrador central. Cambie las contraseñas de las cuentas en el Administrador central. Pero lo más importante es que los atacantes podrían crear cuentas ocultas en cualquier dispositivo controlado por el Administrador Central.

Las vulnerabilidades están presentes en las versiones 20.0.1 a 20.1.0 de BIG-IP Next Central Manager. La versión 20.2.0, lanzada el miércoles, corrige las dos vulnerabilidades reconocidas. Como se señaló anteriormente, se desconoce si la versión 20.2.0 corrige el otro comportamiento descrito por Eclypsium.

«Si se solucionan, está bien, teniendo en cuenta que la versión que los contiene seguirá siendo considerada vulnerable a otras cosas y necesitará una solución», escribió el investigador de Eclypsium, Vlad Babkin, en un correo electrónico. «Si no, el dispositivo tiene una forma a largo plazo para que un atacante autenticado mantenga su acceso para siempre, lo que será problemático».

Una consulta realizada mediante el motor de búsqueda de Shodan muestra sólo tres casos de sistemas vulnerables expuestos a Internet.

Dada la reciente serie de exploits activos dirigidos a VPN, firewalls, balanceadores de carga y otros dispositivos ubicados en el borde de la red, los usuarios de BIG-IP Central Manager harían bien en otorgar alta prioridad a parchear las vulnerabilidades. La disponibilidad de código de explotación de prueba de concepto en la divulgación de Eclypsium aumenta aún más la probabilidad de ataques activos.

Los piratas informáticos están explotando activamente un par de vulnerabilidades descubiertas recientemente para controlar de forma remota dispositivos de almacenamiento conectados a la red fabricados por D-Link, dijeron investigadores el lunes.

Aproximadamente 92.000 dispositivos son vulnerables a los exploits de adquisición remota, que pueden transmitirse de forma remota mediante el envío de comandos maliciosos a través de un simple tráfico HTTP. La vulnerabilidad salió a la luz hace dos semanas. El investigador dijo que estaban haciendo pública la amenaza porque D-Link dijo que no tenía planes de parchear las vulnerabilidades, que están presentes sólo en dispositivos al final de su vida útil, lo que significa que ya no cuentan con el soporte del fabricante.

Una receta ideal

El lunes, los investigadores dijeron que sus sensores comenzaron a detectar intentos activos de explotar las vulnerabilidades a partir del fin de semana. Greynoise, una de las organizaciones que informó sobre la explotación en estado salvaje, dijo en un correo electrónico que la actividad comenzó alrededor de las 02:17 UTC del domingo. Los ataques intentaron descargar e instalar uno de varios programas maliciosos en dispositivos vulnerables según su perfil de hardware específico. Uno de esos programas maliciosos está marcado con varios nombres por 40 servicios de protección de endpoints.

La organización de seguridad Shadowserver también ha reportado viendo escaneos o exploits desde múltiples direcciones IP pero no proporcionó detalles adicionales.

El par de vulnerabilidades, que se encuentra en la interfaz de programación nas_sharing.cgi de los dispositivos vulnerables, proporciona una receta ideal para la adquisición remota. La primera, identificada como CVE-2024-3272 y con una clasificación de gravedad de 9,8 sobre 10, es una cuenta de puerta trasera habilitada mediante credenciales codificadas en el firmware. El segundo es un fallo de inyección de comandos identificado como CVE-2024-3273 y tiene una clasificación de gravedad de 7,3. Se puede activar de forma remota con una simple solicitud HTTP GET.

Netsecfish, el investigador que reveló las vulnerabilidades, demostró cómo un hacker podría controlar remotamente dispositivos vulnerables enviándoles un simple conjunto de solicitudes HTTP. El código se ve así:

GET /cgi-bin/nas_sharing.cgiuser=messagebus&passwd=&cmd=15&system=<BASE64_ENCODED_COMMAND_TO_BE_EXECUTED>

En el siguiente ejemplo de explotación, el texto dentro del primer rectángulo rojo contiene las credenciales codificadas (bus de mensaje de nombre de usuario y un campo de contraseña vacío), mientras que el siguiente rectángulo contiene una cadena de comando malicioso codificada en base64.

«La explotación exitosa de esta vulnerabilidad podría permitir a un atacante ejecutar comandos arbitrarios en el sistema, lo que podría conducir a un acceso no autorizado a información confidencial, modificación de las configuraciones del sistema o condiciones de denegación de servicio», escribió netsecfish.

La semana pasada, D-Link publicó un aviso. D-Link confirmó la lista de dispositivos afectados:

Modelo	Región	Revisión de hardware	Fin de vida útil	Firmware fijo	Conclusión	Última actualización
DNS-320L	Todas las regiones	Todas las revisiones de H/W	31/05/2020 : Enlace	No disponible	Retirar y reemplazar dispositivo	01/04/2024
DNS-325	Todas las regiones	Todas las revisiones de H/W	01/09/2017 : Enlace	No disponible	Retirar y reemplazar dispositivo	01/04/2024
DNS-327L	Todas las regiones	Todas las revisiones de H/W	31/05/2020 : Enlace	No disponible	Retirar y reemplazar dispositivo	01/04/2024
DNS-340L	Todas las regiones	Todas las revisiones de H/W	31/07/2019 : Enlace	No disponible	Retirar y reemplazar dispositivo	01/04/2024

Según netsecfish, los análisis de Internet encontraron aproximadamente 92.000 dispositivos vulnerables.

Según el correo electrónico de Greynoise, los exploits que los investigadores de la empresa ven se ven así:

GET /cgi-bin/nas_sharing.cgi?dbg=1&cmd=15&user=messagebus&passwd=&cmd=Y2QgL3RtcDsgcLnNo HTTP/1.1

Otro malware invocado en los intentos de explotación incluye:

La mejor defensa contra estos ataques y otros similares es reemplazar el hardware una vez que llega al final de su vida útil. Salvo eso, los usuarios de dispositivos EoL deben al menos asegurarse de estar ejecutando el firmware más reciente. D-Link proporciona esta página de soporte dedicada para dispositivos antiguos para que los propietarios puedan localizar el firmware más reciente disponible. Otra protección eficaz es desactivar UPnP y las conexiones desde direcciones remotas de Internet a menos que sean absolutamente necesarias y estén configuradas correctamente.

ADVERTENCIAS DE FRAUDE ACTUALES

8 de marzo de 2024 a las 14:38

Si tiene un teléfono inteligente o una tableta con Android, actualmente corre un grave riesgo de sufrir ataques cibernéticos. Debido a brechas de seguridad, su dispositivo ya no está protegido.

Las vulnerabilidades de seguridad en los sistemas operativos representan una de las mayores oportunidades para que los ciberdelincuentes obtengan acceso a sus dispositivos y datos. Los dispositivos Android se ven afectados actualmente precisamente por este peligro.

Los dispositivos de Google, Samsung o LG con Android 12, 12L, 13 y 14 instalado se ven afectados por varias vulnerabilidades. Según el informe de seguridad de Android, están clasificados como críticos.

Dos de estas brechas de seguridad son particularmente peligrosas. Pueden permitir que terceros accedan al sistema operativo y ejecuten libremente código malicioso. Los piratas informáticos también podrían obtener derechos de uso no autorizados de su dispositivo móvil en el área de la conexión Bluetooth.

También hay problemas en el marco que podrían aprovecharse para llevar a cabo ataques DoS. También existen vulnerabilidades en el gestor de arranque, pero éstas sólo afectan a determinados fabricantes. Incluyendo Qualcomm y AmLogic.

Así te proteges

Para evitar ser víctima de un ciberataque, es importante actuar lo más rápido posible. Afortunadamente, los fabricantes también se lo han tomado en serio y ya te ofrecen las actualizaciones de seguridad necesarias para descargar.

Si tienes un smartphone o tablet con Android 12, 12L, 13 o 14, debes comprobar inmediatamente si la última actualización 2024-03-01 o 2024-03-05 ya se ha instalado automáticamente. Si ese no es el caso, tendrás que hacerlo manualmente. Para hacer esto, vaya al submenú «Sistema y actualizaciones» en la configuración.

• » Consejo: Los mejores proveedores de VPN para mayor seguridad y protección de datos
• » Comprar central eléctrica para balcón: Comparación de los mejores sistemas solares.

Es un mal día para los insectos. Hoy temprano, Sentry anunció su función AI Autofix para depurar código de producción y ahora, unas horas más tarde, GitHub está lanzando la primera versión beta de su función Autofix de escaneo de código para encontrar y reparar vulnerabilidades de seguridad durante el proceso de codificación. Esta nueva característica combina las capacidades en tiempo real de Copilot de GitHub con CodeQL, el motor de análisis de código semántico de la compañía. La compañía presentó por primera vez esta capacidad en noviembre pasado.

GitHub promete que este nuevo sistema puede remediar más de dos tercios de las vulnerabilidades que encuentre, a menudo sin que los desarrolladores tengan que editar ningún código ellos mismos. La compañía también promete que la reparación automática del escaneo de código cubrirá más del 90% de los tipos de alertas en los lenguajes que admite, que actualmente son JavaScript, Typecript, Java y Python.

Esta nueva característica ya está disponible para todos. GitHub Clientes de Seguridad Avanzada (GHAS).

«Tal como GitHub Copilot libera a los desarrolladores de tareas tediosas y repetitivas, la reparación automática del escaneo de código ayudará a los equipos de desarrollo a recuperar el tiempo que antes se dedicaba a la remediación”, escribe GitHub en el anuncio de hoy. «Los equipos de seguridad también se beneficiarán de un volumen reducido de vulnerabilidades cotidianas, de modo que puedan centrarse en estrategias para proteger el negocio mientras se mantienen al día con un ritmo acelerado de desarrollo».

En segundo plano, esta nueva característica utiliza el motor CodeQL, el motor de análisis semántico de GitHub para encontrar vulnerabilidades en el código, incluso antes de que se haya ejecutado. La compañía puso a disposición del público una primera generación de CodeQL a fines de 2019 después de adquirir la startup de análisis de código Semmle, donde se incubó CodeQL. A lo largo de los años, realizó una serie de mejoras en CodeQL, pero una cosa que nunca cambió fue que CodeQL solo estaba disponible de forma gratuita para investigadores y desarrolladores de código abierto.

Ahora CodeQL está en el centro de esta nueva herramienta, aunque GitHub también señala que utiliza «una combinación de heurística y GitHub API de Copilot” para sugerir sus soluciones. Para generar las correcciones y sus explicaciones, GitHub utiliza el modelo GPT-4 de OpenAI. Y aunque GitHub claramente tiene la suficiente confianza como para sugerir que la gran mayoría de las sugerencias de autocorrección serán correctas, la compañía señala que «un pequeño porcentaje de las correcciones sugeridas reflejarán un malentendido significativo del código base o la vulnerabilidad».

Un ataque de spam que afectó al rival de código abierto X, Mastodon, Misskey y otras aplicaciones, pone de relieve cómo la web social descentralizada, también conocida como fediverse, está abierta al abuso. En los últimos días, los atacantes se han dirigido a servidores Mastodon más pequeños, aprovechando los registros abiertos para automatizar la creación de cuentas de spam. El fundador y director ejecutivo de Mastodon, Eugen Rochko, confirmó el ataque en una publicación durante el fin de semana y agregó que los administradores del servidor de Mastodon deberían cambiar el registro al modo de aprobación y bloquear los proveedores de correo electrónico de eliminación para ayudar a combatir el problema.

Si bien este no es el primer ataque de spam que ha impactado a Fediverse, Rochko señala que anteriormente solo se habían atacado servidores más grandes como Mastodon.social. Como ese servidor está dirigido por el propio equipo de Mastodon, ellos mismos han podido mitigar esos ataques. Lo que es diferente esta vez es que los spammers se dirigieron a servidores más pequeños e incluso abandonados que ofrecían registro abierto, lo que permitió a los malos actores crear cuentas rápidamente y generar spam.

Este ataque en particular, que fue completamente automatizado cuando los atacantes descubrieron que podían escribir spam, fue causado por una disputa entre dos partes en Discord, donde una parte intentaba prohibir el servidor Discord de la otra parte, según informes de Mastodon. (Más detalles sobre esto aquí.) Muchos de los otros objetivos de los spammers no eran solo Mastodon: también apuntaban a Misskey. (Misskey es una plataforma de blogs descentralizada de código abierto que utiliza el protocolo ActivityPub, como Mastodon, Pixelfed, PeerTube y otros, lo que permite a sus usuarios interactuar con aquellos en otras plataformas sociales federadas). Dado que los orígenes del spam parecen ser japoneses En el foro, muchos de los objetivos también estaban en Japón.

El ataque de spam destacó una de las debilidades derivadas de la forma en que está estructurado el fediverso. Mastodon es un software de código abierto que cualquiera puede instalar en su propio servidor, esencialmente estableciendo su propia instancia o nodo, que se conecta con otros servidores de redes sociales federados, impulsados ​​por el protocolo ActivityPub.

Debido a que los servidores más pequeños de Mastodon son a menudo proyectos de aficionados dirigidos por entusiastas, eran vulnerables a este tipo de ataque. Si los administradores del servidor no prestaban atención a sus servidores a diario y ofrecían registros abiertos, probablemente eran víctimas del spam.

O como comentó un administrador de servidor, @[email protected]: “A algunos administradores de instancias se les recordó que tenían una instancia. Y también aprendimos que hay MUCHAS instancias abandonadas con la puerta abierta para registrarse sin aprobación”.

Durante los últimos días, los administradores del servidor trabajaron juntos para crear listas continuas de instancias abandonadas que otros administradores podrían usar como base para una lista de bloqueo para proteger a sus propios usuarios de los ataques de spam. Muchos servidores simplemente se cerraron porque sus administradores decidieron que sería más fácil esperar a que pasara el ataque o abandonar Mastodon por completo.

La popular aplicación Mastodon de terceros, Ivory, de Tapbots, lanzó una actualización de emergencia que incluía un filtro personalizado denominado «Spam potencial» en su pestaña Filtro que permitiría a los usuarios silenciar las menciones de spam. Los usuarios afectados podían activar este filtro para detectar la mayor parte del spam, pero no podían detener las notificaciones push de spam, dijo la compañía.

El ataque parece estar amainando a partir de esta mañana. El tecnólogo e investigador Tim Chambers (@[email protected]) señaló que hoy era el primer día en cuatro días en que tenía menos de 40 cuentas de spam para suspender en el servidor que administra, por ejemplo. Mastodon le dice a TechCrunch que en servidores activos con un equipo de moderación reactiva, Mastodon tiene múltiples herramientas para evitar el registro automatizado de cuentas, incluido el modo de aprobación, CAPTCHA y varias herramientas de bloqueo, por lo que el atacante fue manejado muy rápidamente. También señaló que el ataque de spam estaba disminuyendo ya que los dos grupos de hackers aparentemente habían hecho las paces.

Mientras que algunos vieron la experiencia como algo positivo para la red social y la diversidad social en general, ya que reveló una debilidad que ahora podía discutirse y abordarse, otros estaban enojados por la experiencia y la falta de respuesta de Rochko en las primeras horas del ataque.

“Esto está arruinando mi experiencia con Mastodon. Me dan ganas de alejarme y rendirme”, escribió un administrador del servidor Mastodon, [email protected]. «Y el continuo silencio de Eugen sobre el problema no ayuda con eso», dijeron.

El CTO de Mastodon, Renaud Chaput, dijo que el ataque impulsará a la empresa a mejorar su software.

“Por el momento, no existen buenas herramientas integradas para manejar esto, ya que se trata de un tema complejo: ¡las redes federadas no son fáciles! – pero tenemos muchas ideas sobre cómo mejorar nuestras funciones de lucha contra el spam y el abuso”, dijo. “Se trabajará en ello durante los próximos meses. Siempre estamos trabajando para mejorar el software (la última versión introdujo soporte captcha opcional). Otra medida que tomamos hoy es cambiar la configuración de las instancias nuevas para que no estén abiertas de forma predeterminada, y agregamos un banner para recordar a los administradores que las instancias completamente abiertas deben moderarse activamente, por lo que esta debe ser una decisión cuidadosa por parte del administrador. ”, añadió Chaput.

Desde la llegada de Instagram Threads, otro competidor de Twitter/X que también planea federarse mediante ActivityPub, el uso de Mastodon ha tenido una tendencia a la baja.

En octubre del año pasado, Mastodon había crecido hasta incluir alrededor de 1,8 millones de usuarios activos mensuales. Cuando Threads se lanzó públicamente, se había reducido a 1,5 millones. A partir del lanzamiento público de Bluesky este mes, otra red social descentralizada basada en un protocolo diferente (lo que significa que no es parte del mismo fediverso, al menos hasta que se construya un puente), el uso de Mastodon se había reducido a 1 millón de usuarios activos mensuales.

Ahí es donde continúa el uso de Mastodon en la actualidad, según la página de inicio de la compañía. El fediverse más amplio, que incluye Mastodon y otras aplicaciones, tiene alrededor de 2,9 millones de usuarios activos mensuales. La entrada de Threads en este espacio eclipsará a otros servidores de Mastodon y podría aportar la experiencia técnica de Meta en áreas como la prevención de spam, pero a muchos les preocupa que el objetivo final de Meta sea esencialmente hacerse cargo del fediverse convirtiéndose en el cliente predeterminado que los usuarios eligen y usando su recursos significativos para escalar la adopción de la aplicación de Meta.

Actualizado el 20/02/24, 1:31 pm ET para agregar el comentario del CTO de Mastodon

AMD ha revelado nuevas vulnerabilidades del lado del BIOS en todas sus generaciones de CPU Zen, lo que ha afectado particularmente a la conexión SPI, comprometiendo la seguridad.

Las vulnerabilidades recientemente descubiertas de AMD podrían conducir potencialmente a compromisos de seguridad de alto nivel y afectan a todas las generaciones de CPU Zen, pero se publicaron correcciones de BIOS

La aparición de vulnerabilidades en las arquitecturas de CPU no es sorprendente, pero esta vez, AMD aparentemente ha descubierto algo mucho más grande, que afecta a una base de consumidores más extensa, y su gravedad también figura como «alta» esta vez. Además, las vulnerabilidades descubiertas también ingresan desde el BIOS de su placa base; por lo tanto, el asunto es realmente delicado y, según AMD, las consecuencias de lo mencionado incluyen el «desencadenamiento» de códigos arbitrarios y mucho más.

Pasando a los detalles, AMD menciona que la vulnerabilidad se divide en cuatro compromisos diferentes y se basa en «estropear» su interfaz SPI, lo que puede conducir a actividades maliciosas como denegación de servicio, ejecución de códigos arbitrarios y la eludir la integridad de su sistema. Team Red ha descrito las vulnerabilidades en múltiples CVE y puedes ver sus hallazgos a continuación para tener una idea de lo costoso que puede ser:

CVE	Gravedad	Descripción CVE
CVE-2023-20576	Alto	Una verificación insuficiente de la autenticidad de los datos en AGESA puede permitir que un atacante actualice los datos de la ROM SPI, lo que podría provocar una denegación de servicio o una escalada de privilegios.
CVE-2023-20577	Alto	Un desbordamiento de montón en el módulo SMM puede permitir que un atacante tenga acceso a una segunda vulnerabilidad que permite escribir en SPI flash, lo que podría resultar en la ejecución de código arbitrario.
CVE-2023-20579	Alto	Un control de acceso inadecuado en la función de protección AMD SPI puede permitir que un usuario con acceso privilegiado Ring0 (modo kernel) evite las protecciones, lo que podría provocar una pérdida de integridad y disponibilidad.
CVE-2023-20587	Alto	Un control de acceso inadecuado en el modo de administración del sistema (SMM) puede permitir que los atacantes accedan a la memoria flash SPI, lo que podría provocar la ejecución de código arbitrario.

Sin embargo, lo bueno es que para mantenerse a salvo de las vulnerabilidades mencionadas anteriormente, AMD ha aconsejado a sus consumidores que actualicen a las últimas versiones de AGESA, que la empresa ya ha eliminado.

Las nuevas versiones apuntan a mitigaciones para todas las líneas de CPU AMD Ryzen, junto con las series EPYC, Threadripper y Embedded de AMD, lo que demuestra que siempre que tenga la versión correcta de AGESA cargada en sus sistemas, no será un gran problema. Gran oferta. Sin embargo, determinados SKU, como las APU Ryzen 4000G y 5000G, no han recibido parches de mitigación en sus respectivas placas base, lo que podría generar preocupaciones. Esto depende principalmente de los fabricantes de placas base. Aun así, creemos que las nuevas versiones de AGESA se adoptarán pronto.

CVE (AMD)		Procesadores de escritorio Ryzen serie 3000	Procesadores de escritorio Ryzen serie 5000	Procesadores de escritorio Ryzen serie 5000 con gráficos Radeon	Procesadores Ryzen serie 7000	Procesadores de escritorio Athlon serie 3000 con gráficos Radeon	Procesadores de escritorio Ryzen serie 4000 con gráficos Radeon
Versión mínima para mitigar todos los CVE enumerados		ComboAM4v2 1.2.0.B (2023-08-25)ComboAM4 1.0.0.B (Objetivo marzo de 2024)	ComboAM4v2 1.2.0.B (2023-08-25)	ComboAM4v2PI 1.2.0.C (2024-02-07)	ComboAM5 1.0.8.0 (2023-8-29)	ComboAM4v2 1.2.0.B (2023-08-25)ComboAM4 1.0.0.B (Objetivo marzo de 2024)	ComboAM4v2PI 1.2.0.C (2024-02-07)
CVE-2023-20576	Alto	ComboAM4v2 1.2.0.B (2023-08-25)	ComboAM4v2v 1.2.0.B (2023-08-25)	ComboAM4v2 1.2.0.B (2023-08-25)	ComboAM5 1.0.0.7b (2023-07-21)	No afectado	ComboAM4v2 1.2.0.B (2023-08-25)
CVE-2023-20577	Alto	ComboAM4v2 1.2.0.B (2023-08-25)ComboAM4 1.0.0.B (Objetivo marzo de 2024)	ComboAM4v2 1.2.0.B (2023-08-25)	ComboAM4v2 1.2.0.B (2023-08-25)	ComboAM5 1.0.0.7b (2023-07-21)	ComboAM4v2 1.2.0.B (2023-08-25)ComboAM4 1.0.0.B (Objetivo marzo de 2024)	ComboAM4v2 1.2.0.B (2023-08-25)
CVE-2023-20579	Alto	No afectado	No afectado	ComboAM4v2PI 1.2.0.C (2024-02-07)	ComboAM5 1.0.8.0 (2023-8-29)	No afectado	ComboAM4v2PI 1.2.0.C (2024-02-07)
CVE-2023-20587	Alto	No afectado	No afectado	No afectado	No afectado	No afectado	No afectado

CVE (AMD)		Procesadores Ryzen serie 6000 con gráficos Radeon	Procesadores Ryzen serie 7035 con gráficos Radeon	Procesadores Ryzen serie 5000 con gráficos Radeon	Procesadores Ryzen serie 3000 con gráficos Radeon	Procesadores Ryzen serie 7040 con gráficos Radeon	Procesadores móviles Ryzen serie 7045
Versión mínima para mitigar todos los CVE enumerados		RembrandtPI-FP7 1.0.0.A (2023-12-28)	RembrandtPI-FP7 1.0.0.A (2023-12-28)	CézannePI-FP6 1.0.1.0 (2024-01-25)	CézannePI-FP6 1.0.1.0 (2024-01-25)	FénixPI-FP8-FP7 1.1.0.0 (2023-10-06)	DragonRangeFL1PI 1.0.0.3b (2023-08-30)
CVE-2023-20576	Alto	RembrandtPI-FP7 1.0.0.9b (2023-09-13)	RembrandtPI-FP7 1.0.0.9b (2023-09-13)	No afectado	No afectado	FénixPI-FP8-FP7 1.0.0.2 (2023-08-02)	DragonRangeFL1PI 1.0.0.3a (2023-05-24)
CVE-2023-20577	Alto	RembrandtPI-FP7 1.0.0.9b (2023-09-13)	RembrandtPI-FP7 1.0.0.9b (2023-09-13)	CézannePI-FP6 1.0.0.F (2023-6-20)	CézannePI-FP6 1.0.0.F (2023-6-20)	FénixPI-FP8-FP7 1.0.0.2 (2023-08-02)	DragonRangeFL1PI 1.0.0.3a (2023-05-24)
CVE-2023-20579	Alto	RembrandtPI-FP7 1.0.0.A (2023-12-28)	RembrandtPI-FP7 1.0.0.A (2023-12-28)	CézannePI-FP6 1.0.1.0 (2024-01-25)	CézannePI-FP6 1.0.1.0 (2024-01-25)	FénixPI-FP8-FP7 1.1.0.0 (2023-10-06)	DragonRangeFL1PI 1.0.0.3b (2023-08-30)
CVE-2023-20587	Alto	No afectado	No afectado	No afectado	No afectado	No afectado	No afectado

Fuente de noticias: AMD

La explotación masiva comenzó durante el fin de semana de otra vulnerabilidad crítica en el software VPN ampliamente utilizado vendido por Ivanti, a medida que los piratas informáticos que ya atacaban dos vulnerabilidades anteriores se diversificaron, dijeron investigadores el lunes.

La nueva vulnerabilidad, identificada como CVE-2024-21893, es lo que se conoce como falsificación de solicitudes del lado del servidor. Ivanti lo reveló el 22 de enero, junto con una vulnerabilidad separada que hasta ahora no ha mostrado signos de ser explotada. El miércoles pasado, nueve días después, Ivanti dijo que CVE-2024-21893 estaba bajo explotación activa, agravando unas semanas ya caóticas. Todas las vulnerabilidades afectan a los productos Connect Secure y Policy Secure VPN de Ivanti.

Una reputación empañada y profesionales de la seguridad maltratados

La nueva vulnerabilidad salió a la luz cuando otras dos vulnerabilidades ya estaban bajo explotación masiva, principalmente por un grupo de piratas informáticos que, según los investigadores, está respaldado por el gobierno chino. Ivanti proporcionó orientación para la mitigación de las dos vulnerabilidades el 11 de enero y lanzó un parche adecuado la semana pasada. Mientras tanto, la Agencia de Seguridad de Infraestructura y Ciberseguridad ordenó a todas las agencias federales bajo su autoridad desconectar los productos Ivanti VPN de Internet hasta que se reconstruyan desde cero y ejecuten la última versión del software.

Para el domingo, los ataques dirigidos a CVE-2024-21893 se habían multiplicado, desde lo que Ivanti dijo que era un «pequeño número de clientes» hasta una base masiva de usuarios, según mostró una investigación de la organización de seguridad Shadowserver. La línea pronunciada en el extremo derecho del siguiente gráfico sigue el meteórico aumento de la vulnerabilidad a partir del viernes. En el momento en que se publicó esta publicación de Ars, el volumen de explotación de la vulnerabilidad superó el de CVE-2023-46805 y CVE-2024-21887, las vulnerabilidades anteriores de Ivanti bajo ataque activo.

Los sistemas que habían sido vacunados contra las dos vulnerabilidades más antiguas siguiendo el proceso de mitigación de Ivanti permanecieron completamente abiertos a la vulnerabilidad más nueva, un estado que probablemente los hizo atractivos para los piratas informáticos. Hay algo más que hace que CVE-2024-21893 sea atractivo para los actores de amenazas: debido a que reside en la implementación de Ivanti del lenguaje de marcado de afirmación de seguridad de código abierto (que maneja la autenticación y autorización entre partes), las personas que explotan el error pueden eludir las medidas de autenticación normales y obtener acceder directamente a los controles administrativos del servidor subyacente.

La explotación probablemente recibió un impulso gracias al código de prueba de concepto publicado por la firma de seguridad Rapid7 el viernes, pero el exploit no fue el único contribuyente. Shadowserver dijo que comenzó a ver exploits funcionales unas horas antes del lanzamiento de Rapid7. Todos los diferentes exploits funcionan más o menos de la misma manera. La autenticación en las VPN de Ivanti se produce a través de la función doAuthCheck en un binario de servidor web HTTP ubicado en /root/home/bin/web. El punto final /dana-ws/saml20.ws no requiere autenticación. Cuando se publicó esta publicación de Ars, Shadowserver contó un poco más de 22,000 instancias de Connect Secure y Policy Secure.

Las VPN son un objetivo ideal para los piratas informáticos que buscan acceso a lo más profundo de una red. Los dispositivos, que permiten a los empleados iniciar sesión en portales de trabajo mediante una conexión cifrada, se encuentran en el borde mismo de la red, donde responden a las solicitudes de cualquier dispositivo que conozca la configuración correcta del puerto. Una vez que los atacantes establecen una cabeza de puente en una VPN, a menudo pueden recurrir a partes más sensibles de una red.

La ola de tres semanas de explotación ininterrumpida ha empañado la reputación de seguridad de Ivanti y ha golpeado a los profesionales de la seguridad mientras luchan (a menudo en vano) para detener el flujo de compromisos. Para agravar el problema, se produjo un tiempo de parche lento que no cumplió con la fecha límite del 24 de enero de Ivanti por una semana. Para empeorar aún más las cosas: los piratas informáticos descubrieron cómo eludir los consejos de mitigación que Ivanti proporcionó para el primer par de vulnerabilidades.

Dados los comienzos en falso y lo que hay en juego, el mandato del viernes de CISA de reconstruir todos los servidores desde cero una vez que hayan instalado el último parche es prudente. El requisito no se aplica a las agencias no gubernamentales, pero dado el caos y la dificultad para asegurar las VPN de Ivanti en las últimas semanas, es una medida de sentido común que todos los usuarios ya deberían haber tomado.

Sequoia, el gigante del capital de riesgo de Silicon Valley, está respaldando a una incipiente startup danesa para construir una herramienta de análisis de composición de software (SCA) de próxima generación, que promete ayudar a las empresas a filtrar el ruido e identificar vulnerabilidades que son una amenaza genuina.

A modo de contexto, la mayoría del software contiene al menos algunos componentes de código abierto, muchos de los cuales están desactualizados y reciben un mantenimiento irregular (si es que lo reciben). Esto ha dado lugar a todo tipo de fallos de seguridad, como Log4Shell, que afectó al marco de registro de código abierto Java Log4j y provocó infracciones que afectaron a organizaciones de alto perfil, como una agencia federal de EE. UU. que no logró corregir el error. A su vez, esto está dando lugar a una serie de nuevas regulaciones, diseñadas para obligar a las empresas a gestionar una cadena de suministro de software más estricta.

El problema es que, con millones de componentes presentes en la cadena de suministro de software, no siempre es fácil saber si una aplicación determinada utiliza un componente en particular. Por supuesto, existen muchas herramientas de análisis de composición de software (SCA), desde Snyk hasta Synopsis, que alertan a las empresas sobre vulnerabilidades conocidas en su pila de tecnología, pero esto puede generar mucho ruido, especialmente si una aplicación no está activa. utilizando ese componente, lo que dificulta que los equipos de seguridad prioricen las vulnerabilidades que realmente importan.

Y aquí es donde la startup danesa de ciberseguridad Coana se propone marcar la diferencia, utilizando SCA «con reconocimiento de código» para ayudar a sus usuarios a separar alertas irrelevantes y centrarse solo en aquellas que importan.

Fundada en Dinamarca en 2021, Coana es obra de un profesor de informática (Anders Møller) y dos doctores (Martin Torp y Benjamin Barslev Nielsen) que dicen haber logrado un «avance técnico» mientras formaban parte de un grupo de investigación en Aarhus, Dinamarca. University, descubriendo una nueva técnica para analizar y comprender aplicaciones grandes basadas en JavaScript. El director ejecutivo, Anders Søndergaard, se unió al trío como cofundador en 2022, después de haber salido de una startup de tecnología biométrica anterior llamada Resilio el año anterior.

Para ayudar a financiar su empresa a través de su etapa de acceso temprano a la comercialización total, Coana anunció hoy que ha recaudado $ 1,6 millones en una ronda de financiación previa a la semilla liderada por Sequoia Capital, con la participación de Essence VC y una gran cantidad de ángeles, incluidos actuales y anteriores. ejecutivos de Google, Red Hat y GitHub.

Una aplicación típica puede constar de hasta un 90 % de bibliotecas de terceros, la mayoría de las cuales son de código abierto y mantenidas (o no) por cualquier número de desarrolladores voluntarios.

Por lo tanto, una empresa que crea software podría crear su propia capa de aplicación que se base en estas innumerables bibliotecas, creando una larga cadena de dependencias que están conectadas por funciones. Tradicionalmente, una herramienta SCA analizaba el número de versión de una dependencia particular, la asignaba a una base de datos de vulnerabilidades conocidas y luego informaba a los desarrolladores si encontraba una coincidencia. Sin embargo, en muchos casos, una aplicación solo puede usar una o dos funciones de una biblioteca de quizás 50, por lo que si existe una vulnerabilidad en una parte de la biblioteca a la que la aplicación nunca llama, en realidad no debería afectar esa aplicación.

Las empresas pueden utilizar Coana para crear lo que llaman un «gráfico de llamadas» de toda la aplicación, que abarca el código de la aplicación y las dependencias, para comprender las rutas del flujo de datos y luego utilizarlo para eliminar falsos positivos.

«La cantidad de paquetes que se utilizan y las líneas de código pueden ser extremadamente altas, por lo que requiere un análisis estático realmente sofisticado», dijo Søndergaard a TechCrunch. “El gráfico de llamadas nos permite hacer un gran análisis de todos los caminos posibles entre diferentes dependencias. Entonces, imagine una aplicación que consta de cientos o miles de dependencias, podemos identificar todos los caminos entre esas dependencias para comprender cuáles son realmente vulnerables y cuáles no”.

Por supuesto, todavía es muy temprano, ya que Coana presentó la primera versión de su producto en octubre para sus primeros clientes de pago: una combinación de empresas emergentes y en expansión de las etapas Serie B y Serie C. Sin embargo, la empresa está trabajando para ampliar su soporte más allá de JavaScript y a Java y Python este año, lo que le ayudará a dirigirse a una base de clientes más amplia.

«A medida que nuestro producto y nuestra empresa maduran, avanzamos en el mercado y eventualmente apuntamos a grandes empresas, pero pasará un tiempo antes de que tengamos la sofisticación del soporte lingüístico necesario para llegar a ese nivel», dijo Søndergaard.

Las empresas que quieran probar Coana hoy pueden solicitar acceso anticipado ahora.

Realmente siento que nos estamos acercando al futuro estilo Cyberpunk: 2077, donde los hackers netrunner básicamente se convertirán en magos, capaces de hacer explotar casi cualquier cosa con unas pocas líneas de código malicioso. Vale, la realidad puede ser mucho más aburrida, pero considerando que pusieron DRM en los trenes hace un tiempo, cruzo los dedos por los ciberbrujos en las próximas décadas.

¿Lo último en esta lista de tecnología sorprendentemente pirateable? El Bosch Rexroth NXA015S-36V-B, también llamado atornillador, que es un tipo de llave dinamométrica que se empezó a utilizar hace casi 100 años y que comparte muchas letras con «netrunner». Vivimos en un mundo de hermosas coincidencias.